Capital One が示した、クラウド契約の限界と制御証拠の始まり

要約

• Capital One の2019年の侵害は、コントロールの不一致を露呈した。法的およびクラウド業界の責任モデルはどの階層を誰が所有するかを記述できるかもしれないが、インシデントは実際の証拠、つまり設定、メタデータアクセス、ID 権限、ロギング、検出に関する実際の証拠を中心に展開した。
• 新鮮なレンズは、契約と制御証拠の比較である。クラウド侵害において、説明責任は「顧客の責任」または「プロバイダの責任」という言葉で終わらない。それは、どの主体がリスクのある経路を確認でき、変更でき、警告でき、事後にその境界が管理されていたことを証明できるか、を問う。
• 公開記録は、このインシデントを、誤設定された Web アプリケーションファイアウォールロールと Amazon Web Services に保存されたデータへのアクセスに関連付けている。本分析では、これらの記録を使用して、Capital One の運用制御を調査するが、共有責任を一方的な防御または一方的な告発に還元するものではない。
• 金融サービス規制当局は、このインシデントを単一のエクスプロイトとしてではなく、リスク管理とガバナンスの問題として扱った。これは、銀行がクラウド容量を購入しても、顧客データの管理を証明する義務を外部委託できないため重要である。
• 永続的な教訓は、クラウド契約には証拠層が必要であるということだ。すなわち、ID ポリシー、ネットワーク制約、メタデータ保護、ログ取得、警告経路、自動チェック、実際のインシデントに耐えるボード可読のリスクメトリクスである。

証拠記録とその使用方法

以下の情報源は異なる主張に使用される。Capital One と規制当局の記録はインシデントの時系列、顧客通知、執行コンテキストを確立する。DOJ 資料は、公的記録レベルでの申し立てられた侵入経路を確立する。AWS の文書は、クラウド環境で利用可能な共有責任モデルとメタデータサービスの制御を説明する。セキュリティ基準と攻撃リファレンスは、制御フレーミングを提供するが、非公開の調査結果ではない。

共有責任は曖昧さの共有ではない

Capital One の侵害は、人々がクラウド責任についてどのように語るかの公のテストとなった。「共有責任」というフレーズは、プロバイダがクラウドを保護し、顧客がクラウド内に構築するものを保護するということを明確にする場合に有用である。それが霧のように機能するとき危険になる。侵害後、一般の人々はスローガンを必要としない。顧客、規制当局、取締役会、クラウド購入者は、実際の障害経路にどのような制御が存在したかを示す証拠を必要とする。

公開記録は、Capital One のデータへの不正アクセスが Amazon Web Services に保存され、誤設定されたウェブアプリケーションファイアウォールとクラウドメタデータアクセスが中心的な役割を果たしたと説明している。この事実パターンは、単純なプロバイダの過失または顧客の過失に集約されるものではない。AWS は環境、メタデータサービス、ID ツール、責任モデルを提供した。Capital One はそのアプリケーション、設定、ロール権限、モニタリング、ガバナンスを設計し運用した。攻撃者はこれらの選択が交わる境界を悪用した。

これが契約対制御のレンズが重要である理由である。契約は、顧客がアプリケーションと ID の設定に責任があると言うかもしれない。しかし、規制当局は依然として、銀行がその設定が安全であることをどのように知っていたかを問うだろう。自動チェックは危険な権限を検出したか？セキュリティレビューは SSRF 経路をテストしたか？メタデータアクセスにはアプリケーションに適した保護が必要だったか？ログは異常なアクセスを迅速に示したか？WAF ロールは必要な権限のみを持っていたか？リーダーは侵害前に例外を確認できたか？

共有責任は市場機能も持つ。それはクラウド顧客に何に投資すべきかを伝える。モデルが弁護士とアーキテクチャチームだけに理解されているなら、データを保護しない。銀行はモデルを運用制御に変換しなければならない：ガードレール、ポリシーとしてのコード、ID 境界、ネットワークセグメンテーション、メタデータ保護、アラート、インシデントプレイブック、独立した検証、取締役会報告。責任は、測定可能な制御状態を生み出すときにのみ実用的になる。

