タグ: 情報漏洩

投稿日:

デジタル庁GSSに不正アクセス ―約24.6万件の情報漏洩の可能性と企業の対策

Share
デジタル庁GSSに不正アクセス ―約24.6万件の情報漏洩の可能性と企業の対策アイキャッチ画像

デジタル庁は2026年9月11日、ガバメントソリューションサービス（GSS）への不正アクセスにより、職員や業務関係者の個人情報約24.6万件が漏洩した可能性があると公表しました*1。今回の事案では、VPN機器の既知の脆弱性が悪用され、保守運用担当者のアカウントを利用した大量のファイルアクセスが検知されています。本記事では、公表情報をもとに事案の経緯と影響を整理するとともに、企業が脆弱性管理やセキュリティログ監視で見直したいポイントについて解説します。

GSS不正アクセスの検知から公表までの経緯

GSSは、デジタル庁が運用し、各府省庁などが業務に利用するサービスです。今回の調査は、6月25日に保守運用担当者のアカウントによるサーバー上の大量ファイルアクセスを検知したことから始まりました。VPN機器の脆弱性を使って第三者が侵入していたと判明したのは7月9日です。同日、当該アカウントを停止し、侵害された機器と外部との通信を遮断したと説明されています。6月25日は検知日であり、侵入開始日を示すものではありません。7月15日に個人情報保護委員会へ報告し、対象者や情報の内容の調査を進めたうえで9月11日に公表しました。

公式Q&Aによると、影響範囲や侵入経路、漏えいした可能性のある情報の特定に時間を要したとしています。公表時点では、修正プログラムの適用や関係アカウントの認証情報変更、通信遮断などの措置を実施済みで、その後、新たな不正アクセスや不審な通信は確認されておらず、政府業務への支障も生じていないと説明しています。*2。

図1：GSS不正アクセスの検知から公表まで

出典：デジタル庁「ガバメントソリューションサービスへの不正アクセスによる職員等の個人情報の漏えいの可能性について」（https://www.digital.go.jp/news/2026-0911-01）および「ガバメントソリューションサービスへの不正アクセスによる職員等の個人情報の漏えいの可能性について」に関するQ&A」（https://www.digital.go.jp/press/5fc99139-a4e2-4b7b-8b0c-d475e926143f）を基に作成

約24.6万件の個人情報が漏洩した可能性

約24.6万件の内訳は、GSS利用機関の職員や業務に携わった公務員等の情報が約18.9万件、業務に携わった事業者や個人の情報が約5.7万件です。漏洩した可能性のある個人情報には、氏名、メールアドレス、電話番号、住所などが含まれます。属性別では、氏名が約23.6万件、メールアドレスが約23.1万件、電話番号が約9.4万件、住所が約0.1万件とされています。これらの属性には重複があるため、単純に合計することはできません。

デジタル庁は、一般の国民の個人情報や、マイナンバー、金融機関口座情報、年金番号は含まれないと説明しています。ただし、公務員以外でも、関係省庁の業務に携わった企業の従業員や個人事業主などは対象に含まれます。また、約24.6万件すべてについて、外部への持ち出しが確認されたわけではありません。不正アクセスの痕跡があり、漏えいの可能性を否定できない情報も対象にした数字です。9月14日時点で確認した公表資料では、関連する二次被害は確認されていません。

深刻度「中」でも悪用

今回の脆弱性は、攻撃が確認される前に公表されていた既知の問題でした。デジタル庁は、当初の深刻度評価に応じた一般的対応より早く対処を進めたものの、修正プログラムの適用前に悪用されたと説明しています。この情報だけで、脆弱性を把握していなかった、あるいは放置していたとは判断できません。VPN製品名やCVE番号なども公表されていません。企業で見直したいのは、脆弱性の深刻度と、自社での対応優先度をつなぐ判断です。

CVSSを管理するFIRSTは、CVSSの基本評価値は脆弱性そのものの深刻度を表し、単独でリスク評価に使うべきではないと説明しています*3。利用環境や脅威の状況を加えて評価する考え方が、公式ガイドに示されています。

これを自社の運用に落とし込むなら、スコアの横に「どこから接続できる機器か」「侵害された場合に何へアクセスできるか」「業務や情報にどのような影響があるか」を記録する方法が考えられます。同じ深刻度でも、外部から接続できるVPNと、接続元を限定した機器では、確認すべき条件が異なります。これは今回のGSSの詳細構成を推定する話ではなく、自社で優先順位を判断するための実務上の整理です。パッチ適用に調整が必要な場合は、ベンダーが示す回避策や接続制限の適用可否も併せて検討します。その際、「次回メンテナンスで更新する」という予定だけで終わらせず、更新までに残るリスクと担当者、再判断の条件を記録しておくと、悪用情報が追加された際の見直しにつなげやすくなります。

図2：脆弱性対応の優先順位を考える視点

出典：FIRST「CVSS v4.0 User Guide」、デジタル庁「本事案に関するQ&A」をもとに弊社作成
※GSSの実際の運用・判断手順を示すものではありません。

保守アカウントを信頼しきらず、操作の実態を確かめる

もう一つの論点が、保守運用担当者のアカウントを通じたアクセスです。今回の公表資料では、アカウントをどのように悪用できる状態にしたのか、認証情報をどう取得したのかまでは明らかにされていません。パスワードの使い回しや多要素認証の未導入が原因だった、と断定することはできません。

企業側で検討したいのは、認証の成否に加え、アクセス後の行動を確認できる状態です。例えば、保守作業の予定と実際のアクセス時刻を照合し、対象サーバー、操作内容、ファイルへのアクセス量が作業目的と整合するかを確認する、といった運用が考えられます。大量アクセス自体には正当な作業もあるため、件数だけで不正と決めつけず、普段の利用や作業申請と照らし合わせることが大切です。その判断を支えるのが、VPNの接続記録、認証ログ、サーバーの監査ログなどです。NISTのログ管理ガイドでは、ログ管理の基盤整備や、組織全体で継続的にログを管理するプロセスの構築について示しています*4。

企業では、必要なログを取得・保存するだけでなく、複数のログを時系列で確認できる状態を整え、異常を検知した際の対応や役割分担まで含めて運用を設計することが重要です。

ゼロトラストも、日々の脆弱性管理と監視が土台になる

GSSはゼロトラストアーキテクチャを採用していたと説明されています。ただし、具体的な構成や対策は非公表です。今回の事案だけから、ゼロトラスト全体の有効性や、特定の対策が機能しなかった理由を評価することはできません。NISTはゼロトラストを、ネットワーク上の場所や資産の所有者だけで、利用者や機器を暗黙に信頼しない考え方として整理しています*5。

企業が確認すべきなのは、自社でどのアクセスを検証し、どこまでを許可し、どの記録から異常を判断できるかです。VPNの更新、アクセス権限の確認、ログ分析を、導入した製品や構成に合わせて継続する必要があります。

BBSecのログ分析・活用支援で、確認できる範囲を広げる

「ログは保存しているが、保守アカウントの不正利用をどう見つけるか決まっていない」。そうした課題には、取得対象と分析目的の整理から取り組む方法があります。BBSecの「セキュリティログ分析／活用支援」は、蓄積したログの分析から、ログ取得環境の整備に向けたコンサルティング、Splunkを用いた統合ログ管理・分析環境の構築、運用までを支援するサービスです。現状の管理ポリシー、取得状況、体制、運用プロセスを確認し、改善プランを検討しましょう。自社のVPNや認証基盤、サーバーについて、取得するログと検知したい事象を具体化すれば、追加すべき記録や運用上の課題を検討できます。既存ログの活用や分析環境の見直しを進めたい企業は、BBSecにご相談ください。

【参考情報】

編集責任：木下

セキュリティ対策についてお困りの方へ

自社のセキュリティ対策についてお悩みの場合は、ブロードバンドセキュリティ（BBSec）までお気軽にご相談ください。

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

盗まれたトークンから約3時間でクラウド管理権限へ ―AnthropicのAI悪用報告から考える企業の対策

Share
AnthropicのAI悪用報告から考える企業の対策アイキャッチ画像

生成AIの活用が広がる一方で、サイバー攻撃にAIを悪用する動きも確認されています。Anthropicが2026年9月10日に公表したAI悪用の調査報告には、盗まれた開発者トークンを足掛かりに、攻撃者が被害組織のクラウド環境の完全な管理権限を約3時間で取得した事例が記されています。AIサイバー攻撃への備えを考えるうえで、この事例は、認証情報の保護と、検知後に動ける体制を点検する材料となります。

AnthropicのAI悪用報告で何が確認されたのか

今回の報告では、2025年12月から2026年8月にかけてAnthropicが検知・対処したAI悪用活動が取り上げられています。サイバー攻撃におけるAIの使われ方には幅があり、攻撃者の補助として利用された例に加え、偵察、侵入、認証情報の収集、情報窃取などをAIに実行させる例や、複数の標的に対してAIエージェントが並行して処理する例も確認されています。一方、標的の選定や攻撃結果の確認、収益化などの重要な判断には、人間が引き続き関与していたとされています。

報告には、認証情報の悪用に関する事例も複数示されています。被害組織の環境から盗んだAIサービスのAPIキーを別の攻撃に利用した例に加え、盗まれた開発者トークンを足掛かりに、被害組織のクラウド環境の完全な管理権限を約3時間で取得した事例も報告されています。認証情報は情報を盗む入口となるだけでなく、攻撃に用いるAIの計算資源へのアクセスにも利用されていました。*6

なお、約3時間という数値は、Anthropicが観測した個別の侵害事例に関するものです。すべてのAIを使った攻撃が同じ速さで進むことや、従来の攻撃より何倍速いかを示す統計ではありません。この事例から企業が考えるべきなのは、約3時間という時間そのものではなく、認証情報が悪用された場合に、異常を検知し、調査やアクセス制限などの対応へ移るまでにどの程度の時間を要するかという点です。

図1：AI悪用による侵入の個別事例

開発者トークンから管理権限取得までの個別事例
開発者トークンから管理権限取得までの個別事例
出典：Anthropic「Detecting and countering misuse of AI: September 2026」（https://www.anthropic.com/threat-intelligence-report-september-2026）を基に作成

認証情報漏洩への対策は、トークンの権限まで確認する

認証情報の管理を見直すときは、人がログインに使うパスワードに加え、アプリケーションや開発環境が使うアクセスキー、トークンも対象にします。ここからは、クラウド環境で取り組める対策をAWSの公式資料を例に整理します。前述の被害事例のクラウド事業者をAWSと特定するものではありません。

AWSはIAMの推奨事項として、一時的な認証情報の利用、多要素認証（MFA）、業務に必要な範囲に絞った権限付与、使われていない認証情報や権限の定期的な見直しを挙げています*2。システムが継続的に使う認証情報についても、長期のアクセスキーを配布する構成から、IAMロールによる一時的な認証情報へ移行できるかを検討します。自社で点検する際は、認証情報を誰が管理し、どのシステムが使い、どのデータにアクセスできるのかを確認し、用途が終わったテスト用の権限や、担当者の異動後も残る認証情報などを整理します。認証情報の保護とあわせて、必要以上の権限を与えないことが重要です。

クラウドのログは、データへの操作まで記録されているか

クラウド監視では、「ログを取得している」だけでなく、実際にどの操作まで記録されているかを確認する必要があります。例えばAWS CloudTrailでは、Amazon S3上のオブジェクトの読み取りなどはデータイベントに分類され、証跡やイベントデータストアでは初期設定で記録されないため、取得には設定と追加料金が必要です*3。自社の重要データについて、調査時に確認したい操作が記録に残るかを点検し、顧客データを保管する領域であれば、誰が、いつ、どのデータへアクセスしたかを追える設定になっているかを確認します。大量のログを一律に増やすのではなく、守るべきデータと必要な調査項目を先に決めると、取得範囲や費用も検討しやすくなります。

また、アクセスがあったという事実だけで、不正利用とは断定できません。AWSのGuardDutyの対応ガイドも、検知に関係するユーザーやロール、API操作を特定し、操作時刻や接続元IPアドレスを含めて正当な利用か確認するよう案内しています*4。担当者がこれらを照合できる情報と連絡先を持つことが、アラートを判断につなげる前提になります。

検知後は、どの認証情報の利用を止めるか判断する

認証情報の不正利用が疑われる場面では、影響するユーザーやロールと、その権限を特定する必要があります。API操作の内容を見れば、正常な処理との違いや調査すべき範囲を検討できます。確認の結果、正当な利用と判断できない場合は、該当するクラウドサービスの手順に沿って封じ込めを進めます。

ここで注意したいのが、すでに発行された一時的な認証情報の扱いです。AWSは、不正利用を止める手段として、一時的な認証情報に付与される権限の変更や、IAMロールの既存セッションの取り消し方法を説明しています*5。対象のロールを利用する正常なユーザーにも影響する場合があり、どの利用を止めるかを区別することが必要です。

