AWS IAM角色最佳实践

Amazon Web Services（AWS）作为领先的云服务提供商，提供从简单实例机器到无服务器数据集成服务的全方位工具和服务套件。虽然AWS上有数百种不同的服务，但有一个服务统领全局：AWS身份和访问管理（IAM）。

根据设计，AWS是一个云平台，其中每个实体都需要权限才能访问和利用资源与服务。这些实体范围从用户和虚拟机一直到原生AWS服务。是的，即使是内置的AWS服务也需要权限才能访问其他AWS服务。这种设计理念将IAM置于一切的中心，而IAM的主要功能——IAM角色，则定义了其核心的权限和特权。

什么是IAM角色？

IAM角色是您可以在账户中创建的具有特定权限的IAM身份。IAM角色类似于IAM用户，因为它是一个具有权限策略的AWS身份，这些策略决定了该身份在AWS中能够和不能执行的操作。然而，角色并非与某个人唯一关联，而是旨在由任何需要它的人担任。角色没有与之关联的长期凭证（控制台密码、标准访问密钥），它们拥有通过安全令牌服务（STS）授予的短期凭证。每次服务主体想要担任角色时，它会调用安全令牌服务（STS），如果获得许可，它将收到带有临时安全令牌的响应。

有不同类型的服务主体可以担任IAM角色。我大致将它们分类为用户和服务。

用户是代表个人的实体；该实体具有名称和与之关联的凭证。虽然这不是官方分类，但我会将供用户使用的角色称为“用户角色”。
服务实体可以是在您 behalf 执行操作的原生AWS服务，也可以是在AWS服务（如EC2和Lambda）上运行的应用程序。原生AWS服务预定义角色，这些角色赋予它们代表用户访问其他AWS服务所需的所有权限；它们被称为“服务关联角色”。在EC2、Elastic Beanstalk或Lambda上运行的应用程序是自定义构建的，通常需要“自定义IAM角色”，因此我会这样称呼它们。

实际上，角色是通用的，任何被允许的实体都可以担任它。考虑到用户可以使用IAM角色，而数百种原生服务专门使用IAM角色，我们最终会面临这样一种情况：拥有过多的IAM角色，并且新的角色还在不断涌现。

我概述了最佳实践以应对IAM带来的潜在风险。为了条理清晰，这些最佳实践按识别、防护、检测、响应和修复阶段进行排序。

我坚信这个助记符：“识别所有资产，防护其免受威胁，检测无法防护的威胁，响应检测到的威胁并修复其影响”。

识别与防护

1. 锁定您的AWS账户根用户

当您首次创建Amazon Web Services（AWS）账户时，您会从一个具有完全访问账户中所有AWS服务和资源的身份开始。此身份称为AWS账户根用户。任何拥有您AWS账户根用户凭证的人都可以不受限制地访问您账户中的所有资源。根凭证的泄露是最有害的。

a. 我建议不要将根用户用于您的日常任务，即使是管理任务。相反，仅使用您的根用户凭证来创建您的IAM管理员用户。 b. 要么禁用根用户的访问密钥，要么完全删除它。 c. 使用强密码甚至随机密码限制根用户。 d. 对根用户强制执行多因素认证。

2. 为所有服务主体首选IAM角色但限制其使用

a. 对于用户：首选使用IAM角色供内部用户和第三方用户使用。使用SAML 2.0角色是合适的。根据信任策略文档限制对角色的访问，仅允许匹配特定SAML属性（如SAML关联）的用户。此外，使用aws:SourceIp条件基于用户的源IP地址限制访问。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Federated": "arn:aws:iam::account-id:saml-provider/ExampleOrgSSOProvider"},
    "Action": "sts:AssumeRoleWithSAML",
    "Condition": {
      "StringEquals": {
        "saml:aud": "https://signin.aws.amazon.com/saml",
        "saml:iss": "https://openidp.feide.no"
      },
      "ForAllValues:StringLike": {"saml:edupersonaffiliation": ["staff"]},
      "StringEquals": { "aws:SourceIp" : "x.x.x.x" }
    }
  }]
}

b. 对于EC2实例和Lambda函数：在IAM角色中使用信任策略直接限制其对特定实例的使用是不可能的。Lambda也存在同样的问题。我建议使用诸如aws:SourceVpc之类的条件来限制访问，以确保该角色至少仅限于来自受信任VPC的资源。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "ec2.amazonaws.com" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringLike": {
          "aws:SourceVpc": " arn:${Partition}:ec2:${Region}:${Account}:vpc/${VpcId}"
        }
      }
    }
  ]
}

3. 管理任务的即时访问

传统上，用户必须经过身份验证和授权才能访问受保护的资源。身份验证通常是一次性事件，这意味着用户拥有持久访问权限，可以随时调用。调用访问的过程不考虑他们在每次调用时的具体原因。

“即时”方法考虑了对关键权限的临时提升访问权限，也称为即时访问。用户必须像以前一样经过身份验证和授权——但此外，每次用户调用访问时，都会进行一个额外的过程，其目的是识别并记录在此特定场合调用访问的业务原因。该过程可能涉及额外的人员参与者，或者可能使用自动化。当过程完成时，仅当业务原因适当时才授予用户访问权限。