この侵害は、クラウド成熟度がクラウド採用と同じではないことを示した。Capital One は高度なクラウドユーザーと広く見なされていたが、それでもインシデントは発生した。そのため、教訓はより深刻になる。洗練された銀行で境界障害が発生した場合、成熟度の低い機関は、自社のクラウドプログラムが制御証拠が必要な箇所で契約文言に依存していないという強力な証明を必要とする。

メタデータ経路が設定の問題をデータイベントに変えた

メタデータサービスの側面は、ローカルアプリケーションの欠陥がクラウド ID 問題にどのようになるかを示すため重要である。現代のクラウド環境では、コンピュートインスタンスはメタデータサービスからの一時的な資格情報を使用して他のリソースにアクセスできる。この設計はハードコードされた秘密を回避し、静的資格情報よりも安全であることが多い。しかし、アプリケーション経路がメタデータを要求するように誘導でき、アタッチされたロールが広範なアクセス権を持つ場合、攻撃者はウェブ向けの脆弱性からクラウドリソースアクセスに移行できる。

それはメタデータサービスが本質的に壊れていることを意味しない。リスクは周囲の制御に依存する：アプリケーション入力処理、ネットワークエグレスルール、メタデータサービス設定、ロール権限、ロギング、モニタリング。安全な自動化を可能にする同じクラウド機能が、ID 境界が過度に寛容であるか SSRF に対して防御されていない場合に橋渡しとなる可能性がある。制御の問いは、組織がメタデータを目に見えない配管ではなく特権インターフェースとして扱ったかどうかである。

IMDSv2、IAM ロール、多層防御 SSRF ガイダンスに関する AWS の現在のドキュメントは、制御表面を読みやすくするため有用である。セッション指向のメタデータアクセス、制限的なホップ動作、最小特権、アプリケーション層防御は抽象的なベストプラクティスではない。これらは価値の高い内部サービスをより困難なターゲットにする方法である。本記事は現在のドキュメントを使用して2019年の義務を正確な遡及で書き換えるものではない。現代のクラウド説明責任がどのような証拠を要求すべきかを示すために使用する。

Capital One の侵害は、最小特権が意図のレベルに留まることができない理由も示す。正当な運用上の理由でロールが存在するかもしれないが、それに付与された権限が、ロールが意図しない経路を介して到達されたときの爆発半径を決定する。WAF ロールがアプリケーション機能に厳密に必要とされるよりも多くのデータにアクセスできた場合、誤設定はより重大になった。正しい問いはロールが存在したかではない。侵害前に誰かがロールの特権が狭い運用上のニーズに一致していることを証明できたかである。

成熟したクラウドプログラムはそのような証明を日常的にすべきである。オブジェクトストアへの広範なアクセス権を持つロールを自動検出し、アプリケーション所有者と照合し、例外に有効期限を要求し、既知の SSRF クラスをテストし、可能な場合はメタデータを制限し、資格情報が異常な方法で使用された場合に警告する。この証拠はインシデント前に利用可能であるべきである。侵害後にのみ組み立てられるなら、失敗を説明できても防止できない。

契約は義務を割り当て、規制当局はリスク管理を検査する

OCC と連邦準備制度の記録が重要なのは、金融規制当局がこの侵害を単なる技術的驚きとして扱わなかったためである。彼らは規制対象の銀行組織におけるリスク管理の問題として扱った。この区別は重要である。銀行はクラウドプロバイダと契約できるが、顧客データの保護、運用リスクの管理、第三者および内部統制が有効であることの証明に責任を持つ。

規制環境では、共有責任図は出発点に過ぎない。監督者は、経営陣がリスクを理解し、統制を実施し、テストし、不備を修正し、懸念をエスカレートしたかどうかを問う。銀行の義務は、クラウドプログラムに対するガバナンスを含み、プロバイダへの契約上の依存だけではない。クラウド採用がインフラストラクチャ決定の速度と規模を変える場合、この義務は特に重要になる。誤設定は、従来の調達プロセスがレビューを招集するよりも速く何百万もの記録を露出させる可能性がある。

規制上の説明責任はまた、証拠が適切なレベルに到達したかどうかを問う。セキュリティエンジニアはロールが広範であることを知っているかもしれない。クラウドアーキテクトはメタデータ保護が存在することを知っているかもしれない。リスクオフィサーは移行プログラムが戦略的であることを知っているかもしれない。取締役はクラウド採用が競争力の中心であることを知っているかもしれない。しかし、誰もが技術的な例外をリスク言語に変換しなければ、監視はパフォーマティブになる。取締役会は、クラウドは設計上安全であると聞くが、実際の設計には未レビューの例外が含まれている。

