Capital One 元数据泄露：云配置如何成为责任链

概要

• Capital One 表示，一名外部人员在 2019 年 3 月 22 日和 23 日利用了一个配置漏洞。刑事与监管记录则描述了一条更长的控制链：一个配置不当的 Web 应用防火墙使得命令得以到达云环境，获取了某个角色的凭证，这些凭证可以枚举并复制存储对象，而监控并未将可疑活动转化为及时的遏制措施。
• Office of the Comptroller of the Currency 并未将此事件定性为孤立的工程失误。其同意调查结果追溯至该银行 2015 年的云迁移，并指出存在无效的风险评估、网络安全性不足、数据丢失防护控制缺失、警报处置不力、内部审计存在漏洞，以及董事会未能有效追究管理层责任等问题。
• 责任存在于多个层面，但在法律上不可互换。联邦陪审团判定 Paige Thompson 犯有刑事罪行。Capital One 接受了 8000 万美元的 OCC 罚款，同时既不承认也不否认该机构的调查结果。针对 Capital One 和 Amazon 的消费者索赔在诉状阶段部分未被驳回，后来达成和解，因此民事案件并未就银行与云提供商之间的过错分配产生审判结果。
• 主权教训并非在于选择国内的云区域就能解决数据保护问题。加拿大约有 600 万人受到影响，其中约 100 万人的社会保险号码（Social Insurance Number）遭到泄露。数据本地化、保留策略、身份权限、元数据访问、加密授权、日志记录以及监管机构对证据的访问，必须作为一个整体系统进行治理。

事件描述过于狭窄

关于 Capital One 数据泄露事件的常见版本是：防火墙配置错误，攻击者获取了 Amazon Web Services 中的数据，超过 1 亿人的信息被盗取。这句话的每个部分都指向了正确的方向。然而，作为一份问责说明，这个描述过于狭隘，它让整个事件听起来像是受控环境的一个边缘设定错误。

官方记录揭示了更深层次的结构性问题。Capital One 于 2019 年 7 月 29 日提交给 SEC 的公告称，该公司在 7 月 19 日确定，一名外部人员利用特定的配置漏洞获取了个人信息。公告将重大未授权访问的时间定在 3 月 22 日和 23 日，指出负责任披露报告于 7 月 17 日送达，并解释称公司已修复该配置问题，并与联邦执法部门合作。公告还表示，云运营模式帮助公司一经发现问题便迅速诊断并进行纠正。

最后一点值得注意。Capital One 并未将云本身视为根本原因。该公司强调，相关基础设施要素在云中或本地环境都可能存在。从技术上讲，这一立场无可非议：反向代理或 Web 应用防火墙在任何环境中都可能成为意外中继；服务凭证在任何环境中都可能权限过高；合法身份在任何环境中都可以读取加密数据。然而，云改变了这些条件结合的速度、抽象层次和规模。一个跨越应用程序边界的命令能够到达实例元数据服务。一个临时凭证可以通过 API 从别处被调用。一个存储角色可以枚举一个远超单台服务器磁盘规模的数据湖。使云操作高效的自动化同样可能使权限错误对入侵者高效。

Capital One 当前的事件信息页面指出，约有 1 亿美国人和约 600 万加拿大人受到影响。最大的数据类别是消费者和小型企业在 2005 年至 2019 年初申请信用卡产品时提供的信息：姓名、地址、邮政编码、电话号码、电子邮箱、出生日期和自我申报的收入。部分信用卡客户数据包括信用评分、信用额度、余额、还款历史、联系方式以及 2016 年、2017 年和 2018 年中 23 天的交易数据片段。该公司报告称，泄露的数据中包括约 14 万个美国社会安全号码、约 8 万个关联银行账号以及约 100 万个加拿大社会保险号码。该公司表示，信用卡账号和登录凭证并未泄露。

这些区别有助于避免夸大其词，但并不能将控制问题简化为一个数字。在信贷决策之后，应用数据仍可能长期携带身份敏感性。收入、地址历史、出生日期、信用状况以及政府标识符可以跨系统进行组合。因此，该事件不仅涉及某个存储桶是否私密，还涉及为什么一个面向应用程序的角色能够访问所存储的语料库，为什么本地元数据边界的凭证路径会变成外部数据路径，为什么监控未能弥补缺口，以及为什么大约十四年间收集的数据仍处于可触及的范围内。

时间线与问责形式的演变

日期会改变对组织合理知晓和采取行动的预期。核心时间线可以从公司披露、后续起诉和定罪、监管命令以及法院记录中梳理出来，但不应将每个来源视为同等类型的证据。

