IAM角色的使用被吹捧为获得EC2实例凭据的首选方式,这样它就可以与AWS API对话。我知道密钥是临时的,可以轮换,这与使用存储在磁盘上的凭证相比有明显的优势。然而,它引入了另一个严重的安全问题,这是通过在磁盘上使用加密凭据来避免的。
如果我的凭证在文件系统上,我可以使用文件系统的内置权限机制来防止除需要密钥的进程以外的任何进程读取它们。在这种情况下,如果有人使用与需要访问AWS API的用户不同的用户身份运行的软件中的某些漏洞来危害实例,则他无法读取包含凭据的文件(由操作系统强制执行)。(我没有考虑他可以提升到root访问权限的情况,在这种情况下,所有的赌注都是无效的)。
但是,在使用IAM角色时,凭据可通过网络调用获得:
http://169.254.169.254/latest/meta-data/iam/security-credentials/*.
任何进程,甚至是那些几乎没有权限的进程,都可以对这个URL执行wget (或curl等),并拥有随时可以使用的凭据。它们轮换的事实并不能使这个场景更安全。
在这里,我能想到的唯一补救方法就是使用本地防火墙来限制哪些进程可以访问IP地址169.254.169.254。这看起来既笨拙又不优雅。
在使用IAM角色时,是否有建议的方法来解决此安全问题?
发布于 2013-11-18 01:39:01
考虑IAM角色的方法是将权限授予实例,而不是流程或用户。如果您的实例具有不应具有特权的用户或进程,则不应通过IAM角色提供该特权。
我们通常不会将实例用作通用机器,而只是用于特定的应用程序目的。对于这种用例,IAM角色比创建具有固定凭据的IAM用户并将凭据放在实例上要好得多。在任何一种情况下,接管实例的入侵者都可以使用它来获得我们赋予该实例的任何权限。但使用角色时,入侵者无法将这些凭据拿走,并在较长时间内单独使用它们,因为凭据过期且频繁轮换。入侵者必须维护实例的所有权和存在,才能损害角色,如果入侵者可以做到这一点,您就失去了所有的安全性。
我们还通过CloudFormation堆栈创建IAM角色和新实例,这允许每个实例具有所需的权限,而不是其类型的所有实例的一组通用权限。
https://stackoverflow.com/questions/20025044
复制相似问题