A sample Translation Work

Yeqing July 14, 2019, 9:05 p.m.

Translation essays


Mastermind,完美解决AWS访问管理问题 ——带您解锁Mastermind如何完美平衡AWS的安全性和易用性

原文链接: https://medium.com/driven-by-code/mastermind-an-elegant-secure-aws-access-management-solution-7afc83225fb8 作者: Dan Reed 和 Eric Slick 出版商: Medium 日期: 2019年7月3日 翻译者:柳叶青 原文字数:1514 译文字数:2811

每个网络都有一个大问题:如何平衡安全性和易用性。通常,网络越安全,管理和使用就越困难。相反,管理和使用的解决方案越容易,它往往越不安全。在AWS的访问管理方面人们会遇到类似的问题,于是我们试图用Mastermind去找到安全性和易用性之间的最佳平衡点。事实上,它是一个令人惊喜的优雅解决方案,为我们提供了两全其美的办法。我们将向您展示为什么Mastermind是一个完美解决方案以及它是何如达到这个平衡点的。

简单的集成示例 在Mastermind中,当新应用程序需要访问AWS资源时,该应用程序只需向其源添加一个Access-Request文件,该文件定义了应用程序所需的特定AWS资源。该文件可能如下所示:

“common”部分将应用于所有环境中的部署,“prod”部分将仅应用于prod。这意味着所有环境都将对“arn:aws:s3 ::: example-app-bucket / *”进行“s3:GetObject”访问,但除了“s3:GetObject”之外,只有prod将具有“s3:PutObject”。

这就是所有我们需要做的。我们将向您详细地解释如何运行Mastermind。但在此之前,先带您了解一下在使用Mastermind之前网络访问控制是如何操作的。

“曾经的坏日子” 多年来,我们实施了多种方法来管理应用程序对AWS资源的访问。没有任何一个是“理想的”。安全性是最首要的需求,但我们提出的所有合理的管理方案都缺乏安全性。如果仅从安全性出发选取可行的管理方式,它们跟其他应用程序一起运行的时候或者更换环境后会变得笨重难以运行。

更糟糕的是,我们最终得到了多个解决方案,需要在组织中的多个架构内执行。于是我们意识到我们需要改变思路,寻找其他解决方案。

因此,我们开始设计一个可以替代它们的单一访问系统。我们想要的新系统需要满足以下特性:

  1. 坚持最小特权原则,这意味着访问应尽可能紧密地适应应用程序的要求(安全性)。
  2. 取消访问密钥的使用,尤其是共享密钥和长期密钥(安全性和可管理性)。
  3. 减少授予必要访问权限所需的人工工作量(易用性和可管理性)。
  4. 使软件集成尽可能无缝衔接(易于使用)。

第一版 我们首次尝试的解决方案是静态访问密钥。这种方法的主要问题是管理和安全性。因为密钥需要存储和轮换,这是管理上的一个负担。此外,开发人员可以轻松地重复使用密钥,这使得记录使用这些密钥几乎不可能。

我们知道如果将管理和密钥分开,限制密钥的使用权限,我们可以在一定程度上解决此类问题。但这会增加我们的管理费用,因为SRE需要维护应用程序和内容。换句话说,我们在解决一个问题的同时创造了另一个问题。

第二版 然后我们决定使用角色。这最终产生了与密钥创建类似的问题,因为它也需要对管理进行大量的维护。它让我们知道是谁在使用哪些角色,从而防止角色重用。但是,SRE仍在手动创建、分配和更新角色。也就是说,增加安全性使管理变得更加困难。整个探索过程就像一个打鼹鼠的游戏。击中安全性,易用性受到影响。但是保证易用性就会让管理问题变得棘手。也许这个问题是无解的。

顿悟时刻 之后一个简单的想法改变了这个困境。有谁会比应用程序的开发人员更了解应用程序所需要的访问权限呢?既然如此,那为什么不授权开发人员决定他们需要哪些访问权限呢?

从那一刻,我们从才开始从正确的角度思考这个问题。如果我们可以直接地让应用程序声明它需要访问哪些资源,那么系统可以使用更适当的角色来连接这些资源。

这个想法意味着应用程序将不再需要选择用什么角色。开发人员只需要定义一个简单的文件包含其开发的程序所需资源的访问。然后,Mastermind可以找出相应的内容来连接应用程序和所需资源。这启发了我更多的想法:我们能否将Mastermind自动化并完全消除人为干预的需要?事实证明,我们完全可以做到。

