零信任:假定入侵的三大战略要素

F5生态系统 | 2023年4月13日

如今,零信任已成为网络安全领域的热门话题,但每当我提到零信任思维的一个关键理念,即假定已遭入侵时,仍会有人投来异样的目光。我认为,这种反应可能源于两种顾虑。首先,一些安全从业者可能会将其理解为一种极度悲观的世界观。他们对“假定已遭入侵”的理解大概是:“所以,你是说我们都在劫难逃。既然如此,那就干脆放弃,连尝试都不必了。”另一些人或许更为自负,他们可能会说:“好吧,你们的系统或许会遭到入侵,但我的安全防护坚不可摧,攻击者绝不可能突破我的防线。”

我的本意并非上述任何一种极端观点,而是要强调,我们应当真正认识到在数字世界中运营的现实:安全事件难免发生,因此在设计任何安全系统时,都可以且应该将这一点纳入考量。这并不是什么新概念。世世代代的工匠和技术工人早已接受这一理念,我们应当从他们积累的智慧中汲取启发。

水管工、电工以及其他在现实环境中工作的专业人员,早已深刻理解“假定失陷”的真正含义。他们需要打造能够在现实环境中可靠运行的解决方案,因此会自然地接受并在工作中考虑这样一个简单的事实:故障必然会发生。他们也明白,故障并不代表其技能不足,也不意味着不应再使用其服务。恰恰是那些技艺精湛的专业人员,能够认识到自己的成果终有一天会出现故障,从以往的故障中吸取经验,并预判未来可能出现的故障。

最近,我就遇到了这样一次故障:家中的一条污水管在排水通道中段堵塞了。这栋房子已有30多年,因此出现故障,也就是发生“失陷”,并不意外。毕竟,任何系统经过长时间运行后,发生失陷的可能性都会接近100%。

这正是关键所在。无论是应用安全解决方案,还是我家的管道系统,都应预见到随着时间推移可能会出现故障。此外,将“我家的管道系统永远不会出故障”作为家庭维护策略,与认为“我的网络防御永远不会被攻破”同样不妥。

因此,无论是水管工还是网络安全从业人员,都应考虑如何应对最终难免发生的故障,也就是安全防线被攻破。

“假定已遭入侵”理念的三大战略要素