3 月 12 日与 3 月 22 日之间的表面差异并非必须强行统一为一个日期的矛盾。2021 年的后续起诉书指控了从 3 月 12 日或前后开始的一段更广泛的未授权计算机访问期。Capital One 的公告则使用 3 月 22 日和 23 日作为其事件描述中核心的数据访问日期。时间线应保留这种差异，即指控的行为过程与公司对数据外泄的描述之间的区别。

同样的严谨也适用于人口统计数字。公司最初的公告使用了美国约 1 亿人和加拿大 600 万人受影响的说法。美国和解管理人后来描述的则是约 9800 万美国消费者属于和解集体。这两个数字都不应被默不作声地转换为精确的通用计数。它们属于不同阶段的不同记录，定义也有所不同。

元数据边界如何成为凭证边界

技术链条始于服务器端请求伪造，通常缩写为 SSRF。在 SSRF 条件下，外部调用者诱导服务器端组件发出由该调用者选择或影响的请求。该请求是从服务器的网络位置发出的，因此可能到达从公共互联网直接无法访问的目的地。安全问题不仅仅在于接受了某个 URL，而在于应用程序成为了一个代行者，将外部人员的意图带入了更受信任的网络环境中。

司法部关于 Capital One 的案件页面将入侵描述为通过一个配置错误的 Web 应用防火墙发生。审判前提交的后续起诉书指控，Thompson 创建并使用扫描器来识别那些 Web 应用防火墙配置允许外部命令到达并在其服务器上执行的云客户。起诉书还指控，这些命令获取了客户账户或角色的安全凭证；随后利用这些凭证列出存储桶并复制角色拥有权限的对象。起诉书使用了中性术语“云服务公司”，但公开的民事记录和 Capital One 自己的文件确认该环境为 AWS。

EC2 实例元数据服务的存在是为了让虚拟机上的软件能够了解其运行时环境，并获取与附加身份角色关联的临时凭证。这是一种替代在文件中存储长期访问密钥的有效方法。然而，这种设计假设来自实例的访问是有意义的。如果一个面向 Web 的组件可以被诱导发出任意内部请求，那么“实例本地”就不再等同于“授权的工作负载代码”。

AWS 在2019 年对 IMDSv2 的说明中指出，元数据地址是一个链路本地端点，并解释元数据可能包括附加到实例的角色的临时凭证。第 2 版要求软件首先发出 HTTP PUT 请求以建立会话并获取一个秘密令牌，然后在后续的元数据请求中出示该令牌。AWS 设计该协议旨在增加对常见的未受保护的 Web 应用防火墙、未受保护的反向代理、SSRF 漏洞以及某些第 3 层防火墙或网络地址转换错误的抵抗力。客户可以要求使用第 2 版，或完全禁用元数据访问。

重要的分析点不在于协议修订事后证明了一个缺陷，也不在于客户配置可以免除平台设计者的一切设计责任。重要的是，可以在多个层面强化本地信任假设。Capital One 可以约束 WAF、限制出站到元数据端点、收窄角色权限、限制可访问的存储、检测异常的 API 使用，并减少保留的数据。AWS 可以使元数据协议更难通过透明代理和 SSRF 路径被重用。深度防御认识到，一个应用程序错误不应自动演变为一个身份凭证，而一个身份凭证也不应自动演变为大规模数据导出。

Web 应用防火墙并非泄露事件的唯一原因

将该事件称为防火墙配置错误可能掩盖了三个独立的问题。第一，为什么不受信任的请求能够导致防火墙或其背后的组件访问内部目的地？第二，当这种情况发生时，暴露了什么身份？第三，该身份能做些什么？

第一个是应用程序和网络路径问题。Web 应用防火墙通常被理解为一种在请求到达应用程序之前过滤恶意输入的控制措施。在此事件中，相关配置使其成为了通往内部资源路径的一部分。这种倒置应改变云团队测试边缘控制的方式。WAF 不仅仅是公共边界处的一套规则集；它是一段代码，具有执行上下文、出站可达性、报头、方法以及附加的身份。安全审查必须询问：当控制措施自身被混淆时，它能访问和冒充什么。

第二个问题涉及元数据凭证。临时凭证在重要方面比嵌入的长期密钥更安全：它们会轮换、过期，并且可以集中与一个角色关联。但“临时”描述的是持续时间，而非特权。如果攻击者能够反复获取当前凭证，或者能够在凭证有效窗口内使用它复制大量数据集，那么轮换并不能防止伤害。因此，凭证卫生必须包括凭证的颁发路径及其携带的权限。

第三个问题是最小权限。起诉书指控，获取的账户具有列出和复制目标存储的必要权限。民事法院的2020 年 9 月驳回动议裁决记录了（作为该程序阶段接受的指控）Amazon 对应用层防火墙配置错误以及可能比预期更宽泛的权限的描述。该裁决还记录了原告关于访问存储和数据湖的指控。这些段落并非审判认定。但它们仍然有用，因为法院的处理方式表明，刑事入侵在法律上并不必然切断安全决策与消费者损害之间的所指控的因果链条。