契約と制御の不一致がここに現れる。契約は、顧客が ID およびアクセス管理を制御すると言うことができる。しかし、リスク管理はその制御がどのように実行されるかを示さなければならない。IAM ポリシーは誰が承認するか？WAF ルールはどのようにレビューされるか？ストレージバケットはどのように分類されるか？メタデータ保護はどのように実施されるか？アラートはどのようにトリアージされるか？どの例外が受け入れられ、どのくらいの期間か？どの第三者依存関係が集中リスクを生み出すか？答えは調達サマリーではなく、運用証拠に基づいていなければならない。

Capital One の公開提出書類は、侵害がどのようにエンタープライズイベントになるかを示している。同社は費用、訴訟、リスク要因を開示した。その証券記録は、消費者通知と規制執行の隣にある。クラウド制御の失敗は、顧客の信頼、訴訟、コンプライアンス、市場開示、ガバナンスに影響を与えた。問題は、銀行がクラウド契約を持っていたかどうかだけではなかった。銀行が公の監視の下でクラウド運用モデルに対する制御を示すことができたかどうかであった。

検出証拠はインシデントと不確実性の間の分水嶺である

クラウド侵害の後、検出証拠は組織がどれだけ迅速に被害を狭めるかを決定する。ログ、オブジェクトアクセス記録、ID トレイル、ネットワークイベント、異常アラートは範囲特定の基礎となる。それらがなければ、企業は不確実性を強いられ、不確実性は顧客と規制当局に広がる。Capital One の侵害は、クラウドロギングがオプションの計装ではない理由を示している。それはシステムの記憶である。

公開記録は、インシデントが定期的な内部防止のみではなく外部報告によって明らかになったことを示している。その事実は検出証拠の説明責任バーを引き上げる。規制対象の銀行は、ロールが異常な方法で使用されているか、データストアが列挙されているか、アクセスパターンが期待されるアプリケーション動作と一致しているか、公開リポジトリや外部シグナルが盗まれたデータを示しているかを知るべきである。クラウド環境はリッチなテレメトリを生成できる。ガバナンスの問いは、組織がそれを収集、保持、行動するかである。

クラウドシステムでの検出には特別な課題がある：正当な自動化はノイズのように見えることがある。アプリケーションは絶えずデータを読み書きする。ロールは設計どおりに資格情報を引き受ける。開発者は迅速に構成をデプロイする。この正常な動作は、組織が期待される動作を正確に定義しない限り、悪用を隠すことができる。最小特権プログラムは正常な動作の空間を減らす。強力なロギングプログラムは逸脱を記録する。調整されたアラートプログラムは逸脱を行動に変える。それらのどれも契約には現れない；すべてがインシデント証拠に現れる。

顧客にとって、検出証拠は通知の質に影響する。銀行がどのデータカテゴリがアクセスされたか、どのアカウントが影響を受けたか、何が侵害されなかったか、どのような是正措置が取られているかを言える場合、顧客はより合理的に行動できる。銀行がインシデントを狭めることができなければ、顧客は広範な不安を引き継ぐ。侵害の公的コミュニケーションはしたがって、ほとんどの消費者が決して見ることのない技術的テレメトリに依存した。その非対称性が、規制当局が制御証拠を気にする理由である。

検出はクラウドアーキテクチャにフィードバックされるべきである。ロールの動作が悪用と区別するのが難しい場合、ロールが広すぎるかアーキテクチャが不透明すぎる。メタデータ資格情報の使用が期待されるワークロードに結び付けられない場合、ID 境界は弱い。アラートがまれな外部報告に依存する場合、保持するデータに対してモニタリングは十分に成熟していない。クラウドプログラムは、フォレンジックが必要になる前にフォレンジックの明確さを設計すべきである。

顧客コミュニケーションは精度と安心の間にある

Capital One は何が起こったか、誰が影響を受けたか、どのデータタイプが関与したか、会社が何をするかを顧客に伝えなければならなかった。これは難しい。なぜならクラウドインシデントはしばしば一般顧客が理解しない技術的経路を含むからだ。「誤設定されたウェブアプリケーションファイアウォール」のようなフレーズは正確だが、ID 盗難を心配する人には意味がない。コミュニケーションは隠蔽せずに翻訳しなければならない。

