生命保険協会の情報漏洩｜原因はゲストユーザー権限の誤付与、2.7万件の対象と現在の状況

一般社団法人生命保険協会は2026年7月29日、同協会が運営する生命保険契約照会システムで、利用者の個人情報が外部から特定の操作で閲覧できる状態になっていたと第一報で公表しました。2026年9月14日の調査結果で、原因は「ゲストユーザー（ログインしていない利用者）に、他の利用者の個人情報を参照できる権限が誤って付与された」ことだと確定しています。対象は延べ37,929件、重複を除くと27,407件で、項目は氏名・生年月日・住所・電話番号・メールアドレス・システム上の内部管理用IDです。

2026年10月16日時点で、協会のニュースリリース一覧に9月14日より後の続報はありません。WEB申請は9月15日に再開済みです。この記事では、確定した事実と現在の状況、自分が対象かの確かめ方を先に整理し、そのあとで未認証の利用者に権限が付く仕組み、同じ型の先行事例、開発工程での検出方法、再発防止の設計を実装者向けに解説します。

まとめ｜生命保険協会の情報漏洩で押さえる要点

利用者として知っておくべきことは2つです。対象は生命保険の加入者全員ではなく、2021年7月1日から2026年7月27日までに照会システムへアカウント登録した人（WEB・書面・電話のいずれの申請でも登録された人）に限られます。契約内容・保険金額・口座・クレジットカードの情報は、このシステムがそもそも保有しておらず、漏えいの対象ではありません。

実装者にとっての要点は、未ログインのゲストユーザーに参照権限が誤って付与されていた点です。閲覧に必要だった具体的な操作は公表されていません。未ログインのまま他人のレコードが返る設定が約5年残り、協会自身が「運用開始時の確認・検証およびその後の定期的な点検が十分ではなかった」と認めています。ログは直近1年分しかなく、外部からのアクセスは確認できても、実際に取得されたかは特定できませんでした。打ち手は、未認証の主体には公開する資源以外を既定で拒否し、「ログインしていない状態で何が見えるか」を検収と定期点検の両方で確かめることです。

生命保険協会の情報漏洩で確定した事実と10月時点の状況

対象件数の確定値｜延べ37,929件・重複除外27,407件

第一報の時点では、対象は氏名・住所・電話番号・メールアドレスの4項目、件数は「利用者ベースで約37,000件となる可能性」とされ、協会会員の生命保険会社の担当者情報も含まれるとされていました。9月14日の調査結果ではこれが改められ、件数は延べ37,929件・重複を除いた対象27,407件に確定しています。生年月日と内部管理用IDが対象に加わり、会員生保会社の担当者情報は対象外と確認されました。報道で広まった「3万7千人」は第一報の見込みで、確定値ではありません。

露出したのはアカウント登録者の属性情報で、照会の結果（どの会社に契約があったか）は外部から見えない状態でした。データベースへ到達されて保存データを持ち出された型とは打ち手が違い、その対比はPeakManagerの個人情報漏えい｜DB侵害・外部転送とデータ削除の技術解説で扱っています。

外部指摘から第一報、通知、WEB申請再開までの時系列

指摘を受けた日付は協会の資料には書かれておらず、7月22日は共同通信の配信記事によるものです。個人情報保護委員会へ報告した日付も公表されていません。

現在の状況は、2026年10月16日時点で次のとおりです。協会の生命保険契約照会制度のご案内には、システムを9月15日9時に再開したこと、書面による申請が立て込んでいて通常より手続きに時間がかかっていることが掲示されています。調査結果は「新たに公表すべき事実が判明した場合には、当会ホームページで速やかにお知らせ」するとしており、9月14日以降に続報はありません。

外部アクセスは確認、取得は特定できずという調査結果の読み方

協会は保存されていた直近1年分のアクセスログを検証し、「外部からのアクセスがあったことを確認」した一方で、個人情報が実際に取得されたと特定するには至らなかったとしています。本件に起因する被害申告や不正利用は、9月14日時点で確認されていません。

