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

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

但能力越大，责任越大。

虽然云能够为企业提供很多支持，但如果使用不当，很容易出现错误配置，并可能导致安全漏洞。四分之一的组织（27%）经历过与公共云相关的安全事件；比去年增加了10%。今年，错误配置（23%）已超越去年用户数据暴露（15%）和账户泄露（15%），成为排名第一的安全相关事件。

2022年Check Point云安全报告

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

云防护栏的引入

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

防护栏类型：

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

预防性防护栏

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

Amazon Web Services（AWS）中的服务控制策略（SCPs）是为AWS账户和资源设置细粒度权限的一种方式。SCPs用于在组织根级别或组织内各个AWS账户设置权限。它们允许您为整个组织中的各种操作和资源设置明确的允许或拒绝权限。

另一方面，Azure Policy是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的ATT&CK框架提供了一种结构化方法来放置这些防护栏。

这方面的一个例子是防止与数据外泄相关的技术，即：

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

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

检测性防护栏

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

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

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

使用案例：

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

修复性防护栏

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

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

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

修复的另一种方法是使用自定义构建的修复应用程序或函数。

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

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

您也可以在不使用CloudGuard的情况下使用CloudBots，使用相同的触发器，但源自您的应用程序。

态势金字塔

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

态势金字塔

• 检测性防护栏是组织内的主导实践；它评估大量检查，主要作为合规性或最佳实践框架的一部分，并构成防护栏实践的基石。检测性防护栏检测各种错误配置，并且它们总是需要手动修复。检测性防护栏也作为大多数预防性或修复性防护栏的暂存地。

• 预防性防护栏是防护栏中执行范围最窄的实践。它们的本质阻止用户广泛实施它们，但它们在即时阻止关键错误配置方面发挥着关键作用。一旦定义，预防性防护栏很少改变或发展。

• 修复性防护栏在检测性和预防性防护栏之间取得平衡。修复性防护栏的本质是检测错误配置的发生并进行修复。响应时间不是瞬时的，并且根据使用的修复工具而有很大差异，但它是自动化的。修复性防护栏通常从检测性防护栏有机地发展而来，因此是一种不断发展的实践。

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

类比时间

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

防护栏类比

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

结论

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

祝您云使用愉快！