掌握AWS身份和访问管理

今天，我们很高兴地介绍我们的第二个开源项目--AirIAM，它使用基础设施即代码来管理AWS IAM。🎉。

AWS Identity and Access Management(IAM)是一项AWS服务，它允许或拒绝每项服务、服务器或用户在AWS中的每项操作。这项服务内在地嵌入到云中的每个部署中，处于多个级别，这需要高度的抽象性和灵活性。

管理不善和配置不当的IAM可能会导致许多安全风险，例如使用受损权限的帐户接管或比特币挖掘攻击、使用过高权限角色的数据泄露等等。

作为Bridgecrew的解决方案架构师，我每周都会看到数十个AWS客户。这些帐户的结构各不相同-一些使用Kubernetes，另一些使用无服务器架构，还有一些仍然实施“简单”的vPC-EC2设置。不管结构如何，他们都有一个共同的担忧：

“我们的IAM很复杂，可能都是垃圾。你能帮我们解决一下吗？“。

在过去的几个月里，我们帮助我们的客户做到了这一点，因此我们开始发现AWS IAM设置中出现的这些反复出现的安全问题：

通过定期验证附加了AdministratorAccess策略的人员，您可以随时准确了解哪些人员对您的AWS帐户具有完全访问权限。即使您在IAM方面非常严格，将如下所示的简单策略附加到任何角色/用户都可以在AdministratorPolicy完全不知情的情况下授予他们完全访问权限！

就连我们都对此感到内疚。六个月前，我们制定了一个明确的规则，即所有员工必须对其IAM用户使用多因素身份验证(MFA)。随着时间的推移，我们引进了新的工程师，其中只有一部分人建立了MFA。要找出差距，我必须转到AWS控制台或使用API主动找出谁是违规者。即使我们迁移到Single Sign-On以避免完全使用IAM用户，我们仍然需要定期检查是否没有创建IAM用户。这是非常单调乏味的。

4.无法知道某一特权是否正在实际使用。

尤其是在云中，情况会发生变化。过去在EC2上运行的东西转移到了ECS，数据从DynamoDB移动到另一个数据库，甚至可能您的某个员工更换了团队，需要一组与他拥有的权限不同的权限。这种流动性使得人们很难知道某项特权是否真的在使用，这与最低特权原则形成了鲜明对比。

在Bridgecrew，我们喜欢为重复和乏味的问题提供自动化解决方案。我们也热爱开源--我们是Checkov的创建者，也是许多其他开源工具的贡献者。为了将这两种热情结合起来，我们决定构建一个新的开源工具，通过将其转换为Terraform来帮助管理AWS IAM。

标识相关用户、组或角色未使用的策略附件。

通过使用Terraform并利用您的版本控制系统(VCS)确定IAM配置中的漂移和更改。

通过将分析时间最小化到几分钟，并允许与相关利益相关者在他们已经了解并喜爱的工具中进行协作，减少IAM调整所需的时间。

AirIAM的工作方式是直接从AWS IAM&；Access Advisor API查询您的配置和使用数据。从那里，您可以将其结果输出到CLI，也可以输出Terraform代码，一旦由您运行，它将修复您的IAM设置。

PROMENT_GROUPS根据find_unussed的输出为现有IAM用户创建访问组。

TerraForm创建地形代码和地形状态以简化移植。这可以考虑前面命令输出的未使用的实体和/或组！

使用基础设施即代码来管理AWS IAM可以提供许多优势，包括最低权限分析、识别不良操作规范和大规模修复错误配置。要开始使用AirIAM，请访问文档或在GitHub上查看-非常感谢您的贡献！

Bridgecrew的平台在运行时和构建时持续查找并自动修复云基础设施错误配置。在bridge gecrew.io开始使用免费帐户吧。🚀