两个关于限制权限为何起作用的真实示例：来自 亚马逊云科技 CIRT 的经验教训

欢迎阅读 亚马逊云科技 客户事件响应小组 (CIRT) 的另一篇博客文章！在这篇文章中，我们将从一个经常讨论但有时被误解的话题（ 最小权限）的角度来看团队参与的两项活动。 具体而言，我们考虑的想法是，在现实生活中的用例中减少权限的好处并不总是需要使用绝对最低的权限集。相反，您需要权衡创建和维护权限的成本和工作量与所实现的风险降低，以确保您的权限适合您的需求。

引 用亚马逊安全 副总裁兼杰出工程师 Eric Brandwin e 的话 ，“最低权限等于最大的努力。”这种想法是，创建和维护执行给定任务所需的尽可能少的权限集将需要付出最大的努力，尤其是在客户需求和服务功能随着时间的推移而发生变化的情况下。但是，工作量与权限减少之间的关联不是线性的。因此，你应该问的问题是：如何平衡削减权限的努力与它提供的好处？

不幸的是，这不是一个容易回答的问题。您需要考虑意外问题发生的可能性、该问题如果确实发生所产生的影响，以及防止（或检测并从中恢复）该问题所花费的成本和精力。您还需要在决策过程中考虑诸如业务目标和监管要求之类的要求。当然，你不需要只考虑一个潜在的问题，而是需要考虑很多问题。通常，从一组粗略的权限开始，然后在逐渐了解所需的安全级别时对其进行细化可能会很有用。 如果您使用的是 亚马逊云科技 Organizati ons，则还可以使用 服务控制策略 (SCP) 来提供一组权限防护。 在这篇文章中，我们讲述了两个真实的故事，其中通过限制安全事件的影响来限制A WS身份和访问管理 (IAM ) A ccess Management 权限起到了作用，但权限集却没有付出最大的努力。

故事 1：寻找证书

在这篇亚马逊云科技 CIRT故事中，我们看到了威胁行为者如何无法实现其目标，因为他们获得的访问权限（数据库管理员的访问权限）没有他们想要的IAM权限。

背景和 亚马逊云科技 CIRT 参与度

一位客户在本地系统和某些 亚马逊云科技 账户中发现了未经授权的活动后来找我们。他们具备事件响应能力，正在寻找另一批具有 亚马逊云科技 知识的人手来帮助他们进行调查。这有助于让客户的员工腾出时间专注于本地分析。

在我们参与之前，客户已经进行了初步的封闭活动。这包括轮换证书、吊销临时证书和隔离受影响的系统。他们还很清楚威胁行为者访问了哪些联合用户帐户。

每个 亚马逊云科技 CIRT 互动的关键部分都是客户的要求。我们团队所做的一切都属于 亚马逊云科技 分担责任模型 的客户方面 ，因此我们要确保我们与客户的预期结果保持一致。问题很明确——审查潜在的未经授权的联合用户的访问权限，并调查这些用户在已知时间段内采取的有害的 亚马逊云科技 操作。为了更好地了解什么是 “不想要的”，我们与客户进行了交谈，以便从较高的层面上了解平常的一天会给这些用户带来什么，并了解预期会采取什么样的行动的背景信息。用户主要专注于使用 亚马逊关系数据库服务 (RDS) S ervic e。

分析和发现

在故事的这一部分中，我们将重点关注一个联合用户，我们调查了该用户的明显行为，因为威胁行为者没有以有意义的方式冒充其他联合用户。我们知道需要重点关注的大概开始和结束日期，并发现威胁行为者采取了许多不必要的行动。

在审查了这些行为后，很明显，威胁行为者在2小时内曾三次进行控制台登录。每次，威胁行为者都试图执行以下操作的子集：

• 创建访问密钥 — 创建新的 亚马逊云科技 私有访问密钥
• createLoginProfil e — 为给定的 IAM 用户创建控制台密码
• updateAccessKey — 将访问密钥从非活动更改为活动状态（反之亦然）
• DeleteAccessKey — 删除访问密钥 对
• putrolePolicy — 添加或更新内联 IAM 策略
• createPolicyVer sion — 创建现有托管策略的新版本

注意： 此列表仅包括在 亚马逊云科技 CloudTrail 中显示为 ReadOnly = false 的操作，因为这些操作通常（但并非总是）影响更大，有可能改变 亚马逊云科技 环境。

这就是权限限制的好处变得显而易见的地方。编译此列表后，我们注意到列出 的所有 操作都有两个字段：

