わかりやすく学ぶサプライチェーン攻撃の要点

• サプライチェーン攻撃とは、自社を直接狙うだけでなく、委託先、取引先、ソフトウェア、クラウドサービス、開発ツールなどの「つながり」を悪用して侵入する攻撃です。
• 情報システム担当者にとって重要なのは、攻撃名を覚えることではなく、自社のどの業務が外部依存になっているかを棚卸しすることです。
• 対策は一つの製品で完結しません。契約、アカウント管理、脆弱性管理、ログ監視、バックアップ、インシデント時の連絡網を組み合わせます。
• 委託先を「信用する」ことと、アクセス権限を「検証せずに広げる」ことは別です。最小権限、変更管理、多要素認証を前提にします。
• この記事は、NIST、CISA、ENISA、IPAなどの一次情報を確認し、情報システム担当者が初動で判断しやすい形に整理したものです。

はじめに

「サプライチェーン攻撃とは何か」をわかりやすく説明すると、自社の外側にある弱い入口を使って、最終的に自社へ影響を及ぼす攻撃です。たとえば、業務委託先の端末、利用中のSaaS、更新プログラム、開発ライブラリ、リモート保守用アカウント、クラウド連携などが入口になります。攻撃者から見ると、守りの固い大企業や自治体を正面から破るより、その企業と接続している小規模な委託先やソフトウェア供給元を狙うほうが効率的な場合があります。

情報システム担当者がこのテーマで悩みやすいのは、責任範囲が自社ネットワークだけで閉じない点です。端末管理やファイアウォールだけを見ていても、委託先の権限、外部サービスの設定、ソフトウェア更新の経路、開発環境の依存関係までは見えません。しかも、業務部門は便利さを求めて新しいクラウドサービスを導入し、開発部門は外部パッケージを使い、保守会社はリモート接続を必要とします。サプライチェーン攻撃は、こうした通常業務のつながりの中に潜みます。

本記事では、専門用語をできるだけ噛み砕きながら、情報システム担当者が押さえるべき要点を整理します。対象は、セキュリティ専任ではないが、社内システム、委託先管理、クラウド利用、アカウント管理に関わる担当者です。法的判断や個別製品の設定手順までは扱わず、実務上のリスク把握と初期対策に範囲を絞ります。現場で会話に使える説明も重視します。

サプライチェーン攻撃とは

サプライチェーン攻撃は、製品やサービスが利用者へ届くまでの流れを悪用します。サプライチェーンという言葉はもともと調達、製造、物流の文脈で使われますが、ITではソフトウェア開発、クラウドサービス、運用委託、保守、認証連携、外部APIなども含めて考える必要があります。つまり「自社が業務を進めるために依存している外部の仕組み」が攻撃面になります。

NIST SP 800-161 Rev.1は、サイバーセキュリティのサプライチェーンリスク管理を、組織全体のリスク管理に統合すべき領域として扱っています。単なる購買管理ではなく、システムライフサイクル全体で見る考え方です。Source: NIST SP 800-161 Rev.1

Cybersecurity Supply Chain Risk Management (C-SCRM) is a critical capability.

"サイバーセキュリティサプライチェーンリスク管理（C-SCRM）は、極めて重要な能力である。"

出典: NIST SP 800-161 Rev.1

この引用のポイントは、サプライチェーンリスク管理が「あると望ましい追加施策」ではなく、組織の基本的なセキュリティ能力として扱われている点です。情シスの実務に置き換えると、外部委託先や利用サービスを台帳化し、権限と接続経路を管理することが、技術対策と同じくらい重要になります。

よくある攻撃パターン

サプライチェーン攻撃は一つの型に限定されません。理解しやすくするため、情報システム担当者が見落としやすい入口ごとに整理します。

この表でまず見るべきなのは、攻撃の入口が「怪しい外部サイト」だけではないことです。正規の取引先、正規の保守経路、正規の更新プログラムが悪用される可能性があります。したがって、対策も「不審なものを拒否する」だけでは足りません。正規の経路であっても、誰が、いつ、どの権限で、何を変更したかを後から追える状態にする必要があります。

ENISAのサプライチェーン攻撃に関する報告では、攻撃者がサプライヤーを侵害し、そこから顧客へ影響を広げる構造が整理されています。Source: ENISA Threat Landscape for Supply Chain Attacks
特に、サプライヤー側の信頼関係が顧客側の防御をすり抜ける点は、情シスが委託先管理を考えるうえで重要です。

なぜ情報システム担当者に関係するのか

サプライチェーン攻撃は、セキュリティ部門だけの問題ではありません。多くの会社では、委託先のアカウント発行、SaaSの管理者設定、端末のリモート保守、ネットワーク接続申請、バックアップ運用などを情報システム部門が担います。つまり、攻撃を受けた場合の入口にも、影響を抑える手段にも、情シスの業務が深く関わります。