露出期間は約5年、検証できたログは1年分です。それ以前の約4年については、公表された直近1年分のアクセスログによる検証では、アクセスの有無を確認できません。協会は対象者全員への通知を公表していますが、通知範囲を決めた具体的な判断過程までは説明していません。

自分が対象かを確かめる方法と不審な連絡への備え

照会システムの対象者｜申請経路とアカウント登録期間

調査結果によれば、対象は2021年7月1日から2026年7月27日までの間に、WEB申請・書面申請・電話申請のいずれかで照会システムにアカウント登録された人です。書面や電話で申し込んだ人も、手続きの過程でシステムに登録されていれば対象に入ります。生命保険に加入しているだけの人、この期間に照会制度を使っていない人は対象外です。

対象者には2026年8月20日から協会がお詫びの文書を発送しています。心当たりがあるのに文書が届いていない場合や、対象かどうか確かめたい場合は、照会制度の問い合わせ先である生命保険相談所（03-3286-2648、平日9時〜17時）に問い合わせてください。

氏名と住所の組が狙われる理由と、連絡を受けたときの対応

生命保険契約照会制度は、家族が亡くなったときや認知判断能力が低下したときに、その人の生命保険契約の有無を協会加盟会社へまとめて確認する仕組みです。利用者名簿は「身近に相続や介護の事情がある世帯」という属性を帯びるため、氏名・生年月日・住所・電話番号が揃えば、保険金の受け取りや相続手続きを装った電話や勧誘の標的にされやすくなります。

協会は、不審な連絡を受けるなどの懸念がある場合は照会制度の問い合わせ先へ連絡するよう案内しています。電話やメールで手数料の振り込みや口座番号を求められても応じず、相手の名乗った窓口ではなく、協会の公式サイトに載っている番号へ自分でかけ直して確かめてください。

ゲストユーザーへの参照権限の誤付与が未認証の露出を生む仕組み

未ログインの利用者もひとつの主体として権限を持つ基盤の落とし穴

公開サイトを持つ業務基盤の多くは、ログインしていない訪問者を「ゲスト」という1人の利用者として扱い、ゲスト用のプロファイルや共有設定に読み取り権限を割り当てます。ここに利用者テーブルの参照権限が付くと、未ログインのまま他人のレコードが返ります。協会は基盤製品の名称を公表していませんが、原因の説明はこの構造そのものです。

この型は開発中の確認では見えにくい欠陥です。開発者も検収担当者もログインした状態で画面を確かめるため、正しく表示される画面しか目に入りません。ゲストの権限は画面の外で設定されており、コードレビューの差分にも現れないことがあります。

ログイン済み利用者のIDORと未認証ゲスト型の違い

IDOR（安全でない直接オブジェクト参照）は、オブジェクトの識別子に対する認可確認が欠け、権限のないデータを参照・変更できる欠陥です。以下では、認証済みの利用者同士で起こる典型例と本件を比べます。

分類上は、OWASP Top 10:2025のA01:2025 Broken Access Controlが挙げる「特定の機能・ロール・利用者にだけ許可すべきアクセスが誰にでも許可されている」状態、つまり既定拒否（deny by default）の原則違反に当たります。API文脈で第1位に置かれるAPI1:2023 Broken Object Level Authorization（BOLA）は、送られたオブジェクトIDに対する権限確認が無い型を主に指します。本件で公表されているのは、未認証のゲストへの参照権限の誤付与です。権限が製品の既定値だったか、オブジェクト単位の認可不備も伴っていたかは公表資料から判断できません。両方を抱えるシステムもあるので、検査はどちらか一方で済ませないでください。BtoCのアプリで認証・認可の欠陥が問われた例はタカラトミーのデュエマアプリ個人情報漏えい｜認証・認可実装の何が抜けたのかで扱っています。

ゲストユーザーを持つ基盤で先行した同型事例とSalesforceの既定強化

「ゲストユーザーに付いた権限から個人データが見える」型は、本件が初めてではありません。協会が使っていた基盤は公表されておらず、ここで挙げる製品が本件の基盤だと断定するものではありませんが、同じ構造の欠陥が国内で一度まとまって表面化しています。

