AppLocker

　　微软公司将AppLocker描述为“Windows Server 2008 R2与Windows 7中出现的一项新机制，为软件限制策略带来功能与特性上的全面提升。AppLocker包含的新功能与扩展能力允许用户根据独一无二的文件验证手段创建应用程序控制规则，并可以指定哪些用户或群组有权运行这些应用程序。”

　　但简单来说，AppLocker基本就是经过健身训练的SRP。也许其中最出彩的两项特性要数根据目前已经安装的软件自动创建规则以及AppLocker的“纯审计”运行模式。这意味着它能够在无需管理人员手动设定策略的前提下自主判断一款应用程序可以放行还是该被关禁闭。在初始设置与故障排查等情况下，这样的功能显然非常贴心。

　　我们可以在组策略中使用AppLocker。首先创建新GPO，对其右键点击以进行编辑，然后按照计算机配置——>Windows设定——>安全设定——>应用程序控制策略与AppLocker的流程找到这项新机制。

　　以下截图显示了AppLockerGPO的使用界面，其中显示了规则执行配置以及哪些规则正处于适用状态。

Windows Server 2008 R2中的AppLocker组策略对象界面

　　AppLocker与SRP相比更容易从白名单起步加以部署，这是因为它能够对相关设备进行自主配置。举例来说，我们刚刚搭建好一套设备环境，其中尚未设定任何限制、也没有安装任何业务环境中的常用软件。只要完成最基本的计算机设置（例如企业环境下必不可少的流程——部署镜像），我们就可以让AppLocker自动为其生成规则，而规则本身又能通过信息收集识别系统中可信的软件可执行文件。最后，大家只要将这些规则导入生产组策略环境中以备规则网络使用即可。

　　AppLocker的弊端在哪里？首先，它只能运行于Windows 7旗舰版、Windows 7企业版或者Windows 8专业版当中，所以如果大家还在使用Windows XP——甚至在跟Vista打交道——那么AppLocker恐怕没法帮到您了。不过我们可以先从已经采用了Windows 7的设备上入手，先行体验AppLocker的实际表现；而后再慢慢迁移，让新系统自动接纳来自组策略的管理规则。在这种情况下，安全性只取决于我们何时全面部署Windows 7或者Windows 8。

　　总结

　　只要听到“白名单”这个字眼，大家的第一反应很可能是：这好像是份麻烦的活儿。事件也的确如此。不过对未经授权的软件进行安装与执行限制能带来诸多回报——正如我在前文所提到，而且也能免去在网络及业务环境中不断进行补丁安装与软件升级的麻烦。（一旦限制机制太过松散，用户很可能随意下载并安装软件，从而导致业务环境中的软件版本千奇百怪。另外，以Java为代表的‘顽劣’应用往往存在安全漏洞，而IT部门对于未经批准的软件很难提供集中化的补丁安装方案。）

　　依靠Windows自带的工具，再加上一点点聪明才智，大家完全可以不花一分钱让自己的系统安全性更上一层楼。

　　附：关于用户账户控制的一点意见

　　大家可能在想，为什么现有Windows版本（包括WindowsVista及其后续版本）都会提供用户账户控制（简称UAC）机制。这套机制最著名的特色就是在我们访问系统中的敏感内容或是尝试执行可能给系统完整性带来影响的操作时弹出确认对话框。

　　对于一些（或者说大部分）应用程序而言，单凭UAC限制机制来实现权限许可就已经足够了。用户无法安装那些尝试访问或将内容写入受权限保护区域的软件，除非他们拥有超级管理权限。

　　不过某些软件的正常安装机制（也就是并不涉及系统敏感区域的机制）也有可能触发UAC保护。另外，某些实用工具还可能会在可执行文件中绑定运行时间库或者动态分发机制，而非利用常规的安装规程。

　　进一步来讲，以谷歌Chrome以及流行的文件共享工具Dropbox为代表的某些程序会直接被安装在用户的个人配置空间当中；UAC无法针对这类情况提供保护。最后，UAC几乎不能在安装流程结束后再对软件的执行加以控制；UAC一般只在软件执行过程中涉及权限操作时才会起效。

　　如果大家希望对所有类型的软件都拥有限制能力，或者控制系统中的软件执行流程，那么UAC并不算是理想的解决方案；我们需要通过其它途径对计算环境中的软件安装与执行进行管理。