如何避免安全架构设计的“经典”反面模式？

Posted 2021-04-10 互联网安全内参

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了如何避免安全架构设计的“经典”反面模式？相关的知识，希望对你有一定的参考价值。

1.介绍

2.术语

3.反模式1：“向上访问”管理模式

4.反模式2：管理平面越权

5.反模式3：背靠背防火墙

6.反模式4：在云上构建“本地部署”解决方案

7.反模式5：不受控制且未被监控的第三方访问

8.反模式6：无法打补丁的系统

介绍

在英国国家网络安全中心（NCSC），我们的技术专家为中小型企业和大型机构提供顾问服务，协助他们建立安全的网络和系统。

本文介绍了在系统设计时经常会遇到、但应当避免使用的一些常见反面模式。我们将揭开它们背后的思路，阐述这些模式的缺陷，最重要的是，提出更好的替代方案。

本文的目标读者是负责设计大型机构系统的网络设计师、技术架构师和安全架构师。对于小型机构内的技术人员也有帮助。

术语

开始介绍之前，让我们先简单了解一下相关术语。

反模式

术语“反模式”现在用来代指对一个常见问题的任意重复(但无效)的解决方案。为了对应 "设计模式：可复用面向对象软件的基础"这本开创性的书，Andrew Koenig创造了这个词。

信任

计算机系统很少是孤立存在的。也就是说，它们需要连接到网络以及其他系统。您可能更信任其中的一些网络和系统，但这些网络和系统的所有者可能根本不信任您的系统。我们用到以下术语：

较不可信（或低侧）指的是我们不太信任系统的完整性
较为可信（或高侧）指的是我们较为信任系统的完整性

信息技术vs运营技术

在提到信任和完整性时，我们认为信息技术的管理方法与运营技术的运营方法有大致相似的要求。下面是比较典型的信息技术示例，但我们认为其中的许多理念也适用于运营技术领域。

反模式1："向上访问"管理模式

当使用较不可信的系统来管理较为可信的系统时。

遗憾的是，使用“向上访问”来管理系统的方法太常见了。这表明日常实践并不总是最佳实践。在这种场景下，即使需要通过"堡垒机"或"跳板机"来访问，进入目标系统的最简单途径之一就是使用管理员的终端设备。

在计算机系统中，完整性是至关重要（无论是处理个人信息或财务信息的数字服务，还是工业控制系统），如果您不信任用来管理或操作系统的设备，您就不能信任该系统的完整性。

有一种常见的误解，认为堡垒机或跳板机是这种情况下注入信任的好方法，即以某种方式使您信任管理员在不可信的设备上所采取的行动。然而这是不可能的。

堡垒机对于帮助监控和分析管理员正在执行的操作是很有用的，它们还有助于避免为管理目的而在系统外部暴露多个协议。但它们无法帮助您确信设备上的用户就是您打算允许访问的人。暗地里，用于对跳板机进行身份验证的凭证可能已经被泄露（考虑到设备可信度较低，这是一个合理的假设）。即使管理员使用双因子来验证他们的会话，恶意软件仍然有可能对远程桌面或shell连接进行会话劫持，就像劫持网上银行会话一样。获得访问权限后，攻击者就能以管理员身份执行其他操作，从而控制整个系统。

如何识别这种反模式

以下是三种可以识别“向上访问”管理模式的方法：

寻找从较不可信的系统中通过远程桌面(或远程shell)执行的管理活动。
寻找外包或远程支持等第三方人士使用远程桌面或shell进入网络的连接。如果您信任第三方使用的设备的完整性，那么这就不是一个“向上访问”问题，但如果您对他们系统的信任不及您的系统，那么这就是一个“向上访问”问题。
此外，任何可浏览网页或阅读外部邮件的设备都是不可信的。因此，如果您发现一个管理员在浏览网页（或读取外部电子邮件）的同时使用远程桌面或shell进行管理操作，那么这也属于向上访问。

推荐做法："向下访问”

对于生产系统，应该始终使用完整性可信的设备进行管理。这些设备需要保持上网卫生（即它们完全不该用来浏览网页或打开外部电子邮件，因为这些操作对于设备来说是很危险的）。

如果为了方便，您想在同一个设备上做这些事情，那么我们建议您采用"向下访问"的方式来做。在“向下访问”模型中，风险较大的活动是在隔离的处理环境中进行的。隔离的强度可以根据您的需求进行定制，但目标是确保即使较不可信环境中的活动泄密，攻击者仍无法对较为可信的环境进行任何管理操作。