同社はまた、2つの逆の失敗を避けなければならなかった。過度に技術的なメッセージは実務上のリスクを曖昧にする可能性がある。過度に安心させるメッセージは不確実性を最小化する可能性がある。適切な通知は、データカテゴリ、可能性のある悪用経路、保護措置、サポート、調査の限界を平易な言語で説明する。顧客が自分自身を保護するためにメタデータサービス、IAM ロール、SSRF を理解する必要があるべきではない。しかし、それらの詳細が無関係であると装うべきでもない。なぜなら、それらの詳細は侵害がなぜ発生したか、何を変える必要があるかを説明するからである。

クラウド契約はコミュニケーションを複雑にする可能性がある。顧客がデータがクラウドに保存されたと聞くと、クラウドプロバイダが失敗したかどうか尋ねるかもしれない。企業が問題は自社の設定であると言う場合、顧客はなぜ検出されなかったか尋ねるかもしれない。企業が犯罪行為を強調する場合、顧客はなぜ経路が存在したか尋ねるかもしれない。各回答は、顧客データを管理する当事者に説明責任を保持しながら、共有責任の境界を尊重しなければならない。これはナラティブな課題であるが、ガバナンスの課題でもある。

和解のコンテキストは別の層を追加する。消費者救済、クレジットモニタリング、払い戻しプロセスがコミュニケーション記録の一部になる。顧客が救済を容易に理解またはアクセスできない場合、侵害対応は影響を受ける人口に作業を転送する。和解サイト、サポート資料、継続的更新の質は重要である。なぜならコミュニケーション経験は、顧客が直接使用できる数少ない制御の1つだからである。

より広範な教訓は、クラウドの透明性は侵害前に計画されるべきであるということである。企業は、プロバイダが保護するもの、会社が保護するもの、何が失敗したか、何が変わっているか、顧客が何をできるかを人間の言葉で説明する準備をすべきである。その説明は、法的レビューがすべての文を狭めた後に即興で行われるべきではない。銀行の信頼性は、正確であり有用であることに依存する。

セキュリティ自動化はミスマッチを防止または増幅する可能性がある

Capital One の侵害はセキュリティ自動化の教訓でもある。自動化はしばしばクラウドの速度への答えとして推進される。それは部分的に正しい。自動チェックは危険な IAM ポリシー、公開ストレージ露出、欠落した暗号化、異常なネットワーク経路、安全でないメタデータ設定を検出できる。ポリシーとしてのコードは、本番に到達する前にリスクのあるデプロイを停止できる。継続的モニタリングはクラウドのドリフトを目に見える例外に変えることができる。しかし、自動化は間違ったものをチェックしたり、誰も所有しない結果を報告する場合、誤った自信を生み出すこともある。

実用的なクラウド制御プログラムは、高リスクパターンに必須のガードレールを定義すべきである。ウェブ向けコンポーネントは、明示的なレビューなしにメタデータや広範なデータストアに到達できないようにすべきである。境界コンポーネントにアタッチされたロールは狭くすべきである。ストレージアクセスは分類され監視されるべきである。SSRF テストはアプリケーションセキュリティの一部であるべきである。例外には有効期限が必要である。高リスクの変更は、リスク所有者が検査できる証拠を生成すべきである。これらの制御は書類作業ではなく、契約を実際の行動に結び付ける機械である。

自動化はスケールにも役立つ。大規模銀行は数千のリソース、ロール、ポリシーを運用する。手動レビューだけでは追いつけない。しかし、自動化された制御には人間の説明責任が必要である。誰かがポリシーの意味、失敗時の対処、例外を承認できる人、リーダーシップに届くメトリクスを決定しなければならない。優先順位なしに数千の所見を報告するダッシュボードは、別のノイズ源になる可能性がある。少数の重大なクラウド境界違反は迅速なエスカレーションを受けるべきである。

メタデータ経路は自動化を特に価値あるものにする。組織はワークロードがメタデータアクセスを必要とするかどうかをテストし、適切な場合は IMDSv2 を強制し、メタデータトークンの使用を監視し、ロール権限を制限し、期待されるワークロード ID と一致しない資格情報の使用を検出できる。また、アプリケーションコードと構成を SSRF 露出についてスキャンできる。これらの制御は無敵を保証しないが、1つの誤設定が大量データアクセスになる可能性を減らす。

自動化は証拠も保存すべきである。ポリシーがデプロイをブロックする場合、組織は理由を知るべきである。例外が付与された場合、誰が受け入れ、どのくらいの期間かを知るべきである。ロールが変更された場合、どのデータアクセスが変更されたかを知るべきである。その証拠は侵害が発生した場合に重要になる。それは組織が機能する制御システムを持っていたか、単なるツールのコレクションだったかを示す。

データローカリティはクラウド制御義務を除去しない

Capital One のインシデントは北米に影響を与えたが、クラウドの教訓は広がる。データ主権とローカリティの議論はしばしばデータがどこに保存され、どの法制度が適用されるかに焦点を当てる。それらの問いは重要である。しかし、ID、アプリケーション、メタデータ制御が失敗した場合、ローカリティだけではデータを保護しない。承認されたリージョンに保存された記録も、誤設定されたロールを通じて露出する可能性がある。準拠したホスティング場所も、運用境界が弱い場合に害を生み出す可能性がある。

規制対象の金融機関にとって、ローカリティは制御証拠と組み合わせる必要がある。データはどこにあるか？誰がアクセスできるか？どのロールを通じて？どのアプリケーション経路を通じて？どのロギングがあるか？メタデータ資格情報が到達された場合、どうなるか？どのサポート要員またはベンダーがアクセス権を持つか？バックアップと分析コピーはどのように管理されているか？組織が最初の質問だけに答えられる場合、それはロケーションストーリーであり、セキュリティストーリーではない。

この区別は取締役会と調達チームにとって重要である。クラウド契約はしばしば認証、リージョン、監査レポート、プロバイダ制御を強調する。これらは必要なインプットであるが、顧客側のアーキテクチャが実務的なリスクの多くを決定する。銀行は IAM 設計、アプリケーションセキュリティ、検出から買って逃れることはできない。より良い制御をサポートするプラットフォームを購入し、その後運用しなければならない。

Capital One の侵害は、影響を受けた記録が大手クラウドプロバイダの環境内にありながら、申し立てられた経路に顧客の設定と ID 選択が関与していたため、この境界を可視化した。それはプロバイダを無関係にするものではない。プロバイダのデフォルト、メタデータ設計、ドキュメント、ツール、サポートは顧客の行動を形成する。しかし、銀行の義務はそれらの機能を自社のデータ周りの防御可能な制御状態に変換することである。

有用なクラウドガバナンスレポートはしたがって、ローカリティと制御を組み合わせるべきである。リージョン別の重要なデータストア、アタッチされたロール、露出したアプリケーション経路、メタデータ設定、キー管理、ロギングカバレッジ、例外の経過期間、インシデント対応準備を示すべきである。そのレポートは、データが準拠したクラウドにあるという一般的な声明よりも価値がある。説明責任は場所だけでなく経路に付随する。

インシデントはクラウド成熟度の意味を狭めた

侵害の前、クラウド成熟度は移行規模、エンジニアリング文化、クラウドファースト戦略への公的信頼と誤解される可能性があった。侵害の後、成熟度はより狭く、より要求の厳しい意味を持たなければならなくなった：アプリケーション、ID、データの境界における制御が機能していることを証明する能力。洗練されたユーザーでも危険な例外を持つことができる。現代のアーキテクチャでも古典的なウェブの弱点を含むことができる。規制対象の機関でも、リスクを可視化したであろう証拠を見逃すことができる。

これはクラウド購入者にとって謙虚であるべきである。教訓はクラウドを避けることではない。それは魔法の思考を避けることである。クラウドプラットフォームは強力なプリミティブ、基盤インフラの迅速なパッチ、きめ細かい ID、自動ロギング、スケーラブルなセキュリティサービスを提供できる。また、リソースがプログラム可能で接続されているため、誤設定を拡大することもある。違いはガバナンスである。

