Nitro系统的软件和固件由不同的全球分布的工程师团队开发。所有与Nitro系统相关的配置和代码更改都要经过多方审查和批准，并在测试和生产环境中分阶段推出。软件开发从设计文档和评审开始，并通过代码评审。独立AWS安全团队和亚马逊EC2工程团队将对重大更改或功能进行安全审查。

所有变更均由至少一名额外的工程团队成员或利益相关者进行审查，并由一名拥有大量EC2任期的工程师进行审查，该工程师是我们变更管理Bar Raiser项目的成员。除了专家人工审查之外，所有代码签入都必须通过一系列的自动质量和安全检查，这些检查无法通过，并且在中央构建服务的控制下自动运行，确保遵循部署最佳实践，包括适当的监控和回滚。

一旦代码审查和批准完成，并且所有自动化检查都通过，我们的自动化包部署过程就接管了。作为自动化部署管道的一部分，构建二进制工件，团队运行端到端、验证和安全特定测试。如果任何类型的验证失败，部署过程将停止，直到问题得到补救。

软件和固件二进制文件使用非对称私钥进行加密签名，该私钥只能通过记录所有密钥签名活动的自动管道访问。

签名的软件和固件由专门的EC2部署系统部署到EC2车队，该系统配置为遵循定义的部署策略和时间表。更改在可用性区域和地区之间一波又一波地展开。对部署进行监控，以确保只有按预期运行的软件版本保持部署状态，并且任何异常行为都会触发自动回滚。

笔记

有关Amazon如何构建和操作软件的更多信息，请参阅Amazon Builder的库。具体而言，AWS高级首席工程师Clare Liguri自动化了安全、无需手动的部署，AWS软件开发高级经理Mark Mansour加快了持续交付，AWS高级主工程师Sandeep Pokkunuri确保了部署期间的回滚安全。

如前所述，Nitro系统由三个主要部件组成：

• 专用Nitro卡
• Nitro安全芯片
• Nitro虚拟机监控程序

Nitro卡

现代EC2服务器由一个主系统板和一个或多个Nitro卡组成。系统主板包含主机CPU（Intel、AMD或Graviton处理器）和内存。Nitro卡是具有强大的64位处理能力和专用专用集成电路（ASIC）的专用硬件组件，独立于运行所有客户计算环境（包括代码和数据处理操作）的系统主板运行。

Nitro卡实现了EC2服务用于提供和管理计算、内存和存储的所有面向外部的控制接口。它们还提供所有I/O接口，例如提供软件定义的网络、Amazon EBS存储和实例存储所需的接口。这意味着，在主系统板之外与EC2服务的外部世界交互的所有组件，无论是逻辑上入站还是出站，都在独立的计算设备上运行，这些设备在物理上与运行客户工作负载的系统主板分离。

Nitro系统设计用于在主机组件和Nitro卡之间提供强大的逻辑隔离，两者之间的物理隔离提供了一个牢固可靠的边界，有助于实现该设计。虽然在逻辑上隔离且物理上独立，但Nitro卡通常包含在与主机系统主板相同的物理服务器机柜中，并共享其电源及其PCIe接口。

笔记

对于EC2 mac1.metal和mac2.metal实例。一个Nitro控制器与一个Mac Mini在同一个金属外壳中，两者通过Thunderbolt连接在一起。请参阅Amazon EC2 Mac实例。

Nitro卡的主要组件是AWS设计的运行专用固件的片上系统（SoC）包。AWS已仔细推动了这些卡的硬件和固件的设计和实现过程。硬件由负责AWS内部硅设计的团队Annapurna Labs从头开始设计。这些卡的固件由专门的AWS工程团队开发和维护。

笔记

Annapurna实验室于2015年被亚马逊收购，此前在AWS Nitro系统关键技术开发的初始阶段成功建立了合作伙伴关系。Annapurna不仅负责制造AWS Nitro系统硬件，还负责AWS定制的基于Arm的Graviton处理器、用于ML训练和推理的AWS Trainium和AWS Infrentia硬件加速器芯片、AWS NitroSSD和用于Amazon Redshift的Aqua（高级查询加速器）。

Nitro卡上的关键控制固件可以使用加密签名软件包实时更新。Nitro卡可以独立于Nitro系统的其他组件进行更新，包括彼此以及系统主板上的任何可更新组件，以便部署新功能和安全更新。Nitro卡的更新对客户的工作负载几乎没有影响，也没有放松Nitro系统的任何安全控制。

Nitro卡通过PCIe物理连接到系统主板及其处理器，但在逻辑上与运行客户工作负载的系统主板隔离。Nitro系统可以包含一个或多个Nitro卡；如果有多个，则通过服务器机柜内的内部网络进行连接。该网络提供了独立于系统主板的Nitro卡之间的专用通信信道，以及与基板管理控制器（BMC）的专用连接（如果服务器设计中存在）。

Nitro控制器

主要的Nitro卡称为Nitro控制器。Nitro控制器为整个系统提供硬件信任根。它负责管理服务器系统的所有其他组件，包括加载到系统其他组件上的固件。整个系统的固件存储在直接连接到Nitro控制器的加密固态驱动器（SSD）上。SSD的加密密钥设计为受可信平台模块（TPM）和SoC的安全引导功能的组合保护。本节介绍了Nitro控制器的安全引导设计及其作为服务器和网络之间的可信接口的作用。

笔记