緊急時の手順には、実行する操作だけでなく、その操作で停止する業務と、判断を行う担当者も記載しておきます。「認証情報を無効にする」とだけ書かれた手順を、自社のアカウントやサービスに当てはめて確認する作業です。担当部門が異なる場合も、現場で判断できる範囲をあらかじめ合意しておくことが、連絡待ちを減らすための実務的な準備になります。

図2：認証情報の悪用に備える監視と初動対応

出典：AWS「Remediating potentially compromised AWS credentials」（https://docs.aws.amazon.com/guardduty/latest/ug/compromised-creds.html）「Disabling permissions for temporary security credentials」（https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_disable-perms.html）「SEC10-BP07 Run simulations」（https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_run_game_days.html）を基に弊社作成

「対応できるはず」を訓練で確かめる

検知から対応までの時間を短くしたいなら、まず自社の手順を一度動かして確かめることです。AWSのWell-Architected Frameworkでは、インシデント対応能力を評価する方法として演習を挙げ、机上演習では関係者の役割や責任、連絡手段、手順書を確認できると説明しています。*6

例えば「夜間に、通常と異なる認証情報の利用が通知された」という場面を設定し、担当者に連絡が届くか、正当な作業かを確認できるか、アクセス制限を誰が判断するかを話し合います。これは本稿で提案する訓練の例です。連絡先の更新漏れや判断権限の曖昧さが見つかれば、実際のインシデントが起こる前に修正できます。

演習では、通知を確認した時点、調査を始めた時点、対応を決めた時点を分けて記録すると、改善すべき箇所を具体化できます。約3時間という他社事例をそのまま自社の目標時間にするのではなく、自社の重要業務と運用体制に即して、対応を遅らせる要因を取り除くことが大切です。

監視からインシデント対応まで、セキュリティ体制を見直したい企業へ

こうした体制を自社だけで維持することが難しい場合は、監視や分析、対応を専門家と分担する方法があります。ブロードバンドセキュリティ（BBSec）の「G-MDR®」では、セキュリティ対策を統合的に監視・相関分析し、専門エンジニアが24時間365日体制で監視・運用を支援します。アラートの検知だけでなく、その後の調査や対応を含めたセキュリティ体制についてもご相談いただけます。

G-MDR® について詳しく見る

※外部サイトにリンクします。

セキュリティ対策について相談する

「アラートは検知できても、その後の調査や対応に不安がある」「24時間365日の監視体制を整えたい」といった課題がある場合は、BBSecまでお気軽にご相談ください。

導入を検討する際は、自社のクラウド環境や既存製品から連携できるログ、検知後に実行する対応、社内の承認が必要な操作を具体的に相談するとよいでしょう。すべてのクラウドサービスや復旧作業が無条件に対象になると考えず、自社に必要な監視範囲と対応範囲を確認することが大切です。

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

RIZAPの生成AIへの顧客情報誤アップロードから考える ―企業が見直すべきシャドーAI対策

Share
RIZAPの生成AIへの顧客情報誤アップロードアイキャッチ画像

生成AIの業務利用が広がる一方、会社が把握・承認していないAIサービスを従業員が利用する「シャドーAI」は、情報漏洩につながるリスクの一つです。本記事では、RIZAPが公表した事案をもとに、生成AIへ情報を送信する際の注意点と、企業が見直すべきシャドーAI対策について解説します。

※本記事は2026年9月14日時点で公表されている情報に基づき作成しています。

RIZAPの生成AIへの誤送信で何が起きたのか

2026年9月3日、RIZAPは、社員が私用の外部生成AIサービスに顧客情報を誤ってアップロードしたと公表しました。[1]今回の事案は、RIZAPの社員が特定保健指導管理システムのデータを集計する際、顧客情報を外部の生成AIサービスに誤ってアップロードしたものです。対象は、同システムに2026年1月1日から8月19日までに登録された対象者データの一部で、氏名や保険証記号番号のほか、疾患情報などの要配慮個人情報も含まれます。同社の発表では、対象者数および利用された生成AIサービスの名称は公表されていません。またAI事業者以外の第三者による閲覧と学習利用の可能性はないと説明する一方、事業者の役職員等が閲覧可能だったかは確認中としています。外部生成AIへの情報送信では、閲覧の可能性と学習への利用は別の論点です。

図1：RIZAPの公表内容
※「学習されない」という説明だけで、外部送信の適否は判断できません。

出典：RIZAP株式会社「当社における外部生成AIサービスへのお客様情報の誤ったアップロードに関するお詫びとお知らせ」（2026年9月3日）（https://business.rizap.jp/news/2492）を基に作成

「学習されない」だけで生成AIへの入力を判断しない

外部の生成AIサービスにファイルをアップロードすると、まず、そのサービスへ情報を送信することになります。その後にどのように保存・処理され、誰がアクセスでき、学習に利用されるかは、契約や設定、サービスの仕様によって確認する論点です。一つの設定を見ただけで、情報の取り扱い全体を判断することはできません。

個人情報保護委員会は、生成AIに個人情報を含むプロンプトを入力する際、特定した利用目的の達成に必要な範囲かを確認するよう注意喚起しています。また、本人の同意なく入力した個人データが応答の出力以外の目的で扱われる場合には、法に違反する可能性があるとして、機械学習に利用しないこと等の十分な確認を求めています。[2]企業が確認すべきなのは、「学習をオフにしたか」に加えて、「この業務に、この情報を外部へ送る必要があるか」です。たとえば、集計式を知りたいだけなら実在する顧客のデータを渡さず、架空のサンプルで処理方法を相談できる場合があります。また、実データの処理が必要な場合は事前に承認された環境と手順で取り扱う業務プロセスを設計します。

シャドーAIとは？ 私用アカウントと業務利用の境界

本記事で述べている「シャドーAI」とは、会社が把握・承認していないAIサービスを、従業員が業務に利用することです。たとえば、会社が承認していない個人アカウントで、会社の資料を要約したり、業務ファイルを分析したりする利用が該当します。同じサービス名でも、会社が契約・管理する環境と、従業員の私用アカウントでは、管理できる範囲や適用される条件が同じとは限りません。そのため、社内ガイドラインに「生成AIの利用可」とだけ記載しても、判断基準としては不足します。対象のサービスと契約プラン、使用するアカウント、許可する業務、入力できる情報を一緒に示す必要があります。「会社で使えるAI」と「自分が普段使っているAI」を現場が取り違えないよう、利用ルールや利用環境を整えることが大切です。

RIZAPでは再発防止策として、社内で許諾されていない生成AIの業務利用禁止の再周知、教育、アクセス権限や利用環境の点検・見直しを挙げています。企業が生成AIの利用を見直す際は利用ルールだけでなく、アクセス制限などの利用環境もあわせて確認する必要があります。

生成AIの情報漏洩を防ぐために企業が見直すべきこと

社内ルールは、現場の作業に沿った形で示すと使いやすくなります。以下は、企業が自社の契約や情報分類に合わせて具体化するための判断例です。

図2：生成AIへファイルを送る前の判断例

参考：個人情報保護委員会【別添1】「生成AIサービスの利用に関する注意喚起等について」（令和5年6月2日）（https://www.ppc.go.jp/files/pdf/230602_kouhou_houdou.pdf）等を参考に弊社作成。
※図は企業向けの一般的な判断例であり、法令上の適否を判定するものではありません。また、RIZAP社内の実際の運用を示すものではありません。

ファイル単位ではなく、中に含まれる情報まで確認する

表計算ファイルには、集計対象の列だけでなく、別のシートや自由記述欄に情報が残っている場合があります。そこで、アップロード用のデータを別に作成し、必要な項目だけを含める手順を設けます。氏名を削除しただけで安全と判断せず、番号や属性の組合せなど、個人を識別できる情報が残っていないかも確認します。

禁止事項と、迷ったときの相談先をセットにする

教育では「個人情報を入力しない」という説明に加え、集計表、議事録、顧客から届いた資料など、実際の業務を題材に判断を練習します。許可された使い方と相談窓口も示し、判断できないファイルは送信を止めて確認する運用にします。アクセス制限やデータ送信の制御を導入する場合も、対象のサービスや通信経路でどこまで制御できるかを確認したうえで、ルールを補完する仕組みとして位置付けます。

生成AIへ誤って情報を送信した場合の対応

生成AIへの誤送信に気付いたら、追加の送信を止め、社内の情報セキュリティ・個人情報管理の担当窓口へ速やかに報告します。サービス名、アカウント、送信日時、ファイルの内容、実施した操作を整理し、削除依頼や事業者への照会を進めます。必要な記録の保全と拡散防止は担当者の指揮で行い、記録用に機微な情報を別の外部サービスへコピーしないようにします。 確認したいのは、保存先と保持期間、閲覧の可能性、学習等への利用、削除の対象と完了状況です。画面上の履歴削除と、事業者側にあるデータの削除がどのような関係にあるかも確認します。行政機関への報告や本人への通知については、把握した事実に基づき、個人情報保護委員会の案内に沿って要否を判断します。[3]

生成AIの安全な業務利用に向けたBBSecの支援

生成AIの利用を始めていても、承認手順や教育が追い付いていない企業は、まずルールと実際の使い方の差を整理することが出発点になります。BBSecの「AIサービス提供者・利用者向けサイバーセキュリティ対策支援」では、AI利用者向けのセキュリティガイドライン雛形の提供と、事業に合わせたカスタマイズによる整備支援を用意しています。さらに、AI利用時の脅威・リスク・適切な利用方法・対策を扱う教育コンテンツの提供や、講師によるオンライン研修にも対応しています。既存の社内規程との整合性を見直したい場合は、「情報セキュリティ文書整備支援」により、文書体系の提案や既存文書の統廃合・改訂について支援を受けることもできます。生成AIを安全に業務利用するためには、ルールを定めるだけでなく、従業員が実際の業務で判断できるよう、教育とあわせて運用していくことが重要です。自社のAI利用ルールや教育体制を見直したい場合は、BBSecにご相談ください。

よくある疑問

▼ 個人情報を削除すれば、自由に使えますか？

【参考情報】

編集責任：木下

生成AIの安全な業務利用についてご相談ください

生成AIの安全な業務利用や、AI利用ルール・教育体制の整備についてお悩みの方は、ブロードバンドセキュリティ（BBSec）までお気軽にご相談ください。

ウェビナー開催のお知らせ

最新情報はこちら

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

クラウドセキュリティの事故・インシデント事例から学ぶ主なリスク

Share

クラウドサービスの利用は利便性などのメリットがある一方で、セキュリティリスクも伴います。サイバー攻撃の被害に遭った場合、データの漏洩やサービス停止に追い込まれてしまうなどのリスクがあります。実際、国内外でもクラウドサービス（SaaS）のセキュリティ設定ミスなどを原因としたセキュリティインシデントが発生しており、その影響は深刻です。本記事では、クラウドサービスの利用時におけるセキュリティリスク、具体的なインシデント事例、サプライチェーンでのセキュリティについて解説します。

クラウドサービス利用時のセキュリティリスク

クラウドサービスの利用が拡大する一方で、組織を脅かす要因（脅威）や様々なリスクが存在します。

【要因（脅威）】

  • 不正アクセス：クラウド上のデータやシステムに対する未承認のアクセスは、企業情報の漏洩や改竄につながる可能性があります。
  • サイバー攻撃：DDoS攻撃やマルウェアの拡散は、サービスの停止やデータの破壊を引き起こすことがあります。
  • 内部不正：従業員や内部関係者が意図的に不正行為を行うケースがあり、これは情報の盗難や破壊に直結します。
  • 設定／管理の不備：アクセス権限の設定ミスやセキュリティパッチの適用漏れは、攻撃者にとって格好の侵入経路となります。

【リスク】

  • 情報漏洩：クラウド上に保存されたデータが外部に流出することです。不正アクセスやサイバー攻撃、内部不正によって機密情報が漏洩すると、企業の信用が大きく損なわれ、顧客や取引先との信頼関係が崩壊する危険性があります。
  • 情報改ざん（消失・破壊）：クラウド上のデータが不正に改ざんされたり、消失・破壊されたりすることです。サイバー攻撃や内部不正が原因でデータの整合性が失われると、業務運営に重大な支障をきたし、最悪の場合、ビジネスの継続が困難になることもあります。
  • システム停止：クラウドサービス自体が停止するリスクです。DDoS攻撃や設定／管理の不備によってシステムがダウンすると、サービス提供が一時的に停止し、顧客対応や取引が滞ることになります。これにより、企業の収益に直接的な影響を与え、長期的なビジネス成長にも悪影響を及ぼす可能性があります。

クラウドサービスのセキュリティインシデントの例

近年、クラウドサービスのセキュリティに関する設定が十分でなかったために、意図せず、クラウドサービスで管理している機密情報を無認証状態で外部に公開してしまい、機密情報を漏洩させてしまった事例が相次いで報告されています。以下に、国内で実際に発生したインシデントを例に挙げ、その原因、被害状況などを紹介します。