因此，有效的审查不应止步于“WAF 已修复”。它应该重建完整的特权图：公共请求到代理；代理到元数据端点；元数据端点到角色会话；角色到存储列表；存储列表到对象读取；对象读取到解密路径；API 调用到网络出口。每条边都需要有一个所有者、业务理由、预防性控制和遥测。移除一个有故障的规则只能阻止已知的路径，并不能证明身份和数据架构是相称的。

加密保护了介质，而非经授权的滥用

Capital One 表示，作为标准做法，它对数据进行了加密，并对选定的字段（特别是社会安全号码和账号）进行了令牌化处理。它还表示，当时的情况允许解密被访问的数据，而令牌化数据仍然受到保护，因为令牌化使用了不同的方法和密钥。这是对“数据已加密”就解决了控制问题这一常见说法的重要纠正。

静态加密的主要目的是当存储介质、快照或底层存储在授权服务路径之外被访问时保护数据。但应用程序仍然需要读取数据。因此，云存储和密钥管理系统会为满足策略的身份解密信息。如果攻击者获得的凭证与工作负载具有相同的读取权限，加密可以完全按照设计运行，同时将明文释放给使用授权机器身份的未授权人员。

这并不是反对加密的论据，而是主张分离权限。一个暴露给面向公众的控制措施的角色，不应拥有广泛的数据读取和密钥使用权限。高度敏感的字段应在通用存储读取器身份无法跨越的服务边界内进行令牌化或加密。密钥策略、数据策略和角色策略应作为一个授权决定进行审查。否则，三个单独看来合理的配置会交叉作用，授予其所有者在无意中本不想给予的访问权限。

该事件也表明，控制报告为何要区分覆盖范围与后果。“100% 对象已加密”可能为真，而保密风险仍然很高。更有用的董事会衡量指标应展示：每个运行时角色可读取的敏感对象的比例、哪些身份可以调用解密操作、是否有面向公众的工作负载出现在这些路径中，以及一个角色在其正常前缀、容量、区域或时间模式之外读取数据的频率。

检测失败，响应成功

Capital One 的负责任披露计划在外部人员使用时发挥了作用。该公司表示，于 7 月 17 日收到报告，7 月 19 日确认了该漏洞，修复了问题，联系了 FBI，于 7 月 29 日公布了事件，并促成了快速逮捕。这些都是有意义的响应事实。但它们没有回答，为什么内部控制系统未能在 3 月将相关活动做出最终处置。

OCC 的调查结果在更高层面填补了这一空白。在民事罚款同意令中，Comptroller 审计官认定，Capital One 未能建立适当的云风险管理，包括足够的数据丢失防护控制和有效的警报处置。Capital One 既不承认也不否认这些调查结果。“处置”不仅仅意味着生成警报，它是指判定一个事件是良性的、升级、遏制还是以证据结案的过程。

云环境会产生大量的遥测数据：角色假定、元数据使用、存储列表、对象读取、API 源地址、出口流量、拒绝的调用、策略更改以及数据分类事件。更多的信号并不会自动形成检测。一个程序可能收集了每一个相关事件，但如果规则不能关联这些序列，如果阈值对角色正常行为不敏感，如果警报缺乏负责任的所有者，或者结案原因未经独立审查，那么它仍然会失败。

由外部报告导致发现的事实，应被同时记录为一次响应成功和一次保证失败。成功之处在于渠道存在、受到监控并促成了行动。失败之处在于，一条存在四个月的访问路径竟然通过公开活动被发现，而银行的自身控制措施在此之前未能做出最终遏制。负责任披露是一个宝贵的外部感知器，但不应被视为替代对凭证检索、异常存储桶枚举和大规模对象复制的内部检测。

OCC 将泄露事件视为迁移治理失败

最有力的公开问责记录并非技术事后剖析，而是 OCC 2020 年的执法组合。该机构的罚款公告指出，该银行在将重大技术运营迁移至公共云之前，未能建立有效的风险评估流程，也未能及时纠正缺陷。该机构处以 8000 万美元罚款，认可了银行的通知和补救措施，并声明负责任的创新仍需健全的风险管理和内部控制。

同意调查结果异常具体。OCC 发现，在 2015 年前后，该银行在迁移前未能建立有效的风险评估。它发现了网络安全控制设计和实施、数据丢失防护以及警报处置方面的缺陷。还发现内部审计未能识别出众多的控制弱点和漏洞，未能有效向审计委员会报告已识别的问题，并且董事会未能采取有效行动就审计提出的某些问题追究管理层的责任。Capital One 同意该命令以避免诉讼费用，并明确表示既不承认也不否认这些调查结果。

