【2026年6月】アフラック生命保険「よりそうネット」への不正アクセス ― 通常の利用と同じ形式のデータ照会を見抜けず、顧客約440万人・代理店約4万店の個人情報が漏えい

2026-10-23

2026年6月30日、アフラック生命保険 は、契約者向けサイト「アフラックよりそうネット」などのシステムが第三者による不正アクセスを受け、顧客と代理店の個人情報が漏えいしたと公表しました。判明したのは6月25日で、6時30分にシステムの CPU 高負荷 を検知したことがきっかけでした。7月13日の第二報で、最初の漏えいは 6月10日 と訂正され、漏えいした顧客は 約440万人（うち保険料振替口座の情報を含む約22万人）、代理店は 約4万店 とされました。

7月31日に公表された調査結果では、「オンライン相談」と「よりそうネット」のシステムで、今回の攻撃に使われたアクセスとデータ照会の手口に対する制御が不十分だった と説明しています。不正アクセスを検知・遮断する機能はありましたが、アクセスの形式が通常の利用時と同様 だったため直ちに検知できず、短時間の大量照会を監視・制御する機能 も不足していました。本記事では、公表された範囲の事実を整理します。

■ この記事のまとめ

対象システム：契約者向けサイト「アフラックよりそうネット」と「オンライン相談」のシステム。ほかのシステムでは同種・類似の漏えいはないと確認
期間：最初の漏えいは6月10日（第一報では6月15日としていたが訂正）。6月25日まで複数回
発覚：6月25日 6時30分、システムの CPU 高負荷を検知。同日、不正アクセスを遮断し関連システムを停止
原因（7月31日）：アクセスとデータ照会の手口に対する制御が不十分。アクセスの形式が通常の利用と同様で直ちに検知できず、短時間の大量照会を監視・制御する機能も不足。設計時のレビューとリリース前の侵入テストでも想定できず
漏えい：顧客約440万人（うち保険料振替口座約22万人）、代理店約4万店。マイナンバー・クレジットカード情報・メールアドレスは含まず
分類：Web アプリケーションのアクセス制御（認証・認可）と量の制御の不備を突いた大量照会。手口の詳細は非公表

概要

項目	内容
被害組織	アフラック生命保険
対象システム	契約者向けサイト「アフラックよりそうネット」、「オンライン相談」
期間	2026年6月10日〜25日（複数回）
発覚	6月25日 6時30分、システムの CPU 高負荷を検知
原因（公表）	アクセスとデータ照会の手口に対する制御の不足、短時間の大量照会を監視・制御する機能の不足
漏えいした顧客	約440万人（第一報は約438万人）。うち保険料振替口座の情報を含む約22万人（第一報は約23万人）
主な項目	契約者の氏名・生年月日・性別・住所・電話番号、被保険者の氏名・生年月日・性別、受取人氏名、証券番号、保障内容、第二連絡先、保険料振替口座（金融機関名・支店名・預金種類・口座番号・口座名義など）
含まれない情報	マイナンバー、クレジットカード情報、メールアドレス
代理店	約4万店（代表者氏名、住所、電話番号など）
行政対応	金融庁報告徴求命令（6月30日）
攻撃者・手口の詳細	非公表

事件の時系列

日付	出来事
2026年6月10日	不正アクセスによる最初の情報漏えい（第二報で訂正）
6月10日〜25日	複数回にわたり不正アクセス
6月25日 6時30分	システムの CPU 高負荷を検知し、不正アクセスが判明。同日遮断し、関連システムを停止
6月30日	第一報（約438万人、最初の不正アクセスは6月15日）。金融庁が報告徴求命令
7月10日〜30日	対象の顧客へお詫びとお願いの文書を発送
7月13日	第二報。発生日を6月10日に、件数を約440万人に訂正。金融機関との連携を開始
7月31日	調査結果と再発防止策を金融庁に報告し、公表
8月24日	漏えいした保険料振替口座の情報を、該当の金融機関へ提供開始
9月28日	よりそうネットを一部の手続きを除き再開

① 初期アクセス：契約者向けの Web システム

不正アクセスを受けたのは、契約内容の確認や住所・電話番号の変更などをパソコンやスマートフォンから行う契約者専用サイト「アフラックよりそうネット」と、「オンライン相談」のシステムです。どちらもインターネットから利用者が直接使う Web アプリケーションです。

同社は、攻撃者がどのようにシステムにアクセスしたか（不正に入手した認証情報か、アプリケーションの欠陥か）を公表していません。ただし、再発防止策の1番目に「システムへのアクセス時における認証およびデータ照会時の認可を強化」を挙げていることから、認証と、照会するデータごとの認可の両方に、攻撃者に利用された弱点があったとみられます（T1190 とみられる。T1078 の可能性も否定できない）。

② 収集：通常の利用と同じ形式の大量照会