IPAの「情報セキュリティ10大脅威」では、組織向け脅威としてサプライチェーンや委託先を経由した攻撃が継続的に取り上げられています。Source: IPA 情報セキュリティ10大脅威
これは、単発の流行語ではなく、企業の通常運用に根ざしたリスクとして見られていることを示します。

情シスが特に注意すべき理由は三つあります。第一に、外部依存の全体像を把握できる部署が限られることです。業務部門が個別にSaaSを契約し、開発部門が外部ライブラリを使い、総務や経理が外部委託を進めると、接続先やデータの流れが散らばります。第二に、サプライチェーン攻撃は発覚時の影響範囲確認が難しいことです。どのシステムが、どの委託先に、どの権限を渡しているかが不明だと、遮断や復旧の判断が遅れます。第三に、対策が部門横断になることです。契約条項、セキュリティ評価、ID管理、ログ保全、事故連絡体制を一体で扱う必要があります。

「防ぐ」より先に「見える化」する

サプライチェーン攻撃への第一歩は、外部依存の見える化です。いきなり高度な監視製品を入れるより、どの委託先やサービスが重要システムに触れるのかを把握するほうが効果的です。見えないものは守れず、インシデント時にも止められません。

最初に作るべき台帳は、完璧でなくて構いません。重要なのは、業務影響が大きい順に整理することです。たとえば、基幹システムの保守会社、ID基盤に接続するSaaS、顧客情報を扱う委託先、管理者権限を持つ外部アカウント、社内ネットワークへVPN接続する業者を優先します。台帳には、サービス名、管理部署、契約先、扱うデータ、接続方式、権限、ログ取得可否、緊急連絡先を入れます。

台帳づくりでつまずきやすいのは、「誰が正しい情報を持っているのか」が分からないことです。情シスだけで完結させようとすると、業務部門が直接契約したクラウドサービス、部門内で使っているファイル共有、開発現場が導入した外部ツールが漏れます。最初の棚卸しでは、購買、経理、法務、開発、情報セキュリティ、主要業務部門に協力を求め、契約書、請求書、SSOログ、プロキシログ、クラウド利用状況を突き合わせると精度が上がります。

CISAはソフトウェアサプライチェーンのセキュリティに関して、組織がソフトウェアの構成要素を理解し、脆弱性対応やリスク判断に使う考え方を示しています。SBOM、つまりSoftware Bill of Materialsはその代表例です。Source: CISA SBOM SBOMはすべての会社で即日完全導入できるものではありませんが、少なくとも重要なソフトウェアについて「何に依存しているか」を問うきっかけになります。

見える化の実務では、次の順で着手すると進めやすくなります。

1. 管理者権限を持つ外部アカウントを洗い出す。
2. 社内ネットワークへ接続できる委託先を洗い出す。
3. 個人情報、顧客情報、営業秘密を扱う外部サービスを洗い出す。
4. 重要システムの更新、保守、バックアップに関わる事業者を洗い出す。
5. 退職、契約終了、プロジェクト終了時の権限削除手順を確認する。

この段階で「一覧がない」こと自体は失敗ではありません。むしろ、一覧がないと分かった時点で、攻撃発生時にどこを止めるべきか判断できないリスクが明確になります。

対策は契約、技術、運用を分けて考える

サプライチェーン攻撃対策をわかりやすく整理するなら、契約、技術、運用の三層で考えると抜け漏れを減らせます。技術対策だけに寄せると、委託先の報告義務や事故時の連絡が曖昧になります。契約だけに寄せると、実際の権限管理やログ監視が弱くなります。運用だけに頼ると、担当者異動や繁忙期に崩れます。

契約面では、委託先が扱う情報、再委託の有無、事故時の通知期限、ログ提供、脆弱性対応、契約終了時のデータ削除、監査協力を確認します。すべてを一律に厳しくするのではなく、扱う情報と接続権限に応じて重みを変えるのが現実的です。たとえば、公開情報しか扱わない印刷業者と、顧客DBに接続する保守会社を同じ評価表で扱うと、重要な差が見えにくくなります。

技術面では、多要素認証、最小権限、接続元制限、端末証明書、特権ID管理、ログ監査、EDR、脆弱性管理が中心になります。外部アカウントに常時管理者権限を与えるのではなく、作業時だけ権限を付与し、作業後に戻す運用が望ましいです。また、APIキーやOAuth連携は人間のアカウントより見落とされやすいため、定期的な棚卸し対象に含めます。

運用面では、変更管理と初動対応が重要です。委託先から「緊急で設定変更が必要」と依頼されたとき、誰が承認し、どのログを残し、どの時間帯に実施するのかが決まっていないと、攻撃者に正規作業を装われる可能性があります。異常検知時には、委託先連絡、アカウント停止、ネットワーク遮断、バックアップ確認、経営報告、法務確認を並行して進める必要があります。

初動で使えるチェックリスト