2020年末から国内で相次いだSalesforceサイトの設定不備と個人情報保護委員会の注意喚起

セールスフォース社は2020年12月25日、Experience Cloud（旧Community Cloud）・Salesforceサイト・Site.comを利用する顧客で、組織の一部情報が第三者から閲覧できる事象が判明したと発表しました（ScanNetSecurityの報道による）。製品の脆弱性ではなく、ゲストユーザーに対する共有設定が適切に行われていない場合に起きる事象という説明です。翌2021年にかけて国内の複数の事業者が個人データの漏えいを報告し、個人情報保護委員会は令和3年5月31日にセールスフォース社のクラウド製品での権限設定に関する注意喚起を出しています。

注意喚起が挙げた典型は、会員登録や予約受付のようにゲストが個人データを入力するサイトで、保存されたレコードの所有者がゲストユーザーのまま残り、第三者から見えてしまう事例です。2020年7月以降に作成されたレコードは所有者が自動でゲスト以外になるものの、それ以前のレコードは自動では更新されないため、利用者側で所有者を内部ユーザーに付け替える必要があるとしています。基盤の仕様が直っても、過去のデータと過去の設定は利用者が直さない限り残る、という指摘です。

Salesforceの既定強化と読み取り共有ルールの残存リスク

Salesforceの公式ガイド「Share Securely with Guest Users」（Winter ’27版・2026年7月22日更新）によれば、Winter ’21以降は「Secure guest user record access」が無効化できない設定として有効になっています。通常のレコード共有でゲストに付与できるのは、ゲストユーザー共有ルール（条件ベースの共有ルールの一種）による読み取り専用のアクセスです。ゲストは更新・削除の権限も「すべて表示」「すべて変更」も持てません。ただし、過去の共有設定やシステムモードで動くApexなどは別途点検が必要です。

ここで見落としやすいのは、漏えいに必要なのは読み取りだけだという点です。基盤がゲストへの更新・削除権限や「すべて表示」権限の付与を制限しても、条件の広すぎる読み取り共有ルールを1本作れば、未ログインの訪問者に他人のレコードが返ります。本件の原因も「参照できる権限」の誤付与でした。基盤の既定強化は事故の上限を下げますが、「何をゲストに読ませるか」の判断は設定する側に残ります。同じガイドはゲストプロファイルの「API Enabled」権限を、明確に必要な場合を除いて無効にするよう強く推奨しています。APIからの読み取りは、画面をたどる検収では確かめにくい経路です。SaaSの設定を定期的に診断する手順の全体はSaaSセキュリティ対策の実装手順｜設定診断・OAuth棚卸し・ログ監視を解説にまとめています。

未認証アクセスと認可の欠落を開発工程と定期点検で検出する手順

ログインしない状態で他人のレコード取得を試す検査コマンド

最初に用意するのは「0人目の利用者」、つまり未ログイン状態での検査です。次の例は、自社の検証環境に対して、Cookieも認証ヘッダも付けずに参照系のエンドポイントを順に叩き、HTTPステータスを一覧にします。Linux・macOSのbash、またはWindowsのGit Bashで動きます。本番環境や他社のシステムには実行しないでください。

# endpoints.txt に、検証環境の参照系パスを1行1件で書いておく（例: /api/users/10428）
# Cookie・Authorization ヘッダを一切付けない＝未ログイン（ゲスト）としてアクセスする
BASE="https://staging.example.jp"
while IFS= read -r path || [ -n "$path" ]; do
  code=$(curl -q -sS -o /dev/null -w "%{http_code}" --max-time 10 "${BASE}${path}")
  echo "${code} ${path}"
done < endpoints.txt
# 拒否応答の例: 401・403・404。302はLocationと応答本文も確認する
# ステータスだけで合格にせず、非公開データが本文にないことを確認する
# 000や通信失敗は判定不能として再検査する
# 200 が出た行は、応答本文に他人の氏名や生年月日が入っていないかを必ず目視で確認する

