サプライチェーンセキュリティは「自社だけ守る」時代から変わっている
サプライチェーンセキュリティは、もはや大企業やIT企業だけの課題ではありません。業務委託、クラウド利用、SaaS連携、外部ベンダーによる保守運用、再委託先での作業など、企業活動の多くは外部事業者との接続を前提に成り立っています。
そのため、自社のネットワークや社内ルールだけを整えても、委託先や再委託先の管理が弱ければ、そこが攻撃や情報漏えいの入口になる可能性があります。経済産業省のサイバーセキュリティ経営ガイドラインでも、ビジネスパートナーや委託先を含むサプライチェーン全体の対策状況の把握、役割と責任範囲の明確化が求められています。
本記事では、サプライチェーンセキュリティと再委託先管理について、契約、監査、業務フロー、SBOM、評価制度対応までを実務目線で整理します。
なぜ再委託先管理が重要なのか
委託先の先にある「見えないリスク」が増えている
多くの企業では、システム開発、保守運用、データ入力、コールセンター、配送、バックオフィス、マーケティング支援などを外部に委託しています。さらに委託先が一部業務を別会社や個人事業主に再委託するケースも珍しくありません。
問題は、発注企業から見ると、再委託先の実態が見えにくいことです。誰が、どこで、どの端末を使い、どの情報にアクセスしているのかが曖昧なまま業務が進むと、情報漏えい時に原因特定や責任分担が難しくなります。
特に個人データや営業秘密、設計情報、認証情報、顧客リストなどを扱う業務では、再委託の有無を契約上明確にし、事前承認、管理義務、事故時の報告義務、再委託先への同等義務の適用を定めておく必要があります。
「信頼している取引先」でも管理は必要
取引実績が長い委託先ほど、現場では「いつもの会社だから大丈夫」と判断されがちです。しかし、サイバーセキュリティでは信頼関係だけでは不十分です。
委託先の担当者変更、業務量増加、クラウドツールの追加、再委託の発生、リモート作業の拡大などにより、当初想定していなかったリスクが生まれることがあります。個人番号・特定個人情報の文脈では、最初の委託者は再委託先に対しても間接的に監督義務を負うとされ、委託先は再委託にあたり最初の委託者の許諾を得る必要があると説明されています。
再委託先管理は、取引先を疑うためのものではありません。事故が起きたときに、発注者・委託先・再委託先の全員を守るための仕組みです。
サプライチェーンセキュリティで押さえるべき5つの実務フロー
1. 委託先選定時にセキュリティ要件を確認する
委託先管理は、契約後ではなく選定段階から始まります。価格や納期、実績だけでなく、情報セキュリティ体制も評価項目に入れるべきです。
確認すべき項目は、情報セキュリティ基本方針の有無、アクセス権限管理、端末管理、バックアップ、ログ取得、インシデント対応体制、再委託の有無、クラウドサービス利用状況などです。
中小企業の場合、IPAのSECURITY ACTIONを参考にする方法もあります。SECURITY ACTIONには一つ星と二つ星があり、一つ星は「情報セキュリティ5か条」への取組、二つ星は自社診断と情報セキュリティ基本方針の策定・公開が求められます。
ただし、自己宣言だけで十分と考えるのは危険です。扱う情報の重要度が高い場合や、自社システムと接続する場合は、追加の確認や監査が必要になります。
2. 契約書で再委託ルールを明確にする
再委託先管理で最も重要なのは、契約書に曖昧さを残さないことです。口頭確認やメールのやり取りだけでは、事故時に責任範囲が不明確になります。
契約書には、少なくとも次の内容を入れるべきです。
- 再委託の禁止または事前承認制
- 再委託先の名称、業務範囲、所在地、取扱情報の開示
- 再委託先にも同等のセキュリティ義務を課すこと
- 個人情報・機密情報の目的外利用禁止
- アクセス権限、端末、媒体、クラウド利用の管理
- 漏えい・不正アクセス発生時の報告期限
- 監査権限、証跡提出、是正要求
- 契約終了時の返却・削除・廃棄証明
特に重要なのは「同等義務の連鎖」です。発注者と委託先の契約だけが厳しくても、再委託先に同じ義務が課されていなければ、実効性は落ちます。
3. 業務中はアクセス権限とログを管理する
契約でルールを定めても、業務中に運用されなければ意味がありません。実務では、必要な人だけが、必要な期間だけ、必要な情報にアクセスできる状態を作ることが基本です。
アカウントを共有しない、退職者や担当変更者の権限を削除する、管理者権限を必要最小限にする、ファイル共有リンクを期限付きにする、重要データのダウンロードを制限するなど、細かな管理が事故防止につながります。
また、ログを取得していなければ、事故時に「いつ、誰が、何にアクセスしたのか」を確認できません。クラウドサービスを使う場合も、ログの保存期間、取得範囲、調査時の提出可否を事前に確認しておく必要があります。
4. 納品・業務終了時にデータ返却と削除を確認する
再委託先管理で見落とされやすいのが、業務終了時の処理です。契約期間中は注意していても、納品後に作業用データ、バックアップ、テストデータ、ローカル保存ファイルが残ることがあります。
そのため、業務終了時にはデータの返却、削除、廃棄、アカウント停止、アクセス権限削除を確認し、必要に応じて削除証明書や作業完了報告書を提出してもらうべきです。
特に個人情報や機密情報を扱う場合は、「削除したはず」ではなく「削除したことを確認できる状態」にすることが大切です。
5. インシデント時の連絡・初動・再発防止を決めておく
情報漏えいや不正アクセスが起きた場合、初動の遅れは被害拡大につながります。委託先や再委託先で事故が起きたとき、誰が発注者へ報告し、どの情報を、何時間以内に共有するのかを決めておく必要があります。
報告項目には、発生日時、検知日時、影響範囲、対象データ、対象人数、原因、暫定対応、再発防止策、外部機関への報告要否などを含めます。
個人情報保護委員会のQ&Aでも、委託関係における漏えい等発生時の報告義務主体や、クラウドサービス、配送事業者を利用した場合の考え方が整理されています。個人データを扱う業務では、契約だけでなく法令上の報告・通知対応も見据えた設計が必要です。
SCS評価制度が委託先管理に与える影響
取引先のセキュリティ水準を段階的に見る流れが強まる
経済産業省は、サプライチェーン強化に向けたセキュリティ対策評価制度、いわゆるSCS評価制度の整備を進めています。制度では、セキュリティ対策の段階を★3・★4に区分し、★5は今後検討とされています。★3の要求事項・評価基準を基礎に、★4ではより広い範囲や対策を含む要求事項・評価基準に基づき、自己評価や第三者評価機関による評価を行う仕組みです。
この流れにより、今後は「取引先にセキュリティ対策をお願いする」段階から、「どの水準の対策が必要かを明示し、実施状況を確認する」段階へ進む可能性があります。
ただし、SCS評価制度は任意制度であり、特定のセキュリティ製品の導入が必須とされているものではありません。経済産業省も、不適切な勧誘に注意するよう案内しています。
中小企業は「取引先から聞かれる前」に準備する
中小企業にとって重要なのは、制度の名称を覚えることではなく、取引先から確認される項目に答えられる状態を作ることです。
たとえば、情報セキュリティ基本方針、委託先管理台帳、利用クラウド一覧、インシデント対応手順、バックアップ方針、アクセス権限管理表、再委託先一覧などが整っていれば、取引先からの確認に落ち着いて対応できます。
反対に、実態はある程度対応していても、文書化や証跡がなければ「説明できない会社」と見なされる可能性があります。セキュリティ対策は、実施するだけでなく、説明できる形に整えることが重要です。
SBOMはソフトウェアサプライチェーン管理の基盤になる
ソフトウェア部品の可視化が求められている
現代のシステムは、自社で一から作ったコードだけで構成されているわけではありません。オープンソースソフトウェア、外部ライブラリ、クラウドサービス、API、パッケージ製品など、さまざまな部品が組み合わされています。
そのため、利用しているソフトウェア部品に脆弱性が見つかったとき、自社のどのシステムに影響するのかをすぐに把握できなければなりません。ここで重要になるのがSBOM、つまりソフトウェア部品表です。
SBOMは、ソフトウェアを構成する部品、バージョン、依存関係などを可視化するための仕組みです。単なる一覧表ではなく、脆弱性情報と組み合わせて運用することで、影響範囲の特定や優先順位付けに役立ちます。
SBOMは作って終わりではない
SBOM対応で失敗しやすいのは、導入を「ツールを入れること」と考えてしまうことです。実際には、対象システムの範囲、生成タイミング、保管場所、更新頻度、脆弱性情報との照合、対応判断、委託先との情報共有まで含めて設計する必要があります。
特に委託開発や外部ベンダーが関わるシステムでは、契約書や仕様書にSBOMの提出、更新、脆弱性発見時の通知、修正対応の責任範囲を定めておくことが重要です。
SBOMは、セキュリティ部門だけの管理資料ではありません。開発、調達、法務、情報システム、委託先管理をつなぐ実務インフラとして位置付けるべきです。
再委託先管理を形骸化させないためのポイント
台帳管理で委託先・再委託先を可視化する
最初に取り組むべきことは、委託先と再委託先の一覧化です。どの会社に、どの業務を、どの情報を、どの期間、どのシステムで扱わせているのかを台帳化します。
台帳には、契約開始日、契約終了日、担当部署、取扱情報、再委託の有無、利用クラウド、監査実施日、是正状況、事故履歴などを記録します。
この台帳がないままでは、サプライチェーン全体のリスク評価はできません。まずは完璧な仕組みを作るより、現在の委託先を棚卸しすることが現実的です。
リスクに応じて管理レベルを変える
すべての委託先に同じレベルの管理を求めると、現場の負担が大きくなり、運用が続きません。重要なのは、リスクに応じて管理レベルを変えることです。
たとえば、個人情報や機密情報を扱わない軽微な業務と、顧客データベースに接続する保守業務では、必要な確認項目が違います。自社システムへの接続有無、取り扱う情報の重要度、業務停止時の影響、再委託の有無などを基準に、確認項目や監査頻度を変えるべきです。
契約・技術・運用を分断しない
再委託先管理は、法務部門だけでも、情報システム部門だけでも完結しません。契約書に厳しい条項があっても、技術的なアクセス制御が弱ければ事故は起こります。逆に、システム上の制御があっても、事故時の報告義務や損害分担が曖昧では、対応が混乱します。
契約、技術、運用を一体で設計することが、サプライチェーンセキュリティの基本です。
まとめ｜サプライチェーンセキュリティは取引継続の条件になる
サプライチェーンセキュリティと再委託先管理は、単なる情報システム部門の課題ではありません。取引先との信頼、契約責任、事業継続、法令対応に関わる経営課題です。
まず取り組むべきことは、委託先・再委託先の可視化、契約条項の見直し、アクセス権限とログの管理、業務終了時のデータ削除確認、インシデント時の報告フロー整備です。さらに、SCS評価制度やSBOM対応の流れを踏まえれば、今後は「対策しているつもり」ではなく、「対策状況を説明できること」が取引上の重要な条件になる可能性があります。
次の研究テーマとしては、再委託先管理台帳の作り方、情報セキュリティ特約の条項設計、SCS評価制度に向けた中小企業の準備、SBOMを契約に組み込む方法などを掘り下げると、より実務に直結したコンテンツになります。
コメント