访问服务:对云的临时访问

安迪李2021年6月1日

访问总是在变化。当你进入一家新公司时,根据你的团队和角色,你通常新万博app2.0下载会在第一天就获得一组应用。即使在第一天,您被授予的访问权限和您完成工作所需的访问权限之间也可能存在差异。这会导致两种结果:配置不足或配置过多的访问。

对于管理云基础设施账户的IT和安全团队来说,确保对这些账户的访问是困难和可怕的;系统很复杂,风险也很高。如果您授予过多的访问权限,您可能会允许不良行为者访问您的工具和基础设施,这最多会导致违反通知;在最坏的情况下,它会导致公司倒闭,游戏结束。新万博app2.0下载如果你给予的权限太少,你就在同事和他们需要做的工作之间设置了障碍,这意味着你正在降低公司的生产力。新万博app2.0下载

获得访问权限

初创公司和小公司通常采取的方法是允许访问。在这些公司中,早期生产力对于业务的成功至关重要。一个员工因为缺少访问权限而被锁定在系统之外,意味着生产力的损失和业务收入的损失。

如果给员工对每个系统的永久管理权限,就可以优化速度,但代价是员工账户被泄露和内部威胁带来的风险增加。这导致了增加攻击表面.随着公司的发展,新万博app2.0下载确保关键资源的访问变得更加重要,而这需要一种不同的方法。

Underprovisioned访问

如果你给员工的权限太少,就会迫使他们更频繁地请求权限。尽管新员工最初会根据他们的团队和角色获得访问权限,但新职责和新项目可以迅速增加他们需要的访问范围。根据您公司提供访问的流程,这对于请求新万博app2.0下载者、批准者或通常两者都是很麻烦的。

在Segment,我们的生产环境横跨亚马逊网络服务(AWS)和谷歌云平台(GCP)。我们需要确保这些账户的安全,这样我们的工程师才能继续快速开发和安全.在许多公司,您可能依赖于一个集中的团队来管理内部访问。虽然这是一种简单的方法,但它不能伸缩——团队成员对请求的上下文数量有限,可能会意外地过度提供请求者的访问。在Segment,我们通过构建access Service来解决管理最低权限云访问的问题:access Service是一种支持基于时间的同行评审访问的工具。

设置舞台:访问Segment

在Segment,我们在数十个SaaS应用程序和代表不同访问级别的云提供商中有数百个角色。在过去,我们必须分别登录每个应用程序或系统才能授予用户访问权限。我们的IT团队设法“联合”我们的云访问,并使用Okta作为我们的身份提供商。这为我们提供了一个单独的位置来管理哪些用户可以访问哪些角色和应用程序。这篇博文的其余部分建立在这个联邦访问系统之上。

如果您的组织还没有构建类似的东西,那么以下资源可以帮助您构建和设置自己的联邦云访问系统。

博客:

文档:

将OKTA应用程序映射到AWS角色

通过将Okta应用程序配置为云提供商角色,工程师只需点击一下,就可以通过具有适当权限的单点登录(SSO)验证云提供商。

变焦和保证金

每个OKTA应用程序都映射到“云账户的作用”(或“项目角色“对GCP)。例如,在AWS,我们有一个暂存账户与提供对特定资源的读访问权限的角色。在OKTA中,我们有一个名为“分册读取的角色”的相应应用程序,允许工程师对AWS暂存帐户进行身份验证并假设读取角色。

变焦和保证金

这需要配置一个Okta应用程序每一个“云账户角色”组合,这在写作时是150+ Okta应用。

使用Okta配置GCP略有不同,如何做到这一点的技术细节是在这个博客的底部

将OKTA组映射到SaaS应用组

除了身份验证外,身份提供者还可以帮助授权。当他们访问应用程序时,用户可以理解地沮丧,但没有正确的权限来完成他们的工作。

标识提供者已经同意使用一组公共REST api来管理配置、取消配置和组映射SCIM跨域身份管理系统。

如果应用程序支持SCIM,您可以在您的身份提供者(例如Okta)中创建组,这将把用户成员资格映射到应用程序中。通过此设置,将用户添加到Okta组将自动将他们添加到应用程序中相应的组。类似地,当用户从Okta中的应用程序中被取消分配时,他们在应用程序组中的成员资格也将丢失。

SCIM允许我们提供细粒度的、应用程序级的访问,同时使用我们的身份提供者作为真相的来源。

变焦和保证金

有了一个地方来管理我们所有云提供商的访问,这个问题应该得到解决,对吗?不太……

虽然底层的Okta应用和群组系统运行良好,但我们很快就遇到了更多的人为问题。