200が返った経路がすぐ欠陥とは限りません。公開ページとして意図して見せている資源もあるからです。判定の決め手は応答本文で、個人情報が含まれていればゲストに参照権限が付いています。画面のURLだけでなく、基盤が自動で用意するAPIやデータ取得用の経路も一覧に入れてください。

Salesforceの前述のガイドも、ゲストの見え方の確認手順として、シークレットウィンドウでログアウト状態を作る、各オブジェクトの詳細ページへ直接リンクでアクセスしてアクセスできないことを確かめる、サイト内検索で特定のレコードを探す、サイトのsitemap.xmlを開いて検索エンジンに出している情報を確かめる、といった項目を挙げています。直リンクと検索の2つは、画面を順にたどるだけの検収では通らない経路です。

認可の自動テストに用いる未認証状態と利用者間の組み合わせ

テスト用のフィクスチャには、未ログイン（ゲスト）・同一組織の別利用者・所属組織の異なる利用者の3種類を揃えます。利用者Aでログインした状態から利用者Bのリソース識別子を指定したリクエストを送り、403か404が返ることを主要エンドポイントすべてで自動テストにします。OWASPのIDOR対策資料も、利用者A・Bとそれぞれの所有データを用意し、AからBのデータへアクセスできないことを検証する手順を示しています。退会済みの利用者を加えると、削除後のデータが見えないかまで確かめられます。

設定画面で付けるゲスト権限の差分レビューと定期棚卸し

本件の欠陥はコードではなく設定にありました。設定画面で権限を付け外しする基盤では、変更がコードレビューを通らないまま本番に入ります。対策は2つです。権限設定をエクスポートして構成管理に置き、変更のたびに差分をレビューすること。ゲストに付いている権限の一覧を四半期など決まった間隔で出力し、公開すべき資源だけになっているかを点検することです。運用開始時の検収に未認証アクセスの検査を入れ、運用後も同じ検査を回していれば、約5年の露出は短くできた可能性があります。

DASTやスキャナが認可不備を見つけにくい理由と診断の使い分け

自動診断ツールが認可不備を見落としやすいのは、「公開してよい応答」と「見えてはいけない応答」を区別できないためです。SQLインジェクションはSQLエラー、条件による応答差、応答時間の変化などを使って検出できる場合がありますが、未認証で個人情報が返る応答は、正常なJSONが200で返るだけです。どのデータが公開対象かという業務上の判断がないと、異常と判定できません。

予算が限られるなら、先に入れるべきは画面と経路を洗い出して既知の欠陥類型を一通り当てる脆弱性診断です。手法や費用相場は脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説で整理しています。認可制御の検証を外部に委ねるなら、脆弱性診断・セキュリティ診断のように設定と実装まで踏み込める体制を選ぶと、検出後にどの層へ認可判定を戻すかの設計まで扱えます。

漏えい発覚から個人情報保護法の報告期限までに開発側が動く順番

個人情報保護委員会への速報と確報の期限

個人情報保護委員会の漏えい等報告のページは、報告が義務となる類型の1つに本人の数が1,000人を超える漏えい等（又はそのおそれ）を挙げ、その例として「システムの設定ミス等によりインターネット上で個人データの閲覧が可能な状態となり」1,000人を超える場合を示しています。重複を除いて27,407件の本件は、この例にそのまま当てはまります。

速報は報告対象事態を知った後、速やかに行い、概ね3〜5日以内が目安です。確報は知った日から30日以内、不正の目的で行われたおそれがある場合は60日以内です（2026年10月16日時点の同ページの記載）。起算点は原因が判明した日ではなく発覚した日なので、調査の途中でも速報を出す必要があります。報告書の項目と書き方の実務は個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務で扱っています。

開発側がこの期限に巻き込まれるのは、報告に「漏えい等が発生した個人データの項目」「本人の数」「原因」が含まれるためです。本件でも第一報の4項目・約37,000件が、調査で6項目・27,407件へ改められました。どの項目が、どの経路で、何件返り得たのかを確定させる作業は、法務ではなくシステム側が担います。

