AWS IAM安全最佳实践

身份和访问管理是安全的一个支柱。随着云计算的出现，它变得更加复杂。

虽然这篇博文特别提到了AWS服务，但对于任何其他IAM框架来说，最佳实践大多是相同的。

"安全是零工作"。

当涉及到AWS的安全时，这是事实上的文化和标准。

这意味着它甚至比任何头号优先事项更重要。在AWS，如果有任何已知的安全问题开放，新的服务将不会启动。

作为AWS的用户，虽然我们同意云已经是新的规范，但它与在内部运行的安全是不同的。当涉及到云安全操作时，我们不想重新发明车轮（保障云安全的10条规则）。

因此，在这篇文章中，让我们通过 AWS IAM中的一些顶级规则和最佳实践，让我们以亚马逊的方式来做。

---

1 对AWS IAM的快速回顾

本节简要概述了AWS IAM及其中的一些术语。

如果你已经非常熟悉AWS IAM，请随意跳到下一节。如果你是AWS和IAM的初学者，建议阅读官方文档并在沙盒环境中进行操作。

1.1 什么是IAM？

AWS身份和访问管理（IAM）在所有的AWS中提供细粒度的访问控制。通过IAM，你可以指定谁可以访问哪些服务和资源，以及在哪些条件下。

它提供了两个共同作用的基本功能：

• 认证（Authn）：它验证了用户的身份。它通常通过检查凭证来处理，如用户名和密码。先进的Authn可能包括多因素认证 （MFA），它将传统的凭证与第三种认证形式相结合，如向用户的智能手机发送一个独特的代码。
• 授权（Authz）：不是每个用户都能访问 整个组织的每个应用程序、数据集或服务。一旦用户被认证，授权就定义了该用户的权限，并限制对该特定用户允许的资源的访问。

1.2 IAM身份。用户、组、角色

IAM处理几类不同的原则实体：根用户、用户、用户组和角色。

这些实体详细说明了一个用户是谁，以及该用户被允许在环境中做什么。 AWS根用户、组和用户