成熟度には証拠のリズムが必要である。毎日の自動ポリシーチェック。毎週の例外レビュー。毎月のリスクレポート。高リスク経路の定期的なペネトレーションテストと脅威モデリング。クラウドデータ露出のための机上演習。独立した検証。ロールとデータストアの明確な所有権。クラウドインシデントのための消費者通知プレイブック。これらの活動はアーキテクチャを管理されたシステムに変える。

侵害はまた、クラウド契約が操作的に読まれるべきであることを示唆している。共有責任モデルは、各高リスクワークロードの制御マトリックスにマッピングされるべきである。プロバイダ責任はプロバイダが提供する証拠をリストすべきである。顧客責任は顧客が作成する証拠をリストすべきである。共有インターフェースは共同の前提と失敗モードをリストすべきである。義務の証拠が存在しない場合、その義務は管理されていない。

銀行にとって、この証拠は意思決定をサポートする形でリスクリーダーシップに届く必要がある。取締役はすべての IAM JSON ポリシーをレビューする必要はない。彼らは、境界ワークロードが機密ストアにアクセスできるかどうか、クラウド例外が経年化しているかどうか、ロギングが完全かどうか、セキュリティ自動化が高リスクの変更をブロックするかどうかを知る必要がある。クラウド成熟度はインシデントの欠如ではない。インシデントをより起こりにくく、より小さく、説明しやすくする制御の存在である。

WAF ロールは法的抽象概念ではない

誤設定されたウェブアプリケーションファイアウォールを介した申し立てられた経路は、説明責任を具体的な運用ポイントに置くため重要である。WAF は防御層のように聞こえることがあり、しばしばそうである。しかし、防御コンポーネントにアタッチされた ID には依然として権限がある。その ID が狭い機能を超えてデータストアに到達できる場合、セキュリティツールが橋渡しになりうる。制御の問題は、コンポーネントがファイアウォールと呼ばれたかどうかではない。それは、意図しない方法で到達されたときにコンポーネントが何をすることを許されていたかである。

この区別は規制対象のクラウドプログラムにとって重要である。セキュリティツールは保護スタックに位置するため、しばしば高い信頼を受ける。ロギングエージェント、ファイアウォール、スキャナー、デプロイシステム、モニタリングツールは機能するためにアクセスを必要とする。そのアクセスは依然として最小特権と悪用の想定によって管理されなければならない。1つの経路を保護するツールは、そのロールが仕事よりも広い場合に別の経路を露出させる可能性がある。コンポーネントの名称は権限レビューの代わりになるべきではない。

したがって、銀行はすべての境界ロールを高価値の ID として扱うべきである。ロールには名前付きの所有者、ビジネス目的、データアクセスマップ、レビュー日、自動ポリシーチェック、異常使用のアラートが必要である。ロールがストレージから読み取る場合、その理由は明示的であるべきである。オブジェクトをリストできる場合、必要性をテストすべきである。機密記録に到達できる場合、補償する検出経路が必要である。ロールがインターネット向けインフラにアタッチされている場合、メタデータサービス露出は脅威モデリングで仮定されるべきであり、エッジケースとして却下されるべきではない。

それがコンプライアンスインベントリと制御証拠の実用的な違いである。インベントリはロールが存在すると言う。証拠は誰が承認したか、何にアクセスできるか、なぜそのアクセスが必要か、悪用がどのように検出されるか、権限が最後にレビューされたのはいつか、どの自動ガードレールが拡大を停止するかを示す。規制当局と取締役会は2番目の形式を必要とする。侵害によって害を受けた顧客は2番目の形式を必要とする。自社の露出を評価するクラウド購入者は2番目の形式を必要とする。

教訓は WAF を超えて適用される。欠陥を介して到達可能で広範な権限を持つクラウドサービス ID はすべてピボットになり得る。ビルドシステム、データパイプライン、分析ジョブ、サポートツール、インシデント対応アカウントも同様のミスマッチを生み出す可能性がある。Capital One のインシデントは原則を可視化する：クラウド ID は背景設定ではない。それらは本番セキュリティ境界である。

クラウドデューデリジェンスは顧客側をテストしなければならない

多くのクラウドデューデリジェンスプログラムはプロバイダ証拠に過度に依存する。認証、監査レポート、リージョン表明、暗号化説明、サービスコミットメントを収集する。これらの資料は有用である。それらは、顧客自身のアプリケーションロール、メタデータ設定、WAF ルール、データ分類、アラートが安全かどうかには答えない。Capital One の侵害は、強力なプロバイダ制御環境が顧客側の露出経路と共存できることを示した。

