云工程和安全团队需要就其云环境的安全性提出一些重要问题，而且他们必须远远超出环境是否通过合规性审计。
在你向互联网添加一个新的端点的几分钟内，潜在的攻击者已经对其进行了扫描并评估了它的可利用性。因此一个云的错误配置就会使你的组织成为一个目标，并使你的数据处于危险之中。
假设一个攻击者发现了这些漏洞之一，并在你的环境中获得了最初的立足点。这种渗透的爆炸半径是多少？他们能造成什么样的损害？
攻击者有多容易发现关于你的环境和你存储敏感数据的地方的知识？他们能否利用云资源API密钥和过于宽松的IAM（身份和访问管理）设置来破坏你的云控制平面并获得对其他资源和数据的访问？他们是否能够在不被发现的情况下将这些数据提取到自己的云账户中，例如通过存储桶同步命令？
深入调查，你有可能不喜欢你所发现的。迅速采取行动，在黑客利用这些漏洞之前，弥补你的云安全中的这些漏洞。同时也要认识到，云配置的 "漂移 "一直在发生，即使是在使用自动化的CI/CD管道时也是如此，所以你需要保持警惕。今天没有错误配置的云环境，不可能长期保持这种状态。
云安全就是配置安全
云本质上是一个巨大的可编程计算机，云操作的重点是云资源的配置，包括安全敏感的资源，如IAM、安全组以及数据库和对象存储的访问策略。你需要确保你的云资源的配置在第一天是正确和安全的，并在第二天保持这种状态。
行业分析师将此称为云安全态势管理 (CSPM)。这就是云客户经常出错的地方，有时会带来毁灭性的后果。如果你看到涉及 Amazon Web Services、Microsoft Azure 或 Google Cloud 的数据泄露，则可以确定攻击是由于云客户的错误而成为可能的。
我们倾向于非常注重避免对单个云资源（例如对象存储服务（例如，Amazon S3、Azure Blob）和虚拟网络（例如，AWS VPC、Azure VNet））的错误配置，这样做绝对至关重要。
但同样重要的是要认识到云安全取决于身份。在云中，许多服务通过 API 调用相互连接，需要 IAM 服务来确保安全，而不是基于 IP 的网络规则、防火墙等。
例如，从 AWS Lambda 函数到 Amazon S3 存储桶的连接是使用附加到 Lambda 函数承担的角色（其服务身份）的策略来完成的。IAM 和类似的服务很复杂且功能丰富，而且很容易为了让事情正常工作而过度宽容，这意味着过度宽容（而且通常很危险）的 IAM 配置是常态。
Cloud IAM 是新的网络，但由于云 IAM 服务是通过配置创建和管理的，因此云安全仍然与配置有关，并避免配置错误。
云配置错误和安全事件
与数据中心相比，云基础设施的种类要多得多，所有这些资源都是完全可配置的，而且是可配置错误的。考虑到所有可用的不同类型的云资源，以及它们可以组合在一起以支持应用程序的方式，配置的可能性实际上是无限的。
在我们 2021 年的调查中，36% 的云专业人士表示，他们的组织在过去一年中遭受了严重的云安全漏洞或破坏。并且有多种方式使这些事件成为可能。
资料来源：2021 年云安全状况报告
请记住，在横向扩展的环境中，对象存储和 IAM 服务等资源的配置可能会变得极其复杂，而且我们所知道的每一次云泄露都涉及到一系列错误配置漏洞。与其仅仅关注单一资源的错误配置，还不如彻底了解你的用例并批判性地思考如何在你的环境的完整上下文中保护这些服务。
例如，你可能认为你的 Amazon S3 存储桶已安全配置，因为启用了“阻止公共访问”，此时恶意行为者可能能够通过在同一环境中利用过度特权的 IAM 资源来访问其内容。了解你的爆炸半径风险可能是一个难以解决的问题，但这是一个不容忽视的问题。
云配置错误的规模
云计算错误配置漏洞与应用程序和操作系统漏洞不同，因为它们在你修复后还会不断出现。你可能已经在你的开发管道中进行了控制，以确保开发人员不会将已知的应用程序或操作系统漏洞部署到生产中。一旦这些部署得到保障，一般来说问题就解决了。
云的错误配置是不同的。同样的错误配置漏洞一次又一次地出现，这是司空见惯的。允许不受限制的SSH访问的安全组规则（如22号端口的0.0.0.0/0）只是日常发生的那种错误配置的一个例子，往往是在批准的部署管道之外。我们使用这个例子是因为大多数工程师都熟悉它（并且很可能在他们职业生涯的某个阶段犯过这种恶劣的行为）。
因为云基础设施非常灵活，我们可以使用API随意改变它，所以我们倾向于经常这样做。这是一件好事，因为我们在不断创新和改进我们的应用程序，需要修改我们的基础设施来支持这种创新。但是，如果你没有防范沿途的错误配置，预计会有大量的错误配置被引入你的环境。一半的云计算工程和安全团队每天要处理50起以上的错误配置事件。
资料来源：2021 年云安全状况报告
为什么会发生云配置错误
如果我们成功地使用了云，那么我们的云环境唯一不变的就是变化，因为这意味着我们正在快速创新并不断改进我们的应用程序。
但每一次变化都伴随着风险。
根据Gartner的数据，到2023年，至少有99%的云安全故障将是客户的错。考虑到云的错误配置是云安全故障发生的原因，而错误配置100%是人为错误的结果，这1%似乎是一个对冲。
但是，为什么云计算工程师会经常犯这样的关键错误呢？
缺乏对云安全和政策的认识是过去一年中报告的云错误配置的首要原因之一。把你所有的合规规则和内部安全政策汇编在一起，你可能有一个像《战争与和平》一样厚的卷宗。没有人能够记住所有这些，我们也不应该期望他们能够记住。
因此，我们需要控制措施来防止错误配置。但是，31%的人说他们的组织缺乏足够的控制和监督来防止云计算的错误配置。
部分原因是有太多的API和云界面让团队无法有效管理。使用多个云平台（45%的受访者称）只会使问题更加严重，因为每个平台都有自己的资源类型、配置属性、需要管理的接口、政策和控制。你的团队需要有效解决所有使用中的云平台的专业知识。
如果团队采用了云服务提供商的本地安全工具，而该工具在多云环境中并不适用，那么多云安全挑战就更加复杂。
资料来源：2021 年云安全状况报告
七项战略建议
由于云安全主要涉及在错误配置错误被黑客利用之前对其进行预防、检测和修复，因此从基础架构即代码 (IaC) 到开发生命周期的每个阶段都需要部署有效的基于策略的自动化。 CI/CD 到运行时。
下面我列出了来自云专业人士的七项建议来实现这一目标。
1. 建立对环境的可见性。
云安全是关于你的云的知识，并拒绝你的对手访问该知识。如果你不了解云环境的完整状态，包括每个资源、配置和关系，那么你正在招致严重的风险。跨云平台建立并保持对云环境的全面可见性，并持续评估每次更改的安全影响，包括潜在的爆炸半径风险。
你不仅会获得更好的安全态势，还会使你的开发人员能够更快地行动，合规专业人士会感谢你提供的主动审计证据。
2. 尽可能使用基础设施即代码。
除了少数例外，你没有理由构建和修改基础架构之外的任何云基础架构，即代码和自动化 CI/CD 管道，尤其是对于任何新事物。使用 IaC 不仅为云操作带来了效率、规模和可预测性，还提供了一种检查云基础设施预部署安全性的机制。当开发人员使用 IaC 时，你可以为他们提供在部署之前检查其基础架构安全性所需的工具。
如果你正在运行多云环境，那么像Terraform这样被广泛采用的开源 IaC 工具可能是你最好的选择。云服务提供商提供的 IaC 产品是免费的，如果你不需要多云支持，则值得考虑。
3. 尽可能使用基于策略的自动化。
任何有以人类语言表达的云策略的地方，都会引起解释和实施错误的差异。适用于你的云环境的每项云安全和合规策略都应以可执行代码的形式表达和执行。使用策略即代码，云安全变得具有确定性。这样可以有效地管理和实施安全性，并帮助开发人员在开发过程的早期获得安全性。
避免将专有供应商策略作为代码工具，并选择开源策略引擎，例如Open Policy Agent (OPA)。OPA 可以应用于任何可以生成 JSON 或 YAML 输出的东西，这几乎涵盖了所有云用例。
优先考虑不需要针对 IaC 和运行云基础架构使用不同工具和策略的解决方案。
4. 使开发人员能够安全地构建。
对于云，安全性是一个软件工程问题，而不是数据分析问题。云安全专业人员需要工程技能并了解整个软件开发生命周期 (SDLC) 的工作原理，从开发到 CI/CD 和运行时。开发人员需要工具来帮助他们在 SDLC 早期获得安全性。让安全成为发展的先见之明和密切的伙伴，而不是只关注部署后问题的事后考虑。
对安全团队进行云工程实践培训不仅能让他们更好地掌握防御现代云威胁所需的技能，而且他们还将获得宝贵的技能和经验，以帮助他们推进职业生涯。你将提高团队保留率并更好地将你的组织定位为理想的工作场所。
5. 锁定你的访问策略。
如果你还没有正式的访问和管理云环境的策略，那么现在是时候创建一个了。使用虚拟专用网络 (VPN) 来加强与关键网络空间（例如，亚马逊虚拟私有云或 Azure 虚拟网络）的安全通信。使 VPN 访问可用或需要，以便团队可以访问公司资源，即使它们位于不太受信任的 Wi-Fi 网络上。
工程师倾向于创建新的安全组规则或 IP 白名单，以便他们可以访问云中的共享团队资源。频繁的审计可以证明虚拟机或其他云基础设施没有面临额外的风险。监督创建堡垒主机，锁定源 IP 范围，并监控不受限制的 SSH 访问。
在 AWS、Azure、GCP 和其他公共云中，IAM 充当普遍网络。遵循最少许可原则，并利用Fugue 最佳实践框架等工具来识别合规检查可能遗漏的漏洞。让 IAM 更改成为你的更改管理流程的一部分，并利用特权身份和会话管理工具。
采用“默认拒绝”的心态。
6. 标记所有云资源。
在整个云足迹中实施资源标签并建立有效的标签约定。使用标签是帮助你跟踪和管理云资源的最佳方式之一，但你需要建立标签约定并强制执行。使用人类可读的资源名称，并包括每个资源的联系人、项目名称和部署日期。
如果云资源未正确标记，则应将其视为高度可疑并终止。
Microsoft Azure在云资源标记约定方面有很好的资源。
7. 确定平均修复时间 (MTTR)。
衡量你的风险和云安全的有效性是你如何确定你的立场和你想去的地方。最重要的衡量标准是你的平均修复时间。你可能不知道你当前的 MTTR 是多少安全关键的云资源配置错误（很少有云客户会这样做），你应该改变它。为以分钟为单位的 MTTR 设定目标，如果自动修复对你的团队和环境来说不是一个可行的选项，请调整你的流程以确保你的团队能够在黑客发现关键漏洞之前检测和修复它们。
展望未来
随着云使用的增长，你的环境的复杂性以及保持其安全的挑战将会增加。黑客正在使用自动化在几分钟内识别和利用云错误配置，因此首先避免配置错误至关重要。通过为你的开发人员配备基于策略即代码的自动化工具，你将能够扩展你的安全工作以应对这些新挑战，而无需扩展安全人员数量。而且，你在云中的移动速度将比在数据中心中的移动速度更快。
原文标题：7 ways to avoid a cloud misconfiguration attack
原作者：Josh Stella
