云技术的应用改变了企业开发软件的方式。
它加快了软件部署的速度，改变了基础设施的管理方式，也影响了工程团队的运作模式。同时，它还改变了安全防护的格局。
那些曾经运行在少数几台固定服务器上的应用程序，如今已经可以在容器、Kubernetes集群、API、无服务器函数以及多个云服务提供商上运行。
许多组织在短短几年内，从拥有寥寥几项基础设施资源发展成了拥有数千项资源的庞大体系。然而，尽管基础设施发展迅速，但渗透测试的方法却往往没有随之改变。
这就导致了一种日益严重的不匹配现象：传统的渗透测试方法原本是为变化缓慢的环境设计的，而云环境却并非如此。
系统可以在几分钟内被创建出来，又会在几分钟内被销毁；新的代码每天都会多次进入生产环境。基础设施正变得越来越动态且分布广泛。
问题并不在于传统渗透测试已经不再有用，而是它的效果已经不足以满足当前的需求了。
在本文中，您将了解到为什么传统的渗透测试方法在现代云环境中会遇到种种困难，了解云基础设施是如何改变安全防护模式的，以及各组织是如何朝着持续进行安全验证的方向发展的。
我们还会探讨在实际操作中，持续渗透测试意味着什么，以及自动化技术与人力专家如何共同发挥作用。
先决条件： 对虚拟机、容器、API以及CI/CD管道等云计算概念有基本的了解会有帮助，但并不要求具备任何渗透测试方面的经验。
我们将涵盖以下内容：
传统渗透测试方法是为稳定环境设计的
多年来，渗透测试一直遵循着相同的流程：企业首先确定测试范围，聘请安全专家进行评估，收到评估报告后采取相应的措施，几个月后再重复这一过程。
在传统环境中，这种运作方式效果良好。基础设施相对稳定，应用程序的变化频率也较低，生产系统具有足够的可预测性，因此对某一时间点的评估能够在较长时间内发挥作用。
对于金融机构而言，可能每个季度都会进行一次重大系统升级；而对于企业级应用来说，每年只会发生几次变更。在这种情况下，渗透测试能够有效地反映当前存在的风险状况。
然而，云环境打破了这一假设。
如今，那些运行在微软Azure或亚马逊Web Services等云平台上的企业，可以在一周内完成数百项系统变更。基础设施团队会使用自动化工具来迅速创建新的测试环境，而工程团队则依赖那些持续演进的微服务架构。
等到渗透测试报告出炉时，部分环境已经发生了变化。
安全团队实际上是在试图防御一个不断变动的目标。
基础设施的快速发展导致攻击面急剧扩大
随着组织规模的扩大，云系统往往会变得更加复杂，而非变得更简单。
一家小型初创企业可能最初只拥有几台虚拟机和一个数据库；而大型企业则会逐渐积累各种API、无服务器应用程序、容器集群、身份认证系统、第三方集成方案、持续集成/持续交付流程，以及跨地区的部署环境。
每一项新服务的推出都会带来新的安全挑战：
-
谁有权访问这些资源？
-
目前有哪些权限设置？
-
哪些API是对外公开的？
-
哪些应用程序在内部进行通信？
-
敏感信息被存储在哪里？
-
上周有哪些配置发生了变化？
手动回答这些问题变得越来越困难。
真正的挑战不在于资产的数量，而在于它们变化的速度。
传统的渗透测试是针对已知系统和明确的范围进行的；而云环境则会不断产生新的测试对象和范围。
这种差异至关重要。
安全团队可能会成功检测出当前存在的安全问题，但却会忽略那些未来会出现的新风险。
多云环境使得安全监控更加困难
如今，许多组织已经不再在单一的环境中运作。
出于成本、功能或业务需求的不同，不同的团队可能会将应用程序部署在不同的云平台上。开发团队往往会独立做出技术决策，而企业并购也会引入全新的基础设施架构。
结果就是，各种环境之间变得相互孤立且碎片化。
某家企业可能会在亚马逊Web Services上运行应用程序，在微软Azure上处理分析任务，而内部系统则部署在其他地方。每种环境都会采用不同的安全模型、日志记录机制、身份认证方式以及运营流程。
保持一致性变得非常困难。
如今，安全团队面临的不仅是有测试方面的问题，还有可见性方面的问题。
挑战不再仅仅是发现漏洞，而是要弄清楚究竟应该在哪些环节进行测试。
大型企业经常会发现一些被遗忘的环境、被弃用的API、未被利用的资源，或是安全团队根本不知道存在的基础设施。
传统的渗透测试假定人们能够完全了解系统状况，但云环境往往恰恰相反。
速度会带来安全漏洞
工程团队总是致力于提升交付速度，这种做法确实很有道理——更快的迭代速度确实能创造商业价值。
像GitHub和New Relic这样的公司提供的工具，帮助团队快速发布新功能，并持续监控应用程序的运行状况。
然而，速度也会带来一些意想不到的副作用。
那些基于人工审核的安全流程往往会成为瓶颈。当开发团队每天进行十次部署时，安全团队根本无法手动检查每一处变更。
这就导致了艰难的权衡：要么延迟发布进程以确保安全性，要么在缺乏充分验证的情况下强行推进发布。
这两种做法都没有好的结果。
企业们往往会发现一个现实：软件交付能力的提升并不会自动带来安全操作效率的提高。
旧有的流程最终会在高负载环境下崩溃。
云基础设施本质上是临时性的
传统的系统通常会长期处于运行状态。
但云基础设施却有所不同。
容器可能只会运行很短一段时间，之后就会被替换掉；自动扩展系统会在流量高峰时创建资源，高峰过后又会将其删除。开发环境会不断地出现和消失。
有些资源可能只存在几个小时，而有些则可能仅存活几分钟而已。
这种情况给定期安全评估带来了严重挑战——比如在周一进行的渗透测试，很可能无法检测到周三新创建的基础设施。
当环境本身在不断变化时，针对固定环境进行测试的做法就变得不再可行了。
安全团队现在越来越需要持续性的监控，而不仅仅是定期审查。
问题也发生了变化：从“我们是否对这部分进行了测试？”转变为“我们如何才能知道哪些地方发生了变化？”
这其实代表了一种完全不同的运作模式。
安全团队需要的不仅仅是报告
传统的渗透测试通常以生成一份报告作为结束。
这份报告会列出检测结果及其严重程度，工程团队随后会根据这些信息来安排修复工作的优先级。
这种做法往往会造成延迟，因为检测结果与实际运行系统之间的关联性不强，团队还需要手动将问题录入工作流程中。安全和工程部门往往也是分开运作的。
现代工程组织越来越期望安全措施能够直接融入开发流程中。
安全问题分析需要具体的背景信息、明确的负责部门以及相应的优先级安排。最重要的是，这些分析结果必须能够自然地融入工程团队的日常工作方式之中。
如果几周后才提交一份PDF报告，那么这种处理方式显然与持续部署的理念背道而驰。
如今，安全工作越来越像是一门工程学科，而不再是一种孤立的审查流程。
向持续渗透测试的转变
持续渗透测试代表着组织在应对安全威胁方式上的重大变革。与过去将渗透测试视为每年仅进行几次的定期活动不同，如今许多团队已经将安全验证视为一个与不断变化的基础设施同步进行的持续性过程。
这种做法结合了实时监控与自动化技术，以便随时了解云环境当前的安全状况。安全团队不再追问“上个季度是否进行了评估”，而是关注自己是否能够准确、实时地掌握自身所面临的安全风险。
这意味着需要持续收集来自整个系统环境的安全信息。这些信息包括新部署的互联网服务、身份与访问管理权限设置的变化、存在漏洞的容器镜像、泄露的敏感信息、配置错误的存储账户、基础设施代码中的缺陷、依赖关系中的安全风险，以及异常的认证或网络活动等等。
通过实时监控这些信息，团队可以在安全问题出现后立即发现它们，而无需等到下一次定期评估时才采取行动。
其中许多检测工作都是自动完成的。云安全平台、漏洞扫描工具、基础设施代码分析工具以及持续集成/持续交付流程能够不断识别新的安全风险、扫描配置信息、找出常见的漏洞、检测泄露的凭证，并监控那些可能增加系统安全风险的变更。
现代安全平台并不会生成孤立的安全分析结果，而是会整合来自多个来源的信息，从而突出那些真正构成威胁的问题。
不过，这并不意味着完全不需要人类的专业判断。经验丰富的安全专家仍然在验证漏洞是否真的具有利用价值、理解业务背景、将多种安全风险串联成真实的攻击路径、确定修复工作的优先级，以及进行自动化工具无法完成的深入分析等方面发挥着至关重要的作用。
不同之处在于，那些重复性高、工作量大的任务越来越多地被自动化处理了，这使得安全团队能够把更多时间用于研究那些需要人类智慧来评估的复杂安全风险，而不是把时间浪费在发现显而易见的问题上。
像XBOW这样的平台恰恰反映了这一更为广泛的变革趋势。随着云环境规模的不断扩大以及其动态性的日益增强，各组织越来越需要能够持续监控不断变化的基础设施状况，并实时了解自身的安全防护状态，而不能再仅仅依赖定期的安全评估流程。
我们的目标并非取代人类工作者，而是让安全专家们能够将他们的专业知识应用于那些最能创造价值的领域，而自动化技术则可以处理现代云基础设施所带来的大规模和高速度的处理需求。
云技术改变了规则
真正的问题并不在于安全团队突然变得效率低下，而是环境本身已经发生了变化。
传统的渗透测试方法是在基础设施稳定、部署流程可预测、边界相对固定的环境中发展起来的。
而云系统的运行方式截然不同：基础设施会持续发生变化，各种资源会迅速出现或消失，开发周期也会显著加快，其覆盖范围的增长速度远远超出了传统手动处理流程的能力。
十年前那些行之有效的安全防护措施，如今已经与现代云环境的实际情况产生了矛盾。
那些能够及早意识到这一变革趋势的组织，正在重新审视他们的安全运营方式。他们正在摒弃孤立式的评估方法，转而采取持续监控的安全策略。
因为在云环境中，风险本身就不是静止不变的，因此安全防护措施也必须具备动态性。
希望您喜欢这篇文章。您可以通过在LinkedIn上与我联系。