在一段简短的创建视频解说和评论中 ，Snyk首席架构师 、安全开发首家云安全SaaS公司Fugue的云架创始首席执行官Josh Stella ，就针对云环境的构的个步攻击者为何如此容易避开企业的安全措施向业务和安全领导者提供建议 ，并讨论创建固有安全云架构的创建五个关键步骤 。
云计算网络攻击不像好莱坞惊悚片中的安全场景 。没有人会慢慢把汤姆·克鲁斯放进预选目标的云架安全数据中心 ，该中心配备了超灵敏的构的高防服务器个步噪音、温度和运动探测器 ，创建以便他可以窃取特定的安全文件 。
现实生活中的云架剧本要平淡得多 。攻击者坐在笔记本电脑前 ，构的个步部署自动化技术扫描互联网，创建寻找可利用的安全漏洞 。他们得到的云架是一个虚拟的目标“购物列表” ，可以从中选择 ，建站模板一旦进入云环境 ，他们就会利用体系结构的弱点来查找敏感数据 ，如个人识别信息(PII)，并在几分钟内提取出来，通常是从对象存储服务或数据库快照中提取出来 。
听起来很简单 ，很容易防范 ，但根据刚刚发布的2022年版Verizon年度数据泄露调查报告(DBIR)，“错误配置错误的上升始于2018年 ，主要是由于云数据存储的实施没有适当的源码下载访问控制……尽管主要云提供商努力使默认配置更加安全(我们对此表示赞赏)，但这些错误仍然存在。”
攻击者无法穿越安全团队可以使用传统入侵检测和预防解决方案和流程监控的传统网络。企业正试图用昨天的数据中心安全技术来挫败今天的云攻击者 ，但他们对云威胁的前景还不完全了解 。
通常 ，重点是识别攻击者可以利用的资源配置错误来进入环境 ，并分析日志事件以识别可疑活动“危害指标”(IOC) 。这些可能是身份和访问管理(IAM)配置中的免费模板更改 ，以提升权限 ，关闭加密以访问数据，或记录以覆盖个人轨迹 。这些都是任何云安全工作所必需的活动 ，但最终它们还不足以保证云数据的安全 。错误配置只代表了黑客进入云环境并破坏API控制平面的途径之一 ，几乎每一次重大的云破坏都会发生这种情况 。
花这么多的时间和精力来发现和消除单一资源的错误配置并不能回答“当它们通过并进入控制平面时会发生什么?”因为请放心 ，云计算他们迟早会的 。
没有一个企业云环境不存在错误配置 。云安全团队通常每天都会发现并修复数十个或数百个 。仅仅专注于识别IOC以阻止正在进行的攻击的风险更大;在团队有机会做出响应之前 ，云破坏可能会在几分钟内发生 。即使有最好的监控 、分析和警报工具，你也只能指望很快发现自己被黑客攻击了 。
新的威胁格局开发人员和工程师越来越多地使用基础设施即代码(IaC) ，该代码针对云提供商的应用程序编程接口(API)进行操作，源码库以在其工作时实时构建和修改其云基础设施 ，包括安全关键配置 。云中的变化是恒定的 ，每次变化都会带来错误配置漏洞的风险 ，攻击者可以使用自动检测快速利用该漏洞 。
控制平面是配置和操作云的API表面 。例如 ，您可以使用控制平面来构建容器 、修改网络路由 ，以及访问数据库中的数据或数据库快照(这是黑客比入侵实时生产数据库更常见的目标) 。换句话说，API控制平面是用于配置和操作云的API集合 。
将任何成功的云穿透事件的潜在爆炸半径最小化 ，意味着在环境的架构设计中防止控制平面受损 。
安全云架构的五个步骤任何组织都可以采取五个步骤来设计其云环境 ，使其在本质上能够安全地抵御控制平面泄露攻击：
1 、将控制平面泄露风险降至最低 。现在是时候将“云错误配置”的定义从单一资源错误配置扩展到包括架构错误配置的时候了 ，这些架构错误配置涉及多个资源以及它们之间的关系。
对于现有云环境，通过分析资源访问策略和IAM配置来评估任何潜在渗透事件的爆炸半径 ，以确定攻击者可以利用的过度许可设置进行发现 、移动和数据提取 。当您找到它们时——相信我 ，您会找到它们的——与您的开发人员和DevOps团队合作，在不破坏应用程序的情况下消除这些架构错误配置 。这可能需要一些返工来解决现有环境中的这些漏洞，因此最好在设计和开发阶段解决体系结构安全问题 。
2 、采用策略作为云基础设施的代码 。策略即代码(Policy as code ，PaC)是一种用机器可以理解的语言表达策略的方法 ，如开放策略代理、开源标准和云原生计算基础项目 。
在软件定义的世界中 ，安全性的角色是领域专家，他向构建人员(开发人员)传授知识，以确保他们在安全的环境中工作 。不是规则手册或清单 ，而是代码。记住，是开发人员在云中构建应用程序和应用程序的基础设施。这一切都是通过代码完成的，因此开发人员(而不是安全团队)拥有这个过程。PaC使团队能够用编程语言表达安全性和法规遵从性规则 ，应用程序可以使用该语言检查配置的正确性 ，并识别不需要的条件或不应该出现的情况 。
使所有云涉众能够安全地运行 ，而不会对规则是什么以及应该如何应用规则产生任何歧义或分歧，这有助于在单一的策略真相来源下协调所有团队 ，消除解释和应用策略时的人为错误 ，并在软件开发生命周期(SDLC)的每个阶段实现安全自动化(评估 、实施等) 。
3 、使开发人员能够构建安全的云环境 。IT团队提供物理基础设施并将其提供给开发人员的日子一去不复返了 。如今 ，开发人员和DevOps工程师使用IaC表达他们想要的基础设施并自动提供 。
虽然这对于高效的云操作非常有用 ，但它增加了大规模传播漏洞的风险 。然而 ，IaC的采用为我们提供了一个前所未有的机会 ：能够在部署前检查基础设施安全 。有了PaC ，我们可以为开发人员提供在开发过程中检查安全性的工具，并指导他们设计固有的安全环境 ，以最大限度地减少控制平面泄露威胁 。每个人都可以更快 、更安全地移动 。
4 、使用护栏以防止错误配置。无论您在通过IaC检查和更安全的设计“扩展”云安全方面有多成功 ，错误配置仍然可能会漏掉，部署后云资源的变异是一个持续的风险。
您应该在持续集成和持续交付(CI/CD)管道中构建自动安全检查 ，以自动捕获部署过程中的错误配置 ，并在构建未通过安全检查时自动失败 。对于敏感度较低的部署 ，请提醒团队注意违规行为 ，以便他们可以在必要时进行调查和补救 。由于部署后对云资源的更改非常普遍 ，因此保持连续的运行时监控以检测漂移是至关重要的。确保运行的内容反映了创建它的IaC模板 ，并检查危险的错误配置事件和可能包含漏洞的孤立资源 。在所有这些用例中 ，您采用PaC将继续支付红利。
5 、构建云安全架构专业知识 。企业云采用率的不断提高 ，要求安全专业人员将注意力从传统的安全方法(如威胁检测和监控网络流量)转移开来 ，以了解控制平面泄露攻击是如何工作的 ，以及如何有效地使用安全架构设计来防止它们。
为了做到这一点 ，组织需要云安全工程师和架构师 ，他们可以与开发人员和DevOps团队密切合作，了解云用例 ，并帮助在开发过程中建立安全的设计原则 。
保护云环境的最终目标是在任何成功的初始攻击渗透事件发生之前使其变得毫无意义 。毕竟，如果攻击者无法从企业云环境中获得任何资源 ，谁会在乎攻击者是否能够访问该资源?
让您的安全团队学习云应用程序如何工作 ，以帮助确保云基础设施支持应用程序 ，而不会带来不必要的风险。他们还需要知道如何利用PaC来检查环境中更深层次的多资源漏洞，并帮助指导开发人员设计和构建本质上安全的环境 。
技术雷达站
