介绍
每个使用过 Amazon Web Services (AWS) 的人都知道，云环境有一种独特的方式来授予用户和资源的访问权限。这是通过允许用户和/或资源临时承担角色来完成的。由于分配给这些角色的信任策略，这些类型的操作是可能的。信任策略是附加到 AWS 环境中每个角色的文档。本文档描述了允许哪些用户、组、角色和/或资源临时承担角色以执行操作。
信任策略对于临时授予用户或资源的特定访问权限非常有用。他们为角色添加了一层保护，以避免被对手滥用。信任策略最常用于以下四种情况之一：
- 允许 AWS 服务访问另一个 AWS 服务
- 允许两个 AWS 账户之间的跨账户访问
- 允许第三方 Web 身份访问 AWS 账户
- 作为单点登录身份验证的一种方式
信任策略的好处和危险
信任策略有许多可能的实现。以下是信任策略及其用例的两个示例。
示例 1：创建一个可以访问 lambda 函数的角色。制定了此角色的信任策略，以便每个人都可以访问此角色（使用“*”通配符）。当网站具有计算独特的东西的 lambda 函数时，可以使用此方法，每个人都应该能够使用。
示例 2：有两个 AWS 账户，其中一个用于运行公开可用的应用程序，另一个用于对其他 AWS 账户进行安全监控。在此设置中，公共 AWS 账户中有一个 lambda 函数，它将所有日志从公共账户推送到日志记录 AWS 账户。为此，在安全监控 AWS 账户中创建了一个角色，该角色可由公共账户上的 lambda 函数承担。
图 1：示例 2 的设置示意图
上述两个示例的信任策略都存在一些基本问题。在示例 1 中，我们允许任何人和所有事物访问我们的 lambda 函数。因此，代码中的任何错误都可能被利用，并可能导致 AWS 账户的初始立足点。更重要的是，如果角色的权限不限制对单个 lambda 的访问，那么任何人都可以访问 AWS 账户中的任何 lambda 函数！
更有问题的是，有一种攻击技术使用信任策略来允许外部枚举目标环境中的用户和角色。攻击者甚至不需要访问此环境即可枚举用户和角色的名称。攻击的核心依赖于以下内容：攻击者在其环境中具有一个角色，并附加了一个初始信任策略。通过更改信任策略，他们可以尝试允许或拒绝目标用户或角色访问他们自己的角色。如果更改导致错误，则用户或角色不存在。同样，如果更改成功，则用户或角色存在。攻击者通常在野外使用它来枚举角色并尝试承担发现的角色。在示例 1 中，由于信任策略允许任何人访问该角色，
在示例 2 中，我们将假设攻击者已经在 AWS 账户中建立了初始立足点。现实生活中的场景可能是一个妥协或不满意的程序员，他们可以选择修改 lambda 函数。因此，可以滥用 lambda 函数的任何权限来获取有关安全监控 AWS 账户的更多信息。因此，单个权限问题可能会被滥用，并对这个敏感环境造成灾难性后果。
图 2：对示例 2 执行的攻击示例
信任策略的最佳实践
信任策略允许用户或资源访问 AWS 账户内的一组特定权限。因此，定义明确的界限以避免对手滥用角色非常重要。信任策略的最佳实践是限制有权访问它们的资源、用户、组和角色。不惜一切代价避免使用“*”通配符，并将角色的访问权限限制为 AWS 账户中的单个服务或单个组。如果我们回顾示例 1，更好的实现是只允许网站访问 lambda 函数。这样，所有流量都可以先被网站过滤掉，然后再发送到 lambda 函数。
总体而言，最好避免使用跨账户信任策略，因为它们允许 AWS 账户之间的横向移动。但是，由于这并不总是可行的，因此遵循最佳实践可以帮助您更好地保护您的 AWS 账户：在设置跨账户信任策略之前，首先确定两个账户中最敏感的一个。该帐户将执行该操作，因为这是最受信任的帐户。如果我们想重新设计示例 2，我们可以在安全监控 AWS 账户中设置一个函数，而不是公共 AWS 账户。然后，此函数将有权访问公共 AWS 账户上的角色，并将该账户中的数据提取到它自己的账户中。
图 3：示例 2 的“更好”解决方案示例
结论
使用信任策略允许许多机会和复杂的设置。然而，有很多可能性也带来了很多责任。因此，在实施信任关系之前对其进行适当的规划非常重要。
设置信任策略时，请始终确保该策略适用于尽可能少的用户或资源。还要确保更敏感的资源或帐户对不太敏感的资源和帐户执行操作。确保在所有情况下都将最低权限原则应用于您的角色。
本文为译文，原文链接：https://blog.nviso.eu/2022/10/25/the-dangers-of-trust-policies-in-aws/
