委託先とクラウドの責任境界

受注基盤を委託先B社が運用し、顧客データをクラウドC社で保管する。B社の管理用アカウントに不審な操作があったが、契約には事故の報告先と期限が曖昧にしか書かれていない。技術的な対策を並べるだけでは、誰がリスクを受け入れ、誰が封じ込め、いつ報告するか決まらない。資産から残留リスクまでを一つの管理票で追う。

読む順序は、用語→実際の構成と処理→記録の照合→異常の成立条件→変更・復旧→短答演習です。以下の組織、アドレス、時刻、識別子、ログは教材用の架空例です。観測できた事実と、追加調査が必要な推論を分けて読みます。

1. 用語をこの事案の判断に結び付ける

用語	意味とこの事案での判断の限界
リスク評価	守る対象、脅威事象、弱点、起こりやすさ、被害の大きさ、既存対策を明示して対応を決める。数値は優先順位の補助であり、根拠と不確実性を消さない。
STRIDE	Spoofing、Tampering、Repudiation、Information Disclosure、Denial of Service、Elevation of Privilegeの六分類。データフローと信頼境界に脅威を問い、対策を見落とさないための手法。
残留リスク	対策を実装した後も残るリスク。受容するなら影響、監視、期限、受容者の権限と判断根拠を記録する。委託先へ作業を渡しても委託元の説明責任は消えない。
責任分界	委託元、B社、C社が、設定、認証、監視、ログ保全、連絡、復旧をどこまで担うかの境界。クラウドの責任共有モデルと個別契約の範囲を照合する。
契約・SLA	契約は実施すべき管理、再委託、監査、事故報告、終了時の返却・消去を定める。SLAは可用性や応答など測定可能なサービス水準。SLA達成は安全性の証明ではない。
報告体制	検知者、一次窓口、意思決定者、顧客・関係機関への通知判断を決める。いつから何を知っていたか、報告時刻と内容の改訂履歴を残す。
ISMS	ISO/IEC 27001に基づく情報セキュリティマネジメントシステム。リスクの評価、管理策、運用・改善の仕組みであり、認証が個々のシステムを無欠陥にするわけではない。
BCMS	ISO 22301に基づく事業継続マネジメントシステム。重要業務、必要資源、復旧目標、演習・改善を扱う。セキュリティ事故時も受注業務をどの水準で続けるかを決める。
監査	規程・契約で定めた管理策が運用され、証拠が残るかを独立した視点で評価する。監査報告書の存在だけで個々の事故対応が適切だったとは言えない。

2. 構成と判断する位置

架空のA社は顧客情報を含む受注基盤をB社へ運用委託し、B社はC社クラウドを利用する。A社は業務要件・顧客対応を、B社はアプリ運用と管理者IDを、C社は基盤設備を担当する想定だが、ログの長期保管とC社からの事故通知の仲介が未定義である。攻撃者がB社管理者IDを使えば、本番設定の変更と顧客データ取得ができる。A社の受注停止許容は4時間、前日分の注文喪失も受容できない。

委託先とクラウドの責任境界

1. 契約と作業承認
2. 設定操作
3. 運用アクセス

データと管理操作が境界を越える位置を示す。

C社の設備保護と、B社が作った管理ID・公開設定・ログ設定は別の管理対象である。A社がB社に委託していても、顧客へのサービス責任と残留リスクの受容主体を契約で明確にする必要がある。

3. 正常時の処理と管理

A社が重要業務、保護データ、受注停止や漏えいの影響、復旧目標を確定する。資産とデータフローにB社・C社の境界を入れる。
境界ごとにSTRIDEを適用し、B社管理者のなりすまし、注文データ改ざん、操作否認、情報漏えい、サービス停止、権限昇格を具体化する。
既存対策と弱点を調べ、起こりやすさ・影響・不確実性を記録し、回避、低減、移転、受容の対応を選ぶ。保険や委託による移転は被害そのものを消さない。
契約へ最小権限、MFA、ログ、再委託、事故報告、監査権、バックアップ、データ消去を落とし、各項目に実施者と検証者を置く。
定期監査と訓練で証拠を確かめ、事故・構成変更・委託先変更時にリスクと残留リスク承認を更新する。

STRIDEの名称を六つ暗記するだけでは対策は選べない。『B社管理端末→クラウド管理API』のようにデータフローを特定し、その境界で何が偽装・改ざんされるかを問う。事業影響を把握するA社と、実装を把握するB社の情報を合わせる。

4. 設定・記録のフィールドを読む

項目	読み方と注意点
asset / owner	受注基盤、顧客データ、管理ID、バックアップの所有・運用責任者。契約の会社名だけで実際の担当者を代替しない。
threat / boundary	どの主体がどの境界を越え、どのデータや操作に到達するか。STRIDE分類は具体的な事象に添える。
likelihood / impact	既存対策、露出、悪用実績、停止時間、影響人数等を根拠に評価。数字のみの『高』では再評価できない。
control / evidence	MFA、監査ログ、バックアップ等の管理策と、その有効性を示す設定・試験・ログ。規程文書と実設定を分ける。
risk owner / expiry	対策後に残るリスクを受容する権限者と期限。B社担当者がA社の事業リスクを代わりに受容しない。
report clock	B社が検知した時刻、A社へ通知した時刻、一次報告の確度、次回更新予定。契約の起点を明確にする。
SLA / recovery	応答・復旧水準、RTO/RPO、試験頻度。可用性99.9%のSLAだけではデータ完全性・事故通知を測れない。

