アフラック生命保険「よりそうネット」等への不正アクセス（顧客約440万人の契約情報、うち約22万人の保険料振替口座情報が漏えい）
公表日
アフラック生命保険の契約者向けサイト「よりそうネット」などが不正アクセス使う権限のない人が、他人のIDやパスワード、システムの弱点を使って、サービスやサーバーに入り込むことです。日本では「不正アクセス禁止法」で禁止されている犯罪です。を受け、顧客 約440万人の契約情報が漏えいしました。そのうち約22万人分には、保険料を引き落とす口座の情報も含まれていました。
対象者は？
アフラックの保険の契約者 約440万人です（漏えいは確定）。氏名・生年月日・住所・電話番号・証券番号・保障内容のほか、被保険者や受取人の氏名、緊急連絡先として登録した親族などの情報も含まれます（これらの人数は440万人に含まれず、公表されていません）。約22万人分は保険料振替口座の情報（金融機関名・口座番号・名義など）を含みます。代理店 約4万店の代表者の情報も漏えいしました。マイナンバー、クレジットカード情報、メールアドレス、よりそうネットのID・パスワードは含まれていません。
対象のお客様には、2026年7月30日までにお詫びの文書が送られています。詳しくは公式のお知らせとよくある質問（FAQ）で確認できます。
いますぐできること
- 保険会社や銀行を名乗る電話・SMS・郵便で、証券番号や保障内容を示されても信用しない。口座の変更や支払いを求められたら、手元の保険証券などに書かれた窓口に自分から確認する
- 保険料を引き落としている口座の入出金明細を確認し、身に覚えのない取引がないか見る
- 家族を受取人や緊急連絡先にしている場合は、家族にも不審な連絡に注意するよう伝える
何が起きたのか
2026年6月10日から25日にかけて、契約者向けサイト「アフラック よりそうネット」と、代理店が使う「オンライン相談」の2つのシステムに、第三者が何度も不正にアクセスしました。6月25日の朝、システムの負荷が急に高くなったことで気づき、会社は同じ日にアクセスを遮断してシステムを止めました。顧客 約440万人の契約情報が漏えいし、6月30日に公表されました。最初の発表（約438万人、6月15日から）は、7月13日に約440万人、6月10日からと訂正されています。
なぜ起きたのか・なぜ広がったのか
会社の調査では、攻撃が普段の利用と同じ形のアクセスだったため、すぐには不正と見分けられませんでした。また、短い時間に大量のデータが照会されたときに、それを見張って止める仕組みが足りていませんでした。設計時の確認やリリース前のテストでも、この手口は想定できていなかったと会社は説明しています。具体的にどの機能がどう悪用されたかは、まだ公表されていません。
いまの状況2026-10-01 時点続報待ち
よりそうネットは2026年9月28日に、初回登録の方法を変え、パスキー（パスワードに代わるログイン方法）を導入して、一部を除き再開しました。漏えいした口座の情報は、不正な取引を見張ってもらうために各金融機関へ提供されています。10月1日時点で、漏えいした情報の不正利用は確認されていないとしています。金融庁から報告を求める命令を受け、7月31日に調査結果と再発防止策を報告しました。補償の方針は発表されていません。
企業として考えたいこと
自社のWebサービスで、1人の利用者が短時間に大量のデータを見ていたら、それに気づける仕組みはあるでしょうか。
技術的な要約
アフラック生命保険の契約者専用サイト「アフラック よりそうネット」と、代理店が使う「オンライン相談」の2システムに、2026年6月10日から25日にかけて第三者による不正アクセスが複数回あった。6月25日6:30にシステムのCPU高負荷を検知して発覚し、同日アクセスを遮断して関連システムを停止した。漏えいは顧客約440万人（第一報では約438万人）の氏名・生年月日・住所・電話番号・証券番号・保障内容などで、うち約22万人は保険料振替口座情報を含む。代理店約4万店の代表者情報も漏えいした。7月31日の調査結果では、攻撃のアクセス形式が通常利用と同じで検知できなかったこと、短時間の大量データ照会を監視・制御する機能が不足していたことを原因に挙げ、同日、金融庁の報告徴求命令に基づき報告した。9月28日に初回登録方法の変更とパスキー導入を伴って、よりそうネットを一部を除き再開した。不正利用は確認されていないとしている。
攻撃の分類
- 侵入口
- 管理画面/API公表で確認公式（7/31調査結果）は『対象システムにおいて、今回の攻撃に使われたアクセスおよびデータ照会の手口に対する制御が不十分であった』『検知・遮断機能はあったが、通常利用と同様のアクセス形式であったため直ちに不正と判別できなかった』『短時間に大量のデータ照会があった場合の監視・制御機能が不足していた』『設計時のセキュリティレビューとリリース前の侵入テストでもこの手口のリスクを想定できていなかった』と説明している。再発防止策の第一項は『アクセス時の認証とデータ照会時の認可の強化』。認証方式、悪用された機能・API名、IDOR/BOLAかどうか、使われたアカウントが正規に作られたものか窃取されたものか、送信元、照会件数はいずれも非公表。分類は、公式が『データ照会の認可』と『大量照会の制御不足』を原因に挙げたことから 管理画面/API（認可不備）とした。分類はこちらの判断で、公式が『API』という語を使っているわけではない。
- 脆弱性
- CVE 非公表公表で確認アフラック よりそうネット／オンライン相談（自社システム）製品・OSSの脆弱性ではなく、自社システムのアクセス制御とデータ照会の認可に関する設計上の不備と公式が説明。大量照会のレート制限・監視が不足していた。具体的な欠陥の種類は非公表。
- 攻撃者
- 特定・主張なし
- ATT&CK
影響
- 業務停止
- あり 6/25に不正アクセスを遮断し、よりそうネットとオンライン相談の関連システムを停止。停止中は契約内容の確認や各種手続きをコールセンターで受け付けた（保険金・給付金請求は通常どおり）。9/28に初回登録方法の変更とパスキー導入を伴って、よりそうネットを一部を除き再開。2026年9月28日時点でも、支援金・祝金・長期給付無事故支払金の請求と、受取人・指定代理請求人の登録・変更はオンラインで利用できない。オンライン相談の再開状況は確認できなかった。期間：よりそうネットは2026-06-25〜2026-09-28に停止（約3カ月）。一部手続きは10/1時点でも停止中
- データ
- 確定上限 4,400,000確定 4,400,000人氏名生年月日性別住所電話口座取引先情報その他（証券番号、保障内容、受取人氏名、第二連絡先）顧客約440万人（契約者数で計上。第一報では約438万人）。うち保険料振替口座情報（金融機関名、支店名、預金種類、口座番号、口座名義など）を含むのが約22万人（第一報では約23万人）。項目は契約者の氏名・生年月日・性別・住所・電話番号、被保険者の氏名・生年月日・性別、受取人の氏名、証券番号、保障内容、第二連絡先（緊急時の連絡先に指定された親族等）の情報。被保険者・受取人・第二連絡先の人数は非公表で、440万人には含まれない。このほか代理店約4万店分（代表者氏名・住所・電話番号など。提携先や過去の代理店を含む）が漏えい。マイナンバー、クレジットカード情報、メールアドレス、よりそうネットのID・パスワードは含まれない。ASCIIの本文は『約483万人』と書いているが、見出しと公式の数字は438万人で、誤記とみられる。
- 波及先
- 40000 店（代理店、約）
- 代理店約4万店の代表者氏名・住所・電話番号が漏えい（提携先や過去の代理店を含む）
- パナソニック保険サービスが7/2に、自社経由の契約者向けの注意喚起を公表
- 日本理学療法士協会が7/1に、会員情報が含まれるかを確認中と公表
- 第一生命保険がアフラック商品の顧客情報が漏えいした可能性を発表（Rocket Boysの報道）
- 漏えいした口座の金融機関へ、口座情報を提供して不正取引の監視を依頼（個人情報保護法27条1項2号）
- 金銭影響
- 役員報酬の自主返納（代表取締役会長と代表取締役社長が月額報酬の30%×1カ月、取締役専務執行役員と常務執行役員が20%×1カ月）。特別損失、対応費用、補償の金額は公表されていない。
- サプライチェーン
- 委託先経由の侵入やソフトウェアサプライチェーンの関与は公表されていない。侵害されたのは自社システムだが、代理店が使う『オンライン相談』も対象で、代理店約4万店の情報が漏えいし、提携代理店（パナソニック保険サービス等）や団体（日本理学療法士協会）が自社の顧客・会員に注意喚起した。CRITERIAの判定例どおり③は付けていない。
時系列
技術解説
攻撃の構造：正規利用と同じ形での大量照会 事実
公式の調査結果によれば、攻撃は『通常利用と同様のアクセス形式』で行われた。そのため既存の検知・遮断機能では不正と判別できず、6月10日から25日までの約15日間に複数回、データ照会が繰り返された。対象は契約者向けの『よりそうネット』と、代理店が使う『オンライン相談』の2システムである。原因は『アクセスおよびデータ照会の手口に対する制御の不十分さ』と『短時間の大量照会の監視・制御機能の不足』とされ、再発防止策の筆頭は『アクセス時の認証とデータ照会時の認可の強化』である。つまり、認証を通過したセッションから、本来見えるべきでない範囲の契約データを大量に照会できた構造だったと公式自身が認めている。発覚のきっかけはセキュリティアラートではなくCPU高負荷（6/25 6:30）という性能指標だった。
何が悪用されたのか（推測） 解釈
手口の具体名は公表されていないが、再開時の変更点が手がかりになる。新規登録に保険証券等の『初回ID・仮パスワード』を必須にした点、利用状況による追加の本人確認、メールアドレス変更をログイン後に限定した点は、従来のアカウント登録・本人確認フローが、推測や入手が容易な情報（証券番号、生年月日など）で他人名義のアカウントを作成または乗っ取れた可能性を示す。もう1つの可能性は、照会APIのオブジェクト単位の認可（BOLA/IDOR）が不十分で、ログインした1アカウントから証券番号等のパラメータを変えて他人の契約を列挙できたことである。代理店向けの『オンライン相談』も対象であることから、代理店側の権限経路が使われた可能性もある。いずれも推測であり、攻撃者が正規アカウントを使ったのか、窃取した認証情報を使ったのかも公表されていない。
被害の性質：IDやパスワードではなく、詐欺の材料になる文脈情報 事実
漏えいにメールアドレスやID・パスワードは含まれないが、氏名・住所・電話番号に、証券番号・保障内容・受取人・第二連絡先（親族）・保険料振替口座が結びついている。保険会社や銀行を名乗る電話やSMS、郵送で『あなたの○○保険（証券番号××）の口座変更が必要』と持ちかける詐欺では、きわめて信憑性の高い材料になる。アフラックは約22万人分の口座情報を該当金融機関へ提供し、不正取引の監視を依頼した。個人情報保護法27条1項2号（財産の保護）を根拠に、個人情報保護委員会へ事前照会したうえでの提供で、漏えい後の二次被害対策としては珍しい。10/1時点で不正利用は確認されていないとしている。
公表と当局対応の評価 事実
判明（6/25）から5日後の6/30に第一報を出し、同日、金融庁が保険業法128条1項と個人情報保護法146条1項に基づく報告徴求命令を出した（報道）。7/13の第二報では、初回漏えい日を6/15から6/10に5日早め、件数を約438万人から約440万人に、口座情報を約23万人から約22万人に修正した。初期の痕跡調査が侵入期間の最初を取りこぼしていたことになる。7/31の調査結果では原因を設計レビューと侵入テストの不足にまで踏み込んで認め、経営陣の報酬返納も示した。一方、手口の種類、照会件数、送信元、攻撃者像は一切示されておらず、同種のWeb会員サービスを運営する事業者が自社と照合できる技術情報は乏しい。
なぜ15日間止められなかったか（解釈） 解釈
WAFやIDSのシグネチャ型の防御は、正規のリクエストと同じ形の照会を止められない。必要なのは、1セッション・1アカウント・1送信元あたりの照会件数や、照会対象の契約者数の分布といった『振る舞い』の監視である。アフラックは『短時間の大量照会の監視・制御機能が不足』と認めており、アプリ層でのレート制限や、1アカウントが参照する契約数の上限・異常検知がなかったとみられる。結果として、攻撃の検知はDBやアプリサーバのCPU高負荷という副作用頼みになった。大量照会がCPUの閾値を超えるほどでなければ、さらに長期間気づかなかった可能性がある。
対応
- 封じ込め
- 6/25に不正アクセスを遮断し、よりそうネット・オンライン相談の関連システムを停止。社内と外部の専門機関で調査（機関名は非公表）。再発防止策として、(1)アクセス時の認証とデータ照会時の認可の強化、(2)アプリケーションとセキュリティ機器での大量アクセス監視・制御の強化、(3)多層的なリスク分析によるセキュリティ要件の最新化と、設計レビュー・侵入テストの強化、(4)情報セキュリティ管理態勢の強化（基準の再整備、リリース前後の検証・監視、人財・体制の増強）。9/28の再開時に、初回ID・仮パスワード必須の登録、追加の本人確認、ログイン後に限定したメールアドレス変更、パスキー（今後必須化予定）を導入。漏えいした口座情報は金融機関へ提供し、不正取引の監視を依頼。
- 公表の仕方
- 6/30第一報（約438万人、口座約23万人、代理店約4万店、最初の不正アクセスは6/15）。7/1に報告徴求命令の受領を公表。7/6にFAQ公開。7/13第二報（初回漏えいを6/10へ、件数を約440万人・口座約22万人へ訂正）。7/10〜7/30に対象顧客全員へ文書を送付。7/31に調査結果・再発防止策・役員報酬返納を公表。8/24に金融機関への口座情報提供を告知。9/28にサービス一部再開。手口の詳細は公表していない。
- 当局対応
- 金融庁：6/30に保険業法128条1項と個人情報保護法146条1項に基づく報告徴求命令（共同通信・Rocket Boysの報道。アフラックの7/1公表は本調査で開けず未確認）。7/31に調査結果と再発防止策を報告
- 警察：6/30時点で報告済み
- 個人情報保護委員会：金融機関への口座情報提供（法27条1項2号）について事前照会
教訓と対策
| 教訓 | 具体的な対策 |
|---|---|
| データ照会の認可が不十分で、認証済みセッションから他人の契約データを照会できた | 照会APIの全エンドポイントで、セッション主体（契約者ID・代理店ID）と照会対象（証券番号等）の所有関係をサーバ側で検証する（BOLA対策）。連番・推測可能なIDを外部に出さず、不透明なIDを使う。認可テストを自動化し、他人のIDでの照会が403になることをCIで確認する |
| 正規利用と同じ形の大量照会を検知・制御できなかった | アカウント・セッション・送信元IP/ASN単位でのレート制限と、1アカウントが参照したユニーク契約数の上限を実装する。照会件数の分布を可視化し、上位パーセンタイルからの逸脱をリアルタイムでアラート化する（例：契約者アカウントが1時間に自分以外の証券番号を照会したら即遮断） |
| 推測しやすい情報だけでアカウント登録・本人確認ができた可能性がある（推測） | 初回登録には郵送したワンタイムコードなど、郵送物を持つ本人しか知らない要素を必須にする。登録とメールアドレス変更は既存の確認済みチャネルで再認証してから行い、パスキー等のフィッシング耐性のある認証へ移行する |
| 設計レビューと侵入テストで、正規機能の悪用シナリオを想定できていなかった | 脅威モデリングに『正規アカウントによる大量取得』『他人のリソース参照』『代理店権限の濫用』のシナリオを必須項目として入れ、OWASP API Security Top 10（API1:BOLA、API4:リソース消費の無制限）に基づく侵入テストをリリース前と定期で実施する |
| 検知が性能指標（CPU高負荷）頼みで、初回侵入日を後から5日訂正した | 照会ログ（誰が・どの契約を・いつ）を改ざん耐性のあるストアに長期保存し、事後に侵入期間と漏えい範囲を正確に再構成できるようにする。性能アラートが出たら、セキュリティ視点でトリアージする手順を運用に組み込む |
| 漏えい後の二次被害（口座悪用・なりすまし詐欺）への対策 | 口座情報など財産に関わる情報が漏えいした場合に備え、金融機関へ情報を提供して監視を依頼する法的根拠（個人情報保護法27条1項2号）と手順を、平時から整理しておく。顧客への通知文には、自社が電話・SMSで口座情報や暗証番号を聞かないことを明記する |
自組織などでの確認項目
- 自社の会員サイトやAPIで、ログインした1ユーザーが自分以外のレコードを照会しようとした場合、どの層で止まるか。それを確認する自動テストはあるか。
- 正規ユーザーと同じ形のリクエストで1日に数万件を取得されたら、今の監視で気づけるか。何を閾値にアラートを出しているか。
- 新規登録やメールアドレス変更で本人確認に使っている情報（会員番号、生年月日など）は、第三者が推測・入手できないか。
- 代理店・販売パートナー向けの画面やAPIが、顧客向けより広い照会権限を持っていないか。パートナーのアカウントが悪用された場合の上限はどこにあるか。
未解明点
- 悪用された具体的な手口（アカウント不正登録、認可不備によるID列挙、窃取した認証情報の利用、代理店権限の濫用など）と、侵入口が『よりそうネット』か『オンライン相談』か
- 攻撃者が使ったアカウントの種類と数、照会件数、送信元（IP、国、ボットの有無）
- 6/15から6/10へ初回漏えい日を訂正した経緯と、ログの保存状況
- 被保険者・受取人・第二連絡先として漏えいした人数（440万人には含まれない第三者）
- 外部調査機関の名称と、金融庁への報告内容の詳細
- オンライン相談の再開状況と、停止中の一部手続きの再開時期
- 攻撃者の正体・目的（本調査では犯行声明やリークサイトへの掲載を確認できなかった）
出典
- 1アフラック生命保険2026-06-30公式本文確認済
- 2アフラック生命保険2026-07-01公式未確認
- 3アフラック生命保険2026-07-13公式本文確認済
- 4アフラック生命保険2026-07-31公式本文確認済
- 5アフラック生命保険2026-10-01公式本文確認済
- 6アフラック生命保険2026-10-01公式本文確認済
- 7アフラック生命保険2026-08-24公式本文確認済
- 8アフラック生命保険2026-09-28公式本文確認済
- 9パナソニック保険サービス2026-07-02公式本文確認済
- 10Impress Watch2026-06-30報道本文確認済
- 11共同通信（熊本日日新聞）2026-06-30報道本文確認済
- 12共同通信（熊本日日新聞）2026-07-01報道本文確認済
- 13ASCII.jp2026-06-30報道本文確認済
- 14ScanNetSecurity2026-07-01報道本文確認済
- 15ScanNetSecurity2026-07-14報道本文確認済
- 16ScanNetSecurity2026-07-14報道本文確認済
- 17ScanNetSecurity2026-08-20報道本文確認済
- 18セキュリティ対策Lab（Rocket Boys）2026-07-02報道本文確認済
- 19セキュリティ対策Lab（Rocket Boys）2026-07-14報道本文確認済
- 20セキュリティ対策Lab（Rocket Boys）2026-08-03報道本文確認済
- 21セキュリティ対策Lab（Rocket Boys）2026-08-25報道本文確認済
- 22セキュリティ対策Lab（Rocket Boys）2026-09-30報道本文確認済