有很多方式可以构建“向下访问”的方法。您可以在管理设备上使用一个虚拟机来对较不可信的系统进行操作。或者您可以通过远程桌面或shell协议向下访问到一个远程机器上。这个思路是：如果某个不干净的（较不可信的）环境被入侵，由于处理堆栈中它并不在干净环境之内，因此恶意软件操作者就无法访问您的干净环境。

反模式2：管理平面越权

当网络中数据平面的分层防御可以被管理平面短接时。

有一种良好的做法是将管理流量与网络上的普通数据或用户流量分开。在某些系统架构中，这被称为数据平面与管理平面相分离。然而，虽然人们通常使用网络控制来分离这些类型的通信，但有一种常见的错误做法是只将深度防御的概念应用于数据平面。管理旁路的意思就是：如果相对于数据平面，从管理平面更容易夺取计算机系统的"皇冠明珠"（指最宝贵的权限/数据，译者注）。

如何识别这种反模式

寻找系统中隶属于不同分层组件的管理接口，且这些接口都连接到同一个用于管理、却没有相应分层的交换机上。

推荐做法：在管理平面中进行分层防御

解决方案很简单：在管理平面构建类似于数据平面的分层防御。良好的实践包括：

从较为可信的设备进行管理，向下访问到较低的信任层级。
使用独立的堡垒机来管理每个信任边界内的系统。
在不同的层级使用不同的凭证，以帮助防止横向移动。
限制数据平面上的系统与管理平面上的基础设施进行通信，反之亦然。

反模式3：背靠背防火墙

当两台（或许来自不同制造商的）防火墙串联来实施相同的控制措施时。

似乎有一个江湖传说：为了安全收益而“加倍”使用防火墙实现同一套控制措施是值得的。有些人还认为，这两台防火墙最好来自不同的制造商。他们的想法是：某一台防火墙的漏洞不太可能出现在另一台防火墙上。根据我们的经验，这几乎总是增加了额外的成本、复杂性和维护开销，但却没有什么益处。

让我们来探讨一下为什么背靠背防火墙几乎在所有情况下都没有益处。以OSI 3/4层防火墙为例。它的工作原理很简单：控制哪些网络通信可以通过设备，哪些不能。把两个3/4层防火墙串联起来，类似于用两个笸箩而不是一个笸箩来沥干煮熟的土豆—这只会带来更多的清洗工作。

但是，如果在某个防火墙中存在一个可以被利用的漏洞呢？嗯，是的，这是有可能的。毕竟大多数产品都有漏洞。但是，防火墙通常不会在处理TCP/IP报文头部时发生代码执行而产生可以被利用的漏洞。而它们的管理界面往往存在漏洞，所以不应该将它们的管理界面暴露在不可信的网络中。

即使防火墙的数据平面接口中发现了漏洞，如果在补丁发布后便迅速应用补丁，这也意味着任何攻击都需要利用0day漏洞，而不是已知的漏洞。此外，深度防御设计意味着：单单一个防火墙漏洞，不足以导致敏感数据泄露或关键系统的完整性遭到破坏，而在大多数系统的威胁模型里，攻击者的能力水平还远远达不到使用两个0day进行攻击。

拥有两台防火墙也会使管理开销增加一倍，如果您拥有两个不同的供应商，那么您需要同时具备两个供应商的专业知识，这还将增加更多的成本和复杂性。另外，您还要维护更多的基础设施，而我们大多数人都认为：要跟上一套网络基础设施的补丁就已经很困难了。

然而在一个例外中我们发现两套防火墙很有用：用于支持不同双方之间的合约接口。我们将在本节的末尾介绍这种例外情况。

如何识别这种反模式

在网络架构图中寻找两个串联的防火墙。

推荐做法：只做一次，一次做好。

一台维护良好、配置良好的防火墙或网络设备要比两台维护不良的设备好。我们还建议采用以下规范做法。

避免将网络设备的管理界面暴露在不可信的网络中，并妥善管理网络设备所使用的凭证。
使用简单的配置策略，以减少引入错误的机会。
使用配置管理工具来确保您了解正确的配置，这样您就可以发现错误的配置（意味着系统被攻陷或者内部人员未遵循变更流程的标志）。

例外情形

使用两台背靠背防火墙更有意义的例子就是作为相互连接的两个实体之间的合约执行点。如果双方就各自网络中的哪些子网可以使用哪些协议进行通信达成一致，那么双方就可以通过在各自管理的防火墙上应用商定的控制措施来实现。

反模式4：在云上构建"本地部署"解决方案

当您在公共云中构建与您自身数据中心一致的解决方案时。