日本国内のクラウドセキュリティインシデントの報告事例（2023年）

報告年月業種原因概要
2023年12月総合IT企業設定ミス利用するクラウドサービス上で93万5千人以上の個人情報を含むファイルが公開設定となっており、閲覧可能な状態だった*7
2023年6月地方公共団体設定ミス利用するクラウドによるアンケートフォームの設定ミスにより、申込者の個人情報が漏洩していた。*2
2023年5月自動車メーカー設定ミス関連会社が運用するクラウド環境に設定ミスがあり、管理委託する顧客約215万人分に係る情報が、外部より閲覧可能な状態だった。*3
2023年4月空調
設備メーカー		不正アクセス利用するクラウド型名刺管理サービスで従業員になりすました不正アクセスが確認され、約2万件の名刺情報が第三者に閲覧された可能性*4

2023年5月に公表された国内自動車メーカーの事例について判明した内容は以下のとおりです。顧客に関する情報が、長いものでは約10年もの間、外部から閲覧可能な状態となっていました。

公表日外部から閲覧された
可能性のある情報		対象閲覧可能になっていた期間
5月12日車載端末ID、車台番号、車両の位置情報、時刻2012年1月2日～2023年4月17日の間、該当サービスを契約していた約215万人2013年11月6日～2023年4月17日
5月12日法人向けサービスで収集されたドライブレコーダー映像（非公開）2016年11月14日～2023年4月4日
5月31日車載端末ID、更新用地図データ、更新用地図データ作成年月該当サービスに契約した顧客、および該当サービス契約者のうち、2015年2月9日～2022年3月31日の間に、特定の操作を行った顧客2015年2月9日～2023年5月12日
5月31日住所、氏名、電話番号、メールアドレス等日本を除くアジア・オセアニア2016年10月～2023年5月

本件に対しては個人情報保護委員会からの指導が入り、2023年7月には同社より以下に示した再発防止策が明示されています。サプライチェーンである委託先関連会社とも共有され、管理監督すると公表されました。自社のみならず、委託先についてもクラウド設定にセキュリティ上の不備がないか注意する必要があります。

  • 技術的安全管理措置の強化
  • 人的安全管理措置の徹底
  • 機動的な委託先管理のための見直し

また、2023年12月7日、スマホアプリなどを提供している国内総合IT企業が、Googleドライブで管理していた一部ファイルが外部から閲覧可能な状態だったと公表しました。ファイルへのリンクを知っていれば、誰でもインターネット上でアクセス可能な状態だったといいます。インシデントの原因は、Googleドライブの閲覧範囲の公開設定を「このリンクを知っているインターネット上の全員が閲覧できます」にしていたことで、設定がされてから6年以上もの間、閲覧可能な状態となっていました。

クラウドサービスの設定ミスでセキュリティインシデントが多発している原因の一つとして考えられるのが、クラウドサービスを利用している企業や組織が対応すべき情報セキュリティ対策が曖昧になっていることです。クラウドサービス事業者とクラウドサービスユーザはお互いにクラウドサービスに対する責任を共有する「責任共有モデル」を多くの場合採用しています。しかし、実際にはクラウドサービス利用者側でのセキュリティの当事者意識が低いというケースが散見され、そのために設定ミスによるインシデントが多発していると考えられます。

サプライチェーンにおけるクラウドサービスのセキュリティ

クラウド上でソフトウェアを提供するサービス「SaaS」の利用が拡大するにともない、セキュリティに関するインシデントが多く報告されています。IPA（情報処理推進機構）が2023年7月に公開した「クラウドサービス（SaaS）のサプライチェーンリスクマネジメント実態調査」によると、セキュリティインシデントの主な原因として、クラウドサービス事業者のセキュリティ対策の不足や、利用者側のセキュリティ意識の欠如が挙げられています。また、サプライチェーン全体のセキュリティ管理の不備も大きな課題となっています。特に、クラウドサービスの利用状況の可視性が低く、インシデント発生時の対応が遅れることが、被害を拡大させる要因となっています。

さらに、同調査では、セキュリティ対策の強化が急務であるとする回答が多く寄せられました。具体的な対策としては、クラウドサービス提供者との連携強化、セキュリティ教育の徹底、サプライチェーン全体のセキュリティ監査の実施などが求められています。特に、サプライチェーン全体でのセキュリティ基準の統一と、インシデントが発生した際、迅速に対応ができる体制の構築が重要であると強調されています。

今回のアンケート調査の結果は、サプライチェーン全体でのセキュリティ意識の向上と、具体的な対策の実行が不可欠であることを示しています。

まとめ

クラウドサービスの利用が拡大する一方で、様々なセキュリティリスクが存在します。主な脅威としては、不正アクセス、サイバー攻撃、内部不正、設定や管理の不備が挙げられます。これらの脅威により、情報漏洩、情報改竄、システム停止といったリスクが生じる可能性があります。

クラウドサービスのセキュリティインシデントの例として、日本国内での具体的な事例が報告されています。例えば、総合IT企業では設定ミスにより93万5千人以上の個人情報が閲覧可能となっていたり、地方公共団体や自動車メーカーでは設定ミスにより申込者や顧客の個人情報が漏洩したりする事態が発生しています。

クラウドサービスのセキュリティインシデントの主な原因としては、クラウドサービス事業者のセキュリティ対策の不足や、利用者側のセキュリティ意識の欠如が指摘されています。セキュリティ対策の強化が急務であり、クラウドサービス提供者との連携強化、セキュリティ教育の徹底、サプライチェーン全体のセキュリティ監査の実施などが求められています。特に、サプライチェーン全体でのセキュリティ基準の統一と、インシデントが発生した際には、迅速な対応ができる体制の構築が重要です。

クラウド環境のセキュリティに不安はありませんか？

クラウド環境では、設定不備や権限管理の不備がセキュリティリスクにつながることがあります。BBSecでは、クラウド環境の設定状況を確認し、セキュリティ上のリスクを可視化する「クラウドセキュリティ設定診断」を提供しています。

公開日：2024年7月17日
更新日：2026年9月9日

編集責任：木下

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

イエローハットに不正アクセス、最大約180万人分の個人情報漏えいの可能性―企業が学ぶべき対策とは

Share
イエローハットに不正アクセス、最大約180万人の個人情報漏えいの可能性アイキャッチ画像

2026年8月、カー用品大手のイエローハットが運営する「イエローハットWEB作業予約システム」が不正アクセスを受け、最大約180万人分の個人情報が漏えいした可能性があることが公表されました。本記事では、イエローハットの公式発表をもとに事案の概要を整理するとともに、企業が同様の被害に備えるために見直しておきたいセキュリティ対策について解説します。

※本記事は2026年9月4日時点で確認できる公表資料に基づき作成しています。

イエローハットの不正アクセスで何が起きたのか

株式会社イエローハットは2026年8月28日、「イエローハットWEB作業予約システム」が不正プログラムによる攻撃を受け、一部会員の個人情報が外部へ漏えいした可能性が判明したと発表しました*5。漏えいの可能性がある対象者は最大1,801,499名で、対象情報は氏名、電話番号、メールアドレス、会員番号とされています。同社は8月18日朝に不正アクセスを検知し、直ちにシステムの外部接続を遮断するなどの緊急措置を実施しました。その後、影響範囲などの調査を進める過程で、一部の会員情報が外部へ漏えいした可能性があることが判明したとしています。

公表時点でシステム上の対策は完了しており、個人情報保護委員会への報告と警察への相談も行われました。一方、クレジットカード情報、パスワード、車両情報は当該システムで保持していないため、同社は、これらの情報の漏えいはないと説明しています。また、グループ他社は異なる独自の管理システムを利用しているため、他ブランド店舗の利用者への影響もないとしています。

現時点で原因や侵入経路は公表されていない

今回のイエローハットの不正アクセスについて、攻撃者、侵入経路、悪用された脆弱性、攻撃手法の詳細は、2026年8月28日の公式発表では明らかにされていません。「Webシステムの脆弱性が悪用された」「認証情報が突破された」「ランサムウェアによる攻撃だった」などと原因を推測することはできません。また、公表された1,801,499名は、個人情報の漏えいが確認された人数ではなく、漏えいした可能性がある対象者の最大人数です。同社は今後新たな事実が判明した場合には、ホームページで公表するとしています。

利用者が注意すべき二次被害

イエローハットは、対象となる会員に対し、電子メール、SMS、電話または書面で順次連絡するとしています。同時に、心当たりのないメールやSMSなどに注意し、メールの開封、不審なリンクへのアクセス、添付ファイルの開封を避けるよう呼びかけています。氏名や連絡先、会員番号を組み合わせると、実在する企業やサービスを装った連絡に説得力を持たせやすくなります。ただし、今回の情報が実際にフィッシング等へ悪用されたとの事実は公表されていません。利用者は不安をあおる連絡に反応せず、案内の真偽をイエローハットの公式サイトや公式窓口で確認することが重要です。

2りんかんの不正アクセスとは別事案

イエローハットグループでは、株式会社2りんかんイエローハットも2026年4月に会員専用サーバーへの不正アクセスを公表しています*2。6月19日の最終報では、アプリの仕組みであるAPIを悪用した不正アクセスにより、3,179,454名分の会員データが取得されたことが特定されました。

ただし、2りんかんの事案と今回のイエローハット本体の事案を同じ原因によるものとみなすことはできません。今回対象となった「WEB作業予約システム」はグループ他社とは異なる独自管理システムであり、攻撃者や原因の共通性も公表されていません。企業が注目すべきなのは、二つの事案を安易に結び付けることではなく、グループ内でインシデントが発生した際に、類似する公開システムや利用技術、委託先などに同様のリスクがないか横断的に点検することです。

Web予約システムがサイバー攻撃の対象になり得る理由

Web予約システムは、顧客がインターネットから利用できる利便性の高い窓口である一方、外部に常時公開されるシステムでもあります。予約受付だけでなく、会員情報との連携、通知、店舗側の管理機能など、複数のシステムや機能とつながっているケースもあります。また、氏名や電話番号、メールアドレスなどの個人情報を扱うことも多いため、不正アクセスを受けた場合には情報漏えいにつながる可能性があります。そのため、公開前のセキュリティ確認だけでなく、運用開始後も継続的にリスクを管理することが重要です。

企業が見直すべき5つのセキュリティ対策

公開しているIT資産を把握し、管理責任を明確にする

最初に必要なのは、自社とグループ会社がインターネット上に公開しているWebサイト、予約システム、API、クラウド環境などを洗い出すことです。古いキャンペーンサイトや管理部門が不明確なシステムが残っていれば、脆弱性情報の確認や修正が遅れる原因になります。資産ごとに管理責任者、使用技術、保守委託先、個人データの有無を整理し、不要な公開資産は閉鎖する必要があります。

WebアプリケーションとAPIを継続的に点検する

Webシステムは公開前に確認して終わりではありません。機能追加、設定変更、ミドルウェアやライブラリの更新によってリスクは変化します。IPAは、Webサイトの新規公開前や既存ページの変更時の確認に加え、構成するソフトウェアやCMSを把握し、最新状態を保つことを推奨しています。システムの重要度や変更頻度に応じて、定期的な脆弱性診断やセキュリティ点検を実施することが有効です。

ログを『保存するだけ』にせず、検知と調査に使える状態にする

不正アクセスを早期に捉え、発生後に原因や影響範囲を調べるには、アクセスログや認証ログなどが欠かせません。ただし、ログが分散したまま、確認する担当者やルールが決まっていなければ、異常の発見につながりません。監視対象、検知条件、通知先、保管期間、時刻同期、改ざん防止を定め、異常を検知した際に調査へ移れる運用を整備することが重要です。

保有する個人データを最小化し、アクセスを必要な範囲に絞る

攻撃を完全に防ぐことは困難ですが、侵害された場合の影響を抑えることはできます。予約や会員サービスに本当に必要なデータだけを取得し、保存期限を過ぎた情報を削除し、業務上必要な担当者だけがアクセスできるようにします。決済情報を外部の専用システムで扱うなど、重要な情報を分離する設計も被害範囲を限定するうえで有効です。なお、これは一般的な推奨策であり、今回の事案に過剰保有やアクセス制御の不備があったことを示すものではありません。

インシデント対応手順を整え、グループ横断で訓練する

不正アクセスを検知した直後は、遮断、証拠保全、影響範囲の特定、経営層への報告、外部専門家や関係機関との連携、顧客への説明を並行して進めなければなりません。平時から責任者と連絡網を決め、初動手順を文書化し、机上演習で判断の遅れや役割の抜けを確認しておくことが重要です。グループ企業で事案が発生した場合は、当該システムの復旧だけで終わらせず、他社・他サービスへ横展開して点検する仕組みも必要です。

公開システムのセキュリティ対策を見直すには

