アフラック生命保険は2026年6月30日、契約者専用サイト「アフラック よりそうネット」などのシステムが第三者の不正アクセスを受け、顧客の個人情報が漏えいしたと公表しました。第二報で顧客数は約440万人、最初の漏えいは6月10日と訂正され、7月31日には調査結果と再発防止策が出ています。公表された原因は、アクセスの形式が通常の利用時と同じで検知できなかったこと、そして短時間の大量照会を監視・制御する機能が足りなかったことでした。この記事では公式発表で時系列を確定させたうえで、会員サイトやAPIを運営する側が同じ穴を塞ぐための照会量制御を、nginxの設定とPythonのコードで示します。
まとめ：アフラック情報漏洩の確定事実と、照会量制御で実装者が持ち帰る教訓
確定している事実は次のとおりです。漏えいしたのは顧客約440万人（うち保険料振替口座の情報を含む約22万人）と代理店約4万店の情報で、マイナンバー、クレジットカード情報、メールアドレス、よりそうネットのID・パスワードは含まれていません。発覚は6月25日早朝のCPU高負荷で、最初の漏えいから15日が過ぎていました。よりそうネットは9月28日に一部を除いて再開しています。
| 項目 | 公表内容 |
|---|---|
| 最初の漏えい | 2026年6月10日（第一報の6月15日から訂正） |
| 発覚 | 2026年6月25日 6時30分 CPU高負荷検知 |
| 顧客 | 約440万人（第一報は約438万人） |
| 振替口座を含む顧客 | 約22万人（第一報は約23万人） |
| 代理店 | 約4万店 |
| 原因 | 通常と同形式のアクセス、大量照会の監視・制御の不足 |
| よりそうネット再開 | 2026年9月28日（一部を除く） |
実装側の教訓は1つに絞れます。認証を通った正規の形のリクエストでも、1つのアカウントが短時間に何人分の契約を読んだかを数え、上限を超えたら止める層を持つことです。IP単位のレート制限とWAFだけでは、この型の取得は止まりません。
アフラックの公式発表を時系列で整理｜6月10日の初回漏えいから9月28日の再開まで
第一報の438万人が第二報で440万人に、初回漏えい日が6月10日に訂正された経緯
6月30日の第一報では、不正アクセスが最初に発生したのは6月15日で、顧客は約438万人、うち振替口座情報を含むのは約23万人とされていました。報道の多くはこの数字のまま止まっています。
7月13日の第二報で、さらなる調査の結果として3点が書き換わりました。不正アクセスによる情報漏えいが最初に起きたのは6月10日、顧客は約440万人、振替口座を含む顧客は約22万人です。件数は契約者の人数で数えています。7月31日の調査結果と再発防止策は、この第二報の内容から変更はないと明記しました。記事やリスク評価で引用するなら、7月13日以降の数字を使ってください。
漏えい項目は契約者・被保険者・受取人・第二連絡先・振替口座まで及ぶ範囲
第二報で明記された顧客側の項目は、契約者の氏名・生年月日・性別・住所・電話番号、被保険者の氏名・生年月日・性別、受取人の氏名、証券番号、保障内容、第二連絡先の情報、保険料振替口座（金融機関名、支店名、預金種類、口座番号、口座名義など）です。第二連絡先とは、緊急時に契約者へ連絡がつかない場合に指定した親族等の氏名・生年月日・性別・住所・電話番号を指します。
項目自体は第一報から変わっていないと同社は説明しています。それでも、被保険者・受取人・親族まで並べて書き直したのは、契約者本人以外にも詐欺の連絡が届きうるからです。保障内容と家族構成がそろった名簿は、保険会社や金融機関を名乗る電話を本物らしく見せる材料になります。代理店側は代表者氏名・住所・電話番号で、過去に委託契約を結んでいた代理店も含みます。
よりそうネットのID・パスワードは漏えいせず、再開時に初回登録方法を変更
アフラックのFAQによれば、よりそうネットのID・パスワードとメールアドレスは漏えいしていません。同社は9月28日、再発防止策の実施と安全性の検証が完了したとして、一部を除いてよりそうネットを再開しました。支援金・祝金などの請求と、受取人・指定代理請求人の登録・変更は9月28日時点でまだ使えず、コールセンターで受け付けています。
再開にあわせて初回登録方法が変わり、ログインにはパスキーの登録が推奨されています。パスワードと併存させながらパスキーへ寄せていく実装の手順はパスキー移行の実装手順で扱いました。ただし今回の原因はログインの突破ではなく照会の量なので、パスキー化だけで同じ型の取得を防げるわけではありません。
金融庁の報告徴求命令と、個人情報保護法の報告が同時に走る保険会社の事情
第一報の翌日、アフラックは金融庁から報告徴求命令を受領したと公表しました。根拠は保険業法第128条第1項と個人情報保護法第146条第1項で、6月30日当日の命令です。7月31日には調査結果と再発防止策を金融庁へ報告し、役員4名の報酬の一部返納も発表しています。
一般の事業者でも、漏えいした本人が1,000人を超える場合や、不正の目的によるおそれがある場合は、個人情報保護委員会への速報と確報が必要です。速報は知った時点から3〜5日以内が目安で、原因がまだ判明していない段階でも提出が必要です。期限の数え方は個人情報保護委員会への報告義務に、委員会の様式と手引きは個人情報保護委員会の「漏えい等の対応とお役立ち資料」にまとまっています。金融分野の事業者は、監督官庁からの報告徴求が同時に来る前提で、影響件数を数日で出せるログを平時から持っておく必要があります。
公表された発生原因を実装の言葉に置き換える｜通常と同じ形式のアクセスと大量照会
「アクセスの形式が通常の利用時と同様」が既存の検知をすり抜けた構造
7月31日の発表は、原因を3つの文で説明しています。攻撃で使われたアクセスとデータ照会の手口に対する制御が不十分だったこと。不正アクセスを検知・遮断する機能は備えていたが、アクセスの形式が通常の利用時と同様だったため、直ちに検知できなかったこと。短時間に大量のデータ照会があった場合に監視・制御する機能が不足していたこと。
実装の言葉にすると、1件ずつのリクエストは正規の画面や正規のAPIが送るものと見分けがつかなかった、という意味です。WAFや侵入検知が見ているのは、SQLインジェクションの文字列や既知の攻撃シグネチャのように「形がおかしい」リクエストです。形が正しいリクエストを大量に送られると、1件単位の判定はすべて正常と出ます。異常は1件の中ではなく、同じ主体が短時間に何件読んだかという集計の中にしか現れません。
6月25日6時30分のCPU高負荷で発覚した事実が示す15日間の空白
FAQによると、発覚のきっかけは6月25日6時30分にシステムが検知した情報処理装置（CPU）の高負荷でした。セキュリティの監視ではなく、性能の監視が先に鳴ったことになります。最初の漏えいは6月10日なので、15日間は大量照会が止まらなかった計算です。第一報は6月25日までに複数回アクセスされたとしています。
CPUが張り付くほどの量になって初めて気づけた、という順番が問題の核心です。性能監視のしきい値はシステムを守るために置かれ、1人の利用者が通常の何十倍のデータを読んでいるかを見ていません。照会量の監視が業務単位で置かれていれば、負荷が上がるより前の段階で止められた可能性があります。
手口は非公表、再発防止策の「データ照会時の認可を強化」から読める範囲
アフラックは、攻撃で使われた手口の具体的な内容を公表していません。侵入に使われた認証情報の出どころも、照会がどの画面やAPIを経由したのかも不明です。この記事では手口を推測で断定しません。
読み取れるのは再発防止策の書き方までです。第1項に「システムへのアクセス時における認証およびデータ照会時の認可を強化」、第2項に「アプリケーションおよびセキュリティ対策機器における大量アクセスに対する監視と制御を強化」とあります。対策が認可と照会量の2本立てで書かれている以上、他人の契約に届く経路が開いていなかったか、という点検と、1主体あたりの照会量に上限を置く設計は、同種のシステムを持つすべての事業者に共通する点検・設計の対象です。他人のIDを渡したときに応答するかを確かめる方法は認可バイパスとはで、サーバ側の止め方まで解説しています。
アカウント単位の照会量制御｜nginxのlimit_reqとアプリ層の別契約数の計測
IP単位のレート制限が分散アクセスと正規セッションに効きにくい理由
まず思いつくのはIPアドレス単位のレート制限です。ただし今回のような取得に対しては、効く範囲が狭いと考えてください。攻撃側はクラウドや住宅用プロキシで送信元を数百に散らせます。1つのIPあたりの量を通常の利用者並みに抑えれば、IP単位の上限には引っかかりません。
OWASP API Security Top 10 2023のAPI4:2023 Unrestricted Resource Consumptionは、1回の応答で返すレコード数の上限や、一定時間内の操作回数の上限が無いAPIを脆弱と定義しています。加えてAPI6:2023 Unrestricted Access to Sensitive Business Flowsは、正規の業務フローを自動化して大量に回す悪用を別項目に分け、非人間的な操作パターンの分析を対策に挙げています。契約照会はまさにAPI6でいう機微な業務フローです。全10項目の位置づけはOWASP API Security Top 10 2023の全10項目にまとめました。
nginxのlimit_req_zoneのセッション単位キー設定例と空キーの落とし穴
入口で粗く絞る層としては、nginxのngx_http_limit_req_moduleが手軽です。キーには変数を組み合わせて使えるので、IPだけでなくセッションCookieを単位にできます。拒否時の応答コードは既定で503なので、429に変えておくとクライアント側が再試行の制御をしやすくなります。
# http コンテキスト（Cookie名 sid は自社の実装に合わせる）
limit_req_zone $cookie_sid zone=per_session:20m rate=30r/m;
limit_req_zone $binary_remote_addr zone=per_ip:10m rate=120r/m;
limit_req_status 429;
limit_req_log_level warn;
server {
location /api/policies/ {
limit_req zone=per_session burst=10 nodelay;
limit_req zone=per_ip burst=20 nodelay;
# limit_req_dry_run on; # しきい値を測る間は遮断せず記録だけ残す
}
}落とし穴は公式docsの1文にあります。キーの値が空のリクエストは計数されません。Cookieを付けずに送られたリクエストは per_session の制限を素通りするため、IP単位の zone を必ず併記します。もう1つの限界は、攻撃側がセッションを作り直せばキーも変わることです。nginxの層はあくまで粗い入口の絞りであり、ログインしたアカウント単位の上限はアプリケーション側で持つ必要があります。方式ごとの違いと429の返し方はAPIレート制限（レートリミット）とはで比較しています。
アプリ層で1時間あたりの別契約の参照数を数えて遮断するPython実装例
アプリケーション層では、リクエスト数ではなく「何件の別の契約に触れたか」を数えます。本人が自分の契約を何度開いても業務上は普通ですが、1つのアカウントが1時間に数十件の別契約を読むことは代理店の業務を除いてまずありません。標準ライブラリだけで動く最小の実装は次のとおりです。
import time
from collections import defaultdict, deque
WINDOW_SEC = 3600 # 集計する時間幅（1時間）
MAX_DISTINCT = 30 # 1アカウントが1時間に参照してよい「別の契約」の数
_seen = defaultdict(deque) # account_id ごとに (時刻, 契約番号) を保持
def allow_lookup(account_id, policy_no, now=None):
"""同じアカウントが短時間に何件の別契約を照会したかで判定する"""
now = time.time() if now is None else now
q = _seen[account_id]
while q and now - q[0][0] > WINDOW_SEC:
q.popleft()
distinct = {p for _, p in q}
if policy_no not in distinct and len(distinct) >= MAX_DISTINCT:
return False # 遮断して監視側へ通知する
q.append((now, policy_no))
return True
if __name__ == "__main__":
t0 = 1_000_000.0
ok = all(allow_lookup("A", f"P{i % 3}", t0 + i) for i in range(500))
print("本人の再参照500回:", "通過" if ok else "遮断")
results = [allow_lookup("B", f"P{i:07d}", t0 + i) for i in range(40)]
print("別契約の連続照会: 遮断開始 =", results.index(False) + 1, "件目")
print("1時間後:", allow_lookup("B", "P9999999", t0 + 40 + WINDOW_SEC))Python 3.14で実行すると、本人の契約3件を500回参照しても通過し、別の契約番号を1秒ごとに照会すると31件目で遮断され、1時間後には枠が戻ることを確かめられます。本番ではプロセス内の辞書ではなくRedisなどの共有ストアに置き、複数のアプリサーバーで同じ参照件数を共有できる構成にしてください。遮断と同時に監視基盤へイベントを送り、照会ログをアカウント単位で集計するSQLはセイコーマートの不正アクセスと57万人の会員情報で示した検知の組み方がそのまま使えます。
しきい値は本番ログの99パーセンタイルとdry runで先に測ってから決める
上限値を勘で決めると、正規の利用者を止めて問い合わせが殺到します。先に本番の照会ログから、アカウントごとの1時間あたりの別契約参照数を集計し、99パーセンタイルと最大値を確認してください。個人契約者なら数件に収まり、代理店の募集人アカウントは桁が変わるはずです。利用者の種別ごとに上限を分けるのが前提になります。
次に、nginxなら limit_req_dry_run、アプリなら「遮断せずにログだけ出す」モードで1〜2週間動かします。dry run中に上限を超えたアカウントを1件ずつ確認し、正規の業務で超えたものがあれば上限を調整します。この手順を飛ばして本番で遮断を始めるのは、障害を自分で起こすのと同じです。
侵入テストとセキュリティレビューで「想定外の手口」を減らすための見直し
侵入テストを実施していても大量照会のリスクを想定できなかった理由
アフラックは、システム設計時のセキュリティレビューとリリース前の侵入テストを実施していたが、今回の手口に関するリスクを想定できていなかったと説明しています。テストをしていなかったのではなく、テストの観点に入っていなかったという意味です。
一般的な侵入テストは、脆弱性を突いて権限を奪えるか、データベースに直接届くかといった「突破」を試します。正規の権限のまま正規の操作を大量に繰り返すことは、突破ではないので観点から漏れやすい。1件の照会が正しく動くことを確かめる機能テストでも見つかりません。試験計画に「同じアカウントで1時間に1,000件の別契約を照会したら止まるか」という項目が無い限り、誰も試さないままリリースされます。
OWASP API4とAPI6を受入条件に書き込み、業務フローの悪用を試験項目にする
塞ぎ方は、要件定義と受入条件に照会量の要件を1行ずつ足すことです。たとえば「認証済みの1アカウントが1時間に参照できる他契約の数は利用者種別ごとに上限を設け、超過時は429を返して監視基盤へ通知する」。この1行があれば、開発側は実装とテストに落とせ、発注側は検収で確かめられます。
試験項目は、API4とAPI6の観点で業務フローごとに作ります。照会、一覧表示、CSV出力、検索のそれぞれで、1回の応答で返る件数の上限、一定時間内の照会数の上限、上限超過時の挙動の3点を確認します。検索APIのページサイズ指定に上限が無く、1回で数万件返る作りは今でも珍しくありません。
外部診断の見積り段階で、認可と照会量の観点を指定しておく理由
外部の脆弱性診断やペネトレーションテストを発注するときは、見積りの前に診断観点を指定します。標準の診断メニューは注入系や設定不備が中心で、他人の契約に届くかという認可の観点と、上限なく照会できるかという照会量の観点は、指定しないと範囲外になりがちです。どちらの検査を先に入れるかはペネトレーションテストと脆弱性診断の違いで整理しています。
個人情報を返す会員サイトやAPIの点検を、検出後の改修設計まで含めて相談するなら脆弱性診断・セキュリティ診断の窓口を使ってください。報告書を受け取って終わりにせず、上限値をどの層に置くかまで決めておくと、同じ指摘が次の機能追加で戻ってくる事態を防げます。
照会量制御を入れる順番と、入れなくてよい場面を条件付きで言い切る
個人情報を一覧・詳細で返す会員サイトは照会数の上限を最優先で入れる
契約、会員、患者、顧客のような個人単位のレコードを、ログインした利用者にWebやアプリで返しているシステムなら、照会数の上限を最優先で入れてください。WAFの追加やSIEMの導入より先です。理由は単純で、正規の形をした大量照会を止められる層はアプリケーション自身しかないからです。
順番は、本番ログで現状の分布を測る、dry runで上限を試す、アプリ層で遮断と通知を入れる、nginxやAPIゲートウェイで粗い上限を足す、の4段階です。並行して、他人のIDで応答しないかという認可の点検を必ず行います。上限だけ入れても、1時間に30件ずつ読める穴が残っていれば、時間をかければ全件に届きます。
社内限定の業務システムやバッチ連携では、照会数の上限を見送ってよい
逆に、利用者が社員だけで、社内ネットワークやゼロトラストの経路からしか届かない業務システムでは、アカウント単位の照会数上限は後回しで構いません。業務上の大量参照が普通に起き、上限が業務を止める副作用のほうが大きいからです。この場合はアクセスログの保全と事後の監査で足ります。
システム間のバッチ連携やETLのように、そもそも全件を読むことが仕様の経路にも、照会数の上限は不向きです。代わりに、接続元の固定、専用の認証情報、実行時間帯の制限で守ります。上限を一律にかけて業務を止めるのは、この2つの場面では過剰な対策です。
よくある質問
アフラックの情報漏洩について検索されている疑問のうち、公式発表で答えられるものと実装者からの質問をまとめました。
アフラックの情報漏洩で、自分の情報が対象かどうかはどう確かめますか？
対象となる顧客には、7月10日からお詫びとお願いの文書が順次送られ、7月30日に発送が完了したと7月31日の発表に書かれています。文書が届いていない場合や判断がつかない場合は、本件専用のコールセンター（0120-332-856）に問い合わせてください。受付時間は状況に応じて変わるため、公式のお知らせページで最新の時間を確認するのが確実です。
よりそうネットのパスワードは変更したほうがよいですか？
アフラックのFAQでは、よりそうネットのID・パスワードとメールアドレスは漏えいしていないため、継続して使って問題ないとしています。不安がある場合はパスワードを再設定でき、あわせて推奨されているのがパスキーの登録です。注意すべきは、氏名・生年月日・住所・電話番号から推測しやすいパスワードや暗証番号を他のサービスで使っている場合で、FAQもその変更を勧めています。
漏えいした口座情報だけで、預金を引き出されることはありますか？
FAQは、今回漏えいした情報のみで直ちに預金が引き出されるものではないと説明しています。危ないのは、漏えいした情報を使って保険会社や金融機関、警察を装い、暗証番号やワンタイムパスワードを聞き出す詐欺です。アフラックや金融機関がこれらを電話やSMSで尋ねることはありません。振替口座の不審な取引に気づいたら、金融機関とアフラックの両方へ連絡してください。
アフラックの不正アクセスの手口は何だったのですか？
2026年10月6日時点で、手口の具体的な内容は公表されていません。公表されているのは、攻撃で使われたアクセスとデータ照会の手口に対する制御が不十分だったこと、アクセスの形式が通常の利用時と同様で直ちに検知できなかったこと、短時間の大量照会を監視・制御する機能が不足していたことの3点です。再発防止策では、データ照会時の認可と大量アクセスの監視・制御の強化が挙げられています。
自社の会員サイトで同じことが起きないか、まず何を確かめればよいですか？
2つを確かめてください。1つは、ログインした利用者が他人の会員IDや契約番号を指定したときにAPIが応答しないか。もう1つは、1つのアカウントが1時間に何件の別レコードを読めるかに上限があるかです。後者は本番ログから利用者ごとの参照件数を集計すれば、上限が無いことも、現状の最大値もすぐ分かります。どちらも検証環境の専用アカウントで試してください。
関連記事
- 生命保険協会の契約照会システム情報漏えい｜ゲストユーザー権限の設定不備を技術解説：同じ保険業界で起きた、認可の設定不備による漏えいの解説です
- タイムズカーの不正アクセスと免許証画像160万件の流出｜退会者まで残さない保管設計：漏えい時の被害を小さくする保管設計の側から扱っています
- Gyazoの不正アクセスと2,362万件の流出｜利用者の点検手順とアップロード基盤の見直し：大量の利用者データが一度に流出した事案の点検手順です
- 時系列データの異常検知｜手法の選び分けとしきい値・評価・アラート運用を実装目線で解説：照会量の上限を固定値でなく統計で決めるときの手法です
- WAFとは？仕組み・ファイアウォール／IPS・IDSとの違いと企業の選び方を解説：WAFで止められる範囲と止められない範囲の切り分けに使えます