这一框架改变了问责的单位。如果事件是 2019 年创建的一条不良 WAF 规则，那么整改可能集中在工程师、变更审查和即时控制上。如果相关失败始于 2015 年对操作模型评估不足，那么责任系统则包括迁移治理、云控制设计、第二道防线挑战、内部审计、委员会报告、管理层整改和董事会升级。

随附的OCC 停止令将这一更广泛的边界付诸操作。它要求设立一个至少由三名董事组成的合规委员会，制定书面的纠正行动计划，改进技术风险评估、云运营风险管理、独立风险管理、控制测试和内部审计。云计划必须解决边界安全、敏感信息的识别和保护、防止和检测未授权披露以及容器化对象的配置管理。独立风险管理必须定义全面的风险与控制范围，并对第一道防线的固有和剩余网络风险进行质疑评估。

命令中关于控制测试的要求尤为重要。Capital One 必须制定相关云控制措施的清单，将基于风险的测试计划与该清单进行对标，跟踪差距，进行整改或正式接受风险。内部审计必须验证管理层技术资产、可配置设备和软件清单的完整性和准确性；将其审计范围与检查关注点进行映射；纳入来自泄露事件根源分析的教训；修订审计覆盖面；评估员工专业知识；并改进向审计委员会的报告。

这些义务回答了一个反复出现的云治理错误。一家企业可能拥有控制目录和审计计划，但两者之间缺乏可靠的联系。控制目录包含了管理层认为存在的内容。资产清单包含了团队认为自己运营的内容。审计范围包含了审计期待审查的内容。如果这些集合没有互相对账，那么一个面向公众的角色、一条元数据路径、一个存储桶或一个配置引擎可能就存在于不同所有权的模型之间。OCC 命令要求提供证据，证明这些集合是一致的。

董事会问责在于证据，而非会议频率

Capital One 的2020 年委托书声明称，在 7 月 19 日发现事件后，管理层立即向董事会报告了此事。多个委员会的独立成员和全体董事会就事件和响应问题举行了超过 20 次会议。董事会聘请了外部专家，收到了关于根源和整改的报告，加强了监督，并指定风险委员会在审查加强的网络治理中发挥主导作用。管理层设立了一个高级委员会，负责企业网络问题和升级。

这些是合理的治理回应，但会议次数不能证明控制措施有效。OCC 的调查结果侧重于泄露事件之前的时期，当时审计弱点据称未被有效反映，且管理层未就某些未解决的问题被追究责任。因此，有用的比较不是“之前会议少，之后会议多”，而是送达董事的信息是否从活动报告转变为控制证据。

OCC 命令定义了这种证据应支持的内容。董事们被要求确保及时的纠正行动，核实行动的有效性，确保充足的人员和系统，追究管理层的责任，要求充分及时的报告，并处理不合规情况。董事会可以依赖管理层、委员会和第三方，但依赖并不免除确保纠正行动的责任。

对于云元数据和存储风险，董事会级别的资料包应回答具体问题。有多少互联网可达的工作负载可以访问实例元数据？有多少需要更强的会话协议？哪些可以完全禁用元数据？有多少面向公众的角色可以列出或读取敏感对象存储？每个角色在一个凭证有效期内可以获取的最大数据量是多少？哪些控制措施防止数据离开已批准的网络或区域？有多少警报在没有确凿证据的情况下被关闭？哪些云审计问题错过了目标日期，又是哪位高管接受了残余风险？

这些问题中没有一个要求董事们去配置防火墙。它们问的是管理层能否证明其声称的操作边界。这正是行政管理与监督之间的区别。董事们无需了解每个 API 参数，但他们需要一个报告系统，能够在外部研究员之前让危险的组合变得可见。

共享责任是控制地图，而非免责声明

AWS 将云安全描述为提供商与客户共同分担。根据AWS 共享责任模型，AWS 保护运行云服务的基础设施，而客户的职责则因服务选择而异，通常包括客户数据、身份与访问、应用软件、操作系统配置、防火墙配置、加密选择以及流量保护。对于像 EC2 这样的基础设施服务，客户比在全托管服务中控制更多的操作栈。

该模型之所以有用，是因为它防止了一种类别错误：租用计算资源并不使提供商成为客户应用程序权限的运营者。但图表只是治理的开端。许多重要的控制措施都跨越了这条界线。提供商设计元数据服务；客户决定是否以及如何使用它。提供商提供身份策略机制；客户定义角色和权限。提供商生成日志；客户启用、保留、路由并调查它们。提供商提供区域选项；客户选择满足法律义务的区域和架构。提供商使更安全的默认配置成为可能；客户必须迁移现有工作负载并强制执行。