Web予約システムのセキュリティ対策では、脆弱性を見つけて修正する予防策、攻撃の兆候を早期に捉える監視、被害が疑われた際の初動対応を分断しないことが重要です。どれか一つを導入するだけでは、継続的に変化する公開システムのリスクには対応しきれません。

BBSecでは、公開システムの脆弱性診断から、セキュリティログの分析・監視、インシデント発生時の緊急対応・フォレンジック調査までと、「予防」・「検知」・「対応」の各段階を支援しています。自社やグループ会社の公開システムをどこから見直すべきか判断に迷う場合は、現在の対策状況を整理したうえで、各段階での不足部分を補うことが有効です。

まとめ

イエローハットの不正アクセスでは、WEB作業予約システムに保存されていた最大約180万人分の個人情報が漏えいした可能性が公表されました。現時点では侵入経路や具体的な攻撃手法は明らかにされていないため、今後の調査結果や追加発表を確認する必要があります。企業にとって重要なのは、こうした事案を一過性のニュースとして捉えるのではなく、自社の対策を見直す機会とすることです。公開IT資産の把握、WebアプリケーションやAPIの継続的な点検、ログ監視、個人データの適切な管理、インシデント対応体制の整備を一連の取り組みとして進めることが、被害の予防と早期収束につながります。

【参考情報】

編集責任：木下

BBSecの脆弱性診断・セキュリティ対策支援サービス

BBSec（ブロードバンドセキュリティ）では、WebアプリケーションやAPIの脆弱性診断をはじめ、セキュリティログの分析・監視、インシデント発生時の緊急対応・フォレンジック調査など、予防・検知・対応の各段階を支援しています。公開システムのセキュリティ対策や、情報漏えい・不正アクセスへの備えを見直したい場合は、お気軽にご相談ください。

ウェビナー開催のお知らせ

最新情報はこちら

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

AIセキュリティとは？生成AI時代に企業が知っておくべきリスクと対策

Share
AIセキュリティとは？生成AI時代に企業が知っておくべきリスクと対アイキャッチ画像策

生成AIの業務利用が広がる一方、情報漏洩や誤情報、著作権、AIシステムを狙った攻撃など、新たなリスクも生じています。本記事では、企業がAIを安全に活用するために押さえておきたい、AIセキュリティの主なリスクと対策を紹介します。

AIセキュリティについて、テーマ別に詳しく知りたい方はこちらもご覧ください。

AIセキュリティとは

AIセキュリティとは、AIの利用やAIを組み込んだシステムに伴うセキュリティ上のリスクを把握し、情報やシステム、業務を守るための取り組みです。企業におけるAI活用を考える際には、大きく二つの観点があります。

一つは、AIを利用することで生じるリスクです。従業員が生成AIに機密情報や個人情報を入力することによる情報漏洩、生成された誤情報の利用、著作権や知的財産に関する問題、企業が把握していないAIサービスを業務に利用する「シャドーAI」などが挙げられます。

もう一つは、AIシステムそのものに対するセキュリティリスクです。AIやLLM（大規模言語モデル）を組み込んだシステムでは、悪意のある指示によって意図しない動作を引き起こすプロンプトインジェクションをはじめ、機密情報の漏洩や不適切な権限の利用など、AI特有のリスクを考慮する必要があります。

生成AIやAIエージェントの普及により、AIは単に質問に回答するツールから、社内データを参照したり、外部のシステムやサービスと連携して処理を行ったりする存在へと用途を広げています。そのためAIセキュリティでは、従業員の利用ルールだけでなく、AIに接続するデータやシステム、付与する権限まで含めてリスクを捉えることが重要になります。

AIセキュリティが注目される背景

生成AIは、文章作成や要約、翻訳、情報収集、プログラミングなど幅広い業務で活用されています。また、既存の業務システムやWebサービスに生成AIを組み込むケースも増え、企業とAIとの接点は広がっています。

こうした活用の拡大に伴い、セキュリティ上の課題も顕在化しています。従業員が組織の許可を得ずに生成AIを利用するシャドーAIによる情報漏洩や、不正確な出力による業務への影響などは、その代表例です。

さらに、AIシステム自体が攻撃対象になることも考慮しなければなりません。従来のWebアプリケーションやクラウドサービスへのセキュリティ対策に加えて、AI・LLMの特性を悪用した攻撃への備えも必要になっています。

AIをめぐっては、国内外で安全性や透明性、適正な利用に関するルールやガイドラインの整備も進められています。企業には、技術的なセキュリティ対策だけでなく、こうした動向を踏まえてAIの利用方針や管理体制を継続的に見直すことも求められます。

従来のセキュリティ対策との違い

AIを利用する場合でも、アクセス制御や認証、脆弱性管理、ログ監視といった従来のセキュリティ対策が不要になるわけではありません。これらは引き続き重要な基盤となります。そのうえでAIセキュリティでは、AIへの入力、AIからの出力、AIが参照するデータ、AIに与える権限といった新たな要素についても対策を考える必要があります。

例えば、システムへのアクセス権限が適切に管理されていても、従業員が外部の生成AIサービスへ機密情報を入力すれば、別の経路から情報が外部へ渡る可能性があります。また、AIを組み込んだシステムでは、通常の操作では想定していなかった指示によってAIの動作が誘導される可能性もあります。

したがって、AIセキュリティでは従来のサイバーセキュリティを土台としながら、「AIをどのように利用するか」と「AIを組み込んだシステムをどのように守るか」の両面から対策を考えることがポイントとなります。

企業が注意すべき生成AIの主なリスク

生成AIは業務効率化や情報収集などに役立つ一方、使い方によっては情報漏洩や誤った判断につながる可能性があります。企業で利用する際には、どのような情報を入力するのか、生成された内容をどのように扱うのかといった観点からリスクを把握する必要があります。

機密情報・個人情報の漏洩

生成AIに顧客情報や社内の機密情報、個人情報などを入力すると、利用するサービスの仕様や設定によっては、入力した情報がサービス提供者側で保存・利用される可能性があります。業務で生成AIを利用する場合は、入力してよい情報と禁止する情報を明確にするとともに、利用するサービスのデータ取り扱い方針や設定を確認することが必要です。

誤情報・ハルシネーション

生成AIは、事実と異なる内容や、もっともらしい誤情報を生成することがあります。こうした現象は「ハルシネーション」と呼ばれます。

生成された文章や回答を十分に確認せず、社内資料や顧客への回答、意思決定などに利用すると、誤った情報が業務に影響を及ぼすおそれがあります。重要な情報については、信頼できる情報源と照合するなど、人による確認が欠かせません。

著作権・知的財産に関するリスク

生成AIでは、入力する情報と生成されたコンテンツの双方について、著作権や知的財産への配慮が必要です。第三者が権利を持つ文章や画像などを安易に入力したり、AIが生成したコンテンツを確認せずに公開・商用利用したりすると、権利上の問題につながる可能性があります。利用する生成AIサービスの規約を確認するとともに、生成物の利用方法に応じた確認体制を整えることが求められます。

シャドーAI

シャドーAIとは、組織が把握・管理していない生成AIサービスを従業員が業務で利用している状態を指します。企業が生成AIの利用を一律に禁止していても、従業員が個人アカウントなどを使って利用すれば、機密情報が管理外のサービスへ入力される可能性があります。そのため、単に利用を禁止するだけでなく、利用可能なAIサービスや用途を明確にし、組織として利用状況を把握できる環境を整えることが重要です。

生成AIの利用に伴うリスクや企業が取るべき対策については、「生成AIのリスクとは？企業利用で注意すべき情報漏洩・著作権・誤情報と対策」で詳しく紹介します。

AIを狙ったサイバー攻撃にも注意が必要

AIセキュリティで考えるべきなのは、従業員が生成AIを安全に利用するための対策だけではありません。AIやLLM（大規模言語モデル）を組み込んだシステムが普及することで、AIの仕組みや特性を悪用した攻撃への備えも必要になっています。

プロンプトインジェクション

プロンプトインジェクションは、攻撃者が悪意のある指示をAIに与えることで、本来想定されていない動作や出力を引き起こそうとする攻撃です。ユーザーが直接入力する指示だけでなく、AIが読み込むWebページや文書などに悪意のある指示を埋め込む「間接プロンプトインジェクション」にも注意が必要です。外部の情報を参照するAIや、他のシステムと連携して処理を行うAIでは、影響範囲が広がる可能性があります。

センシティブ情報の漏洩

AIを組み込んだシステムでは、モデルが参照できる情報やユーザーの入力内容などが、意図せず出力される可能性があります。特に、社内文書や顧客情報などをAIから参照できるようにしている場合には、利用者の権限に応じて参照可能な情報を制御するなど、AIだけに依存しないアクセス制御が必要です。

データやモデルへの不正な操作

AIの動作は、学習データや外部から取得する情報などの影響を受けます。攻撃者によってデータが意図的に操作されれば、AIの判断や出力が影響を受ける可能性があります。AIが参照するデータの信頼性を確認するとともに、データへのアクセスや変更を適切に管理することが求められます。

AIに与える権限にも注意

AIエージェントなど、AIが外部サービスや社内システムと連携して処理を実行する仕組みでは、AIにどこまでの権限を与えるかが重要になります。必要以上の権限を付与すると、AIが意図しない操作を行った場合や攻撃者に悪用された場合の影響が大きくなります。人のアカウントと同様に、AIについても必要最小限の権限を設定し、重要な処理には人による確認を組み合わせることが重要です。

OWASPが示すLLMアプリケーションのリスク

LLMを利用したアプリケーションには、従来のWebアプリケーションと共通するリスクに加え、プロンプトインジェクションをはじめとしたLLM特有のリスクがあります。

OWASPでは、LLMや生成AIアプリケーションで特に注意すべきセキュリティリスクを整理しています。AIを組み込んだサービスを開発・提供する企業では、こうしたリスクを踏まえて、設計・開発・運用の各段階で対策を検討する必要があります。

具体的な脅威と対策については、「LLMセキュリティとは？プロンプトインジェクションなどの脅威と対策」で詳しく紹介します。

AIセキュリティ対策は「利用」と「システム」の両面から考える

ここまで見てきたように、AIセキュリティには、従業員による生成AIの利用に伴うリスクと、AIを組み込んだシステムそのものに対するリスクがあります。そのため企業では、利用ルールの整備だけでなく、ガバナンスや技術的なセキュリティ対策を組み合わせて取り組むことが必要です。

AI利用ルールを整備する

まず、従業員がどのような条件でAIを利用できるのかを明確にします。利用可能なAIサービスや用途、入力してはいけない情報、生成物を利用する際の確認方法などを定め、従業員が判断に迷わないルールにすることが重要です。また、AIサービスや利用方法は変化するため、一度ルールを作成して終わりにせず、利用状況に応じて見直していく必要があります。

AIガバナンスの体制を整備する

AIの利用を個々の従業員や部門だけに任せるのではなく、組織として管理する仕組みも必要です。誰がAI利用を管理するのか、どのようにリスクを評価するのか、問題が発生した場合にどの部門が対応するのかなど、役割と責任を明確にします。

AI利用ガイドラインの策定方法や組織としての管理体制については、「AIガバナンスとは？企業に必要な体制とAI利用ガイドラインの作り方」で詳しく紹介します。

シャドーAIを把握・管理する

ルールを整備しても、組織が把握していないAIサービスが利用されていれば、リスクを十分に管理できません。どの部門でどのようなAIが利用されているかを把握し、必要に応じて利用サービスを承認制にするなど、実際の利用状況とルールを一致させる取り組みが必要です。

AIを組み込んだシステムのセキュリティを確認する

AIを利用したシステムを開発・導入する場合には、通常のアプリケーションと同様のセキュリティ対策に加えて、AI・LLM固有のリスクも確認します。入力・出力の検証、アクセス制御、権限管理、APIや外部サービスとの連携、ログの記録などを確認し、プロンプトインジェクションをはじめとする攻撃への対策も検討します。

継続的なセキュリティ対策の見直し

AIを取り巻くサービスや技術、攻撃手法は変化しています。現在安全と判断した利用方法や設定であっても、将来も同じとは限りません。AIの利用状況や新たな脅威を定期的に確認し、ガイドラインやシステム設定、セキュリティ対策を継続的に見直していくことが重要です。

企業はAIセキュリティ対策をどこから始めるべきか

AIセキュリティといっても、すべての対策を一度に導入する必要はありません。まずは自社でAIがどのように使われているかを把握し、リスクの高い領域から優先して対策を進めます。

STEP1　AIの利用状況を把握する
利用しているAIサービス、利用部門、用途、取り扱う情報などを整理します。
STEP2　扱う情報とリスクを整理する
機密情報や個人情報など、AIで扱う情報と想定されるリスクを確認します。
STEP3　AI利用ガイドラインを整備する
利用可能なサービスや用途、禁止事項、生成物の確認方法などを定めます。
STEP4　技術的なセキュリティ対策を実施する
AIを組み込んだシステムについて、アクセス制御や権限管理、入出力の検証、脆弱性への対策などを行います。
STEP5　継続的に評価・改善する
利用状況や新たなリスクを確認し、ルールと技術対策を定期的に見直します。

