プライバシー設定

このサイトでは、第三者のウェブサイト追跡技術を使用して、当社のサービスを提供および継続的に改善し、ユーザーの興味に応じた広告を表示します。同意します。また、将来的に有効となる限り、いつでも同意を取り消したり、変更したりすることができます。

すべての記事

サプライチェーン攻撃の対策｜企業が今すぐ取り組むべき手順と国内事例

ジョーシス編集部

SaaS運用に課題を感じている方へ

現在の状況をヒアリングし、最適な改善方法をご提案します。

この記事は読むことができます 5 分

この記事は 1 分で読むことができます

ジョーシス編集部

この記事は 1 分で読むことができます

コピー

サプライチェーン攻撃とは、標的企業の取引先・委託先・ソフトウェアベンダーを経由して侵害するサイバー攻撃です。IPA（情報処理推進機構）が毎年発表する「情報セキュリティ10大脅威」において、「サプライチェーンや委託先を狙った攻撃」は2023年から4年連続で組織部門の第2位に位置しています。2024年には株式会社イセトーへのランサムウェア攻撃が発端となり、約150万件の個人情報が漏えいしました。被害は委託元となった全国の自治体や企業に波及しています。

問題は、イセトーを委託先として利用していた企業が自社システムは直接侵害されていないにもかかわらず被害を受けた点です。これがサプライチェーン攻撃の本質です。自社がどれほど堅固なセキュリティを構築していても、取引先・委託先の脆弱性が侵入口になります。

攻撃の手口と国内被害事例を整理した上で、情シス担当者がIT管理側で実践できる具体的な対策を解説します。委託先管理の方法や法規制動向も含め、自社の対応状況を点検するための実践的な情報をまとめています。

サプライチェーン攻撃とは？3種類の攻撃手口

サプライチェーン攻撃とは、標的企業に直接侵入するのではなく、その企業が依存する取引先・委託先・ソフトウェアベンダーを経由して侵害する手法です。セキュリティが強固な大企業を正面から狙うよりも、対策が手薄な周辺企業を足がかりにするほうが攻撃者には容易なため、近年急増しています。

ビジネス型（委託先・取引先経由）

最も広く見られる形態です。標的企業の委託先や取引先のシステムに侵入し、そこを踏み台として本来の標的に接続します。委託先企業はターゲット企業のネットワークに接続する権限を持っていることが多く、その信頼関係が悪用されます。

2022年のトヨタ・小島プレス工業事件が典型例です。トヨタの部品サプライヤーである小島プレス工業がランサムウェアに感染したことで、トヨタの国内全14工場28ラインが停止しました。影響台数は約1万3千台。トヨタ自身は攻撃を受けていなかったにもかかわらず、サプライヤーとの接続を遮断せざるを得ない状況に追い込まれた事例です。

ソフトウェア型（OSS汚染・アップデート悪用）

ソフトウェアの開発・配布プロセスに悪意あるコードを混入させる手法です。企業が利用するソフトウェアのアップデートファイル自体に攻撃コードが含まれるため、利用企業は正規のアップデートを適用したつもりで感染します。

代表的な事例が2020年のSolarWinds事件です。米国のIT管理ソフトウェアOrionのアップデートに悪意あるコードが混入され、米国政府機関を含む約18,000組織が影響を受けました。オープンソースソフトウェアの依存関係を悪用した攻撃も急増しており、開発環境を持つ企業は特に注意が必要です。

サービス型（クラウドサービス・SaaS経由）

企業が利用するクラウドサービスやSaaSプロバイダーが侵害される形態です。多くの企業が共通して利用するSaaS管理ツールや認証サービスが侵害されると、そのサービスを利用する全企業に被害が連鎖します。SaaSのAPIを通じた不正アクセスも増加しています。

参考：IPA「情報セキュリティ10大脅威 2025」

参考：IPA「情報セキュリティ10大脅威 2026」

国内被害事例から学ぶ：主要インシデント

サプライチェーン攻撃は海外の大企業だけが受ける攻撃ではありません。国内事例を振り返ると、業種・規模を問わず被害が拡大していることがわかります。

株式会社イセトー事件（2024年）

2024年5月、印刷・発送業務を手がける株式会社イセトーがランサムウェア攻撃を受けました。イセトーは全国の自治体や企業から住民税の特別徴収通知書・年金通知書・医療費通知書などの発送業務を受託しており、漏えいした個人情報は約150万件に上りました。

