Capital One 揭示云合同边界与控制证据起点

摘要

• Capital One 2019 年的泄露事件暴露了控制不匹配的问题：法律和云行业责任模型可以描述谁负责哪一层，但事件取决于关于配置、元数据访问、身份权限、日志记录和检测的实战证据。
• 新的视角是合同与控制证据的对比。在云泄露事件中，问责并不止于“客户责任”或“提供商责任”这些说法，它追问哪个行为者能够看到风险路径、改变它、发出警报，并事后证明边界已被管控。
• 公开记录将事件与配置错误的 Web 应用防火墙角色以及在 Amazon Web Services 中存储的数据访问联系起来。本文分析利用这些记录审视 Capital One 的运营控制，而不是将共享责任变为一句简单的辩护或指控。
• 金融服务监管机构将该事件视为风险管理和治理问题，而不只是一次单一的攻击。这很重要，因为银行购买云容量，但不能将其证明对客户数据有控制力的义务外包出去。
• 持久的教训是，云合同需要一个证据层：身份策略、网络限制、元数据保护、日志记录、警报路径、自动化检查和经得起真实事件考验的、董事会可读的风险指标。

证据记录及使用方式

以下来源用于不同主张。Capital One 和监管记录确定事件时间线、客户通知和执法背景。美国司法部（DOJ）材料在公开记录层面确定了指控和裁定的入侵路径。AWS 文档解释了云环境中可用的共享责任和元数据服务控制。安全标准和攻击参考提供控制框架，而非私下调查结果。

共享责任不是共享的模糊性

Capital One 的泄露事件成为人们讨论云责任方式的公开检验。“共享责任”这一说法在清晰表明提供商保护云、客户保护其在云中构建的内容时是有用的，但当它像迷雾一样运作时就会变得危险。泄露事件之后，公众不需要口号。客户、监管机构、董事会和云买家需要通过证据来显示在真实的故障路径上存在哪些控制。

公开记录描述了对存储在 Amazon Web Services 中 Capital One 数据的未授权访问，其中配置错误的 Web 应用防火墙和云元数据访问发挥了核心作用。这一事实模式并不简化为单纯的提供商之过或客户之过。AWS 提供了环境、元数据服务、身份工具和责任模型。Capital One 设计并运行其应用程序、配置、角色权限、监控和治理。攻击者利用了这些选择交界处的边界。

这就是合同与控制对比视角的重要性所在。合同可能会说客户负责配置应用程序和身份，但监管机构仍会追问该银行如何知道其配置是安全的。自动化检查是否检测到了风险权限？安全审查是否测试了 SSRF 路径？元数据访问是否需要适合应用程序的保护？日志是否快速显示了异常访问？WAF 角色是否仅拥有其所需的权限？领导者能否在泄露事件之前看到例外情况？

共享责任也有市场功能。它告诉云客户他们必须投资什么。如果该模型只有律师和架构团队理解，它将无法保护数据。银行必须将该模型转化为运营控制：护栏、策略即代码、身份边界、网络分段、元数据保护、警报、事件预案、独立验证和董事会报告。只有当责任产生可衡量的控制状态时，它才变得实用。

该泄露事件证明，云成熟度不等同于云采用。Capital One 被广泛视为先进的云用户，但事件仍然发生了。这应该使教训更加严肃，而不是相反。如果一家成熟的银行都可能遭遇边界失败，那么不那么成熟的机构需要更有力的证据，证明它们自己的云计划不是在需要控制证据的地方依赖合同语言。

元数据路径将配置问题转变为数据事件

元数据服务方面至关重要，因为它展示了一个局部应用程序漏洞如何变成云身份问题。在现代云环境中，计算实例可以使用来自元数据服务的临时凭证访问其他资源。这种设计避免了硬编码的密钥，通常比静态凭证更安全。但如果应用程序路径可以被诱导去请求元数据，并且关联的角色拥有广泛访问权限，攻击者就可能从面向 Web 的漏洞转移到云资源访问。

这并不意味着元数据服务本身就有问题。这意味着它们的风险取决于周边的控制：应用程序输入处理、网络出口规则、元数据服务配置、角色权限、日志记录和监控。能够实现安全自动化的同一云特性，在身份边界过于宽松或没有防御 SSRF 时，可能成为桥梁。控制问题在于该机构是否将元数据视为特权接口，而不是看不见的管道。

