制定全球扩展战略 - AWS 规范性指导
带托管区域的中央登录区区域登录区AWS 欧盟主权云服务

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

制定全球扩展战略

调查

我们很乐意听取您的意见。请通过简短的调查提供有关 AWS PRA 的反馈。

AWS 安全保障服务团队经常收到关于在全球扩展时如何在 AWS 上构建隐私架构的问题。这些问题通常围绕如何在符合特定隐私要求（例如数据主权义务或客户合同）的同时，避免增加额外成本和运营开销。设计考虑因素通常包括数据驻留、运营人员访问限制、恢复能力和生存能力以及整体独立性。有关更多信息，请参阅 Meeting digital sovereignty requirements on AWS（AWS re:Invent 2022 演示文稿）。

以下是一些较为常见的问题，只有您才能根据自己的使用案例回答这些问题：

  • 客户的个人数据需要存放在哪里？

  • 我的客户数据存储在哪里？

  • 个人数据如何以及在哪里进行跨境传输？

  • 跨区域的人工或服务访问数据是否构成传输？

  • 如何确保外国政府不会访问客户的个人数据？

  • 我可以在哪里存储备份以及热站点或冷站点？

  • 为使数据保留在本地，我应该在提供服务的每个区域都维护一个 AWS 登录区，还是可以使用现有的 AWS Control Tower 登录区？

对于数据驻留要求，不同的架构部署可能更适合不同的组织。有些组织可能要求将其客户的个人数据保留在特定区域内。如果是这种情况，您可能需要考虑如何在履行这些义务的同时，总体上遵守相关法规。无论情况如何，在选择多账户部署策略时都需要考虑多个因素。

要定义关键架构设计组件，请与您的合规与合同团队密切合作，以确认个人数据在何处、何时以及如何跨越 AWS 区域的要求。确定哪些行为属于数据传输，例如移动、复制或查看。此外，了解是否必须实施特定的韧性和数据保护控制措施。备份和灾难恢复策略是否需要跨区域失效转移？ 如果需要，请确定哪些区域可用于存储备份数据。确定是否对数据加密有任何要求，例如特定的加密算法或生成密钥的专用硬件安全模块。在与合规利益相关者就这些主题达成一致后，即可开始考虑多账户环境的设计方案。

以下是可用于规划 AWS 多账户策略的三种方法，按基础设施分割程度的升序排列：

需要注意的是，隐私合规可能不仅仅局限于数据主权。查看本指南的其余部分，了解应对诸多其他挑战的可能解决方案，例如同意管理、数据主体的请求、数据治理和人工智能偏见。

带托管区域的中央登录区

如果希望在全球范围内扩展，但已经在 AWS 中建立了多账户架构，通常的做法是使用同一多账户登录区（MALZ）来管理其他 AWS 区域。在此配置中，您将在创建登录区的区域中，继续通过现有的 AWS Control Tower 登录区运营基础设施服务，例如日志记录、账户工厂和常规管理。

对于生产工作负载，您可以通过将 AWS Control Tower 登录区扩展到新区域来运营区域部署。这样便可将 AWS Control Tower 治理范围扩展到新区域。通过这种方式，您可以将个人数据存储在特定的托管区域内，同时数据仍驻留在受益于基础设施服务和 AWS Control Tower 治理的账户中。在 AWS Organizations 中，包含个人数据的帐户仍会汇总到专用的个人数据 OU 下，其中实施了 AWS Control Tower 的所有数据主权护栏。此外，区域特定的工作负载放在专用账户中，而不是在多个区域中建立可能包含相同工作负载的生产账户。

这种部署可能是最具成本效益的，但要控制跨 AWS 账户和区域的个人数据流动，还需要考虑其他因素。请考虑以下事项：

  • 日志可能包含个人数据，因此可能需要进行一些额外的配置以包含或编辑敏感字段，从而防止在聚合期间进行跨区域传输。有关控制跨区域日志聚合的更多信息和推荐做法，请参阅本指南中的集中式日志存储。

  • 在 AWS Transit Gateway 设计中考虑 VPC 的隔离和适当的双向网络流量。您可以限制允许和批准哪些中转网关连接，也可以限制哪些人员能够更改 VPC 路由表和可以更改哪些内容。

  • 您可能需要阻止云运营团队成员访问个人数据。例如，系统可能认为包含客户事务数据的应用程序日志比其他日志源具有更高的敏感性。可能需要额外的批准和技术护栏，例如基于角色的访问控制和基于属性的访问控制。此外，访问数据时可能会受到驻留限制。例如，一个区域 A 中的数据只能从该区域内访问。

下图显示集中式登录区及区域部署。

集中式登录区及区域部署。

区域登录区

拥有多个 MALZ 可以将处理个人数据的工作负载与非关键工作负载完全隔离，从而帮助您实施更严格的合规要求。默认情况下，可以配置 AWS Control Tower 集中式日志聚合，从而简化该流程。使用此方法时，您无需为需要编辑的单独日志流维护日志记录例外。您甚至可以为每个 MALZ 设立本地专属云运营团队，从而将运营人员的访问权限限制为本地驻留。

许多组织在美国和欧盟都有单独的登录区部署。每个区域登录区都对该区域中的账户采用一刀切的安全策略和相关的治理。例如，一个 MALZ 的工作负载中可能不需要使用专用 HSM 对个人数据进行加密，但在另一个 MALZ 中则可能需要该加密措施。

尽管此策略可扩展以满足当前和未来的诸多需求，但了解与维护多个 MALZ 相关的额外成本和运营开销至关重要。有关更多信息，请参阅AWS Control Tower定价。

下图显示两个区域中单独的登录区。

两个区域中单独的登录区。

AWS 欧盟主权云服务

一些组织要求将其在欧洲经济区（EEA）运营的工作量与在其他地区运营的工作量彻底分开。在这种情况下，可以考虑使用 AWS 欧盟主权云服务。AWS 欧盟主权云服务是面向欧盟的新型独立云，旨在帮助客户满足该区域不断演进的主权需求，包括严格的数据驻留、运营自主权和韧性要求。

AWS 欧盟主权云服务在物理和逻辑上都与现有的 AWS 区域分开，同时提供相同的安全性、可用性和性能。只有位于欧盟的 AWS 员工才能控制 AWS 欧盟主权云服务的运营和支持。如果您有严格的数据驻留要求，AWS 欧盟主权云服务会将您创建的所有元数据（例如角色、权限、资源标签及其用来运行 AWS 的配置）保留在欧盟境内。AWS 欧盟主权云服务还配备自己的计费和使用量计量系统。

对于此方法，您将使用与上一节区域登录区中类似的模式。但是，对于向欧盟客户提供的服务，您可以在 AWS 欧盟主权云服务中部署专用的 MALZ。