• 根用户。当你第一次创建一个亚马逊网络服务（AWS）帐户时，你开始有一个单一的登录身份，可以完全访问该帐户中的所有AWS服务和资源。这个身份被称为AWS账户根用户，通过使用您创建账户时使用的电子邮件地址和密码登录来访问。
• 用户。IAM用户是您在AWS中创建的一个实体。IAM用户代表使用IAM用户与AWS互动的人或服务。IAM用户的主要用途是让人们能够登录到AWS管理控制台进行互动任务，并使用API 或CLI对AWS服务进行编程请求。IAM用户拥有永久的长期凭证，并用于直接与AWS服务互动。
• (用户）组。一个IAM用户组是一个IAM用户的集合。你可以使用用户组来指定用户集合的权限，这可以使这些用户的权限更容易管理。
• 角色。IAM角色与用户非常相似，它是一个具有权限策略的身份，决定该身份在AWS中可以做什么和不能做什么。然而，一个角色没有任何长期的凭证（密码或访问密钥）与之相关。相反，当你承担一个角色时，它为你的角色会话提供临时安全凭证。一个角色并不与一个人相关联；它的目的是让任何人或任何需要它的服务（IAM用户、应用程序或AWS服务，如EC2）都可以承担。 AWS IAM概念概述

1.3 IAM策略

• 您通过创建策略并将其附加到IAM身份（用户、用户组或角色）或AWS资源来管理AWS中的访问。
• 策略是AWS中的一个对象，当与一个身份或资源相关联时，定义其权限。
• 策略中的权限决定了请求是被允许还是被拒绝。
• 大多数策略以JSON文档的形式存储在AWS中。

---

2 安全原则

在跳到如何使用IAM的最佳实践之前，让我们快速看一下两个重要的安全原则。理解这两条原则是至关重要的，因为它们是所有其他规则建立的基础。

2.1 零信任

零信任的意思正如其名：你绝对不信任任何人，即使是内部用户。从那里开始，你建立你的安全机制。

一个零信任的安全模型依赖于这些核心原则：

• 永不信任；总是验证（即使是一个内部服务访问另一个内部服务，也需要验证）
• 假设破坏（假设访问是一个安全破坏，并从那里建立访问权限）
• 最低权限访问（在不干扰用户日常工作流程的情况下，尽可能地限制访问和权限）

通过采用零信任模式，我们可以减少无意中允许未授权用户访问的风险。IAM和 "零信任 "策略能很好地配合，因为 "零信任 "能确保你的IAM政策和程序在用户需要访问的任何时候和任何地方都得到遵守。

零信任的基本规则是最小特权访问。

2.2 最低权限访问

这可能是最常见的安全相关最佳实践之一。

最小特权在不干扰用户正常使用的情况下，尽可能地限制访问和权限。

我们通过定义每个角色的用户在执行工作时需要的最小权限来实现这一目标。而目标是定期审计使用情况，尽可能减少不必要的常设权限。

当我们创建IAM策略时，要遵循标准的安全建议，即授予最少的权限或只授予执行任务所需的权限。确定用户（和角色）需要做什么，然后制定政策，只允许他们执行这些任务。

我们总是可以从最小的权限集开始，并根据需要授予额外的权限。尝试，失败，再尝试，增加更多，然后使之完美。这样做比一开始就赋予过宽的权限，然后再试图收紧它们更安全。

考虑到零信任和最小特权原则，让我们开始实施IAM。

3 减少你的IAM运营开销

让我直说吧：IAM很复杂。

它不容易理解，当然也不容易使用。尤其是当你在一个有许多用户、组、资源、甚至AWS账户需要管理的大团队中时。因此，首先要做的是：让我们谈谈一些顶级规则，以减少你的操作开销。

3.1 集中式IAM

如果你正在管理一个以上的 "环境"（如开发/测试/生产环境），你极有可能为每个环境使用一个单独的AWS账户，以实现最大的资源和权限分离。

但是，在每个账户中多次定义用户、角色和策略会带来
不必要的操作开销。另外，如果用户从一个账户中签出，再签入另一个账户来访问不同环境中的资源，那就很麻烦了。

因此，我们可以委托他人访问不同AWS账户中的资源。这个想法是为了与不同账户的用户共享一个账户中的资源。这是通过在一个账户中创建一个角色并授予另一个账户的用户承担该特定角色来实现的。

如果你管理多个AWS账户，这将是一个管理身份和访问的简单方法。集中IAM允许所有功能和配置驻留在一个中央AWS账户中。一个集中的安全系统将为所有不同的安全配置提供更好的可见性。

3.2 DevSecOps - 自动化一切

相信我，你不会想登录到AWS网络控制台，进入IAM，然后点击一些按钮来管理IAM用户/组/角色。我能想到的唯一情况是，这可能是一个好主意：

• 第一次使用新账户时。
• 以及当你想尝试一些不熟悉的功能时。

但让我在这里阻止你。除了这两种情况外，不建议通过控制台手动管理IAM资源。

为什么是自动化？当然，自动化可以减少人工劳动。但它不仅仅是这样。

• 自动化可以减少人类的错误。我们是人类，而人类会犯错。这就是我们之所以为人，而不是机器人的原因。
• 自动化使记录、审计和定期生成报告变得容易，以满足合规要求。

如果你想开始自动化你的IAM的东西，Terraform和Terraform AWS提供者是很好的开始。

4 基本设置

4.1 不要使用根用户

一个公司可能会用根证书创建一个AWS账户，并用其他证书建立许多不同的用户和角色。根账户应该始终是AWS环境中最受保护和安全的实体。

要向AWS提出程序性请求，你需要一个访问密钥（访问密钥ID+秘密访问密钥）。 千万不要使用你的AWS账户根用户访问密钥。 你的AWS账户根用户的访问密钥可以完全访问你所有AWS服务的所有资源。你 不能减少与您的AWS帐户根用户访问密钥相关的权限。

因此，保护你的根用户访问密钥，就像保护你的信用卡号码或任何其他敏感秘密一样。这里有一些方法可以做到这一点：

• 不要在你的日常任务中使用根用户，甚至是管理任务。相反，只使用你的根用户凭证来创建你的IAM管理用户。然后安全地锁住根用户的凭证。对于日常任务，甚至不要使用你的IAM管理用户。相反，使用角色来委托权限。
• 删除根用户的访问密钥。如果你必须保留它（你不需要），定期轮换（改变）访问密钥。

4.2 启用多因素认证（MFA）

IAM支持多因素认证，这需要一个基于用户拥有的物理项目的额外凭证。

为了提高安全性，强烈建议你为AWS账户中的所有用户启用MFA。启用MFA后，如果一个用户的密码或访问密钥被破坏，你的账户资源仍然是安全的，因为有额外的认证要求。

4.3 使用一个强大的密码策略

如果你允许用户改变他们的密码，创建一个自定义的密码策略，要求他们创建强密码并定期轮换密码。

IAM允许IAM管理员实施一个自定义的密码策略，可以强制使用更强的密码并要求定期更换密码。更强的密码更难通过系统的尝试来破解，并增强了云安全。

4.4 使用IAM角色而不是长期的访问密钥

访问密钥提供了对AWS的程序化、长期（它们永远不会过期）的访问。如果它被泄露了，就等于泄露了你的AWS账户密码。

对于大多数需要访问AWS的应用程序，最好的做法是配置程序，使用IAM角色检索临时安全凭证。

考虑到这一点，不要把访问密钥放在未加密的代码内。例如，如果你在持续集成系统中使用你的访问密钥，不要把它们作为明文使用。相反，将它们作为 "秘密 "使用。例如，在Jenkins中，你可以创建凭证；在或GitHub Actions中，你也可以创建repo秘密。

另外，不要在用户之间分享这些安全凭证。要让你的用户有单独的程序性访问，可以创建一个有个人访问密钥的IAM用户。

4.5 定期轮换凭证

如果你从不改变你的密码，而密码或访问密钥在你不知道的情况下被泄露，那么这个凭证可以永远使用。

如果我们对你的账户应用自定义密码策略，要求你的所有IAM用户轮换他们的AWS管理控制台密码，并选择密码必须轮换的频率（例如，每90天），我们就会限制凭证可以用来访问我们的资源的时间。而且，如果凭证在我们不知情的情况下被泄露，我们可以肯定地知道，该凭证最多只有90天的有效期。

因此，定期更改你的密码和访问密钥，并确保你账户中的所有IAM用户都能做到。这可以大大降低风险。

4.6 删除过时的和不必要的凭证

例如，如果你为一个不使用控制台的应用程序创建了一个IAM用户，这个IAM用户就不需要密码。

同样地，如果一个用户只使用控制台，请删除他们的访问密钥。

另外，找到并删除闲置的IAM密码和密钥，以提高安全性。你可以使用控制台，使用CLI或API，或通过下载凭证报告来找到未使用的密码或访问密钥。

5 组

在现实世界中，你有不同的团队，每个团队需要不同的权限，应该只允许访问某些资源。

当然，我们可以创建每个用户并为每个用户分配权限，但创建组并为其分配权限总是比为单个用户定义权限要容易。把AWS IAM中的用户组看作是用户的逻辑集合。这样，我们可以创建与各种工作职能相关的多个组（管理员、安全审计员等），并在将用户标记到这些组之前为每个组分配相关权限。

我们可以通过在IAM中创建组来轻松管理团队的访问级别。一个组中的用户将有类似的访问级别。AWS建议通过创建组来管理用户的访问，并将权限分配给该组。这使得管理用户访问级别变得简单而精简。将来，如果你需要改变团队的访问级别，你只需要在组的级别上做一个改变。

使用组不仅更容易，而且更安全，更容易管理。例如，每当有部门间的调动，人们只需要把个人放在另一个组里，而不是重新定义整个权限。

6 角色

6.1 使用角色来委托权限

你不应该把钥匙放到代码或实例中。

当编写代码时，将密钥存储在代码本身（或环境中）比较容易，但它有潜在的漏洞。即使钥匙是加密的，黑客也有可能提取这些钥匙。推荐的做法是使用IAM角色和生成的临时安全凭证。

你可以通过使用AWS安全令牌服务 （STS）操作来承担IAM角色，或者在AWS管理控制台中切换到一个角色来接收一个临时角色会话。这比使用你的长期密码或访问密钥更安全。一个会话的持续时间是有限的，这可以减少你的凭证被破坏的风险。

对于IAM用户，为特定的工作任务创建单独的角色，并为这些任务承担这些角色。不要在日常工作中使用你的IAM管理员用户。

6.2 为EC2实例上的应用程序使用角色

在AWS EC2实例上运行的应用程序需要凭证来访问其他AWS服务。例如，如果你有一个在EC2实例上运行的应用程序，并且该应用程序需要写入一个S3桶。

你可以创建一个带有访问密钥的IAM用户，然后将这些凭证分发到实例上，使应用程序能够私下签署请求。

但问题在于分发：为了安全地将凭证分发到每个实例，特别是AWS代表您创建的实例（例如，Spot Instances或Auto Scaling组中的实例），您还必须能够在轮换AWS凭证时更新每个实例的凭证。

简而言之，使用IAM角色来更安全地授予应用程序的访问权。

提醒：角色是一个实体，它有自己的一套权限，但它不是一个用户或用户组。角色也不像IAM用户那样有自己的永久凭证集。在亚马逊EC2的情况下，IAM动态地提供临时凭证给EC2实例，这些凭证会自动为你旋转。

细节。亚马逊EC2 使用一个实例配置文件作为IAM角色的容器。当您使用IAM控制台创建IAM角色时，控制台会自动创建一个实例配置文件，并将其命名为与它所对应的角色相同。如果您使用亚马逊EC2控制台启动具有IAM角色的实例或将IAM角色附加到实例，您将根据实例配置文件名称的列表选择角色。通过这种方式，在EC2实例上运行的应用程序在访问AWS资源时可以使用该角色的证书。

7 策略

7.1 AWS管理的策略

如果你是AWS世界的新手，并努力为不同的用户、组和角色创建和维护你的策略，考虑尽可能使用AWS预定义的、开箱即用的管理策略。

AWS管理的策略涵盖了常见的使用情况，并与常见的IT功能相匹配。无论你是一个需要在AWS中设置和配置东西的网络人员，还是一个试图运行一些Hadoop查询的数据科学家，都有可能已经有一个AWS管理的策略为你服务。

使用AWS管理的策略可以减少你的操作开销。此外，还有一个主要的好处：自动更新。每当有新的AWS服务或API引入时，这些策略就会更新。这节省了大量的时间，确实是生活质量的提高。例如，AWS管理着一个名为 "ReadOnlyAccess "的策略，它提供对所有AWS服务和资源的读取访问。比方说，AWS推出了一项新服务。AWS将确保'ReadOnlyAccess'策略随着这个新推出的服务而更新。此外，这一变化将被应用到所有实体（组、用户或角色），只要ReadOnlyAccess策略已经被附加。

警告!请记住，AWS管理的策略不会授予最低权限的权限。你必须考虑授予你的委托人比他们完成工作所需的更多权限的安全风险。

7.2 客户管理的策略优于内联策略（对于大多数情况）

尽管AWS管理的策略是一个很好的开始，但它们并不遵循最小特权原则。

建议使用具有最小特权原则的策略。最安全的方法是编写一个只有你的团队需要的权限的自定义策略。然而，你必须创建一个流程，允许你的团队在必要时申请更多的权限：因此你要负责管理你的策略；这就是为什么我们谈论客户管理的策略。创建只向你的团队提供他们需要的权限的政策，需要时间和专业知识。

在大多数情况下，客户管理的政策比内联政策更受欢迎（内联政策是嵌入在用户、组或角色中的）。管理的策略具有以下特点：

• 用户、组、角色之间的可重复使用性
• 中央变更管理（任何变更都会自动传播）。
• 版本管理和回滚（任何变化都可以轻松回滚），以及
• 委托权限管理（允许你的AWS账户中的用户附加和分离策略，同时保持对他们着手的权限的控制）。

如果你在管理政策和内联政策之间犹豫不决，请选择管理政策。

只有当你想在策略和应用该策略的身份之间保持严格的一对一关系时，才会选择内联策略。例如，你想确保策略中的权限不会被无意中分配给一个身份，而不是他们的目的。当你使用内联策略时，策略中的权限不会被无意中附加到错误的身份。此外，当你使用AWS管理控制台删除该身份时，嵌入该身份的策略也被删除。这是因为它们是主体实体的一部分。

7.3 额外安全：政策条件

上下文在安全方面是很重要的。你可以通过定义IAM策略允许访问资源的条件来利用它。

例如，你可以写条件来指定一个请求必须来自的IP地址范围。再比如，你可以要求用户通过MFA设备认证，以便被允许终止一个亚马逊EC2实例。

但要注意，不要做得太过火，以至于变得不切实际。

7.4 策略验证

验证你所创建的策略。

你可以验证语法（JSON）和逻辑。前者是自动的，任何现代文本编辑器都可以做到。

第二种是比较复杂的：你可以很好地利用IAM访问分析器来检查你的策略，并得到建议来编写更安全的策略。当你的策略中的某个声明允许我们认为是过度许可的访问时，它就会产生安全警告。

7.5 根据访问活动生成一个策略

这很聪明：你不知道谁在使用什么，但想执行最少的特权？很简单!根据AWS CloudTrail记录的访问活动生成IAM策略!

当给定一个IAM实体（用户或角色）时，IAM访问分析器可以审查您的AWS CloudTrail日志，并生成一个策略模板，其中包含该实体在您指定的时间范围内使用过的权限。

这个模板可以用来创建一个具有细粒度权限的管理策略。只要把它附加到IAM实体上，就可以了。

这使得收紧权限变得更加容易，只需要实体在特定的使用情况下与AWS资源进行交互即可。

7.6 使用访问级别来审查IAM的权限

你应该定期审查和监控你的IAM策略，以提高你的AWS账户的安全性。确保您的策略授予仅执行必要操作所需的最低权限。

您可以查看策略摘要，其中包括该策略中每个服务的访问级别摘要。AWS根据每个行动的内容将每个服务行动归入五个访问级别之一。列表、读取、写入、权限管理或标记。你可以使用这些访问级别来决定哪些操作要包括在你的策略中。

8 及时访问管理

一个准确的最小特权安全模型不仅要求用户、应用程序和系统有足够的权利和访问，而且授予的访问时间不超过所需时间。

消除特权用户账户的持久性特权访问，仅在执行活动所需的时间内激活它，这是
，是最小特权实施中最被忽视的部分。

这就是我们所说的适时访问管理。

例如，使用HashiCorp Vault的AWS引擎可以根据IAM策略动态地生成AWS访问凭证。

这通常使使用AWS IAM更容易，因为它根本不涉及在Web UI中的点击。此外，IAM凭证是基于时间的，当Vault租赁期满时，会自动撤销。

例如，Vault将为每个租约创建一个IAM用户，并将角色中指定的管理和内联IAM策略附加到该用户。而Vault将在达到TTL到期时删除IAM用户。

通过这种方式，我们可以用AWS IAM实现JIT访问管理。

9 监控和审计

业务和应用随着时间的推移而改变。创建用户、组、角色和策略并使其自动化只是一个起点。从这里开始，我们还需要定期审查和更新安全相关的设置和策略。

9.1 安排访问审计

即使有围绕访问控制的强大政策，过度供应仍然是许多组织的问题。审计是基本的IAM最佳实践之一，以建立在你的整体IAM策略中，并保持最小特权的原则。

企业不断地在其技术堆栈中添加新的工具和应用程序，员工可能认为他们需要访问所有这些工具来执行他们的工作。然而，随着团队精简他们的工作流程，IT部门通常会发现员工没有使用的孤儿账户。通过定期审计使用日志和访问权限，IT团队可以取消访问权限，减少他们的攻击面。

限制访问权限是IAM安全最佳实践的一部分，但持续跟踪用户真正需要的访问权限的唯一方法是通过定期审计。 在你的IAM策略中创建一个审计时间表，以确保你的团队优先考虑这个重要的安全程序。

9.2 最后访问的信息

应定期审查政策和权限，特别是当人们离开或改变时。

另一个可以帮助审查访问和坚持最小特权的IAM功能是最后访问信息。这个信息可以在IAM用户、组、角色或策略的IAM控制台详细信息页面的访问顾问标签上找到。

最后访问信息包括一些服务的最后访问操作信息，如Amazon EC2、IAM、Lambda和Amazon S3。你可以使用这些信息来识别不必要的权限，这样你就可以完善你的IAM或组织策略，删除不使用的策略，以更好地遵守最小特权原则。

9.3 监控活动

你可以使用AWS中的日志功能来确定用户在你的账户中所采取的行动以及所使用的资源。日志文件显示了行动的时间和日期，行动的源IP，哪些行动由于权限不足而失败，等等。

许多AWS服务支持日志记录；它们可以记录用户请求的细节。

如果你想记录AWS账户的API调用和相关事件，你也可以使用AWS CloudTrail，它可以监控和记录整个AWS基础设施的账户活动，让你控制存储、分析和补救行动。

为了进一步减少权限，你可以在AWS CloudTrail事件历史中查看账户的事件。CloudTrail事件日志包括详细的事件信息，你可以用它来减少策略的权限。这些日志只包括你的IAM实体需要的行动和资源。

9.4 可以帮助的其他AWS服务

AWS配置

AWS Config是一项服务，使您能够评估、审计和评价您的AWS资源的配置。

它提供有关您的AWS资源配置的详细历史信息，包括您的IAM用户、用户组、角色和策略。例如，您可以使用AWS Config来确定在特定时间属于某个用户或用户组的权限。

AWS GuardDuty

AWS GuardDuty 是一项威胁检测服务，它可以持续监控AWS账户和工作负载的恶意活动，并提供详细的安全发现，以提高可见性和补救措施。

例如，如果有一天你位于欧盟，而你的账户是在非洲登录的（个人真实故事），GuardDuty可以发现它并提醒你。

恕我直言，AWS的IAM确实是个麻烦。要学习或理解所有的概念并不容易，要完美地自动化使用它也绝对不容易。在下面的文章中见!