FFIEC 云计算声明明确了金融行业的后果。管理层不应仅仅因为系统在云环境中运行就假定安全性和弹性控制措施已经存在。声明指出，合同应确定各方的责任，但金融机构仍需对安全稳健运营和合规负责。声明强调，治理、云架构、身份、数据管理、漏洞管理、监控、事件响应、业务连续性和审计是相互关联的实践。

因此，共享责任必须被转换成一个足够精确的控制矩阵以进行测试。对于每一项控制措施，矩阵应确定由谁设计、由谁配置、由谁运营、谁接收警报、谁验证有效性、保留哪些证据，以及在证据缺失时由谁行动。类似“客户责任”的标签并非控制措施的所有者。在一家大型银行中，“客户”可能意味着平台工程、应用程序团队、云安全、数据治理、身份工程、企业风险、内部审计、法务或供应商。客户组织内部的模糊性可能比客户与提供商之间的模糊性更为危险。

共享责任图表同样不能决定民事责任。合同条款、陈述、技术设计、通知义务、因果关系、州法律和已证实的事实都很重要。该模型可以指导预期操作，但它并非对过错的司法分配，也不应像一份赔偿契约那样呈递给董事会。

刑事责任、监管责任与民事风险

公开记录支持几种形式的问责，每种都具有不同的法律地位。

刑事责任最为明确。司法部的量刑公告指出，联邦陪审团认定 Thompson 犯有电信欺诈罪、五项未经授权访问受保护计算机罪和破坏受保护计算机罪。检察官证明，她扫描了云账户以寻找配置错误，利用这些错误获取数据和计算能力，并访问了超过 30 个实体。她被判处已服刑期和五年缓刑。这一经裁定的犯罪行为不应被淡化为一次意外发现。

监管问责集中在银行方面。OCC 罚款令是一份最终同意令，但 Capital One 既不承认也不否认 Comptroller 的结论。美联储在协调执法公告中表示，该控股公司必须加强风险管理、治理、网络安全和信息安全控制。随附的美联储同意令要求母公司董事会利用其资源确保各银行遵守 OCC 命令，并提交一份董事会监督的书面计划。

民事风险范围更广，但就最终过错而言结论性较低。消费者根据过失、合同、不当得利、通知和消费者保护等理论起诉了 Capital One 和 Amazon。2020 年 9 月，地区法院批准了被告方部分驳回动议，驳回了其他部分。大多数过失索赔得以继续，而华盛顿州过失索赔和若干自身过失理论被驳回。法院在该阶段得出结论，Thompson 的犯罪行为并不必然取代被告方所指控的过失。由于驳回动议将充分陈述的指控视为真实，该裁决确立了索赔可以继续推进，但并未确立 Capital One 或 Amazon 实施了所指控的行为。

该案件以和解而非实体审判告终。最终批准令批准了一项 1.9 亿美元的非返还性基金、身份保护和恢复服务以及商业实践承诺。该和解协议解决了针对 Capital One 和 Amazon 的索赔。批准意味着法院认为根据集体诉讼规则，该协商解决方案是公平、合理且充分的。它并未在银行、AWS 和攻击者之间分配任何比例的泄露责任。

这一区别很重要，因为“谁负有责任？”这个短语可能引出错误的单一答案。Thompson 因犯罪行为被定罪。Capital One 基于同意调查结果承担了监管制裁并接受了纠正义务。Capital One 和 Amazon 面临了部分存续并最终和解的民事索赔。提供商后来的设计变更与预防相关，但不构成对法律过失的承认。每项陈述都有其来源和程序背景。将它们合并成一个泛泛的判决将是不准确的。

IMDSv2 与更安全默认值的治理

AWS 于 2019 年 11 月推出了 IMDSv2，此时距 Capital One 披露泄露事件不足四个月。AWS 发布通告将其描述为针对未授权元数据访问的深度防御。客户可以在新实例或运行中的实例上要求使用增强的请求方法，或完全关闭元数据访问。第 1 版仍然可用以便兼容。

IMDSv2 的会话令牌制造了针对几种混淆代理路径的摩擦。转发简单 GET 请求的代理可能不允许初始的 PUT 请求。插入转发报头的反向代理可能无法用于创建令牌。令牌与实例绑定，不能简单地从任意机器重放。跳数限制可以限制元数据响应在网络层的传输距离。这些都是有价值的协议控制措施，因为它们降低了应用程序和代理错误的后果。

但它们并未消除最小权限的必要性。如果恶意代码确实在实例上执行，它可能能够像合法代码一样执行令牌交换。如果一个易受攻击的 SSRF 允许任意方法和报头，保护可能不太完整。如果附加的角色可以读取不必要的数据湖，残余后果仍然很高。因此，元数据加固是序列中的一个层，而不是角色设计、出口控制、数据分段和监控的替代品。