AWS 后来以及当前关于 IMDSv2、IAM 角色和纵深防御 SSRF 指南的文档很有用，因为它使控制界面清晰可读。面向会话的元数据访问、限制跳转行为、最小权限和应用程序层防御并不是抽象的最佳实践。它们是将高价值内部服务变成更难攻击的目标的方法。本文没有在确切事后回顾中，利用当前文档改写 2019 年的义务，而是用它来展示现代云问责应要求什么样的证据。

Capital One 的泄露事件也表明了为什么最小权限不能停留在意图层面。角色可能出于合法的运营原因而存在，但附加的权限决定了当角色通过意外路径被访问时的破坏范围。如果 WAF 角色能够访问的数据超过了应用程序功能严格所需，那么配置错误的后果就更严重。正确的问题不是角色是否存在，而是是否有人能在事件发生前证明该角色的权限匹配了狭窄的运营需求。

一个成熟的云计划应将此类证明常规化。它应自动检测拥有广泛对象存储访问权限的角色，将其与应用程序所有者进行交叉核对，要求例外情况到期，测试已知的 SSRF 类别，在可能的地方限制元数据，并在凭证以异常方式使用时发出警报。这些证据应在事件发生前就可用。如果只在泄露后才收集，它或许能解释失败，但无法防止失败。

合同分配职责，监管机构检查风险管理

美国货币监理署（OCC）和美联储的记录很重要，因为金融监管机构并没有将这次泄露仅仅视为技术意外，而是将其视为受监管银行组织中的风险管理问题。这种区别很重要。银行可以与云提供商签订合同，但它仍然负责保护客户数据、管理运营风险并证明其第三方和内部控制有效。

在受监管的环境中，共享责任图只是一个起点。监管者会询问管理层是否理解风险、实施控制、测试它们、纠正缺陷并升级关注事项。银行的职责包括对云计划的治理，而不仅仅是在合同上依赖提供商。当云采用改变基础设施决策的速度和规模时，这一职责变得尤为重要。一次配置错误可能比传统采购流程召集审查还要快地暴露数百万条记录。

监管问责还追问证据是否达到了恰当的层级。安全工程师可能知道某个角色范围很广，云架构师可能知道元数据保护存在，风险官可能知道迁移计划具有战略意义，董事可能知道云采用对竞争力至关重要。但如果没有人将技术例外转化为风险语言，监督就变成了表演。董事会听到的是云在设计上是安全的，而实际设计中却包含未经审查的例外。

合同与控制的错配在此显现。合同可能说客户控制身份和访问管理，但风险管理必须展示如何执行这种控制：谁批准 IAM 策略？如何审查 WAF 规则？如何分类存储桶？如何强制执行元数据保护？如何分诊警报？接受哪些例外，持续多长时间？哪些第三方依赖产生了集中风险？答案必须在运营证据中，而不是采购摘要里。

Capital One 的公开文件也显示了泄露如何变成企业事件。该公司披露了成本、诉讼和风险因素。这份证券记录与消费者通知和监管执法并列。因此，一次云控制失败在客户信任、诉讼、合规、市场披露和治理方面都产生了后果。问题不仅仅是该银行是否有云合同，而是在公众注视下，该银行能否展示对一个云运营模型的控制。

检测证据是事件与不确定性之间的分界线

在云泄露事件之后，检测证据决定了组织能否迅速缩小损失范围。日志、对象访问记录、身份踪迹、网络事件和异常警报成为界定范围的基础。没有它们，公司就被迫陷入不确定性，而不确定性会蔓延到客户和监管机构。Capital One 的泄露事件说明了为什么云日志不是可选的仪器装备，而是系统的记忆。

公开记录表明，该事件是在外部报告之后才被发现，而不仅仅是常规的内部预防。这一事实提高了对检测证据的问责标准。一家受监管的银行应该知道某个角色是否被以异常方式使用，数据存储是否被枚举，访问模式是否匹配预期的应用程序行为，以及公共存储库或外部信号是否指示数据被盗。云环境可以生成丰富的遥测数据。治理的问题是组织是否收集、保留并据此采取行动。

云系统中的检测有一个特殊的挑战：合法的自动化可能看起来充满噪声。应用程序不断读写数据，角色按设计获取凭证，开发人员快速部署配置。这种正常活动可能隐藏滥用，除非组织精确地定义了预期行为。最小权限计划减少了正常行为的空间，强大的日志记录程序记录偏差，经过调校的警报程序将偏差转化为行动。这些都不出现在合同里，而全都出现在事件证据里。

对客户来说，检测证据影响通知质量。如果银行能说明哪些数据类别被访问、哪些账户受影响、什么未被泄露以及正在采取什么补救措施，客户就能更理性地行动。如果银行无法缩小事件范围，客户就会继承广泛的焦虑。因此，该泄露事件的公开信息传达依赖于大多数消费者永远不会看到的技术遥测。这种不对称正是监管机构关注控制证据的原因。

检测还应反馈到云架构中。如果一个角色的行为难以与滥用相区分，该角色可能太宽泛或架构太不透明。如果元数据凭证的使用无法与预期工作负载关联，身份边界就很薄弱。如果警报依赖于罕见的外部报告，那么监控对持有的数据来说还不够成熟。云计划应在需要取证之前就设计好取证清晰度。

客户沟通游走于精确与安抚之间

Capital One 必须告诉客户发生了什么、谁受到影响、涉及哪些数据类型以及公司将采取什么措施。这比听起来更难，因为云事件通常涉及普通客户无法理解的技术路径。诸如“配置错误的 Web 应用防火墙”之类的短语可能准确，但对担心身份盗用的人来说却毫无意义。沟通必须在翻译时不隐瞒。

该公司还必须避免两种相反的失误。过于技术化的表述可能掩盖实际风险。过于安抚性的表述可能淡化不确定性。恰当的通知用浅白语言解释数据类别、可能的滥用途径、保护步骤、公司支持以及调查限制。它不应要求客户理解元数据服务、IAM 角色或 SSRF 才能保护自己，但也不应假装这些细节无关紧要，因为这些细节解释了泄露为何发生以及必须改变什么。

云合同可能让沟通更加复杂。如果客户听说数据存储在云中，他们可能会问是否是云提供商出了问题。如果公司说问题是其自身配置，客户可能会问为什么没有检测到。如果公司强调犯罪行为，客户可能会问为什么路径存在。每个答案都必须尊重共享责任边界，同时将问责保持在控制客户数据的一方。这是一项叙事挑战，也是一项治理挑战。

和解背景又增加了一层。消费者救济、信用监控和报销程序成为沟通记录的一部分。如果客户无法轻松理解或获取补救措施，泄露响应就会将工作转移给受影响的人群。和解网站、支持材料和持续更新的质量很重要，因为沟通体验是客户可以直接使用的少数控制之一。

更广泛的教训是，应在泄露事件之前就规划好云透明度。公司应准备好用通俗的话语解释云责任：提供商保护什么、公司保护什么、什么失败了、正在改变什么以及客户能做什么。这种解释不应在法律审查已将每个句子缩减到最小范围之后才临时拼凑。银行的可信度取决于既精确又有用。

安全自动化可防止或放大错配

Capital One 的泄露事件也是关于安全自动化的一个教训。自动化常被宣传为应对云速度的答案。这在一定程度上是对的。自动化检查可以检测危险的 IAM 策略、公开存储暴露、缺失的加密、异常的网络路径和不安全的元数据设置。策略即代码可以在风险部署到达生产环境之前将其阻止。持续监控可以将云配置漂移转化为可见的例外。但如果自动化检查的对象不对，或者报告的结果无人认领，它也可能产生虚假的信心。

一个实用的云控制计划应当为高风险模式定义强制性护栏。面向 Web 的组件未经明确审查不应能够接触元数据或广泛的数据存储。附加到外围组件的角色应该狭窄。存储访问应分类并监控。SSRF 测试应是应用安全的一部分。例外应当到期。高风险的变更应产生风险所有者可以检查的证据。这些控制不是文书工作，而是将合同与实际行为连接起来的机制。

自动化还有助于解决规模问题。大型银行运营着成千上万的资源、角色和策略，单靠人工审查无法应付。但自动化控制需要人类问责。必须有人决定策略意味着什么、失败时会发生什么、谁可以批准例外以及哪些指标需要提交给领导层。一个报告数千条发现却没有优先排序的仪表盘，可能成为另一个噪声源。一小部分高后果的云边界违规应得到快速升级。

元数据路径使自动化特别有价值。该组织可以测试工作负载是否需要元数据访问、适当地强制执行 IMDSv2、监控元数据令牌使用、限制角色权限，并检测凭证使用与预期工作负载身份不符的情况。它还可以扫描应用程序代码和配置以查找 SSRF 暴露。这些控制并不能保证无懈可击，但它们降低了单次配置错误变成大规模数据访问的可能性。