这一切是如何运作的? 我们大可以挥挥手轻松地说:“它就是有效。”但这不是魔术,没有那么简单,所以让我们从一个需要资源的新应用程序的角度来解释它。

任何新应用程序请求访问的第一步是创建访问请求文件。如前所述,它看起来像这样。

下一步是在部署应用程序期间发生的。在我们的例子中,我们使用Spacepods进行部署。Spacepods读入Access-Request文件并可能加入环境信息。然后它将此数据传递给Mastermind。

一旦Mastermind接收到Access-Request文件的内容,它就会做三件事。 首先,它会构建访问所请求资源的必要角色。然后,它会生成一个AWS CLI配置文件,描述他们访问的角色和资源。生成的AWS CLI配置文件如下所示:

此AWS CLI配置文件具有“默认”部分,用于定义可以访问所有本地资源的角色,以及应用程序请求访问的任何远程环境(其他AWS账户中的资源)的特定于环境的部分。

此时,Mastermind将AWS CLI配置文件返回给Spacepods。Spacepods然后将该文件添加到应用程序的容器设置中。因此,当应用程序转动时,AWS CLI配置文件将被添加到容器中。

这意味着当应用程序加载AWS SDK(或任何知道此配置文件的库)时,便可以立即获得访问所请求资源所需的所有权限。所有这些,都不需要应用程序或者引用角色。以下Ruby示例设置对两个不同存储桶的访问。

如果未指定配置文件,则使用默认值,这意味着如果我们仅访问容器本地的资源,则根本不需要指定配置文件。在我们请求访问不同帐户中的资源的情况下,我们需要指定配置文件(“prod”)。

易于管理 Mastermind的主要功能是获取AWS资源和相应操作的列表,然后创建授予对所请求资源的访问权限的角色。以下是关键部分的高级概述:

如前文所述,应用程序定义其Access-Request文件,然后使用我们自己的工具Spacepods部署应用程序。

Mastermind充当黑盒子来创建角色并将它们链接到应用程序。它向Spacepods返回一个AWS CLI配置文件,该文件在旋转时插入应用程序的容器中。然后,AWS SDK使用该文件为应用程序提供对所需AWS资源的访问权限。

所有这些自动化的过程大大减少了对管理角色和应用程序的需求。应用程序定义它想要的资源这一事实进一步简化了管理。该应用程序索取自己所需的资源,所以,它一定是正确的。

但是,并非一切都是自动处理的。每次应用程序决定需要访问新资源时,都会引入手动步骤。在这种情况下,Mastermind将通过Slack向相应的人发送批准请求。一旦获得批准,SRE就会收到通知,他们会按下一个按钮,让Mastermind发挥其魔力。你看,整个过程真的很复杂!

等等!不仅如此,它还真的很安全! 访问是针对每个应用程序定制的,所以只有实际使用的资源是公开的。Spacepods充当应用程序请求资源和Mastermind之间的可信中介,同时也是构建和部署应用程序容器的唯一方式,因此我们可以安全地控制构建角色和将AWS资源连接到应用程序的整个过程。

开发人员永远不会直接接触或了解AWS角色。从技术上讲,他们可以找出他们的应用程序使用的角色,但这些角色在创建它们的容器之外是无用的。这是因为每个角色都是直接绑定到运行应用程序的容器。

它是真的很简单而优雅 应用程序开发人员只需创建一个Access-Request文件即可访问AWS资源。不涉及任何角色或密钥。他们需要的一切都是由Mastermind通过Spacepods为他们自动生成的。几乎消除了所有手动管理(存在一个可操作的按键)。而与此同时安全性不会受到影响。

这就像我们最后根除了脸上的痣一样。 Mastermind是一个真正意义上的简单、优雅和安全的AWS访问管理解决方案。

最后,感谢瑞吉斯威尔逊校正这篇文章的初稿。

Keywords
0 likes

Related articles

为什么我们不建议国内的翻译做外语互译?

Desiderata / 生命之渴求

留学文书作品展示-传媒

留学文书展示-语言学专业

东哥在美国的事情传开以后,我们连陪同口译都不好找了!

留学文书展示-时尚设计专业


Most liked articles