Device Guard是Windows Server 2016及更高版本中内置的一项核心安全功能，它通过代码完整性策略（Code Integrity Policy）和虚拟化安全（Virtualization-Based Security, VBS）来锁定服务器只允许运行经过信任签名的应用程序。要启用Device Guard，你需要满足几个硬性前提：64位Windows Server操作系统、支持UEFI安全启动的固件、TPM 2.0芯片，以及CPU支持虚拟化扩展（Intel VT-x或AMD-V）。如果你的硬件不达标，Device Guard根本无法激活，更谈不上后续的兼容性测试。下面我直接拆解整个流程，从硬件检查到策略部署，再到兼容性验证，一步步讲清楚。
一、Device Guard到底是什么，为什么要启用它
Device Guard本质上是微软推出的应用程序白名单机制。传统的杀毒软件是"黑名单"思路——已知病毒才拦截，未知的就放行。Device Guard反过来，它默认拒绝一切未经授权的代码执行，只有你明确信任的程序才能跑。这对服务器来说意义重大，因为服务器一旦被恶意软件入侵，后果往往比个人电脑严重得多——数据泄露、业务中断、勒索攻击都可能发生。启用Device Guard后，即使攻击者拿到了管理员权限，也无法随意运行恶意程序，因为系统会在代码加载阶段就把它拦截掉。
二、启用前的硬件兼容性检查——这一步决定成败
很多人在部署Device Guard时卡在第一步，不是软件配置问题，而是硬件根本不支持。你需要逐一确认以下四项：
第一，确认UEFI和安全启动状态。打开命令提示符，输入以下命令检查：
msinfo32
在系统信息中查看"安全启动状态"，必须显示"已启用"。如果显示"不支持"或"已禁用"，你需要进BIOS/UEFI固件设置，找到Secure Boot选项开启它。注意，部分老旧服务器的BIOS可能根本没有这个选项，这种情况下硬件就不兼容Device Guard。
第二，确认TPM 2.0是否存在且已激活。运行以下命令：
Get-Tpm
如果返回结果显示TpmPresent为True且TpmReady为True，说明TPM正常。如果TpmPresent为False，说明主板上没有TPM芯片或者没有在BIOS中启用。有些服务器需要在BIOS中手动开启TPM，路径通常是Security → TPM Device → Enable。
第三，确认CPU虚拟化支持。运行：
systeminfo | findstr /i "虚拟化"
如果显示"已启用"，说明虚拟化扩展已开启。如果没有，需要进BIOS找到Intel VT-x或AMD-V选项并启用。这一步对于Hyper-V环境尤其重要，因为Device Guard依赖VBS，而VBS又依赖CPU虚拟化。
第四，确认操作系统版本。Device Guard要求Windows Server 2016 Datacenter或Standard版、Windows Server 2019、Windows Server 2022。如果你还在用Server 2012 R2，那就不用想了，直接升级系统。
三、逐步启用Device Guard的完整操作流程
硬件确认无误后，开始软件层面的部署。整个过程分为三个阶段：启用VBS、部署代码完整性策略、验证运行状态。
阶段一：启用虚拟化安全（VBS）。这是Device Guard的底层依赖。运行以下PowerShell命令：
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Hypervisor
执行后需要重启服务器。重启后再次确认VBS状态：
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard
如果返回SecurityServicesRunning包含"Credential Guard"和"Device Guard"且值为True，说明VBS已正确运行。
阶段二：部署代码完整性策略。微软提供了一个自动化工具叫Device Guard and Credential Guard hardware readiness tool，但手动部署更可控。首先，你需要准备一个代码完整性策略XML文件。微软官方有模板，你可以在以下路径找到参考：C:\Windows\schemas\CodeIntegrity\ExamplePolicies。核心策略内容大致如下：
<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy">
<VersionEx>11.0.0.0</VersionEx>
<PolicyTypeID>{A244370E-44C9-4C06-B551-F6016E563076}</PolicyTypeID>
<PlatformID>{2E07F7E4-194C-4D20-B7C9-6F44A6C5A2BE}</PlatformID>
<Rules>
<Rule>
<Option>Enabled:UMCI</Option>
</Rule>
<Rule>
<Option>Enabled:Dynamic Code Security</Option>
</Rule>
<Rule>
<Option>Required:WHQL</Option>
</Rule>
</Rules>
<EKUs />
<FileRules />
<Signers />
<DriverSigners />
</SiPolicy>
这个策略的含义是：启用用户模式代码完整性（UMCI）、动态代码安全，并要求所有驱动程序必须有WHQL签名。你需要根据自己的实际业务需求调整FileRules和Signers部分，把你信任的应用程序签名添加进去。
部署策略命令：
ConvertFrom-CIPolicy -XmlFilePath "C:\Policy\DeviceGuardPolicy.xml" -BinaryFilePath "C:\Windows\System32\CodeIntegrity\SIPolicy.p7b"
部署完成后重启服务器。重启后Device Guard正式生效。
阶段三：验证状态。重启后运行：
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object *
重点看CodeIntegrityPolicyEnforced是否为True。如果是True，恭喜，Device Guard已经在工作了。
四、硬件兼容性测试——重点排查这些坑
启用Device Guard后，最常见的问题不是安全策略本身，而是兼容性。很多业务软件、驱动程序、管理工具会因为没有被列入白名单而被拦截。以下是我总结的高频兼容性问题和解决方案。
问题一：第三方安全软件被拦截。很多传统杀毒软件、EDR代理本身就不在微软的信任签名列表中。解决方案是在策略的FileRules中添加这些软件的签名，或者使用微软推荐的方式——将安全软件部署为内核模式驱动并确保有有效签名。
问题二：自研或小众业务程序无法运行。这是最头疼的。你需要用以下命令提取被拦截程序的签名信息：
Get-FileHash -Path "C:\Program Files\YourApp\yourapp.exe" -Algorithm SHA256
然后用签名工具查看证书详情，把签名哈希加入策略的FileRules中。如果程序没有数字签名，那就需要先给它签名，或者在策略中添加文件路径规则（但这会降低安全性，需谨慎）。
问题三：某些硬件驱动不兼容。特别是老旧的RAID卡、网卡、显卡驱动。解决方案是确保驱动有WHQL签名，如果没有，需要联系硬件厂商获取新版驱动。如果实在找不到签名驱动，可以考虑在策略中添加特定的Signer规则，但仅限已知可信的厂商。
问题四：远程管理工具失效。比如某些远程桌面增强工具、PowerShell远程模块。这些通常需要在策略中明确放行。建议在部署前先在测试环境中完整模拟所有管理操作，确认没有遗漏。
问题五：Hyper-V虚拟机内部的兼容性。如果你的服务器上跑了虚拟机，Device Guard策略默认会继承到虚拟机中。这可能导致虚拟机内的某些操作被拦截。你需要评估是否需要对虚拟机单独配置策略，或者在策略中添加虚拟机相关的例外规则。
五、测试方法论——如何系统化验证
不要直接在生产环境上部署Device Guard。正确的做法是：先搭建一个与生产环境硬件配置一致的测试服务器，完整走一遍启用流程，然后进行为期至少一周的兼容性观察。具体测试步骤如下：
第一步，基线记录。在启用前，用以下命令记录当前所有可执行文件的哈希和签名信息：
Get-ChildItem -Path "C:\Program Files" -Recurse -File | ForEach-Object { [PSCustomObject]@{ Path=$_.FullName; Hash=(Get-FileHash $_.FullName -Algorithm SHA256).Hash; Signer=(Get-AuthenticodeSignature $_.FullName).SignerCertificate.Thumbprint } } | Export-Csv "C:\Baseline\PreDG_Files.csv" -NoTypeInformation
第二步，启用Device Guard后，运行事件查看器，定位代码完整性事件。路径是：应用程序和服务日志 → Microsoft → Windows → CodeIntegrity → Operational。这里会详细记录每一个被拦截的文件和原因。
第三步，根据事件日志逐步补充白名单，直到所有业务正常运行。这个过程可能需要反复多次，耐心是关键。
第四步，压力测试。模拟高负载场景，确认Device Guard不会导致性能明显下降。正常情况下，VBS会带来约5%-10%的性能开销，但如果超过15%，需要检查是否有策略配置不当或硬件瓶颈。
六、常见误区与注意事项
误区一：认为Device Guard可以替代杀毒软件。它不是杀毒软件，它是代码执行控制机制。两者应该配合使用，Device Guard负责阻止未知代码运行，杀毒软件负责检测已知威胁。
误区二：认为启用后就万事大吉。Device Guard需要持续维护，每次系统更新、软件升级都可能引入新的签名，需要及时更新策略。建议建立定期审计机制，每月检查一次CodeIntegrity事件日志。
误区三：忽略回退方案。如果部署后出现严重兼容性问题导致业务瘫痪，你需要知道如何快速回退。回退命令如下：
Set-RuleOption -FilePath "C:\Windows\System32\CodeIntegrity\SIPolicy.p7b" -Option 3
这会将策略切换为"审核模式"而非"强制模式"，被拦截的程序会记录日志但不会被阻止，给你时间调整。如果需要完全关闭，可以用：
Set-RuleOption -FilePath "C:\Windows\System32\CodeIntegrity\SIPolicy.p7b" -Option 0
但注意，完全关闭后需要重启才能生效，且安全性会降回到传统水平。
七、总结与建议
Device Guard是Windows Server安全体系中非常硬核的一道防线，但它不是"一键开启"的功能，而是需要硬件达标、策略精细配置、兼容性充分测试的系统工程。我的建议是：先评估硬件是否支持，再在隔离环境中完整测试，最后分阶段在生产环境部署。不要跳过兼容性测试直接上线，否则你可能面临的不是安全问题，而是业务中断问题。对于中小企业，如果硬件条件不具备，可以考虑先从Windows Defender Application Control（WDAC）入手，它是Device Guard的轻量替代方案，硬件要求更低，但核心原理类似。
