Amazon Elastic Kubernetes Service获得对其零操作员访问设计的独立肯定

今天，我们很高兴地宣布Amazon Elastic Kubernetes Service (Amazon EKS) 的零操作员访问态势。

由于安全是我们在亚马逊云科技 (AWS) 的首要任务，我们设计了一种运维架构，以满足受监管和最严格客户对托管Kubernetes服务所期望的数据隐私态势，让他们能够持续有信心在AWS服务上运行最关键和数据敏感的工作负载。我们的服务旨在防止AWS人员通过技术途径在管理Amazon EKS的过程中读取、复制、提取、修改或以其他方式访问客户内容。

在AWS，赢得信任不仅仅是一个目标，它是指导我们每个决策的核心领导原则之一。客户选择AWS是因为他们信任我们能够提供最安全的全球云基础设施，让他们在此之上构建、迁移和运行工作负载，并存储他们的数据。为了建立在这种信任之上，我们推出了AWS信任中心，以便更容易地获取关于我们如何在AWS云中保护客户资产的信息。随着此次发布，我们正在描述我们如何处理操作员访问，以展示业界领先的数据隐私态势，以及我们如何在AWS云中履行我们在AWS责任共担模型中的职责。

许多AWS核心系统和服务都是按照零操作员访问设计的，这意味着它们基于一种架构和模型运行，该架构和模型至少能防止任何形式的在服务管理过程中对客户内容的访问。相反，他们的系统和服务通过自动化和保护客户内容免于无意甚至被迫泄露的安全API进行管理。其中一些服务包括AWS Key Management Service (AWS KMS)、Amazon Elastic Compute Cloud (Amazon EC2)（通过AWS Nitro系统）、AWS Lambda、Amazon EKS和AWS Wickr。

当AWS做出其数字主权承诺时，我们承诺向客户提供更高的透明度和保证，说明AWS服务是如何设计和运营的，尤其是在处理客户内容方面。作为增加透明度的一部分，我们邀请了总部位于英国的领先网络安全咨询公司NCC Group对Amazon EKS以及我们向客户提供的安全保证进行独立的架构审查。NCC Group现已发布其报告并肯定了我们的声明。报告指出：

“NCC Group没有发现会直接损害AWS所主张安全声明的架构漏洞。”

具体来说，报告验证了以下关于Amazon EKS安全态势的声明：

AWS人员无法通过技术手段获得对托管Kubernetes控制平面实例的交互式访问。
AWS人员无法通过技术手段读取、复制、提取、修改或以其他方式访问托管Kubernetes控制平面实例中的客户内容。
用于管理Kubernetes控制平面实例的AWS人员内部管理API无法访问Kubernetes数据平面中的客户内容。
用于管理Kubernetes控制平面的内部管理API的变更始终需要多方审查和批准。
AWS人员无法通过技术手段访问etcd数据库备份存储中的客户内容。任何AWS人员都无法访问用于保护etcd数据库中数据的任何明文加密密钥。
AWS人员只能在不访问托管Kubernetes控制平面或Kubernetes数据平面中客户内容的情况下，使用内部管理API与Kubernetes集群API端点进行交互。AWS人员在Kubernetes集群API端点上执行的所有操作都可通过客户启用的审计日志对客户可见。
对内部管理API的访问始终需要身份验证和授权。内部管理API执行的所有操作操作都会被记录和审计。
托管Kubernetes控制平面实例只能运行由可信管道部署的经过测试的软件。在此管道之外，任何AWS人员都不能将软件部署到托管Kubernetes控制平面实例。

详细的NCC Group报告审查了每项声明，包括NCC Group用于评估这些声明的范围、方法和步骤。

Amazon EKS如何为零操作员访问而设计

AWS始终使用最小权限模型来最小化能够访问处理客户内容的系统的人员数量。这意味着我们设计产品和服务，只为每位亚马逊员工提供访问完成其指定任务或职责所需的最少系统集合，并将该访问限制在需要的时候。任何对存储或处理客户数据的系统的访问都会被记录、监控异常并接受审计。AWS设计其所有系统，以防止AWS人员为未经授权的目的访问客户内容。我们在我们的AWS客户协议和AWS服务条款中承诺这一点。AWS的运营从不要求我们在客户不知情和未授权的情况下访问、复制或移动客户的内容。

我们的运营架构包括专门使用基于AWS Nitro系统的实例，为托管的Kubernetes控制平面提供机密计算基线。

我们使用一组受限的管理API来实现对访问的精确控制，以便我们的操作员能够执行精确的、允许列表中的操作进行故障排除和诊断，而无需直接或交互式访问Kubernetes控制平面实例。这些API经过专门设计，没有技术手段可以访问Kubernetes控制平面或客户Kubernetes数据平面中的客户内容。

遵循我们的标准变更管理机制，我们对这些受限管理API的修改强制执行内置的多方审查和批准流程，以及随附的策略，这些策略进一步强化了我们运营该服务的防护措施。该模型在Amazon EKS集群中一致实施，无论客户为Kubernetes数据平面选择何种启动模式。

此外，与这些受限管理API的每次交互都会生成日志，并遵循最小权限原则，强制执行身份验证和授权。通过启用集群的审计日志，客户可以保持对AWS人员在集群API端点上执行的所有操作的可见性。

默认情况下，我们在将Kubernetes API数据存储到etcd数据库之前对其进行信封加密，并进一步保护etcd数据库的备份存储，以增加多层保护，防止访问集群快照中的客户内容。此外，我们的系统经过设计，使得任何AWS人员都无法访问用于保护etcd数据库及其备份中数据的任何明文加密密钥。

这些操作员访问控制统一适用于Amazon EKS控制平面，无论您如何运行工作节点——无论是自行管理、通过Amazon EKS自动模式，还是使用AWS Fargate。如AWS责任共担模型所述，客户仍需负责保护Kubernetes工作节点的配置，但Amazon EKS自动模式和Fargate启动模式除外。有关Amazon EKS中这些AWS托管数据平面启动模式安全性的更多信息，请参阅“了解更多”部分中的相关链接。

结论

Amazon EKS的设计和构建旨在确保没有AWS员工能够读取、复制、修改或以其他方式访问Amazon EKS中的客户内容。通过使用基于AWS Nitro系统的机密计算、严格限制的管理API、多方变更批准流程和端到端加密，AWS避免了操作员访问的技术途径。NCC Group的独立验证未发现会削弱这些保证的架构漏洞。简而言之，Amazon EKS提供了一种零操作员访问模型，可以满足最严格的监管和主权要求，让组织有信心在AWS上运行其最敏感、任务关键的工作负载。

了解更多

如果您对此文章有反馈意见，请在下面的评论部分提交评论。如果您对此文章有疑问，请联系AWS支持。