从最基本的层面上来讲，安全性中的所有事物都可归结为主体和对象。对象是所保护的事物，而主体是可能威胁对象安全的事物。在身份验证（核对您的身份）、授权（授予某个事物的访问权限）以及审核（跟踪谁访问过什么）中使用了这两种结构。从本质上来说，这些概念非常简单（如图 1 所示）。
图 1 一位用户尝试读取某个文件
主体是执行操作的事物，而对象是主体对其执行操作的事物。并且，有时主体的操作对象又是另一个主体。
在安全性方面，Windows 支持一些非常丰富的语义并且极大地扩充了主体和对象的定义。主体可能不仅仅只是用户，其表示远比基本用户标识符要复杂得多。
在 Windows 中，安全主体不仅包括典型的主体（即可视为用户），还包括组和计算机。安全主体是可向其分配一个安全标识符 (SID) 并授予其某些访问权限的任何事物。
在本期的安全观察中，我将介绍如何在 Windows 中表示和使用主体。
主体/对象/操作聚合
对安全性的管理往往涉及到主体/对象/操作聚合。主体是尝试对某个对象执行某种操作的行动者。例如，一位用户可能尝试访问某个文件，如图 1 所示。当用户尝试读取文件时，操作系统需要检查对象（文件）上是否设置了权限，允许主体（用户）对该特定对象执行操作（读取）。如果存在相应权限，则访问请求成功。否则，将拒绝访问请求。这听起来非常简单。
安全主体的类型
基于 Windows 的系统以及基于 Windows 的网络中的主体—或者安全主体（之后我将这样称呼它们）—远不止是用户。但是，用户仍是最基本的概念。
|
大小写问题 在 Windows 文献中，出现包含大写字母 "A" 的单词 "Administrator" 或 "Administrators" 时，通常分别指代用户或组。若均以小写字母形式拼写 ("administrator") 则指代具有管理权限的某个用户帐户或人员。其他实体也适用这一原则，如 "Guest" 和 "guest"。 |
用户 用户是登录计算机的某个独立实体。从根本上来说，所有安全主体都与用户至少有点相关。Windows 中可能存在以下两类用户：本地用户和域用户。本地用户是在计算机的本地安全帐户管理器 (SAM) 数据库中定义的。每个基于 Windows 的计算机都有本地 SAM，它包含了该计算机上的所有用户。
人们通常认为域控制器 (DC) 没有本地 SAM，因而没有本地用户。然而，这种观点是错误的。即使是 DC 也有本地 SAM，只是其 SAM 中的帐户只能在目录服务还原模式下使用。#p#
本地 SAM 始终至少包含以下两个用户帐户：Administrator 帐户和 Guest 帐户，并且 Guest 帐户始终默认处于禁用状态。
在所有版本的 Windows Server 2008（除了 Windows Small Business Server 2008）中，默认启用 Administrator 帐户并且在首次登录计算机时必须使用此帐户。在 Windows Vista 中，默认禁用 Administrator 帐户并且只能在非常严格的环境中使用它。
在这两种情况下，均应为即将管理指定计算机的每个人至少创建两个帐户。如果受到各种规章制度的约束（并且您可能就是此类人员），则这是必要条件。对于每位用户，一个帐户应为用户自己的个人管理帐户。另一帐户是用户执行非管理任务时使用的个人非管理帐户。
并非本地用户的用户为域用户 这些用户在域的 DC 上定义。本地帐户和域帐户之间的区别主要在于帐户范围的不同。域帐户可在域中的任意计算机上使用，而本地帐户仅在定义它的计算机上有效。并且，与本地帐户相比，域帐户拥有大量与其相关的属性（请参见图 2 和图 3 进行比较）。
图 2 本地帐户的属性窗口
图 3 域帐户的属性窗口
域帐户拥有更为丰富的一组语义，包括组织环境中的各种属性：如电话号码、管理关系以及电子邮件帐户。域帐户在网络中的作用更大，因为可在整个网络的计算机上使用它们并向其分配权限。此外，在域中定义帐户简化了管理过程，因为现在只在一个地方维护帐户即可。#p#
计算机 计算机就是另一种类型的用户。在 Active Directory 中，这一特点尤为鲜明，且经过了继承模型的证实。计算机承袭的继承结构如图 4 所示。
图 4 Active Directory 中显示用户和计算机关系的继承层次结构
图 4 中展示了多个非常有趣的地方。首先，如您所见，Active Directory 中的所有类均派生自根类 Top。实际上，即使是 Top 也被视为 Top 的子类。其次，User 类由 organizationalPerson 类派生而来。再次（也是最有趣的地方），Computer 类由 User 类派生而来。换句话说，在面向对象的环境中，Computer 是一种用户类型。以这种方式人性化计算机实际非常有意义，因为计算机也需被视为主体并与人拥有几乎完全相同的属性。
组 您应该还记得，主体是尝试访问某个对象的事物。操作系统通过检查对象的权限来确认这一访问尝试。很早之前，操作系统设计者就意识到将每个对象的权限分配给需要它的每位用户非常困难。为解决这一问题，设计者允许用户成为组成员。这样，除了用户外，还可将权限分配给组。
组可能并非用户，但组仍是一种安全主体，因为就像用户和计算机一样，它可以拥有标识符。在 Windows 中，用户可以是多个组的成员，并且对象可将权限分配给多个组。组还可以嵌套，只是存在一些限制。
非域控制器只有以下两种类型的组：内置组和管理员定义的本地组。但在 Active Directory 中有以下六种不同的安全组：内置域本地组、内置全局组、内置通用组、用户定义的域本地组、用户定义的全局组以及用户定义的通用组。
对于域本地组，只能将其定义域中资源的权限分配给它们。但是，它们可包含任意受信域或林的用户、通用和全局组以及自身域中的域本地组。
全局组只能包含在其定义域中的用户和全局组；但是，可将此域所在的林或任意信任林中任意域内的资源的权限分配给它。
通用组可包含任意域的用户、通用组和全局组。对于通用组，可将任意信任域或林中的资源的权限分配给它。换句话说，通用组是域本地组和全局组之间的一种混合体。
尽管默认情况下工作站仅带有两个组—Administrators 和 Guests—域却带有所有这三种类型的组，并且数量相当多。图 5 显示了域中的默认组。所有组均被指定为安全组，即意味着可向其分配权限。（不要将安全组与 Microsoft Exchange Server 用于在电子邮件列表中分组用户的通讯组相混淆。两者均是在 Active Directory 中定义的。）所有基于 Windows 的计算机上存在的本地组都是在 DC 上的 Active Directory 中进行定义的。#p#
图 5 在 Active Directory 的 Users 容器中定义的默认组
与 DC 一样，一些非 DC 也有很多组。图 6 显示了测试计算机上的 16 个内置组。任意指定计算机上组的具体数目各不相同，具体取决于已在该计算机上安装的角色。
图 6 某个非 DC 上的内置组（单击图像可查看大图）
如果打算分配某个对象的权限，您还会发现更多的组，比我目前为止所展示的要多。实际上，一个基本的 DC 上存在着 63 余个组和内置安全主体，如图 7 所示。#p#
在图 7 中所显示的 63 个组中，大部分都是代表动态安全主体组的抽象概念（有时也称为“特殊身份”）。有时，它们也被称为登录组。
登录组 登录组是代表安全主体的某个动态内容（如用户或其他安全主体的登录方式）的组。例如，图 7 中所示的 INTERACTIVE 组包括通过终端服务登录计算机控制台的所有用户。相比之下，NETWORK 组包括通过网络登录的所有用户。根据定义，一位用户一次只能是其中一个此类组的成员，并且组中的成员是在登录时才指定的。可使用此类组向以某种特定方式登录的所有用户授权，但却无法控制谁将成为此类组的成员。
图 7 一个基本的 DC 拥有 63 余个组和内置安全主体
其他一些组也具有此项本性。特别需要注意的是 Everyone 组和 Authenticated Users 组。顾名思义，Everyone 组包括访问该计算机的每位用户，但是，从 Windows XP 起，其中不再包括完全匿名且未经身份验证的用户。换句话说，在任意受支持的基于 Windows 的操作系统上，声名狼藉的 NULL 用户并不包括在 Everyone 组中。但 Guests 却包括在内。
Authenticated Users 组也是动态填充的，它仅包括那些经过实际身份验证的用户。因此，Guests 并不包括在 Authenticated Users 中。这就是这两个组之间的唯一不同之处。但由于操作系统上唯一的来宾帐户处于禁用状态，Authenticated Users 与 Everyone 之间并不存在功能差异；除非可能由于希望 Guests 可以访问资源并因此需要 Everyone 组完整无缺时，手动启用了 Guests 帐户。
尽管如此，还是有许多管理员由于“世界上的每个人都有权访问我的服务器”这一事实而花费了大量时间，并且采取了非常极端的措施来修改权限以期矫正这一情形。这些修改通常会带来彻底的灾难。无论如何，没有理由尝试用 Authenticated Users 的权限替换 Everyone 的权限。如果希望来宾有权访问您的计算机，可启用 Guest 帐户；否则，需保持该帐户的禁用状态。如果确实希望来宾拥有访问权限，可使用 Everyone 权限。否则，Everyone 组与 Authenticated Users 组没有任何区别。
有些人认为执行此类更改是“深层防御”更改。如果将“深层防御”定义为“无法以任何其他方式证明的更改”，则的确如此。实际情况是此类修改在安全方面的改进极少甚至毫无改进，而是会带来极大的风险。最好让默认值保持原样。#p#
如果以上论述的说服力不够，请参阅 Microsoft 知识库文章 885409（“安全配置指南支持”）。简而言之，它声明大规模的权限替换可能致使支持合同无效。执行此操作时，您基本上构建了自己的操作系统，而 Microsoft 无法再保证其可以正常运行。
内置 Users 组与 Authenticated Users 之间的区别也有必要专门加以指出。这一区别之处非常明显：Authenticated Users 包含通过身份验证可以访问计算机的每位个用户，包括位于不同域的用户、Users 组以外的本地组的成员用户以及不是任何组成员的用户（是的，此类情况完全可能出现）。这意味着 Users 组的限制远比 Authenticated Users 严格。
尽管如此，我仍看到过有的组织因为想要“强化自身的系统”而尝试将 Users 的权限替换成 Authenticated Users 的权限，导致破坏了整个网络。我一直在与昏庸的 PCI/DSS 审核者进行争论，他们宣称支付卡行业要求把所有 Users 权限替换成 Authenticated Users 权限。这种做法毫无可取之用。
我也支持世界各地的组织抵制那些将整体替换访问控制列表 (ACL) 视为赢取宝贵时间的最有效方法的顾问。毫无疑问，任何将 Users 或 Everyone 整体替换成 Authenticated Users 的尝试都会极大地损害安全性和稳定性。
服务
Windows Vista 和 Windows Server 2008 都支持一种新的安全主体类型：服务。为了解这些实体有多大价值，以目前对基于主机的防火墙的讨论为例。销售产品的供应商大力为许多人灌输了一种观点：即推崇基于主机的防火墙必须过滤出站流量，因为这样可防止网络的其余部分受到问题计算机的影响。更多客观的人们指出：如果某台计算机已遭到破坏，恶意软件已进入该计算机，因此恶意软件有能力完全绕开或禁用基于主机的防火墙。
要了解出现此类情况的原因，以作为相同安全主体运行的两个服务为例。允许服务 A 通过防火墙实现通信，但不允许服务 B 这样做。如果服务 B 遭到了破坏，攻击者只需通过接管以该安全主体身份运行的另一进程（如服务 A）就可绕开该限制，并改为通过该进程进行通信。
为解决这一问题，Microsoft 需要利用某种方法以将权限应用于进程，或者更具体地说是服务。为此，服务变成了其自身权限的安全主体。这使得每个服务现在都拥有应用权限所用的标识符。可通过在命令行运行 "sc showsid" 命令来查看任意服务的服务 SID。
通过使用服务 SID，可限制特定进程对资源的访问，而非仅限制特定用户的访问。在某些情况下，这一变化使得基于主机的防火墙出站过滤非常有意义。此类情况的具体性质超出了本文的讨论范围，但如果有兴趣了解更多此方面的内容，建议阅读我在 2008 年 6 月刊的《TechNet 杂志》中撰写的有关 Windows Vista 防火墙的文章（请参阅“管理 Windows Vista 防火墙”）。
结束语
安全主体是众多 Windows 安全性的基础，因此所有的管理员都有必要至少基本了解各种安全主体的工作原理以及它们的使用方法。只有理解这些主题后，您才能有效地创建可充分利用这些安全主体的安全策略。有时，某些对安全主体一无所知的人希望您做出不必要且错误的更改，而那些更改可能危及网络的正常运行，在驳斥这些观点时，这一知识将非常有用。
本专栏系根据我的《Windows Server 2008 安全资源工具包》(Microsoft Press) 一书中的材料撰写而成。
