云防护栏理论：配置错误的历史与应对

云和云原生计算范式为全球组织带来了前所未有的敏捷性和加速能力，使企业能够以极快速度生产和更新业务应用。应用更新或修改的周转时间已从季度缩短至数周甚至数天。

但能力越大，责任越大。

虽然云能够极大赋能业务，但如果使用不当，很容易出现配置错误并导致安全漏洞。27%的组织经历过与公有云相关的安全事件，较去年上升10%。今年，配置错误（23%）已成为头号安全事件，超越了去年的用户数据暴露（15%）和账户泄露（15%）。

根据《Check Point 2022年云安全报告》，76%的受访者使用两个或更多云提供商，表明组织正积极拥抱更敏捷的软件开发。如今，35%的受访者将超过50%的工作负载放在云上，29%预计在未来12-18个月内将这一比例提升至75%。这种向自助服务生态系统的趋势，即开发人员使用云构建应用，只会加剧配置错误的风险。

云防护栏的引入

云防护栏是实施的安全控制措施，用于引导用户正确配置，并阻止他们进行有害的错误配置。

防护栏类型：

• 预防性防护栏
• 检测性防护栏
• 修复性防护栏

预防性防护栏

预防性防护栏通常内置在云服务提供商（CSP）的控制平面中，可以立即限制某些操作，使用各CSP原生工具（如AWS服务控制策略或Azure策略）强制执行。

在亚马逊网络服务（AWS）中，服务控制策略（SCPs）是一种为AWS账户和资源设置细粒度权限的方法。SCPs用于在组织根级别或组织内单个AWS账户设置权限，允许您为整个组织中的各种操作和资源设置显式允许或拒绝权限。

另一方面，Azure策略是Microsoft Azure中的一项服务，使您能够创建、分配和管理策略，定义Azure订阅中允许和不允许的内容。这些策略可用于强制执行企业标准并保护资源。

用例：

管理控制：防护栏用作工具，强制执行对CSP提供服务使用的一系列操作或管理限制。这些限制的主要目的是限制或防止使用CSP的某些服务，例如：

• 限制可部署的EC2/VM实例的大小或类型
• 限制可使用CSP服务的区域/位置
• 拒绝启动不符合组织命名和标记约定的资源的请求
• 防止在账户/订阅中使用根账户

以下是AWS防止在账户中使用根账户的方法示例。AWS Control Tower服务推荐使用SCP拒绝根用户。这很好，因为它减轻了AWS围绕根用户可能发生的密码恢复（即账户接管）的担忧。（“Summit Route — AWS SCP最佳实践”）这也意味着，如果根用户无法使用，则无需为该用户设置多因素设备。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

{
  "Version": "2012-10-17",
  "Statement": {
    "Sid": "DenyRootUser",
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {
      "StringLike": {
        "aws:PrincipalArn": "arn:aws:iam::*:root"
      }
    }
  }
}

威胁威慑控制：一种更以威胁为导向的防护栏方法是防止攻击在账户/订阅中的进展。MITRE的ATTACK框架提供了一种结构化方法来放置这些防护栏。

例如，防止与数据外泄相关的技术，即：

• 防止修改关键资源（如数据库、对象存储、块存储等）的访问控制策略。例如，禁止生产账户中所有S3存储桶的“putbucketpolicy”或“putbucketacl”
• 禁用上述所有资源的“静态加密”

请参阅expel团队的文章，该文章从AWS的角度讨论了不同的MITRE ATT&CK策略。防止ATT&CK周期的后期阶段，如数据外泄，是实际可行的威胁威慑控制。

预防性防护栏在上述用例中有效，但如果以中等规模应用，则变得不切实际；例如具有数百到数千项检查的合规性控制。这是因为预防性控制无法有效执行细粒度或资源特定检查，而且预防性防护栏设计上仅阻止或防止不良操作，但它们无助于或引导用户构建更安全的环境。不断阻止不良行为而不提供替代方案会阻碍开发人员和CSP用户的生产力。

检测性防护栏

检测性防护栏本质上是非侵入性的，仅用于识别云的状态，即资源或服务是否配置错误。由于它们是检测性的且不存在意外预防的威胁，因此可以更自由地使用，并且是比其他类型防护栏更主流的实践。检测性防护栏也可以是资源特定的，并且是一种不断发展的实践，具有微调周期。

AWS Config是亚马逊网络服务（AWS）提供的一项服务，允许组织评估、审计和评估其AWS资源的配置。它提供资源的详细配置视图，包括它们如何相互关联的信息，并可用于跟踪配置随时间的变化。

