AWS 加密与数据主权 - 从 KMS 到 Nitro Enclaves 实现硬件级隔离
解析 AWS KMS、CloudHSM、Nitro Enclaves 实现的硬件级加密与数据主权保障，并与其他云服务商的设计差异进行比较。
加密的层次结构这一设计原则
AWS 的加密策略设计为可根据用途和需求选择的层次结构。最便捷的层是使用 AWS 托管密钥的服务端加密，S3、EBS、RDS 等主要服务默认启用加密。用户无需任何操作即可获得静态数据加密。下一层是 KMS 的客户托管密钥（CMK），用户可以自行管理密钥的生命周期、轮换策略和访问策略。再下一层是 CloudHSM，在专用硬件中管理密钥，密钥材料绝不离开 HSM 设备。最高层是 Nitro Enclaves，实现处理中数据的硬件级隔离。这种层次结构使用户可以根据合规要求和安全需求选择适当的加密级别，避免过度设计或保护不足。
KMS 的设计与信封加密
AWS KMS 采用信封加密（Envelope Encryption）方法。数据本身用数据密钥（DEK）加密，该数据密钥再用主密钥（CMK）加密的双重结构。这种设计有明确的理由。直接用主密钥加密大量数据在性能上不现实，且主密钥的使用频率越高安全风险越大。信封加密将数据加密和密钥保护分离，兼顾性能和安全性。KMS 的 CMK 绝不以明文形式离开 KMS 服务边界。加密和解密操作在 KMS 内部的 HSM 中执行，即使 AWS 运维人员也无法访问密钥材料。这一设计通过 SOC 报告和第三方审计得到验证。密钥策略和 IAM 策略的组合可以精细控制谁能使用哪个密钥执行什么操作。
CloudHSM 实现专用硬件密钥管理
CloudHSM 是在 VPC 内提供获得 FIPS 140-2 Level 3 认证的专用 HSM 设备的服务。与 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 与 Nitro 系统的深度集成以及与 KMS 的原生协作是 AWS 独有的优势。
数据主权与其他云服务商的比较
数据主权（Data Sovereignty）是数据应按其物理所在国法律管理的原则。AWS 通过区域选择实现数据的地理控制、通过 KMS 和 CloudHSM 实现加密密钥的客户管理、通过 Nitro Enclaves 实现处理中数据的保护，提供多层数据主权保障。Azure 的 Sovereign Cloud 和 GCP 的 Sovereign Controls 也提供数据主权功能，但 AWS 的优势在于这些功能不是作为独立的主权云产品提供，而是作为标准服务的功能内置。客户无需迁移到特殊环境即可在现有 AWS 环境中实现数据主权要求。如果想系统学习加密技术，相关书籍 (Amazon) 也可供参考。
总结
AWS 的加密策略提供了从托管密钥自动加密到 KMS 客户托管密钥、CloudHSM 专用硬件、Nitro Enclaves 处理中数据保护的层次结构。信封加密实现性能与安全的兼顾，CloudHSM 满足法规要求的专用硬件密钥管理，Nitro Enclaves 实现处理中数据的硬件级隔离。数据主权方面，这些功能作为标准服务内置而非独立主权云产品提供，是 AWS 的设计优势。加密与数据主权的综合保障能力方面，AWS 领先于其他云服务商。