云护栏理论：配置错误的历史与演变

配置错误的历史

云计算和云原生计算范式为全球组织带来了前所未有的敏捷性和发展速度。它使企业能够以惊人的速度生产和更新其业务应用程序。更新或修改应用程序的周转时间已经从按季度计算缩短到了几周甚至几天。

但是，能力越大，责任越大。

虽然云技术能为业务提供巨大助力，但如果使用不当，很容易配置错误，并可能导致安全漏洞。四分之一（27%）的组织经历过与公共云相关的安全事件；这一比例比去年上升了10%。今年，配置错误（23%）已取代去年用户数据暴露（15%）和账户泄露（15%），成为首要的安全相关事件。

Check Point 2022年云安全报告

更复杂的是，组织继续依赖多云解决方案，76%的受访者使用两个或更多云提供商，这清楚地表明组织正在拥抱更敏捷的软件开发。如今，35%的受访者将超过50%的工作负载放在云端，29%的人表示他们预计在未来12-18个月内将这一比例提高到75%。这种向自助服务生态系统发展的趋势，即开发人员可以使用云来构建他们的应用程序，只会加剧这种情况。

引入云护栏

云护栏是实施的安全控制措施，旨在引导用户走向正确的配置路径，阻止他们进行有害的错误配置。

护栏的类型：

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

预防性护栏

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

亚马逊云科技（AWS）中的服务控制策略（SCPs）是一种为你的AWS账户和资源设置细粒度权限的方法。SCPs用于在组织根级别或组织内的单个AWS账户级别设置权限。它们允许你为整个组织范围内的广泛操作和资源设置明确的允许或拒绝权限。

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

用例：

• 管理控制：在这里，护栏被用作一种工具，对CSP提供的服务的使用实施一系列操作或管理限制。这些限制的主要目的是限制或阻止使用CSP的某些服务，例如：
  • 限制可以部署的EC2/虚拟机实例的大小或类型
  • 限制可以使用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的ATT&CK框架为放置这些护栏提供了一种结构化方法。

这方面的一个例子是防止与数据窃取相关的技术，例如：

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

可以参考来自Expel同事的这篇文章，它从AWS的角度讨论了不同的MITRE ATT&CK策略。防止ATT&CK周期的后期阶段，如数据窃取，是实际可行的威胁威慑控制。

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

检测性护栏

检测性护栏本质上是非侵入性的，仅用于识别云的状态，即资源或服务是否存在错误配置。由于它们是检测性的，并且不存在无意中阻止的风险，因此可以更自由地使用，并且与其他类型的护栏相比，这是一种更主流的实践。检测性护栏也可以是特定于资源的，并且它们是一种不断发展的实践，需要经过精细调整的周期。

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

Azure策略计划是一种将多个策略组合在一起并将其应用于特定资源集的方法。这使组织能够以更高效和精简的方式跨大量资源强制遵守多项策略。

用例：

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

修复性护栏

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

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

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

态势金字塔

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

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

成熟的护栏实践会不同程度地包含所有三种类型的护栏，但会保持类似于态势金字塔中提到的比例。

类比时间：

我一直认为类比是理解新概念的最佳方式，所以这里有一个关于护栏的类比。想象一条高速公路，如果高速公路上的汽车代表你的云状态，那么：

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

结论

错误配置将一直存在！！随着CSP新功能以持续且惊人的速度推出，我们可以确信这一点！！组织必须将护栏实践视为一种必需品，而护栏理论是一个可以容纳任何规模实践的框架。

云上愉快！！