在AWS前哨部署的情况下，Nitro安全密钥也与TPM和SoC的安全引导功能一起使用，以保护直接连接到Nitro控制器的SSD的加密密钥。

Nitro控制器安全引导设计

Nitro控制器中SoC的安全引导过程从其引导ROM开始，然后通过测量和验证存储在连接到Nitro Controller的闪存中的早期固件来扩展信任链。随着系统初始化的进行，使用可信平台模块（TPM）记录初始启动代码测量值，然后将测量值扩展到其他系统固件。嵌入防篡改TPM中的加密密钥用于对已知良好系统测量的完整集合进行数字签名。然后在每次重新启动时，将此数字签名文件与所有后续系统测量值进行比较，以检测任何意外更改。

如果未检测到任何更改，则使用由TPM中锁定的密钥加密的附加解密密钥来解密系统中的附加数据，以允许引导过程继续。如果检测到更改，则不会解密附加数据，系统将立即停止服务，因此不会托管客户工作负载。

前面的步骤详细说明了Nitro控制器在启动时建立系统软件完整性和有效性的过程。为了使安全引导设计真正安全，SoC引导代码的每个阶段不仅必须有效且未修改，而且必须在实现时功能正确。这一点尤其适用于作为设备物理制造一部分的静态ROM代码。为此，AWS在我们的设计中应用了正式的方法来验证早期启动代码的内存安全属性。

Nitro控制器作为EC2服务器和网络之间的接口

Nitro Controller是EC2、Amazon EBS和Amazon虚拟私有云（Amazon VPC）的物理服务器和控制平面之间的专用网关。虽然逻辑上不同，并且由多个子组件微服务组成，但这三个控制平面在下文中通常称为EC2控制平面。

笔记

在AWS中，一种常见的设计模式是将系统分成负责处理客户请求的服务（数据平面）和负责管理和销售客户配置的服务（例如，创建、删除和修改资源）（控制平面）。Amazon EC2是包括数据平面和控制平面的架构的示例。数据平面由运行客户EC2实例的EC2物理服务器组成。控制平面由许多服务组成，这些服务负责与数据平面通信，并执行诸如中继命令以启动或终止实例或接收操作遥测等功能。

Nitro系统控制架构

Nitro控制器向专用EC2控制平面网络提供一组经过严格认证和加密的网络API，用于系统管理。每一个API操作都会被记录，所有调用API的尝试都会使用细粒度访问控制模型进行加密认证和授权。每个控制平面组件仅被授权用于完成其业务目的所需的一组操作。使用正式方法，我们已经证明Nitro控制器的控制消息解析实现的面向网络的API在面对任何配置文件和任何网络输入时都不会出现内存安全错误。

用于I/O的Nitro卡

除Nitro控制器外，一些系统还使用其他专用Nitro卡来执行特定功能。这些从属Nitro卡与Nitro控制器共享相同的SoC和基本固件设计。这些Nitro卡根据其特定功能的需要设计了附加硬件和专用固件应用程序。例如，包括用于VPC的Nitro卡、用于EBS的Nitro卡和用于本地NVMe存储的NitroCard。

这些卡使用集成在SoC中的安全密钥存储的硬件卸载引擎实现网络和存储的数据加密。这些硬件引擎提供本地NVMe存储和远程EBS卷的加密，而不会对其性能产生实际影响。VPC的Nitro Card的最后三个版本（包括所有新发布的实例类型上使用的版本）对所有VPC流量进行透明加密，使其能够传输到运行在同样配备加密兼容Nitro卡的主机上的其他EC2实例，而不会影响性能。

笔记

AWS在所有类型的EC2实例之间提供安全的私有连接。此外，一些实例类型使用底层Nitro系统硬件的卸载功能，使用AES-256-GCM自动透明地加密和匿名化实例之间的传输流量。对网络性能没有影响。为了支持实例之间的这种额外的传输流量加密，实例必须是支持的实例类型，在同一个Region中，并且在同一VPC或对等VPC中。流量不得通过虚拟网络设备或服务，如负载平衡器或传输网关。有关其他信息和支持的实例类型列表，请参阅传输中的加密。

用于EBS、本地实例存储和VPC网络的加密密钥仅以明文形式存在于Nitro卡的受保护易失性存储器中；AWS操作员以及在主机系统主处理器上运行的任何客户代码都无法访问它们。Nitro卡提供通过PCIe连接到主服务器处理器NVMe的硬件编程接口，用于块存储（EBS和实例存储）、用于网络的弹性网络适配器（ENA）、用于带外操作系统控制台日志记录和调试的串行端口等。

笔记

EC2为客户提供了访问实例控制台输出以进行故障排除的权限。Nitro系统还使客户能够连接到串行控制台会话，以便对引导、网络配置和其他问题进行交互式故障排除。在此上下文中，“带外”是指客户通过与实例本身或其网络连接分离的通道获取信息或与其实例交互的能力。

当系统配置为使用Nitro Hypervisor时，Nitro卡提供的每个PCIe功能都使用单根输入/输出虚拟化（SR-IOV）技术细分为虚拟功能。这有助于将硬件接口直接分配给VM。客户数据（客户传送给我们用于处理、存储或托管的内容）直接在Nitro卡提供的实例和这些虚拟化I/O设备之间移动。这将使I/O中涉及的软件和硬件组件集最小化，从而降低成本、提高性能和提高安全性。

Nitro安全芯片

