AWS 上的操作员访问

许多AWS核心系统和服务都是在零操作员访问的情况下设计的，包括 AWS密钥管理服务（AWS KMS）、亚马逊EC2（通过AWS Nitro系统）、AWS Lambda 、亚马逊弹性Kubernetes服务（亚马逊EK S）和AWS Wickr。 这些服务没有任何技术手段可供 AWS 操作员访问客户数据。相反，系统和服务是通过自动化和安全的 API 进行管理的，这些 API 可以保护客户数据免受无意甚至强制泄露。

AWS 一直使用最低权限模型来最大限度地减少有权访问处理客户数据的系统的人数。这意味着我们确保每位亚马逊人只能为了完成分配给他们的任务或工作职责对系统进行最低限度的访问，仅限于需要该权限的时间。对存储或处理客户数据或元数据的系统的任何访问都将记录在案、监控异常情况并进行审计。AWS 会防范任何会禁用或绕过这些控制的操作。

我们还将最低权限原则应用于 AWS 系统和服务的状况。AWS 在这一领域超过了行业标准。 AWS 身份和访问管理 (IAM) 使客户能够使用 IAM 角色阐明细粒度的权限，这使客户能够仔细控制谁有权访问哪些内容。我们还添加了一个名为前向访问会话（FAS）的额外独特安全层，该层可确保敏感权限以加密方式取决于客户授权。亚马逊EC2和亚马逊简单存储服务（Amazon S3）等AWS服务也允许客户加密其数据，因此即使是AWS也无法在没有客户直接授权的情况下使用客户的加密密钥。 这是由 FAS 强制执行的，这证明客户已授权此操作。此外，这些被称为 “代表” 服务操作的操作会记录在案，并在 AWS CloudTrail 中向客户公开。 根据设计，没有超级用户密钥允许 AWS 服务在没有隐式授权的情况下访问其他服务中的客户资源。

为了防止操作员不受监控地访问包含客户数据的系统，AWS 设计了我们的系统，以确保集中记录并监控所有管理操作。所有操作员操作都可以通过细致的取证细节追溯到执行操作的真实人类；没有提供匿名性的共享团队账户。系统会实时监控访问是否存在异常活动，包括潜在的错误或可疑活动，并向 AWS 操作员的经理和领导团队以及独立的 AWS 安全组织提供所有此类活动的定期摘要。这种监控是多级的，包括主机内日志记录代理，可将本地事件快速推送到由 AWS 安全团队运营的集中式日志聚合系统，以及在主机代理因任何原因停止工作时发出实时警报。网络级别监控、堡垒机服务监控和其他控制措施对此进行了补充。

AWS 人员通过安全界面执行所有操作，确保操作员拥有最新的安全工作站、经 FIPS 验证的硬件安全令牌并经过正确身份验证。这些界面为 AWS 操作员提供短暂的临时凭证，还使用不可替代或绕过的机制监控所有活动。这些安全的操作员界面仅允许不泄露客户数据的有限操作，并对敏感操作强制进行多人批准。

如果需要访问可能存储或处理客户数据的内部资源，例如进行故障排除或修复与服务相关的问题，我们会增加额外的控制层来限制、评估并监控操作员的访问。

协助客户处理支持请求的 AWS Support 人员无权访问客户数据。用于支持目的的所有 AWS IAM 权限均有完整记录，可通过每个 AWS 客户禁用的专用角色进行访问。对这些专用角色的任何使用也会记录在 AWS CloudTrail 中。

AWS 运营安全的数据中心以降低网络窃取、盗窃或其他物理攻击的风险。我们使用最低权限原则来审查访问请求。这些请求必须指定个人需要访问数据中心的哪一层，并且是有时限的。 未使用 NIST 800-88 中描述的技术进行物理销毁或消毒，任何电子存储介质都不得离开 AWS 数据中心。AWS 服务和系统支持对网络、内存和存储进行不间断加密。在许多情况下，有两层或更多层的不间断加密，确保只能由负责为客户处理数据的系统访问数据。

AWS 采用组织和技术制衡手段来确保任何安全事件都不能逃过检测，任何个人或团体都无法颠覆重要的安全控制措施。AWS 访问控制系统和访问监控系统有意独立，由不同的团队运营。

我们在设计 AWS 时采用了深度防御安全措施，包括变更控制、不可变日志功能、责任分离、多方批准、应急授权机制和免干预操作工具。这些安全措施超出了标准安全惯例，因此 AWS 操作员采取的措施是安全、透明的，而且进行了记录和审查。

我们已经实现了用于分配资源访问权限的权限组，用于管理权限组成员资格的权限工具，以及允许授权操作员在不直接访问服务资源的情况下进行系统维护和故障排除的安全工具。当员工变更角色或退出公司时，我们还会自动更新成员资格。