Windows Server 部署到生产环境后，默认状态并不适合直接承载业务。默认防火墙规则、本地管理员账户策略、日志覆盖范围以及组件安装方式都存在大量可被利用的缺口。企业级安全防护不是安装一个杀毒软件或者开启系统更新就能完成的事，它是一套从身份、网络、主机、审计到补丁管理的组合动作。下面直接拆解每一层需要做什么、怎么做、做到什么程度才算合格。
先收紧身份与访问入口
服务器被入侵最常见的入口不是漏洞利用，而是弱口令和凭据复用。Windows Server 安装完成后第一件事应该是重命名或禁用默认 Administrator 账户。新建一个低权限管理账户用于日常登录，需要提权时通过 RunAs 或单独的管理员账户操作。所有具备管理权限的账户必须启用“账户敏感、不能委派”属性，并加入“Protected Users”安全组。这个组会强制 Kerberos 认证、禁止 NTLM 回退、限制凭据缓存，能有效阻断 Pass-the-Hash 和凭据转储攻击。
本地安全策略中，账户锁定阈值建议设置为 5 次无效登录后锁定 30 分钟，锁定计数器在 30 分钟后重置。密码策略不要再使用传统的 90 天强制过期，微软现行基线更推荐使用长密码并配合泄露密码检测。如果域环境支持，启用“禁止存储 LAN Manager 哈希”和“禁止使用可逆加密存储密码”。对于服务账户，一律使用组托管服务账户 gMSA，避免人工维护密码。
用防火墙把攻击面压到最小
Windows Defender 防火墙默认只开放了文件和打印机共享、远程桌面等少量入站规则，但这还不够。生产服务器应当启用“默认阻止入站、默认允许出站”的配置文件，并逐条添加业务所需端口。远程桌面 3389 不建议直接暴露在公网，也不建议仅修改端口号来规避扫描。正确做法是限制来源 IP 或通过堡垒机跳转。如果必须对外开放 RDP，至少启用网络级身份验证 NLA，并在防火墙规则的作用域中填写允许访问的 IP 段。
PowerShell 可以快速导出当前防火墙规则并做基线比对：
Get-NetFirewallRule -Direction Inbound -Enabled True | Select-Object DisplayName,Action,Profile | Export-Csv -Path C:\fw-baseline.csv
每次业务变更后重新导出并与上一版比对，能及时发现异常放行。对于出站流量，企业环境同样建议从“默认允许”改为“默认阻止”，只放行系统更新、DNS、NTP 和业务依赖的出站目标。这样即使服务器被植入后门，也无法轻易回连控制端。
系统组件最小化安装
服务器角色和功能装得越多，暴露面越大。部署时只安装业务必需的 IIS、文件服务或证书服务等角色，不要顺手勾选 .NET Framework 3.5、Telnet 客户端、SMB 1.0 这类遗留组件。SMB 1.0 是勒索软件横向传播的经典通道，必须在所有服务器上禁用：
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart
安装完成后用 Get-WindowsFeature 检查已安装角色，凡是显示“已安装”但业务用不到的，直接卸载。对于 IIS，禁用不用的模块和 ISAPI 扩展，关闭目录浏览，删除默认站点和示例页面。应用程序池使用独立标识运行，不要用 NetworkService 或 LocalSystem 跑 Web 应用。
补丁管理必须自动化且有验证
补丁不是“有空再打”，而是安全基线的一部分。企业环境应部署内部 WSUS 或直接使用 Windows Update for Business 策略，将服务器划分为测试组和生产组。安全更新在测试组验证 7 到 14 天后再推送到生产组。关键漏洞如远程代码执行、提权类补丁，测试周期应缩短到 72 小时以内。
仅安装补丁还不够，需要每月生成合规报告，确认所有服务器补丁安装状态。PowerShell 可以调用 Windows Update API 查询最后安装时间和待安装更新数量：
$Session = New-Object -ComObject Microsoft.Update.Session
$Searcher = $Session.CreateUpdateSearcher()
$Results = $Searcher.Search("IsInstalled=0")
$Results.Updates | Select-Object Title,MsrcSeverity,LastDeploymentChangeTime
对于无法立即打补丁的老旧系统，必须通过网络隔离、应用白名单或 IPS 规则做补偿控制，并记录风险接受审批。
日志与审计要能支撑溯源
很多企业服务器被入侵后无法溯源，根本原因是日志没开全或者只存了很短时间。Windows Server 高级审核策略中，至少启用登录事件、账户管理、策略更改、进程创建和对象访问。进程创建日志配合命令行参数记录，能还原攻击者执行过的命令。启用方法：
auditpol /set /subcategory:"Process Creation" /success:enable /failure:enable auditpol /set /subcategory:"Logon" /success:enable /failure:enable
日志存储不要只放在本机。通过 Windows 事件转发或第三方 SIEM 将日志集中收集，保留至少 180 天，关键系统保留一年以上。本地事件日志大小建议设置为 4GB 以上，覆盖策略设为“按需覆盖旧事件”。同时启用 PowerShell 脚本块日志和模块日志，这能记录混淆过的恶意脚本实际执行内容。
应用白名单与端点防护双管齐下
杀毒软件能拦截已知恶意程序，但对无文件攻击、PowerShell 内存加载和合法工具滥用几乎无效。Windows Defender Application Control 或 AppLocker 是更硬核的防线。生产服务器上应配置“默认拒绝”策略，只允许系统目录、Program Files 和业务指定路径下的可执行文件、脚本和 DLL 运行。AppLocker 规则示例：
$Rule = New-AppLockerPolicy -RuleType Exe -User Everyone -Action Allow -Path "C:\Program Files\*" Set-AppLockerPolicy -Policy $Rule -Merge
配置后先以审核模式运行两周，确认没有误拦截再切换到强制模式。端点防护方面，Windows Defender 的云保护、自动样本提交和篡改保护都要开启。定期用离线扫描模式查杀 rootkit 类威胁。
远程管理与传输加密
管理服务器不要用明文协议。Telnet、FTP、HTTP 管理后台必须关闭。远程 PowerShell 使用 WinRM over HTTPS，配置证书后通过 5986 端口通信。RDP 强制 NLA 并配置 TLS 加密。对于文件传输，用 SMB 3.x 并启用加密：
Set-SmbServerConfiguration -EncryptData $true -Force
这条命令会让所有 SMB 共享强制加密，代价是传输性能略有下降，但能防止内网嗅探。对于 IIS 站点，强制 HTTPS 并禁用 TLS 1.0 和 1.1，只保留 TLS 1.2 及以上版本。注册表配置：
New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" -Force Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" -Name Enabled -Value 0
备份与恢复是最后一道防线
安全防护做得再好，也要假设服务器可能被勒索软件加密或物理损坏。备份策略必须遵循 3-2-1 原则：至少 3 份数据、2 种不同介质、1 份异地存放。Windows Server Backup 可以做系统状态和裸机恢复备份，但企业级更推荐使用支持应用感知的备份产品，确保数据库和 AD 能一致恢复。
备份文件本身也要防篡改。使用不可变存储、离线磁带或带 MFA 的备份管理控制台，防止攻击者拿到域管权限后顺手删除备份。每月至少做一次恢复演练，验证备份真的能还原，而不是只检查备份任务是否成功。
持续检测与基线比对
安全部署不是一次性项目。服务器上线后应建立安全基线，包括账户列表、服务状态、防火墙规则、计划任务、注册表关键项和已安装补丁。每周自动采集一次当前状态并与基线比对，任何新增账户、异常服务或计划任务都触发告警。PowerShell 可以快速列出最近 7 天新增的计划任务：
Get-ScheduledTask | Where-Object {$_.Date -gt (Get-Date).AddDays(-7)} | Select-Object TaskName,TaskPath,State
配合 Sysmon 部署，可以记录进程哈希、网络连接和文件创建，进一步强化检测能力。Sysmon 配置文件应包含常见 LOLBin 路径和可疑命令行模式，日志同样接入 SIEM 做关联分析。
企业级安全防护的核心逻辑是：减少暴露面、收紧身份、强制加密、完整记录、快速恢复。每一层单独看都不复杂，难的是持续执行和自动化验证。把上述措施固化成部署清单和合规脚本，每台服务器上线前逐项检查，才能把“安全防护部署”从口号变成可落地的工程实践。
