HW期间，为防范钓鱼，即日起FreeBuf将取消投稿文章的一切外部链接。给您带来的不便，敬请谅解~

IBM X-Force始终秉承“以事件响应为中心”，使客户始终处于网络安全体验的最前沿，其中包括在云原生环境中进行响应。

那么，什么是“云原生”（Cloud Native）？云原生这个概念最早于2013由Pivotal公司的Matt Stine首次提出。2015年，云原生刚推广时，Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：12因素、微服务、自敏捷架构、基于API协作、扛脆弱性；到了2017年，Matt Stine在接受采访时又改了口风，将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理6特质；而Pivotal最新官网对云原生概括为4个要点：DevOps+持续交付+微服务+容器。

之后在2015年夏天，Linux基金会创建了云原生基金会CNCF。CNCF在宣布成立时也没有一个关于云原生的具体定义。只是提到了一些相关的技术，包括开源，容器，微服务，编排工具。

可以说，时至今日，关于云原生并没有一个明确的定义，每个人都有自己不同的注解。在IBM，其将云原生应用程序和基础架构定义为“由离散的、可重用的组件（称为微服务）组成，旨在集成到任何云环境中。这些微服务充当构建块，通常打包在容器中。微服务作为一个整体协同工作以组成一个应用程序，但是，每个组件又都可以通过自动化和编排流程进行独立缩放，不断改进和快速迭代。”

随着云原生已经成为许多组织IT基础架构规划的关键部分，我们认识到所有相关功能都需要扩展到云原生中，这包括事件检测及响应过程，因为这些事件极可能影响这些环境。

从物理到虚拟再到云原生

网络靶场的概念诞生于物理时代。如果企业部署了服务器，那么安全或IT管理员将控制物理机箱和机架，包括网络接口卡、硬盘驱动器以及所有其他组件。如果企业运营软件，其将控制其安装的代码。在虚拟和云原生环境中，管理员和安全人员几乎无法控制物理硬件，甚至无法控制在云原生应用程序下运行的原始控制面。这就意味着网络安全方法必须考虑架构、监视和控制方面的关键差异。

从许多意义上讲，虚拟化可能会带来一些复杂性。当组织以混合模式工作时，尤为如此。在这种模式中，组织的一些资产仍在公司内部，但他们也具有基于云的工作负载以及跨多个不同供应商的数据。

随着疫情的持续以及整个员工队伍向远程办公迁移，对云端事件响应功能的需求显然已经变得越来越迫切。我们看到越来越多的攻击者将目标锁定在云原生环境中的薄弱环节，利用流行的平台和应用程序，并在Linux和云环境中运行恶意软件，这些恶意软件通常以Go编程语言编写，以在混合基础架构中运行。

例如，众所周知，Amazon Web Services（AWS）的S3存储系统对于正确地进行安全保护就是一个挑战。它也是云中最流行的对象存储设备，并且公司将继续把敏感数据放入S3存储桶中。结果无疑是面临更大的风险，要么是无意中将存储桶暴露在公开的互联网上，要么像CapitalOne在2019年夏天那样遭受极具破坏性的攻击。在CapitalOne攻击事件中，一位前AWS员工利用配置错误的Web应用程序防火墙（WAF）暴露了超过1.06亿人的信用卡应用程序。

云原生安全性演习有何不同？

在旧时代中，当检测到问题时，安全团队可以选择将受影响的服务器与网络隔离，删除连接，但保留物理机以进行进一步检查和分析。但是，在云原生时代，这些都是不可行的，因为根本不存在需要保留的物理设备。虽然可以从企业网络中删除虚拟实例，但是安全团队并不具备快速简便的方法可以从云提供商的网络中删除物理服务器。事实上，这些做还会破坏许多其他客户的应用程序。

