本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
SEC01-BP02 安全账户 root 用户和属性
root 用户是中权限最高的用户 AWS 账户,拥有对账户内所有资源的完全管理访问权限,在某些情况下不受安全策略的限制。停用对根用户的编程访问,为根用户建立适当的控制机制,并避免日常使用根用户,这样有助于降低无意中暴露根凭证以及随后破坏云环境的风险。
期望结果:保护根用户有助于减少因滥用根用户凭证而导致意外或故意损坏的可能性。建立检测性控制机制也可以在有人使用根用户执行操作时向适当人员发出警报。
常见反模式:
-
使用根用户执行各种任务,而非仅在必要时使用根用户凭证。
-
忽略定期测试应急计划,不验证关键基础设施、流程和人员在紧急情况下的运作情况。
-
只考虑典型的账户登录流程,而没有考虑或测试替代的账户恢复方法。
-
不是处理DNS,电子邮件服务器和电话提供商是关键安全边界的一部分,因为它们用于账户恢复流程。
建立此最佳实践的好处:保护对根用户的访问可以建立信心,让账户中的操作受到控制和审核。
在未建立这种最佳实践的情况下暴露的风险等级:高
实施指导
AWS 提供了许多工具来帮助保护您的帐户。但由于其中一些措施默认情况下未启用,因此您必须采取直接行动来实施这些措施。请将这些建议视为确保 AWS 账户安全的基本步骤。实施这些步骤时,务必建立一个可持续评测和监控安全控制机制的过程,这非常重要。
首次创建时 AWS 账户,首先要有一个可以完全访问账户中所有 AWS 服务和资源的身份。此身份被称为 r AWS 账户 oot 用户。您可以使用在创建账户所用的电子邮件地址和密码以根用户身份登录。由于向 AWS root 用户授予了更高的访问权限,因此您必须限制使用 AWS root 用户来执行特别需要它的任务。必须严格保护根用户登录凭证,并且应始终对 AWS 账户 根用户使用多因素身份验证 (MFA)。
除了使用用户名、密码和多重身份验证 (MFA) 设备登录根用户的正常身份验证流程外,还有一些账户恢复流程可以登录 AWS 账户 根用户,该用户可以访问与您的账户关联的电子邮件地址和电话号码。因此,保护发送恢复电子邮件的根用户电子邮件账户和保护与该账户关联的电话号码同样重要。还要考虑潜在的循环依赖关系,即与 root 用户关联的电子邮件地址托管在电子邮件服务器或来自该服务器的域名服务 (DNS) 资源上 AWS 账户。
使用时 AWS Organizations,有多个, AWS 账户 每个都有一个 root 用户。将一个账户指定为管理账户,然后可以在管理账户下面添加几层成员账户。优先保护管理账户的根用户,然后解决成员账户根用户问题。保护管理账户根用户的策略可能与保护成员账户根用户的策略不同,您可以对成员账户根用户建立预防性安全控制机制。
实施步骤
建议使用以下实施步骤为根用户建立控制机制。在适用的情况下,建议与CIS AWS
基金会基准测试版本1. 4.0进行交叉引用。除这些步骤外,请查阅保护您的 AWS 账户 和资源AWS 的最佳实践指南
预防性控制机制
-
为账户设置准确的联系信息。
-
这些信息用于丢失的密码恢复流程、丢失的MFA设备帐户恢复流程,以及与您的团队进行与安全相关的关键通信。
-
使用企业域托管的电子邮件地址(最好是通讯组列表)作为根用户的电子邮件地址。使用通讯组列表而不是个人的电子邮件账户可提供额外的冗余和连续性,以便在很长一段时间内访问根账户。
-
联系信息上所列的电话号码应该是为此目的而设置的专用安全电话的号码。电话号码不应列出或与任何人共享。
-
-
不要为根用户创建访问密钥。如果存在访问密钥,请将其删除 (CIS1.4)。
-
消除根用户的任何长期编程凭证(访问密钥和私有密钥)。
-
如果 root 用户访问密钥已经存在,则应将使用这些密钥的进程过渡为使用 AWS Identity and Access Management (IAM) 角色中的临时访问密钥,然后删除 root 用户访问密钥。
-
-
确定是否需要为根用户存储凭证。
-
如果您使用 AWS Organizations 创建新的成员帐户,则新成员账户中根用户的初始密码将设置为一个不会向你公开的随机值。如果需要,可以考虑使用 AWS 组织管理账户中的密码重置流程来访问成员账户。
-
对于独立账户 AWS 账户 或管理 AWS 组织账户,请考虑为根用户创建并安全存储凭证。用MFA于 root 用户。
-
-
在 AWS 多账户环境中对成员账户 root 用户使用预防性控制。
-
考虑为成员账户启用不允许为根用户创建根访问密钥预防性防护机制。
-
考虑为成员账户启用不允许以根用户身份执行操作预防性防护机制。
-
-
如果需要根用户凭证,请执行以下操作:
-
使用复杂密码。
-
为 root 用户开启多重身份验证 (MFA),尤其是 AWS Organizations 管理(付款人)账户 (CIS1.5)。
-
考虑使用硬件MFA设备来提高弹性和安全性,因为一次性设备可以减少包含您的MFA代码的设备被重复用于其他目的的机会。确认定期更换由电池供电的硬件MFA设备。(CIS1.6)
-
考虑注册多MFA台设备进行备份。 每个账户最多允许 8 MFA 台设备
。 -
安全地存储密码,如果以电子方式存储密码,则考虑循环依赖关系。不要以需要访问密码 AWS 账户 才能获取密码的方式存储密码。
-
-
可选:考虑为根用户制定定期密码轮换计划。
-
凭证管理最佳实践取决于您的监管和政策要求。受保护MFA的 root 用户不依赖密码作为身份验证的单一因素。
-
定期更改根用户密码可降低无意中暴露的密码被滥用的风险。
-
侦测性控制
-
创建警报以检测根凭证的使用情况 (CIS1.7)。通过RootCredentialUsage调查结果,Amazon GuardDuty 可以监控根用户API凭证的使用情况并发出警报。
-
评估和实施 Well-Ar chitecte AWS d Security Pillar 一致性包中包含的侦探控件, AWS Config以用于控制塔中强烈推荐的控件,或者如果 AWS Control Tower使用控制塔中强烈推荐的控件。
运营指导
-
确定组织中应该有权访问根用户凭证的人员。
-
使用两人规则,这样任何人都无法访问所有必需的凭证,也无法获得 root 用户访问权限。MFA
-
确认组织而不是个人保持对与该帐户关联的电话号码和电子邮件别名(用于密码重置和重MFA置流程)的控制权。
-
-
仅在例外情况下使用 root 用户 (CIS1.7)。
-
r AWS oot 用户不得用于日常任务,即使是管理任务也是如此。仅以根用户身份登录,以执行需要根用户的AWS 任务。所有其他操作都应由代入适当角色的其他用户执行。
-
-
定期检查对根用户的访问是否正常,以便在出现需要使用根用户凭证的紧急情况之前对过程进行测试。
-
定期检查与账户关联的电子邮件地址以及备用联系人下列出的电子邮件地址是否有效。监控这些电子邮件收件箱,查看您可能从
<abuse@amazon.com>
中收到的安全通知。还要确保与该账户相关的任何电话号码都有效。 -
准备事件响应程序,应对根账户滥用情况。请参阅《AWS Security Incident Response Guide》以及《安全性支柱》白皮书“事件响应”部分中的最佳实践,了解有关为 AWS 账户构建事件响应策略的更多信息。
资源
相关最佳实践:
相关文档:
相关视频:
相关示例和实验室: