ライフネット生命の不正アクセスでKDDI顧客2.2万件：対象確認と提携先APIの認可設計

ライフネット生命保険とKDDIは2026年10月30日、KDDIと連携するライフネット生命のシステムが不正アクセスを受け、KDDIが保有するお客さま情報が最大22,541件漏えいした可能性があると連名で公表しました。侵入されたのは保険会社側のシステムで、漏えいの可能性があるのは通信会社側のデータという、提携先を経由した事案です。本記事は前半で「自分は対象か」「保険契約の情報は漏れたか」「どこに問い合わせるか」に公表文の文言で答えます。後半では、データを持つ側が提携先に開ける連携APIを、会員・項目・提携先の3つの単位で絞る実装をPythonのコードで示します。

まとめ：ライフネット生命の不正アクセスで公表された事実と利用者・連携先事業者が今日やること

確定しているのは次の事実です。ライフネット生命は10月23日に不正アクセスを検知し、KDDIは翌日にライフネット生命側からの接続経路を遮断しました。漏えいした可能性がある情報に、パスワード・クレジットカード情報・口座情報と、ライフネット生命の保険契約情報は含まれません。脆弱性の種類や侵入の手口は公表されていません。

利用者が今日やることは1つです。au・KDDI・ライフネット生命を名乗るメール、SMS、電話のURLを開かず、パスワードや暗証番号を答えないこと。両社は、パスワードや暗証番号を尋ねることはないと明言しています。他社とシステムを連携させている事業者は、提携先からの接続で「どの会員の、どの項目まで」取れる作りになっているかを確かめてください。

11月3日に当社が確認した範囲では、原因や確定件数を示す続報は出ていません。

自分が対象か確かめる手順｜6区分の項目と窓口2つ、auの生命ほけんの停止

対象はKDDIが保有するお客さま情報で、保険契約の情報は含まれない点

ライフネット生命の10月30日の報道発表資料によると、漏えいした可能性があるのは「KDDIのシステム（Kシステム）が保有するお客さま情報の一部」です。ライフネット生命が保有する保険契約に関する情報は含まれていません。保険の契約内容や受取人、給付の記録が漏れたという発表ではない、という点を最初に押さえてください。

対象かどうかを自分で調べる方法は公表されていません。両社は、対象のお客さまに順次個別に案内するとしています。案内が届く前に「対象です」と連絡してきて、個人情報や支払いを求める相手は疑ってかかるのが安全です。

22,541件を6区分に分けた項目の組み合わせと性別・生年月日の扱い

公表文は、漏えいの可能性がある情報を項目の組み合わせごとに6区分で示しています。KDDI側に掲載された同じ発表資料でも内容は同一です。

表の「メール」は、公表文ではメールアドレスと書かれています。発表資料に合計の記載は無く、6区分を足すと22,541件です。一部のお客さまは、これに加えて性別と生年月日も漏えいした可能性があります。住所は郵便番号までで、番地を含む住所は項目に挙がっていません。

au・ライフネット生命を名乗る連絡への対応と、用件で分かれる問い合わせ窓口

メールアドレスか電話番号が含まれる区分は、合計で18,072件です。両社はこれらへの不審なメール、SMS、電話に注意するよう呼びかけています。氏名と電話番号がそろった名簿は、本名で呼びかけるSMSや電話に使われやすく、宛名が正しいことは本物の根拠になりません。KDDIグループを名乗る偽の本人確認の見分け方は、BIGLOBE・@niftyの「本人確認のお願い」の解説でも扱いました。

問い合わせ先は用件で分かれます。不正アクセスそのものについてはKDDIお客さまセンター（au携帯電話から局番なしの157、一般電話から0077-7-111、いずれも無料・9時〜20時・年中無休）です。「auの生命ほけん」など保険の契約についてはライフネット生命コンタクトセンター（0120-205-566、無料・9時〜20時・土日祝と年末年始を除く）に連絡します。「auの生命ほけん」は申込受付を含む一部の機能がメンテナンス中で、再開時期は公表されていません。

公表文から読む侵入の構造｜提携先の連携システムからKDDI側の情報へ届いた経路

検知した10月23日から翌日の経路遮断までと「連携の範囲に限定」の意味

発表資料は、LNシステム（ライフネット生命のシステムのうちKDDIと連携する部分）とKシステム（KDDIのシステム）を分けて書いています。ライフネット生命は10月23日に不正アクセスを検知し、同日KDDIに報告して、被疑箇所を特定し技術的な防御措置を取りました。KDDIは翌日、KシステムへのLNシステムからのアクセス経路を遮断しています。