この事件が残した教訓は、イセトー自身の被害にとどまらず、業務を委託していた自治体・企業がすべて二次被害者になったという点です。委託元は自社のシステムには一切問題がなかったにもかかわらず、顧客への謝罪・通知対応を余儀なくされました。

KADOKAWAグループへのランサムウェア攻撃（2024年）

2024年6月、KADOKAWAグループの複数サーバーへのアクセス障害が発生し、ニコニコ動画を中心としたサービス群が長期間にわたって停止しました。ランサムウェアを含む大規模なサイバー攻撃であることが確認され、グループ企業の業務データや個人情報の漏えいも発生しています。

KADOKAWAの事例は、グループが提供するサービスを利用していたクリエイターや企業が、自らのシステムは無事であるにもかかわらず、データアクセス不能という二次的な影響を受けたサードパーティリスクの典型例です。

トヨタ・小島プレス工業事件（2022年）

2022年2月、トヨタ自動車の部品サプライヤーである小島プレス工業がサイバー攻撃を受け、トヨタは翌日から国内全14工場28ラインの稼働を停止せざるを得ませんでした。生産停止による影響台数は約1万3千台。Tier1と呼ばれる一次サプライヤーへの攻撃が、製造業の中核に直接ダメージを与えた象徴的な事例です。

名古屋港コンテナターミナル（2023年）

2023年7月、名古屋港のコンテナターミナルで使用されているシステムがランサムウェアに感染し、コンテナの搬出入業務が約3日間停止しました。名古屋港は日本の総輸出入額の約10%を扱う国内最大の港湾であり、トヨタ自動車など多くのメーカーの物流に影響が生じました。

参考：サイバーセキュリティクラウド「企業のセキュリティインシデントに関する調査レポート2024」

なぜサプライチェーン攻撃は防ぎにくいのか

サプライチェーン攻撃が4年連続でIPAの10大脅威上位に位置するのは、従来のセキュリティ対策では防ぎにくい構造的な特徴があるためです。自社のファイアウォールやEDRを強化しても、攻撃経路が自社の外にある以上、これらの対策が機能しない場面が必ず生じます。

攻撃者の侵入経路が自社のコントロール外にある

自社のサーバーやエンドポイントへの不正アクセスは、自社のセキュリティツールで検知・遮断できます。しかし委託先企業のネットワークで何が起きているかは、自社のツールでは把握できません。委託先が侵害された後、正規の接続経路を通じてアクセスしてくる攻撃は、正規の通信として認識されてしまいます。

委託先のセキュリティ水準を把握できていない

委託先のセキュリティ対策水準を定期的に評価する仕組みを持っている企業は多くありません。契約時にセキュリティポリシーの遵守を義務付けていても、実際の対策状況を確認できていないケースが大半です。委託先が数十社・数百社に及ぶ場合、個別確認は現実的に困難です。

シャドーITや未把握SaaSが盲点になる

社員が情シスの承認なく利用しているSaaSや外部サービス、いわゆるシャドーITがサプライチェーン攻撃の入口になることがあります。未承認のSaaSが外部サービスと連携している場合、情シスが把握していないルートで攻撃者が侵入する可能性があります。

企業が取るべきサプライチェーン攻撃対策の全体像

サプライチェーン攻撃への対策は、自社内部・委託先管理・ソフトウェア管理の3層で考える必要があります。どれかひとつに集中するだけでは不十分であり、3層をバランスよく整備することが求められます。

NIST CSF 2.0では新たに「統治（Govern）」機能が追加され、サプライチェーンリスクを含む組織全体のリスク管理体制の整備が求められるようになりました。自社のセキュリティ対策をこのフレームワークに照らして点検することで、対策の網羅性を確認できます。3層それぞれの主な対策内容と担当部門を以下にまとめます。

対策層	主な内容	担当部門
自社内部	アクセス制御・多要素認証・監査ログ・シャドーIT排除	情シス
委託先管理	セキュリティ評価・契約条項・定期監査	情シス＋調達・法務
ソフトウェア管理	SBOM・脆弱性管理・OSS依存関係の把握	情シス＋開発部門

IT管理側で実践できる6つの具体的対策

情シス担当者がIT管理の観点から今日から取り組める対策を6つ挙げます。すべてを同時に実装する必要はなく、リスクが高い領域から順番に着手することが現実的です。

①最小権限の原則によるアクセス権管理

すべてのユーザー・システム・アプリケーションに対して、業務遂行に必要な最小限のアクセス権のみを付与します。委託先・外部ベンダーに付与しているアクセス権は特に注意が必要です。念のため広めに権限を与えておくという運用は、攻撃者が侵入した際の被害範囲を広げます。

