admin

避免顶级云访问风险的7个步骤

admin 安全防护 2022-12-01 451浏览 0

根据云计算安全联盟(CSA)最近发布的一份调查报告,在云计算面临的11种最大威胁中,配置错误和变更控制不足排在第二位,仅次于数据泄露。

Capital One公司的数据泄漏事件就是一个很好的例子,该事件导致该公司1.06亿张信用卡客户和申请人的数据泄露。网络攻击者利用了开放源Web应用程序防火墙(WAF)中的一个漏洞,该漏洞被用作银行基于AWS云平台操作的一部分。

避免顶级云访问风险的7个步骤

通过这个漏洞,网络攻击者可以获取凭据以访问Web应用程序防火墙(WAF)以访问所有资源。不幸的是,Web应用程序防火墙(WAF)被赋予了过多的权限,也就是说,网络攻击者可以访问任何数据桶中的所有文件,并读取这些文件的内容。这使得网络攻击者能够访问存储敏感数据的S3存储桶。

减轻这种身份滥用的最有效方法是执行最低特权原则。在理想情况下,每个用户或应用程序应仅限于所需的确切权限。

实施最低特权的第一步是了解已授予用户(无论是人员还是机器)或应用程序哪些权限。下一步是映射所有实际使用的权限。两者之间的比较揭示了权限差距,从而暴露了应保留的权限和应撤销的权限。因此必须定期连续执行这一过程,以保持一段时间内的最小特权。

为了说明这个过程如何在云平台中工作,以主流的AWS云平台为例,并且提供可用的细粒度身份和访问管理(IAM)系统之一。AWS身份和访问管理(IAM)是一个功能强大的工具,它允许管理员安全地配置超过2500个权限,以实现对给定资源可以执行哪些操作的细粒度进行控制。

步骤1:检查附加政策

第一步是检查直接附加到用户的策略。有两种类型的策略:

  • 托管策略有两种类型:由云计算服务提供商(CSP)创建和管理的AWS托管策略,以及(组织可以在其AWS帐户中创建和管理的客户托管策略。与AWS托管策略相比,客户托管策略通常提供更精确的控制。
  • 内联策略,由AWS客户创建并嵌入在身份和访问管理(IAM)标识(用户、组或角色)中。当最初创建或稍后添加身份时,可以将它们嵌入标识中。

步骤2:分析身份和访问管理(IAM)组

下一步是检查用户所属的每个身份和访问管理(IAM)组。这些还具有附加策略,可以间接授予用户访问其他资源的权限。就像用户本身一样,组可以附加到托管策略和内联策略。

步骤3:映射身份和访问管理(IAM)角色

现在,所有附加到用户的身份和访问管理(IAM)角色都需要映射。角色是另一种类型的标识,可以使用授予特定权限的关联策略在组织的AWS帐户中创建。它类似于身份和访问管理(IAM)用户,但其角色可以分配给需要其权限的任何人,而不是与某个人唯一关联。角色通常用于授予应用程序访问权限。

步骤4:调查基于资源的策略

接下来,这一步骤的重点从用户策略转移到附加到资源(例如AWS存储桶)的策略。这些策略可以授予用户直接对存储桶执行操作的权限,而与现有的其他策略(直接和间接)无关。对所有AWS资源及其策略(尤其是包含敏感数据的策略)进行全面审查非常重要。

步骤5:分析访问控制列表

在策略审查完成之后,分析应该移至链接到每个资源的访问控制列表(ACL)。这些类似于基于资源的策略,并允许控制其他帐户中的哪些身份可以访问该资源。由于不能使用访问控制列表(ACL)来控制同一帐户中身份的访问,因此可以跳过与该用户相同帐户中拥有的所有资源。

步骤6:查看权限边界

在这一步骤中,需要检查每个用户的权限边界。这是一项高级功能,用于定义用户、组或角色可能具有的最大权限。换句话说,用户的权限边界基于附加的策略和权限边界定义了允许他们执行的动作。重要的是要注意权限边界不会以相同的方式影响每个策略。例如,基于资源的策略不受权限边界的限制,这些策略中的任何一个明确拒绝都将覆盖允许。

步骤7:检查服务控制策略

最后,有必要检查服务控制策略(SCP)。从概念上讲,这些权限类似于在AWS账户中所有身份(即用户、组和角色)上定义的权限边界。服务控制策略(SCP)在AWS组织级别定义,并且可以应用于特定帐户。

强制最小权限访问

正如人们所看到的,在云中保护身份和数据是一项挑战,随着组织扩展其云计算足迹而变得越来越复杂。在许多情况下,用户和应用程序往往会积累远远超出其技术和业务要求的权限,这会导致权限差距。

通常,在像AWS云平台这样的复杂环境中,确定每个用户或应用程序所需的精确权限所需的工作成本高昂,而且无法扩展。即使是诸如了解授予单个用户的权限之类的简单任务也可能非常困难。

为了使其中一些流程实现自动化, AWS公司几年前发布了一个名为Policy Simulator的工具,该工具使管理员可以选择任何AWS实体(即IAM用户、组或角色)和服务类型(例如关系型数据库服务或S3存储桶),并自动评估特定服务的用户权限。

尽管Policy Simulator是一个很棒的工具,但并不十分成熟。例如,Policy Simulator不会检查用户可能承担的所有角色及其策略(步骤3)。它还不考虑访问控制列表(ACL)(步骤5)或权限边界(步骤6)。在大多数情况下,组织被迫执行人工策略管理或编写专有脚本。

如人们所见,在云计算环境中管理身份和访问以实施最低特权策略非常复杂,需要大量人工工作,并且成本高昂。由于这门学科还处于起步阶段,因此缺少云平台提供商提供的可靠的原生工具。在通常情况下,第三方解决方案正在填补市场空白。

继续浏览有关 云安全 的文章
发表评论