漏えいの範囲は約440万人で、契約者だけでなく被保険者や受取人、第二連絡先、保険料振替口座の情報まで含んでいました。1人の契約者が自分の契約を見るためのシステムから、これだけの人数分のデータが取得されたことになります（T1213）。

同社の説明では、システムには不正アクセスを検知・遮断する機能がありましたが、今回のアクセスの形式が通常の利用時と同様 だったため、不正アクセスとして直ちに検知できませんでした。1件ごとのリクエストが正規の画面や API と同じ形式であれば、シグネチャや形式のチェックに基づく防御（WAF など）では止まりません。一般に、こうした大量取得は、照会対象の識別子を変えながら他人のデータを要求する オブジェクト単位の認可の不備（OWASP API Security Top 10 の API1:2023 BOLA）や、業務フローを自動化して大量に実行する手口（API6:2023）で起こります。本件の手口がこれらに当たるかは公表されていません。

③ 検知：CPU 高負荷という「副作用」

同社は、短時間に大量のデータ照会があった場合に監視・制御する機能が不足していた ことも認めています。利用者や接続元ごとの照会件数の上限（レート制限）や、通常の利用からかけ離れた照会量の検知が働いていれば、より早く止められた可能性があります。

実際に不正アクセスに気づいたきっかけは、6月25日6時30分の CPU 高負荷の検知 でした。最初の漏えいから15日後で、その間、複数回の不正アクセスが続いていました。セキュリティの監視ではなく、性能の監視が異常を拾った形です。

④ 設計とテスト：想定できていなかったリスク

同社は、システム設計時のセキュリティレビューとリリース前の侵入テストを実施していましたが、今回の攻撃で使われた手口に関するリスクを想定できていなかった としています。再発防止策では、不正アクセスのリスクを多層的に分析してセキュリティ要件を最新化し、レビューと侵入テストを強化するとしています。

⑤ 封じ込めと二次被害の防止

6月25日に不正アクセスを遮断し、関連システムを停止しました。社内と外部専門機関の調査で、2つのシステム以外では同種・類似の情報漏えいがないことを確認しています。保険料振替口座の情報が漏えいした顧客については、二次被害を防ぐために金融機関と連携し、8月24日からは漏えいした口座情報（支店名、預金種類、口座番号、口座名義など）を該当の金融機関に提供しています。

よりそうネットは9月28日に一部の手続きを除いて再開しました。新規登録には「初回ID」と「仮パスワード」が必要になり、パスキーを導入して設定の必須化を予定しています。

MITRE ATT&CK との対応

段階（戦術）	技術	本件での事実
初期アクセス	T1190 Exploit Public-Facing Application（とみられる）／T1078 Valid Accounts（可能性）	契約者向け Web システムへの不正アクセス。再発防止策は認証と照会時の認可の強化（手口は非公表）
収集	T1213 Data from Information Repositories	通常の利用と同じ形式で、短時間に大量のデータを照会
持ち出し	（非公表）	顧客約440万人・代理店約4万店の情報が漏えい
検知	―	6月25日 6時30分、CPU 高負荷の検知で判明

本事件を未然に防ぐために必要な予防策

オブジェクト単位の認可：照会のたびに、ログイン中の利用者がそのデータ（契約、被保険者、口座など）を参照してよいかをサーバー側で確認します。識別子を変えれば他人のデータが返る作りになっていないかを、設計レビューと侵入テストの観点に必ず含めます。
量の制御と監視：利用者・セッション・接続元ごとの照会件数に上限を設け、超えたら遮断して通知します。通常の利用の件数・時間帯・順序と比べた振る舞いの検知を、性能の監視とは別に持ちます。
認証の強化：契約者向けサイトにはパスキーなどフィッシング耐性のある認証を導入します。同社も再開にあたってパスキーを導入しました。
画面ごとのデータ最小化：口座情報などの重要な項目は、必要な場面でだけ、追加の確認のうえ表示します。一覧や API の応答に必要以上の項目を含めないようにします。
侵入テストの範囲：脆弱性診断だけでなく、正規の機能を組み合わせた悪用（業務ロジックの悪用、大量取得）をテストのシナリオに入れます。

まとめ

アフラックの事件は、1件ずつは通常の利用と区別できない照会が積み重なって、約440万人分の情報が持ち出された事例です。検知・遮断の仕組みや設計レビュー、侵入テストを備えていても、照会ごとの認可と「量」の制御が抜けていれば防げません。最終的に異常を拾ったのは CPU の高負荷で、最初の漏えいから15日がたっていました。契約者向けの Web システムでは、「このデータをこの利用者に返してよいか」と「この量は普通か」の2点を、アプリケーションの側で確認し続けることが求められます。

■ メモ

本記事は、アフラック生命保険の公表（2026年6月30日、7月1日、7月13日、7月31日）と報道をもとに、公表された範囲の事実を整理したものです。攻撃者、具体的な手口（認証を突破した方法、照会に使われた機能）は公表されていません。OWASP API Security Top 10 との対応は一般論としての参考で、本件の手口を示すものではありません。