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角色。我将其大致分类为用户和服务。
-
用户是代表个人的实体；该实体具有与之关联的名称和凭据。虽然这不是官方分类，但我会将供用户使用的角色称为“用户角色”。
-
服务实体可以是代表您执行操作的原生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地址限制访问。
{"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的资源。
{"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操作，并仅通过“即时”系统允许它们。
"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。
'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可以协助此练习。
（1.）
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策略添加显式拒绝所有。
典型的自动事件响应解决方案可以使用Cloudtrail日志、CloudWatch警报、SNS和在Lambda上运行的CloudBots构建。请参考图表（2.）并参考CloudBots项目以获取更多信息。
（2.）
更多精彩内容 请关注我的个人公众号 公众号（办公AI智能小助手）
对网络安全、黑客技术感兴趣的朋友可以关注我的安全公众号（网络安全技术点滴分享）
公众号二维码
公众号二维码