云原生应用程序和体系结构要求以不同的方式来考虑和应对安全威胁。例如，当容器或虚拟机受到威胁时，安全响应团队必须立即冻结并隔离该计算实例，以进行适当的取证，这一点至关重要。这与最初关闭云服务器的冲动想法背道而驰，这种冲动可能会阻止其违规行为，但也会消除进行正确的分析所需的取证追踪。

当DevSecOps团队致力于跨多个云保护其应用程序和基础架构时，这些差异将成倍增加。云之间的安全标准和功能差异很大。例如，像S3等存储服务的默认配置可能具有不同的安全级别。两种云日志文件服务AWS Cloud Trails和Microsoft Azure Sentinel中用于收集和分析云日志文件的标准也有所不同。在AWS和Azure上运行的基础级应用程序编程接口（API）也存在根本差异，这要求与这些API进行通信的开发人员在命令脚本和DevOps工具中使用不同的语言标准以进行持续集成（CI）和连续部署（CD） 。

为了检测潜在的安全事件，适当的监控必须使团队能够看到他们所需保护的整个环境。但不幸的是，在复杂的混合基础架构中，创建一个简单易用的单窗格视图才是真正的挑战。这就是为什么我们经常在企业和政府客户的安全咨询工作中生成此类仪表板和连接层的原因。

除了监控障碍外，团队可用的安全工具和控件在整个云中也可能有所不同。例如，AWS具有三种类型的负载均衡器，它们具有不同的（或没有）Web应用程序防火墙（WAF）。在AWS和Azure上运行的托管Kubernetes服务不允许将WAF轻松地放置在群集的前面。

此外，在内部部署和云中范式之间，安全团队如何使用诸如SafeBreach之类的连续安全控制验证平台也存在很大不同。在云中，大多数应用程序是使用容器技术部署的。容器能够大规模创建不可变且短暂的基础架构的能力使云原生成为可能。因此，在这些演习中，我们针对容器使用攻击模拟，攻击其网络堆栈、安全流程以及安全团队在构建和保护多云环境的过程中必须管理的任何其他攻击面。

向基于容器的安全性转变也扩大了参与者的范围。在这种情况下，开发人员将不断部署代码和应用程序，并控制容器中的内容。由于发布周期快，安全审查往往是自动化的。因此，云原生网络靶场包括来自开发团队和DevSecOps的参与者，而对于传统事件响应团队而言，情况并非总是如此。

将所有资源整合在一个平台

在向客户咨询他们对事件响应培训的需求时，我们听说他们想要一个实践平台，在这里，安全团队不仅可以在混合（传统）实施和云之间，而且可以在多个云之间进行分析、监视和编排。这正是IBM X-Force的云原生网络靶场的推动思想。

在网络靶场中，演习始于紧急触发，例如新闻工作者打来的电话或FBI发出的电子邮件，以告知企业团队的违规行为。这些演习中的漏洞来源可能是公共云中众多攻击点之一。除此之外，我们还确保将不受参与者控制的云部分包括在内，以教会他们如何应对这一“新现实”，以及如何与公共云安全团队进行互动，以最大限度地发挥成功响应的机会，从而尽可能地减少影响。

借助SafeBreach，我们可以运行以容器为中心的攻击手册，来着眼潜在的杀伤链进展，然后重点凸显哪些控件有效，哪些控件失无效。SafeBreach规定的补救措施还可作为改善参与者的云原生安全状态的指南。采取补救措施后，我们将运行同一本手册，以确保控件现在可以按预期运行。

我们构建云原生网络靶场的主要目标之一是帮助安全组织和开发者团队了解在高速部署的分布式应用程序环境中验证安全性的最佳方式。这就要求加强他们的安全代谢，因为如果可以将其纳入CI/CD管道中，而不是作为对妥协指标（IoC）的反应进行添加，那么所需的补救措施实际上能得到更好地执行。

如今，大多数团队已经了解了这一点，但是帮助它们实现并持续存在下去，才是适应这种转变并更改安全立场，以反应新的云原生方式现实的最佳方式。