自动化还应保留证据。当策略阻止部署时，组织应知道为什么。当例外被批准时，应知道谁接受了它以及持续多久。当角色变更时，应知道什么数据访问发生了改变。如果发生泄露，这些证据就变得至关重要。它表明该机构是拥有一个正常运作的控制系统，还是仅仅一堆工具。

数据本地性并不免除云控制责任

Capital One 的事件影响主要在北美，但云教训遍及各地。数据主权和本地性的辩论常常聚焦于数据存储在哪里以及适用何种法律制度。这些问题很重要，但如果身份、应用和元数据控制失败，仅靠本地性并不能保护数据。存储在获批地区的记录仍可能通过配置错误的角色而泄露。如果运营边界薄弱，合规的托管位置仍可能造成伤害。

对于受监管的金融机构，本地性必须与控制证据配对。数据在哪里？谁能访问它？以什么角色？通过什么应用路径？有什么日志记录？如果元数据凭证被获取会发生什么？哪些支持人员或供应商可访问？备份和分析副本如何治理？如果组织只能回答第一个问题，那它只有一个关于位置的故事，而不是安全的故事。

这种区别对董事会和采购团队很重要。云合同常常强调认证、区域、审计报告和提供商的控制。这些都是必要的输入，但客户端的架构决定了大部分实际风险。银行无法通过购买来摆脱 IAM 设计、应用安全和检测。它可以购买一个支持更好控制的平台，然后必须运营这些控制。

Capital One 的泄露事件使这一边界清晰可见，因为受影响的记录位于一家主要云提供商的环境中，而据称的路径涉及客户配置和身份选择。这并不意味着提供商无关紧要。提供商的默认设置、元数据设计、文档、工具和支持塑造了客户行为。但银行的义务是将这些能力转化为围绕其数据的可防御控制状态。

因此，一份有用的云治理报告应将本地性与控制相结合。它将按区域显示关键数据存储、附加的角色、暴露的应用路径、元数据设置、密钥管理、日志覆盖范围、例外时长以及事件响应准备情况。这份报告比一份“数据位于合规云中”的泛泛声明更有价值。问责附着于路径，而不仅仅是地点。

该事件收窄了云成熟度的含义

在泄露事件之前，云成熟度可能被误解为迁移规模、工程文化或对云优先策略的公众信心。在泄露之后，成熟度必须意味着更狭窄且要求更高的东西：证明应用程序、身份和数据边界处的控制正在起作用的能力。一个成熟的用户仍可能有一个危险的例外。一个现代架构仍可能包含一个经典的 Web 弱点。一家受监管的机构仍可能缺失本可使风险可见的证据。

这应让云买家保持谦逊。教训不是避开云，而是避免魔法般的思维。云平台可以提供强大的原语、底层基础设施的快速修补、精细粒度的身份、自动化日志记录和可扩展的安全服务。它们也可能放大配置错误，因为资源是可编程且互联的。区别在于治理。

成熟度需要一套证据节奏。每日自动化策略检查，每周例外审查，每月风险报告，对高风险路径的定期渗透测试和威胁建模，云数据暴露的桌面推演，独立验证，角色和数据存储的明确所有权，以及云事件的消费者通知手册。这些活动将架构转变为受治理的系统。

该泄露事件还表明，云合同应该以运营的视角来阅读。共享责任模型应映射到每个高风险工作负载的控制矩阵中。提供者责任应列出提供者提供的证据。客户责任应列出客户产生的证据。共享接口应列出共同的假设和失效模式。如果某项职责没有证据存在，那么该职责就没有被管理。

对于银行来说，这些证据必须以支持决策的形式送达风险领导层。董事们不需要审查每个 IAM JSON 策略，但他们确实需要知道外围工作负载能否访问敏感存储、云例外是否在老化、日志是否完整、安全自动化是否阻止了高风险变更。云成熟度不是没有事件，而是存在一些控制使得事件更不可能发生、影响更小且更容易解释。

WAF 角色不是法律上的抽象概念

据称通过配置错误的 Web 应用防火墙的路径很重要，因为它将问责置于一个具体的运营点上。WAF 听起来像一层防御层，通常也的确如此。但附加到防御组件的身份仍然拥有权限。如果该身份能够访问超出其狭窄功能的数据存储，一个安全工具就可能变成桥梁。控制问题不在于该组件是否被称为防火墙，而在于当以意外的方式访问时，该组件被允许做什么。