Nitro控制器和其他Nitro卡一起作为Nitro系统中的一个域运行，系统主板与Intel、AMD或Graviton处理器一起运行，客户工作负载运行在该主板上。虽然Nitro控制器及其安全引导过程为Nitro系统提供了硬件信任基础，但使用了一个附加组件来扩展对系统主板的信任和控制。Nitro安全芯片是这两个域之间的链接，它将Nitro控制器的控制扩展到系统主板，使其成为系统的从属组件，从而扩展了Nitro Controller的信任链以覆盖它。以下各节详细介绍Nitro控制器和Nitro安全芯片如何共同工作以实现这一目标。

系统硬件的Nitro安全芯片保护

Nitro安全芯片是集成到服务器系统主板中的设备。在运行时，它拦截并调节对本地非易失性存储设备和低速系统管理总线接口（如串行外围接口（SPI）和I2C）的所有操作，换句话说，对所有固件的操作。

Nitro安全芯片也位于BMC和主系统CPU之间的高速PCI连接上，这使得该接口能够在生产系统上进行逻辑防火墙。Nitro安全芯片由Nitro控制器控制。因此，Nitro控制器通过其对Nitro安全芯片的控制，能够调解和验证系统主板或Nitro卡上固件的更新或其他非易失性设备的编程。

一种常见的行业实践是依靠管理程序来保护这些系统硬件资产，但当不存在管理程序时，例如当EC2以裸机模式使用时，需要一种替代机制来确保用户无法操作系统固件。Nitro安全芯片提供关键的安全功能，确保主系统CPU不能在裸机模式下更新固件。此外，当Nitro系统与Nitro Hypervisor一起运行时，Nitro安全芯片除了为管理程序提供的系统硬件资产提供保护外，还提供深度防御。

系统启动或重置时的Nitro安全芯片

Nitro安全芯片还在系统启动或重置期间提供第二个关键安全功能。它控制服务器系统主板的物理复位引脚，包括其CPU和BMC（如果存在）。这使Nitro控制器能够完成自己的安全引导过程，然后在指示Nitro安全芯片释放主CPU和BMC以使其不被重置之前，验证基本输入/输出系统（BIOS）、BMC和所有其他系统固件的完整性。只有这样，CPU和BMC才能使用刚刚通过Nitro控制器验证的BIOS和固件开始启动过程。

Nitro虚拟机监控程序

Nitro Hypervisor是一个有限的、精心设计的组件，已被有意地最小化，并专门构建，具有执行其指定功能所需的功能，不再需要。Nitro Hypervisor被设计为接收从Nitro控制器发送的虚拟机管理命令（启动、停止等），并通过PCIe将Nitro硬件接口（用于EBS和实例存储的NVMe块存储、用于网络的弹性网络适配器（ENA）等）提供的SR-IOV虚拟功能分配给适当的VM。

笔记

虽然Nitro体系结构的独特之处在于它不需要使用管理程序来提供软件定义的基础架构，但在大多数客户场景中，虚拟化是非常有价值的，因为它允许将非常大的服务器细分为多个实例（VM）同时使用，以及其他优势，如更快的资源调配。虚拟化配置中需要Hypervisor，以提供来宾和系统的隔离、调度和管理。因此，在这些常见场景中，Nitro Hypervisor在保护基于Nitro的EC2服务器方面发挥着关键作用。

在Nitro系统上构建的一些实例类型包括硬件加速器，它们都由AWS和第三方（如图形处理单元或GPU）构建。Nitro Hypervisor还负责将这些硬件设备分配给VM，从硬件错误中恢复，并执行无法通过带外管理接口执行的其他功能。

在Nitro Hypervisor中，根据设计，没有网络堆栈，没有通用文件系统实现，也没有外围设备驱动程序支持。Nitro Hypervisor的设计仅包括其任务所需的服务和功能；它不是一个通用系统，既不包括外壳，也不包括任何类型的交互式访问模式。与常规管理程序相比，Nitro管理程序的体积小且相对简单，这本身就是一个显著的安全优势。

Nitro Hypervisor代码是一个托管的、加密签名的类似固件的组件，存储在连接到Nitro控制器的加密本地存储上，因此链接到Nitro控制器的硬件信任根。当系统配置为使用Nitro虚拟机监控程序时，Nitro控制器以类似于固件的方式将虚拟机监控代码的已知良好副本直接加载到系统主板上。

笔记

此虚拟机监控程序注入过程的机制是使用Nitro控制器提供给主板的只读NVMe设备作为系统引导驱动器。

将数据处理和I/O虚拟化卸载到分立硬件，并减少在主机CPU上运行的管理程序的责任，这是Nitro系统设计的核心。它不仅通过隔离提供了改进的性能和更强的安全性，还支持EC2的裸机实例类型功能，因为管理程序现在是一个可选的分立组件，不再需要它来提供I/O虚拟化、系统管理或监视。

笔记

Nitro系统通过在Nitro卡上而不是在主机的系统主板CPU上运行虚拟化系统的几乎所有功能，实现了有效的“裸机”性能。请参阅AWS Nitro系统的裸金属性能。

Nitro Hypervisor对非必要功能的严格排除消除了其他Hypervisor可能遭受的各种错误，例如远程网络攻击或基于驱动程序的权限升级。即使Nitro Hypervisor中存在允许访问特权代码的错误，但由于缺少标准操作系统功能（如交互式shell、文件系统、通用用户空间实用程序、，或获得可促进较大基础设施内横向移动的资源。

