【云安全】AWS Nitro系统的安全设计 --将工件放在一起：EBS卷附件

为了更好地了解Nitro系统的多个部分一起运行，让我们来回顾一下当客户发出公开的EC2API调用以更改其在Nitro上的EC2实例的运行状态时会发生什么。特别是，我们将研究客户将现有加密EBS卷附加到正在运行的实例的情况。

在第一步中，客户使用AWS命令行界面（AWS CLI）、AWS SDK或AWS管理控制台以实例为目标调用AttachVolume命令。验证客户的IAM身份是否经过验证并被授权执行AttachVolume命令后，API调用由EC2和EBS控制平面内的一组微服务处理。最后，控制平面服务调用由Nitro控制器提供的一组定义的加密、认证的网络API，其中包含分配附加卷所需的资源所需的信息。此操作涉及多个服务，每个微服务都有各自的职责，限制了对Nitro Controller API的访问范围。

EC2控制平面为EBS分配Nitro卡的PCIe设备资源，这些资源用于逻辑EBS卷的读写服务（虚拟化实例的NVMe虚拟功能或裸机实例的NVMe物理功能）。EBS控制平面提供连接到EBS服务器所需的信息，EBS服务器通过网络存储加密卷数据，还提供存储为卷元数据的卷数据密钥的加密副本。加密数据密钥受AWS密钥管理服务（AWS KMS）内部的AWS KMS密钥保护；因此，作为附加卷过程的一部分，加密密钥必须发送到AWS KMS进行解密。

假设发出AttachVolume命令的客户IAM身份也被授权使用预期的AWS KMS密钥在AWS KMS中发出Decrypt命令，则加密卷的数据密钥将被解密。Nitro系统对此操作的访问受到AWS KMS授权和IAM转发访问会话的保护。（请参阅AWS副总裁兼杰出工程师Colm MacCárthaigh在演讲中关于弹性负载平衡、AWS证书管理器和AWS密钥管理服务的IAM前向访问会话的解释。）

总之，这些机制以密码方式确保Nitro系统只有在客户最近授权并验证了该访问时才被授予使用客户的AWS KMS管理密钥的权限。Nitro系统不允许在临时基础上使用AWS KMS管理的密钥，或者没有最近的客户授权。

在AWS KMS内部解密后，在使用加密传输层安全（TLS）网络连接发送到Nitro控制器之前，AWS KMS使用公钥再次加密数据密钥，该公钥用作单个生产Nitro主机服务器的加密数字标识。EBS控制平面将该公钥与加密卷的数据密钥一起发送给AWS KMS。因此，除了通过TLS在网络上加密整个消息之外，数据密钥也在网络上双重加密的消息中不对称加密。只有具有特定客户计算环境的特定生产主机的Nitro卡具有解密加密数据密钥所需的私钥。一旦本地解密，在卷连接和使用期间，该明文数据密钥仅存储在单个Nitro卡的易失性存储器中。

现在，Nitro EBS卡已准备好通过NVMe接口的PCIe附件将EBS卷呈现给EC2实例。当主机配置为使用Nitro Hypervisor时，Nitro控制器通过PCIe接口发送一条消息，指示Nitro Hypervisor将该EBS卷的NVMe虚拟功能分配给相应的EC2实例。然后，管理程序向VM发送虚拟硬件热插拔事件，以警告客户提供的系统软件有新的NVMe块设备可用。在裸机实例的情况下，EBS的Nitro卡直接向服务器处理器发出PCIe热插拔事件的信号，并且在处理器上运行的客户提供的系统软件与在任何其他服务器上一样处理NVMe设备的PCIe热插拔。

此时，作为虚拟客户机或裸机实例运行的客户实例操作系统通过PCIe接口与Nitro Card for EBS提供的NVMe设备交互。这种交互在虚拟化EC2实例的情况下作为SR-IOV功能发生，或者在裸机EC2实例情况下作为PCIe物理功能发生。通过PCIe接口发送的NVMe命令由运行在用于EBS的Nitro卡上的固件处理，该固件又通过Nitro SoC的集成网络接口与EBS服务交互。而且，如前所述，Nitro EBS卡还能够卸载AES-256 XTS加密EBS卷的加密操作，以便在离开Nitro卡之前，对每个客户数据块进行完全加密，而不会影响性能。客户还可以选择在操作系统级别使用加密文件系统，以便在将所有客户数据写入或传输到用于EBS的Nitro卡之前对其进行完全加密。这种方法还为在线和EBS存储系统中的EBS数据建立了额外的加密层。