这种区别对受监管的云计划很重要。安全工具通常因其处于保护栈中而获得较高的信任。日志代理、防火墙、扫描器、部署系统和监控工具需要访问权限才能工作。这种访问仍必须受最小权限和滥用假设的约束。保护一条路径的工具如果其角色比其职责更广泛，就可能暴露另一条路径。组件的头衔永远不应替代权限审查。

因此，银行应将每一个外围角色都视为高价值身份。该角色应有一个指定的所有者、一个业务目的、一个数据访问映射、一个审查日期、自动化策略检查以及针对异常使用的警报。如果该角色从存储中读取数据，理由应该是明确的。如果它可以列出对象，那么需求应该经过测试。如果它可以接触到敏感记录，就应该有一条补偿性的检测路径。如果该角色附加到面向互联网的基础设施上，在威胁模型中应假定存在元数据服务暴露，而不是将其视为极端情况而忽略。

这就是合规清单与控制证据之间的实际区别。清单说角色存在，证据则说明谁批准了它、它能访问什么、为什么该访问是必要的、如何检测滥用、上次审查权限是什么时候以及哪些自动化护栏会阻止权限扩大。监管机构和董事会需要后一种形式，受到泄露伤害的客户需要后一种形式，评估自身暴露程度的云买家也需要后一种形式。

该教训也适用于 WAF 之外。任何云服务身份如果可通过漏洞触及且带有广泛的权限，都可能成为跳板。构建系统、数据管道、分析作业、支持工具和事件响应账户都可能造成类似的错配。Capital One 的事件使这一原则清晰可见：云身份不是后台配置，它们是生产环境中的安全边界。

云尽职调查必须检验客户端

许多云尽职调查计划过度依赖提供商的证据。它们收集认证、审计报告、区域声明、加密描述和服务承诺。这些材料有用，但它们并没有回答客户自身的应用角色、元数据设置、WAF 规则、数据分类和警报是否安全的问题。Capital One 的泄露事件表明，强大的提供商控制环境可以与一条通向暴露的客户端路径共存。

因此，一个严肃的尽职调查计划应该有两本账。提供者账本询问平台承诺了什么：物理安全、基础设施补丁、服务弹性、身份原语、日志功能和支持义务。客户账本询问机构实际配置了什么：角色范围、数据存储访问、元数据强制执行、公共暴露、秘密处理、日志保留、警报阈值和响应权限。只有当两本账都存在时，共享责任模型才变得有用。

采购团队常常在最重要的云控制配置完成之前就结束了工作，这造成了治理缺口。合同可能已获批，但工作负载后续可能通过代码变更、策略例外、新数据集和紧急发布发生漂移。因此，云尽职调查必须是持续的。它应跟随工作负载经历设计、部署、运营和退役。一次性的供应商审查无法证明一个活的控制状态。

金融机构特别容易受到这一缺口的影响，因为它们实行分层治理。供应商风险、技术风险、网络安全、法律、隐私、审计和业务部门可能各管一块。如果没有人端到端地拥有云数据路径，一条有风险的边界就可能横跨在团队之间。WAF 属于安全部门，存储桶属于应用团队，IAM 角色属于平台工程，而客户通知属于法律部门。攻击者并不会遇到任何此类组织架构边界。控制记录必须跨越这些边界。

对 Capital One 事件的公开监管回应应推动云买家走向证据优先的尽职调查。一份董事会资料不应只说银行在共享责任模型下使用了一家信誉良好的提供商，而应展示高风险的客户端责任是如何履行的。这包括云安全态势管理发现的问题是否得到修复、最小权限例外是否在老化、SSRF 类别是否经过测试、IMDS 保护是否强制执行，以及关键数据存储是否拥有完整的访问遥测。

控制证据必须经得起对抗性重建

对云计划最严苛的考验是对抗性重建：在事件发生后，该组织能否以对调查人员、监管机构、客户和自身都具有可信度的方式重建路径？这不仅需要保留日志，还需要架构图、身份策略、应用行为、安全警报、变更记录和数据访问证据之间的协调关系。如果这些工件无法协调一致，该组织或许能理解事件的一些片段，却无法证明整个路径。

对抗性重建不同于常规报告。常规报告可能显示大多数控制呈绿色，而重建则会追问为什么有一条路径是红色的，以及该组织是否本应知道。它会追问角色拥有广泛访问权限是因为一个有记录的例外，还是因为权限随时间积累。它会追问元数据服务是由策略保护还是交由工作负载自行决定。它会追问警报是缺失、被忽略、噪声过大还是路由错误。它会追问数据分类系统是否与实际存储模式相符。

