ベンダー丸投げを防ぐ責任分解チェック
はじめに
大企業では、システムに強い人材と弱い人材が同じ組織に混在します。事業部門がシステムオーナーになっているが、実際の設計・構築・運用は外部ベンダーが担っている。SaaSやPaaSの設定も、社内では詳細を理解できず、運用ベンダーに任せている。こうした状態は珍しくありません。
このとき、「このシステムはMFAに対応していますか」「ログは取得していますか」「脆弱性対応はしていますか」といったチェック項目をベンダーへ投げると、ベンダー視点の回答が返ってくることがあります。
たとえば、SaaSベンダーやクラウド事業者が基盤側でログや暗号化や可用性対策を提供しているため、運用ベンダーが「対応済み」と回答する。しかし実際には、顧客テナント側の設定、IdP連携、権限レビュー、ログ転送、退職者無効化、データ分類、監視ルールは未整備のまま残っている。このギャップが危険です。
クラウドでは責任共有モデルが前提です。AWSは、クラウドのセキュリティとクラウド内のセキュリティを分け、サービス選択によって顧客責任が変わると説明しています。1 Microsoftも、SaaS/PaaS/IaaSで責任分担が変わる一方、データ、ID、アクセス管理など顧客が常に保持する責任があると整理しています。2 Google Cloudは、共有責任モデルで残る課題を踏まえ、継続的に安全性を高める「shared fate」の考え方を示しています。3
この記事では、ベンダーに丸投げしても、少なくとも責任分解が崩れた回答になりにくいように、チェック項目と統制項目の設計方法を整理します。
全体像
ポイントは、質問を「対応していますか」ではなく、誰が、どの範囲で、どの証跡をもって、何を未対応として残しているかまで回答させる形に変えることです。
何が危険なのか
ベンダーの「対応済み」は範囲が狭いことがある
ベンダーが「ログ取得済み」と回答しても、それがSaaS基盤の監査ログなのか、顧客テナントの操作ログなのか、社内SIEMへの転送なのか、アラート調査記録なのかは分かりません。
ベンダーが「脆弱性対応済み」と回答しても、それがクラウド基盤の脆弱性なのか、PaaS上で動く自社コードなのか、利用ライブラリなのか、設定不備なのかは分かりません。
「対応済み」という回答は、責任主体、対象範囲、証跡、未対応範囲が分からなければ、説明責任には使えません。
SaaS/PaaSは責任境界が見えにくい
IaaSは比較的分かりやすく、OS、アプリ、データ、設定の多くは利用者側に残ります。一方で、PaaSやSaaSは基盤やアプリの一部が事業者側へ移るため、「どこまで任せたのか」が曖昧になりやすい領域です。
SaaSでは、アプリケーション本体は事業者が提供しますが、顧客テナントの設定、ID連携、権限、データ分類、外部連携、監査ログの保管、利用者教育は顧客側に残ることが多いです。Salesforceも、顧客データ、設定、アクセス権限の保護は顧客の責任として説明しています。4
ベンダー丸投げ体質が責任分解をさらに曖昧にする
システムオーナーが技術的に弱く、運用をベンダーに任せきりにしている場合、チェック項目の回答者もベンダーになります。すると、顧客として受容すべきリスク、顧客が承認すべき設定、顧客が教育すべき利用者、顧客が保持すべきログまで、ベンダー回答の中に埋もれます。
デジタル庁のDS-203も、委託元と委託先が果たすべき責任を合意し、理解する必要があること、曖昧な責任分界がリスクになることを示しています。5 NIST SP 800-161 Rev.1も、サプライチェーンにおける可視性や理解の低下がリスクにつながるとして、組織の複数レベルでサプライチェーンリスクを管理する考え方を示しています。6
設計原則
質問を能力確認ではなく責任分解にする
悪い質問は、製品機能やベンダー作業の有無だけを聞きます。
- MFAに対応していますか
- ログを取得していますか
- 脆弱性診断をしていますか
- バックアップを取得していますか
よい質問は、主体、範囲、証跡、例外を分けます。
- MFAを誰が強制し、どの利用者・管理者・外部委託IDに適用し、未適用IDは誰が承認していますか
- どのログを、誰の責任で、どこへ、何日以内に転送し、誰が調査しますか
- ベンダー基盤、顧客設定、自社コード、OSS、SaaS連携ごとに、脆弱性対応責任者とSLAを分けていますか
- バックアップは誰が取得し、誰が復元試験し、RTO/RPO未達を誰が受容していますか
回答欄を分ける
自由記述欄だけにすると、ベンダーは自分の得意な範囲を説明します。回答欄を最初から分けます。
| 回答欄 | 書かせること |
|---|---|
| クラウド/SaaS事業者責任 | 基盤、物理、標準機能、事業者運用の範囲 |
| 運用ベンダー責任 | 設計、設定、運用、監視、報告、一次対応の範囲 |
| 顧客責任 | 承認、リスク受容、利用者管理、データ分類、業務判断の範囲 |
| 再委託先責任 | 再委託、オフショア、サポート、SOC、保守会社の範囲 |
| 証跡 | 一次証跡、レポート、契約、ログ、チケット、設定エクスポート |
| 未対応・例外 | 対象外、未実装、期限、代替統制、承認者 |
「対象外」を禁止せず、理由を書かせる
大企業では対象外や例外は必ず出ます。重要なのは、「対象外」と書いて終わらせないことです。
対象外の場合も、理由、判断者、再評価条件を求めます。たとえば「SaaS標準機能によりOSパッチは顧客管理対象外。ただし、顧客テナント設定と外部連携アプリは顧客責任」と書かせます。
顧客が承認すべき事項を分離する
ベンダーが作業を代行しても、顧客が承認すべきものがあります。
- 特権IDの付与
- 監査ログの保持期間
- 個人情報や機密情報の保管場所
- バックアップのRTO/RPO
- 例外リスクの受容
- 再委託・オフショア・サポートアクセス
- SaaSの外部共有設定
これらをベンダー作業欄に埋めず、「顧客承認欄」として分けます。
回答テンプレート
チェック項目ごとに、次の形で回答させると責任分解が崩れにくくなります。
| 項目 | 回答内容 |
|---|---|
| 統制目的 | 何のリスクを下げるための統制か |
| 対象範囲 | 対象システム、環境、SaaSテナント、データ、利用者 |
| 責任分担 | SaaS/PaaS事業者、運用ベンダー、顧客、再委託先の分担 |
| 実装状態 | 実装済み、部分実装、未実装、対象外 |
| 証跡 | 設定、ログ、チケット、監査報告、契約、画面ではなく原本リンク |
| 鮮度 | 証跡取得日、更新頻度、次回確認日 |
| 未対応・例外 | 残っているリスク、期限、代替統制、承認者 |
| 顧客判断 | 顧客が承認・判断すべき事項 |
このテンプレートは、システムに詳しくないシステムオーナーにも有効です。回答を読むだけで、「ベンダーが対応したこと」と「自社が判断すべきこと」を分けられるからです。
悪い質問と改善後の質問
| 領域 | 悪い質問 | 改善後の質問 |
|---|---|---|
| MFA | MFAに対応していますか | 管理者、一般利用者、外部委託ID、API/サービスアカウントごとに、MFAまたは同等統制の適用責任者、未適用例外、証跡を示してください |
| ログ | ログを取得していますか | SaaS基盤ログ、顧客テナント操作ログ、管理者操作ログ、API連携ログ、認証ログを分け、取得者、保管先、保持期間、調査責任を示してください |
| 脆弱性 | 脆弱性対応していますか | クラウド基盤、PaaSランタイム、自社コード、OSS、SaaS設定、外部連携ごとに、検出方法、対応責任者、SLA、例外承認者を示してください |
| バックアップ | バックアップしていますか | 誰が取得し、どのデータを対象にし、復元試験を誰が実施し、RTO/RPO未達を誰が承認するかを示してください |
| アクセス権 | 権限管理していますか | 権限設計、付与承認、棚卸し、退職者無効化、特権ID利用ログを、顧客責任とベンダー代行作業に分けて示してください |
| 委託先管理 | 再委託はありますか | 再委託先、オフショア、サポートアクセス、再委託先の管理策、事故時の報告ルート、顧客承認有無を示してください |
| データ保護 | 暗号化していますか | 保存時/転送時暗号化、鍵管理者、鍵ローテーション、顧客管理鍵の有無、ベンダー運用者の復号可能性を示してください |
| インシデント | インシデント対応できますか | 検知者、一次対応者、顧客通知SLA、証跡保全、法務判断、広報判断、再発防止責任を分けて示してください |
改善後の質問は長く見えますが、曖昧な回答を防げます。大企業では、短い質問で曖昧な回答を集めるより、最初から回答の構造を指定したほうが総コストは下がります。
統制項目説明一覧例
以下は、SaaS/PaaS/ベンダー運用を前提にした統制項目の例です。実際にはシステム重要度やデータ種別に応じて絞り込みます。
| 統制項目 | 狙い | 責任分解で確認すること | 主な証跡 |
|---|---|---|---|
| 責任分界表 | 誰が何を守るかを曖昧にしない | SaaS/PaaS事業者、運用ベンダー、顧客、再委託先の責任を統制ごとに分けているか | 責任分界表、契約、SOW、運用設計書 |
| テナント設定管理 | SaaS標準機能の設定ミスを防ぐ | 設定方針は顧客が承認し、設定作業は誰が実施し、変更は誰がレビューするか | 設定エクスポート、変更チケット、承認記録 |
| ID連携とMFA | 不正ログインと退職者残存を防ぐ | IdP管理者、SaaS管理者、外部委託ID、サービスアカウントの責任が分かれているか | IdP設定、MFA適用一覧、例外承認 |
| 特権ID管理 | 管理者権限の乱用を防ぐ | 特権付与承認、利用ログ、緊急ID、ベンダー管理者IDを分けているか | 特権ID一覧、PAMログ、棚卸し記録 |
| ログ取得と保管 | 事故時の追跡可能性を確保する | 基盤ログ、テナントログ、認証ログ、APIログの取得責任と保管先が明確か | ログ設定、SIEM転送設定、保管ポリシー |
| ログ調査責任 | ログがあるだけで終わらせない | 誰がアラートを見るか、誰が調査し、誰が顧客へ報告するか | アラートチケット、調査記録、月次報告 |
| PaaSランタイム管理 | PaaSで残る顧客責任を見落とさない | ランタイム、依存ライブラリ、環境変数、シークレット、デプロイ設定の責任者は誰か | CI/CDログ、構成管理、SCA結果 |
| SaaS外部共有 | 意図しない公開や外部共有を防ぐ | 共有リンク、ゲストユーザー、外部ドメイン許可を誰が承認するか | 共有設定一覧、ゲスト一覧、承認記録 |
| データ分類と保存場所 | 機密情報の扱いを業務判断に戻す | どのデータを入れてよいか、国外保存やサポートアクセスを誰が承認するか | データ分類表、DPA、リージョン設定 |
| 鍵管理 | 暗号化を設定名だけで終わらせない | 鍵を誰が管理し、ベンダーが復号可能か、顧客管理鍵を使うか | KMS設定、鍵管理手順、アクセスログ |
| バックアップと復元 | 取得ではなく戻せることを確認する | 取得者、対象、復元作業者、復元承認者、RTO/RPO受容者を分ける | ジョブ結果、復元試験記録、例外承認 |
| 脆弱性管理 | 基盤と顧客管理範囲を分ける | 事業者基盤、自社コード、OSS、設定不備、外部連携ごとに責任者とSLAがあるか | スキャン結果、SCA、修正チケット |
| 設定ドリフト管理 | 運用中の設定逸脱を検知する | 標準設定、例外設定、変更承認、是正責任を分けているか | CSPM/SSPM結果、変更履歴 |
| インシデント通知 | 事故時の責任押し付けを防ぐ | 検知、初動、顧客通知、法務判断、証跡保全、再発防止の責任者は誰か | 連絡体制、通知SLA、訓練記録 |
| 再委託管理 | 見えない委託先を減らす | 再委託先、オフショア、サポート拠点、アクセス権、事故時報告が明確か | 再委託一覧、承認記録、監査報告 |
| 終了・移行時管理 | 契約終了後の残存リスクを防ぐ | データ返却、削除証明、アカウント無効化、ログ引継ぎの責任者は誰か | 削除証明、移行計画、無効化記録 |
この一覧の目的は、ベンダーを細かく詰めることではありません。自社が持つべき判断と、ベンダーが代行できる作業と、クラウド/SaaS事業者へ継承できる統制を分けることです。
サービスモデル別の聞き方
SaaSの場合
SaaSでは、製品自体の安全性よりも、顧客テナントの設定と利用者管理が抜けやすいです。
聞くべきことは、次のような領域です。
- テナント管理者は誰か
- SSO/MFAを誰が強制するか
- 外部共有、ゲスト、API連携を誰が承認するか
- 管理者操作ログを誰が取得し、どこへ保管するか
- ベンダーサポートのテナントアクセスをどう承認・記録するか
- 契約終了時にデータ返却・削除を誰が確認するか
PaaSの場合
PaaSでは、OSやミドルウェアの一部は事業者側へ移りますが、自社コード、設定、シークレット、CI/CD、依存ライブラリの責任は残ります。
聞くべきことは、次のような領域です。
- ランタイム更新は自動か、顧客が選択するのか
- 自社コードとOSSの脆弱性を誰が検出・修正するか
- 環境変数やシークレットを誰が管理するか
- デプロイ権限と承認フローは誰が持つか
- アプリログと基盤ログの境界はどこか
- WAF、認証、ネットワーク制御は誰が設定するか
IaaSの場合
IaaSでは、顧客側の責任が広く残ります。AWSが例示するように、EC2のようなIaaSではゲストOS、パッチ、アプリ、セキュリティグループ設定などが顧客責任になります。1
聞くべきことは、次のような領域です。
- OSパッチを誰が適用するか
- EDRやログエージェントを誰が導入・監視するか
- ファイアウォールやセキュリティグループを誰が承認するか
- AMI/イメージの脆弱性を誰が管理するか
- バックアップと復元試験を誰が実施するか
- 運用ベンダーの管理者アクセスを誰が監督するか
導入ステップ
1. まず責任主体を固定する
回答者を「ベンダー」だけにしないで、最低限次を分けます。
- SaaS/PaaS/クラウド事業者
- 構築・運用ベンダー
- 自社システムオーナー
- 自社セキュリティ/リスク管理部門
- 再委託先、サポート拠点、SOC
2. 重要システムから始める
全システム一斉ではなく、顧客データ、決済、認証、外部公開、基幹業務、重要SaaSから始めます。最初は10〜20個の代表システムで、回答が崩れやすい質問を洗い出します。
3. 質問票ではなく回答様式を標準化する
質問項目だけを標準化しても、回答の粒度が揃いません。責任分担、証跡、例外、顧客判断を含む回答様式を標準化します。
4. 契約・SOW・運用設計に反映する
チェック項目だけで運用すると、回答は一時点で終わります。責任分解をSOW、運用設計書、月次報告、インシデント通知SLA、再委託承認に反映します。
5. 監査では回答ではなく分解の妥当性を見る
内部監査やセキュリティレビューでは、「対応済みか」だけでなく、責任分解が正しいかを見ます。特に、顧客責任がベンダー回答に吸収されていないか、クラウド事業者責任を顧客責任と誤認していないかを確認します。
まとめ
SaaSやPaaSを使うほど、ベンダーに任せられる範囲は広がります。ただし、責任が消えるわけではありません。クラウド/SaaS事業者、運用ベンダー、顧客、再委託先の間で、責任が移動し、分割されるだけです。
大企業でベンダー丸投げ体質が残っている場合、普通のチェック項目ではベンダー視点の「対応済み」が集まりがちです。これを防ぐには、質問そのものを責任分解型に変える必要があります。
実務上の要点は次の3つです。
- 「対応していますか」ではなく、誰が、どの範囲で、何を証跡にしているかを聞く
- ベンダー責任、顧客責任、クラウド/SaaS事業者責任、再委託先責任を回答欄で分ける
- 未対応や対象外を禁止せず、理由、代替統制、承認者、再評価日を必ず残す
この設計に変えると、ベンダーに回答作成を任せたとしても、自社が判断すべき責任とリスクが見えやすくなります。