以下は架空のリスク台帳と事故連絡記録の抜粋。『管理策あり』と『有効に働いた』を分けて読む。

text

R-21 asset=orders owner=A control=MFA+audit
  threat=B-admin impersonation impact=high residual=medium
  approved_by=none review_due=2026-10-01
INC-7 detected_by=B at=10:00 source=cloud-admin-log
INC-7 B_to_A at=14:50 confidence=preliminary
SLA availability=99.9% incident_report_deadline=undefined

R-21は残留リスクの承認者が空欄で、受容済みとは言えない。B社は10:00に検知し14:50に一次連絡したが、報告期限が未定義なので契約違反かどうかはこの記録だけでは断定できない。さらに不審な操作の成否、漏えい範囲、A社の顧客対応判断には別の証拠が要る。

5. 異常が成立する条件と証拠

状態・攻撃	成立条件、証拠、対策の位置
なりすまし	B社管理IDの奪取や共有IDを想定。端末・MFA・特権付与・操作ログの照合と緊急失効を契約と手順に含める。
改ざん	注文データや監査設定が変更可能なら、二者承認、変更差分、独立保管のログ、復元検証を求める。
否認	共有管理IDと短期ログ保存では誰が何をしたか追えない。個人識別、改ざん耐性、保管期間、時刻同期を決める。
情報漏えい	C社基盤が安全でもB社の公開設定や管理権限が過大なら流出する。設定・アクセス・配布URLを定期監査する。
サービス停止	B社だけが復旧鍵や手順を持つと、連絡不能時にA社が再開できない。代替窓口と復旧演習を定める。
権限昇格	B社の通常保守IDが本番全権限を持つ場合、承認付きの一時権限と操作対象の制限を設ける。

STRIDEの六分類は脅威を列挙するための補助であり、各分類を一件ずつ埋めれば網羅したことにはならない。委託契約上の管理責任、実際のシステム権限、事故時の連絡責任が一致しているかを継続して確認する。

6. 調査で結論を強くする順序

判定段階	必要な証拠と結論の上限
何を守るか	資産、データ、業務と停止・漏えいの影響をA社の事業部門が確定する。
誰が実行できるか	B社とC社のID、操作権限、再委託先を実設定と契約で照合する。
何が起きたか	クラウド管理ログ、アプリ監査、データ取得、変更履歴を結び、可能性と確定事実を分ける。
誰が対処を決めるか	B社が封じ込めを実行できても、受注停止・顧客通知・残留リスク受容はA社の権限者が決める。
有効だったか	MFAやログの存在ではなく、設定、権限、監視、通知、復旧演習の記録で確認する。

リスクは『脆弱性がある』という技術事実だけでなく、脅威がその弱点を突く条件と事業影響を合わせて評価する。例えば管理APIが外部公開でも、端末制限と短時間の特権付与が働く場合と、共有IDで常時全権限を持つ場合では評価が違う。根拠が不明な項目は低リスクとせず、不確実性として残す。

残留リスクの受容は対策を免除する魔法の手続ではない。対象、想定被害、実施済みの低減策、監視、期限、再評価条件、権限者を記録する。A社の経営判断が必要な事故リスクをB社の現場担当が『受容済み』として閉じるのは責任分界の誤りである。

SLAは測定式と対象期間、除外条件、違反時の扱いがなければ比較できない。例えば稼働率の基準を満たしても、顧客データの不正閲覧や遅い事故報告は発生し得る。セキュリティ要件、報告期限、証跡、RPO/RTOはSLAの稼働率とは別に契約へ明記する。

事故報告は初報時点で全容が不明でも行う設計にする。検知時刻、観測事実、未確認事項、暫定封じ込め、次報予定を伝え、後で内容を更新する。『確定してから報告』とすると判断権を持つA社の封じ込めや顧客対応が遅れる。法令や契約による通知期限は適用範囲を別途確認する。

ISMSは情報セキュリティを継続的に管理する仕組み、BCMSは混乱時に重要業務を続け回復する仕組みである。受注システムでは管理IDの漏えいを防ぐことと、受注停止後にどのデータから何時間で再開するかを両方扱う。いずれの認証も個別の管理策の実装や今回の事故の無被害を直接証明しない。

監査では『B社はMFAを採用』という回答票だけで終えず、特権IDの一覧、除外ID、最近の権限付与、ログ保存、復旧演習、再委託先の運用をサンプルで確かめる。監査対象期間と認証範囲に受注基盤が含まれるかも確認する。範囲外の認証書を全サービスの安全証明として扱わない。

契約終了時にはB社と再委託先に残るデータ、鍵、バックアップ、管理ID、ログの返却・消去と引継ぎを決める。削除証明だけでバックアップからの残存がないと断定せず、保存期間と削除方式、監査可能な証跡を確認する。

