适用于：Windows 10 神州 信政府版，Windows 10
1.概要：
AppLocker 在企业内部部署，由 IT 人员使用受信任的凭据集中管理。 这使得其策略创建和部署符合类似的策略部署过程和安全限制。
2.操作步骤/更多信息：
如何使用AppLocker创建规则：
- 按Win+R，输入“services.msc”，打开服务，双击application identity服务，点击启动。
- 按Win+R，输入“taskschd.msc”，展开计划任务-Microsoft-Windows-AppID，查看对应计划任务是否运行。（如禁用，可手动开启）
- 在开始菜单-Windows管理工具-本地安全策略中，展开应用程序控制策略-applocker，根据需要创建规则类型，选择文件类型，以“可执行规则”为例，右键选择“创建新规则”，按照向导进行操作：
点击“下一步”；
选择操作类型：允许或拒绝；选择用户权限，点击”下一步”；
选择条件类型：发布者，路径或文件哈希，点击”下一步”；
指定受规则影响的文件或文件夹，点击“下一步”；
如有需要，可根据条件添加例外，完成后点击“下一步”；
添加例外界面：
点击“创建”，完成规则创建向导；
如第一次尚未添加默认规则，系统会询问是否需要添加，点击“是”；
- 右键点击applocker，选择属性，在“可执行规则”下勾选“已配置”，并选择“强制规则”，点击“确定”；
等待3-5分钟或重启电脑，查看新规则是否生效。
AppLocker的分发方式：
AppLocker 策略通过已知进程和已知方式通过组策略在域中分发。本地策略的强制设置等同于组策略对象中的相同 AppLocker 策略 (GPO) 。 但是，由于 AppLocker 规则是累加的，因此仍将为该计算机评估不在 GPO 中的本地策略。
注意事项：
软件限制策略与Applocker的异同：
- 实现方式有所不同，AppLocker是白名单模式，SRP是黑名单模式。
- 实现目的是一样的，均可帮助锁定系统防止未经授权程序运行。但SRP只实现了第一步，存在缺陷，即难以管理，并且无法应用于特定的用户或组，所有用户都会受到SRP规则影响。APPLOCKER解决上述问题，因而取代SRP。
那么，Applocker的工作原理是怎样的呢：
AppID和SRP服务共存于同一个库（AppIdSvc.dll）中，并通过一个SvcHost进程运行。该服务请求了注册表变动通知功能，借此监视注册表键值的改动，注册表键值可由GPO或本ID安全策略MMC管理单元中的AppLocker界面写入。
在检测到变化后，AppID服务会触发一个用户模式任务（AppIDPolicyConverter.exe），该任务将读取（使用XML描述的）新规则，并将其转换为二进制格式的ACE和SDDL字符串，这样才能被用户模式和内核模式的AppID以及Applocker组件所理解。该任务会将转换后的规则存储在c:windowssystem32applocker文件夹内，其文件后缀为.applocker。该文件只能由system，administrators和local service写入，对通过身份验证的其他用户是只读的。用户模式和内核模式的AppID组件会直接从注册表读取转后的规则。
另外AppID服务还会监视本地计算机的受信任根证书存储，并会通过一个用户模式的任务（AppIdCertStoreCheck.exe）验证这些证书，验证工作每天至少进行一次，或在证书存储出现变化后也会进行验证。AppID内核模式驱动程序（%SystemRoot%System32driversAppId.sys）可以通过APPIP_POLICY_CHANGED这个DeviceIoControl请求接到AppID服务发来的有关规则出现变化的通知
其中AppID服务使用LocalService账户运行，因此可以访问系统中的受信任根证书存储区域，也可以借助它来进行证书验证。AppID服务则负责验证发行商的证书、将新证书加入缓存，以及检测AppLocker规则的更新并通知AppID驱动程序。
其中AppID驱动程序承担了Applocker的大部分功能，并依赖与AppID服务的通信（通过DeviceIoControl请求通信），因此其设备对象会受到ACL的保护，仅允许NT SERVICEAppIDSvc、LOCAL SERVICE和BUILTINAdministrators组访问。因而该驱动程序无法被恶意软件仿造。
当AppID驱动程序首先加载后，它会调用PsSetCreateProcessNotifyRoutineEx请求一个进程创建回调。当该通知例程被调用后，它会获得一个PPS_CREATE_NOTIFY_INFO结构（所创建进程的描述）。之后将已识别的AppID属性写入进程的访问令牌，接下来它会调用未文档化的SeSrpAccessCheck例程，由这个例程检查进程令牌和条件式ACE的AppLocker规则，进而确定进程是否允许运行。如果进程不允许运行，AppID驱动程序会将STATUS_ACCESS_DISABLED_BY_POLICY_OTHER写入PPS_CREATE_NOTIFY_INFO结构的Status字段，这样即可导致进程创建操作被取消，并将设置进程的最终完成状态。对于DLL，其限制方式为：映像加载器在将DLL载入进程时向AppID驱动程序发送DeviceIoControl请求。随后由AppID驱动程序针对AppLocker条件式ACE检查该DLL的标识。（对所要加载的每个DLL进行这样的检查会消耗大量时间，甚至会被最终用户察觉，因此DLL规则通常是禁用的。）
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！