AWS 加密与数据主权 - 从 KMS 到 Nitro Enclaves 实现硬件级隔离
解析 AWS KMS、CloudHSM、Nitro Enclaves 实现的硬件级加密与数据主权保障，并与其他云服务商的设计差异进行比较。
加密的层次结构这一设计原则
AWS 的加密策略设计为可根据用途和需求选择的层次结构。第一层是使用 AWS 托管密钥的服务端加密，适用于 S3、EBS、RDS 等服务。在这一层，用户无需管理密钥，静态数据根据相应的服务和设置进行加密。下一层是 KMS 的客户托管密钥，用户可以自行管理密钥的生命周期、轮换策略和访问策略。再下一层是 CloudHSM，在专用硬件中管理密钥。最高层是 Nitro Enclaves，实现处理中数据的硬件级隔离。这种层次结构使用户可以根据合规要求和安全需求选择适当的加密级别。
KMS 的设计与信封加密
AWS KMS 采用信封加密（Envelope Encryption）方法。数据本身用数据密钥（DEK）加密，该数据密钥再用 KMS 密钥加密的双重结构。这种设计有明确的理由。直接用 KMS 密钥加密大量数据在性能上不现实，且 KMS 密钥的使用频率越高安全风险越大。信封加密将数据加密和密钥保护分离，兼顾性能和安全性。KMS 密钥绝不以明文形式离开 KMS 服务边界。加密和解密操作在 KMS 内部的 HSM 中执行。这一设计通过 SOC 报告和第三方审计得到验证。密钥策略和 IAM 策略的组合可以精细控制谁能使用哪个密钥执行什么操作。
CloudHSM 实现专用硬件密钥管理
CloudHSM 是在 VPC 内提供专用 HSM 设备的服务，FIPS 模式的集群通过 FIPS 140-2 Level 3 或 FIPS 140-3 Level 3 验证。与 KMS 的区别在于客户自行管理所使用的算法和密钥。KMS 是在 AWS 托管服务中创建和控制密钥，而 CloudHSM 的数据平面经过端到端加密，AWS 无法看到。CloudHSM 适用于法规要求密钥必须在专用硬件中管理的场景（金融机构、医疗机构等），以及需要 PKCS#11、JCE、CNG 等标准加密 API 的应用。CloudHSM 集群可跨多个 AZ 部署以提高可用性，密钥材料在集群内自动同步。
Nitro Enclaves - 处理中数据的硬件隔离
传统加密保护静态（at rest）和传输中（in transit）的数据，但处理中（in use）的数据以解密状态存在于内存中，难以保护。Nitro Enclaves 通过 Nitro Hypervisor 创建与主 EC2 实例隔离的执行环境来解决这一课题。Enclave 没有持久存储、没有网络访问、没有交互式访问。即使主实例的 root 用户也无法访问 Enclave 内部的内存和处理。这使得在处理个人信息、医疗数据、金融数据等敏感信息时，可以将数据处理与主实例隔离。Azure 的 Confidential Computing 和 GCP 的 Confidential VMs 也提供类似功能，Nitro Enclaves 则与 KMS 集成。
数据主权与其他云服务商的比较
数据主权（Data Sovereignty）是数据应按其物理所在国法律管理的原则。AWS 通过区域选择实现数据的地理控制、通过 KMS 和 CloudHSM 实现加密密钥的客户管理、通过 Nitro Enclaves 实现处理中数据的保护，提供满足数据主权要求的机制。Azure 的 Sovereign Cloud 和 GCP 的 Sovereign Controls 也提供数据主权功能，AWS 将这些功能作为标准服务的功能提供。客户无需迁移到特殊环境即可在现有 AWS 环境中实现数据主权要求。
总结
AWS 的加密策略提供了从托管密钥加密到 KMS 客户托管密钥、CloudHSM 专用硬件、Nitro Enclaves 处理中数据保护的层次结构。信封加密实现性能与安全的兼顾，CloudHSM 满足法规要求的专用硬件密钥管理，Nitro Enclaves 实现处理中数据的硬件级隔离。数据主权方面，这些功能作为标准服务内置提供，这是 AWS 的设计方式。在加密与数据主权方面，AWS 提供上述多层功能。
参考资料（AWS 官方）
本页的第一手信息来源是 AWS 官方网站及官方文档。最新的规格与价格请以下列官方页面为准。
如本页内容与官方文档不一致，请以官方文档为准。