保険会社の契約者ページには、氏名や住所だけでなく、保険証券番号や連絡先が集まります。情報が漏れたときには、不審な連絡への備えと、契約変更・事故連絡などを続けるための代替手段を、同時に確認する必要があります。今回は、三井住友海上とあいおいニッセイ同和損保が公表した事案を、会社ごとの違いに注意して整理します。
両社は2026年11月6日に情報漏えいを確認したと公表しました。対象は契約者向け専用ページの登録者で、両社の全契約者が対象と確定したわけではありません。侵入経路や悪用された脆弱性は、確認した発表では未公表です。本記事の確認日は11月9日朝。件数は11月6日9時時点の会社発表、サービス状況は各案内の記載時点を示します。
被害概要：会社別に件数と漏えい項目を読む
根拠は、三井住友海上の11月6日発表とあいおいニッセイ同和損保の同日発表です。どちらも、ご契約者さま専用ページで不正アクセスを検知し、調査の中で情報漏えいを確認したと説明しています。数字は「件」で公表されており、本記事では重複を除いた人数に置き換えません。
| 会社 | 漏えい件数・対象 | 公表された項目 |
|---|---|---|
| 三井住友海上 | 約3.7万件。契約者専用ページに登録されている顧客 | 保険証券番号、氏名、住所、電話番号、メールアドレスなど。カード情報・口座情報は含まないと説明 |
| あいおいニッセイ同和損保 | 約44.4万件。契約者専用ページに登録されている顧客 | 保険証券番号、氏名、住所、電話番号、メールアドレス、専用ページID。一部にカード・口座に関する情報。該当項目は顧客により異なる |
両社はそれぞれ、発表時点で漏えい情報の不正使用を確認していないとしています。これは「漏えいしていない」「今後も被害が起きない」という意味ではありません。対象者には準備が整い次第、順次個別に案内する方針です。
時系列：検知、停止、漏えいの公表を分ける
| 日時 | 確認できる出来事 | 読み取れる範囲 |
|---|---|---|
| 11月2日夜間 | 両社が契約者専用ページへの不正アクセスを検知 | 検知日であって、攻撃開始日時の特定ではない |
| 直後の翌3日深夜（会社発表の表現） | 関連サービスを停止 | 顧客情報の保護、被害拡大防止、調査のための措置 |
| 11月6日 | 両社が漏えいを確認したと公表 | 件数と項目の基準時点は同日9時。原因・影響範囲の調査は継続 |
| 11月6日12時時点 | あいおいニッセイ同和損保の停止案内の基準時点 | 契約者ページやWeb事故連絡などの停止と代替窓口を案内 |
| 11月7日9時時点 | 三井住友海上の停止案内の基準時点 | 停止サービスと代替手段の一覧を確認できる |
停止案内は、三井住友海上の更新PDFとあいおいニッセイ同和損保のお知らせを確認しました。漏えい公表は11月6日、三井住友海上の停止案内更新は11月7日です。11月9日に新たな漏えい発生を発表した、という扱いにはしていません。
被害内容詳細：カードの下4桁と、口座の「下3桁以外」は違う
あいおいニッセイ同和損保の発表には、部分的な決済情報の説明があります。「マスキングあり」という一言でまとめると、どの部分が漏れたのかが分からなくなるため、分けて読みます。マスキングとは、値の一部を隠す処理です。
| 項目 | 漏えいしたと発表された範囲 | 漏えいしていないと説明された範囲 |
|---|---|---|
| カード関連：3件 | 名義人とカード番号の下4桁 | 番号の全桁、セキュリティコード |
| 口座関連：19件 | 名義人名、金融機関名、口座番号の下3桁を除く部分 | 番号の全桁、暗証番号、インターネットバンキングの認証情報 |
口座の説明は「下3桁だけが漏れた」ではありません。下3桁が隠され、それ以外の部分が対象です。また、約44.4万件すべてに決済関連の全項目が含まれるわけではありません。同社は、要配慮個人情報も含まれないとしています。この範囲を三井住友海上の約3.7万件に当てはめてはいけません。
以下は一般的なリスクの説明です。氏名、証券番号、連絡先などを知った相手から連絡が来ると、本物の担当者のように見える可能性があります。部分的な番号だけで特定の不正取引が可能だとは断定できませんが、相手が自分の情報を知っていることだけで本人性を判断しない、という備えは必要です。本件でそのような二次被害が確認されたという記述ではありません。
原因：不正アクセスは確認、侵入手法はまだ断定できない
両社は外部専門機関によるフォレンジック調査を含む対応を進めています。フォレンジック調査は、保存された記録や機器などから、何が起きたのかを調べる作業です。確認した資料からは、侵入口、認証突破の方法、悪用されたCVE、権限設定の不備などは特定できません。
そのため、「PHPの脆弱性が原因」「パスワードの使い回しが原因」「共有基盤の同じ欠陥が原因」といった説明はしません。また、両社は専用ページをネットワークから切り離した後の外部からの不正アクセスはないと説明していますが、切り離し前に持ち出された情報への対応は別の課題として残ります。
利用者はどう動くか：不審な連絡と、止まっている手続きを分ける
- 1自分の契約先を確認する。両社の発表内容を混ぜず、該当する会社の公式サイトと個別案内を見る。
- 2突然届いたメール・SMS・電話で、パスワードやカード情報を入力・回答しない。両社もなりすましへの注意を呼びかけています。
- 3相手が証券番号や氏名を知っていても、それだけで信用しない。手元の保険証券や、自分で開いた公式サイトの連絡先から確認する。
- 4事故連絡、契約変更、加入・更新など急ぐ手続きは、再開を待つだけにせず、公式に案内された代替手段を確かめる。手続きごとに受付可否や必要書類を確認する。
| 会社・案内の時点 | 停止対象の例 | 案内されている代替経路 |
|---|---|---|
| 三井住友海上：11月7日9時 | 契約者専用ページ、Myエージェント、1DAY保険、ネットde保険各種、法人お客さまWebサービス、インターネット事故受付など | 公式PDFの別紙で手続き別に案内。事故連絡は事故受付センターや取扱代理店、契約内容等は担当窓口へ |
| あいおいニッセイ同和損保：11月6日12時 | 契約者専用ページ、ワンデーサポーター、eとらべる海外旅行保険、Myエージェント、法人お客さまWebサービス、e-G1、Web事故連絡 | 公式お知らせに事故受付窓口と代替手段へのリンク。電話、書面、代理店などで扱える場合がある |
三井住友海上の案内では、たとえばWebで契約内容を閲覧できない場合の紙の保険証券については、取扱代理店等への問い合わせを案内しています。すべてのWeb手続きがそのまま電話で完結するという意味ではありません。各社とも通常と異なる受付のため時間がかかる場合があるとしています。
本件専用の問い合わせ先は、三井住友海上が0120-560-559、あいおいニッセイ同和損保が0120-705-101。11月9日以降は平日9〜17時、年末年始・土日祝日を除くと発表されています。事故受付の窓口とは役割が異なるため、事故の連絡は停止案内にある事故受付先を確認してください。
どうすれば被害を減らせたか：原因の推定ではなく自社の点検へ
原因が確定していないため、特定の対策で本件を必ず防げたとは言えません。以下は、契約者ページや会員サイトを持つ企業が自社を点検するための一般的な提案です。両社にこれらの対策がなかった、という主張ではありません。
| 点検領域 | 自社で確かめること | 期待する効果と限界 |
|---|---|---|
| 閲覧権限 | ログイン後も、各APIで本人・対象契約・操作の権限を確認しているか | 別の利用者の情報へのアクセスを制御する。侵入口の対策は別途必要 |
| データの持ち方 | 契約者画面に必要な項目だけを返し、不要な決済情報を持たせていないか | 侵害時に露出する情報を減らす。既に外部へ出た情報は戻せない |
| マスキングの範囲 | 画面だけでなくAPI応答・ログ・出力ファイルの実データも確認する | 表示上隠れていても別経路に全桁が残る設計を見つける。今回の実装を推定するものではない |
| 監視と初動 | 異常な大量参照を検知できるか、証拠保全と切り離しの担当が決まっているか | 発見と封じ込めを早める。停止が必要かどうかは状況別に判断する |
| 代替業務 | ポータルが停止しても、事故連絡・本人確認・契約手続きの窓口を案内できるか | 情報保護と業務継続を両立しやすくする。受付負荷や個人情報の扱いも設計する |
権限管理の考え方は、OWASPの認可チートシートが示す、最小権限、既定で拒否、リクエストごとの権限確認を参考にできます。認可とは「その人にその情報や操作を許してよいか」の判断です。ログインの成功だけで、全契約の情報を読めるようにはしません。
LLMへの点検指示：機密値を渡さず、読み取り専用から始める
LLMには、個人情報の実データ、保険証券番号、カード・口座番号、認証情報を貼り付けないでください。項目名、加工済みの設計資料、秘密を除いたコードなど、社内で利用を認めた資料だけを渡します。設定変更や本番へのアクセスを任せず、まず確認すべき箇所を整理させます。
あなたは当社の契約者ページの設計レビュー補助です。提供資料は、利用許可済みで個人情報・認証情報を除去した設計とコードです。
読み取り専用で確認し、外部アクセス、攻撃試験、データ取得、設定変更、コマンド実行は行わないでください。
1. 画面とAPIごとに、利用者・対象契約・操作の認可がどこで実施されるかを整理してください。根拠のファイル名・該当箇所を示してください。
2. 氏名、連絡先、証券番号、決済関連情報について、保存・API応答・表示・ログ・出力ファイルの経路を一覧化してください。実際の値は出力しないでください。
3. マスキングが画面だけか、応答データやログにも適用されるかを区別してください。確認できない経路は「不明」としてください。
4. 大量参照の監視、記録の保全、切り離し判断、停止中の代替窓口、再開判断の担当と手順を点検してください。
5. 結果を「確認済み／要確認／提案」に分け、根拠、影響、追加で必要な資料、人が判断すべき事項を表にしてください。
実際に起きた他社事案の原因を当社資料から推測しないでください。資料不足を脆弱性の存在と断定せず、安全性の保証もしないでください。この指示文は棚卸しの補助です。LLMの回答だけでは、実装が安全かどうかは判定できません。人が根拠を確認し、必要な検証は権限を持つ担当者が承認された環境と手順で行います。
次に確認する情報
- 各社の漏えい対象・項目・件数の確定と、個別案内の更新
- 侵入経路、悪用された脆弱性などの調査結果
- 不正使用やなりすまし被害についての追加発表
- 停止サービスごとの再開時期、再開後に利用者が行う操作、代替手段の変更
本記事は2026年11月9日朝に取得した公式資料に基づきます。漏えい範囲は11月6日9時、停止状況は三井住友海上11月7日9時・あいおいニッセイ同和損保11月6日12時の記載です。実際の停止状態をログインして試したものではありません。重要な追報が出た場合は、このページの該当項目を更新します。