1年分しか残らなかったアクセスログと保持期間の決め方

「閲覧可能な状態だった」ことと「実際に閲覧された」ことは別の事実です。区別するには、リクエストごとに「誰が（未認証か、どのアカウントか）」「どのリソース識別子に」「いつ」アクセスしたかが揃っている必要があります。実務で足りなくなるのは識別子の記録と保持期間です。POSTのボディに識別子が入る設計だとURLのログに残らず、未認証アクセスを記録しない設定の基盤もあります。個人情報を返す経路の参照ログは、事故の検知・調査に必要な期間、契約や法令の要件、保存コスト、ログ自体の個人情報保護を踏まえて保持期間を決めてください。

WEB申請の停止と書面申請の併存が支えた再開判断

協会は7月27日からWEB申請を止め、その間も書面申請を受け付け、災害時の電話申請も使える体制を保ちました。欠陥のある経路が1本とは限らない以上、システムごと止める判断は妥当です。停止を選べるかは平時の設計で決まり、オンライン以外の受付手段が並行してあれば申請を継続できますが、手作業の増加や処理遅延に備えた人員・処理能力も必要です。一方で、10月時点でも書面申請の処理に時間がかかっていると掲示されており、代替経路は処理能力ごと用意しておかないと停止明けまで滞留が残ることも示しています。

再発防止として実装と運用に落とす認可設計と効果が薄い対策の線引き

協会の3つの再発防止策を開発と運用の作業へ置き換える例

協会は再発防止策として「システム設定に関する確認の強化」「システムリスク管理の強化」「システム運営に関する確認・検証態勢の強化」の3つを掲げています。抽象度の高い表現なので、同じ型を防ぐための一般的な作業に置き換えると次のようになります。右列は協会が公表した内容ではありません。

RBACとRLSによる機能単位・行単位の認可制御

コード側の再発防止の核心は、認可判定を各所に手書きさせない構造へ移すことです。アプリケーション層で「このロールはこの機能を使えるか」を判定するのがRBACとは？ロールベースアクセス制御の仕組みと導入判断を実装視点で解説で整理したロールベースの制御で、ゲストもロールの1つとして明示し、何も許可しない状態から始めれば本件の型を構造で防げます。同じロールの利用者同士の境界は、データベース側でRLS（Row Level Security）とは？DBの行レベルセキュリティの仕組みと設定例のポリシーを使い、セッション上の利用者IDと行の所有者を突き合わせます。未認証時の利用者IDを必ず未設定として扱い、その場合に拒否するポリシーを適用すれば、非公開の行を返さない構成にできます。PostgreSQLではスーパーユーザーとBYPASSRLS属性を持つロールにポリシーが適用されず、テーブルの所有者も既定では対象外です（FORCE ROW LEVEL SECURITYで対象にできます）。アプリケーションはこれらと別の接続ロールで動かしてください。

WAFとログ監視で防げる範囲と防げない範囲

WAFは認可不備や権限設定の誤りをほぼ防げません。未認証のまま正規の形式で送られた参照リクエストは、公開ページへのアクセスとリクエストの見た目で区別がつかないからです。効くのは、未認証の接続元からの大量アクセスに対するレート制限と、短時間に多数の異なる識別子へアクセスする挙動の検知です。この検知を担うのはEDRとは？EPP・XDRとの違いと検知の仕組み・導入判断を実装者向けに解説【2026年時点】で扱う端末側の仕組みではなく、アプリケーションログを集める監視基盤の側です。正規の形式で大量に照会された同じ保険業界の事案と照会量の制御はアフラックの情報漏洩440万人｜大量照会を止められなかった原因と照会量制御の実装で扱っています。

外部委託で認可の要件が書かれないときに生まれる空白