企业在向公有云迈出第一步时往往会犯这样的错误：在公有云的IaaS基础上，构建他们在自己本地场所内同样的东西。这种方法的问题是，您将继续面对您在本地基础设施中遇到的大部分相同问题。尤其是，您会承担大量用于修补操作系统和软件包的维护开销，并且可能无法从预期的云计算弹性伸缩特性中获益。

如何识别这种反模式

发现：

在计算实例上安装的数据库引擎、文件存储、负载均衡和安全设备。
隔离的且7*24小时运行的开发（测试、参考、生产等）环境。
在不考虑云原生控制是否合适的情况下使用的虚拟设备。

推荐做法：使用高阶功能

除非您在测试和部署操作系统补丁方面比公有云供应商更快，否则最好放手让他们来做这些。将他们的操作系统补丁记录与您自己的记录进行比较，然后就能得出结论。

同样，在为数据库引擎（或其他存储服务）打补丁时，他们提供的高度抽象PaaS产品的维护水平很可能会让许多大型企业都羡慕不已。使用这样的高层次的服务意味着：

可以减少不必要的基础设施管理开销
您可以专注于您组织（业务/架构）的独特之处
您的系统更容易被修补，以避免已知的安全问题

反模式5：不受控制且未被监控的第三方访问

在没有任何限制或监控措施的情况下，第三方不受限制地进行远程接入来管理或操作系统。

许多组织将其部分或全部系统支持工作外包给第三方。这不一定是一件坏事，但一定要了解并处置其中的相关风险。如果把管理或运维工作外包，您将依赖另一个组织来保障您的系统安全。第三方的员工、流程和技术都需要被仔细考量。

我们举个例子。假设您采购了一些小众技术并附带了一份专家支持合同，供应商需要远程接入来支持设备。在这种情况下，供应商仅需要访问待支持的组件，而不需要访问您系统的任何其他部分。如果您提供的堡垒机开放访问所有内部网络（并且依赖应商的流程规范来限制他们自身只访问由他们支持的组件，而不是从技术上强制保证），那么供应商的系统（或您的堡垒机）被攻陷后将会带来更严重的危害。

通过限制这些访问权限，并对连接进行有效的审计，就可以大大降低第三方入侵的风险。

如何识别这种反模式

通过在网络拓扑中寻找"脐带"，通常可以确定与第三方的关系。

推荐做法：优良的合同文本、受限的访问权限以及详细的审计线索。

良好的做法包括以下几点：

慎重选择第三方单位，签订合理的合同，并规定关于您需要信赖的人员、流程和技术的控制措施。
遵循最小权限原则来限制访问权限；只允许远程受信用户拥有对系统的合理访问权限。
确保您拥有审计线索，用于事件响应以及有效的保护性监控。当遇到事件响应时，您是否能够对哪些命令是由第三方供应商的哪个用户执行的做到胸有成竹？

在为第三方设计远程访问解决方案时，我们还推荐以下良好实践。

询问您的供应商：如何防止攻击者在他们的其他客户以及您的系统之间横向移动。
确保远程支持人员使用多因子认证，并确保他们不共用凭证—这在发生违规事件时将有助于您界定个体行为的责任。
为不同的第三方提供独立且隔离的第三方接入系统。
考虑使用即时管理方法，只对当前正在处理的支持工单启用远程管理接入。

反模式6：无法打补丁的系统

当系统由于需要保持7*24小时不间断运行而无法打补丁。

有些系统需要7*24小时运行。缺乏预见性可能意味着：在未安排大量停机时间窗口的情况下，系统无法应用安全补丁。根据技术和复杂性的不同，可能需要几个小时（或几天）的窗口来应用补丁，这会是令运维人员无法忍受的停机时间。随着时间的推移，由于之前选择了推迟应用安全补丁，导致您在维护窗口期需要应用大量的补丁。而现在应用如此之多的补丁已经变得风险很大，所以您陷入了一个恶性循环：这个系统几乎无法修补。

如何识别这种反模式

寻找缺少冗余的系统架构。那些需要所有组件每时每刻运行的系统不适合分阶段升级，因为分阶段升级要求系统在维护期间仍能保持运行。

缺少典型的开发环境或参考环境（或快速搭建环境的能力）也可能会带来问题。如果系统所有者不相信开发环境或参考环境与生产环境相似，那么就会担心打补丁会影响稳定性。

推荐做法：设计"简易"的维护方法，少量但频繁地进行维护

NCSC的设计原则之一是设计易于维护的系统。在某些系统中，这意味着确保可以分阶段对系统打补丁，而不会中断运行。虽然这可能需要较高的基础设施成本，但考虑到以下因素，全生命周期成本可能会更低。