例如，如前所述，Nitro Hypervisor没有网络堆栈，也无法访问EC2网络。相反，Nitro控制器和其他Nitro卡调解对外部网络的所有访问，无论主服务器处理器是运行Nitro Hypervisor还是以裸机模式运行。此外，正如下面详细讨论的，Nitro的被动通信设计意味着任何试图从在管理程序环境中运行的代码到Nitro卡的“扩展”都将被拒绝和警告。

Nitro Hypervisor的更新过程

维护系统安全的一个关键方面是例行更新。Nitro Hypervisor允许全系统实时更新。当Nitro Hypervisor的新版本可用时，将替换完整运行的Hypervisor代码，同时保留客户EC2实例，对这些实例的性能几乎没有影响。这些更新过程的设计使得任何时候都不需要放弃或放松Nitro系统的任何安全协议或防御。此整体实时更新功能旨在为客户的实例提供零停机时间，同时确保不仅可以定期快速应用新功能，还可以快速应用安全更新。

客户实例停机时间与Nitro系统组件更新的分离消除了EC2服务在计划系统更新时仔细权衡客户体验和潜在安全影响之间的需要，从而提高了安全性。

本文中讨论的Nitro系统设计功能是在AWS的全套强大控制的背景下运行的，以维护AWS云中的安全和数据保护。在本节中，我们将对相关AWS安全和合规实践进行高级概述。作为AWS客户，您继承了AWS政策、体系结构和运营流程的所有最佳实践，以满足我们最安全敏感客户的要求。

AWS环境不断接受审计，并获得来自不同地区和垂直行业的认证机构的认证。如果需要，AWS前哨站还为客户提供了在位于自己设施内的基于Nitro System的硬件上本地运行AWS计算、存储、数据库和其他服务的能力。

基础设施安全

AWS的安全始于我们的核心基础设施，即运行AWS云服务的硬件、软件、网络和设施。我们为云定制，旨在满足世界上最严格的安全要求，我们的基础设施全天候监控，以帮助确保客户数据的机密性、完整性和可用性。使用AWS，您可以建立在最安全的全球基础设施上，知道您始终拥有客户数据，包括加密、移动和管理保留的能力。

物理访问

专业安全人员使用视频监控、双因素和生物特征认证、入侵检测系统和其他电子手段，对AWS数据中心的物理访问进行严格控制，无论是在周界还是在建筑物入口。授权员工必须至少通过两次双重身份验证才能访问数据中心楼层。所有访客都必须出示身份证明，并由授权人员签字并持续陪同。AWS仅向有合法业务需要的员工和承包商提供数据中心访问和信息。

当员工不再需要这些特权时，即使他们继续是亚马逊或亚马逊Web服务的员工，其访问权限也会立即被撤销。AWS员工对数据中心的所有物理访问都会定期记录和审核。

媒体净化

AWS将用于存储客户数据的媒体存储设备分类为“关键”。AWS对如何安装、维修和最终销毁不再有用的设备制定了严格的标准。当存储设备达到其使用寿命时，AWS使用NIST 800-88中详述的技术停用介质。存储客户数据的介质在安全停用之前不会从AWS控制中删除。

数据保护

通过AWS全球网络（连接我们的数据中心和地区）传输的所有数据在我们的安全设施之间传输之前，都会在物理层自动加密。还存在其他加密层；例如，所有区域间VPC对等流量以及客户或服务到服务TLS连接。我们提供的工具允许您在传输和休息时轻松加密客户数据，以确保只有授权用户才能使用AWS KMS管理的密钥访问，或使用FIPS 140-2 Level 3验证HSM使用AWS CloudHSM管理加密密钥。

我们还为您提供所需的控制和可见性，以帮助您遵守区域和本地数据隐私法律法规。我们全球基础设施的设计允许您选择客户数据所在的地区，帮助您满足数据驻留要求。

Nitro系统是多年来为AWS云基础设施重新构想虚拟化技术的产物。在这一过程中，虚拟化技术的每个组件都得到了重新实施和替换。虽然客户在这个过程中看到了早些时候发布的EC2实例的成本、性能和安全性的提高，但基于最终的完整Nitro系统（其中每个组件都已更换）的实例与以前的实例类型有着显著的不同。Nitro系统为Amazon EC2的客户提供了增强的安全性、保密性和性能，并为快速交付新的创新技术提供了基础。

Nitro系统的引入包括将通用数据中心CPU上Dom0中运行的软件组件逐步分解为独立的专用服务处理器单元。最初是一个紧密耦合的单片虚拟化系统，一步步转变为专门构建的微服务体系结构。从2017年引入的C5实例类型开始，Nitro系统完全消除了对EC2实例上Dom0的需求。相反，基于KVM的定制开发的最小化管理程序提供了一个轻量级的VMM，同时将以前由Dom0中的设备模型执行的其他功能卸载到一组分立的Nitro卡中。

Nitro System virtualization architecture

为了更好地了解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数据建立了额外的加密层。

根据设计，Nitro系统没有操作员访问权限。没有任何系统或人员登录EC2 Nitro主机、访问EC2实例的内存或访问存储在本地加密实例存储或远程加密EBS卷上的任何客户数据的机制。如果任何AWS操作员（包括具有最高权限的操作员）需要在EC2服务器上执行维护工作，他们只能使用一组经过验证、授权、记录和审核的管理API。这些API都没有为操作员提供在EC2服务器上访问客户数据的能力。由于这些都是在Nitro系统中设计和测试的技术限制，AWS操作员无法绕过这些控制和保护。

