浅谈云上攻防系列——云 IAM 原理 & 风险以及最佳实践
云上身份和访问管理功能简介
身份和访问管理是什么?关于这个问题,Gartner Information Technology Glossary 中给出了关于 IAM 的定义:“Identity and access management (IAM) is the discipline that enables the right individuals to access the right resources at the right times for the right reasons”。与之类似,云上身份和访问管理服务,则是云厂商提供的一种用于帮助用户安全地控制对云上资源访问的服务。用户可以使用 IAM 来控制身份验证以及授权使用相应的资源。IAM 的 8 大管理维度,可以参见下图:
图 1 IAM 8 大管理维度
云上身份与访问管理首先在配置阶段注册和授权访问权限,然后在操作阶段识别、验证和权限控制。下图将展示 IAM 的配置阶段与操作阶段之间的关系,以及身份与访问管理的区别。
图 2 身份和访问管理概念图
云厂商为租户提供云上 IAM 服务用以身份和访问管理,例如:腾讯云 Cloud Access Management 服务、亚马逊云 AWSIdentity and Access Management 服务等。通过提供账号全生命周期管理、身份管理、认证、权限、审计以及联合身份等基本功能,加强了身份认证体系的安全性。
正确的使用访问管理,可以规避许多云上攻击事件的发生。但是错误的配置以及使用将会导致严重的云上漏洞。Unit 42 云威胁报告指出,错误配置的亚马逊云 IAM 服务角色导致数以千计的云工作负载受损。研究人员成功地使用错误配置的 IAM 功能在云中横向移动,并最终获得凭据以及重要数据。接下来,我们将介绍云 IAM 技术体系框架以及工作原理,并从历史案例中刨析云 IAM 的风险,并寻找最佳解决方案。
云 IAM 技术体系框架 &工作原理
我们首先来谈谈云 IAM 的技术体系框架。云上身份与访问管理是一个比较复杂的体系架构。用户日常使用云上服务时,往往会接触到到云平台所提供的账号管理功能,角色管理、临时凭据、二次验证等等,这些都是云上身份与访问管理的一部分。但实际上云上身份与访问管理不仅仅包含上述这些功能,对于云平台来说,云上身份与访问管理是一项复杂的成体系化的架构。
从云安全联盟大中华区发布的《IAM 白皮书(试读本)》中可见,云 IAM 技术体系框架包含认证管理、授权份管理、用户生命周期管理、策略管理等模块,见下图:
图 3 CSA GCR 身份和访问管理框架
云 IAM 使用上图中这些管理技术,以实现对云上资源以及云上业务的身份与权限管理,从而确保云上身份管理的安全以及合规,保障云上资源访问的可审计、风险可控性。在了解云 IAM 技术体系框架后,我们来看一下 IAM 的工作流程以及身份验证和授权工作步骤如。身份和访问管理工作原理图可参加下图所示:
图 4 身份和访问管理工作原理图
我们将对上图中的流程与步骤进行说明:
Step 1:扮演委托人(Principal)身份的用户或应用程序,使用账户或凭据对云资源发起请求并以此执行操作。
Step 2:云 IAM 服务将校验请求的身份认证情况,委托人使用其合法凭证发送请求以通过身份验证。在不同的场景下,认证方式将会有所不同。值得注意的是,并非访问所有云服务,都经历身份认证环节:在一些云服务中,允许跳过身份认证流程,例如对象存储服务,这类服务可以配置允许匿名用户的请求。
Step 3:在通过身份认证机制后,IAM 服务会进行授权校验:在此期间,IAM 服务将会使用请求上下文中的值来查找应用于请求的策略,依据查询到的策略文档,确定允许或是拒绝此请求。在此期间,如果有一个权限策略包含拒绝的操作,则直接拒绝整个请求并停止评估。
Step 4:当请求通过身份验证以及授权校验后,IAM 服务将允许进行请求中的操作(Action)。常见的操作有:查看、创建、编辑和删除资源。
Step 5:IAM 通过操作(Action)和资源(Resource)两个维度进行权限校验,在 IAM 批准请求中的操作后,将会校验权限策略中与这些操作相关联的资源范围。在一个常见的案例中,当前委托人拥有云服务器重启实例操作权限,但其策略中的资源配置处限定了只拥有某个具体实例的此操作权限,委托人使用此策略,也是仅仅可以重启这个实例,而不是对所有实例资源进行重启操作。
云 IAM 风险案例
纵观近年来的云安全大事件,其中不乏有很多由于漏洞、错误配置以及错误使用云 IAM 导致的严重云安全事件,下文我们将回顾几个真实的云 IAM 安全事件,从 IAM 漏洞、IAM 凭据泄露与错误实践等几个方面来了解云 IAM 的安全风险。CVE-2022-2385:潜伏 5 年的 Aws Iam Authenticator 提权漏洞 Aws Iam Authenticator 是一个使用 AWS IAM 凭据对 Kubernetes 集群进行身份验证的工具。这个工具最初是由 Heptio 推动,目前由 Heptio 和 Amazon EKS OSS 工程师维护。
图 5 Aws Iam Authenticator 认证鉴权流程图
近日,AWS 发布了一份安全公告,通报了 Aws Iam Authenticator 中的一个漏洞(CVE-2022-2385)。利用此漏洞,攻击者可以在 EKS [Elastic Kubernetes Service] 集群进行提升权限攻击。该漏洞在 AWS Iam Authenticator 代码中存在了多年。研究人员发现,AWS Iam Authenticator 在进行身份验证过程中存在几个缺陷:由于代码错误的大小写校验,导致攻击者可以制作恶意令牌来操纵 AccessKeyID 值,利用这些缺陷,攻击者可以绕过 AWS IAM 针对重放攻击的保护,从而进行集群提权利用。
GitHub 市场应用 Waydev 服务客户凭据泄露事件
Waydev 是一个工程团队使用的分析平台,通过提供的 SaaS 服务,通过分析基于 gitbase 的代码库来跟踪软件工程师的工作输出,用户可以通过 Waydev 在 GitHub 的 App 商店中提供的应用来使用此服务。客户在使用 Waydev 服务时,需要客户提供其 GitHub IAM 服务所生成的 OAuth token,以便 Waydev 访问与分析客户在 GitHub 上部署的项目。Waydev 将这些客户的 GitHub OAuth token 以明文形式保存在内部数据库中。攻击者通过传统的入侵手段,成功的入侵 Waydev 公司内部数据库,造成 Waydev 数据库中明文存储的用户 GitHub OAuth token 泄露,攻击者利用窃取到的客户 GitHub IAM 凭据,成功访问客户代码仓库,从而窃取项目源代码。
图 6 黑客论坛上发布 Dave 客户数据
此次云 IAM 凭据泄露事件,对 Waydev 的客户造成了严重的影响,以数字银行应用 Dave.com 为例,在此次事件中,由于 Dave.com 存储于 Waydev 中的的 IAM 凭据被窃取,导致 Dave.com 750 万用户数据泄露,对 Dave.com 造成了严重的损失。
Unit 42 云威胁报告:99%的云用户 IAM 采用了错误的配置
据 Palo Alto Networks 调查团队 Unit 42 对 1.8 万个云帐户以及 200 多个不同组织中的 68 万多个 IAM 身份角色进行调查结果表明:错误的 IAM 使用以及不安全 IAM 凭证管理将会为云安全带来极大的风险。据调查报告显示,约有 44%的企业机构的 IAM 密码存在重复使用情况;53%的云端账户使用弱密码;99%的云端用户、角色、服务和资源被授予过多的权限,而这些权限最终并没有被使用;大多数云用户喜欢使用云平台内置 IAM 策略,而云服务提供商默认提供的内容策略所授予的权限通常是客户管理所需策略权限的 2.5 倍。除此之外,据报告显示:在野的攻击团队(WatchDog、Kinsing 等)已经开始使用一套专门针对云端的攻击策略、技术和工具,来攻击用户错误配置的云 IAM。
云 IAM 最佳实践
通过对云上身份与访问管理安全的研究,我们在这里总结出 12 条针对云 IAM 的最佳实践,以帮助正确的配置以及使用 IAM。
避免使用根用户凭据:由于根用户访问密钥拥有所有云服务的所有资源的完全访问权限。因此在使用访问密钥访问云 API 时,避免直接使用根用户凭据。更不要将身份凭证共享给他人。应使用 IAM 功能,创建子账号或角色,并授权相应的管理权限。
使用角色委派权:使用 IAM 创建单独的角色用于特定的工作任务,并为角色配置对应的权限策略。通过使用角色的临时凭据来完成云资源的调用,使用角色临时凭据将比使用长期访问凭证更安全。由于角色临时凭据的持续时间有限,从而可以降低由于凭据泄露带来的风险。
遵循最小权限原:在使用 IAM 为用户或角色创建策略时,应遵循授予”最小权限”安全原则,仅授予执行任务所需的权限。在明确用户以及角色需要执行的操作以及可访问的资源范围后,仅授予执行任务所需的最小权限,不要授予更多无关权限。
使用组的形式管理账号权限:在使用 IAM 为用户账号配置权限策略时,应首先按照工作职责定义好用户组,并为不同的组划分相应的管理权限。在划分组后,将用户分配到对应的组里。通过这种方式,在修改用户组权限时,组内的所有用户权限也会随之变更。
不使用同一 IAM 身份执行多个管理任务:对于云上用户、权限以及资源的管理,应使用对于的 IAM 身份进行管理。应该让部分 IAM 身份用以管理用户,部分用以子账号管理权限,而其他的 IAM 身份用来管理其他云资产
为 IAM 用户配置强密码策略:通过设置密码策略,例如:最小和最大长度、字符限制、密码复用频率、不允许使用的用户名或用户标识密码等,以此保证 IAM 用户创建密码时的强度安全要求。
启用多重验证:在开启多重验证后,访问网站或服务时,除了其常规登录凭证之外,还要提供来自 MFA 机制的身份验证。这样可以增强账号安全性,有效的对敏感操作进行保护。
定期轮换凭证:定期轮换 IAM 用户的密码与凭据,这样可以减缓在不知情的情况下密码或凭据泄露带来的影响。
删除不需要的 IAM 用户数据:应及时删除不需要的 IAM 用户信息,例如账户、凭据或密码。通过云厂商提供的查找未使用的凭证功能以及用户管理功能,获取不需要的账户、凭据或密码,及时删除这些信息。
制定细粒度策略条件:在制定 IAM 策略时,应该定义更细粒度的约束条件,从而对策略生效的场景进行约束,并以此强化 IAM 的安全性。在一些常见的场景中,可以通过在策略中生效条件(condition)中配置 IP 地址,以限制凭据只有指定服务器可用,当凭据发生泄露后,由于 IP 的约束,导致凭据无法被利用。
监控 IAM 事件:通过审计 IAM 日志记录来确定账户中进行了哪些操作,以及使用了哪些资源。日志文件会显示操作的时间和日期、操作的源 IP、哪些操作因权限不足而失败等。
在云服务器实例上使用角色而非长期凭据:在一些场景中,云服务实例上运行的应用程序需要使用云凭证,对其他云服务进行访问。为这些云服务硬编码长期凭据将会是一个比较危险的操作,因此可以使用 IAM 角色。角色是指自身拥有一组权限的实体,但不是指用户或用户组。角色没有自己的一组永久凭证,这也与 IAM 用户有所区别。
写在最后
云 IAM 服务作为云平台中进行身份验证与访问管理的一个重要功能,通过了解云 IAM 服务的工作原理、功能特征以及如何正确使用 IAM 进行配置,对保障云上安全尤为重要。通过上文分析可见,虽然 IAM 服务自身拥有如上的众多优势,可以很好支持云上身份与访问管理,但是由于没有遵循安全规范,错误的使用 IAM 功能,依然会为云上资产带来风险。未来我们将持续关注云 IAM 安全问题,并给出对应的安全建议与解决方案。
版权声明: 本文为 InfoQ 作者【腾讯安全云鼎实验室】的原创文章。
原文链接:【http://xie.infoq.cn/article/18aee3bb26195c29e07ea04ff】。未经作者许可,禁止转载。
评论