AIの利用を一律に禁止するのではなく、どこにリスクがあるのかを把握したうえで、業務上のメリットと安全性のバランスを取りながら活用していくことが重要です。

AIセキュリティに関するよくある質問

▼ AIセキュリティとは何ですか？
▼ 生成AIを業務で利用する場合、どのようなリスクがありますか？
▼ AI利用ガイドラインには何を定めればよいですか？
▼ LLMにはどのようなセキュリティリスクがありますか？

まとめ

生成AIの普及によって、企業がAIを業務やシステムに取り入れる機会は広がっています。それに伴い、情報漏洩や誤情報、著作権などの利用上のリスクだけでなく、プロンプトインジェクションをはじめとするAI・LLMを狙った攻撃についても考える必要があります。AIセキュリティでは、AIを安全に利用することとAIを組み込んだシステムを安全にすることの両面から対策を進めることがポイントです。まずは自社でどのようにAIが利用されているかを把握し、AI利用ガイドラインや管理体制を整備するとともに、AIを組み込んだシステムについてはアクセス制御や権限管理、入出力の検証など、技術的な対策も進めていきましょう。

AIを取り巻く技術や脅威は変化しています。利用を一律に制限するのではなく、リスクを継続的に把握・評価しながら、安全なAI活用につなげていくことが重要です。

参考情報

公開日：2025年4月16日
更新日：2026年8月26日

編集責任：木下

BBSecでは

AIの利用拡大に伴い、企業を取り巻くIT環境やセキュリティリスクも変化しています。公開IT資産の把握、脆弱性の確認、セキュリティ対策の有効性検証など、自社の課題に応じた対策をご相談ください。

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

Foxconnへのサイバー攻撃とは？製造委託先が狙われる理由とサプライチェーン対策

Share
「Foxconnへのサイバー攻撃とは？製造委託先が狙われる理由とサプライチェーン対策」アイキャッチ画像

2026年5月、電子機器の製造受託大手Foxconnの北米拠点がサイバー攻撃を受け、攻撃者は約8TBのデータを窃取したと主張しました。製造委託先には複数企業の設計・製造情報が集まるため、侵害の影響が取引先へ広がるおそれがあります。本記事では、製造委託先が狙われる理由と、企業が取るべきサプライチェーン対策を解説します。

Foxconnへのサイバー攻撃で何が起きたのか

2026年5月、電子機器の製造受託大手Foxconnは、北米の一部拠点がサイバー攻撃を受けたことを明らかにしました。Foxconnによると、影響を受けた工場では復旧対応が進められ、通常の生産体制へ段階的に戻っているとされています。

この攻撃について、ランサムウェア攻撃グループ「Nitrogen」は、約8TB、1,100万件を超えるファイルを窃取したと主張しました。窃取した情報には、Apple、Intel、Google、Dell、Nvidia、AMDなどの顧客企業に関係する情報が含まれるとも主張しています。

ただし、データ窃取の規模や内容、顧客企業に関する情報が実際に含まれていたかについて、Foxconnは詳細を公表していません。そのため、攻撃者側の主張とFoxconnが確認・公表している事実は分けて捉える必要があります。

なぜ製造委託先はサイバー攻撃の標的になりやすいのか

製造委託先が狙われやすい理由の一つは、発注元企業との間に多くの情報連携が発生するためです。製造委託企業には、設計図、部品表、製品仕様、検査手順、試作品情報、調達計画など、製品開発や量産に必要な情報が集約されることがあります。

攻撃者から見ると、こうした企業を侵害することで、発注元企業へ直接侵入しなくても、重要情報に近づける可能性があります。特に大企業はセキュリティ対策が強化されている一方で、委託先や再委託先まで同じ水準で管理されているとは限りません。攻撃者はこの「守りの差」を狙い、比較的侵入しやすい取引先を足がかりにすることがあります。

また、製造業では受発注システム、設計データ共有基盤、生産管理システム、保守対応の連絡経路など、複数企業をまたぐ業務連携が多く存在します。こうした接点が適切に管理されていない場合、侵害された委託先から関連企業へ芋づる式に影響が広がる可能性があります。

つまり、製造委託先は単なる外部企業ではなく、発注元企業の事業継続や情報保護に直結するサプライチェーンの一部として考える必要があります。

Foxconnでは過去にも被害が発生

なお、Foxconnとその関連企業では今回が初めての被害ではなく、過去にもサイバー攻撃による被害が報じられています。

2020年はDoppelPaymerによる攻撃、2022年には別のメキシコ拠点がLockBitの標的となりました。また2024年には子会社のFoxsemiconも攻撃を受けています。

世界各地に拠点や子会社を持つ企業では、組織全体で統一した対策を進めていても、拠点や関連会社によってセキュリティ対策や運用の水準に差が生じることがあります。攻撃者は、こうしたサプライチェーンやグループ企業内の接点を狙う可能性があります。

製造委託先の侵害がもたらす主なリスク

製造委託先が侵害された場合、影響は委託先単独の問題に留まりません。まず懸念されるのは、顧客企業に関係する情報の漏洩です。実際にFoxconnの事例では、攻撃者側が顧客企業の機密情報の窃取を主張しており(Foxconn側は詳細未公表)、こうした主張の真偽が確認される前から報道が先行する点も、企業にとって風評面のリスクとなり得ます。

設計情報や部品表、製造手順、製品仕様などが流出すれば、知的財産の漏洩、模倣品の製造、競争力の低下につながるおそれがあります。

また、製品やシステムの構成情報が外部に出ることで、攻撃者が弱点を分析しやすくなる可能性もあります。たとえば、使用している部品、ソフトウェア、通信仕様、検査工程などの情報が悪用されれば、将来的な攻撃の足がかりになることも考えられます。

さらに、ランサムウェア攻撃では、工場の操業停止や生産ラインの停止も大きなリスクです。製造委託先の業務が止まれば、発注元企業にとっても納期遅延、欠品、代替生産の調整、顧客説明などの対応が必要になります。

近年のランサムウェア攻撃では、システムを暗号化するだけでなく、事前にデータを窃取したうえで公開をちらつかせる「二重恐喝」も多く確認されています。そのため、バックアップからシステムを復旧できたとしても、窃取された情報の公開リスクが残ります。

ランサムウェアの二重恐喝の仕組みや、製造業のサプライチェーンに与える影響については、こちらの記事で詳しく解説しています。
「ランサムウェアの二重恐喝とは？製造業サプライチェーンに与える影響を解説」

製造委託先の侵害は、情報漏洩、知財リスク、操業停止、供給遅延、信用低下が同時に発生し得る、サプライチェーン全体のリスクとして捉えるべきです。

企業が取るべき対策

企業は、製造委託先を「外部の別会社」として扱うだけではなく、自社のサプライチェーンの一部として管理することが重要です。

委託先と共有する情報を最小限にする

まず実施すべきことは、委託先に渡す情報を必要最小限にすることです。設計データ、部品表、製造手順などの重要情報は、必要な範囲、期間、担当者に限定して共有する必要があります。

アクセス権限を分離する

次に、アクセス権限をプロジェクト単位で分離することが有効です。すべての担当者が広範な情報にアクセスできる状態では、侵害時の被害が拡大しやすくなります。プロジェクトごと、顧客ごと、工程ごとにアクセス範囲を分けることで、万一の侵害時にも影響範囲を抑えやすくなります。

委託先の対策状況を定期的に確認する

委託先のセキュリティ対策状況を定期的に確認することも重要です。ただし、すべての委託先に同じ水準の対策や監査を一律に求めるのではなく、委託する業務の重要度や、共有する情報の機密性に応じて確認内容を設定する必要があります。

たとえば、設計情報や顧客情報を扱う委託先、業務停止時に自社の生産や供給へ大きな影響を及ぼす委託先については、ランサムウェア対策、EDRなどの端末監視、バックアップ、ログ管理、脆弱性管理、インシデント対応体制を重点的に確認します。一方で、扱う情報や事業への影響が限定的な委託先については、確認項目を絞るなど、リスクに応じた管理が現実的です。

重要な委託先については、契約時の確認だけで終わらせず、取引期間中も定期的に対策状況を確認し、環境やリスクの変化に応じて見直すことが求められます。

情報漏洩とランサムウェアへの技術的対策を講じる

技術的な対策としては、DLPによるデータ持ち出し監視、アクセスログの分析、大量ダウンロードの検知、重要データの暗号化、バックアップの分離保管などが挙げられます。特にランサムウェア対策では、バックアップが攻撃者に同時に破壊・暗号化されないよう、オフライン保管や改ざん耐性のあるバックアップ設計を検討する必要があります。

契約と事業継続計画を整備する

契約面では、インシデント発生時の通知期限、調査協力、証拠保全、再委託先管理、損害範囲、データ削除義務を明確にしておくことが重要です。さらに、代替生産先、代替部品、重要データの社内保全を含め、サイバー攻撃を前提としたサプライチェーンBCPを整備する必要があります。

サイバー攻撃を想定したサプライチェーンBCPの考え方や、委託先管理で確認すべきポイントについては、こちらの記事で詳しく解説しています。
「サイバー攻撃に備えるサプライチェーンBCPとは？委託先管理の見直しポイントを解説」

まとめ

製造委託先は、複数の顧客企業に関わる設計情報や製造情報を扱うため、攻撃者にとって高価値な標的になり得ます。発注元企業のセキュリティ対策が強固であっても、委託先や再委託先に弱点があれば、そこを入口として情報漏洩や業務停止が発生する可能性があります。

製造業におけるサプライチェーンリスクは、自然災害や物流停止だけではありません。サイバー攻撃による情報漏洩、操業停止、供給遅延、二重恐喝も、事業継続に直結する重要なリスクです。 企業は、委託先への情報共有を最小限に抑え、アクセス権限を分離し、定期的なセキュリティ監査を行うことが求められます。加えて、契約面の見直しやサイバー攻撃を想定したBCPの整備を進めることで、サプライチェーン全体のレジリエンスを高めることが重要です。

【参考情報】（2026年8月時点）

編集責任：木下

BBSecの脆弱性診断・セキュリティ対策支援サービス

BBSec（ブロードバンドセキュリティ）では、Webアプリケーション診断、プラットフォーム診断、クラウド環境診断、脆弱性管理支援など、企業のセキュリティリスクを可視化する各種サービスを提供しています。外部サービスや委託先を含めたセキュリティ体制の見直し、情報漏えいリスクへの備え、インシデント発生前の予防対策を検討している企業は、ぜひご相談ください。

サイバーインシデント緊急対応

サイバーセキュリティ緊急対応電話受付ボタン
SQAT緊急対応バナー

ウェビナー開催のお知らせ

最新情報はこちら

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

さくらのレンタルサーバ不正アクセスが示す「管理環境」のリスク―583アカウントに不正ログイン

Share
さくらのレンタルサーバで不正アクセスアイキャッチ画像

2026年8月17日、さくらインターネットは「さくらのレンタルサーバ」の一部顧客環境への不正アクセスを公表しました。本記事では、同社や公的機関の一次情報をもとに、判明している事実や情報漏えいの可能性、利用企業が確認すべき対策を解説します。

※本記事は2026年8月17日時点で確認できる公表資料に基づき作成しています。

さくらインターネットへの不正アクセスで何が起きたのか

さくらインターネットの発表によると、同社は2026年8月9日、管理するサーバ環境で異常を検知し、調査を開始しました*3。その後、第三者が同社の管理環境を経由して、「さくらのレンタルサーバ」の一部顧客環境へ不正アクセスしていたことが判明しました。8月9日は攻撃開始日ではなく、異常を検知した日です。

8月17日の公表時点で、不正ログインの対象は583アカウントです。第三者が顧客アカウントからアクセスできる領域まで到達していたほか、一部のサーバにはマルウェアが設置されていました。また、一部の顧客情報を含む個人データが、第三者に閲覧または取得された可能性があるとされています。漏えいした可能性がある情報として挙げられているのは、「顧客領域内に保存された情報」と「利用者識別子」です。ただし、具体的な情報項目、対象人数、実際に取得されたデータの範囲は調査中です。

同社は認証情報の失効、アクセス遮断、マルウェアの除去、監視強化、外部専門機関を交えたフォレンジック調査を進めています。あわせて、データベースアップグレード機能、プラン変更、移行ツールなどの一部機能を制限しています。現時点では「さくらのVPS」「さくらのクラウド」「さくらの専用サーバ PHY」「高火力 PHY」への影響は確認されていませんが、その他のサービスを含めた調査は継続中です。

注目すべきは『管理環境を経由』した点