与大多数工程决策一样，选择在没有操作员访问机制的情况下设计Nitro系统需要权衡。在极少数情况下，可能会出现微妙的问题，因为我们的生产硬件上没有通用的访问功能，AWS操作员无法就地调试。在这种罕见的情况下，我们必须根据客户的要求与他们合作，在专用的非生产Nitro调试硬件上重现这些微妙的问题。这可能比我们的运营商能够就地调试更不方便，但我们坚信这对我们的客户来说是更好的选择。因此，我们必须在产品发布之前坚持系统质量和测试的最高标准。

AWS Nitro系统提供了一套独特的功能，使其能够在多租户、超大规模的云环境中支持最敏感的工作负载。这些功能基于AWS对定制硅和相关固件的投资，以创建专门针对该定制硅的虚拟化堆栈。自2018年初以来，所有新的Amazon EC2实例类型都基于AWS Nitro系统，为客户提供了本文中讨论的所有安全性和其他好处。鉴于这些深厚的技术投资和AWS在工作负载隔离方面的出色记录，客户可以依靠AWS计算环境为其最敏感的工作负载提供卓越的安全性。

AWS Nitro系统遵循“无源通信”设计原则。这意味着，在生产操作期间，系统的组件从不启动出站通信，包括到任何控制平面、管理或云服务的通信。相反，有一个单一的强化的可信服务在网络上侦听，它们侦听网络或系统总线上的命令，根据这些命令采取行动，然后通过定义良好的API返回结果，这些API具有范围向下的访问控制。这些通信路径的两侧还执行参数验证，以确保仅发送和接收有效参数。

此模式从管理程序本身开始。它通过PCIe在专用信道上等待来自Nitro控制器的命令。它从不启动与Nitro系统其余部分的出站通信。它无法启动任何出站网络连接，因为如前所述，它没有网络堆栈。如果在任何时候通过一系列不太可能的动作，Nitro管理程序应尝试启动与其他Nitro系统组件的通信，则这种情况将是固件缺陷或可能的系统损坏的明显信号，并且EC2服务被设计为相应地做出反应，以防操作员响应受到影响和发出警报。

笔记

在裸机模式下，服务器处理器上没有运行管理程序来等待Nitro控制器发出的启动、停止或重置主机服务器的指令。在这种情况下，Nitro控制器通过其专用BMC连接和Nitro安全芯片控制主板。

被动通信模型在硝基系统的下一层重复。Nitro控制器在安全网络信道上侦听，等待EC2控制平面调用的特定API形式的认证和授权命令。Nitro控制器从不启动EC2控制平面网络上的任何出站通信。甚至逻辑上的“推送”功能（如发布主机上运行的EC2实例的CloudWatch度量，或将Nitro API日志发送到EC2控制平面）也被实现为“拉”过程。控制平面定期轮询Nitro控制器，以使用定义良好的API检索度量。任何尝试从Nitro控制器进行出站通信的行为都将是固件错误或可能的系统损坏的明确信号，EC2服务将据此做出反应，以防止对操作员响应的影响和警报。

被动通信模式的净效应是高度隔离和安全。由于正常操作仅涉及监听定义明确的参数验证消息，并使用定义明确的、参数验证的响应对其进行响应，因此该系统旨在明确识别和警告潜在的异常活动。该系统的设计使得，在系统主板出现固件错误的情况下，很可能会检测到、阻止和警告试图从系统主板向外逃到Nitro卡的潜在对手。此外，即使在极不可能发生的情况下，前一种情况下的潜在对手能够逃离系统主板并以某种方式访问硝基卡，硝基系统的设计再次使得该对手逃离硝基卡的任何尝试都很有可能因同样的原因被检测、阻止和警报。这些多层防御不仅保护EC2服务本身，还保护在EC2系统内运行工作负载的所有客户。

自成立以来，EC2一直采用保守的方法为客户设计和操作安全的多租户系统。我们的设计方法支持简单可靠的抽象，它在安全域之间提供了强大的隔离，并限制了客户之间关键系统资源的共享。AWS设计我们的系统，不仅可以针对已知的安全威胁提供纵深防御，还可以避免不具备已知实用开发技术的潜在安全问题的影响。除了我们在生产中采用的经过彻底测试和完善的安全机制外，AWS还积极参与最前沿的安全研究，以确保我们不仅保持最新状态，而且代表客户积极寻找安全问题。

在过去几年中发表的微结构侧通道领域的研究和披露已经将围绕这一主题的担忧推到了最前沿。旁道是一种机制，通过对从计算机系统收集的间接数据进行分析，有可能泄露计算机系统中的秘密信息。这种间接数据的一个示例可以是系统对输入进行操作所需的时间量。在某些情况下，尽管系统从未直接披露秘密数据，但外部方可能能够通过仔细分析处理精心选择的输入所花费的时间差异来确定该秘密的价值

笔记

这种情况的一个简单示例是一个程序，它接收字符串形式的密码作为输入，并验证该字符串是否与机密值匹配。该程序一次一个字符地分析所提供的字符串，将每个字符与机密的对应字符进行比较，并在遇到不匹配时立即返回错误。尽管程序从未向请求者提供秘密的值，但对于以一个或多个与秘密相同的字符开头的输入，程序会以不同的响应时间的形式“泄漏”有关秘密的信息。通过一个系统的试错过程，观察者可以测量响应某些输入所花费的时间，以便一次确定一个字符的秘密值。

