云防护栏理论:应对云配置错误的安全防护策略

云防护栏理论:配置错误的历史与解决方案

配置错误的历史

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

但能力越大,责任越大。

虽然云能够为企业提供很多支持,但如果使用不当,很容易配置错误并导致安全漏洞。四分之一的组织(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最佳实践")这也意味着如果根用户无法使用,则无需为该用户设置多因素设备。

json 复制代码
{ 
  "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周期的后期阶段,如数据外泄,是实际可行的威胁威慑控制。

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

检测性防护栏

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

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

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

使用案例:

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

修复性防护栏

修复性防护栏在预防性和检测性防护栏之间找到了中间立场。与预防性防护栏相反,修复性防护栏的方法可以有细微差别。组织可以将一个操作定义为对错误配置的响应。考虑将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、modify和append。

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

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

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

您也可以在不使用CloudGuard的情况下使用CloudBots,使用相同的触发器,但源自您的应用程序。 </ humble-plug >

态势金字塔

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

态势金字塔

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

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

类比时间:

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

防护栏类比

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

结论

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

祝云上愉快!

相关推荐
ezl1fe2 小时前
RAG 每日一技(二十一):让证据“会算账”——差异对照与可核验公式的最小闭环
人工智能·后端·程序员
电鱼智能的电小鱼2 小时前
服装制造企业痛点解决方案:EFISH-SBC-RK3588 预测性维护方案
网络·人工智能·嵌入式硬件·算法·制造
_Mya_3 小时前
后端接口又改了?让 Apifox MCP 帮你自动同步类型定义
前端·人工智能·mcp
西柚小萌新3 小时前
【深入浅出PyTorch】--7.1.PyTorch可视化1
人工智能·pytorch·python
兔子小灰灰3 小时前
论文笔记:π0.5 (PI 0.5)KI改进版
人工智能·深度学习
PKNLP3 小时前
Transformer模型
人工智能·深度学习·transformer
渡我白衣3 小时前
深度学习进阶(一)——从 LeNet 到 Transformer:卷积的荣光与注意力的崛起
人工智能·深度学习·transformer
机器之心3 小时前
蚂蚁Ring-1T正式登场,万亿参数思考模型,数学能力对标IMO银牌
人工智能·openai
用户5191495848453 小时前
深入探索Next.js中的SSRF漏洞挖掘
人工智能·aigc