"errorCode": "Client.UnauthorizedOperation",
"errorMessage": "You are not authorized to perform this operation. [rest of message]"

正如这所揭示的那样，由于联合用户账户没有所需的 IAM 权限，威胁行为者尝试的每一次非 ReadOnly 操作都被拒绝。

客户沟通和结果

在我们确认调查结果后，我们与客户进行了电话讨论结果。可以想象，他们很高兴结果显示出对他们的数据没有实质性影响，并表示当时无需进行进一步的调查或采取行动。

联合用户拥有的 IAM 权限有哪些，这些权限阻止了威胁行为者尝试的一系列操作？

答案实际上并不涉及用户完成工作所需的绝对最低权限集。仅仅是联合用户的角色没有针对威胁行为者尝试的 IAM 操作的 Allow 语句——他们的工作不需要他们。如果没有明确的 Allow 语句，尝试的 IAM 操作会被拒绝，因为 IAM 策略默认为拒绝。在这种情况下，仅仅没有所需的 IAM 权限就意味着威胁行为者无法实现其目标，因此停止使用访问权限。我们永远不会知道他们的实际目标是什么，但是尝试创建访问密钥、密码和更新策略意味着可以合理地猜测他们正在尝试创建另一种访问该亚马逊云科技账户的方式。

故事 2：更多加密挖矿实例

在这篇亚马逊云科技 CIRT故事中，我们看到了威胁行为者无法创建额外的 亚马逊弹性计算云（Amazon EC2） 实例如何导致威胁行为者在没有实现目标的情况下离开。

背景和 亚马逊云科技 CIRT 参与度

我们的第二个故事涉及一位客户，该客户使用一个 亚马逊云科技 账户来测试一些使用 亚马逊弹性容器服务 (Amazon ECS) 的新第三方软件 。 该客户开启了 亚马逊 GuardDuty ，发现他们收到了 GuardDuty 警报，以了解与加密货币:ec2/BitcoinTool 相关的调查结果。

由于该账户是新账户，目前仅用于测试他们的软件，因此客户发现该检测与 Amazon ECS 集群有关，因此决定删除该账户中的所有资源并进行重建。这样做后不久，他们就已经建立的新亚马逊ECS集群收到了类似的GuardDuty警报。第二项发现导致客户的安全团队和亚马逊云科技被邀请来试图了解是什么原因造成的。客户的安全团队专注于审查集群上正在运行的任务，而 亚马逊云科技 CIRT 则审查了 亚马逊云科技 账户操作并提供了有关 GuardDuty 调查结果及其可能原因的见解。

分析和发现

通过与客户合作，不久我们发现客户使用的 ^第三 方 Amazon ECS 任务定义无意中向互联网暴露了 Web 界面。该接口允许未经身份验证的用户在系统上运行命令。这解释了为什么在新安装完成后不久也收到了同样的警报。

这就是故事变得更好的地方。亚马逊云科技 CIRT 对 亚马逊云科技 CloudTrail 日志的分析发现，有人多次尝试使用与亚马逊 ECS 任务相关的任务 IAM 角色的证书。大多数操作都试图通过 runInstances 调用启动多个 Amazon EC2 实例。这些操作中的每一项操作以及尝试的其他操作都失败了，出现了 c lient.unauthorized Operation 或 AccessDenied 错误消息。

接下来，我们与客户合作，了解了 Task IAM 角色提供的权限。再一次，权限本可以受到更严格的限制。但是，这次威胁行为者的目标——运行多个 Amazon EC2 实例（最有可能用于秘密的加密挖矿）——与赋予该角色的策略不一致：

{
    "Version": "2012-10-17",
    "Statement": [
        {
          "Effect": "Allow",
          "Action": "s3:*",
          "Resource": "*"
        }
    ]
}

亚马逊云科技 CIRT 建议制定策略以进一步限制允许的操作，尽可能提供特定资源，并可能增加一些条件以限制访问的其他方面（例如 最近推出的 两个条件密钥 ， 以限制可以从何处使用 Amazon EC2 实例证书）。但是，仅仅设置策略限制访问 亚马逊简单存储服务（Amazon S3） 就 意味着威胁行为者决定只带着一个运行加密挖矿的亚马逊 ECS 任务离开，而不是大量的 Amazon EC2 实例。

客户沟通和结果

