服务
关于
CloudProse博客

2017年10月24日星期二

在Trek10上,运行24/7 CloudOps支持服务的一大好处是,我们经常必须自己解决AWS上的问题,然后利用我们的经验为客户实施相同的解决方案。在这种情况下,这是一个安全性挑战:我们如何在一系列广泛的AWS账户中平衡最小特权原则和合理的生产力水平?我们认为我们提出了一种有趣的方法;在这篇文章中,我将介绍这种方法的原理。

如果您还不熟悉AWS IAM的基本概念,包括用户,组,策略和跨账户角色,请先阅读这些内容。 这是一个很棒的概述。 IAM公认的最佳做法是将用户集中在一个特殊的“仅IAM” AWS账户中,或者通过AWS外部的某些用户存储和SSO服务(即Active Directory或Okta)进行集中,然后将跨账户角色用于各种访问级别以访问您组织的AWS账户。该方案如下所示:

该系统为您提供明确划分的访问级别,将攻击面限制为一次登录,并留下一个不错的访问审计记录,您可以将其用于通知或警报。

但是,这一最佳实践掩盖了一个重要点……您如何定义哪些用户可以担任哪些角色?对于拥有少量AWS账户的小型团队来说,这可能不太重要……只需根据作业功能选择访问级别并根据需要进行调整。但是对于拥有许多AWS账户的大型团队来说,这是一个关键问题。用真正的最小特权原则很难定义谁需要什么访问权的先行者。

默认的响应是使用户越来越多地获得全面的访问权限,以承担许多帐户中的许多角色,结果是安全性很差,远远没有特权。

我们的解决方案

这就是我们的解决方案所在的位置:临时标高。批准者可以临时授予用户各种帐户中各个级别的角色。此批准已得到严格保护,并记录了批准说明。最重要的是,每个角色假设许可都是临时的,并附有到期期限。我们允许有效期最长为几周,但是,如果您只需要当天访问权限,那便是您所需要的。

审批权限在这里很重要,因此我们对如何确保这一点进行了很多考虑。 批准者具有仅附带一个许可权的IAM策略:执行一个处理批准的Lambda函数。 这些相同的用户也有 IAM政策 强制执行MFA限制和IP限制。为了确保批准者不会自行升级,我们实施了一个真正定额的系统,其中没有一个用户可以自行升级;成功升级需要两个用户。这加上通常的访问密钥/秘密密钥,使我们总共获得了三个完全不同的身份验证因素。

此外,由于AWS Lambda没有执行人员的进程内上下文(Lambda产品团队,ahem ahem),因此我们开发了一个附加系统,用于确认功能内部的批准者身份,以便我们可以确定批准者的身份准确记录。

还有一点很重要…… 当然,因为我们是Trek10,所以整个系统都是无服务器的。运营成本微不足道,所有基础架构都是代码定义的且可重复的,并且减少了攻击面,并且没有长时间运行的进程可能被黑客入侵。

如果您可能想让Trek10为您实现此解决方案,或者有任何疑问或意见,请通过Twitter或@ trek10inc与我们联系 [email protected].

作者
安迪·沃宗(Andy Warzon)Trek10
安迪·沃宗(Andy Warzon)

创办人& CTO

创办人&CTO Andy一直在AWS上进行开发已有十多年,并且是AWS认证解决方案架构师-专业人士。