集中访问管理的陷阱

即使有了我们令人敬畏的新的Okta+AWS系统,我们仍然需要一个流程,让一个集中的团队通过Okta提供访问。在许多公司,这个团队是IT。在Segment,这是一个叫Boggs的人。请求将进入他的收件箱,他将手动检查请求原因,并决定是否有更适合该任务的访问级别。最后,他会去Okta管理面板,并为用户提供适当的应用程序。虽然这个系统工作了一段时间,但它是不可扩展的,并且存在重大缺陷。

变焦和保证金

永久访问

一旦应用程序被提供给用户,他们就可以访问,直到他们离开Segment。尽管拥有永久访问,他们可能不会需要永久的访问。不幸的是,我们的手动配置过程没有类似的可伸缩方式来确保在不再需要访问时删除访问。被授予一次性任务访问权限的人现在拥有了永久访问权限,这些权限在他们实际需要之后很长一段时间仍然存在。

基于有限情境的难度扩展

作为一名工程经理,Boggs对可用IAM角色及其访问级别有很强的认识。这允许他通过确定使用不太敏感的角色的机会来减少不必要的访问。这种环境很难复制,这也是为什么我们不能简单地将这种责任扩展到更大的IT团队的一个重要原因。

大多数集中的IT团队并没有与他们提供的所有应用程序紧密合作,这使得他们很难评估请求。实施最小权限原则可能需要了解特定应用程序的访问边界。没有这种知识,你将很难决定请求者是否真的需要“管理员”,或者他们是否仍然可以进行“写”权限的工作,甚至只是“读”访问。

- - - - - -来自数据工程团队的凯尔请求进入雷达管理角色进行“调试”。他们究竟需要访问什么?只读角色有用吗?等等,谁是凯尔?!他们是上周开始的吗?他们说他们需要这个权限来做他们的工作

它是缓慢的

尽管在处理访问请求方面,博格斯的装备比大多数人都要好,但他还是一个忙碌的工程经理。虽然最初提供访问是一项不常见的任务,但随着公司的发展,它开始占用宝贵的时间块,并且越来越难以理解每个请求的上下文。新万博app2.0下载

我们考虑过从IT团队中引入额外的团队成员,但这仍然需要时间,因为他们需要联系每个系统的所有者,以确认应该授予访问权限。最终,让有限的集中审批者池处理共享的请求队列会导致响应时间不太理想。

打破Boggs

博格斯根据角色和团队使用复杂的脚本规则尝试自动化问题,但仍有仍然存在的情况下违反了系统。他会如何处理Reorg,其中团队重命名,切换,合并或拆分?用户交换团队时会发生什么?当团队合法业务需要短期访问权限时会发生什么?使用该当前系统,提供的任何访问博格斯持续到永久 - 除非有人进入并手动审核OKTA应用程序进行未使用的访问。

最终,我们发现自己处于这样一种情况:我们有许多过度供应的用户,他们可以访问敏感的角色和权限。为了确保我们了解问题到底有多严重,我们测量了特权角色的访问利用率。我们查看了每个员工可以访问的特权角色数量,并将其与过去30天内实际使用的特权角色数量进行了比较。

变焦和保证金

结果令人震惊:60%的访问没有被使用。

管理长期生存的访问根本没有伸缩性。我们需要找到一种方法将我们的集中式访问管理系统转变为分布式访问管理系统。

访问服务

在真实的访问世界中,我们不应该把用户的访问占用看作是静态的,而应该把它看作是无定形的和不断变化的。

当我们采用此透视时,它允许我们构建访问服务,一个内部应用程序,允许用户获取其真正需要的访问,并避免配置提供太少或过多的失败模式。

访问服务允许工程师请求访问单一角色以获得一定的时间,并且它们的对等体批准请求。验证者来自预定义的列表,这使得类似于GitHub的访问请求过程向指定的审批人提交请求

请求一经批准,Access Service就为用户提供适合角色的Okta应用程序或组。每日cron作业检查请求是否过期,如果过期则取消对用户的配置。

在一个高级这是一个简单的Web应用程序,但让我们看起来更接近一些特定功能以及它们解锁的内容。

变焦和保证金

临时访问

访问服务的魔力是从长期访问到临时访问的偏移。通常,工程师只需要临时访问完成定义的任务。

一旦任务完成,他们就不再需要访问权限,这违反了最小特权原则。如果使用旧的流程修复这个问题,将意味着手动取消Okta应用的配置——还没有添加另一个任务到已经痛苦的工作流程手册。