したがって、真剣なデューデリジェンスプログラムは2つの元帳を持つべきである。プロバイダ元帳はプラットフォームが約束するものを問う：物理的セキュリティ、インフラパッチング、サービス復元力、ID プリミティブ、ロギング機能、サポート義務。顧客元帳は組織が実際に設定したものを問う：ロールスコープ、データストアアクセス、メタデータ実施、公開露出、秘密管理、ログ保持、アラートしきい値、対応権限。共有責任モデルは両方の元帳が存在するときにのみ有用になる。

調達チームはしばしば最も重要なクラウド制御が設定される前に作業を終了する。これがガバナンスギャップを生み出す。契約は承認されるかもしれないが、ワークロードはコード変更、ポリシー例外、新しいデータセット、緊急リリースによって後に漂流する可能性がある。クラウドデューデリジェンスはしたがって継続的でなければならない。設計、デプロイ、運用、廃止を通してワークロードを追跡すべきである。一度きりのベンダーレビューは生きた制御状態を証明できない。

金融機関は、階層化されたガバナンスを運用しているため、このギャップに特にさらされている。ベンダーリスク、テクノロジーリスク、サイバーセキュリティ、法務、プライバシー、監査、事業部門がそれぞれスライスを所有するかもしれない。エンドツーエンドのクラウドデータ経路を誰も所有しない場合、リスクのある境界がチームの間に残る可能性がある。WAF はセキュリティに属し、ストレージバケットはアプリケーションチームに属し、IAM ロールはプラットフォームエンジニアリングに属し、顧客通知は法務に属する。攻撃者はこれらの組織図の境界を経験しない。制御記録はそれらを横断しなければならない。

Capital One のインシデントに対する公的監督対応は、クラウド購入者を証拠ファーストのデューデリジェンスに押し進めるべきである。取締役会パッケージは、銀行が共有責任モデルの下で評判の良いプロバイダを使用していると言うだけでは不十分である。高リスクの顧客側責任がどのように果たされているかを示すべきである。これには、クラウドセキュリティ態勢管理の所見が是正されているか、最小特権の例外が経年化していないか、SSRF クラスがテストされているか、IMDS 保護が実施されているか、重要なデータストアが完全なアクセステレメトリを持っているかを含む。

制御証拠は敵対的再構築に耐えなければならない

クラウドプログラムの最も要求の厳しいテストは敵対的再構築である：インシデント後、調査官、規制当局、顧客、そして自らに対して経路を信頼できる方法で再構築できるか？それにはログの保持以上のものが必要である。アーキテクチャ図、ID ポリシー、アプリケーション動作、セキュリティアラート、変更記録、データアクセス証拠間の首尾一貫した関係が必要である。それらの成果物が調整できない場合、組織はインシデントの断片を理解しても、全体の経路を証明できないかもしれない。

敵対的再構築は日常的な報告とは異なる。日常的な報告はほとんどの制御がグリーンであることを示すかもしれない。再構築はなぜ1つの経路がレッドだったのか、組織はそれを知るべきだったのかを問う。ロールが文書化された例外のために広範なアクセスを持っていたのか、権限が時間とともに蓄積されたのかを問う。メタデータサービスがポリシーによって保護されていたのか、ワークロードの裁量に任されていたのかを問う。アラートがなかったのか、無視されたのか、ノイズだったのか、誤ったルーティングだったのかを問う。データ分類システムが実際のストレージパターンと一致していたのかを問う。

ここでクラウドの速度が説明責任の圧力を生み出す。インフラは迅速に作成、変更、削除される。その速度は価値があるが、証拠は自動的に捕捉されなければならないことを意味する。侵害後の手動想起は不完全になる。強力なクラウドプログラムは、変更が発生したときに記録し、所有者にリンクし、ポリシーに対して評価し、リスクのある状態がなぜ存在したかを説明する十分なコンテキストを保存する。その連鎖がなければ、組織はアクティビティログを持っていても説明責任を持たない可能性がある。