一般的なWebサイトの不正アクセスでは、更新されていないCMSやプラグイン、弱いパスワードなど、顧客側の環境が侵入口になるケースがあります。しかし今回の発表は、第三者がさくらインターネットの管理環境を経由して顧客環境へアクセスしたと説明しています。「管理環境」が具体的にどのシステムを指すのか、最初の侵入に脆弱性や窃取された認証情報が使われたのかは公表されていません。そのため、特定の製品やWordPressの脆弱性、ゼロデイ攻撃などと結び付ける根拠はありません。それでも、サービス提供者側の管理環境を経由し、複数の顧客アカウントへ影響が及んだ点は重要です。

さくらインターネットのサポート情報によれば、「さくらのレンタルサーバ」は複数の利用者が1台のサーバを共有する共用サーバとして運営されています*2。共用ホスティングでは、利用企業が自社サイトを適切に管理していても、サービス提供者側の管理層で発生した問題の影響を完全にコントロールすることはできません。これは「レンタルサーバだから危険」という話ではありません。自社ですべてのサーバを運用する場合にも、別の脆弱性や運用リスクがあります。重要なのは、外部サービスへ運用を委ねることで負担は軽減できても、情報管理やインシデント対応まで外部へ丸投げできるわけではないという点です。なお、「さくらのレンタルサーバ」は共用サーバとして提供されていますが、今回の不正アクセスと共用サーバという構成との因果関係は公表されていません。

583アカウントは「583人分の情報漏えい」ではない

今回さくらインターネットから公表された「583」という数字は、情報漏えいが確認された人数ではなく、不正ログインが判明したアカウント数です。また、「被害申告が確認されていない」ことと「改ざんがなかったことが確認された」ことは区別して捉える必要があります。現段階では、不正ログインとマルウェアの設置は確認済みである一方、個々の顧客環境で何が閲覧、取得、変更されたのかを調べている途中だと捉えるのが適切でしょう。

「通信の秘密」に該当する情報とは

さくらインターネットは、攻撃者が顧客情報だけでなく、「通信の秘密」に該当する情報へアクセスできる状態にあったと説明しています。通信の秘密は、メール本文などの通信内容だけを意味するものではありません。

個人情報保護委員会と総務省の「電気通信事業における個人情報等の保護に関するガイドライン」では、通信当事者の住所や氏名、発受信場所、通信年月日、通信回数、通信の存在自体に関する情報も含まれるとされています。ただし、今回どの情報が実際に閲覧・取得されたのかは公表されておらず、具体的な影響範囲は調査中です。さくらインターネットは、総務省や個人情報保護委員会などの関係機関への報告・情報共有を行うとともに、影響の可能性がある顧客への個別通知を開始しています。

レンタルサーバの侵害が企業へ及ぼす影響

企業が利用するレンタルサーバには、WebサイトのHTMLファイルや画像だけが置かれているとは限りません。問い合わせフォームから取得した情報、会員データ、データベース、業務用メールなどが保存されている場合があります。アプリケーションの設定ファイルに、データベースや外部クラウドサービスへ接続するための認証情報が記録されているケースもあります。

さくらインターネットの公式マニュアルでは、サーバーコントロールパネルへ管理者権限でログインした場合、そのレンタルサーバで行えるすべての操作に加え、作成された全メールアドレスの受信メール閲覧や設定変更などが可能と説明されています*3。ただし、今回不正ログインされた583アカウントが、この管理者権限を持つアカウントに該当するかは公表されていません。ここで重要なのは、実際の被害を先回りして断定することではなく、自社がサーバ上に何を保存し、どのシステムと接続しているかを把握しておくことです。

Webサイトが停止・改ざんされれば、情報発信や問い合わせ受付、ECサイトの販売などに影響します。仮にメールアカウントなどが不正利用された場合には、なりすましメールやフィッシング、取引先への攻撃に悪用されるおそれもあります。外部サービス上の一つのアカウントが、社内外の複数システムをつなぐ接点になっていないかを確認する必要があります。

相次ぐサービス提供者側の不正アクセス

サービス提供者側のシステムが侵害され、利用企業やその顧客へ影響が波及した事例は、今回が初めてではありません。

2025年には、インターネットイニシアティブ（IIJ）の法人向けメールセキュリティサービス「IIJセキュアMXサービス」が、第三者製ソフトウェアの当時未発見だった脆弱性を悪用した不正アクセスを受けました。そして2026年には、KDDIがISP事業者向けに提供していたメールシステムでも、第三者製ソフトウェアの未知の脆弱性を悪用した不正アクセスが発生し、メールアドレスやパスワードなどの漏えいが確認されています。

IIJやKDDIの事案と、今回のさくらインターネットへの不正アクセスが同じ原因や攻撃手法によるものだと示す情報はありません。一方、サービス提供者のシステムが侵害された場合、その影響がサービスを利用する複数の組織へ広がり得る点は共通しています。

IPA「情報セキュリティ10大脅威 2026」でも、「サプライチェーンや委託先を狙った攻撃」は組織向け脅威の2位となっています。ただし、今回の侵入原因や攻撃者の目的は判明しておらず、本件をサプライチェーン攻撃と断定することはできません。「委託先やITサービスを通じて自社へ影響が及ぶリスク」を考えるための事例として捉えるのが適切です。

さくらのレンタルサーバ利用者が確認すべきこと

今回の事案を受けて確認すること

さくらインターネットは利用者に対し、身に覚えのないファイルや管理者アカウントが追加されていないか、Webサイトやアプリケーションに不審な変更がないか、心当たりのないログインやメール送信が発生していないかを確認するよう求めています。確認の際は、現在表示されているWebサイトだけを見て「異常なし」と判断するのではなく、サーバーコントロールパネルのログイン履歴、取得できる範囲の接続・メール送信ログ、ファイルの更新日時なども確認します。身に覚えのないファイルや不審な通信を発見した場合は、調査に必要な記録を残したうえで、さくらインターネットやセキュリティの専門家へ相談することが重要です。

なお、2026年8月17日時点では、全利用者に対する一律のパスワード変更は求められていません。さくらインターネットは、パスワード変更などの追加対応が必要と判明した場合、対象者へ個別に案内するとしています。個別通知を受けた場合はその指示に従い、同じパスワードを他のサービスでも使用している場合は、該当サービスのパスワードも変更する必要があります。

平時から備えておくこと

平時の対策としては、サーバーコントロールパネルとWebメールの二要素認証を有効にし、管理者権限を必要な担当者だけに限定することが有効です。ただし、今回のようにサービス提供者の管理環境を経由した不正アクセスでは、利用者側の二要素認証だけですべてのリスクを防げるとは限りません。今回の侵入を二要素認証で防げたとする情報も公表されていないため、一般的なアカウント乗っ取り対策として捉える必要があります。また、Webサイト、データベース、メール、設定ファイルなど、サーバ上に保存している情報を定期的に棚卸しし、漏えいした場合の影響を把握しておくことも重要です。あわせて、復旧に必要なデータは同じサービス内だけに保存せず、別の媒体や環境にもバックアップを保持します。

IPAの「日常における情報セキュリティ対策」では、データを3つ持ち、2種類の異なる媒体でバックアップし、そのうち1つは異なる場所（オフサイト）で保管する「321ルール」を紹介しています。

外部へ委託しても自社のリスク管理は必要

レンタルサーバやクラウドサービスを利用する目的の一つは、専門事業者へ運用を任せ、自社の負担を軽減することです。しかし、サービス上で扱う情報の種類や重要度を決めるのは利用企業であり、インシデント発生時には、利用企業側にも顧客や取引先への説明・対応が求められる場合があります。サービスを選ぶ際は、料金や容量、表示速度だけでなく、取得できるログ、バックアップの保存場所、障害・不正アクセス時の連絡方法、調査への協力範囲、データの返却・削除方法なども確認しておく必要があります。特に、Webサイトやメールが事業継続に直結する企業では、サービス停止や情報漏えいを想定した連絡体制と復旧手順を、委託先と共有しておくことが重要です。

IPAが進める「サプライチェーン強化に向けたセキュリティ対策評価制度」でも、ITサービスを含む委託先への攻撃を起点としたサービス停止、機密情報の漏えい、改ざん、踏み台化などがリスクとして挙げられています。委託先のセキュリティを確認することは、自社の事業を守るためのリスク管理です。

さくらのレンタルサーバ不正アクセスに関するFAQ

▼ 自分のアカウントが対象か確認する方法は？
▼ パスワード変更は必要ですか？
▼ どの情報が漏えいした可能性がありますか？

まとめ

今回のさくらインターネットへの不正アクセスでは、583アカウントへの不正ログインや一部サーバへのマルウェア設置が確認され、顧客領域に保存された情報などが第三者に閲覧・取得された可能性も公表されています。一方、侵入経路や攻撃の開始時期、実際に取得された情報の範囲などは、現時点では調査中です。今回注目すべきなのは、被害の数字だけでなく、サービス提供者の管理環境を経由して複数の顧客環境へ不正アクセスが行われた点です。利用企業は公式情報を継続的に確認するとともに、自社環境に不審な変更がないかを点検し、サーバ上に保存している情報や外部システムとの接続関係を把握しておく必要があります。 外部サービスを利用していても、自社の情報や事業へのリスクがなくなるわけではありません。本件を、自社のセキュリティ対策だけでなく、委託先やITサービスを含めたリスク管理を見直す機会とすることが重要です。

参考情報

編集責任：木下

BBSecの脆弱性診断・セキュリティ対策支援サービス

BBSec（ブロードバンドセキュリティ）では、Webアプリケーション診断、プラットフォーム診断、クラウド環境診断、脆弱性管理支援など、企業のセキュリティリスクを可視化する各種サービスを提供しています。外部サービスや委託先を含めたセキュリティ体制の見直し、情報漏えいリスクへの備え、インシデント発生前の予防対策を検討している企業は、ぜひご相談ください。