要件定義書に「ログイン機能を実装する」とだけ記載すると、未認証アクセスや利用者間の認可を検収する条件が不明確になります。ログインは機能として要件に挙がりますが、「ログインしていない状態で何が見えてはいけないか」は書かなければ検収の対象になりません。非機能要件の欄に「未認証・認証済みの各主体について、許可されていない個人情報を参照できないことを全参照系の経路で検証する」と1行入れるだけで、受託側はテスト項目に落とせ、発注側は検収で確認できます。

再発防止の優先順位｜ゲスト権限・認可テスト・ログ

個人情報を扱う対外Webシステムを、ゲストユーザーの概念を持つ公開基盤やローコード基盤の上で運用しているなら、最優先はゲストに付いている権限と共有ルールの棚卸し、そして未認証アクセス検査の実行です。所要時間はサイト数や権限設定、検査対象の経路数によって変わります。まず対象範囲を定め、確認できた経路と未確認の経路を記録します。基盤の既定が強化される前に作ったサイトなら、過去に作られたレコードの所有者も確かめてください。

次に、自社開発のAPIを持つなら全参照系エンドポイントへ未認証・他人参照の自動テストを足します。テストは以後の機能追加すべてに効き続けます。そのうえで、アクセスログの粒度と保持期間を、調査に必要な期間と保存上の制約を踏まえて見直します。行レベル制御は、複数企業の情報を同居させる場合に加え、単一組織でも利用者・部署ごとに参照可能な行を分ける必要がある場合に検討します。生命保険の証券番号と契約内容まで漏えいした別の事案は、ソニー生命の不正アクセスで38.5万件が漏えいした事案の解説で整理しています。

よくある質問

生命保険協会の情報漏洩で契約内容や口座情報は流出したのですか？

流出していません。閲覧できる状態だったのは氏名・生年月日・住所・電話番号・メールアドレス・内部管理用IDの6項目です。生命保険契約の内容や保険金額、クレジットカード情報、口座情報等は照会システムで取得・保有しておらず、戸籍謄本や死亡診断書等の提出書類、契約の有無に関する情報も外部から閲覧できる状態ではありませんでした。

生命保険に加入している人は全員が対象ですか？

対象ではありません。対象は2021年7月1日から2026年7月27日までに、WEB・書面・電話のいずれかの申請で生命保険契約照会システムにアカウント登録された人です。対象者には2026年8月20日から協会がお詫びの文書を発送しています。

不正アクセスで情報を盗まれたということですか？

協会は、直近1年分のアクセスログで外部からのアクセスがあったことを確認したものの、個人情報が実際に取得されたとは特定できなかったと公表しています。被害申告や不正利用は2026年9月14日時点で確認されていません。原因は侵入ではなく、未ログインのゲストユーザーに参照権限が誤って付いていた設定不備です。サーバーへの侵入を伴う型との違いはEストアー（ショップサーブ）情報漏えい：どの店舗が対象か・お詫びメールは本物かと読み比べると分かります。

生命保険契約照会制度は今使えますか？

使えます。WEB申請は2026年9月15日9時に再開し、書面申請と災害時の電話申請も引き続き受け付けています。利用料は照会対象者1名につきWEB申請6,000円・書面申請7,000円です。2026年10月16日時点では、書面申請が立て込んでいて通常より手続きに時間がかかると案内されています。

今回の原因はIDORやBOLAと同じものですか？

公開情報だけでは同じ分類か断定できません。IDORやBOLAはオブジェクト単位の認可不備を扱う概念で、ログインの有無だけでは本件との違いを決められません。本件はログイン自体が不要で、未認証のゲストに参照権限が付いていた設定の問題です。OWASP Top 10:2025ではどちらもA01 Broken Access Controlに含まれます。

関連記事

• アフラックの情報漏洩440万人｜大量照会を止められなかった原因と照会量制御の実装
• タカラトミーのデュエマアプリ個人情報漏えい｜認証・認可実装の何が抜けたのか
• SaaSセキュリティ対策の実装手順｜設定診断・OAuth棚卸し・ログ監視を解説
• RBACとは？ロールベースアクセス制御の仕組みと導入判断を実装視点で解説
• 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務