默认值还具有时间维度。2019 年，客户必须在更强的方法可用后选择并强制实施它。AWS 后来宣布了一项IMDSv2 默认启用路线图，将控制台快速启动和新发布的实例类型推向第 2 版，同时保留兼容选项。这一演进说明了一个平台治理的困境。立即强制更改可能破坏现有软件；长期保持可选性则让旧有假设继续存在。提供商应使迁移可衡量、提供账户级强制执行、暴露仍在使用第 1 版的情况，并设定明确方向。客户应将可选的安全升级视为具有所有者和截止日期的风险决策，而不是功能积压。

对于董事会而言，教训在于要询问默认债务。有多少工作负载仍然依赖旧版元数据模式？为什么？如果禁用它，什么会中断？哪些应用程序不能容忍更低的跳数限制？哪项组织政策阻止了新的例外？公司如何知道一个收购的账户或开发环境没有偏离正轨？一个可用但未衡量的安全功能，相比一个与清单和强制执行挂钩的迁移计划，提供的保障更少。

数据本地化并未限制逻辑访问

该泄露事件影响了美加边境两侧的民众。加拿大隐私专员办公室在 Capital One 报告 600 万加拿大人受到影响（包括部分人的社会保险号码遭到访问）后，启动了调查。Capital One 的加拿大事件页面提供了特定国家的通知和支持。这种跨境影响将本地化从一个抽象的云采购问题转变为一个问责问题。

此处审查的来源并未确定每个受影响对象的准确 AWS 区域，也未表明加拿大记录保存在独立的加拿大区域。这种缺失应当保留。从数据主体的国籍或全球云品牌推断存储位置是不负责任的。记录确定的只是：一起事件影响了受不同法律和监管体系管辖的大量人口。

AWS 在其数据隐私资料中表示，客户控制客户内容，提供商与客户的职责遵循共享责任模型。其当前的数字主权框架强调客户对工作负载运行位置、数据访问、弹性和控制的选择。这些能力是相关的，但区域选择并非完整的主权结果。

本地化回答的是，在正常操作下服务被配置为在何处存储或处理数据。安全还必须回答：谁能使服务披露它，凭证可在何处被使用，日志和备份流向何处，如何控制支持访问，以及导出的数据是否可以跨越选定的边界。在 Capital One 的事件链条中，一个 API 凭证比靠近磁盘的物理距离更具决定性。一旦一个角色被接受为已授权，存储就可以通过服务接口交付对象。仅凭一个国内区域，本身无法阻止这种逻辑路径。

因此，主权控制至少需要四个层面。第一是放置：已批准的区域、复制设置、备份、分析、灾难恢复和支持服务。第二是权限：身份、密钥使用、元数据访问，以及按网络、账户、组织或区域限制调用的策略。第三是可观测性：保留在独立控制账户中的日志、跨区域传输的证据、对异常源位置的警报，以及供相关监管机构使用的记录。第四是退出与持续性：以可用形式导出数据和日志的能力、撤销提供商访问、轮换密钥，以及在某个区域、提供商或法律传输机制不可用时运行经过测试的恢复安排。

该事件还表明，即使基础设施地理位置不确定，数据主体的地理位置也至关重要。加拿大监管机构、受影响的个人、通知实践以及身份修复需求，并未因为 Capital One 总部在美国而消失。一个跨国云计划应将数据集映射到它们所代表的人群和义务，而不仅仅是工程师眼中它们所在的账户和区域。

数据保留将访问路径变成了历史档案

Capital One 表示，受影响的最大类别包括 2005 年至 2019 年初的应用程序数据。这个时间跨度改变了风险分析。一份信贷申请有其即时目的：评估资格、遵守法律、防止欺诈和建立账户。随着时间推移，某些信息对于服务、法律保全、监管义务、模型治理、争议解决或欺诈分析可能仍然是必要的。但必要性必须按字段、目的和时间段进行证明。

数据保留往往被视为独立于云安全的隐私排程。该泄露事件表明，这种分离是人为的。一个受感染的角色所能触及的数据量和年龄决定了影响。一个完美的删除计划并不能阻止攻击者读取当前记录，但它可以防止一次凭证事件暴露十四年的申请历史。同样，将一个字段分类为敏感字段，如果不因该分类导致任何存储策略、密钥边界、访问角色或删除作业发生变化，则几乎没有效果。

合适的控制并非简单地“删除旧数据”，而是一个可防御的生命周期：识别收集目的；明确保留的法律和业务基础；将活跃的操作数据与受限档案分离；最小化字段；对持久标识符进行令牌化处理；强制执行删除；仅保留有书面例外记录的数据；并测试已删除数据是否也消除了副本、派生数据集、缓存、快照和开发副本。每个例外都应有一个所有者和到期审查。

