--- title: "住友生命不正アクセス：Vitality約8万名の対象と停止中の手続き、カード番号の桁数点検" url: "https://www.issoh.co.jp/tech/details/19549/" published: 2026-11-10 updated: 2026-11-10 categories: ["セキュリティ"] publisher: "株式会社一創" --- # 住友生命不正アクセス：Vitality約8万名の対象と停止中の手続き、カード番号の桁数点検 住友生命は2026年11月9日、システム関連業務の委託先であるNTTデータのシステムに第三者が不正にアクセスし、Vitalityの単独プランを利用した約8万名の情報が外部に漏えいしたと公表しました。前半では、自分は対象か、解約やカード変更はできるのか、届いた連絡は本物かという疑問に公式の文言で答えます。後半は開発者と委託元の担当者に向けて、カード番号のマスク桁数を調べるPythonと、案内文の区分を作るSQLを実行結果つきで示します。 ## まとめ：住友生命の不正アクセスで判明した約8万名の範囲と利用者がまず確かめること [住友生命の発表](https://www.sumitomolife.co.jp/news/detail/newsrelease%5F261109.html)と[NTTデータの発表](https://www.nttdata.com/global/ja/news/release/2026/110900/)で確定している内容は次のとおりです。 | 項目 | 11月9日時点の内容 | | ------- | -------------------- | | 対象 | 単独プランの現在と過去の利用者 約8万名 | | 対象のプラン | 体験版・企業型、Vitalityスマート | | 漏えいした情報 | 氏名、住所など6項目のいずれか | | カード番号 | 約1,000名（一部マスキング済み） | | 対象外 | 保険契約、歩数等のデータ | | 二次被害 | 不正利用やネット上の拡散は未確認 | | 原因 | 調査中 | Vitality保険の契約者としてだけ利用している人は、発表の対象に入っていません。単独プランを使ったことがある人は、個別の案内を待ちながら、住友生命を名乗るメール、SMS、電話に注意してください。同社がメールや電話でパスワードや暗証番号を尋ねることはありません。 システムの担当者が持ち帰る点は2つあります。カード番号は「マスク済み」と書けるかではなく何桁見えるかで評価すること。そして、人ごとに漏れた項目が違う事案では、案内文を分ける集計を先に作っておくことです。 ## Vitality利用者が確かめる対象範囲、止まっている手続きと偽連絡の見分け方 ### 対象は単独プランの現在と過去の利用者、Vitality保険の契約情報は対象外 対象は、Vitality健康プログラムを単独で利用できる「住友生命Vitality体験版・企業型」と「Vitalityスマート（福利厚生タイプ含む）」の利用者です。今は使っていなくても、過去に利用したことがあれば範囲に入ります。勤務先の福利厚生タイプで利用した人も含まれます。 保険契約と、保険契約に付随するVitalityの情報は漏えいしていないと、両社とも説明しています。歩数などプログラムの利用データも含まれていません。 自分が対象かどうかを照会するページは、発表文に案内がありません。住友生命は対象者の特定を進めており、確認結果を踏まえて対応するとしています。11月10日に確認した時点で、個別案内の方法と時期は示されていませんでした。 ### 6項目の「いずれか」という表現と、約1,000名のカード番号の読み方 漏えいした情報は、氏名、住所、電話番号、生年月日、メールアドレス、クレジットカード番号（一部マスキング済み）の「いずれか」です。約8万名の全員が6項目すべてを取られたという意味ではありません。項目ごとの人数は、カード番号の約1,000名を除いて公表されていないのが現状です。 カード番号が含まれる人は全体の1%強にとどまります。「一部マスキング済み」は、番号の桁の一部が伏せられていたとも、一部の人の番号だけ伏せられていたとも読める書き方です。発表文からはどちらか判断できません。セキュリティコードや有効期限への言及もないため、含まれたかどうかは不明として扱います。 カードの再発行や不正利用の監視について、両社の発表に案内はありません。利用明細に身に覚えのない請求がないかを確かめ、不安があればカード裏面の番号からカード会社に相談するのが確実です。 ### 11月3日から止まる申込・解約・カード変更と、影響のないアプリと保険手続き システムの安全を確認できるまで、次の取扱いが11月3日から止まっています。 - 体験版・企業型、Vitalityスマート（福利厚生タイプ含む）の新規申込受付 - Vitalityスマートの利用者自身による解約、クレジットカード情報の変更など - 福利厚生タイプの団体管理システム（団体ポータル）の利用 Vitalityアプリの利用と、Vitality保険の新規申込・諸手続きには影響がありません。今すぐ解約したい人やカードを変えたい人は、画面での手続きを待たず、後述の窓口に相談できます。停止している取扱いの相談を受けると発表文に明記されているためです。再開は住友生命のホームページで知らせるとされています。 ### 住友生命を装う連絡の判断基準と、専用窓口0120-550-997の受付時間 住友生命は、同社を装うメール、SMS、電話への注意を呼びかけました。NTTデータの発表は、不審な郵便物も挙げています。氏名や住所、生年月日が正しく書かれていても、本物の証拠にはなりません。それらは漏えいした項目そのものだからです。 判断の基準は明快で、パスワードや暗証番号を尋ねてきたら偽物と考えます。リンクを開かず、電話なら一度切り、下の窓口へ自分でかけ直してください。カード情報の入力へ誘導するページも同じ扱いです。偽サイトへ誘導する流れは[フィッシング詐欺の成立の仕組み](https://www.issoh.co.jp/tech/details/13548/)で解説しています。 専用窓口の電話番号は0120-550-997、受付は平日9時から17時です。11月9日から受け付けています。 ## 11月2日から9日までの経緯と、NTTデータの別事案と切り分ける未公表の項目 ### 委託先の確認から住友生命の公表まで7日間、両社の発表を並べた時系列 2社の発表を日付でそろえると次のようになります。 | 日付 | 出来事 | 記載元 | | ----- | -------------------- | ------ | | 11月2日 | NTTデータが不正アクセスを確認 | 両社 | | 11月2日 | 同日、住友生命へ報告 | 住友生命 | | その後 | アクセスログ等の調査で漏えいを確認 | 住友生命 | | 11月3日 | 外部からのアクセスを遮断しサービスを停止 | NTTデータ | | 11月3日 | 新規申込など3つの取扱いを停止 | 住友生命 | | 11月9日 | 両社が公表、専用窓口を開設 | 両社 | NTTデータの説明では、対象システムは同社が住友生命から構築と運用を受託している「申込みに係るサービス」です。確認から委託元への報告までが同日だったことは、住友生命の発表から読み取れます。漏えいを確認した具体的な日付は書かれていません。 ### 10月のSecuritize Japan事案と今回で異なるNTTデータの立場 NTTデータの名前が出る漏えいが短期間に続いたため、混同しやすい状況です。[Securitize Japanの不正アクセスとデジタル社債の購入者への影響](https://www.issoh.co.jp/tech/details/19229/)は、NTTデータが業務を委託していた側の事案でした。今回は反対に、NTTデータが受託者として構築・運用するシステムが侵害されています。 対象者も項目も別で、発表文にも両者を関連づける記載はありません。件数を足し合わせることも、原因を同じと見ることもできません。 ### 侵入経路やマスクの方式など未公表の6項目と、続報で確かめる順番 11月10日に確認した発表文の範囲で、次の点は明らかになっていません。利用者の判断に直結する順に並べました。 1. 個別案内の方法と時期 2. カード番号のマスク方式と、残っていた桁数 3. 解約やカード変更など、止まっている取扱いの再開時期 4. 項目ごとの人数 5. 不正アクセスが始まった時期 6. 原因と侵入経路 「不正利用は確認されていない」は、調査中の現時点の表現です。影響がないと断定したものではありません。NTTデータは新たに知らせるべき事項が判明すれば速やかに公表するとしているので、続報でこの6点を見てください。 ## 約1,000名のカード番号から点検する、マスクの桁数と残存箇所を調べるPython ### PCI DSS要件3.4.1の上限はBINと下4桁、「一部マスキング」だけでは測れない カード番号の「マスク」は、業界の基準に沿った処理が必要です。[PCI SSCのFAQ 1492](https://www.pcisecuritystandards.org/faqs/1492/)によれば、要件3.4.1は画面や帳票に表示する番号をBIN（先頭の発行者識別番号）と下4桁までに制限し、それ以上を見せるには文書化した業務上の理由と管理者の承認が要ります。保存時の要件3.5.1は別物で、切り詰め、全桁の暗号化、インデックストークン、鍵付きハッシュのどれかで読めない状態にすることを求めています。 つまり「マスク済み」という言葉は安全の説明になりません。先頭6桁と下4桁だけ残っているのか、下4桁だけなのか、中央を2桁伏せただけなのかで、悪用のしやすさは大きく変わります。今回の桁数は未公表なので評価はできません。自社のデータなら数えられます。規格の全体像は[PCI DSSの12要件と準拠レベルの整理](https://www.issoh.co.jp/column/details/13185/)が入口になります。 ### 番号を表示せずに全桁とマスク超過を数えるPythonスクリプトと実行結果 次のスクリプトは、CSVやログの中にある13〜19桁の番号らしき文字列を、全桁、基準内のマスク、桁数超過、途中に数字が見えるものに分類します。全桁の場合、注文番号などの除外に使うのはLuhn検査です。標準ライブラリだけで動き、ファイルを省くと内蔵の検証データで試せます。 ``` # エクスポートやログに残るカード番号を、番号そのものは表示せずに種別だけ数える # Python 3.9以上・標準ライブラリのみ。ファイルを省くと内蔵の検証データで動く import argparse import re import sys from collections import Counter from pathlib import Path MASK = "*xX#•" TOKEN = re.compile(rf"(? 4 else n * 2 total += n return total % 10 == 0 def classify(token, max_lead, max_tail): chars = re.sub(r"[ -]", "", token) if chars.isdigit(): return "全桁" if luhn(chars) else None if not any(c.isdigit() for c in chars): return None lead = len(chars) - len(chars.lstrip("0123456789")) tail = len(chars) - len(chars.rstrip("0123456789")) if any(c.isdigit() for c in chars[lead:len(chars) - tail]): return "途中に数字" return "基準内" if lead <= max_lead and tail <= max_tail else "桁数超過" def read_lines(paths): if not paths: yield from (("(内蔵データ)", n, line) for n, line in enumerate(SAMPLE, 1)) for path in paths: with open(Path(path), encoding="utf-8", errors="replace") as f: yield from ((path, n, line) for n, line in enumerate(f, 1)) def main(): parser = argparse.ArgumentParser() parser.add_argument("files", nargs="*", help="検査するテキストファイル") parser.add_argument("--max-lead", type=int, default=6, help="先頭に見せてよい桁数") parser.add_argument("--max-tail", type=int, default=4, help="末尾に見せてよい桁数") args = parser.parse_args() counts = Counter() for path, number, line in read_lines(args.files): for match in TOKEN.finditer(line): kind = classify(match.group(), args.max_lead, args.max_tail) if kind: counts[kind] += 1 if kind in NG: # 値は出さない。結果の置き場が新しい漏えい元になるため print(f"{path}:{number}: {kind}") print("集計:", dict(sorted(counts.items()))) sys.exit(1 if NG & counts.keys() else 0) if __name__ == "__main__": main() ``` Python 3.14.10（Windows）で2026年11月10日に実行した結果です。番号はすべて内蔵の検証データで、住友生命やNTTデータのシステムを調べたものではありません。 ``` (内蔵データ):1: 全桁 (内蔵データ):3: 桁数超過 集計: {'全桁': 1, '基準内': 2, '桁数超過': 1} ``` 終了コードは1です。日付と電話番号と基準内のマスクだけを並べたファイルでは、誤検出がなく0で終わりました。BINが8桁のカードを扱うなら `--max-lead 8` を指定します。保存時の切り詰めで許される形式は国際ブランドごとに異なるため、この既定値を保存形式の合格基準にはしないでください。 検出できないものも書いておきます。英字に挟まれた番号、Base64などの符号化の中身、画像やPDFは対象外です。0件でも「番号が無い」証明にはなりません。例外ログに番号が入る経路と入力値を除く実装は[エディオンの事案で扱ったログ出力の許可リスト](https://www.issoh.co.jp/tech/details/19532/)にまとめています。 ### 非保持化を定めたガイドライン6.1版と、番号を持ち続ける場合の判断条件 桁数を数える前に、番号を持たなくて済まないかを問うべきです。[クレジットカード・セキュリティガイドライン6.1版](https://www.j-credit.or.jp/security/pdf/Creditcardsecurityguidelines%5F6.1%5Fpublished.pdf)（2026年3月）は、EC加盟店の非保持化を、自社の機器とネットワークでカード情報の「保存」「処理」「通過」のいずれも行わないことと定義しました。カード会社から情報の還元を受けて保存するだけでも保持になり、PCI DSSへの準拠が必要です。 同じガイドラインは、非保持化した加盟店でもサイトの脆弱性からカード情報が盗まれている現状を指摘しています。非保持化は番号を手元に残さない対策であって、入力画面の改ざんまでは防げません。 判断はこうします。継続課金の照合や問い合わせ対応に必要なのが下4桁だけなら、それ以外の桁は持ちません。全桁を持つ理由を業務側が説明できないなら、決済代行のトークンへ移す案件です。 今回の対象には過去の利用者も含まれました。保持の理由は公表されていないので本件の評価はしませんが、[個人情報保護法22条](https://laws.e-gov.go.jp/law/415AC0000000057)は、利用する必要がなくなった個人データを遅滞なく消去するよう努めることを定めています。退会後の削除バッチは[保持期限で匿名化するPythonの例](https://www.issoh.co.jp/tech/details/19530/)を参考にしてください。 ## 漏えい項目が人ごとに違う事案で、通知文を分ける区分をSQLで集計する手順 ### 「いずれか」の事案で一律の案内文が使えない理由と、連絡手段ごとの注意 今回のように漏えい項目が人ごとに異なると、全員に同じ文面を送る方法は誤った案内になります。カード番号が含まれない人に明細の確認を促せば問い合わせが増えますし、住所が含まれる人に偽メールの注意だけを書けば、偽の郵便物への備えが抜けます。 連絡手段の選び方にも落とし穴があります。メールアドレスが漏えいした人にメールで案内すると、本物の案内と偽メールの見分けがつきにくくなるためです。通知には、Webサイトの公表文と照合できる案内番号を入れると、受け取った人が自分で確かめられます。 ### 人と項目の対応表から案内文の4区分を作るSQLと検証データの実行結果 ログ調査の結果を、1人1項目1行の表 `leaked_items` に入れておくと、案内文の区分は次のSQLで出せます。優先順位はカード番号、郵送・電話の連絡先、メールの順です。同じ人に同じ項目の行が重複していても、1人として数えます。 ``` WITH person_items AS ( SELECT person_id, MAX(CASE WHEN item = 'card_masked' THEN 1 ELSE 0 END) AS card, MAX(CASE WHEN item IN ('address', 'phone') THEN 1 ELSE 0 END) AS contact, MAX(CASE WHEN item = 'email' THEN 1 ELSE 0 END) AS email FROM leaked_items GROUP BY person_id ) SELECT CASE WHEN card = 1 THEN 'A_card' WHEN contact = 1 THEN 'B_post_phone' WHEN email = 1 THEN 'C_email' ELSE 'D_name_only' END AS notice_group, COUNT(*) AS people FROM person_items GROUP BY notice_group ORDER BY notice_group; ``` 6人分・14行の検証データをSQLite 3.50.4で実行した結果を、列をそろえて示します。 ``` A_card 1 B_post_phone 2 C_email 2 D_name_only 1 ``` 区分ごとの案内は次のように分けます。 | 区分 | 案内に書くこと | | -------------- | --------------- | | A\_card | 明細の確認、カード会社の相談先 | | B\_post\_phone | 偽の電話・郵便物への注意 | | C\_email | 偽メール・SMSへの注意 | | D\_name\_only | 漏えい項目の通知と相談窓口 | 注意したいのは、この表が調査結果の写しだという点です。アクセスログが残っていない期間の人は表に現れません。特定できない期間があるなら、「対象外」と案内せず「特定できない」と分けて扱います。 ## 機能単位の停止設計と委託先との報告線、第三者の診断を入れる判断基準 ### 停止した3つの取扱いから学ぶ、機能ごとに止めるための設計項目と代替窓口 今回は、申込み、解約とカード変更、団体ポータルが止まり、アプリと保険の手続きは続いています。システムの内部構成は公表されていないので、分離の仕組みまでは分かりません。外から確かめられるのは、止める範囲を機能の単位で定義できたという結果だけです。 同じことを自社で可能にするには、次の4点を事前に決めます。 - 外部公開の入口を機能ごとにURLかサービスで分け、個別に遮断できるようにする - 管理画面、団体向けポータルなど、利用者の区分ごとの入口を棚卸しする - 解約とカード変更を止めた間の課金の扱いと、代わりに受け付ける窓口を決めておく - 再開の条件（修正の確認、診断の完了など）と告知する場所を書いておく 3点目は見落とされがちです。解約の画面だけ止めると、やめたい人が課金の継続を止められません。今回の発表が、停止中の取扱いを窓口で相談できると明記した点は、そのまま手順書の項目になります。 ### 同日報告を契約に書く委託先の監督と、委託元・委託先の報告義務の分担 [個人情報保護委員会の通則編ガイドライン](https://www.ppc.go.jp/personalinfo/legal/guidelines%5Ftsusoku/)は、委託先の監督（法25条）として、選定時の確認、取扱状況を把握できる契約、定期的な監査などを挙げています。委託元が実務で足すなら、不正アクセスを確認してから委託元へ報告するまでの時間と、提供を受けるログの項目と保存期間の2つです。契約書に数字で書いておきます。 報告義務は委託元と委託先の双方に原則としてかかり、委託先は委託元へ通知すれば報告を免れます。[漏えい等の報告](https://www.ppc.go.jp/personalinfo/legal/leakAction/)では、不正の目的によるおそれがある事案と1,000人を超える事案が対象の類型に入り、速報は発覚から概ね3〜5日以内、確報は30日以内（不正の目的のおそれがある事案は60日以内）です。今回の発表文に委員会への報告の有無は書かれていません。手順は[個人情報保護委員会への報告義務の実務](https://www.issoh.co.jp/column/details/17840/)をご覧ください。 ### 自社の点検で足りる範囲と、第三者の診断やフォレンジックへ切り替える条件 カード番号を持たず、桁数検査で全桁も桁数超過も出ず、入口の棚卸しも終わっているなら、自社の点検で一区切りと判断してかまいません。 次のどれかに当たるなら、自社だけで結論を出すのはやめましょう。 - 申込みフォームや会員機能を外部公開しているのに、第三者の診断を一度も受けていない - 委託先が作ったシステムで、カード番号の保存箇所を誰も説明できない - 桁数検査で全桁か桁数超過が出た - ログの保存期間が契約にも設定にも書かれていない 申込みやカード変更をAPIで受けているなら、認可とレート制限の抜けは[API不正アクセス対策の実装手順](https://www.issoh.co.jp/tech/details/18346/)で確かめられます。侵入の痕跡が見つかった場合、先に行う作業は保全です。ファイルを消す前に[フォレンジック調査の流れと調査会社の選び方](https://www.issoh.co.jp/column/details/2812/)を確認してください。痕跡は無いが外部公開の入口の弱点を第三者に洗い出してほしい場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)でご相談いただけます。 ## よくある質問 住友生命の不正アクセスについて、利用者から出やすい質問をまとめました。内容は2026年11月9日の両社の発表に基づきます。 ### 住友生命の不正アクセスで自分が対象かどうかはどう確かめますか？ 発表文に、自分で照会するページの案内はありません。住友生命は対象者の特定を進めており、確認結果を踏まえて対応するとしています。急いで確かめたい場合は、専用窓口の0120-550-997（平日9時から17時）に電話してください。発表文に載っている番号へ自分でかけるのが確実で、届いたメールや電話で案内された番号は使わないほうが安全です。 ### Vitality保険に入っている人の情報も漏れましたか？ 発表では、保険契約と保険契約に付随するVitalityの情報は漏えいしていないとされています。対象は単独で利用できる体験版・企業型とVitalityスマート（福利厚生タイプ含む）の現在と過去の利用者です。保険に加入していても、別に単独プランを使ったことがある人は、その利用分について対象になる可能性があります。歩数などのプログラム利用データは含まれていません。 ### クレジットカードは止めたほうがよいですか？ カード番号が含まれたのは約1,000名で、番号は一部マスキング済みとされています。11月9日の時点で不正利用は確認されておらず、両社の発表に再発行の案内もありません。まず利用明細に身に覚えのない請求がないかを確認します。Vitalityスマートにカードを登録していて不安が残るなら、カード裏面の番号からカード会社に再発行の可否を尋ねてください。 ### Vitalityスマートの解約やカード変更はできますか？ 利用者自身による解約とクレジットカード情報の変更などは、11月3日から止まっています。発表文は、停止している取扱いについて問い合わせ窓口で相談を受けるとしているので、電話で相談してください。再開の時期は示されておらず、住友生命のホームページで知らせるとされています。Vitalityアプリの利用には影響がありません。 ### 10月のNTTデータの漏えいと同じ原因ですか？ 両社の発表に、10月のSecuritize Japanの事案と関連づける記載はなく、別の事案として扱うべきものです。今回はNTTデータが受託するシステムへの不正アクセスで、原因と詳しい経緯はまだ調査中とされています。11月10日に確認した時点で侵入経路は公表されていません。原因を推測で語る情報には注意し、続報は両社の公式発表で確かめてください。 ## 関連記事 - [NTTデータ委託先の情報漏洩：委託先はSecuritize Japan、社債購入者の対象確認と漏えい項目](https://www.issoh.co.jp/tech/details/19229/)：NTTデータが委託元の立場だった別の事案 - [API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策](https://www.issoh.co.jp/tech/details/18346/)：申込みや変更を受けるAPIの点検 - [個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務](https://www.issoh.co.jp/column/details/17840/)：事業者が行う報告の流れ - [エディオン不正アクセス第2報：カード番号の対象確認とログ・決済画面の改ざん対策](https://www.issoh.co.jp/tech/details/19532/)：ログへのカード番号の混入と決済画面の改ざん - [PCI DSSとは？12要件と準拠レベル・v4.0.1移行を発注視点で整理【2026年時点】](https://www.issoh.co.jp/column/details/13185/)：カード情報を扱う委託先に求める基準 --- 出典: [住友生命不正アクセス：Vitality約8万名の対象と停止中の手続き、カード番号の桁数点検]()（株式会社一創）