仔细部署应对措施，如AWS的开源SSL/tls实现s2n tls所采用的应对措施，可用于防止这些形式的侧信道数据泄露。

仔细部署应对措施，如AWS的开源SSL/tls实现s2n tls所采用的应对措施，可用于防止这些形式的侧信道数据泄露。

笔记

s2n-tls结合并证明了使用形式化方法的时间平衡对策，以确保过程计时受机密的影响可以忽略不计，因此攻击者可观察到的计时行为不会依赖于机密。有关s2n tls中的这些对策以及这些对策的正式证明的更多信息，请参阅SideTrail:验证密码系统的时间平衡。

微体系结构侧通道特别涉及在某些情况下对系统处理器的低级行为的操纵，以允许在该系统上运行的一个进程通过系统资源（如缓存、内部缓冲区和其他不允许直接访问的有状态数据源）间接地确定秘密数据的值。关键的是，这些副通道围绕着两个系统之间共享对低级硬件资源的访问。

AWS对EC2租户隔离采用了一种保守的方法，这将在后面的章节中讨论，其设计目的是使客户实例永远无法共享系统资源，例如L1/L2缓存或在同一CPU复合体上运行的线程。这种基本的设计选择排除了通过基于租户之间共享访问这些资源的微架构侧通道从客户实例泄漏数据的可能性。

更广泛的EC2服务中的侧通道保护

所有EC2实例都包含对侧信道的强大保护。这包括基于Nitro系统或Xen管理程序的两个实例。虽然本节讨论了Nitro系统的这些保护，但这些保护也存在于基于Xen的EC2实例中。

虚拟化EC2实例类型分为两类：

• 固定性能实例，其中CPU和内存资源在主机上的虚拟化实例的生命周期内预先分配并专用于该实例
• 突发性能实例，其中CPU和内存资源可以被过度使用，以支持在服务器上运行的大量虚拟化实例，从而为客户提供了CPU利用率低到中等的应用程序的相对实例成本。请参阅Burstable性能实例。

无论哪种情况，Nitro Hypervisor的设计和实现都包括对潜在侧通道的多重保护。

对于固定性能的实例，与其他虚拟机管理程序相比，专用资源既提供了对侧通道的自然保护，又提供了更高的性能。例如，一个c5.4xlarge实例分配了16个虚拟CPU（八个内核，每个内核提供两个线程）以及32 GiB的内存。当实例启动时，EC2控制平面指示Nitro控制器分配必要的CPU、内存和I/O资源以支持该实例。

Nitro管理程序由Nitro控制器指导，为实例分配全部物理内核和内存。这些硬件资源被“固定”到该特定实例。CPU内核不用于运行其他客户工作负载，也不以任何方式在实例之间共享任何实例内存页，这与许多管理程序不同，这些管理程序可以合并重复的数据和/或指令页以节省物理内存。

即使在资源有限的非常小的Nitro EC2实例上，CPU内核也不会通过同时多线程（SMT）在两个客户实例之间同时共享。客户实例提供了两个vCPU的倍数，对于采用SMT的处理器，代表单核的两个线程，对于使用专用全核线程的处理器配置（例如AWS Graviton处理器），代表单vCPU。不共享内核意味着不共享1级或2级缓存或其他特定于内核的资源，如推测执行或节能状态。

某些实例大小可以非同时共享某些最后一级缓存行。虽然可以将最后一级缓存线的启动和探测作为一个超低带宽信号在两个协作进程之间使用，但这与实际的侧通道不同。由于其功能，在最后一级缓存行中只引用相对较少访问的数据。侧信道通常需要非常大且统计上相关的样本数量，以克服系统中存在的噪声。

与EC2一样，当内存页不在实例之间共享时，还没有演示过实际的攻击。迄今为止，所有实用的微体系结构侧通道攻击都使用了通过SMT或共享L1/L2缓存的共享内核，或其他低级内核属性（如浮点单元）。在EC2中，侧信道攻击缓解措施非常强大，因为这些资源从未在EC2 Nitro环境中共享。

笔记

EC2准确地暴露了硬件的底层CPU拓扑，包括最后一级（通常为L3）缓存和非统一内存访问（NUMA）信息，直接传递到实例。因此，客户可以通过检查来确定分配了多大大小的实例，即“填充”共享L3缓存的一个或多个CPU段所需的CPU内核数量；从而确定给定实例是否与另一实例共享任何L3高速缓存。三级缓存共享拓扑在CPU设计之间有所不同，并且可以在核心、CPU复合体或核心复合体裸片之间共享，具体取决于处理器架构。例如，在典型的基于Intel的双插槽EC2系统中，一个大小为最大大小一半的实例将填充CPU内核，并且不会与另一个实例共享L3缓存。

如前所述，突发性能EC2实例（例如，T3、T3a和T4g）可以利用过度使用的CPU和内存资源。运行突发性能实例所需的CPU资源根据基于信用的分配进行调度。在这种低成本但相对高性能的实例系列中，即使是最小的实例类型，在使用SMT的处理器上，仍然为客户提供至少两个vCPU（一个内核，两个线程）。

然而，两个可突发性能EC2实例可以在同一内核上顺序（而不是同时）运行。物理内存页也可以作为虚拟内存页进行重用、重新映射和交换。然而，即使是可突发的实例也不会同时共享同一个内核，虚拟内存页也不会在实例之间共享。