虽然我们通常可以将某些权限标记为关键权限，但其中大多数权限与其与生产AWS账户的相关性是主观的。IAM是普遍接受的关键权限之一，因此我建议阻止以下IAM操作，并仅通过“即时”系统允许它们。

1

"iam:Add*", "iam:Attach*", "iam:Create*", "iam:Deactivate*", "iam:Delete*", "iam:Detach*", "iam:Put*", "iam:Remove*", "iam:Set*", "iam:Update*", "iam:Upload*"

AWS有一个“即时”访问系统的模板，许多CSPM和PAM供应商提供商业解决方案，可以满足这一需求。

检测

1. 检测IAM角色枚举

不良行为者采用各种技术来枚举AWS账户的IAM角色。

a. 一种简单但初级的方法是使用IAM角色名称字典暴力尝试sts assume-role。

1

'aws sts assume-role –role-arn arn:aws:iam::<<ACCOUNTID>>:<<ROLE>>'

作为一种检测机制，可以在cloudtrail日志中监控连续的失败sts assume-role请求。

b. 一种更隐蔽的方法是使用UpdateAssumeRolePolicy方法，不良行为者拥有自己的账户，他们尝试在信任策略部分使用UpdateAssumeRolePolicy文档，为受害者账户中的角色提供担任其账户中角色的权限。如果操作成功，则证实了受害者账户中存在该角色。这种技术仅在不法分子账户中生成Cloudtrail日志，而不会在受害者的Cloudtrail日志中记录枚举尝试。请参阅Rhinosecuritylabs的文章以获取更多信息并参考图(1)。

虽然这种技术本质上是不可检测的，但风险较低。作为替代补救措施，我建议运行模拟同类攻击以识别潜在泄漏并可能重命名那些IAM角色。文章中的iam_user_enum.py可以协助此练习。

2. 检测可疑访问

虽然没有明确的方法来识别可疑访问事件，但确实存在一些迹象。

a. 监控IP地址：监控IP地址可以帮助我们识别API调用来源的性质，特别是其信誉；即，该IP地址是否与恶意信誉相关联，源是否试图通过TOR、防弹托管或其他代理服务传输请求来混淆其IP地址。 b. 可疑用户代理：伴随API调用或控制台登录的另一个工件是用户代理。用户代理标头参数描述了源主机，特别是操作系统；一个明显的危险信号是如果操作系统是Kali Linux或其他专为进攻性安全设计的操作系统。 c. 多重登录/超人登录：多重登录或“超人”登录事件也暗示可疑行为。虽然多地点登录很容易检测，但超人登录则不然。超人登录涉及用户从一个地理位置登录，然后随后从另一个遥远的地理位置登录，这是不可行的，除非您像超人一样快速飞行。

上述事件可以通过注入Cloudtrail日志来检测，但更简单的方法是使用原生工具；Amazon Guard Duty。

3. 检测IAM权限提升技术

理想情况下，所有写入和删除IAM权限都应通过“即时”访问机制进行保护，如前一节所述。如果未实施“即时”机制，我们需要监控可能用于权限提升的IAM事件。Cloudwatch可用于监控CloudTrail日志中的这些事件。事件列表如下：

用户事件：

iam:CreateUser
iam:CreateLoginProfile
iam:AddUserToGroup
iam:UpdateProfile
iam:PutUserPolicy
iam:AttachUserPolicy

组事件：

iam:CreateGroup
iam:PutGroupPolicy

角色事件：

iam:CreateRole
iam:CreateInstanceProfile
iam:PutRolePolicy
iam:AttachRolePolicy
iam:UpdateAssumeRolePolicy

策略事件：

iam:CreatePolicy
iam:CreatePolicyVersion

其中一些操作也可以被不良行为者用来在受害者账户中实现持久性。

iam:CreateUser
iam:CreateRole
iam:CreateAccessKey
iam:UpdateAssumeRolePolicy

响应与修复

自动化事件响应

虽然检测潜在的权限提升技术和可疑访问很有帮助，但及时响应是关键，而自动化事件响应是实现这一目标的适当方式。在云中实现自动化事件响应有多种方式；其中大多数涉及使用无服务器函数。无服务器函数根据设计是事件驱动的、短小的代码片段，通常具有明确的目的，因此它们非常适合事件响应。有许多针对AWS事件响应的开源项目；CloudBots就是其中之一。它是由Check Point软件技术维护的项目，构建在CloudGuard持续合规能力之上。它们也可以独立使用，无需CloudGuard，来修复AWS账户中的问题。

我建议至少在以下用例中采用CloudBots：

a. 删除根用户的访问密钥：如果为根用户创建了未经授权的访问密钥，CloudBot iam_delete_access_key.py可以删除它们。 b. 撤销权限提升——分离策略：如果发生通过操纵IAM角色进行的疑似权限提升，CloudBot iam_detach_policy.py可以分离IAM策略，或者iam_quarantine_role.py可以向有问题的IAM策略添加显式拒绝所有。

典型的自动化事件响应解决方案可以使用Cloudtrial日志、CloudWatch警报、SNS和在Lambda上运行的CloudBots来构建。参考图表(2.)并参阅CloudBots项目以获取更多信息。