調査で分かったのは、第三者が「LNシステムの一部機能の脆弱性」を通じて、Kシステムが保有するお客さま情報の一部を取得した可能性です。不正アクセスはLNシステムからKシステムへの連携の範囲に限られ、KDDIの通信設備やライフネット生命の他のシステムへの影響は無いとしています。攻撃者はKDDIのシステムを直接破ったのではなく、提携先に正規に許された接続経路を通って情報に届いたと読めます。

6区分の項目のばらつきから読める範囲と、公表文から読めない範囲

区分を見ると、氏名を含む区分が16,846件、会員識別子だけの区分が807件と、取得された項目が会員ごとに異なります。読めるのは、Kシステムに登録されている項目が会員ごとに違い、その範囲で取得された可能性がある、というところまでです。

反対に、脆弱性がどの機能のどんな不備だったのか、何件の照会で取得されたのか、KDDIの会員全体のうちどう選ばれた2.2万件なのかは書かれていません。当社はこれらを推測で埋めず、続報を待ちます。会員識別子が何を指すのか（auのIDか、連携用の番号か）も公表されていません。

生命保険協会・アフラック・ソニー生命の事案と比べた提携先経由という違い

保険業界では情報漏えいの公表が相次いでいます。生命保険協会の契約照会システムの事案はゲストユーザーへの権限の誤付与、アフラックの事案は通常と同じ形式のアクセスによる大量照会が原因として公表されました。いずれも、情報を持つ組織のシステムそのものが入口です。

本件は入口が提携先の側にある点が違います。データを持つKDDIから見ると、自社のシステムに不備が無くても、接続を許した相手の不備で情報が出ていく構造です。契約者向けの手続きが中心のソニー生命の事案と比べても、守る範囲が自社の外まで延びている点に特徴があります。

提携先に開けた連携APIを会員・項目・提携先の単位で絞るPython実装

OWASP API1とAPI3が示すオブジェクト単位と項目単位の認可の抜け

提携先に開けた連携APIで情報が出すぎる原因は、多くがOWASPのAPI Security Top 10 2023の2項目に当てはまります。API1（Broken Object Level Authorization）は、IDを書き換えると他人のデータを取れてしまう、会員単位の認可の抜けです。API3（Broken Object Property Level Authorization）は、必要以上の項目を返してしまう、項目単位の認可の抜けです。

提携先の認証は、APIキーや証明書で「どの会社からの接続か」を確かめる仕組みです。認証が通っても、その会社が見てよい会員と項目は別に判定しなければなりません。本件の脆弱性がこの2つに当たるかは公表されていませんが、データを持つ側が自分で直せる範囲はこの2つと、提携先ごとの遮断です。

同意の記録が無い会員を404で返し許可外の項目を拒否するゲートウェイ

保険の申込を受け付ける提携先と、通販の提携先の2社に会員情報を返すAPIを想定した例です。提携先ごとに返してよい項目と遮断フラグを台帳に持ち、会員がその提携先の申込で同意した記録があるときだけ情報を返します。同意の無い会員への応答は、会員が存在するかどうかも明かさないように404を返す設計です。標準ライブラリだけで動き、partner_gateway.pyとして保存します。

from datetime import datetime, timezone

# 提携先ごとに「返してよい項目」と「遮断フラグ」を持つ台帳
PARTNERS = {
    "partner-ins": {"enabled": True, "fields": {"member_id", "name", "postal_code"}},
    "partner-shop": {"enabled": True, "fields": {"member_id", "email"}},
}

MEMBERS = {
    "K0001": {"member_id": "K0001", "name": "山田 太郎", "postal_code": "100-0001",
              "phone": "090-0000-0001", "email": "mail-K0001", "birth": "1980-01-01"},
    "K0002": {"member_id": "K0002", "name": "佐藤 花子", "postal_code": "150-0002",
              "phone": "090-0000-0002", "email": "mail-K0002", "birth": "1991-02-02"},
    "K0003": {"member_id": "K0003", "name": "鈴木 一郎", "postal_code": "530-0003",
              "phone": None, "email": "mail-K0003", "birth": None},
}

# 会員が提携先の申込で同意した記録。これが無い会員は提携先から見えない
CONSENTS = {("partner-ins", "K0001"), ("partner-shop", "K0002")}

AUDIT = []


def fetch_member(partner_id, member_id, fields):
    partner = PARTNERS.get(partner_id)
    if partner is None or not partner["enabled"]:
        return log(partner_id, member_id, 403, "partner_disabled")
    # オブジェクト単位の認可: 同意の無い会員は存在も明かさず404
    if (partner_id, member_id) not in CONSENTS or member_id not in MEMBERS:
        return log(partner_id, member_id, 404, "not_found")
    # 項目単位の認可: 許可外の項目を要求したら丸ごと拒否する
    extra = set(fields) - partner["fields"]
    if extra:
        return log(partner_id, member_id, 403, "field_not_allowed:" + ",".join(sorted(extra)))
    row = MEMBERS[member_id]
    log(partner_id, member_id, 200, "ok")
    return 200, {f: row[f] for f in fields}


def log(partner_id, member_id, status, reason):
    AUDIT.append((datetime.now(timezone.utc).strftime("%H:%M:%S"), partner_id, member_id, status, reason))
    return status, reason


print("1 正規の照会      :", fetch_member("partner-ins", "K0001", ["member_id", "name", "postal_code"]))
print("2 許可外の項目    :", fetch_member("partner-ins", "K0001", ["name", "phone", "email"]))
print("3 同意の無い会員  :", fetch_member("partner-ins", "K0002", ["member_id", "name"]))
print("4 IDの総当たり    :", [fetch_member("partner-ins", f"K{i:04d}", ["member_id"])[0] for i in range(1, 6)])
PARTNERS["partner-ins"]["enabled"] = False  # 提携先1社だけを止める
print("5 遮断後の照会    :", fetch_member("partner-ins", "K0001", ["member_id"]))
print("6 他の提携先      :", fetch_member("partner-shop", "K0002", ["member_id", "email"]))
denied = sum(1 for a in AUDIT if a[1] == "partner-ins" and a[3] != 200)
print("partner-ins の拒否件数:", denied, "/", sum(1 for a in AUDIT if a[1] == "partner-ins"))

2026年11月3日に、Python 3.14.7で実行した結果です。会員と提携先のデータは架空で、KDDIやライフネット生命の実際の仕組みではありません。

$ python partner_gateway.py
1 正規の照会      : (200, {'member_id': 'K0001', 'name': '山田 太郎', 'postal_code': '100-0001'})
2 許可外の項目    : (403, 'field_not_allowed:email,phone')
3 同意の無い会員  : (404, 'not_found')
4 IDの総当たり    : [200, 404, 404, 404, 404]
5 遮断後の照会    : (403, 'partner_disabled')
6 他の提携先      : (200, {'member_id': 'K0002', 'email': 'mail-K0002'})
partner-ins の拒否件数: 7 / 9

実行結果の読み方と提携先1社だけを止める遮断フラグを動かす手順

1は正規の照会で、保険の提携先に許した氏名と郵便番号だけが返ります。2は電話番号とメールアドレスを要求したため、丸ごと拒否されました。許可外の項目だけ削って返す作りにすると、提携先の不具合や乗っ取りに気付けないため、拒否して記録に残す方を選んでいます。3と4は、同意の無い会員を照会した場合で、K0002からK0005まで連番で試しても、同意のあるK0001以外は404です。

5は遮断フラグを倒した後の照会で、保険の提携先からの接続はすべて403になります。6のとおり、通販の提携先は止まりません。KDDIは検知の翌日に経路を遮断しましたが、提携先ごとに認証情報と遮断フラグを分けておけば、この操作は分単位で済み、他の提携先の業務も止めずに済みます。運用では次の順で動かします。

1. 提携先から不正アクセスの報告を受けたら、その提携先の遮断フラグを倒し、APIキーや証明書も失効させる
2. 監査ログから、その提携先の照会を時刻順に抜き出し、拒否が急に増えた時刻と取得された会員を数える
3. 取得された会員と項目の組み合わせを集計し、公表と本人への通知に使う区分表を作る
4. 提携先が原因を直したと確認できてから、許可項目を見直したうえでフラグを戻す

拒否の急増は、総当たりや乗っ取りの兆候です。この例では9件中7件が拒否で、本番なら警報を出す水準です。提携先ごとの1時間あたりの照会数の上限はアフラックの解説で示した照会量制御と組み合わせます。

個人情報保護委員会への報告と、提携先と連携する事業者が今月点検する順番

不正アクセスによる漏えいは件数を問わず報告対象、速報3〜5日と確報60日

不正の目的で行われたおそれがある漏えいは、おそれの段階であっても件数にかかわらず、個人情報保護委員会への報告と本人への通知の対象です。速報はおおむね3〜5日以内、不正アクセスによるものの確報は60日以内に出します。様式と手順は個人情報保護委員会の「漏えい等の対応とお役立ち資料」、判断の流れは個人情報保護委員会への報告義務にまとめました。

両社は、関係法令に基づき関係する当局への報告などを進めているとしています。提携先経由の漏えいでは、データを持つ側と侵入された側のどちらが本人に通知し、どちらが窓口を持つかを事前に決めておかないと、初報が遅れます。本件は連名の発表で、窓口を用件ごとに分けて示しました。

提携先APIを今月点検すべき事業者と、次の改修に回してよい事業者

提携先に会員情報を返すAPIを持ち、複数の提携先で同じAPIキーや同じ接続経路を共有している事業者は、今月中に点検してください。見る順番は、提携先ごとに返す項目が分かれているか、同意や申込の記録が無い会員を照会できないか、提携先1社だけを止められるか、の3点です。公開APIに共通するレート制限とトークン失効はAPI不正アクセス対策の実装手順で整理しました。

提携先側のシステムの不備は、データを持つ側からは見えません。接続口の認可が想定どおり働くかを、外から攻撃者と同じ条件で試すのが早道です。脆弱性診断・セキュリティ診断で、提携先向けAPIの会員単位・項目単位の認可を含めて点検できます。

一方、提携先との連携がファイルの受け渡しだけで、提携先から自社の会員情報を照会する経路が無い事業者は、この点検を次の改修に回して構いません。その場合も、受け渡すファイルの項目が提携先の業務に必要な範囲に絞られているかだけは確かめておきます。取引先を入口にした攻撃の全体像はサプライチェーン攻撃とはで解説しています。

よくある質問

ライフネット生命の不正アクセスについて、auの利用者と、他社とシステムを連携させている事業者から出やすい質問をまとめました。

auの生命ほけんに加入していなくても対象になりますか？

なる可能性があります。漏えいの可能性があるのは、KDDIのシステムが保有するお客さま情報の一部で、公表文は保険に加入しているかどうかで対象を分けていません。どのような会員が対象の2万2,541件に含まれるかも書かれていません。対象の方には両社から順次個別に案内が届くので、それまではau・KDDI・ライフネット生命を名乗る不審な連絡に注意してください。

ライフネット生命の保険契約の内容は漏えいしましたか？

公表文は、漏えいした可能性のある情報に、ライフネット生命が保有する保険契約に関する情報は含まれていないとしています。漏えいの可能性があるのは、氏名・郵便番号・電話番号・メールアドレス・会員識別子の組み合わせと、一部の方の性別と生年月日です。契約内容の照会や変更は、ライフネット生命コンタクトセンター（0120-205-566）で受け付けています。

auのパスワードを変更したほうがよいですか？

公表文では、パスワード、クレジットカード情報、口座情報、運転免許証などの本人確認情報は含まれていません。パスワードの変更は必須ではありません。ただし、メールアドレスとほかのサイトで漏れたパスワードを組み合わせてログインを試す攻撃があるため、同じパスワードを複数のサービスで使っている場合は、この機会に分けておくと安心です。

auの生命ほけんの申し込みはいつ再開しますか？

11月3日時点で再開時期は公表されていません。ライフネット生命は、LNシステムを利用する「auの生命ほけん」について、申込受付を含む一部の機能をメンテナンスしています。再開を知らせるメールやSMSのリンクから手続きせず、ライフネット生命とKDDIの公式サイトで確かめてください。

ライフネット生命の不正アクセスの原因は分かっていますか？

公表されているのは、第三者がLNシステムの一部機能の脆弱性を通じて、KDDIのシステムが保有する情報の一部を取得した可能性がある、というところまでです。どの機能のどんな脆弱性だったか、侵入の手口は書かれていません。両社は影響範囲の調査と再発防止策の策定を続けており、新たな事実が判明した場合は改めて報告するとしています。

関連記事

• アフラックの情報漏洩440万人｜大量照会を止められなかった原因と照会量制御の実装：保険会社の事案と照会数の上限の実装
• 生命保険協会の情報漏洩｜原因はゲストユーザー権限の誤付与、2.7万件の対象と現在の状況：権限設定の不備による保険業界の漏えい
• API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策：公開APIの点検項目
• KDDI系メール漏えい：BIGLOBE・@niftyの「システムアップグレードに伴う本人確認のお願い」と電話は本物か：KDDIグループを名乗る連絡の見分け方
• 個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務：漏えい時の報告の判断