KDDIの顧客情報2.2万件が漏えいか ライフネット生命との連携経由

生命保険会社が不正アクセスを受けたのに、漏えいの可能性があるのは保険の契約情報ではなく、通信会社の顧客情報でした。

KDDIとライフネット生命保険は2026年10月30日、連名で発表しました。ライフネット生命の「KDDIと連携するシステム」に入られ、KDDIのシステムが持つ顧客情報の一部が外に出たおそれがあります。発表の表を足すと2万2,541件。合計は発表になく、6行を編集部で足した数です。

自社には関係のない話に見えるかもしれません。ただ、APIやファイル連携で社外のシステムに顧客データを返している会社なら、同じ形の事故が起こりえます。

破られたのは、KDDIにつなぐ側

発表に出てくるシステムは2つです。ライフネット生命でKDDIと連携する部分が「LNシステム」、顧客情報を持つKDDI側が「Kシステム」。発表によると、悪意のある第三者がLNシステムの「一部機能の脆弱性」を突き、Kシステムの情報を取得した可能性があります。

よくある委託先の事故とは、向きが違います。「auの生命ほけん」では、KDDIが保険募集代理店で、ライフネット生命が引受保険会社。自社のデータを預けた先が破られたのではなく、発表の経路の書き方からは、自社のシステムへ問い合わせてくる相手が破られた形です。

ここがいちばん気がかりな点だと編集部はみています。委託先の管理台帳は、ふつう自社のデータや業務を任せた相手を並べます。自社の側へつないでくる提携先は、預けた相手ではないので、台帳から抜けやすいでしょう。それでも、相手が破られたときに出ていくのは自社の顧客情報です。

時間の流れも見ておきます。10月23日金曜、ライフネット生命が不正アクセスを検知し、同じ日にKDDIへ報告して、被疑箇所の特定と防御措置まで進めました。KDDIがLNシステムからのアクセス経路を遮断したのは、翌24日土曜です。

「翌日」をどう読むか。報告を受けた時刻は発表にないので、早い遅いは言い切れません。夜に受けたのなら、土曜のうちに止めたのは手早い部類でしょう。

自社が同じ立場なら、どうでしょうか。金曜の夜に提携先から電話が来て、土曜に経路を切れる担当者がいるかどうかです。

経路を切れば、提携のサービスにも響くはずです。発表によると、ライフネット生命はLNシステムを使う「auの生命ほけん」で、申し込みの受け付けを含む一部の機能をメンテナンスしています。いつからか、遮断が理由かは書かれていません。

売り上げに関わる経路を休日に止める判断をだれが下すのかは、技術の手順だけでは決まりません。

カードや口座は含まれず、件数は2万件を超える

発表の表は、項目の組み合わせごとの件数です。表の項目に加え、一部の顧客は性別と生年月日も漏えいした可能性があります。件数は発表にありません。

表を項目ごとに数え直すと、読み方が変わります。

偽の連絡が来るとすれば、メールが中心になりそうです。電話番号があるのは2割ほどで、住所は郵便番号までしか項目にありません。全行に共通するのは会員識別子だけで、これしかない行も807件あります。

2社の説明では、パスワードやクレジットカード情報、口座情報、運転免許証などの本人確認情報は含まれません。ライフネット生命が持つ保険契約の情報も対象外です。

発表によると、不正アクセスは「LNシステムからKシステムへの連携の範囲に限定」されています。これは影響が及んだシステムの説明で、連携で渡す項目には触れていません。

氏名や連絡先、性別、生年月日は、保険の申し込みで使う項目と重なるはずです。出た項目が連携で渡す項目に沿っているのなら、被害の大きさを決めたのは連携の範囲だったのかもしれません。2社は全容の把握に向けて調査を続けており、項目も件数もまだ変わりえます。

ただ、件数は別の問題です。

保険の申し込みのための連携なら、1回に要るのは申し込む本人の1人分のはずです。その経路から2万件を超える情報が取られたのだとすると、1回や1日あたりの上限と、本人の操作に結び付いた呼び出しかどうかの確認が、どこまで効いていたのかが次の論点になります。連携の目的も手口も不明なので、ここは編集部の推測です。