向客户报告这些发现后，接下来有两个明确的步骤：首先，从他们的亚马逊云科技账户中删除现在不需要和不可信的Amazon ECS资源。其次，审查并重新架构 Amazon ECS 任务，以便仅向相应的用户提供对 Web 界面的访问权限。作为重新架构的一部分，建议采用类似于 “ 允许对 S3 存储桶中的对象进行读写访问 ” 的 Amazon S3 策略。这将 Amazon S3 存储桶操作与亚马逊 S3 对象操作区分开来。当应用程序需要在 Amazon S3 中读取和写入对象时，它们通常不需要创建或删除整个存储桶（或对这些存储桶进行版本控制）。

一些可以提供帮助的工具

我们刚刚研究了在两个不同的安全事件中限制权限是如何起到帮助作用的。现在，让我们考虑一下什么可以帮助您决定如何将您的 IAM 权限降低到适当的级别。有许多资源讨论不同的方法：

第一种方法是使用访问分析器根据来自日志数据的访问活动帮助生成 IAM 策略。然后，可以通过根据需要添加 条件 元素来进一步完善这一点。我们已经有几篇关于这个确切主题的博客文章：

• IAM 访问分析器通过根据访问活动生成 IAM 策略，可以更轻松地实现最低权限权限
• 使用 IAM 访问分析器根据组织跟踪中发现的访问活动生成 IAM 策略

第二种方法类似，即根据上次访问的信息缩小策略范围：

• 查看上次访问的信息以识别未使用的 EC2、IAM 和 Lambda 权限，并收紧您的 IAM 角色的访问权限

第三种方法是手动创建和完善策略以减少所需工作量的方法。为此，您可以先使用适当的 亚马逊云科技 托管 IAM 策略 或 亚马逊云科技 提供的示例策略作为起点。之后，您可以根据需要使用通配符添加或删除操作、资源和条件，以平衡工作量和权限削减。

平衡工作量和权限的一个示例是 IAM 教程 创建并附加您的第一个客户托管策略 。在其中，作者创建了一项在 “操作” 部分使用 iam: get* 和 iam: List: * 的策略。 尽管并非所有 iam: get* 和 iam: List: * 操作都是必需的，但这是将相似 操作组合在一起的好方法，同时最大限度地减少允许不必要访问的操作，例如，iam: Create* 或 iam: Delete*。 前面提到的另一个平衡示例 与 Amazon S3 有关 ，它允许访问创建、删除和读取对象，但不允许更改这些对象所在存储桶的配置。

除了限制权限外，我们还建议您设置适当的检测和响应功能。这将使您能够知道问题何时发生，并提供控制问题和从问题中恢复的工具。有关在 亚马逊云科技 账户中执行事件响应的更多详细信息，请参阅 亚马逊云科技 安全事件响应指南 。

在我们这里介绍的故事中，还有两项服务被用来提供帮助——A mazon Guar dDuty和 亚马逊云科技 CloudTrail 。 GuardDuty 是一项威胁检测服务，可持续监控您的 亚马逊云科技 账户和工作负载中是否存在恶意活动。这是监控 亚马逊云科技 账户中不良活动的好方法。CloudTrail 记录您的 亚马逊云科技 基础设施中的账户活动，并提供用于 亚马逊云科技 CIRT 对这两个故事进行分析的日志。确保两者都正确设置是提高 亚马逊云科技 中威胁检测和事件响应能力的重要第一步。

结论

在这篇文章中，我们看了两个示例，其中限制权限在安全事件期间提供了积极的结果。在第二种情况下，所使用的策略可能应该进一步限制权限，但即便如此，它还是阻止未经授权的用户实现其假定目标的有效预防性控制措施。

希望这些故事能够为您的组织对设置权限的看法提供新的见解，同时考虑到创建权限所做的工作。这些故事很好地说明了如何开始实现最低权限的旅程可以帮助阻止未经授权的用户。这两种情景都没有最低权限的策略，但是这些策略足够严格，以至于这次未经授权的用户无法实现其目标，因此对客户的影响微乎其微。但是，在这两种情况下，亚马逊云科技 CIRT 都建议进一步缩小所使用的 IAM 策略的范围。

最后，我们提供了几种减少权限的方法——首先，使用工具来协助创建策略，其次，编辑现有策略以使其更好地满足您的特定需求。首先，您可以根据 A ccess Analyzer 的建议 检查现有策略 ，在某些现有 IAM 策略中查找并删除过于宽松的通配符 (*)，或者实施和完善 SCP。

如果您对这篇文章有反馈，请在下面的 评论 部分提交评论。如果您对这篇文章有疑问， 请联系 亚马逊云科技 Support 。

想了解更多 亚马逊云科技 安全新闻？在 推特 上关注我们 。