変更要約: 初版
5.2委託先・サプライチェーン管理
委託先選定と契約時のセキュリティ要件、再委託の管理、クラウド利用時の責任分界（責任共有モデル）、SLAとセキュリティ要件の盛り込み方、委託先への監査・報告義務を、具体的な委託シナリオで学びます。
自社の情報セキュリティをどれだけ固めても、業務の一部を外部に委託すれば、その委託先の管理水準が自社のリスクに直結します。サプライチェーン攻撃（委託先やソフトウェア供給元を踏み台にして本丸を狙う攻撃）が増える中、「委託先を選ぶ・契約する・監査する」という一連のプロセスをどう設計するかが、情報セキュリティ管理者の重要な実務です。
5.2.1委託先選定と契約時のセキュリティ要件
- 委託先選定の段階では、価格や納期だけでなく、委託先がどのような情報セキュリティ管理体制を持つか（ISMS認証の有無、過去のインシデント履歴、従業員教育の実施状況など）を事前に評価します。選定後に問題が発覚すると切り替えコストが大きいため、契約前のデューデリジェンス（事前調査）が重要です。
- 契約書には、委託する業務範囲だけでなくセキュリティ要件を明文化することが必須です。具体的には、預ける情報の取扱範囲・保管場所・アクセス権限を持つ者の限定、インシデント発生時の通知期限（例：発覚から24時間以内に報告）、契約終了時のデータ返却・確実な消去などを盛り込みます。口頭合意や曖昧な条項では、委託先の対応が不十分でも契約違反を問いにくくなります。
5.2.2再委託の管理とクラウド利用時の責任分界
- 再委託＝委託先がさらに別の事業者（再委託先）に業務の一部を委託すること。再委託先は自社が直接選定・契約した相手ではないため、再委託の可否を契約で事前に制限し、再委託する場合は事前の書面承諾を必須とする運用が基本です。再委託が連鎖すると、末端の再委託先まで自社のセキュリティ要件が確実に伝わっているかの確認が難しくなります。
- クラウド利用時の責任分界（責任共有モデル）＝クラウドサービス事業者と利用者の間で、どこまでを事業者が守り、どこからを利用者が守るかを明確にする考え方。一般に、物理的な基盤・ハードウェア・ハイパーバイザーの安全性はクラウド事業者側、データの暗号化設定・アクセス権限設定・OS/ミドルウェアのパッチ適用（IaaSの場合）は利用者側が責任を負う、というようにサービス形態（IaaS/PaaS/SaaS）によって分界線が変わる点が重要です。
「クラウドの責任分界はサービス形態（IaaS/PaaS/SaaS）によって変わる」「再委託は契約で事前制限し、行う場合は書面承諾を必須にする」「委託先選定はデューデリジェンスを契約前に行う」「契約書にはセキュリティ要件（通知期限・データ消去等）を明文化する」が最頻出です。「クラウド事業者がすべての責任を負う」という誤認や、「口頭合意で足りる」という誤りが典型的な誤答パターンです。
5.2.3SLAとセキュリティ要件、監査・報告義務
- SLA（Service Level Agreement・サービスレベル合意書）＝委託先が提供するサービスの品質水準を数値で約束する合意書。稼働率や応答時間だけでなく、セキュリティに関する項目（脆弱性診断の実施頻度、インシデント発生時の対応時間、監査への協力義務など）もSLAに含めることで、抽象的な「しっかりやってください」ではなく検証可能な基準として運用できます。
- 委託元は委託先に対して定期的な監査（実地監査・書面監査・第三者認証の確認など）を行い、契約・SLAで定めたセキュリティ要件が実際に守られているかを検証する責任があります。また、委託先でインシデントが発生した場合の報告義務を契約に明記し、発覚から一定時間内の第一報、その後の詳細報告という段階的な報告フローを取り決めておくことで、被害拡大時の初動が遅れるのを防ぎます。
あるECサイト運営企業が、決済処理を外部のクラウド型決済代行サービス（SaaS）に委託する場面を例に考えます。委託先選定の段階で、情報システム部門は候補企業3社に対しISMS認証の有無・過去のインシデント公表履歴・従業員教育の実施状況を確認するデューデリジェンスを実施し、認証を保有し過去3年間の重大インシデントがない事業者を選定しました。契約締結にあたっては、SLAに「四半期ごとの脆弱性診断結果の報告」「インシデント発覚から4時間以内の一次報告義務」「監査への年1回の協力義務」を数値・期限つきで明記しました。運用が始まると、決済代行サービスはSaaSであるため、クレジットカード情報の暗号化やサーバーの物理セキュリティは決済代行事業者側の責任であり、自社が直接管理するのは主に自社サイトから決済代行サービスへ受け渡すAPIキーの管理や、決済フローに組み込む自社側のフロントエンド実装に限られる、という責任分界を情報システム部門は正しく認識していました。ある日、決済代行事業者がさらに一部のログ解析業務を別の事業者へ再委託しようとしていることが判明しましたが、契約書に「再委託には委託元の事前書面承諾を要する」という条項があったため、ECサイト運営企業は再委託先のセキュリティ体制を確認した上で承諾するというプロセスを踏むことができました。もしこの条項がなければ、自社の顧客の決済情報が、選定プロセスを経ていない再委託先に無断で渡ってしまうリスクがありました。半年後の定期監査では、契約時に定めたSLAの「四半期ごとの脆弱性診断結果の報告」が1回未達成であったことが判明し、情報システム部門はこれを契約不履行として是正要求を行いました。このように、選定時のデューデリジェンス→契約への要件明文化→運用中の責任分界の正しい理解→再委託の事前承諾→定期監査による検証という一連の流れを設計しておくことで、委託先の管理水準の変化や再委託の連鎖を組織として把握し続けることができます。
| サービス形態 | 事業者側の主な責任 | 利用者側の主な責任 |
|---|---|---|
| IaaS | 物理基盤・ハードウェア・仮想化基盤 | OS/ミドルウェアのパッチ適用・アクセス設定 |
| PaaS | 物理基盤に加えOS/ミドルウェアの管理 | アプリケーションの実装・データ管理 |
| SaaS | アプリケーション基盤全体の管理 | アカウント管理・データの取扱設定 |
ひっかけ： 「クラウドサービスを利用すればセキュリティの責任はすべてクラウド事業者に移る」は誤りです。サービス形態に応じて利用者側にも残る責任範囲（アクセス設定、データの取扱、IaaSであればOS/ミドルウェアのパッチ適用など）が必ずあります。また「再委託は委託先の裁量で自由に行ってよい」も誤り＝契約で事前の書面承諾を必須にするのが基本です。さらに「SLAは稼働率などの性能面のみを定めるものでセキュリティとは無関係」も誤り＝セキュリティに関する項目（脆弱性診断頻度・インシデント対応時間等）もSLAに含めて検証可能にするのが実務です。
5.2.4この節のまとめ
- 委託先選定は契約前のデューデリジェンスが重要。契約書にはセキュリティ要件を明文化する
- 再委託は契約で事前制限し、行う場合は書面承諾を必須にする
- クラウドの責任分界（責任共有モデル）はサービス形態（IaaS/PaaS/SaaS）で変わる。SLAにセキュリティ項目を含め定期監査で検証する
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. IaaS型のクラウドサービスを利用してサーバーを構築した。OSへのセキュリティパッチ適用の責任は誰が負うか。
Q2. 委託先が、契約で定めた業務の一部をさらに別の事業者へ再委託しようとしている。委託元として最も適切な対応は？
Q3. SLA（サービスレベル合意書）に盛り込む内容として、セキュリティ管理の観点から最も適切なのは？