这就是云速度产生问责压力的地方。基础设施可以快速创建、变更和销毁。这种速度很有价值，但意味着证据必须自动捕获。泄露事件后的人工回忆将是不完整的。强大的云计划会在变更发生时记录它们，将它们与所有者关联，对照策略进行评估，并保留足够的上下文以解释为什么存在危险状态。没有这些链条，该组织可能拥有活动日志，却没有问责。

Capital One 案例中 DOJ 和监管机构的记录在较高层面上使路径对公众清晰可读。银行的内部证据必须更加精细。它应该能够回答相关策略是否已知、是否得到执行、偏差是否获得授权以及监控是否本应更早告警。这些证据不仅是为了追责，也是机构借以了解哪个控制失败以及何种激励允许其持续存在的方式。

客户很少看到这种重建，但他们依赖于它。准确的重建决定了通知是否精确、补救是否成比例以及未来的修复是否针对真实路径。如果一家公司无法重建，它可能过度通知、通知不足或修复错误的东西。因此，证据质量成为一个消费者保护问题，而不仅仅是工程问题。

提供商能在不拥有每次失败的情况下塑造行为

公正的分析还应避免一种懒惰的相对错误：将客户端责任视为云提供商毫无影响。提供商通过默认设置、文档、服务设计、护栏、定价、控制台工作流、支持和升级路径来塑造客户行为。元数据服务安全就是一个很好的例子。提供商可以提供更安全的模式，但客户必须适当地启用或强制执行它们。提供商的职责是让更安全的选择可用、可理解且难以在大规模上误用。客户的职责是在敏感工作负载周围采纳并治理它们。

这种共享影响力正是云问责应审视接口的原因。如果提供商引入了一种更安全的元数据模式，它的可见度有多高？文档是否清晰地解释了威胁模型？组织能否集中强制执行它？托管服务是否减少了对宽泛角色的需求？日志是否使凭证使用变得可理解？客户能否在部署之前检测到危险配置？这些问题并不是要让提供商为每个客户错误负责，而是询问平台设计是否有助于客户履行自身的职责。

对客户而言，提供商的影响力不是借口。受监管的银行不能说某个更安全的控制存在于文档某处却没有被落实。它必须决定哪些平台特性对敏感工作负载是强制性的，并证明其执行。它还必须跟踪提供商的变化，因为云服务在演进。曾经困难的控制可能变得更容易。当有更安全的默认设置或可执行的策略可用时，曾经被接受的风险可能变得不可接受。

因此，Capital One 的泄露事件支持一个平衡的云问责模型。合同分配正式职责，平台设计塑造可用选择，客户治理将选择转化为控制，执行测试这些控制是否真实，公共沟通则为数据受影响的人转译结果。每一层都很重要，且没有任何一层能替代其他层。

排版

排版是安排字体的艺术与技术，旨在使书面语言清晰易读、可读且视觉上吸引人。它涉及选择字体、字号、行长、行距和字距。

• 排版起源于 15 世纪约翰内斯·古腾堡发明的活字印刷术。
• 关键要素包括字体选择、字距调整、词距调整和行距。
• 良好的排版能增强可读性，并在设计中传达情绪或基调。

问责从图表终止之处开始

Capital One 的泄露事件应让懒惰的云问责方式寿终正寝。共享责任图是有帮助的，但它并不是调查本身。调查从图表终止之处开始：在 WAF 规则、元数据路径、角色权限、对象访问日志、已触发或未触发的警报、客户通知以及监管机构对证据的要求处。

Capital One 对暴露其数据的客户端架构拥有实际控制。AWS 对平台原语、文档和云服务行为拥有实际控制。监管机构对监督期望拥有实际控制。客户只有在接到通知后才拥有实际控制权。最公平的问责图谱遵循这些控制点，并追问每个行为者能够预防、检测、限制或证明什么。

长期的教训不是反云，而是亲证据。银行和其他云用户应将每一项合同义务追溯到一个技术和治理控制。它们应知道存在哪些元数据路径，哪些角色可以接触敏感数据，哪些自动化检查阻止了风险变更，以及哪些日志可以重建访问情况。当下一次云事件发生时，该组织不应需要在公众面前才去发现自己的责任模型，而应该已经拥有证据。