使用Access Service,用户使用其访问请求指定持续时间。批准者可以拒绝批准请求,如果他们认为持续时间不必要地长期才能完成任务。这个持续时间也用于自动剥夺他们的访问权限一旦请求过期。

Access Service提供了两种类型的持续时间:“基于时间的访问”和“基于活动的访问”。

基于时间的访问具体的时间段,如一天、一周、两周、四周。这是理想的不寻常的任务,如:

  • 修复一个需要一个通常不需要的角色的错误

  • 执行数据迁移

  • 帮助客户对通常不manbetx客户端应用下载访问的生产实例进行故障排除

基于活动的访问是A.动态每次使用授予您的应用程序或角色时延长访问过期时间的持续时间。这对于日常工作功能所需的访问非常理想——没有人希望每个月都发出少量新的访问请求。然而,我们不为我们的敏感角色提供这种类型的访问。广泛访问角色或有权访问敏感数据的角色需要定期批准以维护访问权限。基于活动的访问提供了摩擦和访问之间更实际的平衡,与我们的目标一致,使我们的工程师能够快速和安全地构建

指定的审批人员

我们之前的流程最大的限制之一是必须由一个人批准所有的事情。在Access Service中,每个应用程序都有一份与系统密切合作的审批人员名单。通过将决策权委托给专家,我们确保了获得决策权的人知道谁应该拥有决策权。

首先,您不能批准自己的访问请求。(对不起红团队。)每个应用程序都有一个“系统所有者”,负责维护其批准者名单。当用户创建访问请求时,他们会选择一个或多个审批者来审查他们的请求。因为审批者列表只包含与系统密切合作的人员,审批者比中心IT团队有更好的环境和对系统的理解。

这使得审批者更容易拒绝不合理或过于宽松的访问请求,并鼓励用户请求较低级别的访问(例如,告诉他们请求只读角色而不是读/写角色)。由于传入请求在审批者之间进行了“负载平衡”,用户还可以看到对其请求的更快响应时间。

提供访问总是需要两个人,就像GitHub的pull请求一样。用户不能选择自己作为审批者,即使他们是系统所有者。Access Service还支持具有不同批准要求的“紧急访问”机制。这可以防止访问服务阻塞一个随叫随到的或站点可靠性工程师,如果他们需要在半夜访问。

通过为每个应用程序指定的系统所有者,我们的分布式批准池继续扩展,因为我们引入具有新的访问角色和级别的新工具。这就是安全社区所呼唤的“左”推

当您“左推”时,您将在开发生命周期的早期引入安全考虑,而不是在系统使用后试图对其进行改进。在软件工程领域,“左推”导致工程师学习更多关于安全性的知识。这意味着最熟悉系统的人是最精通安全修复的人。因为工程师是设计和维护软件的人,他们比中央安全团队拥有更多的上下文。类似地,Access Service减轻了中心IT团队的负担,并授权系统所有者决定谁应该在什么级别上访问他们的系统。这大大减少了IT团队用于配置访问的时间,并将他们解放出来,去做更有意义的工作。

这个怎么运作

Access Service就像我们的许多内部应用一样可以访问开放的互联网,但在Okta背后受到保护。

访问服务的基本单位是“请求”。想要访问的用户创建了一个包含四条信息的请求:

  • 他们想要访问的应用程序

  • 他们想要访问的持续时间

  • 描述为什么他们需要访问的原因

  • 审批者想要审查请求

变焦和保证金

当他们单击“请求访问”时,Access Services将发送所选批准的Slack通知。像许多现代公司一样,细分市场具有高度的松弛存在。使用此平台使访问服务更自然,更少的人们工作流程。即使用户请求访问是特定应用的批准,他们也必须从不同的审批人那里获得批准 - 每个请求必须涉及两个人。

变焦和保证金

访问请求在一个web应用程序中被跟踪,所以你可以看到你打开了哪些请求,以及你当前访问了哪些角色。

变焦和保证金

当他们的请求被批准时,请求者通过Slack通知,因此他们知道他们现在可以回到首先回到他们所需访问的任务。

变焦和保证金 变焦和保证金

结果

在我们将访问流程迁移到访问服务之后,结果是零长寿的访问在AWS和GCP中的任何特权云角色。如果没有积极使用,授予这些角色的所有访问都会到期。

在下面的图表中,“接入点”指的是访问每个管理角色的用户数量。在使用Access Service之后,我们将拥有特权访问的人数减少了90%。

变焦和保证金

在下面的图表中,“活跃”指的是在过去30天内使用某款应用的人数。因为这个数是更高的比接入点数量,这表明了在过去30天中使用的通道比目前提供的要多

