Amazon web services 为什么我应该使用IAM角色？

请帮助我理解为什么AWS建议将角色分配给EC2实例（“基于角色的方法”） 在实例上的文件中过度存储API密钥（“基于文件的方法”）

考虑三个用例： （i） 在运行web应用程序的实例上有一个“tomcat”帐户。该应用程序不使用AWSAPI。 实例上还有另一个帐户（“支持”），它使用AWS API进行内务管理和维护 （日志、指标等）

使用基于文件的方法，如果攻击者利用应用程序并访问文件系统（作为“tomcat”）， 他们将无法读取凭证文件（只能由“支持”读取），也无法进行AWS API调用。 如果攻击者在“tomcat”帐户下执行任意代码，情况也是如此

然而，使用基于角色的方法，如果攻击者能够访问文件系统，他们将一无所获 （因为根本没有凭证文件）并且他们无法调用AWS API。但是如果攻击者能够执行任意代码 他们可以调用API

（ii）有一个运行web应用程序的“tomcat”帐户。应用程序调用AWS API进行操作。 还有另一个帐户（“支持”），它使用AWS API进行内务管理和维护。 两个帐户都需要访问不同的资源（例如，“tomcat”需要S3，而“support”需要日志和指标）

在基于角色的方法中，分配给实例的角色将有效地包含权限的并集 “tomcat”和“support”需要，这违反了最小特权原则。即使权限是 在技术上分为两个角色，每个帐户最终将能够承担一个它并不真正需要的角色

使用基于文件的方法，如果攻击者获得对文件系统的访问权，他们将能够读取“tomcat” 凭据并从另一台计算机进行API调用（这可以通过限制策略来避免 到特定的源IP，尽管维护起来会很麻烦）。如果攻击者执行任意 代码，他们将能够从EC2实例进行API调用。在这两种情况下，“支持”账户将保持不变 受操作系统保护

使用基于角色的方法，如果攻击者获得对文件系统的访问权，则攻击者在API调用方面将一无所获， 因为根本没有凭证文件。但是，如果攻击者执行任意代码，他们可以进行API调用 代表两个角色（“tomcat”和“support”）从instace获得

（iii）有一个运行web应用程序的“tomcat”帐户。应用程序调用AWS API进行操作。 没有从实例进行其他API调用

使用基于文件的方法，如果攻击者获得对文件系统的访问权，他们将能够读取“tomcat” 凭据并从另一台计算机进行API调用（这可以通过限制策略来避免 到特定的源IP，尽管维护起来会很麻烦）。如果攻击者执行任意 代码，他们将能够从EC2实例进行API调用

使用基于角色的方法，如果攻击者获得对文件系统的访问权，则攻击者在API调用方面将一无所获， 因为根本没有凭证文件。但是，如果攻击者执行任意代码，他们可以进行API调用 从实例中

因此，似乎推荐的基于角色的方法实际上增加了案例（i）和（ii）中的风险

---

我在这里缺少什么？

如果您在Amazon EC2实例上有多组用户，每个用户都需要不同的IAM权限，那么通过向EC2实例分配IAM角色来提供凭据是不合适的

通常，建议使用Role方法，因为凭据不会存储在任何位置。存储在磁盘上的凭据有时会意外地签入源代码存储库。能够创建磁盘卷快照的用户也可以访问这些快照，然后可以将这些快照附加到其他实例以访问配置文件并避免正常的安全性。这表明，使用最小权限也很重要，只为IAM用户提供他们工作所需的特定权限，而不是更多权限

为实例分配角色需要

ec2:PassRole

权限，因此也必须谨慎地授予权限，以确保用户不会为自己分配授予访问AWS服务过多权限的角色

---

底线：您一直在思考安全问题，这真是太好了。遵循您认为最适合您的业务需求的流程。

我必须跟踪实际的AWS推荐，但我记得的是，结合EC2角色访问，您应该创建基于IPTABLE的角色，这些角色只限制访问169254.169254的帐户，只有那些应该访问它的帐户，因此，在上面的场景中，“tomcat”用户将无法访问169.254.169.254，这将使该用户无法发现ec2 IAM角色凭据。使用基于文件的方法，除非您使用其他系统访问和获取/旋转凭据，否则您的凭据只创建一次，不会更改，因此，如果一个参与者能够访问您的凭据，那么它们将永远是好的——如果一个参与者能够访问ec2实例并复制访问代码，那么它们只能持续一段时间