記事一覧に戻る
セキュリティ動向2026年8月1日7分で読めます

生命保険協会の第一報、この文書には「書かれていないこと」がある

生命保険協会「生命保険契約照会システム」の第一報を、2020年からのSalesforce設定不備の時系列と重ねて読み解く。約37,000件が閲覧可能な状態だった第一報の何に注目し、第二報で何を確認すべきか——4つの観点を示す。

7月29日、生命保険協会が「生命保険契約照会システム」で、約37,000件の個人情報が外部から閲覧可能な状態だったと公表した。

氏名、住所、電話番号、メールアドレス。

実際に第三者が取得したかどうかは、まだ調査中だ。

亡くなった家族の生命保険を探すための、あの制度である。

この第一報、よく読むと不思議な書き方をしている。

「不正アクセスを受けた」とは書いていない。

「侵入された」とも書いていない。

書いてあるのは、

「外部から特定の操作を行うことで閲覧可能な状態となっていた」

という説明だ。

事件の描写ではない。

状態の描写である。

誰かがシステムの内部へ侵入したというより、外部公開側のアクセス制御に穴があった。

そう読める文章になっている。

発覚の経緯も、

「外部のセキュリティ専門機関からの指摘により判明」

とある。

つまり、開いていることに気づいたのは協会ではなく、外の誰かだった。

この組み合わせ、どこかで見たことがないだろうか。

時計を2020年12月に戻す

楽天とPayPayが相次いで情報流出を公表した。

原因はどちらも、クラウドサービスSalesforceの「設定不備」だった。

ログインしていない訪問者にまで、データが見える設定になっていた。

楽天では、その状態が約5年間続いていた。

2021年1月、NISC、当時の内閣サイバーセキュリティセンターが注意喚起を出した。

イオン銀行、バンダイ、自治体のシステム。

同じ種類の設定不備が、次々に見つかった。

この時期、「Salesforceの設定不備」は、国内のセキュリティ関係者なら誰もが知る問題になった。

翌2月には、Salesforce自身も公式に説明を出した。

製品固有の脆弱性ではなく、ゲストユーザーのアクセス権設定に関する問題だと説明し、点検用の「ゲストユーザ アクセスレポート」も案内した。

そして2021年7月1日。

生命保険協会は、生命保険契約照会制度を開始した。

このシステムが何の上に載っているかは、推測する必要がない。

協会のWeb申請先は、Salesforce Experience Cloudのドメインに置かれている。

さらに協会の理事自身も、Salesforce主催のイベントに登壇し、この制度でSalesforceのSaaSソリューションを活用していると説明している。

どのような課題があり、なぜSalesforceを選んだのか。

DXの活用事例として、対外的に語られてきた。

NISCが注意喚起を出し、Salesforce自身が説明と点検手段を示した、その約5か月後の稼働である。

問題は、Salesforceを選んだことではない。

既知の問題を、稼働前に点検したかどうかだ。

その後、2023年4月にはKrebsOnSecurityが、米国でも銀行、医療機関、州政府などが同様の設定不備によって情報を露出していたと報じた。

Salesforce社の立場は一貫している。

これは製品の脆弱性ではなく、利用者側の設定の問題である。

つまりこの問題は、2020年から2023年にかけて、国内外で繰り返し可視化され、警告され、点検するための道具まで用意されていた。

そこに、2026年の第一報が届く

同じ基盤。

「特定の操作で閲覧可能」という似た型の文言。

外部からの指摘という発覚経路。

同じ問題ではないのか。

断定はできない。

原因を知っているのは協会だけだ。

Salesforceのゲストユーザー設定とは別の、アプリケーション側の不具合かもしれない。

途中の設定変更によって生じた問題かもしれない。

だが、もし同じ種類の問題だとしたら、問いはひとつ残る。

これだけ知られていた問題を、なぜ外部から指摘されるまで見つけられなかったのか。

導入は、こっそり行われたものではない。

DXの取り組みとして、対外的に語られてきた。

導入を決め、成果を発信する体制はあった。

では、同じ基盤で国内外から警告されていたアクセス制御の問題を、点検する体制はあったのか。

稼働前に、未ログインの利用者から何が見えるかを確認したのか。

画面の表示だけでなく、URLやパラメータを変えた直接操作まで試したのか。

点検する役割は、協会と開発会社のどちらに割り当てられていたのか。

途中の設定変更で生じたのなら、変更時のセキュリティ審査はどうなっていたのか。

ゲストユーザーの権限を、稼働後も定期的に点検する仕組みはあったのか。

点検したのに、見落としたのか。

答えは第二報にある。読むべき場所は4つだ

ひとつ。

原因をどう説明するか。

「設定の不備」と既知の類型を認めるのか。

それとも、アプリケーション側の別の問題だったと説明するのか。

ふたつ。

「いつから」閲覧可能だったか。

もし2021年7月の稼働当初から存在した問題なら、稼働前のアクセス制御テストが機能していなかったことになる。

途中からなら、どの変更によって生じ、なぜ変更時に検出されなかったのかが焦点になる。

みっつ。

ログで何を言えるか。

第三者によるアクセスは実際にあったのか。

何回アクセスされ、どの情報が、何件参照されたのか。

ログは、閲覧可能になった時点まで遡れるのか。

これらをどこまで説明できるかが、この協会が自分のシステムをどこまで見えていたかを知る手がかりになる。

よっつ。

アップロードされた書類は、本当に対象外なのか。

このシステムには、本人確認書類、戸籍、死亡診断書、医師の診断書などをWebから提出する機能がある。

第一報が閲覧可能だった情報として挙げたのは、氏名、住所、電話番号、メールアドレスの4項目だ。

対象外と明記されたのは、生命保険契約の内容と口座情報である。

アップロードされた書類、その画像データ、書類に含まれる情報については、第一報には書かれていない。

第二報で「アップロード書類は対象外」と明確に否定されるかどうか。

ここが濁されたら、話の重さは大きく変わる。

現在、Web申請は停止している。

再開するには、少なくとも原因と、安全性をどのように確認したのかという説明が要る。

再開時の説明が、最初の答え合わせになる。

37,000件という数字は、この事案の大きさではない。

第二報が、この事案の大きさを決める。

A

Aikido Community Japan

公開日: 2026/8/1

最終更新: 2026/8/2

シェア:

ニュースを購読

セキュリティの最新情報をお届けします。

Aikido Community Japan からのお知らせの受信に同意します。詳しくはプライバシーポリシーをご確認ください。