アクセス権の棚卸しを定期的に実施し、不要になった権限はその時点で削除する運用を確立してください。プロジェクト終了後の外部委託先アカウントや退職者のアカウントが残存していないかを確認することが出発点となります。

②多要素認証の徹底

VPN・SaaS・クラウドサービスへのアクセスには、パスワードだけでなく多要素認証（MFA）を設定します。委託先がアクセスする際も例外なくMFAを要求してください。アカウント情報がフィッシングで漏えいしても、MFAがあれば不正ログインを防げます。

注意が必要なのは、複数のSaaSを利用している場合にMFAの設定状況がサービスごとに異なる点です。すべてのSaaSでMFAが有効になっているかを一括で確認できる体制を整えることが求められます。

③シャドーIT・未承認SaaSの検出と排除

情シスが把握していないSaaSや外部サービスの利用は、サプライチェーン攻撃の入口になります。社員が業務効率のために個人的に利用しているSaaSが社外の悪意あるサービスと連携している場合、情シスが知らないルートでデータが流出する可能性があります。

シャドーITの検出には、ネットワークの通信ログの分析や、SaaS管理ツールによる利用状況の可視化が有効です。発見した未承認SaaSは、業務上必要なものは正式な申請・承認フローに乗せ、不要なものはアクセスをブロックします。

シャドーIT 対策

④ソフトウェア・ライブラリの脆弱性管理

利用しているソフトウェアやライブラリの構成を把握し、既知の脆弱性が含まれていないかを継続的に確認します。SBOM（Software Bill of Materials）はソフトウェアに含まれるすべてのコンポーネントと依存関係を一覧化したもので、脆弱性が公表された際に影響を受けるシステムを迅速に特定するために活用できます。

オープンソースソフトウェアを利用している場合は、依存関係に脆弱なパッケージが含まれていないかを定期的に確認します。ソフトウェア構成分析ツールを活用することで、このスキャンを自動化できます。

⑤ネットワーク分離とゼロトラスト設計

委託先や外部ベンダーが接続するネットワークセグメントは、社内の重要システムとは分離して設計します。接続できることとすべてのリソースにアクセスできることは別であり、委託先に付与するアクセス権は業務に必要な特定のシステム・データに限定してください。

ゼロトラストセキュリティは「信頼しない、常に検証する」という原則に基づいています。社内ネットワーク内からのアクセスであっても、すべてのアクセスを検証・制御することで、侵入後の被害拡大を防ぎます。

⑥監査ログの収集と異常検知

委託先・取引先からのアクセスを含むすべての接続ログを収集し、異常なアクセスパターンを検知できる体制を整えます。通常とは異なる時間帯・場所・量のアクセスは、侵害の可能性を示すシグナルです。

各SaaSの管理コンソールが提供する監査ログを定期的に確認することも必要です。複数のSaaSにまたがるアクセスログを一元的に管理・分析できる環境を構築することで、異常の早期発見につながります。

参考：NIST CSF 2.0

参考：SBOM導入の手引き（経済産業省）

委託先・取引先のセキュリティ管理方法

自社内部の対策と並行して、委託先・取引先のセキュリティ水準を把握・管理することがサプライチェーン攻撃への実効的な対応です。第三者リスク管理（TPRM）と呼ばれるこの取り組みは、企業規模を問わず求められるようになっています。

委託先のセキュリティ評価チェックリスト

委託先のセキュリティ対策水準を評価するために、定期的な自己評価アンケートや現地確認を実施します。評価すべき主な項目は以下の通りです。

情報セキュリティポリシーの策定・運用状況
アクセス制御・多要素認証の実施状況
セキュリティインシデント発生時の報告義務と対応体制
個人情報・機密情報の取り扱いルール
再委託先（孫請け）のセキュリティ管理状況
定期的な脆弱性診断・セキュリティ教育の実施状況

委託先の規模や委託内容のリスク度に応じて評価の頻度・深度を変えることが現実的です。重要な個人情報や機密データを扱う委託先には、より詳細な評価と頻繁な確認が必要になります。

契約書への情報セキュリティ条項の組み込み

委託先との契約書には、情報セキュリティに関する要件を明示的に盛り込みます。主な条項として、セキュリティポリシーの遵守義務、インシデント発生時の報告義務（報告期限・報告内容を明記）、再委託先への同等のセキュリティ要件の適用、セキュリティ監査への協力義務などが挙げられます。

契約書に条項を盛り込むだけでは不十分です。委託先がこれらの義務を実際に履行しているかを確認する仕組みをセットで構築してください。

