委託する側から見て何を聞けば体制の有無が分かるかを、東芝のサイバーセキュリティ報告書2026から取り出しました。
報告書は大企業が自社で体制を作る側から書かれているので、読み方を裏返しています。企業が持つセキュリティ機能を一連の流れとして並べ直し、そのうち発注側と委託先の境界に出てくるものだけを抜きました。参照したのは2026年6月発行のA4版で、2026年9月9日に読みました。
対応方針
セキュリティ機能を製品ではなく流れで見る理由
セキュリティ機能は個別の製品ではなく、前後がつながった流れとして見ないと、欠けている段が見えません。報告書の全体を通して、次の並びで扱われています。
- ガバナンス、何を守り、どこまでのリスクを受け入れるか
- 把握、守る対象に何があるかの棚卸し
- 予防、入らせないために何をするか
- 検知、侵入に気づけるか
- 対応、止めて調べられるか
- 復旧、決めた時間内に戻せるか
- 検証と改善、ここまでが実際に動くか
委託先がEDR（Endpoint Detection and Response、パソコンやサーバの中の挙動を記録して不審な動きを検知し、その端末を切り離す仕組み）を導入していても、夜間や休日に切り離してよいと決まっていなければ、対応は翌営業日まで止まります。製品を持っているかではなく、誰が何を決められるかを聞く形になるので、委託先も委託元も全体像を知っていることが重要です。
監視のSOCと対応のCSIRT
委託先が監視していますと答えたとき、それが監視だけなのか事故対応まで含むのかで、発注側が用意するものが変わります。SOC（Security Operations Center）はアラートを常時見て一次分析をするチームで、CSIRT（Computer Security Incident Response Team）は事故が起きたときに封じ込め、調査、復旧、報告を指揮するチームです。報告書p.10、16、20では、SOCがアラートを検知すると、全社のSIRT（Security Incident Response Team、事故対応と製品の脆弱性対応の両方の機能を持つ組織）と、該当する部門やグループ会社のCSIRTに連絡が行く流れが説明されています。
監視を外部に出している委託先もあります。MSSP（Managed Security Service Provider）は監視の代行、MDR（Managed Detection and Response）は監視に調査と対応支援まで付けたサービスです。どちらを使っていて、端末の切り離しをどこまで代行させる契約かを聞いておくと、事故のときに誰が手を動かすかが先に分かります。
外部評価のスコアだけで委託先を決めない理由
外部から見える面の評価は、委託先の一部しか映しません。報告書p.37では、取引先の外部公開ネットワークやパッチの適用状況を、ASM（Attack Surface Management、インターネット側から自社のドメイン、IP、サービス、誤設定を探し続ける仕組み）で客観評価しています。映るのは公開されたサーバとドメインの状態までで、内部の権限設計や、誰が止めると決めるかは分かりません。スコアを安全の証拠として扱わず、自社への接続範囲を最小にしておくほうが確実です。
具体的な使い方
【例】委託先の開発者アカウントが乗っ取られたとき
自社のECサイトの開発を委託していて、委託先の開発者が持つクラウド管理用アカウントがフィッシングで乗っ取られた場合を考えます。最初に働くのは予防の段で、ID基盤が普段と違う国からのログインに対して追加の認証を求めるか拒否します。ここを抜けられると検知の段になり、認証ログとクラウドの監査ログが監視基盤に届いて、SOCが、普段と違う国からのログインとその直後のアクセスキー作成を1つの事象として調べます。
対応では、CSIRTがアカウントの停止、セッションの失効、アクセスキーの無効化を指示し、クラウドの設定を継続点検する仕組みが、攻撃者が公開に変えたストレージと新しく作られた権限を検出します。
ここから先に発注側が出てきます。顧客データが実際に持ち出されたかをアクセスログと通信量から確認し、法務が、漏えいの可能性、対象者、法令上の報告が必要かを判定します。サービスを止めるかどうかも発注側の判断で、技術ではなく事業の判断なので委託先が決められません。復旧では、構成をコードで管理していれば正しい定義と監査ログから設定を戻し、鍵を交換して再デプロイします。
この流れを一度追っておくと、契約の前に決めるものが具体的になります。
- 事故の連絡先と、通知の期限
- 端末とアカウントを止める権限を持つ人
- サービス停止を決める人
- 戻せるバックアップ
委託先との契約に入れる条項の範囲
委託先との契約には、事故が起きたあとに必要になる項目を先に入れます。例えば以下です・
- 証跡付きの評価
- 事故通知の期限
- 再委託の条件
- 監査権
- 契約終了時のデータ削除
あとから足しにくいのは監査権と再委託の条件で、契約を結んだあとに証跡の提示を求めても、求める根拠が契約の側にありません。データ削除も、期限と方法と報告の形まで書いておかないと、消したかどうかを確認できないまま契約が終わります。
委託先に渡す権限の決め方
委託先に渡す権限は常時付けたままにせず、使う時間だけ有効にします。管理者権限を申請した時間だけ有効にして操作を記録する運用は、PIM（Privileged Identity Management）と呼ばれます。自動デプロイの仕組みには人のIDを置かず、短時間だけ有効な機械用のIDで動かします。
担当者が変わるときと契約が終わるときに、セッション、API鍵、共有アカウントまで止める手順を決めておくと、契約は終わったのに接続だけ残っている状態を防げます。
委託先から受け取るログとSBOM
受け取るものを先に決めておくと、事故の調査を自社側で追えます。開発を委託している場合の材料は、次のログです。
- ソースコード管理サービスの秘密情報の検知
- クラウドの監査ログ
- ID基盤のログイン記録
- Webの防御装置とCDN（Content Delivery Network、Webの配信を代行する仕組み）のアクセスログ
- アプリケーション自身の認証と認可の記録
受け取るログは、同じ利用者を同じ形式のIDで記録しておかないと突き合わせられません。取得しているかだけでなく、利用者IDの形式をそろえてあるかまで聞いておくと、事故のときに1件ずつ人手で照合する作業が減ります。
製品やシステムを納品してもらう場合は、SBOM（Software Bill of Materials、そのソフトウェアに含まれる部品の名称、バージョン、依存関係、ライセンスの一覧）も対象になります。納品物のバージョンとSBOMの版が対応していることと、新しい脆弱性が公表されたときに影響範囲を返してもらえることまで決めておきます。
委託先が出す検証結果の読み方
委託先から提出される検証の結果は、手法によって測っているものが違います。脆弱性診断の報告書を受け取っただけでは、侵入されたときに気づけるかは確かめられていません。
| 手法 | 測っているもの | 主な成果物 |
|---|---|---|
| 脆弱性診断 | 既知の弱点があるか | 脆弱性の一覧 |
| ペネトレーションテスト | 弱点を悪用して侵入できるか | 侵入経路と証跡 |
| レッドチーム演習 | 侵入されたときに気づいて止められるか | 攻撃シナリオ、到達経路、対応の評価 |
| ASM | 外から見える資産と誤設定が増えていないか | 資産の一覧とリスクの分類 |
レッドチーム演習の評価対象はSOCとCSIRTなので、監視の体制がない委託先に求めても測るものがありません。まず脆弱性診断とペネトレーションテスト、監視が回り始めてからレッドチーム演習という順で求めることになります。テストの進め方はNIST SP 800-115が下敷きです。
報告された脆弱性の優先順位も、深刻度の点数だけでは決まりません。CVSS（Common Vulnerability Scoring System）は技術的な深刻度を0.0から10.0で表す点数なので、悪用が確認された脆弱性の一覧であるKEVカタログと、近いうちに悪用される確率の推定値であるEPSSを材料に加えて、先に直すものを選びます。
手法の違いが分かっていると、提出された報告書を、体制のどの段まで確かめた証拠として扱えるかで読めます。報告書が出てきたこと自体を体制がある証拠として受け取る形ではなくなります。
手順
委託先を見るときは、次の順番で進めます。
- 扱うデータと接続権限で委託先を分類する。全社に同じチェックシートを配る形をやめ、顧客データに触れる先と触れない先を分ける
- 顧客データに触れる委託先との契約を、監査権と再委託の条件を含む形に結び直す
- 事故のときの連絡先と、端末やアカウントを止める権限を持つ人、サービス停止を決める人を決めて、双方の名前で記録する
- 受け取るログとSBOMの種類、利用者IDの形式、提出の頻度を決める
- 委託先の体制がどの段階にあるかを聞く。担当と手順と記録がない、担当者の経験で対応している、手順が文書になっている、定期実施していて証跡と指標がある、指標をもとに改善している、という並びで見る
まとめ
委託先のセキュリティ体制およびセキュリティに知識について判断するための大まかな概要を記載しました。監視と事故対応は別の機能なので分けて聞き、外部評価のスコアは安全の証拠として扱いません。
契約の前に決めるのは、事故の連絡先と通知の期限、端末とアカウントを止める権限を持つ人、サービス停止を決める人、戻せるバックアップです。受け取るログは利用者IDの形式までそろえ、検証結果は委託先の体制の段階に合わせて求めます。
かなり細かい内容も多いので、伴走しながら一緒に考えて欲しい、ベンダー選定もしてほしい、そんな場合はぜひ弊社にご相談ください。幅広い知識をもとに企業の大きさごとに最適な方法をご提案します。
参考リンク
- 東芝 サイバーセキュリティ報告書（2026年9月9日確認。2026年6月発行のA4版を参照）
- NIST SP 800-115 Technical Guide to Information Security Testing and Assessment（2026年9月25日確認）
- CISA Known Exploited Vulnerabilities Catalog（2026年9月25日確認）
- FIRST EPSS（2026年9月25日確認）
- 経済産業省 サイバーセキュリティ経営ガイドライン（2026年9月25日確認）
- SIM3 Security Incident Management Maturity Model（2026年9月25日確認）
- 報告書を読んだときの整理は note にも書いています。担当の役割分担や、把握と予防の機能ごとの詳細はそちらをご覧ください。