这似乎很奇怪-管理应用程序怎么可能使用由更多人的人总数提供访问?这是因为过期的访问已经被自动剥夺,在30天窗口结束时减少了接入点的数量!

变焦和保证金

结论

通过认识到访问需求是不断变化的,我们能够创建一种更实际的方式来管理访问控制。

访问服务允许我们简化访问批准流程。通过将请求直接路由到指定的审批人,我们能够从具有丰富上下文的人那里快速获得批准。访问请求的基于时间的组件允许服务定期删除不必要的访问,防止我们的访问攻击面变得太大。最后,将Slack集成到系统中可以加快审批速度,确保您立即知道请求何时被批准,并在请求到期时提醒您,这样您在工作时就不会遇到意外的访问丢失。

虽然试图重新创造一个现有的、成熟的过程是令人生畏的,但结果可能是令人难以置信的回报。从写下你的目标开始,思考你不喜欢的和当前状态中让你痛苦的是什么,重新评估你的核心假设。公司总是在变化,你的流程也必须跟上;导致以前制度的情况今天可能不再适用。最重要的是,记住在构建时要考虑到用户的工作流,因为安全性依赖于整个公司的参与。新万博app2.0下载

未来的发展

政策

访问服务中的应用程序当前是单独的可自定义的。但是,如果我们希望跨多个类似的应用程序进行更改,这可能会导致可扩展性的问题。例如,如果我们决定要将对几个AWS的访问限制为不超过一周,我们目前必须为每个角色编辑允许的持续时间。随着介绍政策,我们将能够将几个角色映射到一个策略,使我们能够轻松地应用前面示例中的更改。

动态的角色

目前,访问服务授予用户访问预定义的AWS角色。这些角色通常是通用目的,但可能有可能使用的情况下不完全捕获现有角色。而不是为一次性需要配置新角色,或者使用过度允许的角色,访问服务可能允许用户创建一个动态角色.当发出一个请求时,用户会选择对应于他们想要的权限的框(例如“S3 Read”,“CloudWatch Full Access”等)来创建一个自定义的动态角色。


特别感谢David Scrobonia创建访问服务,并为这个博客建立了基础。感谢John Boggs、Rob McQueen、Anastassia Bobokalonova、Leif Dreizler、Eric Ellett、Pablo Vidal、Arta Razavi和Laura Rubin,他们都是Access Service的建造者、设计者、启发者或贡献者。


参考文献

配置Okta中的GCP角色

将GCP角色连接到Okta比使用AWS更困难努力弄明白有一段时间,我们认为这值得分享。为了将GCP角色连接到Okta实例,我们必须使用GSuite中的谷歌Groups。

首先,我们创建了一个单独的GSuite Group对于我们每个项目角色对。在GCP,a谷歌Group是a成员(主体)可以被分配一个角色,添加到该组的所有用户也会分配该角色。

然后,我们将每个GCP角色分配给相应的谷歌组。接下来,我们需要将谷歌组连接到Okta。

你可以通过使用来完成此操作Okta推动组织,它将Okta“group”链接到谷歌group。将用户添加到Okta Push Group会自动将正确的GSuite用户添加到谷歌组。我们为每个角色创建了一个Okta Group,并将其配置为对应谷歌Group的Push Group。

总结一下,流程是这样的:

  1. 添加Okta用户david@www.asianminres.com到Okta组“分段读- GCP角色”

  2. Okta Push Groups将GSuite用户david@www.asianminres.com添加到“Staging Read”谷歌组中

  3. 因为他是“Staging Read”谷歌组的成员,所以david@www.asianminres.com被分配为“Staging”项目的“Read”IAM角色。

变焦和保证金

超越内部应用程序的方法

我们所有的内部应用程序都使用OpenID连接(OIDC)启用ALB (Application Load Balancer)连接Okta这提供了一个超越我们内部应用的访问方式:所有都是公开路由,但都落后于Okta。

从工具开发人员的角度来看,这也很好,因为不仅考虑了身份验证,而且我们可以使用Okta通过ALB返回给服务器的签名JSON web令牌(JWT),以获得与Access Service交互的用户的身份。这允许我们使用Okta作为一个粗略的授权层,并管理哪些用户可以访问不同的内部应用程序。

变焦和保证金

到2030年,你的技术堆栈会是什么样子?

在我们的新报告中,我们调查了超过4000名客户数据决策者,以衡量客户数据行业当前和未万博官方购彩来的预测。

成为一名数据专家。

获取所有有关数据、产品和增长的最新文章,直接发送到您的收件箱。