应对物理系统或网络系统故障的有效策略通常包含三个组成部分。

  1. 可见性。确保具备足够的可见性,以便尽快发现故障。如果浴室排水管漏水后一直无人处理,下方的底层地板就会腐烂并滋生霉菌,而这些问题可能数月甚至数年后才会被发现。又或者,二楼浴室地板下的接水盘溢水、石膏板吸水饱和后,人们才发现楼下空间的天花板在滴水。在这两种情况下,问题都是在初始故障发生一段时间后,并且在造成额外的次生损害之后才首次被发现。假定故障或入侵必然发生的首要原则,是在故障发生后尽快提供清晰的潜在失陷迹象,最好还能针对可能发生的故障主动发出通知。例如,依靠集水坑泵排水的地下室通常装有传感器,当水位超过预设阈值时便会发出警报。在其他情况下,如果无法针对所有可能的故障模式主动发出警报,则应开展例行维护检查,例如每半年检查一次热水器。在网络安全领域,这意味着应用安全架构必须包含经过周密设计和测试的遥测策略,将最重要的故障模式纳入考量,以便及时了解任何潜在入侵。实际应用中,应采用AISecOps实践,将遥测数据流式传输至分析和通知工具,同时将其持久化存储到数据存储中,以供日后使用。应使用AI和警报工具来提高成效、为相关人员提供背景信息,并确保及时响应。应从持久化数据中汲取经验,为今后进一步增强稳健性提供参考。 
  2. 稳健性。解决方案必须具备绕过故障或缩短故障持续时间的机制。在此情境下,常见的稳健性模式包括:(a)优雅降级;或(b)冗余。具体选择取决于系统能否在组件降级的情况下继续运行。热水器等一些系统可以同时采用这两种模式。例如,我的热水器使用泵驱动的循环系统,确保热水随时可用。但如果泵发生故障,我仍然可以使用热水,只是需要多等一会儿。另一方面,如果加热线圈传感器发生故障,导致加热元件无法关闭,则可能引发灾难性故障,因此需要采用冗余措施,例如安装泄压阀。应从多个系统范围考虑稳健性。例如,如果范围仅限于排水管线,负责商用级解决方案的水管工可能会安装两条冗余排水管线,这样任一管线发生故障都不会导致排水系统无法使用。另一方面,从系统抽象层面进行设计的架构师可以在系统级设计冗余,例如在附近增设一个水槽或马桶。这样做还有一个好处,即不仅能应对排水管堵塞,还能应对更多故障模式。冗余在网络安全领域当然也很常见,许多安全设备采用主动/备用(完全冗余)或主动/主动(优雅降级)模式部署。不过,网络安全领域与物理世界略有不同。首先,网络安全领域存在具有明确意图和智能的主动攻击者,因此故障很少由自然原因引起。第二个更显著的区别在于规模。软件是虚拟的,而非实体,因此遵循“一次编写,多处部署”的模式。这一特性非常有利于扩展,但也意味着核心软件组件中的代码漏洞很可能会影响系统中该代码的所有实例。因此,网络安全稳健性解决方案还需要避免单点故障以及同类元素的整体故障,这种策略有时称为“纵深防御”。多因素身份验证就是这一理念在实践中的典型示例。每个因素的故障模式(即遭到攻破的方式)各不相同,仅攻破其中任一因素都不会导致整个系统遭到攻破。
  3. 遏制。限制故障的影响范围(即波及区域)至关重要。正如我们承认故障或安全事件难免会发生一样,也必须承认,我们无法完全避免单点故障,也无法为每项功能要求都构建冗余。因此,架构师还应考虑如何尽量降低故障的影响,并将修复工作量和故障后果作为衡量方案优劣的两个重要指标。例如,管道工可以在排水管道的关键位置增设清扫口,以缩短修复时间。对于后果更严重的故障,承包商可能会选择PVC排水管,而不是镀锌排水管,以便更轻松地修补管道泄漏,减少修复工作量。家庭管道系统通常会安装截止阀,以限制已检测到的故障所造成的后果,从而防止洗手台柜和地板受到连带损坏。在网络安全领域,对应的概念是隔离性、可维护性和模块化。隔离性旨在尽量减少连带损害或阻止损害继续扩大。一种良好做法是构建可充当断路器的基础设施,并采用微分段等技术。可维护性是指在可行的情况下,提供一条快速且省力的路径,使系统从受入侵状态恢复到未受入侵状态。例如,重启因内存溢出攻击而受入侵的工作负载,可能是一种有效但并不彻底的缓解方法。模块化是指在构建系统时,使功能相当的组件能够轻松替换。这样,当维护不可行或不足以解决问题时,可以尽量减少修复所需的工作量。

这些是我在应对安全事件方面总结的一些良好实践,但肯定还有其他做法。更重要的是,负责保护应用的开发人员和安全专业人员需要认识到,防护疏漏在所难免,安全事件也必然会发生。因此,如何规划和应对这些失效,与如何尽量降低其发生频率同样重要,也同样值得深思熟虑。

归根结底,评判我们的标准不仅是安全事件发生的频率,还包括当此类事件不可避免地确实发生时,我们的应对是否得当。

分享

相关博客文章

SOAS 2025:目标不一致,结果难出色
F5生态系统 | 2025/05/13

SOAS 2025:目标不一致,结果难出色

AI部署缺乏协调会导致效率低下。了解如何协调安全、自动化和部署策略,充分释放AI潜力。

AI应用的应用交付与安全:驾驭现代AI架构
F5生态系统 | 2024/08/22

AI应用的应用交付与安全:驾驭现代AI架构

了解生成式AI应用和API安全如何塑造现代应用交付与安全。

借助多云网络简化超级云
F5生态系统 | 2023/09/13

借助多云网络简化超级云

超级云不只是一个流行词。它代表着一种简化愿景,以多云网络为起点,支持跨云提供商的混合IT。

2023年应用策略现状:成本与复杂性是推动多云网络发展的首要因素
F5生态系统 | 2023/03/15

2023年应用策略现状:成本与复杂性是推动多云网络发展的首要因素

多云网络解决方案可在核心、云和边缘环境之间实现无缝、安全的互联,为解决当今混合IT面临的挑战提供支持,因而备受业界关注。

运营演进的必要性
F5生态系统 | 2022/01/11

运营演进的必要性

在数字化成为默认模式的世界中,运维仍然过度依赖人工方式,需要不断演进,才能支持自适应应用。这一演进要求整个IT体系进行重大变革,并具备由AI赋能的自适应能力,以保持可用性、优化性能并保障安全。

多云并非简单使用多个云:让跨云衔接更轻松
F5生态系统 | 2021/10/07

多云并非简单使用多个云:让跨云衔接更轻松

随着企业转向互联云战略,工作负载的管理和保护变得日益复杂。了解F5如何满足市场对多云网络新方法的需求。