数据架构还应减少聚合。不应仅仅因为一个处理作业曾经需要，就授予单个角色对广泛历史语料库的访问权限。按目的、敏感性、时间段和司法管辖区进行分区，能为访问策略提供有意义的执行依据。没有这些边界，最小权限就不得不在一个非常大的存储桶或数据湖的层面上操作，而“能运行此应用程序”与“能读取该机构历史”之间的差异就会变得危险地小。

云依赖包括证据依赖

Capital One 并非仅仅租用远程磁盘。与任何大型云客户一样，它依赖提供商定义的身份语义、元数据行为、API 日志记录、区域构造、存储控制、服务可用性、文档以及提供商保存和解释证据的能力。这是一种比正常运行时间更广泛的依赖性。

2019 年的事件并未导致 Capital One 核心银行服务的长时间公开中断。连续性问题在于保密性和信任。该公司不得不调查庞大的云资产，识别受影响的记录，通知两国的人员，与执法部门和监管机构合作，提供监控，进行诉讼辩护，并在继续运营的同时修复控制措施。这是证据受污染下的连续性：服务可能仍然可用，但机构必须确定其记录、身份流程和客户通信是否仍然值得信任。

Capital One 的2019 年 10-K 表格报告称，2019 年新增的响应和补救费用为 7200 万美元，扣除 3400 万美元的保险赔偿。公司预计总的事件调整项目费用将处于其先前宣布的 1 亿至 1.5 亿美元区间的低端，部分成本将延续到 2019 年以后。它警告了监管干预、诉讼、补救成本、声誉损害和信心丧失。这些数字发生在 8000 万美元 OCC 罚款和后来的 1.9 亿美元集体诉讼和解基金之前，并且不应轻易相加，因为保险、时间、和解范围和会计处理各不相同。

证据依赖应在合同和技术层面进行规划。一个受监管的客户需要具有充分字段和保留期限的日志、及时获得提供商事件通知、在司法取证收集方面进行合作、保存义务、区域和子处理商信息、控制报告访问、漏洞沟通，以及针对政府和监管机构请求的程序。它还需要在一个被侵入的工作负载无法篡改的安全账户中保留自己的一份关键日志副本。一个提供商仪表盘显示服务运行正常，并不能证明客户身份的范围设定得当。

退出规划应属于同一套方案。将数据和身份策略集中在一个提供商处可以改善标准化和可见性，但也可能导致迁移困难。一次退出测试应衡量清点数据、复制访问策略、导出密钥或重新加密、转移日志、重建检测、满足本地化约束以及在旧提供商处证明删除所需的时间。多云部署并不自动更安全；复制不成熟的控制措施可能使不确定性加倍。目标是数据与证据的可信可移植性，而不是装饰性的提供商数量。

和解协议解决了什么，又留下了什么

消费者和解协议规模巨大，但其含义应谨慎表述。该和解设立了一个 1.9 亿美元的基金，用于符合条件的自付损失、时间损失、身份保护服务、恢复服务、通知和行政费用以及法院批准的费用。它还包括了商业实践承诺。最终批准令认为该和解公平、合理且充分，并带有偏见地驳回了被免除的消费者索赔。

和解并未确立修正诉状中的每一项指控均为真实。它并未将驳回动议的背景材料转变为证据之后的认定。它并未认定 AWS 的元数据设计造成了特定比例的损害，也未认定 Capital One 的配置造成了其余部分。它并未抹去 Thompson 的刑事责任，也未取代 OCC 独立的监管调查结果和命令。

这种未解决的分配本身就是一个治理教训。企业不能等待法院分配一个精确的百分比，然后再去改进共享控制。平台提供商可能在没有任何经裁定的责任的情况下添加更安全的协议。客户可能对监管调查结果提出异议，但仍然接受命令并全面整改控制措施。董事会可能在保留法律抗辩的同时，将操作事实视为紧急处理。法律姿态和补救姿态可以不同而互不矛盾。

OCC 后来宣布，它于 2022 年 8 月 31 日终止了 2020 年的停止令。终止对该特定命令而言是一个重要终点。但它并未取消罚款、重写历史调查结果，或证明云风险已变得静止不变。一个成熟的董事会应该将命令中的控制清单、测试、审计和报告纪律转化为常规治理，而不是让它们随着监管监督的结束而失效。

一份针对元数据、身份和本地化风险的证据包

Capital One 的记录为在公共云中运行敏感工作负载的组织提供了一个实用的证据包。

映射公共路径到内部权限。盘点每一个可从互联网访问的代理、负载均衡器、WAF、API 网关和应用程序。对于每一个，展示出站目的地、元数据可达性、附加的身份、允许的方法和报头，以及通过该身份可触及的最大数据权限。从攻击者视角测试路径，而不仅仅对照预期的架构图。

使元数据态势可衡量。记录是否需要元数据、是否可以禁用、需要哪个协议版本、跳数限制、本地防火墙限制、容器影响，以及观察到的旧版调用。在组织或账户级别强制执行首选状态。例外应标识依赖的软件、风险所有者、补偿控制措施和移除日期。

计算凭证爆炸半径。对于每个运行时角色，枚举其可触及的存储前缀、数据库、队列、密钥、密钥操作和管理员操作。估计在一次凭证有效期内以及从哪些网络位置可能读取多少敏感数据。测试有效权限，包括身份、资源、密钥、端点和组织策略的交叉。

将存储访问与解密权限分离。加密不应与通过应用程序路径暴露的角色混为一体。对持久身份字段使用令牌化或单独的服务。当面向公众的身份调用密钥操作或读取超出其狭窄目的的数据类别时发出警报。

按目的和司法管辖区控制数据。根据敏感性、目的、保留期限和受影响人群标记和分区数据。对主存储、副本、分析、备份和恢复实施已批准的区域。记录任何必然会移动内容或支持数据的服务。测试跨区域和跨账户的拒绝，而不仅仅是配置的位置。

拥有审计追踪。将身份、元数据、存储、密钥、网络和数据丢失事件路由到一个独立管理的日志环境中。保护日志免受工作负载角色的影响。关联凭证检索、列表操作、对象读取、解密和出口。衡量警报是否被调查并得出有证据支持的结论，而不仅仅是是否被生成。

对账控制范围。管理层的云控制目录、资产清单、配置清单、数据目录、风险登记簿和审计范围应具有通用标识符。内部审计应测试完整性，而不仅仅从管理层的列表中抽样。未匹配的资产和控制措施应被报告为未知覆盖。

升级重复和逾期的发现。一个带有逾期的补救日期的配置漏洞，应与其暴露的身份和数据路径一同出现。董事会报告应指明责任高管、补偿控制措施、验证方法和截止日期。结案应要求有独立证据证明风险状况已改变。

演练跨境响应。泄露演练应识别涉及哪些人群和监管机构，哪些记录显示位置和访问情况，如何发送特定国家的通知，以及如何针对不同的政府标识符和信用体系进行身份恢复。组织应能够解释受影响数据的存储位置，而无需在危机期间临时拼凑答案。

保留提供商合作与退出权利。合同和运营程序应保障及时获取日志、取证支持、事件通知、证据保存、区域承诺、子处理商透明度以及删除认证。团队应定期测试将数据、策略、密钥和审计证据导出到可用的恢复环境中。

这套证据包之所以要求严格，是因为风险是组合性的。WAF 可能满足其基线。元数据服务可能按文档运行。角色可能有业务理由。存储桶可能是私有的。对象可能已加密。日志可能存在。然而，这些因素的交叉点仍可能允许一个公共请求变成一次授权的数据导出。问责制属于这些交叉点。

持久的检验

Capital One 的泄露事件仍然是一个有用的云问责案例，因为它抗拒两种简单的叙事。第一种说公共云导致了该泄露事件。这种说法忽略了客户控制的配置、权限、数据架构、监控，以及 OCC 关于该银行云风险计划的直接调查结果。第二种说法将共享责任完全置于客户身上。这种说法将提供商图表视为设计分析的终点，忽视了更强健的元数据服务防御、更安全的默认配置、提供商遥测和合同证据的价值。

更好的叙述应该追踪整个链条。一个面向公众的控制措施可以中继一个非预期的请求。该请求到达了一个元数据信任边界。由此产生的临时身份拥有足够的权限来列出并复制存储的信息。加密并未阻止一个被接受为已授权的凭证读取数据。内部监控未能产生及时的遏制。过长的数据保留范围扩大了暴露的语料库。同一事件波及了美国和加拿大隐私制度下的人群。审计和董事会报告未能强制解决监管机构指出的更广泛的云控制漏洞。

责任随后按论坛分离。攻击者被定罪。银行监管机构对 Capital One 施加了同意义务和罚款。消费者同时追究了 Capital One 和 Amazon；索赔部分存续，并在未经审判分配过错的情况下和解。AWS 推出了更具防御性的元数据协议。Capital One 描述了补救措施，加强了董事会监督，并承担了巨额的响应、执法和和解成本。

对于未来的董事会，决定性问题不是云提供商是否经过认证，存储桶是否加密，或者防火墙规则是否已修复。而是该机构能否证明：任何不受信任的路径都不能获得具有不成比例权限的工作负载身份；该身份的异常使用将被检测和解决；可触及的数据受目的、时间和司法管辖区的限制；并且提供商和客户的证据能够足够快速地结合以治理该风险。

这种证明正是共享责任的实践含义。没有它，责任仅仅在纸面上被分割，而风险却在生产中保持连接。