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

点击 蓝字 关注我们

01

02

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

反模式

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

信任

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

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

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

信息技术vs运营技术

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

03

如何识别这种反模式

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

1. 寻找从较不可信的系统中通过远程桌面(或远程shell)执行的管理活动。

2. 寻找外包或远程支持等第三方人士使用远程桌面或shell进入网络的连接。如果您信任第三方使用的设备的完整性，那么这就不是一个“向上访问”问题，但如果您对他们系统的信任不及您的系统，那么这就是一个“向上访问”问题。

3. 此外，任何可浏览网页或阅读外部邮件的设备都是不可信的。因此，如果您发现一个管理员在浏览网页（或读取外部电子邮件）的同时使用远程桌面或shell进行管理操作，那么这也属于向上访问。                        

推荐做法："向下访问”

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

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

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

04

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

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

• 从较为可信的设备进行管理，向下访问到较低的信任层级。

• 使用独立的堡垒机来管理每个信任边界内的系统。

• 在不同的层级使用不同的凭证，以帮助防止横向移动。

• 限制数据平面上的系统与管理平面上的基础设施进行通信，反之亦然。

05

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

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

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

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

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

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

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

如何识别这种反模式

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

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

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

• 避免将网络设备的管理界面暴露在不可信的网络中，并妥善管理网络设备所使用的凭证。

• 使用简单的配置策略，以减少引入错误的机会。

• 使用配置管理工具来确保您了解正确的配置，这样您就可以发现错误的配置（意味着系统被攻陷或者内部人员未遵循变更流程的标志）。

例外情形

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

06

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

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

如何识别这种反模式

发现：

• 在计算实例上安装的数据库引擎、文件存储、负载均衡和安全设备。

• 隔离的且7*24小时运行的开发（测试、参考、生产等）环境。

• 在不考虑云原生控制是否合适的情况下使用的虚拟设备。

推荐做法：使用高阶功能

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

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

• 可以减少不必要的基础设施管理开销

• 您可以专注于您组织（业务/架构）的独特之处

• 您的系统更容易被修补，以避免已知的安全问题

07

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

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

• 慎重选择第三方单位，签订合理的合同，并规定关于您需要信赖的人员、流程和技术的控制措施。

• 遵循最小权限原则来限制访问权限；只允许远程受信用户拥有对系统的合理访问权限。

• 确保您拥有审计线索，用于事件响应以及有效的保护性监控。当遇到事件响应时，您是否能够对哪些命令是由第三方供应商的哪个用户执行的做到胸有成竹？

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

• 询问您的供应商：如何防止攻击者在他们的其他客户以及您的系统之间横向移动。

• 确保远程支持人员使用多因子认证，并确保他们不共用凭证—这在发生违规事件时将有助于您界定个体行为的责任。

• 为不同的第三方提供独立且隔离的第三方接入系统。

• 考虑使用即时管理方法，只对当前正在处理的支持工单启用远程管理接入。

08

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

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

• 更少次数、更短时间的停机

• 降低泄密风险（泄密可能导致高昂的事件响应成本）