本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 制定全球扩展战略
**调查**
我们很乐意听取您的意见。请通过[简短的调查](https://amazonmr.au1.qualtrics.com/jfe/form/SV_cMxJ0MG3jU91Fk2)提供 AWS 有关 PRA 的反馈。
AWS 在全球扩张 AWS 时，[安全保障服务](https://aws.amazon.com/professional-services/security-assurance-services/)经常会收到有关隐私架构的问题。这些问题通常围绕如何在符合特定隐私要求（例如数据主权义务或客户合同）的同时，避免增加额外成本和运营开销。设计考虑因素通常包括数据驻留、运营人员访问限制、恢复能力和生存能力以及整体独立性。有关更多信息，请参阅[满足数字主权要求 AWS](https://d1.awsstatic.com/events/Summits/reinvent2022/SEC205_Meeting-digital-sovereignty-requirements-on-AWS.pdf)（re AWS : Invent 2022 演示文稿）。
以下是一些较为常见的问题，只有您才能根据自己的使用案例回答这些问题：
+ 客户的个人数据需要存放在哪里？
+ 我的客户数据存储在哪里？
+ 个人数据如何以及在哪里进行跨境传输？
+ 跨区域的人工或服务访问数据是否构成传输？
+ 如何确保外国政府不会访问客户的个人数据？
+ 我可以在哪里存储备份以及热站点或冷站点？
+ 为了将数据保存在本地，我是否应该在我提供服务的每个区域都有一个 AWS 着陆区？ 或者我可以使用现有的 AWS Control Tower 着陆区？
对于数据驻留要求，不同的架构部署可能更适合不同的组织。有些组织可能要求将其客户的个人数据保留在特定区域内。如果是这种情况，您可能需要考虑如何在履行这些义务的同时，总体上遵守相关法规。无论情况如何，在选择多账户部署策略时都需要考虑多个因素。
要定义关键架构设计组件，请与您的合规与合同团队密切合作，以确认个人数据在何处、何时以及如何跨越 AWS 区域的要求。确定哪些行为属于数据传输，例如移动、复制或查看。此外，了解是否必须实施特定的韧性和数据保护控制措施。备份和灾难恢复策略是否需要跨区域失效转移？ 如果需要，请确定哪些区域可用于存储备份数据。确定是否对数据加密有任何要求，例如特定的加密算法或生成密钥的专用硬件安全模块。在与合规利益相关者就这些主题达成一致后，即可开始考虑多账户环境的设计方案。
**Topics**
+ [带托管区域的中央登录区](#global-expansion-central)
+ [区域登录区](#global-expansion-regional)
+ [AWS 欧洲主权云](#global-expansion-eea)
需要注意的是，隐私合规可能不仅仅局限于数据主权。查看本指南的其余部分，了解应对诸多其他挑战的可能解决方案，例如同意管理、数据主体的请求、数据治理和人工智能偏见。
## 带托管区域的中央登录区
如果您想在全球范围内扩张，但已经在中建立了多账户架构 AWS，那么通常需要使用相同的多账户着陆区 (MALZ) 来管理其他账户。 AWS 区域在此配置中，您将继续从您创建登录区域的现有 AWS Control Tower 着陆区（Landing zone）运营基础设施服务，例如日志记录、账户工厂和一般管理。
对于生产工作负载，您可以通过将 AWS Control Tower 登录区扩展到新区域来运营区域部署。这样便可将 AWS Control Tower 治理范围扩展到新区域。这样，您就可以将个人数据存储在特定的托管区域内，数据仍存储在受益于基础设施服务和 AWS Control Tower 治理的账户中。在中 AWS Organizations，包含个人数据的帐户仍会汇总到专门的个人数据OU下，其中所有数据主权保护措施 AWS Control Tower 都在那里实施。此外，区域特定的工作负载放在专用账户中，而不是在多个区域中建立可能包含相同工作负载的生产账户。
这种部署可能是最具成本效益的，但要控制跨区域的个人数据流动 AWS 账户 ，还需要考虑其他因素。请考虑以下事项：
+ 日志可能包含个人数据，因此可能需要进行一些额外的配置以包含或编辑敏感字段，从而防止在聚合期间进行跨区域传输。有关控制跨区域日志聚合的更多信息和推荐做法，请参阅本指南中的[集中式日志存储](log-archive-account.md#centralized-log-storage)。
+ 在 AWS Transit Gateway 设计中考虑隔离 VPCs 和适当的双向网络流量。您可以限制允许和批准哪些中转网关连接，也可以限制哪些人员能够更改 VPC 路由表和可以更改哪些内容。
+ 您可能需要阻止云运营团队成员访问个人数据。例如，系统可能认为包含客户事务数据的应用程序日志比其他日志源具有更高的敏感性。可能需要额外的批准和技术护栏，例如基于角色的访问控制和[基于属性的访问控制](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)。此外，访问数据时可能会受到驻留限制。例如，一个区域 A 中的数据只能从该区域内访问。
下图显示集中式登录区及区域部署。
![\[集中式登录区及区域部署。\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/privacy-reference-architecture/images/global-expansion-central.png)
## 区域登录区
与非物质工作负载相比，拥有多个 MALZ 可以完全隔离处理个人数据的工作负载，从而帮助您实现更严格的合规要求。 AWS Control Tower 默认情况下可以配置集中式日志聚合，因此可以简化。使用此方法时，您无需为需要编辑的单独日志流维护日志记录例外。您甚至可以为每个 MALZ 设立本地专属云运营团队，从而将运营人员的访问权限限制为本地驻留。
许多组织在美国和欧盟都有单独的登录区部署。每个区域登录区都对该区域中的账户采用一刀切的安全策略和相关的治理。例如，在一个 MALZ 的工作负载中 HSMs 可能不需要使用专用加密个人数据，但在另一个 MALZ 中可能需要使用专用加密功能。
尽管此策略可以扩展以满足当前和未来的许多需求，但重要的是要了解与维护多个策略相关的额外成本和运营开销 MALZs。有关更多信息，请参阅[AWS Control Tower 定价](https://aws.amazon.com/controltower/pricing/)。
下图显示两个区域中单独的登录区。
![\[两个区域中单独的登录区。\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/privacy-reference-architecture/images/global-expansion-regional.png)
## AWS 欧洲主权云
一些组织要求将其在欧洲经济区（EEA）运营的工作量与在其他地区运营的工作量彻底分开。在这种情况下，可以考虑使用 [AWS 欧盟主权云服务](https://aws.eu/)。 AWS 欧盟主权云服务是面向欧盟的新型独立云，旨在帮助客户满足该区域不断演进的主权需求，包括严格的数据驻留、运营自主权和韧性要求。
AWS 欧洲主权云在物理和逻辑上都与现有云分开 AWS 区域，同时提供相同的安全性、可用性和性能。只有位于欧盟的 AWS 员工才能控制 AWS 欧洲主权云的运营和支持。如果您有严格的数据驻留要求， AWS 欧洲主权云会将您创建的所有元数据（例如角色、权限、资源标签和他们用来运行的配置 AWS）保留在欧盟。 AWS 欧洲主权云还具有自己的计费和使用量计量系统。
对于此方法，您将使用与上一节[区域登录区](#global-expansion-regional)中类似的模式。但是，对于您向欧洲客户提供的服务，您可以在 AWS 欧洲主权云中部署专用的MALZ。