Nitro Hypervisor在实例之间的每个上下文切换处使用了许多安全策略，以确保在同一内核上运行另一个实例之前，删除前一个实例的所有状态。这种做法对可能的侧信道攻击提供了强有力的缓解措施。

对于突发性能EC2实例，Nitro系统可以采用内存管理技术，例如将物理内存重新使用、重新映射或交换为虚拟内存页，但该系统的设计使得虚拟内存页不会在实例之间共享，以保持强隔离边界。

最后，可突发性能实例——无论是目标性能实例还是通过侧信道技术检测数据的实例——都可以在不同于以前使用的内核上重新调度，从而进一步限制任何类型基于时间的成功安全问题的可能性。

Nitro系统的附加副通道优势

除了EC2为Xen和Nitro提供的保护外，在涉及侧信道问题时，Nitro系统和NitroHypervisor的设计中还有一些不明显但非常重要的好处。例如，虽然一些管理程序需要进行大量更改以实现地址空间隔离，作为L1终端故障瞬时执行侧通道攻击缓解措施的一部分（例如，请参阅针对L1终端故障的Hyper-V HyperClear缓解措施），但Nitro系统的设计和实现提供了自然的免疫力，因为Nitro Hypervisor的虚拟地址空间与分配给客户实例的内存隔离。

我们还应用了从设计Nitro系统中学到的知识，以减轻社区版Xen管理程序中微架构侧通道攻击的新威胁。请参阅在没有直接映射的情况下运行Xen。

如前所述，Nitro系统大大减少了运行在主服务器处理器上的EC2系统代码量，这大大缩小了管理程序的攻击面，并将客户I/O数据处理与系统的其他部分隔离开来。提供EC2的软件定义I/O功能所需的AWS代码不在运行客户工作负载的处理器上运行。

专用硬件的这种划分和使用意味着I/O子系统中的客户数据处理在硬件功能级别上是隔离的，并且不驻留在主机内存、处理器缓存或其他内部缓冲区中，这与通用虚拟化软件不同，通用虚拟化软件将这些数据混合在一起，作为在共享主机CPU上运行的副作用。

所有这些保护措施的基础是AWS处于安全研究的前沿，经常领导研究和发现影响行业的问题，以及缓解和协调问题。

Nitro胶囊

Nitro Enclaves是Nitro系统的一个功能，它允许客户将其工作负载划分为独立的组件，这些组件不需要彼此完全信任，同时也是运行高度信任的代码和处理客户EC2实例管理员无法访问的数据的一种方式。本文没有介绍它的特点和优点，但以下内容值得注意。

Nitro Enclave继承了与运行在同一服务器处理器上的每个其他EC2实例相同的隔离和侧通道缓解措施。父实例必须分配固定数量的vCPU（最小数量等于一个完整内核）以及固定数量的内存页。该固定的CPU和内存资源集从父实例中减去（使用Linux和Windows内核中支持的“硬件资源热插拔”功能），然后由Nitro Hypervisor用于创建另一个完全受保护的独立VM环境，在其中运行Nitro Enclave映像。

当使用Nitro Enclaves时，上面讨论的所有保护都会自动到位，因为没有与父实例共享内核或内存。

关闭侧频道的想法

总之，Nitro和EC2平台中谨慎的设计决策提供了一系列非常有力的缓解措施，以防止实际的侧通道攻击，包括删除这些攻击所需的CPU和内存资源实例之间的共享访问。此外，客户可以选择不将其实例与属于其他客户的实例配置在同一主机上。此外，如果任何未来的研究发现新的挑战，AWS参与针对Linux、KVM、Xen和其他关键技术的协调漏洞响应小组，以及Nitro系统的实时更新技术设计，将使AWS能够快速做出反应，保护客户免受新的威胁，而不会干扰客户的工作负载。AWS是在公开披露之前从事Spectre和Meltdown项目的一小部分公司的成员，并在公开披露前减轻了其基础设施中的所有风险。

笔记

通过使用EC2的“专用实例”或“专用主机”功能，客户可以选择不与其他客户共享计算硬件。这些特性表示实例放置策略，该策略导致单个客户在任何给定时间都是唯一的客户，并且实例调度在特定的EC2物理主机上。请参阅Amazon EC2专用主机。

我们继续与Intel、AMD和ARM等关键合作伙伴合作，进行硬件安全研究和协调漏洞响应，并继续通过计算机隔离的其他创新提高标准。一个这样的例子是开源的Firecracker VMM，它使无服务器容器和基于功能的服务（如AWS Fargate和AWS Lambda）能够从虚拟化的安全性、隔离性和一致性中获益，而不会影响客户对这些工作负载所需的速度、灵活性和性能。

笔记

Firecracker是一种虚拟化技术，专门用于创建和管理安全的多租户容器和基于功能的服务。Firecracker是一种虚拟机监视器，用于管理轻量级microVM中的工作负载。它实现了一个最小的设备模型，排除了所有非必要的功能，并减少了microVM的攻击面积。除了采用的安全性和隔离优化外，Firecracker还可以在短短125ms内快速启动用户空间或应用程序代码，并为每个microVM提供低至5 MiB的内存开销。

旁道问题是一个不断发展的研究领域，并由此产生了创新和缓解措施。我们相信，依靠AWS凭借其深厚的专业知识和对这一主题的持续关注，是客户在防范未来风险方面下注的好地方。

笔记

请参阅AWS副总裁兼杰出工程师Eric Brandwine关于侧渠道问题的演示。在演讲中，他谈到了从Xen到Nitro的过渡（42.40）及其带来的优势，但也重要地指出，这一主题已经成为一个类似密码学的主题，其中最合理的方法是依赖深度专家并重用他们的工作（49.29）。

