デンマークCPRで880万人流出！サードパーティAPI連携の認証認可を見直せ

• 事実と背景：デンマークの住民登録簿「CPR」から、正規権限を持つ民間企業を経由して約880万人分の個人番号や住所が流出。
• 技術的変革：システム本体への直接侵入ではなく、APIや照会システムにおける「正規アカウントの権限濫用」が原因となった。
• 現場への影響：サードパーティ連携におけるゼロトラストモデルの徹底と、API利用時のレートリミットや振る舞い検知の導入が急務。

深夜2時に鳴り響くPagerDutyのアラート。インフラエンジニアなら誰もが心臓を凍らせるあの瞬間、今回のデンマーク政府の担当者たちも同じ絶望を味わったに違いない。2026年10月2日夜、デンマークの中央個人登録簿「CPR（Central Person Register）」の管理当局は、システム上での不審な挙動を検知した。週末を徹した調査の結果、判明したのは同国の人口（約600万人）を遥かに凌駕する「約880万人分」の個人情報流出という、国家規模のセキュリティ大惨事だった。

なぜ人口を超えるデータが流出したのか。それは、CPRが現在の居住者だけでなく、既に死亡した人や国外に転出した人の歴史的データも含めて一元管理しているからだ。全登録データ約1100万件のうち、実に8割に相当するデータが第三者の手に渡ったことになる。流出した情報には、氏名や住所だけでなく、日本のマイナンバーに相当する極めて機微な「CPR番号（個人番号）」が含まれていた。この事態に対し、デンマーク高等教育・科学・デジタル化省の担当大臣は「極めて深刻な事案」と表明せざるを得なかった。

しかし、我々エンジニアが最も戦慄すべきは、その侵入経路である。今回の事件は、SQLインジェクションやゼロデイ脆弱性を突いた、いわゆる「システムの隙間を狙ったハッキング」ではない。正規の照会権限を付与されていた「信頼された民間企業」のアカウントとアクセス経路が、そのまま悪用されたのだ。これは、どれだけ堅牢なファイアウォールを築き、WAFを最新の状態に保っていても、内側から鍵を開けられれば無力化するという、現代の分散型システムが抱える最大の急所を突いた事件であると私は考える。

開発現場において、外部パートナーやサードパーティ企業とのAPI連携は日常茶飯事だ。「仕様書通りにトークンを発行し、相手先のIPアドレスをホワイトリストに登録して疎通確認完了」。これで仕事が終わったと満足している開発者がいたら、今すぐその設計思想をゴミ箱に捨てるべきだ。今回の事件は、まさにその「一度確立された信頼関係」を盲信した結果引き起こされた、絵に描いたような特権の濫用である。

技術的な観点から見れば、問題の本質は「認証（Authentication）」と「認可（Authorization）」の混同、そして「レートリミット（流量制限）」および「アノマリ検知（振る舞い検知）」の致命的な欠如にある。正規の認証をパスしたアカウントであっても、通常業務の範疇を逸脱した「数百万件規模の一括ダウンロード」を許してしまったのは、認可モデルの設計ミスと言わざるを得ない。データベースのインデックスをフルスキャンするようなクエリや、短時間での大量リクエストに対して、なぜシステム側で自動的なサーキットブレーカーが作動しなかったのか。以下に、今回のインシデントにおけるデータ構造と流出のインパクトを整理する。

この表が示す通り、流出したデータは単なる公開情報ではなく、個人のアイデンティティを担保するコアデータだ。正規のアクセス権限を持つアカウントが、これほど広範囲のデータを一括で取得できる権限（特権）を保持していたこと自体が、セキュリティ設計における最大の「デッドロック」だったのだ。我々が構築するシステムでも、パートナー企業向けのAPIが「全件取得可能」な状態になっていないか、今一度コードベースを grep して確認する必要がある。

では、我々現場のエンジニアは明日からどう行動すべきか。単に「サードパーティを信用するな」という精神論では、ビジネスは1ミリも前に進まない。必要なのは、アーキテクチャレベルでの「ゼロトラスト（何も信用しない）」の実装である。具体的には、以下の3つの処方箋を即座に開発スプリントに組み込むべきだ。

• 最小特権の原則（Principle of Least Privilege）の徹底：外部連携アカウントには、その業務に必要な「最小限のレコード数」および「特定のクエリ条件」のみを許可する。一括エクスポート権限はデフォルトで剥奪し、必要な場合は多要素認証（MFA）と手動承認を挟むワークフローを義務付ける。
• 動的レートリミットとアノマリ検知：単一のトークンやIPアドレスからのリクエスト数に対して、時間あたりの閾値を厳しく設定する。さらに、普段は1日に数百件しか照会しないアカウントが、突如として数万件の照会を始めた場合に、自動的にアカウントを一時凍結（サスペンド）する振る舞い検知アルゴリズムをAPIゲートウェイ層に実装する。
• 監査ログのリアルタイム監視とアラート：アクセスログを単なるテキストファイルとしてサーバーに放置せず、SIEM（Security Information and Event Management）などの監視ツールにストリーミングし、異常なデータ転送量を検知した瞬間にオンコールエンジニアへ通知する仕組みを構築する。

今回のデンマークの悲劇は、対岸の火事ではない。日本国内でもマイナンバーカードの普及や、各省庁・自治体におけるAPI連携のデジタルシフトが急速に進んでいる。我々が便利さの裏で「信頼」という名のスパゲッティコードを放置し続ける限り、同様の惨劇はいつでも、どの開発現場でも起こり得る。あなたが今設計しているそのAPIは、本当に「裏切られた時」の備えができているだろうか？ 信頼の境界線をどこに引くべきか、今こそ我々エンジニアの倫理と技術力が試されている。