简介：面向IT安全运维、系统管理员及政企终端管理人员的Windows 10 1803安全基线检查资源，围绕微软RS4安全基线规范整理，用于解决终端系统安全配置缺失、合规性难以落地等问题。压缩包共72个文件，以xml检查规则、admx/adml组策略模板、pol策略文件及cmd部署脚本等类型为主，同时包含GPOs组策略对象目录、GP Reports报表、WMI筛选器及MSS/SecGuide/AdmPwd等策略模板，整体包体仅1.06MB，便于下载与分发使用。内容附带RS3到RS4基线差异对照表，并覆盖BitLocker、Credential Guard、Defender Antivirus、Domain Security等专项检查报告，同时提供本地环境与域环境两种安装脚本，可直接导入组策略或批量执行。多份htm报告涉及Windows 10 RS4、Internet Explorer 11等检查项，可快速查看各安全策略的配置状态，适合终端安全加固、合规审计与常态化巡检场景参照落地。已有1616人学习使用。
1. Windows 10 安全基线（1803）：一句“加固”背后要做的三件事
当你和一台装了 Windows 10 1803 的生产机器面对面时，安全基线不是一本三厘米厚的合规手册，而是一组能直接压进系统的策略集合。1803 虽然发布得早，但很多产线终端和旧业务服务器到现在还在跑。你要做的不是照着文档逐条点头，而是把账户策略、审核策略、安全选项一条条落到系统里，再验证它真的生效。
这套基线能解决弱口令、匿名访问、日志缺失等最常见的问题，也适合正在做合规整改的团队。如果你是运维或安全工程师，下面几章就是一次完整的落地路径：先拆开策略看优先级，再通过模板导入，最后排掉最容易翻车的几个坑，还会附上一个可复用的自检脚本。
2. 拆解 Windows 10 1803 安全基线：策略项、来源与优先级
2.1 基线的三类来源：官方模板、合规要求、企业自身
常见做法是先找 Windows 自带的“安全模板”。系统里其实预制了C:\Windows\Inf\defltbase.inf、defltsv.inf这类模板，它们定义了一台干净系统的默认安全级别。1803 的机器在安装后没有额外模板时，本地的安全数据库就是出厂状态。这份状态只是“默认”，不是“安全”。
第二类来源是合规要求，比如等级保护里的身份鉴别、访问控制、安全审计。等保清单不会告诉你哪个注册表键对应哪条要求，需要你自己映射。第三类是企业内部加固手册，通常由运维和安全负责人整理，包含禁用高危端口、关闭 SMBv1、开启审核策略等。
选型时我的习惯：以官方模板为底座，叠加合规要求的差异项，再删掉与业务冲突的项。理由很简单，官方模板经过兼容性测试，误杀风险最低；合规项是保命项，一条都不能少；企业内部项则是根据现网资产定制的。三者叠加起来，才是一份能在 1803 上跑得动的基线。
2.2 核心策略项：账户策略、本地策略、安全选项一张表说清
1803 的安全基线可以按“本地安全策略”的控制台拆成四个大块。下面这张表是我每次必看的项，不是全部，但覆盖了 90% 的合规检查点。
| 策略类别 | 典型策略项 | 建议值 | 作用 |
|---|---|---|---|
| 账户策略-密码策略 | 密码最短长度 | 14（至少 8） | 提高爆破成本 |
| 账户策略-密码策略 | 密码最长使用期限 | 90 天 | 控制泄漏窗口 |
| 账户策略-账户锁定策略 | 账户锁定阈值 | 5 次 | 阻止暴力破解 |
| 账户策略-账户锁定策略 | 锁定持续时间 | 15 分钟 | 延长攻击间隔 |
| 本地策略-用户权限分配 | 拒绝本地登录 | 加入 Guests 等 | 减少攻击面 |
| 本地策略-安全选项 | 网络访问:不允许匿名枚举 SAM | 已启用 | 防共享枚举 |
| 本地策略-安全选项 | 用户账户控制:以管理员批准模式运行 | 已启用 | 提权需要确认 |
| 本地策略-审核策略 | 审核登录事件 | 成功和失败 | 保留溯源证据 |
需要注意的是，1803 的“安全选项”里有很多项在 GUI 上看不到详细说明，只能靠描述猜。比如“网络访问: 不允许存储密码和凭据”会影响某些旧应用记住密码的行为，开启后大概率出现弹窗提示输入密码。这种策略在导入前要专门找出来做一次业务影响评估。
除了这些，建议顺带检查“事件日志设置”。虽然它不挂在本地安全策略里，但安全日志的最大大小默认只有 20 MB，一旦开启登录审核，几天就会写满。我在下面第 5 章会专门说这个坑。
2.3 策略之间的覆盖关系：本地策略、域 GPO 和注册表谁说了算
一台 1803 机器上可能同时存在四层策略：本地安全策略、域 GPO、通过注册表直接写入的设置、安全模板导入后的安全数据库。它们之间不是简单的叠加，而是存在覆盖优先级。
在非域机器上，本地安全策略是最终生效项；一旦加入域，来自域控制器的 GPO 会按顺序覆盖本地策略。GPO 里又分计算机配置和用户配置，同一个策略项如果有冲突，后应用的 GPO 覆盖先应用的。注册表项则要看策略是否对应着注册表键，很多安全选项本身就是写注册表，因此用命令直接改注册表也能达到同样效果。
因此排查策略是否生效时，第一件事不是改本地安全策略，而是先用gpresult /r看当前机器有没有被域 GPO 接管。如果发现基线结果被 GPO 盖掉了，要继续到组策略管理控制台里查链接顺序和筛选条件。这个动作能省掉后面大量“为什么改了没用”的疑惑。
3. 落地第一步：用 SecEdit 和 LGPO 把基线装进系统
3.1 用 SecEdit 导出当前配置：命令与两个关键参数
要改策略前，先导出快照。Windows 自带的secedit.exe比 GUI 控制台更适合脚本化。最常用的导出命令是：
secedit /export /cfg "C:\baseline\current.cfg" /areas SECURITYPOLICY /log "C:\baseline\export.log"这里/areas SECURITYPOLICY指定导出区域，只拿安全策略，不碰系统其他配置。可选的区域有SECURITYPOLICY（账户、本地策略、审核策略）、GROUP_MGMT（受限组）、USER_RIGHTS（用户权限）等。如果不写/areas则导出全部，生成的文件会大不少。命令执行后是一个 INF 格式的文本，可以直接用记事本打开检查。
参数说明：/cfg指定输出文件；/log记录操作日志，失败时必看。权限方面，必须用提升后的管理员会话运行，否则会提示访问拒绝。在域机器上，如果策略正在被 GPO 覆盖，导出得到的其实是本地策略数据库里暂存的配置，未必是最终生效值。所以在导出前先跑一次gpupdate /force，让当前策略汇聚后再导。
3.2 用 LGPO 批量导入安全模板：典型部署流程
拿到基线模板后，手工一条条点控制台太慢。常见做法是使用安全合规工具包里的 LGPO.exe，它能在命令行里把 INF 模板直接导进本地安全数据库。命令格式是：
LGPO.exe /g "C:\baseline\Windows10-1803-Baseline.inf"/g表示导入策略到本机。LGPO 会自动把模板里的账户策略、审核策略、安全选项、限制组全部合并进现有配置，而不是覆盖全部。这一点非常重要：它不会把没在模板里出现的策略项重置成默认值。如果你希望用模板完全替代当前配置，需要先执行一次“配置数据库 + 全新导入”的流程，而不是只靠 LGPO。
在域环境下，不建议逐台机器跑 LGPO，正确做法是把 INF 导入到组策略管理控制台：右键 GPO → 导入设置，选择一个从现网导出的模板。这样可以用一条 GPO 同时下发几百台机器。非域的小规模环境，用 LGPO 配合 psexec 远程执行，也能做到批量下发，但别拿去对付生产域控制器。
导入完成后记得刷新策略：
gpupdate /force如果不刷新，新的策略值可能要到下次前台登录或重启才会应用。
3.3 留好后悔药：如何快速恢复到出厂策略
改基线之前没留后路，是我见过最多人在事后拍大腿的操作。恢复的本地方案有两种：第一种是直接恢复之前导出的 current.cfg，执行：
secedit /configure /db secedit.sdb /cfg "C:\baseline\current.cfg" /areas SECURITYPOLICY这个命令把策略数据库恢复到导出时的状态，但要注意它不会回滚注册表直接修改的项。第二种是用系统默认模板 defltbase.inf，恢复系统初始安全设置：
secedit /configure /db secedit.sdb /cfg "C:\Windows\Inf\defltbase.inf" /areas SECURITYPOLICY这条命令是“后悔药”，同时也会重置一些你手动加的安全项。建议恢复后再按新基线的要求重新导出一遍，对比差异。我在每个项目上都会把导出文件连同日期存进版本控制里，防止模板被同事改得面目全非。
模板里如果包含用户权限分配条目，里面的 SID 必须和本机账户一一对应。不同 SKU 和语言包的 SID 可能存在差异，导入后要在“本地安全策略 → 用户权限分配”里抽查几项。常见翻车是导入后自定义账户丢失了“作为服务登录”权限，导致某些 Windows 服务启动失败。检查方法是启动问题服务前先用secedit /export对比前后差异。
4. 1803 专属加固点：凭据保护、Exploit Guard 与 SMBv1 禁用
4.1 打开 Credential Guard：注册表、虚拟化和硬件条件
Windows 10 1803 是 Credential Guard 相对成熟的版本，它把登录凭据隔离在独立虚拟化进程里，即使系统被提权也很难直接 dump 出 hash。开启它需要底层支持：UEFI Secure Boot、虚拟化技术（VT-x/AMD-V），以及 TPM 2.0 会更稳。没有 TPM 时强行开，某些机器会直接蓝屏。
常用开启方式是通过注册表写入虚拟化安全设置：
New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard" -Force Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard" -Name "EnableVirtualizationBasedSecurity" -Value 1 Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard" -Name "RequirePlatformSecurityFeatures" -Value 1参数说明：EnableVirtualizationBasedSecurity=1开启虚拟化安全；RequirePlatformSecurityFeatures=1表示要求平台安全功能（如 TPM）配合。如果硬件条件不足，先只把第一项设为 1，第二项设为 0，让系统判断能开多少开多少。改完重启后，用msinfo32查看“虚拟化安全状态”，确认它是“正在运行”而不是“未启用”。
我建议在 1803 上先做小规模试点，确认机器的 BIOS 设置没有关闭虚拟化。生产环境里一旦开启 Credential Guard，再想关掉必须逐台修改注册表并重启，没有集中的“一键关闭”。所以开启前把不能支持虚拟化的老设备单拉出来，单独建一条 GPO 排除。
4.2 Exploit Guard：用 PowerShell 配置三个最常用的缓解
1803 开始，系统自带的 Windows Defender Exploit Guard 取代了原先的 EMET 思路，很多缓解策略可以通过 PowerShell 直接管理。推荐先配三样：强制映像随机化、强制 ASLR、堆栈攻击缓解。命令如下：
Set-ProcessMitigation -System -Enable ForceRelocateImages, MandatoryASLR, HighEntropyASLR Set-ProcessMitigation -System -Enable DEPSet-ProcessMitigation的直接作用对象是系统所有进程，-Enable后面跟的每个参数对应一个缓解措施：ForceRelocateImages强制所有可执行映像随机加载，MandatoryASLR让不支持 ASLR 的模块也被强制随机化，HighEntropyASLR开启 64 位高熵随机，DEP是数据执行保护。
查看效果也很简单：
Get-ProcessMitigation -System它会列出当前系统级缓解状态。如果某些老程序因为兼容问题崩溃，可以把指定进程移除缓解，而不是整机关掉：
Remove-ProcessMitigation -Name "LegacyApp.exe" -Set这个灵活性非常关键，1803 的 Exploit Guard 不像以前那样全有全无。实际踩坑点在于，开启MandatoryASLR后，用了旧版 VC++ 运行时或非标准内存分配的软件可能随机崩溃，因此先跑一轮应用兼容性测试非常必要。我一般先在测试机开启，运行 3 天管理软件和打印服务，再往生产扩散。
4.3 停掉 SMBv1 与 NetBIOS：一条命令和它带来的业务影响
1803 里的 SMBv1 协议模块默认存在，只是没启用。这个协议年久失修，是蠕虫传播的主要入口。禁用命令并不复杂：
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart执行后还可顺手检查：
Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol如果在输出里看到False，说明服务端已经不再监听 SMBv1 端口。但注意，这条命令只禁用服务端协议，客户端访问旧设备时仍可能尝试 SMBv1。需要同时把客户端也禁用掉，防止本机连旧共享时回退：
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation" -Name "DependOnService" -Value @("Bowser","MRxSmb20","NSI")这个操作本质是删除 SMBv1 的依赖项，让 Workstation 服务不再加载旧协议。改完重启前，最好先确认内网没有老式 NAS、老打印机依赖 SMBv1。如果有，要么升级固件，要么把这些设备的 IP 加入一条例外规则，单独放行。最怕的就是停掉 SMBv1 之后，整个办公室的旧扫描仪都“消失”了，这种事故我在第 5 章会展开说。
5. 应用安全基线的避坑指南：5 个常见翻车现场
5.1 旧业务连不上共享：SMBv1 一刀切的后遗症
现象：应用基线后，老式 NAS、2008 年之前的打印服务器、某些产线 PLC 上位机突然无法读取共享文件，报错“服务器存储空间不足，无法处理此命令”或“找不到网络路径”。
原因：禁用了 SMBv1 协议，而老设备只支持 SMBv1，无法回退到 SMBv2/3。运维往往以为停掉 SMBv1 只是“关了个开关”，没想到内网还挂着大量古董设备。
解决：先把 SMBv1 协议重新打开，逐个排查依赖它的设备，记录设备型号和 IP 段。新版设备固件有 SMBv2 支持的，升级固件后再次禁用；没有支持的，把仅剩的那几个 IP 段单独建防火墙规则放行，不全部开放。以后做基线前，先在内网用扫描工具探测哪些设备开放了 445 端口且协商版本为 SMBv1，再做决定。
5.2 远程桌面连不上：NLA 与账户锁定策略双重限制
现象：基线导入后，运维同事用远程桌面连接业务服务器，弹窗“由于没有远程桌面授权服务器可以提供许可证”或者直接提示“用户账户已锁定”。
原因：基线里把“远程桌面安全层”设成了“SSL”，并要求启用网络级别身份验证（NLA）。如果客户端还是老版本远程桌面组件，或者管理账号没有加入“允许通过远程桌面登录”用户权限，就会连接失败。更隐蔽的是账户锁定阈值设成 5 次，运维连续输错几次后账号被锁，锁定期内谁都进不去。
解决：先通过 iLO/IPMI 或本地控制台登录，把远程桌面安全层改成“兼容”，并把运维组账号加入“允许通过远程桌面登录”策略。账户锁定阈值建议调成“10 次 / 15 分钟”，既能防爆破又不至于让运维被锁在门外。若是域环境，还要确认相关 GPO 没把本地管理员踢出远程桌面用户组。
5.3 安全日志一天几万条：审核策略过细的代价
现象：启用基线后，安全日志几百 MB 甚至几个 GB，事件查看器打开卡顿，严格模式下日志写满导致系统停止响应。
原因：基线中的“审核策略”常常把“对象访问”“详细跟踪”“系统事件”全部开启成功和失败，且没有同步调大日志大小、设置自动覆盖。1803 默认安全日志最大才 20 MB，全量审核几分钟就能写满。
解决：按资产级别分级审核。域控、核心业务库服务器开“登录事件”“账户登录事件”“对象访问”的成功和失败；普通办公终端只开“登录事件”失败和“账户登录事件”失败。在“事件日志设置”里把安全日志最大大小改成 64 MB 到 128 MB，并选择“按需要覆盖事件”。日志保留天数根据合规要求来，至少保留 180 天，最好把日志转发到集中日志平台，避免被攻击者清理。
5.4 GPO 下发不生效：安全筛选和 WMI 筛选在作怪
现象：新建的基线 GPO 链接到了 OU，但客户端gpresult /r里根本没有这条 GPO，或者显示“已筛选（WMI 筛选器未通过）”。
原因：默认 GPO 的安全筛选里只有 PowerShell 会自动放行“通过”的对象？实际常见错误是创建 GPO 后把安全筛选里的Authenticated Users删了，只加了“域管理员”，导致普通机器没有权限读取策略；另一个问题是 GPO 上挂了 WMI 筛选器，条件写的是Windows 10 1803对应的版本号，但生成 WMI 查询时版本号格式不匹配，比如把1803当成1809的版本号，筛选直接 Flase。
解决：安全筛选保留Authenticated Users，再额外加“不需要应用该策略的机器”用“拒绝应用组策略”来排除；WMI 筛选器用OperatingSystemSKU和Version精确匹配，先在一台机器上跑Get-CimInstance Win32_OperatingSystem拿到准确 BuildNumber（1803 是 17134），再写进筛选器。改完后运行gpupdate /force并查看事件日志 4002。
5.5 系统反复重启：Windows 更新策略撞上了现有更新管理
现象：应用基线后，部分 Windows 10 1803 终端频繁重启，用户在上班时间看到“Windows 需要重启”弹窗，甚至直接自动重启。
原因：基线里包含“配置自动更新”策略，如果设成“自动下载并计划安装”，会绕过企业现有的更新管理平台，自行安装补丁。很多企业更新管理平台还没给 1803 配置维护窗口，两套系统抢着装补丁，自然乱套。
解决：在基线模板里剔除“计算机配置 → 管理模板 → Windows 组件 → Windows 更新”下的所有条目，将更新统一交给企业更新平台。如果仍要保留自动更新，需要设置“不自动重启”策略，并把计划维护时间放到非工作时间。这个坑也再次提醒：安全基线不是越严越好，是要和现网运维体系合并。
6. 用 PowerShell 做一次合规自检：验证基线是否真的生效
安全基线配完之后，最怕的是一句“应该生效了吧”。我用下面的脚本做快速自检，它把关键策略状态汇总成一个表，方便截图存档：
$report = @() # 检查 UAC $uac = (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" -Name EnableLUA).EnableLUA $report += [PSCustomObject]@{ 检查项 = 'UAC 管理员审批'; 状态 = if ($uac -eq 1) { 'OK' } else { 'FAIL' } } # 检查密码策略 secedit /export /cfg "$env:TEMP\sec.cfg" /areas SECURITYPOLICY | Out-Null $sec = Get-Content "$env:TEMP\sec.cfg" $len = ($sec | Select-String 'MinimumPasswordLength').Line $report += [PSCustomObject]@{ 检查项 = '密码最短长度'; 状态 = if ($len -match '= 14$') { 'OK' } else { "FAIL: $len" } } # 检查 SMBv1 $smb1 = (Get-SmbServerConfiguration | Select-Object -ExpandProperty EnableSMB1Protocol) $report += [PSCustomObject]@{ 检查项 = 'SMBv1 协议'; 状态 = if ($smb1 -eq $false) { 'OK' } else { 'FAIL' } } # 检查防火墙 $firewall = (Get-NetFirewallProfile -Profile Domain | Select-Object -ExpandProperty Enabled) $report += [PSCustomObject]@{ 检查项 = '域防火墙'; 状态 = if ($firewall -eq $true) { 'OK' } else { 'FAIL' } } $report | Format-Table -AutoSize这段脚本的关键在于：secedit /export导出的是本地安全库存量值，不是最终生效值，所以在域环境里运行脚本前要先跑gpupdate /force和gpresult /r确认 GPO 已经应用。脚本里MinimumPasswordLength的取值格式可能是MinimumPasswordLength = 14，正则按= 14$匹配，如果你的基线里设成别的长度，记得改匹配规则。
通过gpresult /h c:\temp\report.html还能把 GPO 生效情况导出成 HTML 报告，配合脚本结果一起存档，合规审计时就无需临时翻机器。我对审计的态度从来不是“过了就完”，而是把每台机器的基线快照固定下来，下次再变更时可以做 diff。这几年最深的教训是：安全基线改完必须立刻验证，不要隔天再看。曾经有一台 1803 设备导入后的密码长度一直没变，原因是域 GPO 里还残留着旧的 8 位长度策略，本地配置被覆盖了，隔了几天才发现。从那以后我就把gpresult加到了验收流程的第一步。
如果你用的是 1803 的存量环境，希望这份拆解能帮你把基线从“文档”真正变成“配置”。每台机器跑一遍自检脚本，把输出贴到内部知识库，比口头“已加固”可靠得多。希望帮到你。
本文还有配套的精品资源，点击获取