虚拟化在高级别上使单个物理计算机系统能够同时运行多个操作系统。虚拟化系统（“主机”）实现了转换、仿真和限制功能，使其能够为一个或多个虚拟化操作系统（“客户机”）提供其自身独立硬件（“虚拟机”或“VM”）的虚拟表示。换句话说，虚拟化主机。虚拟化的主要好处之一是能够通过在多个虚拟机之间分配其资源来高效利用单个功能强大的服务器，每个虚拟机都分配了最适合其分配任务的资源量。

笔记

本节中对虚拟化的讨论提供了对该主题的一般性的高级介绍，并没有深入到Paravirtualization之类的主题，在Paravirtualization中，必须修改来宾软件才能在虚拟化环境中运行。有关虚拟化技术的更详细入门知识，请参阅AWS副总裁兼杰出工程师Anthony Liguri的虚拟化技术演示。

负责管理虚拟化系统中来宾虚拟机（VM）的生命周期和操作的核心组件称为虚拟机监视器（VMM）或管理程序。对于它执行的大多数统计操作，客户机在系统的物理CPU上本地运行指令，而不需要VMM的任何参与。例如，当客户试图计算两个值的和或积时，它可以直接与系统的CPU硬件通信，以发出必要的机器代码指令。

然而，有些敏感或特权指令，例如从CPU控制寄存器读取或写入，不应允许访客直接在CPU硬件上运行，以保持系统整体的稳定性和隔离。当客户机试图向CPU发出这些指令中的一条而不是运行时，该指令将被重定向到VMM，VMM将模拟该指令的允许结果，然后将控制权返回给客户机，就像该指令是在CPU上本地执行的一样。

VMM本身是一个相对简单的软件。然而，虚拟化主机需要的不仅仅是VMM的核心功能，以便为来宾提供对网络接口、存储驱动器和输入外围设备等设备的访问。为了提供这些功能，主机依赖于称为设备模型的附加软件组件。设备模型与系统的共享物理I/O硬件通信，并模拟暴露给客户VM的一个或多个唯一虚拟设备接口的状态和行为。

Hypervisor通常使用通用操作系统来与各种系统硬件接口，运行设备模型，并运行虚拟化系统的其他管理软件。此操作系统通常被实现为一个特殊的特权虚拟机，例如，Xen项目调用系统的dom0，Hyper-V调用系统的根/父分区。在早期的EC2实例中，这采用了一种特殊的AmazonLinuxVM的形式，在Xen术语中称为domain0或dom0。

摘要

Amazon Elastic Compute Cloud（Amazon EC2）是一种web服务，在云中提供安全、可调整大小的计算能力。它旨在使开发人员更容易进行web规模的云计算。AWS Nitro系统是所有现代EC2实例的基础平台。本白皮书详细描述了Nitro系统的安全设计，以帮助您评估敏感工作负载的EC2。

介绍

每天，世界各地的客户都将他们最敏感的应用程序委托给Amazon Web Services（AWS）。在AWS，保持客户工作负载的安全和机密性，同时帮助他们满足安全、隐私和数据保护要求，是我们的首要任务。我们投资了严格的运营实践和安全技术，以满足甚至超过我们最苛刻的客户的数据安全需求。

AWS Nitro系统的开发是一个多年的旅程，旨在重塑Amazon EC2的基础虚拟化基础设施。自2006年推出亚马逊EC2测试版以来，我们不断完善、优化和创新服务的各个方面，以满足客户的需求。借助AWS Nitro系统，我们致力于戏剧性地重新构想虚拟化架构，以提供客户所需的安全性、隔离性、性能、成本和创新速度。

从第一天起，安全性就一直是该流程的基本原则，我们继续投资于设计的实施，作为我们持续改进方法的一部分，以不断提高客户的安全性和数据保护标准。AWS Nitro系统是专门构建的服务器设计、数据处理器、系统管理组件和专用固件的组合，为自2018年初以来推出的所有Amazon EC2实例提供了基础平台。AWS Nitro系统的有限和离散设计组件共同为EC2客户提供更快的创新、增强的安全性和改进的性能。

Nitro系统的三个关键组件实现了这些目标：

• 专门构建的Nitro卡-AWS设计的硬件设备，提供独立于主系统板及其CPU和内存的整体系统控制和输入/输出（I/O）虚拟化。
• Nitro安全芯片-基于硬件信任根、提供裸机实例的能力以及纵深防御，为整个系统提供安全引导过程，防止服务器未经授权修改系统固件。
• Nitro虚拟机监控程序-一个故意最小化的、类似固件的虚拟机管理程序，旨在提供强大的资源隔离，性能几乎与裸机服务器无法区分。

笔记

这些组件是互补的，但不需要一起使用。

本文简要介绍了Nitro系统引入的虚拟化和基本架构更改。它讨论了Nitro系统的三个关键组件中的每一个，并通过将新的Amazon Elastic Block Store（Amazon EBS）卷添加到正在运行的EC2实例中来演示这些组件如何协同工作。白皮书讨论了Nitro系统在设计上如何消除管理员访问EC2服务器的可能性、Nitro的总体被动通信设计以及Nitro更改管理过程。最后，本文调查了EC2系统设计的重要方面，这些方面为计算环境中可能出现的潜在侧信道问题提供了缓解措施。