要想控制运行在业务环境中的所有应用听起来似乎像是不可能完成的任务，而且平心而论，达成这一目标确实需要投入大量精力。我们需要制定管理政策以限制软件安装与执行，并利用工具确保这些政策得到切实贯彻，而不至于像行政管理工作那样“蜻蜓点水”般一带而过。整个流程需要以探索的态度组织试验、发现错误，然后才能逐步推开。不过只要能从实践中积累经验，这样的处理方式也将给我们带来诸多回报，其中包括：
恶意软件几乎会得到彻底根除。但凡没有获得批准或列入白名单的应用程序都不允许执行。
由用户安装未受审核的应用（例如iTunes与Dropbox）所引发的桌面系统支持难题将大幅减少。
针对数据泄露的保护机制得到增强，因为用户无法使用那些没有与组策略设定相匹配的应用程序，也就无法绕开企业预先制定好的安全政策。
在本文中，我将带大家一同了解如何在Windows客户计算机中对软件安装及执行实施控制。除非特殊说明，否则我提到的一切操作方式都基于Windows Server2008及后续版本，因此各位不必担心由于使用第三方工具而带来额外的许可开支。另外，我还会为大家总结各套方案的优势与缺点。
限制Windows安装程序
如果您是一位二八开原则的忠实拥护者，完全可以利用20%的精力对Windows安装程序做出简单限制，从而获得80%的管理控制成效。我们最常见的处理方式通常是借助组策略。创建一个组策略对象（group policy object，GPO），右键点击进行编辑，并在弹出的组策略对象编辑器窗口中依次找到计算机配置——>管理模板——>Windows组件——>Windows安装程序。
双击窗口右侧的“禁用Windows安装程序”选项，为了保证Windows安装程序只能接受组策略中所列出的应用程序对象，请点击“只针对未管理应用”。大家也可以直接点击“始终有效”来禁止Windows安装程序处理包括获得许可的应用在内的所有软件。
这套方案的弊端在于只能影响到通过Windows安装程序进行安装的软件。很多知名软件都拥有独立的安装工具，在这种情况下管理政策将无法有效控制其安装与执行。除此之外，GPO在针对业务环境下特定设备子集时效果也不理想，尤其是在某些用户拥有本地管理员权限时——此类权限意味着我们信任其安装应用程序的操作。话说回来，虽然存在各种局限，这种处理方式至少堪称“聊胜于无”，而且确实可以预防某些用户的违规操作。
不过我个人还没见过哪种病毒或者恶意软件会通过Windows安装程序进行传播，因此如果大家希望能在对抗这类威胁时拥有额外的防御机制，这套方案恐怕帮不上什么忙。
#p#
软件限制策略
软件限制策略（简称SRP）允许我们通过推行组策略来控制特定程序的执行。除了能作用于现有业务环境之外，SRP还是一套非常适合终端服务器或公共资讯支持设备的管理方案。在它的帮助下，用户将只能使用特定的某一项功能，且无法利用管理软件或下载来自互联网的应用程序与实用工具。
Windows能够通过不同方式正确识别软件的限制与放行标准。Hash规则就是其中之一，它会识别程序中文件与可执行文件的特征，而后为其生成一套hash算法。
Hash机制对于识别同款程序的特定版本方面表现出色，因为hash值会随着文件的变更而有所不同（程序新旧版本之间必然存在文件差异）。
验证规则会通过数字签名识别软件，这一点在保护授权脚本方面极为重要。Windows系统还能通过软件的路径与互联网区域（IE浏览器内部）识别软件身份，进而严格控制软件下载活动的安全性。
最后，Windows系统可以创建规则、帮我们揪出那些无法通过受信列表或其它管理规则明确界定的软件对象。Windows将程序与规则相比照以确认对方是否符合软件限制GPO要求，如果同一款程序符合多套管理规则，系统会为其匹配最核心的规则。
这些策略功能强大，但正如我在本文开头所提到，每套方案都有自己的弱点：除非大家能精心为用户可能需要的每个Windows可执行文件创建例外规则（包括其应用程序），否则SRP的介入会令整套业务系统变得相当迟钝。
SRP还可能给创建安全环境所必要的用户登录脚本带来麻烦。如果大家决意采取这套方案，那就必须在实验环境下提前对所有限制策略与例外清单进行全面测试。另外还要提醒各位：当我们为特定软件创建限制GPO时，请务必确保将域管理员组加入GPO的访问控制清单当中，而且GPO不可拥有应用组策略的权限。这么做是为了将策略本身的控制权交给管理员，而不至于在关上门之后才发现自己也被锁在了外面。
在做好创建策略的准备工作后，请遵循以下步骤：
为每套限制策略创建新的GPO，一旦我们在实际应用中发现限制过严，就可以轻松禁用对应策略。
通过计算机配置或用户配置将限制规则应用至设备或用户端，具体流程为策略——>Windows设定——>安全设定——>软件限制策略。
右击软件限制策略，在弹出的功能菜单中选择新的软件限制策略。
设定一套默认识别规则：在窗口左侧点击“安全级别”，右击某一安全级别然后在弹出的功能菜单中选择“设为默认”。
现在，我们需要创建一套判断软件是否符合限制约束标准的规则。右键点击窗口左侧的“额外规则”，点选“新验证规则”后从“新Hash规则”及其文件审计模式、“新互联网区域规则”及其区域审计模式、“新路径规则”及其文件模式或者注册表项等方案中做出选择。
在窗口右侧，双击“执行”选项。现在我们来看看这些限制究竟如何生效。推荐大家使用以下选项：“全部软件文件例外库”将帮助我们避免关键性系统及应用程序功能文件受到阻断。“全部本地管理员例外用户”则表示Windows系统只会在本地管理员组之外的用户当中严格执行限制策略。
接下来在窗口右侧双击“指定文件类型”，我们需要在其中审查并添加软件限制策略中涉及到的应用程序文件扩展名。这份列表需要非常完整，而且在必要的情况下请大家确保企业所使用的脚本语言也拥有对应的文件扩展名关联。
最后，在窗口右侧双击“受信发布者”。在这里我们可以指定普通用户、本地管理员或者企业管理员是否有权决定开放数字签名程序的可信性并对其进行控制。
大家可以在任何版本的WindowsXP、Windows Vista、Windows7或者Windows8系统中使用SRO，不过作为其后续方案，AppLocker的功能无疑更为丰富——这也正是我们接下来要讨论的重点。AppLocker目前只在售价最高的Windows7或Windows8操作系统客户端中出现。
#p#
AppLocker
微软公司将AppLocker描述为“WindowsServer2008R2与Windows7中出现的一项新机制，为软件限制策略带来功能与特性上的全面提升。AppLocker包含的新功能与扩展能力允许用户根据独一无二的文件验证手段创建应用程序控制规则，并可以指定哪些用户或群组有权运行这些应用程序。”
但简单来说，AppLocker基本就是经过健身训练的SRP。也许其中最出彩的两项特性要数根据目前已经安装的软件自动创建规则以及AppLocker的“纯审计”运行模式。这意味着它能够在无需管理人员手动设定策略的前提下自主判断一款应用程序可以放行还是该被关禁闭。在初始设置与故障排查等情况下，这样的功能显然非常贴心。
我们可以在组策略中使用AppLocker。首先创建新GPO，对其右键点击以进行编辑，然后按照计算机配置——>Windows设定——>安全设定——>应用程序控制策略与AppLocker的流程找到这项新机制。
以下截图显示了AppLockerGPO的使用界面，其中显示了规则执行配置以及哪些规则正处于适用状态。
Windows Server 2008 R2中的AppLocker组策略对象界面
AppLocker与SRP相比更容易从白名单起步加以部署，这是因为它能够对相关设备进行自主配置。举例来说，我们刚刚搭建好一套设备环境，其中尚未设定任何限制、也没有安装任何业务环境中的常用软件。只要完成最基本的计算机设置（例如企业环境下必不可少的流程——部署镜像），我们就可以让AppLocker自动为其生成规则，而规则本身又能通过信息收集识别系统中可信的软件可执行文件。最后，大家只要将这些规则导入生产组策略环境中以备规则网络使用即可。
AppLocker的弊端在哪里？首先，它只能运行于Windows7旗舰版、Windows7企业版或者Windows8专业版当中，所以如果大家还在使用WindowsXP——甚至在跟Vista打交道——那么AppLocker恐怕没法帮到您了。不过我们可以先从已经采用了Windows7的设备上入手，先行体验AppLocker的实际表现；而后再慢慢迁移，让新系统自动接纳来自组策略的管理规则。在这种情况下，安全性只取决于我们何时全面部署Windows7或者Windows8。
总结
只要听到“白名单”这个字眼，大家的第一反应很可能是：这好像是份麻烦的活儿。事件也的确如此。不过对未经授权的软件进行安装与执行限制能带来诸多回报——正如我在前文所提到，而且也能免去在网络及业务环境中不断进行补丁安装与软件升级的麻烦。（一旦限制机制太过松散，用户很可能随意下载并安装软件，从而导致业务环境中的软件版本千奇百怪。另外，以Java为代表的‘顽劣’应用往往存在安全漏洞，而IT部门对于未经批准的软件很难提供集中化的补丁安装方案。）
依靠Windows自带的工具，再加上一点点聪明才智，大家完全可以不花一分钱让自己的系统安全性更上一层楼。
国外有句俗语，叫做“但凡值得做的事都值得做好”，诚不我欺也。
附：关于用户账户控制的一点意见
大家可能在想，为什么现有Windows版本（包括WindowsVista及其后续版本）都会提供用户账户控制（简称UAC）机制。这套机制最著名的特色就是在我们访问系统中的敏感内容或是尝试执行可能给系统完整性带来影响的操作时弹出确认对话框。
对于一些（或者说大部分）应用程序而言，单凭UAC限制机制来实现权限许可就已经足够了。用户无法安装那些尝试访问或将内容写入受权限保护区域的软件，除非他们拥有超级管理权限。
不过某些软件的正常安装机制（也就是并不涉及系统敏感区域的机制）也有可能触发UAC保护。另外，某些实用工具还可能会在可执行文件中绑定运行时间库或者动态分发机制，而非利用常规的安装规程。
进一步来讲，以谷歌Chrome以及流行的文件共享工具Dropbox为代表的某些程序会直接被安装在用户的个人配置空间当中；UAC无法针对这类情况提供保护。最后，UAC几乎不能在安装流程结束后再对软件的执行加以控制；UAC一般只在软件执行过程中涉及权限操作时才会起效。
如果大家希望对所有类型的软件都拥有限制能力，或者控制系统中的软件执行流程，那么UAC并不算是理想的解决方案；我们需要通过其它途径对计算环境中的软件安装与执行进行管理。
