AWS STS 使用案例和优势

Question

我对 STS 的用例和优点感到困惑。根据文档，它是临时获取一个角色来执行 AWS 中 IAM 用户或服务无法执行的任务。请注意，我说的是编程访问（不是控制台访问）

例如，IAM 用户可能没有 S3 权限。据我的理解：

1. 他可以通过联系AWS STS来获取临时访问密钥/令牌，并获取S3的访问密钥和秘密。

2. 有了这些临时凭证，他就可以访问 S3。

我的问题是：

1. 要从 AWS STS 获取临时凭证，他仍然需要现有的访问令牌（永久）和秘密，对吧？

2. 如果他现有的访问令牌和秘密被泄露，攻击者仍然可以使用它首先从 STS 获取临时凭证，然后访问 S3，对吧？据我所知，攻击者将无法使用他的永久访问令牌和秘密直接访问 S3。

我正在尝试了解其正确的用例。我知道我很困惑，但也许我在循环思考。

提前致谢。

Answer 1

他们不太“联系AWS STS并获取S3的访问密钥和秘密”。相反，他们调用AssumeRole()有权访问 Amazon S3 的 IAM 角色。然后，使用返回的临时凭证，他们可以访问 S3。

您的困惑似乎主要集中在 IAM 角色的用例上。我喜欢用故事的方式来解释它...

我在办公室担任消防员。如果火灾警报器启动，我会走到橱柜前，戴上红色头盔，然后在办公室里走动，引导人们到楼梯间。由于警报响起并且我戴着红色帽子，人们（大多数）都会按照我告诉他们的去做。然而，如果是正常的一天，没有警报响起，而且我没有戴红帽子，我让他们从楼梯间退出办公室，他们很可能会用奇怪的眼神看着我，并忽略我的要求。不同的是，我扮演了消防员的角色，这给了我额外的权限。

所以，作为一个正常人，我不能命令别人离开办公室。然而，一旦我承担了这个角色，我就拥有了额外的权限。

对于 IT 系统来说，这也是一个很好的实践。您公司的系统管理员可能拥有您的 AWS 账户执行任何操作的权限。然而，对于他们来说，在日常工作中使用具有此类权力的帐户将是一种不好的做法。相反，他们的 IAM 用户帐户应该只具有正常权限，但是，如果他们想要执行管理员类型的操作，他们可以承担管理员角色，然后执行强大的操作。当他们完成后，他们应该退出角色并继续作为普通用户。这“更安全”，因为当他们是“普通用户”时，他们不会意外地做一些强大的事情。

Amazon Security Token Service (STS) 还用于为在 Amazon EC2 实例上运行的软件提供权限。在这种情况下，IAM 角色被分配给 EC2 实例，并且 EC2 服务代表该实例“承担”该角色。然后，它通过 EC2 实例元数据服务提供临时凭证。在此示例中，没有 IAM 用户担任该角色。相反，EC2 服务代表实例假定它。

STS还可以提供跨账户的权限。例如，账户 A 中的 IAM 用户可以调用AssumeRole()账户 B 中的 IAM 角色。如果他们有权执行此操作，那么他们将获得与账户 B 关联的临时凭证。这是必需的，因为来自一个账户的凭证可以切勿用于管理另一个帐户中的资源。

使用临时凭证还有其他原因，例如使用 MFA 令牌、没有 IAM 用户的联合登录以及减少您自己的权限集。