はじめに
アフラック生命保険は2026年6月30日、不正アクセスにより顧客の個人情報が流出したと発表しました。対象は当初約438万人とされ、7月13日の第二報で約440万人に訂正されています。翌7月1日には金融庁から保険業法などに基づく報告徴求命令を受け、7月31日には調査結果と再発防止策を金融庁へ報告し、その内容を公表しました。
公表された原因は、高度なゼロデイ攻撃のような特殊なものではありませんでした。「攻撃のアクセスが通常の利用とよく似ていたため、既存の検知機能ですぐには見抜けなかった」「短時間に大量のデータが照会されても、それを止める仕組みが足りなかった」「設計時のレビューや侵入テストでも、この手口を想定できていなかった」というものです。
これは、事業会社がシステムを発注するときに、要件として書くかどうかで差がつく部分です。この記事では、公表された事実を整理したうえで、発注側の担当者が自社のシステムに持ち帰って考えるべきポイントを整理します。
何が起きたのか
公表資料と各社の報道をもとに整理すると、経緯はおおむね次のとおりです。
- 6月10日：不正アクセス（情報漏えい）が始まる（第一報では6月15日とされ、第二報で訂正）
- 6月25日 早朝：社内システムでCPUの高負荷を検知し、調査の結果、不正アクセスが判明。同日中にアクセスを遮断し、関連システムを停止
- 6月30日：個人情報の流出を公表
- 7月1日：金融庁から報告徴求命令を受けたと発表
- 7月13日：第二報で、対象人数や不正アクセスの開始日を訂正
- 7月31日：調査結果と再発防止策を金融庁へ報告し、公表
対象となったシステムは、契約者向けの「アフラック よりそうネット」と、代理店が使う「オンライン相談」です。漏えいした情報の内訳は、おおむね次のとおりです。
- 顧客情報：氏名、生年月日、住所、電話番号、保険の保障内容など、約440万人分
- 保険料振替口座の情報：約22万人分（上記の内数。第一報の約23万人から訂正）
- 代理店情報：約4万店の代表者氏名、店舗の住所など
マイナンバー、クレジットカード情報、メールアドレスは含まれていないとされ、公表時点で情報の不正利用は確認されていないと説明されています。
なぜ見抜けなかったのか
調査結果で示された原因は、大きく3つに整理できます。どれも「特定の会社だけの問題」ではなく、多くの企業の顧客向けシステムに当てはまる論点です。
1. 正規の利用に似たアクセスは、検知機能があってもすり抜ける
対象のシステムには、不正アクセスを検知・遮断する機能がもともと備わっていました。それでも今回のアクセスは、通常の利用と同じような形式だったため、すぐには不正と判別できなかったとされています。
発注の現場では、「WAFを入れています」「不正アクセス検知の仕組みがあります」というベンダーの説明で安心してしまいがちです。しかし、検知の仕組みは「明らかにおかしいアクセス」を止めるのは得意でも、「正規の利用者のふりをしたアクセス」には弱いことがあります。仕組みが「ある」ことと、想定する攻撃を「止められる」ことは別物だと考えておく必要があります。
2. 「量の異常」を監視・制御する仕組みがなかった
もう一つの原因は、短時間に大量のデータ照会が行われた場合の監視・制御機能が不足していたことです。実際に異常に気づいたきっかけも、セキュリティ製品のアラートではなく、CPUの高負荷でした。不正アクセスの開始から発覚まで、約2週間かかっています。
1件1件のアクセスが正常に見えても、「1人の利用者が数分で数千件を照会している」という量の異常は、仕組みさえあれば検知できます。顧客向けの照会システムでは、1回の照会で取得できる件数の上限や、一定時間あたりの照会回数の制限（レート制限）は、機能要件と同じくらい重要な要件です。
3. 設計レビューと侵入テストで、この手口を想定できていなかった
三つ目は、設計時のセキュリティレビューとリリース前の侵入テストでも、今回の手口によるリスクを想定できていなかったことです。再発防止策としても、レビューとテストの見直しと、セキュリティ要件の最新化が挙げられています。
侵入テストは「やったかどうか」ではなく、「どんな攻撃シナリオを想定してテストしたか」で価値が決まります。テストの観点をベンダー任せにしていると、一般的な脆弱性診断の範囲で終わってしまい、自社のシステムに固有の「データを大量に抜かれるシナリオ」が検証されないままリリースされることがあります。
発注側が自社で整えておきたい仕組み
ここからは、事業会社の情シスやDX担当として、顧客データを扱うシステムを発注・更改するときに確認しておきたいポイントを整理します。
1. 非機能要件に「大量取得を防ぐ仕組み」を書く
要件定義では、画面や帳票といった機能要件に比べて、セキュリティの要件は「ベンダーの標準に準拠」の一文で済まされがちです。顧客情報を照会できるシステムでは、少なくとも次の点を要件として明記しておくことをお勧めします。
- 1回の照会で取得できる件数の上限
- 利用者ごと・一定時間あたりの照会回数の上限と、上限を超えたときの動き（遮断、管理者への通知など）
- 通常と異なる利用パターン（深夜帯の大量照会など）を検知したときの通知先
基幹刷新プロジェクトにおけるセキュリティ要件の整理でも触れたとおり、セキュリティ要件は後回しにされやすく、非機能要件として文書化しておかないと抜け落ちます。「何が起きたら困るのか」を言語化し、それを防ぐための要件まで落とし込むことが発注側の役割です。
2. 侵入テストの「想定シナリオ」を発注側も確認する
リリース前の侵入テストや脆弱性診断を依頼するときは、診断の結果だけでなく、どんな攻撃シナリオを想定したのかも確認しておくべきです。
- 正規のアカウントを不正に使われた場合に、どこまでデータを取得できるか
- 認証は通っていても、本来見られないはずの他人のデータを照会できないか（認可の不備）
- 大量の照会を自動で繰り返した場合に、どこで止まるか
テスト計画の立て方｜品質を担保する3つの観点で触れた考え方と同じく、テストの観点そのものに発注側が関与することで、「想定していなかった」というリスクを減らせます。
3. 「量の異常」に気づける監視を運用に組み込む
今回、異常に気づいたきっかけはCPUの高負荷でした。裏を返せば、データの照会件数そのものを見ていれば、もっと早く気づけた可能性があります。運用保守を委託する際は、障害監視（サーバーが止まっていないか）だけでなく、「照会件数やデータ取得量がふだんと比べて急に増えていないか」も監視項目に入れておくことをお勧めします。
4. 報告義務と初動の流れを平時から整理しておく
アフラックは、異常を検知したその日のうちにアクセスを遮断し、関連システムを停止しています。この速さは、誰がどの条件でシステムを止めるかが決まっていなければ実現できません。
また、個人情報の漏えいが起きた場合は、業種を問わず、個人情報保護法にもとづく個人情報保護委員会への報告と本人への通知が求められます。報告は速報と確報の2段階が基本です。業種によっては、今回の金融庁のように監督官庁への対応も加わります。プロジェクト炎上時に発注側が取るべき4つの初動と同じく、「何が起きたかが完全に分かってから動く」のではなく、被害拡大を防ぐ判断を先にできる体制を、平時のうちに整えておくことが重要です。
まとめ
アフラック生命保険の事案で公表された原因は、「正規の利用に似たアクセスを見抜けなかった」「大量の照会を止める仕組みがなかった」「レビューとテストでその手口を想定できていなかった」という3点でした。いずれも、高度な攻撃への備えというよりは、顧客データを扱うシステムの設計・テスト・運用で、何を要件にするかの問題です。発注側としては、大量取得を防ぐ仕組みを非機能要件に書くこと、侵入テストの想定シナリオを確認すること、量の異常に気づける監視を運用に組み込むこと、そして報告義務と初動の流れを平時から整理しておくことに取り組みたいところです。
参考
- セキュリティ対策Lab「アフラック生命保険、不正アクセスによる個人情報漏洩についての調査結果と再発防止策を金融庁へ報告」
- piyolog「アフラック生命保険への不正アクセスについてまとめてみた」
- 時事ドットコム「アフラック、438万人分情報流出 不正アクセス、23万人は口座情報も」
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント