日産自動車、顧客管理システムの開発委託先が侵害され日産福岡販売の顧客約2万1,000人分が流出

項目	内容
発生日	2025年9月26日（侵害の検知）／2025年10月3日（委託先から日産自動車への報告）
公表日	2025年12月23日
対象組織・業界	日産自動車（対象は日産福岡販売の顧客／小売・EC）。侵害を受けたのは顧客管理システムの開発委託先である Red Hat のデータサーバ
影響件数	日産福岡販売で車両購入やサービス入庫をしたことがある顧客 約2万1,000人。氏名、住所、電話番号、メールアドレスの一部のほか、営業活動に使用する関連情報
攻撃手法	顧客管理システムの開発を委託している Red Hat のデータサーバが侵害された。侵入経路は公表されていない
情報源	Security NEXT（2025年12月23日）

概要

日産自動車は2025年12月23日、販売会社の顧客管理システムの開発を委託している Red Hat のデータサーバが侵害されたことが判明したと公表しました。

流出したのは、日産福岡販売で車両購入やサービス入庫をしたことがある顧客 約2万1,000人の情報です。含まれるのは氏名、住所、電話番号、メールアドレスの一部のほか、営業活動に使用する関連情報です。

侵害の検知は2025年9月26日で、翌月10月3日に同社より報告があり、日産自動車は個人情報保護委員会へ届け出ました。対象となった顧客に連絡を取り、経緯を説明するとともに注意を呼びかけています。

二次被害などは確認されていません。

経緯

• 2025年9月26日: 侵害が検知される
• 2025年10月3日: 委託先から日産自動車へ報告。個人情報保護委員会へ届け出
• その後: 対象となった顧客へ連絡し、経緯を説明するとともに注意を呼びかけ
• 2025年12月23日: 日産自動車が公表。二次被害は確認されていないとする

原因

判明している事実: 販売会社の顧客管理システムの開発を委託している Red Hat のデータサーバが侵害されたことです。侵入経路、悪用された脆弱性、侵害されたサーバの用途の詳細は公表されていません。

考えられる原因（推測）

侵害されたのが「開発を委託している」先のデータサーバである点が、この事案の構造を示しています。稼働中の顧客管理システムそのものではなく、その開発を担う側の環境に顧客データが存在していたことになります。

開発の工程では、動作検証のために実データが必要になる場面があります。本番と同等のデータを開発側の環境に持ち込むと、本番と同じ機微さのデータが本番とは異なる管理下に置かれます。流出項目に「営業活動に使用する関連情報」が含まれていることは、渡されていたのが単なるテスト用の断片ではなく、業務に使われる実データであった可能性を示唆します。

対象が日産福岡販売の顧客に限られている点からは、販売会社ごとにシステムまたはデータが分かれていた可能性が考えられます。分離されていたことが、影響範囲を1社の顧客に留めたとも読めます。

なお、侵害の検知から日産自動車への報告までに1週間の間隔があります。

対策

組織が学ぶべきこと

1. 開発委託先に実データを渡すかどうかを、契約の段階で決める

開発の検証に実データが必要かどうかは、設計上の判断です。マスキングした擬似データで検証できる範囲を先に切り分けておけば、委託先の環境に実データを置く必要はなくなります。「必要になったら渡す」という運用では、いつ何が渡ったかを追跡できません。

2. 委託先の侵害を、自社の公表義務として扱う体制を持つ

今回、侵害を検知したのは委託先で、公表したのは日産自動車です。委託先から報告が上がらなければ、自社の顧客情報が流出した事実を知る手段がありません。報告の期限と経路を契約に明記し、委託先が速やかに報告できる関係を維持することが前提になります。

3. 販売会社ごとのデータ分離が、影響範囲の上限を決めた

対象は日産福岡販売の顧客に限られています。販売会社をまたいで顧客データが統合されていれば、影響件数は桁違いになった可能性があります。分離は攻撃を防ぐ手段ではありませんが、侵入されたときにどこで止まるかを決めます。

ヤグラの視点 — 攻撃面の拡張：顧客2万1,000人分は、販売会社でもメーカーでもない場所にあった

日産福岡販売で車を買った顧客から見れば、自分の氏名と住所と電話番号を預けた相手は販売会社です。実際にその情報が流出した場所は、販売会社でもメーカーでもなく、顧客管理システムの開発を委託されていた Red Hat のデータサーバでした。侵害を検知したのもその委託先で、日産自動車がそれを知ったのは1週間後です。

守るべき範囲を「自社のネットワークとシステム」で線引きすると、この事案は視界に入りません。顧客データが実際に置かれていた場所は、日産自動車の資産台帳にも、日産福岡販売のアクセス管理にも現れない外部の環境です。攻撃面という言葉は外部からの侵入経路を指して使われますが、システムの開発を委託した先の作業環境も、同じ意味で守るべき面の一部です。開発環境は本番と比べて認証やネットワークの制限が緩く構成されがちで、そこに本番相当のデータが置かれると、防御の水準とデータの機微さが釣り合わなくなります。

委託先を管理下に置く手段は、技術ではなく指定と検証です。どのデータを渡すか、マスキングするか、どこに保存させるか、いつ削除させるか、侵害時に何時間で報告させるか——委託元が指定していない項目は、委託先の既定の運用のまま動きます。システム開発を外部に委ねるほど、自分の顧客データがどの環境に存在しているかを把握しておく必要が増します。この事案で影響が1社の顧客に留まったのは、データが販売会社ごとに分かれていたという設計の結果でした。

今後の対応

• 侵入経路と、侵害されたサーバの用途の特定
• 開発委託先に実データが渡されていた経緯
• 対象となった顧客への連絡完了状況
• 委託先管理を含む再発防止策の公表内容

更新履歴

日時	内容
2026-08-12	2025年12月23日の公表内容をもとにアーカイブ記事として作成