ウェビナー開催のお知らせ

  • 2026年8月26日（水）「AI時代に見直すセキュリティ対策 ～ASMの考え方で始める攻撃対象領域の可視化とリスク対策～」

    • 最新情報はこちら

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    投稿日:

    ニチレイへのサイバー攻撃で何が起きた？ RansomHouseの主張と情報漏えいの可能性・供給網への影響

    Share
    「ニチレイへのサイバー攻撃で何が起きた？RansomHouseの主張と情報漏えいの可能性・供給網への影響」アイキャッチ画像

    2026年7月13日、ニチレイは不正アクセスによるシステム障害を公表しました。影響は冷蔵倉庫の入出庫や冷凍食品の出荷に及び、7月24日に全拠点が通常稼働へ移行しました。その後、RansomHouseを名乗るグループによる犯行声明や、20万件以上のファイル公開が報じられています。本記事では、その後に明らかになった情報を踏まえ、公式発表で確認できる事実と攻撃者側の主張、第三者の観測を分けて整理し、食品・物流サプライチェーンへの影響と企業に求められる備えを解説します。

    ニチレイが公式に確認したのは、サーバーへのサイバー攻撃、システム障害に伴う入出庫・出荷業務への影響、被害サーバーの一部に個人情報が保管されていたことです。一方、RansomHouseの関与、ランサムウェアによる暗号化、公開ファイルの真正性、情報漏えいの対象人数と範囲、侵入経路は、2026年8月13日時点で公式に確定していません。

    ※本記事は2026年8月13日時点で確認できる公表資料に基づき作成しています。RansomHouseの主張と20万件報道は、公式発表と混同しないよう補足情報として区分しています。

    7月31日時点の公式発表に基づく経緯や、業務再開までの対応、BCPの観点はこちらの記事で解説しています。
    前回記事（速報版）　：「ニチレイへのサイバー攻撃で食品物流に影響―業務再開までの経緯と企業が見直すべきBCP」

    ニチレイへのサイバー攻撃で何が起きたのか

    今回のニチレイへのサイバー攻撃は、情報システムだけの障害ではありませんでした。冷蔵倉庫の入出庫や冷凍食品の出荷が止まり、モノの流れそのものに影響が及んだ点が特徴です。食品物流は、保管温度や納品時間が厳しく管理される業務です。受発注や在庫、倉庫作業を支えるシステムが使えなくなれば、倉庫に商品があっても通常どおりに動かせない状況が起こり得ます。

    ニチレイは障害発生当日に緊急対策本部を設置し、個人情報や顧客データの保護を優先してグループ内システムを遮断しました。遮断は被害拡大を防ぐために重要な措置ですが、その判断によって業務への影響が表面化することもあります。サイバーインシデントでは、「止めないこと」と「安全を確認できない状態で動かさないこと」の間で、経営判断が求められます。

    ニチレイのサイバー攻撃を時系列で整理

    7月13日～24日：サイバー攻撃の確認から通常稼働への移行

    ニチレイは7月13日、不正アクセスによるシステム障害が発生したと発表しました。7月15日には自社サーバーへのサイバー攻撃を確認し、被害サーバーの一部に個人情報が保管されていたことから、個人情報保護委員会へ漏えいの可能性がある事案として速報しています。その後、7月17日から一部制限のもとで業務を順次再開し、7月24日には受発注制限を解除。影響を受けた全拠点が平常時の通常稼働へ移行しました。

    ※発生から業務再開までの詳しい経緯は、前回の速報版で解説しています。

    8月7日：業績への影響を公表

    8月7日の2026年12月期第1四半期決算説明資料（決算期変更に伴う変則決算）で、ニチレイはシステム障害による売上面のマイナス影響を最大50億円、営業利益への影響を8億円と見込み、緊急対応で発生したコストや今後見込まれる損失として特別損失10億円を織り込みました。金額の意味が異なるため、これらを単純に合算して「被害総額」とみなすことはできません。

    8月10日：「20万件以上」のファイル公開が報じられる

    8月10日、テレビ朝日ANNニュースはS&Jの観測として、RansomHouseを名乗るグループが少なくとも20万件以上のファイルを公開し、個人情報も含まれているとみられると報じました*4。ニチレイは追加で情報が公開されていることを把握しているものの、コメントを差し控えると回答したとされています。なお、8月13日時点で、ニチレイの公式サイトには第5報以降、漏えい範囲や対象人数を確定する追加発表は掲載されていません。

    ニチレイから個人情報は漏えいしたのか

    結論からいえば、ニチレイは「個人情報の漏えいの可能性」を公表していますが、実際に社外へ流出した情報の項目や対象人数、件数は明らかにしていません。公式に確認できるのは、被害サーバーの一部に個人情報が保管されていたこと、個人情報保護委員会へ報告したこと、対象者へ通知したことまでです。この対象者への通知が行われたこと自体も、個人情報の社外流出が確定したことを意味するものではありません。

    個人情報保護法では、不正アクセスなどによる個人データの漏えいが発生した場合だけでなく、発生したおそれがある場合にも、一定の要件のもとで個人情報保護委員会への報告と本人通知が必要になります*2。したがって、「個人情報保護委員会へ報告した」という事実だけで、漏えいが確定したとは判断できません。調査が進むにつれて公表内容が更新されることもあるため、初報だけで結論づけず、続報を追う必要があります。

    「20万件以上」は20万人分の個人情報ではない

    報道で使われた「20万件以上」は、文書や画像、フォルダー内のデータなどを含むファイル数です。1人に複数のファイルがひもづく場合もあれば、個人情報を含まない業務資料が数えられている可能性もあります。反対に、1つのファイルに複数人の情報が含まれる可能性もあります。そのため、ファイル数から被害人数を換算することはできません。さらに、公開されたとされるファイルのすべてがニチレイから窃取された真正なデータなのか、S&Jがどの範囲を確認したのかについて、ニチレイによる公式な検証結果は出ていません。

    RansomHouseとは？ニチレイへの犯行は確認されたのか

    RansomHouseは、被害組織からデータを窃取し、公開をちらつかせて金銭を要求する恐喝活動で知られるグループです。パロアルトネットワークスのUnit 42は、RansomHouseをRansomware as a Service（RaaS）として分析し、データ窃取と暗号化を組み合わせる二重脅迫、ESXi環境を狙う管理ツール「MrAgent」と暗号化ツール「Mario」の利用を報告しています*3。

    ただし、これはRansomHouse一般の活動に関する技術分析です。ニチレイの環境でMrAgentやMarioが使われたこと、サーバーやファイルが暗号化されたことを示すものではありません。RansomHouseを名乗るグループは犯行を主張していますが、ニチレイは攻撃主体を公式に特定しておらず、侵入経路や攻撃手法も公表していません。

    サイバー攻撃は食品・物流サプライチェーンへどう波及したか

    ニチレイの事例で見落とせないのは、被害が自社のサーバー内にとどまらず、商品の保管と配送を待つ取引先や、その先の店舗運営へ波及し得ることです。食品物流は、多数の荷主、倉庫、輸配送会社、小売・外食企業をつなぐ共通基盤です。中核となる事業者の機能が止まれば、取引先自身のシステムが侵害されていなくても、商品を受け取れないという形で事業が止まります。

    同時期、日本ケンタッキー・フライド・チキン株式会社（以降KFC）も、食材配送を委託する物流会社で発生した不正アクセス起因のシステム障害により、商品の一部品切れ、販売メニューの制限、営業時間の短縮などが生じたと公表しました*4。7月22日には全店舗への食材納品体制が整い、通常営業へ戻っています。KFCは物流委託先の社名を公表していないため、ニチレイの事案との関係を公式情報だけで断定することはできません。一方、この事例は、物流委託先のシステム障害が消費者向けサービスにまで波及し得る構造を示しています。

    「サプライチェーン攻撃」と「サプライチェーンへの影響」は別物

    ここで用語を分けて考える必要があります。サプライチェーン攻撃は一般に、取引先や委託先、利用するソフトウェアやサービスを足がかりとして標的へ侵入する攻撃を指します。今回、ニチレイへの侵入経路は公表されていないため、攻撃経路という意味でサプライチェーン攻撃だったとは断定できません。

    一方で、サイバー攻撃による業務停止が供給網の先へ広がる「サプライチェーンリスク」は明確に表面化しました。侵入経路の問題と、事業依存関係による影響の連鎖は別の論点です。この二つを混同しないことが、ニュースを正確に読み、自社の対策へ落とし込む第一歩になります。

    ニチレイが公表した業績への影響

    ニチレイの2026年12月期第1四半期決算説明資料では、事業停止に伴う売上面のマイナス影響を最大50億円と見込んでいます。内訳は食品事業が20億円、低温物流事業が30億円です。営業利益への影響は8億円で、食品事業2億円、低温物流事業4億円、持株会社のシステム対応費用2億円とされています。さらに、緊急対応で発生したコストと今後発生が見込まれる損失として、10億円の特別損失を織り込みました。

    ※ニチレイが公表した売上への影響、営業利益への影響、特別損失は、それぞれ意味の異なる数字です。これらを単純に合算して「サイバー攻撃による被害総額」とみなすことはできません。

    親会社株主に帰属する当期純利益の予想は252億円から204億円へ48億円下方修正されましたが、この48億円すべてがサイバー攻撃による損失ではありません。中東情勢によるコスト増や食品・物流事業の進捗など、複数の要因が含まれています。なお、連結売上高の通期予想自体は海外事業の伸長を反映して上方修正されています。

    企業が学ぶべきサイバー攻撃対策

    重要業務と外部依存を、システム単位ではなく事業単位で洗い出す

    まず必要なのは、どのシステムが止まると、どの業務、取引先、商品、売上に影響するのかを平時に把握することです。自社システムの一覧だけでは足りません。物流、決済、クラウド、保守会社、受発注先など、重要業務を支える外部依存まで含め、許容停止時間と代替手段を整理します。委託先が止まった場合の連絡順序、手作業へ切り替えられる範囲、代替事業者の有無も、BCPとインシデント対応計画の両方で確認しておく必要があります。

    また、インシデント対応訓練では自社がサイバー攻撃を受けるケースだけでなく、物流会社やクラウドサービス、主要な仕入先など、重要な委託先・取引先のシステムが停止するケースも想定することが重要です。自社システムが正常でも外部サービスが利用できない状況で、どこまで業務を継続できるのかを確認しておく必要があります。

    「業務復旧」と「情報漏えい対応」を別の時計で管理する

    ニチレイは7月24日に通常稼働へ移行しましたが、その後もダークウェブ上でのデータ公開が報じられました。ここから分かるのは、システム復旧の完了と、情報漏えい調査の完了は一致しないということです。前者は業務を安全に再開できるかという可用性の問題、後者は何が持ち出され、誰にどのような影響があるかという機密性と法令対応の問題です。復旧宣言後も、フォレンジック調査、漏えい範囲の特定、本人通知、二次被害の監視、対外説明を継続できる体制が欠かせません。

    遮断・復旧・証拠保全を同時に進められる初動体制をつくる

    攻撃を疑った場合は、インシデント対応責任者や専門家の判断のもと、必要に応じて感染が疑われる端末やサーバーをネットワークから隔離し、被害拡大を抑える必要があります。一方、電源断や安易な初期化によって調査に必要な証拠を失うおそれもあります。誰が遮断を判断し、どのログを保存し、外部の専門会社や警察、監督機関へいつ連絡するのかを事前に決め、机上訓練で確かめておくことが重要です。

    経済産業省・独立行政法人情報処理推進機構（IPA）の「サイバーセキュリティ経営ガイドライン Ver3.0 実践のためのプラクティス集 第4版」でも、インシデント発生に備えた体制構築とサプライチェーン全体での対策を経営課題として位置づけています。

    バックアップは取得だけでなく、隔離と復旧テストまで行う

    ランサムウェアを含む破壊的な攻撃に備えるには、バックアップを本番環境と同じ認証基盤やネットワークに置き続けないことが重要です。実際に戻せるかを定期的に試し、復旧に必要な時間が事業側の許容範囲に収まるかまで確認して、初めてBCPとして機能します。

    よくある質問

    ▼ ニチレイへの攻撃はランサムウェアだったのですか？
    ▼ 20万件とは20万人分の個人情報ですか？
    ▼ 個人情報の漏えいは確定していますか？
    ▼ ニチレイのシステムと業務は復旧していますか？
    ▼ 今回の事案はサプライチェーン攻撃ですか？

    まとめ―復旧の速さだけでは測れないサイバー攻撃の損失

    ニチレイへのサイバー攻撃は、冷蔵倉庫と冷凍食品出荷の停止、取引先への影響、個人情報漏えいの可能性、財務損失という複数の問題を同時に突きつけました。全拠点が通常稼働へ戻った後にデータ公開が報じられた経緯は、事業継続と情報保護を別々に備える必要性を示しています。

    企業が見るべきなのは、自社への侵入を防げるかだけではありません。重要な委託先が止まったときに業務を続けられるか、攻撃を検知した直後に安全に遮断できるか、バックアップから所定時間内に戻せるか、漏えい調査と対外説明を長期にわたって続けられるかまでが、現在のサイバー攻撃対策です。平時のうちに外部専門会社との連絡経路や調査体制を整え、実際のシナリオで検証しておくことが、被害の大きさを左右します。漏えい調査と対外説明を長期にわたって続けられるかまでを想定することが、現在のサイバーリスク対策には求められます。

    参考情報

    編集責任：木下

    BBSecの脆弱性診断・セキュリティ対策支援サービス

    BBSec（ブロードバンドセキュリティ）では、Webアプリケーション診断、プラットフォーム診断、クラウド環境診断、脆弱性管理支援など、企業のセキュリティリスクを可視化する各種サービスを提供しています。外部サービスや委託先を含めたセキュリティ体制の見直し、情報漏えいリスクへの備え、インシデント発生前の予防対策を検討している企業は、ぜひご相談ください。

    ウェビナー開催のお知らせ

  • 2026年8月19日（水）14:00～15:00「セキュリティ対策の有効性を検証する ―ペネトレーションテストの実施ポイントと脆弱性診断との違い―」
  • 2026年8月26日（水）「AI時代に見直すセキュリティ対策 ～ASMの考え方で始める攻撃対象領域の可視化とリスク対策～」

    • 最新情報はこちら

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    投稿日:

    ニチレイへのサイバー攻撃で食品物流に影響―業務再開までの経緯と企業が見直すべきBCP

    Share
    ニチレイへのサイバー攻撃で食品物流に影響アイキャッチ画像

    2026年7月、ニチレイがサイバー攻撃を受け、冷蔵倉庫の入出庫業務や冷凍食品の出荷業務に影響が生じました。同社は被害拡大を防ぐためグループのシステムを遮断し、一部制限のもとで業務を順次再開。7月24日には、影響を受けた業務が通常稼働へ移行しました。本事案は、サイバー攻撃が情報漏えいだけでなく、物流や取引先を含む事業継続にも影響を及ぼすことを示しています。本記事では、公式発表に基づいて対応の経緯を整理し、企業が見直すべきBCPについて解説します。

    ※本記事は2026年7月31日時点で確認できる公表資料に基づき作成しています。公表されていない製品名、CVE番号、攻撃者、侵入手法の詳細については推測を加えずに構成しています。

    ニチレイへのサイバー攻撃とは

    2026年7月13日、株式会社ニチレイは不正アクセスによるシステム障害が発生したと公表しました*5。影響が出たのは、ニチレイロジグループ各社の冷蔵倉庫における入出庫業務と、ニチレイフーズの冷凍食品出荷業務です。同社は発生当日に緊急対策本部を立ち上げるとともに、お客さまや取引先の個人情報・顧客データなどの保護を最優先し、グループで使用するシステムの遮断措置を講じたことを、2日後の第2報*2で明らかにしています。その後、7月17日から一部制限のもとで業務を順次再開し、7月24日には、影響を受けた入出庫業務と冷凍食品出荷業務の受発注制限を解除して、全拠点を平常時の通常稼働へ移行しています。

    この事案が示したのは、サイバー攻撃の被害が情報漏えいだけにとどまらないことです。攻撃を受けた疑いが生じれば、被害拡大を防ぐためにシステムを止める判断が必要になる場合があります。受発注、在庫管理、倉庫の入出庫、出荷といった業務がITでつながる現在、封じ込め措置そのものが事業停止リスクを伴います。本件からは、侵入を防ぐ対策だけでなく、システムを遮断した後も業務を継続し、段階的に復旧する計画が欠かせないことが分かります。サイバーセキュリティ対策とBCPは、一体で検討すべき課題です。

    7月13日から24日まで―公式発表で追う対応と復旧

    7月13日：不正アクセスによるシステム障害を公表

    ニチレイは7月13日、不正アクセスによるシステム障害が同日に発生したと発表しました。第1報の時点では、個人情報や顧客データが社外へ流出した事実は確認されていないとしていました。一方、冷蔵倉庫の入出庫業務と冷凍食品の出荷業務にはすでに影響が生じており、障害の範囲は公表時点で日本国内に限られると説明しています。

    ここで注意したいのは、7月13日が「攻撃者の侵入日」と確認されたわけではない点です。公式発表から断定できるのは、不正アクセスによるシステム障害が7月13日に発生し、同日公表されたことまでです。攻撃者が最初に侵入した日時や、不正アクセスを検知した正確な時刻・契機は明らかにされていません。

    7月15日：サイバー攻撃を確認、個人情報漏えいの可能性を報告

    7月15日の第2報で、ニチレイは調査の結果、自社サーバがサイバー攻撃を受けたことを確認したと発表しました。さらなる被害拡大を防ぐため、攻撃の詳細は非開示としています。また、被害を受けたサーバの一部に個人情報が保管されていたため、個人情報保護委員会へ「漏えいの可能性がある事案」として第一報を行いました。

    同社は発生当日の7月13日にグループで使用するシステムを遮断しており、この遮断措置に伴って冷蔵倉庫の入出庫と冷凍食品出荷に影響が生じたと説明しています。なお、7月16日付のIR情報では、連結業績への影響は精査中とされ、重要な影響が判明した場合は速やかに開示すると説明しています。

    7月17日：受発注を制限しながら部分稼働

    7月17日、ニチレイは外部のセキュリティ専門会社の支援のもと、影響を受けた業務を順次再開しました。ただし、直ちに平常運転へ戻ったわけではなく、顧客や取引先からの受発注を一部制限し、冷蔵倉庫と食品工場を部分稼働させる形での再開でした。この段階でも、原因と影響範囲は調査中とされていました。

    7月22日から24日：対象者への通知と通常稼働への移行

    7月22日の第4報*3では、外部のセキュリティ専門会社に加え、警察および関係機関と連携して対応していることが公表されました。被害サーバの一部に個人情報が保管されていたため、対象者へ別途通知を行っていることも明らかにされています。

    7月24日、ニチレイは受発注制限を解除し、影響を受けていた入出庫業務と冷凍食品出荷業務について、全拠点が平常時の通常稼働へ移行したと発表しました。ただし、これは影響業務の通常稼働への移行を示すものであり、原因調査や影響範囲の特定まで完了したことを意味するものではありません。

    なぜ食品サプライチェーンへの影響が注目されたのか

    ニチレイが2026年5月12日に公開した「事業概要説明資料」によると、同社の低温物流事業は全国75カ所に冷蔵倉庫を保有し、冷蔵倉庫の保管能力で国内1位です。さらに、ニチレイグループ外の取扱比率が90％を超えるとされています。今回、75カ所すべてに同じ程度の支障が生じたと公表されているわけではありません。ただし、この事業構造から、低温物流業務の中断がニチレイグループ以外の荷主にも波及し得ることが分かります。

    実際、ミールキット宅配サービスのヨシケイは7月27日、ニチレイグループのシステム障害により倉庫からの商品出庫に支障が生じ、一部エリアで代替品や代替食材を届ける場合があると公表しました*4。ニチレイは7月24日に影響業務の通常稼働への移行を発表していますが、自社の業務が再開しても、取引先側では在庫調整や代替品の手配などが続く場合があります。ヨシケイの発表は、障害の影響が取引先の商品供給にまで波及したことを示す事例といえます。

    なお、サイバー攻撃の影響が取引先へ波及したことと、取引先などを侵入経路とする「サプライチェーン攻撃」は区別する必要があります。ニチレイは侵入経路を公表していないため、本件をサプライチェーン攻撃と分類することはできません。一方、業務停止の影響が取引関係を通じて広がるリスクは、物流や食品製造だけでなく、決済、医療、クラウドサービスなどにも共通します。

    個人情報は漏えいしたのか

    2026年7月31日時点で、ニチレイは個人情報の漏えいを確定したとは発表していません。公表されているのは、被害サーバの一部に個人情報が保管されていたこと、漏えいの可能性がある事案として個人情報保護委員会へ第一報を行ったこと、対象者へ別途通知したことです。

    個人情報保護委員会は、不正の目的をもって行われたおそれがある個人データの漏えい等について、実際の漏えいが確定した場合だけでなく、それがある段階も報告対象になると示しています*5。このため、個人情報保護委員会への報告が行われたことだけをもって、外部流出が確定したとは判断できません。

    対象人数、顧客・従業員などの属性、情報項目、持ち出しの有無、不正利用の有無も公表されていません。したがって、現段階で「顧客情報が流出した」「大規模な個人情報漏えいが起きた」と書くのは不正確です。新たな公式発表が出た場合は、漏えいの事実、対象範囲、二次被害の有無を分けて確認する必要があります。

    ランサムウェア攻撃だったのか

    ニチレイは、攻撃手法、侵入経路、悪用された脆弱性、マルウェアの種類、データ暗号化や身代金要求の有無、攻撃者について公表していません。このため、本件をランサムウェア攻撃、ゼロデイ攻撃、あるいは特定の攻撃グループによる犯行と断定できる公式情報はありません。

    攻撃者を名乗る第三者の主張が報じられた場合でも、それだけで攻撃手法や犯行主体が確定するわけではありません。本記事では、ニチレイまたは捜査機関が確認した情報と、外部からの未検証の主張を区別して扱います。

    ニチレイの事例から企業が見直すべきサイバー攻撃対策

    重要業務とシステムの依存関係を可視化する

    対策の出発点となるのは、止まると事業や顧客に大きな影響が出る業務を特定し、それを支えるシステム、データ、拠点、委託先を対応付けることです。受発注システムだけを復旧しても、在庫情報、倉庫作業、輸配送との連携が戻らなければ商品は届きません。業務影響分析（BIA）を用いて復旧の優先順位を整理し、目標復旧時間（RTO）や目標復旧時点（RPO）に加え、システム停止中も最低限維持すべき業務とその水準を、IT部門と現場部門で共有しておくことが有効です。

    多層防御によって被害範囲を限定する

    ニチレイは侵入経路や攻撃手法を公表していないため、本件の原因に特定の対策不足を結び付けることはできません。以下は、同種の業務停止に備えるための一般的な対策です。

    サイバー攻撃への備えでは、侵入を防ぐだけでなく、侵入された場合にも被害を広げない対策が必要です。重要システムやネットワークの分離、特権アカウントの適切な管理、多要素認証、ログの保全・監視などを組み合わせ、攻撃者による内部での移動や権限拡大を抑制します。

    経済産業省・独立行政法人情報処理推進機構（IPA）の「サイバーセキュリティ経営ガイドライン Ver3.0 実践のためのプラクティス集 第4版」も、侵入を防ぐ入口対策に加え、内部での活動拡大を防ぐネットワーク対策、外部への不正通信を防ぐ出口対策、重要データを守る対策を組み合わせる多層防御を示しています。

    「システムを止めた状態」で続ける手順を用意する

    不正アクセスの疑いがある状況では、ネットワークの遮断や機器の隔離、サービス停止が必要になることがあります。IPAの「中小企業のためのセキュリティインシデント対応の手引き」でも、被害拡大の可能性がある場合の初動対応として、ネットワーク遮断や対象機器の隔離、システム・サービスの停止を挙げています。

    だからこそ、BCPはバックアップからシステムを戻す手順だけでは不十分です。システムを遮断した際に利用する代替手順を、業務内容に応じて事前に設計しておく必要があります。例えば、受発注や入出庫を電話、メール、紙の帳票などへ一時的に切り替える場合も、処理可能な件数、誤処理を防ぐ照合方法、記録の保全、平常系へ戻す際のデータ反映まで検証しなければなりません。机上演習に加え、主要システムを利用できない状況を想定し、代替手順が実際に機能するか確認することが重要です。

    復旧可能なバックアップと復旧手順を検証する

    バックアップは、データを保存しているだけでは事業復旧を保証できません。本番環境と同時に暗号化・削除されないよう、ネットワークから分離した媒体や異なる環境にも保管し、バックアップデータの完全性を定期的に確認する必要があります。

    さらに、復元テストを実施し、重要なシステムやデータを想定した時間内に復旧できるかを検証します。復旧の順序、必要な担当者、利用する機器や認証情報、システム間の依存関係も事前に整理しておくことが重要です。

    サイバー攻撃を受けた環境を安全確認なしに復元すると、侵害された設定やマルウェアまで戻してしまうおそれがあります。原因調査や安全性の確認と並行して、どの時点のデータを、どの環境へ、どの順番で戻すかを判断できる復旧手順を整備しておく必要があります。

    初動対応をIT部門だけに背負わせない

    インシデント発生時には、封じ込め、証拠保全、原因調査、復旧に加え、顧客や取引先への連絡、個人情報保護委員会などへの報告、警察との連携、経営判断が並行して進みます。ニチレイも緊急対策本部を設置し、外部のセキュリティ専門会社、警察、関係機関と連携しました。

    平時から、経営、情報システム、事業部門、法務、広報、個人情報保護担当の役割と連絡順序を決め、フォレンジック調査や復旧を依頼する外部専門家の連絡先を整えておくべきです。対応手順は、社内システムが利用できない状況でも参照できる場所に保管します。また、調査に必要なログやデータを不用意に消去しないよう、対象機器の隔離方法や外部専門家へ連絡する判断基準を訓練しておくことが重要です。

    取引先を含めて復旧情報を共有する

    自社が通常稼働へ戻っても、取引先側では在庫不足、納品遅延、代替商品の手配、顧客への案内が続く可能性があります。サプライチェーン全体の復旧を早めるには、「何が止まっているか」「どの業務をいつ再開するか」「制限が残るか」を、攻撃者に利する情報を避けながら継続的に共有することが重要です。

    公表文のひな型だけでなく、重要取引先への連絡経路、問い合わせ窓口、更新頻度、技術情報と事業影響を分けて説明するルールまで準備しておくと、混乱を抑えやすくなります。セキュリティ部門が把握する復旧状況を、物流、営業、調達、顧客対応の言葉へ変換する役割も必要です。

    よくある質問

    ▼ ニチレイのシステム障害はいつ発生しましたか
    ▼ どの業務に影響が出ましたか
    ▼ 個人情報は漏えいしましたか
    ▼ ランサムウェア攻撃だったのでしょうか

    まとめ―サイバー攻撃対策は業務復旧まで設計する

    ニチレイへのサイバー攻撃では、冷蔵倉庫の入出庫と冷凍食品出荷に支障が生じ、制限付きの再開を経て通常運用へ戻りました。一方、2026年7月31日時点では、攻撃手法や侵入経路、個人情報の外部流出の有無、最終的な影響範囲は公表されていません。

    今回の事例から企業が学ぶべきなのは、侵入防止策だけではありません。被害拡大を防ぐためにシステムを遮断しても重要業務を続けられるか、安全性を確認しながらどの順番で復旧するか、取引先へ何を伝えるかまで含めて設計する必要があります。サイバー攻撃をIT障害として閉じず、経営と現場を巻き込んだサイバーBCPとして準備することが、事業とサプライチェーンの強靱性を左右します。

    【参考情報】

    編集責任：木下

    BBSecの脆弱性診断・セキュリティ対策支援サービス

    BBSec（ブロードバンドセキュリティ）では、Webアプリケーション診断、プラットフォーム診断、クラウド環境診断、脆弱性管理支援など、企業のセキュリティリスクを可視化する各種サービスを提供しています。外部サービスや委託先を含めたセキュリティ体制の見直し、情報漏えいリスクへの備え、インシデント発生前の予防対策を検討している企業は、ぜひご相談ください。

    ウェビナー開催のお知らせ

  • 2026年8月19日（水）14:00～15:00「セキュリティ対策の有効性を検証する ―ペネトレーションテストの実施ポイントと脆弱性診断との違い―」
  • 2026年8月26日（水）「AI時代に見直すセキュリティ対策 ～ASMの考え方で始める攻撃対象領域の可視化とリスク対策～」

    • 最新情報はこちら

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る