安全观察跳岛：减少不需要的依赖关系
Jesper M. Johansson
在上个月安全观察的叙述中，我讲过使用 USB 闪存驱动器进行网络攻击的开始步骤。一旦已受感染的 USB 闪存驱动器插入计算机，攻击即开始。恶意代码将随后自动执行或在用户稍有不慎的帮助下（利用一些简单的社交
技巧）执行。虽然这种攻击仍然保持在对工作站的本地攻击层面，但需要清楚的是恶意软件有可能蔓延到网络的其他部分。我在即将出版的新书《Windows Server 2008 安全资源工具包》(Microsoft Press®, 2008) 中详细地讨论了这种网络攻击方式，目前我正在为本专栏修改其中的相关章节。
显而易见的一种保护方式就是禁用可移动驱动器。虽然这种方式很谨慎，但如果真的实行，用户们可能会很不高兴，他们的理由也很充分。除了最敏感的环境中，更好是尝试管理环境中包含的风险并抑制风险暴露。
而且，可移动驱动器并不是威胁客户计算机安全的唯一途径。不知您是否还记得“安全性的十个永恒定律”（可从 microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx 获得）？第 3 条定律依然适用：“如果攻击者对您的计算机具有无限制物理访问权限，那么这台计算机就不再属于您了。”在本讨论中，如果攻击者有权访问您的计算机，则必须认定该计算机已遭到破坏。如果攻击者能够设法使您在自己计算机上运行他的代码，甚至还能远程入侵。您可以将这种情况视为永恒定律的第 1 条：“如果攻击者能够设法使您在自己计算机上运行他的程序，那么这台计算机就不再属于您了。”
可以假定永恒定律仍然有效 — 它们已被证明具有相当普遍的适用性，在我们能够彻底改变计算机的工作方式之前，该定律不可能出现重大变化。因此，考虑一下这些定律如何应用于上述情形，削弱可移动驱动器的功能非常关键。只需要对注册表进行一些调整即可达到目的。
当然，您还必须使用其他保护层。您可以合理地假设许多客户端计算机已经遭到破坏，或者由一些并不总是关心组织最佳安全利益的用户使用。这表示您需要减轻他们对网络其余部分的影响，并提升理解、分析和减少安全依赖关系的重要性。
安全依赖关系的定义
当某台计算机的安全取决于另一台计算机的安全时将产生安全依赖关系。您可能曾经听人们说起如果域控制器 (DC) 已遭到黑客攻击，那您的整个网络都已陷入攻击之中。这种简化说法表明所有域成员的安全性都依赖于 DC。如果 DC 的安全都不能保证，那成员计算机的安全也就无从谈起。如果攻击者能够更改域的安全配置，那么他将可以通过在成员计算机的管理员组添加新帐户（以此为例）的方式接管域内的任何计算机。任何允许管理员对危害妥协的漏洞都不可小觑。因为管理员对所管辖的任何计算机都有完全访问权限。
在计算机系统中，依赖关系不可避免。事实上，它们是既常用又必要的；但是这并不代表所有的依赖关系都可以接受。在本专栏中，我将讨论哪些类型的依赖关系可以接受，而哪些则不可接受，然后我将分析依赖关系的类型及减少依赖关系的方法。在《Windows Server 2008 安全资源工具包》中，我将更加详细地讨论特定的依赖关系及如何对其进行管理。
可接受的依赖关系
通常，当敏感程度较低的系统在安全方面依赖更为敏感的系统时，这种依赖关系是可以接受的。一般来讲，计算机和系统可以根据敏感程度分为几类。（任何特殊环境中的特定类别与此处的一般讨论无关 — 它们的意义在于是固有类别。）为了方便讨论，假定现在有两个类别：工作站和 DC。此时，工作站在安全方面依赖 DC 是可以接受的。DC 比工作站的敏感程度高很多，所以很明显，它应该得到更好地保护。
对于用户帐户也可以得出相同的结论。管理员可以对用户的数据造成影响是可以接受的。这是因为管理员的责任更多，而且拥有对计算机及计算机中包含的所有信息的无限制访问权限（尽管并不总是直接或明显表现出来）。如果您理解这一点并适当管理自己的计算机，这种依赖关系并不会带来任何危害。
甚至软件也可以采用与此相同的方法进行分析。敏感程度较低的软件（如 Web 浏览器）使用并依赖敏感程度较高的软件（如操作系统）当然是可以接受的。如果操作系统有错误，那么 Web 浏览器因为一些新问题而易于受到攻击是意料之中的事，所以很可能处于亟待解决问题列表的较低位置 — 而操作系统和其他关键应用程序和数据将成为主要的焦点。该原理同样适用于错误如何修正或修补程序如何分发的问题 — 应该修正与问题关系最为紧密的错误。这样，修正的保护性影响将得到最大发挥。因此，应该首先修正操作系统自身的错误，而不是先解决 Web 浏览器的问题。
或者，可以通过更改设计去除依赖关系。例如，可以改写 Web 浏览器以减少对操作系统的依赖。安全性更高的组件（本例中为操作系统）实际上绝不会采用安全敏感程度较低的组件（Web 浏览器）所用的方式使用某项功能，在这种情况下，后一种方法更为恰当。
不可接受的依赖关系
根据上述我对可接受依赖关系的解释，不可接受依赖关系的定义现在应该很容易理解。基本上，敏感程度较高的系统应该从不依赖敏感程度较低的系统来保证其安全性。
如果某台工作站受到危害即表明 DC 的安全已遭到破坏，那您将面临严重的安全问题。如果一个网络的总体安全性依赖于网络中每台单独的计算机，那要保护这个网络将成为不可完成的任务。
让我们以统计学方法考虑这个问题。如果网络当中的每台计算机 99.999% 的时间是“安全”的，也许您觉得这个网络已经相当安全了。事实上，此百分比可能远远低于目前除最小型网络以外其他网络的实际情况。但现在假设您的网络当中有 40,000 台计算机，此时任何一台计算机都有 .001% 的可能遭到攻击。打趣点说，您整个网络此时就有 40% 的可能遭到攻击。
并且，即使只有 .001% 的可能，一台计算机还是可以通过不受管理的依赖关系对整个网络造成威胁。在这种情况下，网络到底有多安全？很显然，重点保护更为敏感的系统绝对至关重要。
毫无疑问，用户帐户和软件也是如此。例如，新的 Windows® 终端服务客户端允许您存储用于虚拟透明终端服务登录的用户名和密码。这些凭据使用凭据管理器 API 存储，通过用于主要登录会话的凭据提供保护。
这将产生安全依赖关系。请考虑以下示例：某个网络管理员登录到其个人工作站。她使用此工作站收发电子邮件、浏览 Web，并处理信息工作者的其他常规任务。很自然地，她将使用权限较低的域帐户完成这些工作。
某天的某时，该管理员连接到某台 DC 执行一些管理任务。她使用终端服务客户端执行此任务，并选择存储密码以便以后连接。这将导致至少一个（可能是两个）不可接受的安全依赖关系。第一个是她的域管理帐户凭据现在由其低权限的信息工作者凭据提供保护。如果该低权限的用户帐户遭到破坏，则域管理用户帐户也将遭到破坏，进而危及到整个域。
第二个依赖关系源自她在非域控制器上键入了域管理凭据。除非她的个人工作站与 DC 的受保护程度不相上下（很可能不是这样），否则就会出现 DC 的安全依赖于用户个人工作站安全的依赖关系。举例来说，如果同一办公室内某位心存不满的员工在网络管理员的工作站上安装了击键记录程序，现在就已经捕获了域管理凭据。只要您在非域控制器上键入域管理凭据，整个域就会暴露给非域控制器上的安全漏洞。
现在假设某个攻击者将可移动驱动器插入某台域管理员当前登录、曾经登录过或者将要登录的计算机中。该域管理员将受到影响，进而扩展到整个域都会遭到破坏。必须了解这种情况的危害性才能想办法避免。当然，如果某个安全应用程序依赖另一个安全程度较低的应用程序的功能来执行特定任务，该软件也会遭遇相同的问题。
一种攻击的分析
前面我已经说明了恶意可移动驱动器插入计算机会发生的情况。但是，可能只是清楚地说明了驱动器最初插入的计算机遇到的情况。假设出现问题的计算机已经加入域，如图 1 所示。
图 1** 理想的域依赖关系 **
此处所示的情形展示了最理想的依赖关系。方向性箭头指示从何处继承依赖关系。例如，工作站的安全依赖 DC 的安全，而用户的安全依赖工作站的安全。攻击者也许能够破坏工作站，这可能导致保存在该工作站上的所有用户信息遭到破坏，但危害也仅限于此。
不过，假设登录该工作站的用户是服务器本地管理员组的成员，而且域管理员经常登录该服务器。此时将出现如图 2 中所示的依赖关系。
图 2** 易受攻击的域依赖关系 **
只要更改了登录问题计算机的用户这一假设条件，整个网络的安全性就已经受到影响。由于域管理员登录到该服务器，所以 DC 以及整个域的安全都将依赖该服务器的安全。
如果管理该服务器的安全性和 DC 一样，那这种依赖关系还可以接受。但在本例所示的环境中，登录到工作站的用户是该服务器上管理员组的成员。因此，该服务器的安全将依赖这台工作站的安全性。这意味着整个域的安全都将依赖这台工作站的安全性。那么，试想一下：假如这台工作站上的用户无意之中运行了攻击者的工具会出现什么情况。
当今信息安全领域可能很少有比安全依赖关系更重要的概念了。如果开始分析网络并尝试理解依赖关系，那您很可能会遇到不可接受的依赖关系。在最坏的情况中（这种情况远比您想象中更为常见），整个网络的安全依赖于整个网络 — 换句话说，网络中单台计算机的安全都在一定程度上依赖其他所有计算机的安全。因此，在这种环境下要创建既合理又现实的风险管理策略几乎是不可能的，因为无法控制依赖关系且过于复杂。对这一问题的解决方案是分析并管理依赖关系。
在本专栏中，我仅简要地概述了依赖关系及如何分析和减少依赖关系。您可以从我的新书《Windows Server 2008 安全资源工具包》中获得更多信息。该书用一整章讲述如何通过分析依赖关系，并使用先进的技术（如服务器和域隔离）和比较常见的技术（如管理型帐户管理）管理依赖关系，以便确保网络安全。
衷心感谢 David LeBlanc 为本专栏整理最初构思所提供的帮助。
Jesper M. Johansson 是解决软件安全问题的软件架构师，以及《TechNet 杂志》**的特约编辑。他拥有 MIS 博士学历，并且具有 20 多年安全方面的经验。
© 2008 Microsoft Corporation 与 CMP Media, LLC.保留所有权利；不得对全文或部分内容进行复制.