サプライチェーン攻撃対策は大きなテーマですが、情シスが明日から確認できる項目もあります。以下は、重要システムに関わる委託先や外部サービスを対象にした初期チェックです。

• 外部委託先の管理者アカウントは個人別に発行されているか。
• 共有IDを使っている場合、利用者、利用目的、利用期間が記録されているか。
• 外部接続には多要素認証が必須になっているか。
• 契約終了や担当者交代時に、アカウント削除を確認する手順があるか。
• SaaSの管理画面で、外部連携アプリとAPIキーを棚卸ししているか。
• 重要システムの更新プログラムを、検証環境で確認してから本番適用しているか。
• 委託先が事故を認識した場合の連絡先と通知期限が契約または運用手順にあるか。
• 重要な操作ログを自社側で確認できるか、または委託先から提供を受けられるか。
• バックアップが攻撃者の操作で同時に消されない設計になっているか。
• 重大インシデント時に停止できる接続経路が明確か。

このチェックリストは、すべてに丸が付けば安全という意味ではありません。目的は、優先順位をつけることです。特に、管理者権限、顧客情報、社内ネットワーク接続、バックアップ操作に関わる委託先は、先に確認する価値があります。

チェック結果は、単なる指摘一覧で終わらせず、期限と責任者を付けた改善項目にします。たとえば「MFA未設定」という結果なら、対象アカウント、例外理由、暫定期限、恒久対応、代替監視を記録します。「委託先の事故連絡先が不明」という結果なら、契約担当と業務責任者を巻き込み、緊急連絡先、休日夜間の窓口、初報に含めるべき情報を決めます。サプライチェーン攻撃は発生後の時間が重要なので、平時の確認項目をインシデント時の行動へつなげておくことが大切です。

経営層や業務部門へ説明するときの言い方

サプライチェーン攻撃を社内で説明するとき、専門用語だけでは伝わりません。経営層には「取引先や利用サービス経由で、自社の業務停止や情報漏えいにつながるリスク」と説明すると理解されやすくなります。業務部門には「便利な外部サービスを使うこと自体が悪いのではなく、誰がどのデータへ接続できるかを把握する必要がある」と伝えるほうが協力を得やすいです。

避けたい説明は、「危ないので外部委託をやめましょう」という極端な言い方です。現実には、クラウド、SaaS、保守委託、外部開発を完全に止めることは難しく、業務効率も落ちます。必要なのは、外部依存をなくすことではなく、外部依存を管理できる状態にすることです。

社内説明では、次の三つをセットで示すと合意形成しやすくなります。第一に、リスクの入口です。どの委託先やサービスが重要データに触れるのかを示します。第二に、影響です。停止するとどの業務が止まり、漏えいするとどの顧客や取引先に影響するのかを示します。第三に、現実的な対策です。MFA、権限棚卸し、契約条項、ログ確認など、すぐ始められる項目から提示します。

よくある誤解

いいえ。攻撃者は、最終的な標的に到達するために、規模の小さい委託先や関連会社を狙うことがあります。中小企業でも、大企業や自治体の業務を受託している場合、サプライチェーンの一部として狙われる可能性があります。

十分とは言えません。マルウェア検知は重要ですが、正規アカウント、正規VPN、正規アップデート、正規APIが悪用される場合、単純なウイルス検知だけでは見逃すことがあります。アカウント管理、ログ監視、変更管理を組み合わせる必要があります。

チェックシートは入口として有効ですが、それだけでは不十分です。重要な委託先については、回答内容と実際の接続権限、事故時の連絡体制、ログ提供可否が一致しているかを確認する必要があります。年1回の確認だけでなく、契約変更、システム変更、担当者変更のタイミングでも見直します。

同じではありません。ゼロトラストは、内部外部を問わずアクセスを継続的に検証する考え方です。サプライチェーン攻撃対策では、その考え方を委託先、外部サービス、開発環境にも広げることが有効です。ただし、用語を導入するだけでは対策になりません。実際の権限、ログ、接続経路を管理することが重要です。

まとめ

サプライチェーン攻撃とは、自社の外側にある委託先、ソフトウェア、クラウドサービス、開発ライブラリ、保守経路などを悪用し、最終的に自社へ影響を及ぼす攻撃です。わかりやすく言えば、「信頼してつないでいる相手や仕組み」を入口にされる攻撃です。

情報システム担当者がまず行うべきことは、すべての攻撃を完全に防ぐ宣言ではありません。重要な外部依存を見える化し、管理者権限とデータ接続を優先して棚卸しし、委託先との連絡と停止手順を確認することです。そのうえで、MFA、最小権限、ログ監視、契約条項、バックアップを組み合わせます。

この記事は、NIST、CISA、ENISA、IPAなどの一次情報を確認し、情シス実務の観点で整理しました。組織ごとに業務委託、クラウド利用、開発体制は異なるため、最終判断は自社の情報資産、契約、規制、事業継続要件に合わせて行ってください。