Capital One 事件の DOJ と規制当局の記録は、経路を高いレベルで一般に読みやすくした。銀行の内部証拠はより詳細でなければならない。関連ポリシーが認識されていたか、実施されていたか、逸脱が承認されていたか、モニタリングがより早く発動すべきだったかに答えられるべきである。その証拠は非難のためだけではない。それは機関がどの制御が失敗し、どのインセンティブがそれを存続させたかを学ぶ方法である。

顧客はこの再構築をめったに見ないが、それに依存している。正確な再構築は、通知が正確かどうか、是正が比例しているかどうか、将来の修正が実際の経路に対処するかどうかを決定する。会社が再構築できない場合、過剰通知、過少通知、または間違ったものを是正する可能性がある。証拠の質はしたがって消費者保護の問題になり、エンジニアリングの懸念だけではない。

プロバイダはすべての失敗を所有せずに行動を形成できる

公正な分析は、顧客側の責任を、クラウドプロバイダに影響力がないかのように扱う逆の間違いも避けるべきである。プロバイダは、デフォルト、ドキュメント、サービス設計、ガードレール、価格設定、コンソールワークフロー、サポート、アップグレードパスを通じて顧客の行動を形成する。メタデータサービスのセキュリティは良い例である。プロバイダはより安全なモードを提供できるが、顧客は適切な場所でそれらを有効にし実施しなければならない。プロバイダの義務は、より安全な選択肢を利用可能にし、理解可能にし、スケールで誤用しにくくすることである。顧客の義務は、機密ワークロードの周りでそれらを採用し管理することである。

この共有された影響が、クラウド説明責任がインターフェースを調べる理由である。プロバイダがより安全なメタデータモードを導入する場合、その可視性はどの程度か？ドキュメントは脅威モデルを平易に説明しているか？組織はそれを中央で実施できるか？マネージドサービスは広範なロールの必要性を減らすか？ログは資格情報の使用を理解可能にするか？顧客はデプロイ前にリスクのある構成を検出できるか？これらの質問は、プロバイダをすべての顧客エラーに責任があるようにはしない。プラットフォーム設計が顧客が自らの義務を果たすのを助けるかどうかを問う。

顧客にとって、プロバイダの影響は言い訳ではない。規制対象の銀行は、より安全な制御がドキュメントのどこかに存在したが運用化されなかったとは言えない。機密ワークロードにどのプラットフォーム機能が必須かを決定し、実施を証明しなければならない。また、クラウドサービスは進化するため、プロバイダの変更を追跡しなければならない。かつて困難だった制御が容易になるかもしれない。かつて受け入れられたリスクは、より安全なデフォルトまたは実施可能なポリシーが利用可能になったときに受け入れられなくなるかもしれない。

したがって、Capital One の侵害はバランスの取れたクラウド説明責任モデルを支持する。契約は形式的な義務を割り当てる。プラットフォーム設計は利用可能な選択肢を形成する。顧客ガバナンスは選択肢を制御に変える。実施はそれらの制御が現実だったかどうかをテストする。公的コミュニケーションは、データが影響を受けた人々に結果を翻訳する。各層は重要であり、どれも他を代替できない。

説明責任は図が終わるところから始まる

Capital One の侵害は、怠惰なクラウド説明責任を退けるべきである。共有責任図は有用だが、調査ではない。調査は図が終わるところから始まる：WAF ルール、メタデータ経路、ロール権限、オブジェクトアクセスログ、発動したか発動しなかったアラート、顧客通知、規制当局の証明要求。

Capital One はそのデータを露出した顧客側アーキテクチャに対して実務的な制御を持っていた。AWS はプラットフォームプリミティブ、ドキュメント、クラウドサービス動作に対して実務的な制御を持っていた。規制当局は監督期待に対して実務的な制御を持っていた。顧客は通知後にのみ実務的な制御を持っていた。最も公平な説明責任マップはそれらの制御点を追跡し、各主体が何を防止、検出、制限、証明できるかを問う。

長期的な教訓は反クラウドではない。それは証拠重視である。銀行や他のクラウド利用者は、すべての契約上の義務を技術的およびガバナンス制御にトレース可能にすべきである。彼らはどのメタデータ経路が存在するか、どのロールが機密データに到達できるか、どの自動チェックがリスクのある変更をブロックするか、どのログがアクセスを再構築するかを知るべきである。次のクラウドインシデントが発生したとき、組織はその責任モデルを公に発見する必要があるべきではない。すでに証拠を持っているべきである。