ほかにも、不正アクセスが始まった時期、脆弱性の種類、会員識別子が何を指すかは分かっていません。対象が「auの生命ほけん」の申込者に限られるのか、法人契約の回線の情報を含むのかも、発表からは読み取れません。

10月の7件と比べて見えること

10月に整理した提供元・委託先の事故7件のうち、形がいちばん近いのはConnectWise Cloud Backupです。つないでいる側を押さえた攻撃者が、つながれている側のデータに手を伸ばす。その点は同じです。ただ、型の名前の「入口は正規の権限」は今回と違います。

違いは2つあります。

1つ目は入口です。ConnectWiseではアプリの認証情報が盗まれましたが、今回の発表にあるのは「脆弱性」までで、鍵を盗まれたという説明はありません。

2つ目は権限の広さ。ConnectWiseのアプリには、導入先のメールやOneDrive、SharePointなどを広く読み書きできる権限がありました。今回の発表に出てくるのは連絡先を中心とした項目の取得で、書き換えには触れていません。ベネフィット・ワンの委託先の件でも、漏れたおそれのある鍵で動かせたのは会費の決済だけでした。連携の権限をどこまで狭くしておくかで、相手が破られた日の被害の大きさが変わります。

公表の仕方は、よくできていると感じました。7件は提供元と利用者の関係なので今回の提携と同じではありませんが、公表が分かれた例では、利用者の公表が提供元より1日から約3週間あとでした。今回は2社が同じ日に連名で出し、問い合わせ先も分けました。顧客がたらい回しにされにくい分け方で、提携先と前もって決めておく文面の手本になります。

影響するのは、社員の利用者と提携先につなぐ会社

• KDDIのサービスを使っている社員。対象者には順次、個別に案内が届きます。会社のメールアドレスを登録している人なら、案内や不審な連絡が会社に届くこともありえます。
• APIやファイル連携で、提携先や代理店のシステムに顧客データを返している会社。今回の当事者ではありませんが、同じ形を持っています。
• 「auの生命ほけん」を申し込もうとしている人。今は一部の機能が止まっています。

KDDIの通信とサービスの設備、ライフネット生命の他のシステムには、影響がないと発表されています。au回線が止まる話ではありません。顧客データを社外に返す経路がない会社なら、社内への案内だけで足ります。

社内に伝えるなら、発表のこの1文が使えます。「KDDIおよびライフネット生命がパスワードや暗証番号などをお尋ねすることはありません」。

問い合わせ先は、本件がKDDIお客さまセンターで、au携帯から局番なしの157、一般電話から0077-7-111です。受付は9時から20時で、年中無休。保険の契約についてはライフネット生命コンタクトセンターの0120-205-566で、受付は9時から20時、土日祝と年末年始を除きます。

提携先の経路を棚卸しする手順

社内への案内は今日のうちに。棚卸しは来週始めて、提携先との次の契約更新までに終えられると安心です。

1. 社外のシステムから自社の顧客データに届く経路を、一覧にします。APIとファイル連携、データベースの参照のほか、代理店やグループ会社の分も入れ、委託先の台帳と突き合わせます。
2. 経路ごとに、返す項目を書き出します。相手の業務に要らない項目があれば、事業部門と外す相談をします。
3. 件数の上限を確認します。1回と1日あたりの上限があるか、利用者本人の操作に結び付いた呼び出しだけを受けているかを見て、普段の何倍で警報を出すかも決めます。
4. 止める手順を書きます。その提携先の経路だけを切る方法、夜間と休日の担当者、止まるサービスと止める判断者を1枚にまとめます。
5. 提携先と、連絡と公表の決まりを確認します。検知から何時間で知らせるか、連名で公表するか、問い合わせ窓口をどう分けるかです。

3つ目の警報には理由があります。発表の流れでは、最初に検知したのはライフネット生命で、KDDIは報告を受けて動きました。つながれる側から見ると、連携の呼び出しは普段の通信に見えるでしょう。相手の連絡を待たずに気づける数字を、自社の側に持っておきたいところです。

委託先の一覧を開いて、代理店や提携先の名前があるかを見てください。なければ、そこが来週の仕事になります。