我们使用机器学习技术将英文博客翻译为简体中文。您可以点击导航栏中的“中文(简体)”切换到英文版本。
两个关于限制权限为何起作用的真实示例:来自 亚马逊云科技 CIRT 的经验教训
欢迎阅读
不幸的是,这不是一个容易回答的问题。您需要考虑意外问题发生的可能性、该问题如果确实发生所产生的影响,以及防止(或检测并从中恢复)该问题所花费的成本和精力。您还需要在决策过程中考虑诸如业务目标和监管要求之类的要求。当然,你不需要只考虑一个潜在的问题,而是需要考虑很多问题。通常,从一组粗略的权限开始,然后在逐渐了解所需的安全级别时对其进行细化可能会很有用。
故事 1:寻找证书
在这篇亚马逊云科技 CIRT故事中,我们看到了威胁行为者如何无法实现其目标,因为他们获得的访问权限(数据库管理员的访问权限)没有他们想要的IAM权限。
背景和 亚马逊云科技 CIRT 参与度
一位客户在本地系统和某些 亚马逊云科技 账户中发现了未经授权的活动后来找我们。他们具备事件响应能力,正在寻找另一批具有 亚马逊云科技 知识的人手来帮助他们进行调查。这有助于让客户的员工腾出时间专注于本地分析。
在我们参与之前,客户已经进行了初步的封闭活动。这包括轮换证书、吊销临时证书和隔离受影响的系统。他们还很清楚威胁行为者访问了哪些联合用户帐户。
每个 亚马逊云科技 CIRT 互动的关键部分都是客户的要求。我们团队所做的一切都属于
分析和发现
在故事的这一部分中,我们将重点关注一个联合用户,我们调查了该用户的明显行为,因为威胁行为者没有以有意义的方式冒充其他联合用户。我们知道需要重点关注的大概开始和结束日期,并发现威胁行为者采取了许多不必要的行动。
在审查了这些行为后,很明显,威胁行为者在2小时内曾三次进行控制台登录。每次,威胁行为者都试图执行以下操作的子集:
-
创建访问密钥 — 创建新的 亚马逊云科技 私有访问密钥 -
createLoginProfil e — 为给定的 IAM 用户创建控制台密码 -
updateAccessKey — 将访问密钥从非活动更改为活动状态(反之亦然) -
DeleteAccessKey — 删除访问密钥 对 -
putrolePolicy — 添加或更新内联 IAM 策略 -
createPolicyVer sion — 创建现有托管策略的新版本
注意: 此列表仅包括在
亚马逊云科技 CloudTrail 中显示为 ReadOnly = false 的操作,因为这些操作通常(但并非总是)影响更大,有可能改变 亚马逊云科技 环境。
这就是权限限制的好处变得显而易见的地方。编译此列表后,我们注意到列出 的所有 操作都有两个字段:
正如这所揭示的那样,由于联合用户账户没有所需的 IAM 权限,威胁行为者尝试的每一次非 ReadOnly 操作都被拒绝。
客户沟通和结果
在我们确认调查结果后,我们与客户进行了电话讨论结果。可以想象,他们很高兴结果显示出对他们的数据没有实质性影响,并表示当时无需进行进一步的调查或采取行动。
联合用户拥有的 IAM 权限有哪些,这些权限阻止了威胁行为者尝试的一系列操作?
答案实际上并不涉及用户完成工作所需的绝对最低权限集。仅仅是联合用户的角色没有针对威胁行为者尝试的 IAM 操作的 Allow 语句——他们的工作不需要他们。如果没有明确的 Allow 语句,尝试的 IAM 操作会被拒绝,因为 IAM 策略默认为拒绝。在这种情况下,仅仅没有所需的 IAM 权限就意味着威胁行为者无法实现其目标,因此停止使用访问权限。我们永远不会知道他们的实际目标是什么,但是尝试创建访问密钥、密码和更新策略意味着可以合理地猜测他们正在尝试创建另一种访问该亚马逊云科技账户的方式。
故事 2:更多加密挖矿实例
在这篇亚马逊云科技 CIRT故事中,我们看到了威胁行为者无法创建额外的
背景和 亚马逊云科技 CIRT 参与度
我们的第二个故事涉及一位客户,该客户使用一个 亚马逊云科技 账户来测试一些使用
由于该账户是新账户,目前仅用于测试他们的软件,因此客户发现该检测与 Amazon ECS 集群有关,因此决定删除该账户中的所有资源并进行重建。这样做后不久,他们就已经建立的新亚马逊ECS集群收到了类似的GuardDuty警报。第二项发现导致客户的安全团队和亚马逊云科技被邀请来试图了解是什么原因造成的。客户的安全团队专注于审查集群上正在运行的任务,而 亚马逊云科技 CIRT 则审查了 亚马逊云科技 账户操作并提供了有关 GuardDuty 调查结果及其可能原因的见解。
分析和发现
通过与客户合作,不久我们发现客户使用的 第三 方 Amazon ECS 任务定义无意中向互联网暴露了 Web 界面。该接口允许未经身份验证的用户在系统上运行命令。这解释了为什么在新安装完成后不久也收到了同样的警报。
这就是故事变得更好的地方。亚马逊云科技 CIRT
接下来,我们与客户合作,了解了 Task IAM 角色提供的权限。再一次,权限本可以受到更严格的限制。但是,这次威胁行为者的目标——运行多个 Amazon EC2 实例(最有可能用于秘密的加密挖矿)——与赋予该角色的策略不一致:
亚马逊云科技 CIRT 建议制定策略以进一步限制允许的操作,尽可能提供特定资源,并可能增加一些条件以限制访问的其他方面(例如
客户沟通和结果
向客户报告这些发现后,接下来有两个明确的步骤:首先,从他们的亚马逊云科技账户中删除现在不需要和不可信的Amazon ECS资源。其次,审查并重新架构 Amazon ECS 任务,以便仅向相应的用户提供对 Web 界面的访问权限。作为重新架构的一部分,建议采用类似于 “
一些可以提供帮助的工具
我们刚刚研究了在两个不同的安全事件中限制权限是如何起到帮助作用的。现在,让我们考虑一下什么可以帮助您决定如何将您的 IAM 权限降低到适当的级别。有许多资源讨论不同的方法:
第一种方法是使用访问分析器根据来自日志数据的访问活动帮助生成 IAM 策略。然后,可以通过根据需要添加
-
IAM 访问分析器通过根据访问活动生成 IAM 策略,可以更轻松地实现最低权限权限 -
使用 IAM 访问分析器根据组织跟踪中发现的访问活动生成 IAM 策略
第二种方法类似,即根据上次访问的信息缩小策略范围:
-
查看上次访问的信息以识别未使用的 EC2、IAM 和 Lambda 权限,并收紧您的 IAM 角色的访问权限
第三种方法是手动创建和完善策略以减少所需工作量的方法。为此,您可以先使用适当的
平衡工作量和权限的一个示例是 IAM 教程
除了限制权限外,我们还建议您设置适当的检测和响应功能。这将使您能够知道问题何时发生,并提供控制问题和从问题中恢复的工具。有关在 亚马逊云科技 账户中执行事件响应的更多详细信息,请参阅
结论
在这篇文章中,我们看了两个示例,其中限制权限在安全事件期间提供了积极的结果。在第二种情况下,所使用的策略可能应该进一步限制权限,但即便如此,它还是阻止未经授权的用户实现其假定目标的有效预防性控制措施。
希望这些故事能够为您的组织对设置权限的看法提供新的见解,同时考虑到创建权限所做的工作。这些故事很好地说明了如何开始实现最低权限的旅程可以帮助阻止未经授权的用户。这两种情景都没有最低权限的策略,但是这些策略足够严格,以至于这次未经授权的用户无法实现其目标,因此对客户的影响微乎其微。但是,在这两种情况下,亚马逊云科技 CIRT 都建议进一步缩小所使用的 IAM 策略的范围。
最后,我们提供了几种减少权限的方法——首先,使用工具来协助创建策略,其次,编辑现有策略以使其更好地满足您的特定需求。首先,您可以根据 A
如果您对这篇文章有反馈,请在下面的 评论 部分提交评论。如果您对这篇文章有疑问,
想了解更多 亚马逊云科技 安全新闻?在