Azure策略计划是一种将多个策略分组并应用于特定资源集的方法。这使组织能够以更高效和简化的方式跨大量资源强制执行多个策略的合规性。

用例：

合规性和最佳实践框架：检测性防护栏用于强制执行法规合规性。组织可能需要遵守HIPAA、SOC2或GDPR等法规，因此需要确保其云基础设施满足这些合规性要求。这可能包括数据加密、数据备份和事件响应计划等内容。通过实施这些控制，组织可以确保满足合规义务，并向审计员和监管机构证明合规性。检测性防护栏的另一个类似用例是它们检查云环境是否符合安全最佳实践框架的能力。像CIS Foundations或NIST云安全框架这样的框架为云环境中的安全、隐私和合规性提供了指南。

修复性防护栏

修复性防护栏介于预防性和检测性防护栏之间。与预防性防护栏相反，修复性防护栏的方法可以有细微差别。组织可以定义一种操作作为对错误配置的响应。考虑将VPC/VNET中的资源暴露给互联网；预防性防护栏只会阻止它，而修复性防护栏可以编程以强化VPC/VNET。

AWS Config可以与其他AWS服务（如AWS Lambda、Amazon SNS和Amazon CloudWatch）集成，以自动化响应配置更改，并触发自定义操作。这使组织能够快速识别和解决可能出现的任何问题或合规违规。然而，AWS还提供Systems Manager文档作为预定义自动修复的选项。

Azure策略效果用于指定当评估策略并检测到不合规资源时Azure策略应采取的操作。特别是DeployIfNotExists效果，如果订阅或资源组中尚不存在资源，则部署该资源。这对于确保特定类型的资源始终存在于订阅或资源组中非常有用。然而，Azure策略效果对于修复场景不太灵活，因为它们只能部署ifNotExists、修改和追加。

<低调插播> 修复的另一种方法是使用自定义构建的修复应用程序或功能。

适用于AWS的CloudBots CloudBots是用于公有云平台（AWS、Azure和GCP）的开源自动修复解决方案，构建在CloudGuard持续合规能力之上。（“GitHub — dome9/cloud-bots: Dome9的自动化和修复机器人…”）您可以配置CloudGuard持续合规以使用规则集评估您的云账户，持续检查账户的合规性，并近乎实时地发布报告和发现的问题。CloudBots通过添加一个选项来扩展这一点，该选项可以从失败的合规规则直接触发对账户中有问题的云实体的立即修复操作。该规则触发一个在您账户中运行的机器人，为失败规则的问题提供补救措施。

例如，检查客户管理的KMS是否启用轮换的规则可以触发kms_enable_rotation机器人以启用轮换。同样，检查CloudTrail是否启用的规则可以触发cloud_trailenable机器人以创建和启用CloudTrail。

您也可以在不使用CloudGuard的情况下使用CloudBots，使用相同的触发器，但源自您的应用程序。 </低调插播>

态势金字塔

态势金字塔是一种用于描述防护栏最佳方法的可视化表示。

态势金字塔

• 检测性防护栏是组织内的主导实践；它评估大量检查，主要作为合规性或最佳实践框架的一部分，并构成防护栏实践的基石。检测性防护栏检测各种错误配置，并且总是需要手动修复。检测性防护栏也作为大多数预防性或修复性防护栏的暂存地。
• 预防性防护栏是防护栏中执行最狭窄的实践。它们的本质阻止用户广泛执行它们，但它们在即时阻止关键错误配置方面发挥着至关重要的作用。一旦定义，预防性防护栏很少作为实践改变或演变。
• 修复性防护栏在检测性和预防性防护栏之间取得平衡。修复性防护栏的本质是检测错误配置的发生并修复它。响应时间不是瞬时的，并且根据使用的修复工具而有很大差异，但它是自动化的。修复性防护栏通常从检测性防护栏有机地发展而来，因此是一种不断发展的实践。

成熟的防护栏实践将拥有所有三种类型的防护栏，程度不同，但保持与态势金字塔中提到的比例相似。

类比时间

我一直认为类比是消化新概念的最佳方式，所以这里有一个防护栏的类比。考虑一条高速公路，如果高速公路上的汽车代表您的云状态，那么：

防护栏类比

• 高速公路两侧的物理防护栏将是您的预防性防护栏。
• 驾驶员的视野将是检测性防护栏。
• 汽车的车道辅助机制将是修复性防护栏。

结论

配置错误将长期存在！！随着CSP新功能的持续和极快速度，我们确信这一点！！组织必须将防护栏实践视为必需品，而防护栏理论是一个容纳任何规模实践的框架。

祝云之旅愉快！！

Cloud Security、AWS、Azure、治理、云计算