リスク評価の見直し条件には、新しい管理者接続経路、データの保存先変更、事故、監査不適合、委託先の再編を含める。同じ評価点でも前提となるデータフローが変われば対策の十分性は変わる。A社は変更通知を受けた時点で責任分界表と残留リスクの承認を再確認する。

7. 変更・障害・例外運用

運用場面	崩れやすい条件と確認
再委託	B社がC社や別の監視会社を使う場合、承認要否、同等の義務、事故報告経路、監査可能性を契約でつなぐ。
緊急変更	業務停止を避ける設定変更でも、承認者、対象、ロールバック、事後レビューを残し、B社の単独判断範囲を明確にする。
監査の不適合	指摘を受けた項目に責任者・期限・代替策を置き、是正完了の証拠を再確認する。報告書受領だけで閉じない。
事故初報	検知と一次報告の起点、週末窓口、重大度別の連絡先、報告の更新頻度を試験する。
事業継続	B社に連絡できない状況でもA社が代替運用と顧客対応を行えるか、演習で確認する。

委託先の選定時だけでなく、サービス拡張、管理API変更、再委託、事故、監査結果の変化ごとにリスクを見直す。残留リスクの承認期限を過ぎた項目は自動的に安全にならない。

8. 封じ込めと復旧条件

委託先事故の意思決定

1. 検知：対応 B社が記録を保全／確認する証跡管理操作ログ
2. 初報：対応 A社へ事実を通知／確認する証跡時刻と未確認点
3. 対処判断：対応 A社が業務影響評価／確認する証跡責任分界と影響
4. 復旧：対応 B社が実施しA社承認／確認する証跡試験と監査証跡

発見から再開まで責任者と証拠を残す。

B社は契約で与えられた緊急停止権限の範囲で実行し、A社へ速やかに報告する。A社は顧客への影響と残留リスクを評価する。C社の基盤障害が原因なら、C社からB社を経る報告遅延も検証する。

B社は不審な管理ID・操作・変更を保全し、A社へ観測事実と未確認事項を初報する。
A社とB社が責任分界に沿って特権IDの停止、設定差分の確認、漏えい範囲と受注影響を調査する。
A社は受注の継続・停止・代替運用、顧客連絡、残留リスクの暫定受容を権限者で判断する。
B社が設定復旧とID再発行を実施し、A社が注文の完全性、正常受注、ログ・監視の回復を確認する。
事故後に契約の報告時点・証跡・再委託・監査権を改訂し、演習で再確認する。

技術的な復旧と、委託元の事業判断、対外報告は別の決定である。契約に空白がある場合も連絡を止めず、暫定的な責任者と記録方法を合意して事故対応を進める。

9. 科目B（午後）の解答手順

設問の『誰が』を見落とさない。A社、B社、C社の資産・操作・報告・承認を分け、STRIDEの分類はデータフロー上の脅威に適用する。最後に残留リスクを受け入れる主体と見直し条件を書く。

脅威、弱点、既存策、影響、残留リスクを一行でつなぐ。
委託元・委託先・クラウドの責任を操作単位で分ける。
SLAと事故報告・証拠保全・RTO/RPOを分ける。
ISMS、BCMS、監査は運用証拠と対象範囲を確認する。

10. 短答演習

演習1：STRIDE

条件：B社IDで顧客データを閲覧。

質問：最初にどの境界を描くか。

解答：B社管理端末からクラウド管理API・顧客データへの境界を描く。

誤答の理由：分類名だけでは到達先と対策位置が決まらない。

演習2：承認者空欄

条件：残留リスクmedium、承認者none。

質問：受容済みか。

解答：受容されていない。A社の権限者と期限、監視を決める。

誤答の理由：管理票の登録を受容と混同している。

演習3：稼働率SLA

条件：月の稼働率99.9%を達成。

質問：事故対応は適切か。

解答：判断できない。通知、ログ、漏えい、復旧の別要件を調べる。

誤答の理由：可用性指標を全安全要件に広げている。

演習4：報告の遅れ

条件：10:00検知、14:50初報、期限記載なし。

質問：契約違反と確定できるか。

解答：契約違反はこの記録だけでは確定できない。期限を改訂し、遅延影響を調べる。

誤答の理由：未定義の期限を仮定している。

演習5：ISMS認証

条件：B社はISMS認証取得済み。

質問：受注基盤の管理設定は安全か。

解答：認証範囲と実設定・ログを別途確認する。

誤答の理由：管理システムの認証を個別環境の無欠陥と誤解している。

演習6：再開

条件：B社が管理IDを停止した。

質問：受注を再開してよいか。

解答：変更差分、注文完全性、代替ID、監視、業務試験をA社が確認する。

誤答の理由：ID停止だけでデータと業務を検証していない。

11. 一次資料

NIST SP 800-30 Rev.1：リスク評価

Microsoft：STRIDEの六分類

NIST SP 800-161 Rev.1：サプライチェーンリスク

ISO/IEC 27001：ISMS

ISO 22301：BCMS

リスク評価・STRIDE・委託先管理とISMS・BCMS