委託先への定期的な評価・確認の実施

セキュリティ評価を契約締結時に一度行うだけでは不十分です。委託先のセキュリティ状況は時間とともに変化します。半年から1年に一度の定期的な自己評価アンケート、重大なセキュリティ脆弱性が公表された際の緊急確認、インシデント発生時の即時報告と情報共有の体制を構築してください。

委託先の数が多い場合は、機密情報へのアクセス権がある・大量の個人情報を扱うといったリスクの高い委託先を優先的に評価対象とすることが現実的です。

参考：経済産業省「サイバーセキュリティ経営ガイドライン」

経済産業省SCS評価制度など法規制動向と企業対応

サプライチェーンセキュリティに関する法規制・ガイドラインの整備が急速に進んでいます。現在の対策状況を点検するとともに、今後の規制動向を注視することが求められます。

サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）

経済産業省と内閣官房国家サイバー統括室は、サプライチェーン全体のセキュリティ対策水準を評価・証明するSCS評価制度の構築を進めています。2026年3月27日公表の構築方針では、専門家確認付き自己評価（25項目程度）の★3と第三者評価（44項目程度）の★4を先行して整備し、2026年度末頃の評価開始を目標としています（★5の評価基準は今後検討）。

この制度が導入されると、サプライチェーンに参加する企業はセキュリティ対策の評価を受け、一定水準を満たすことを証明する仕組みが整います。取引先・委託先の選定において、この評価結果が参照される可能性があります。今から対策を整備しておくことが、将来的な取引機会の確保にも直結します。

NIST CSF 2.0でのサプライチェーンリスク管理

2024年2月に公開されたNISTサイバーセキュリティフレームワーク2.0では、新機能「統治（Govern）」が追加されました。組織の意思決定者がサプライチェーンリスクを含むセキュリティリスクを管理する責任が明示され、委託先を含むサードパーティのリスクマネジメントが経営課題として位置付けられています。

金融庁ガイドラインにおける委託先管理要件

2024年10月に策定・公表された「金融分野におけるサイバーセキュリティに関するガイドライン」では、委託先を含むサードパーティリスクの管理が明示的に求められるようになりました。金融業界にとどまらず、他業種でも同様の要件が波及することが予想されます。

参考：経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度構築方針」

参考：経済産業省「SCS評価制度中間取りまとめ」

SaaS可視化・アクセス管理でリスクを下げるJosys活用

サプライチェーン攻撃対策において、IT管理の観点から即効性が高い取り組みのひとつがSaaSの可視化と適切なアクセス管理です。ジョーシスのプラットフォームは、情シス2〜3名体制の組織が抱えるこの課題に直接対応する機能を提供しています。

SaaS管理の穴がサプライチェーンリスクになる理由

現代の企業は数十から数百種類のSaaSを並行して利用しています。しかし、情シスが把握していないSaaSの存在（シャドーIT）や、退職者・プロジェクト終了後も残存するアクセス権は、攻撃者が侵入するための穴になります。

委託先や外部ベンダーに付与したSaaSアクセス権が、業務終了後も削除されないまま残存しているケースは珍しくありません。このような幽霊アカウントが不正アクセスの踏み台になると、正規の認証情報を使ったアクセスとして検知を回避されてしまいます。以前は、未管理のSaaSアカウントや権限の状況を把握するには各SaaSの管理コンソールを個別に確認する必要があり、情シス2〜3名の体制では現実的に困難な作業でした。

ジョーシスのプラットフォームによるSaaSの一元可視化

ジョーシスのプラットフォームは、企業が利用するSaaSアプリケーションとそのアクセス権を一元的に管理・可視化します。どのユーザーがどのSaaSにどのような権限でアクセスしているかを、単一の画面から確認できる環境が整います。

個別のSaaS管理コンソールを横断的に確認していた作業から解放され、全SaaSのアクセス状況を一か所で把握できるようになります。これにより、不審なアクセスや不要な権限の早期発見が可能になります。

シャドーITの自動検出とアクセス権の一括管理

ジョーシスのプラットフォームのSaaS Discovery機能は、社員が利用しているSaaSを自動検出します。情シスが承認していないシャドーITを可視化し、セキュリティポリシーに基づいて対処できます。発見したシャドーITは、業務上必要と判断したものは正式な管理対象に移行し、不要なものはアクセスをブロックします。

SaaSへのアクセス権の付与・変更・削除を一元的に管理できるため、委託先・外部ベンダーへのアクセス権を適切なタイミングで停止する運用もスムーズになります。