【云安全】AWS Nitro系统的安全设计 --被动通信设计

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系统内运行工作负载的所有客户。