Windows Server的安全配置长期依赖GPO和手动操作，这种传统方式最大的问题不是效率低，而是不可审计、不可复现。当一台服务器需要满足CIS基准或等保要求时，管理员通常要对着几百条检查项逐一手动设置，一旦出现配置漂移，排查成本极高。PowerShell Desired State Configuration（DSC）从根本上改变了这个局面，它把安全基线从“操作步骤”变成了“声明式代码”，让服务器自己校验自己是否合规，不合规就自动修复。

理解声明式配置与安全基线的结合点

DSC的核心逻辑是“你只管定义目标状态，引擎负责达成它”。这和传统脚本思维完全不同。传统做法是写一堆if-else判断当前状态再执行修改，而DSC的做法是直接声明“本地安全策略中密码长度最小值必须是14”，引擎会自行比对当前值与目标值，不一致就执行Set动作。这种模式天然适合安全基线管理，因为基线本质上就是一系列目标状态的集合。Windows Server内置了数十个DSC资源，其中与安全基线直接相关的包括SecurityPolicyResource、RegistryResource、WindowsFeatureResource、ServiceResource等，它们覆盖了账户策略、审核策略、用户权限分配、安全选项、注册表键值、角色服务和系统服务状态等核心安全层面。

环境准备与模块获取

在Windows Server 2016及以上版本中，DSC框架已内置于PowerShell，但安全策略相关的DSC资源需要额外安装模块。最常用的是SecurityPolicyDsc模块，它封装了本地安全策略的几乎所有可配置项。安装命令很简单，在提升权限的PowerShell控制台中执行Install-Module -Name SecurityPolicyDsc -Force即可。安装完成后，通过Get-DscResource -Module SecurityPolicyDsc可以列出所有可用资源，包括AccountPolicy、UserRightsAssignment、SecurityOption、AuditPolicySubcategory等。这些资源直接映射到secpol.msc中的各个节点，理解这个映射关系是编写配置脚本的前提。

编写安全基线配置脚本的核心结构

一个完整的DSC配置脚本包含Configuration关键字定义的配置块、Node关键字指定的目标节点、以及一系列资源块。下面是一个典型的安全基线配置骨架，它声明了密码策略、账户锁定策略和审核策略：

Configuration ServerSecurityBaseline {
    Import-DscResource -ModuleName SecurityPolicyDsc
    Import-DscResource -ModuleName PSDesiredStateConfiguration

    Node localhost {
        # 密码策略
        AccountPolicy PasswordPolicy {
            Name = 'PasswordPolicy'
            Enforce_password_history = 24
            Maximum_Password_Age = 60
            Minimum_Password_Age = 1
            Minimum_Password_Length = 14
            Password_must_meet_complexity_requirements = 'Enabled'
            Store_passwords_using_reversible_encryption = 'Disabled'
        }

        # 账户锁定策略
        AccountPolicy AccountLockoutPolicy {
            Name = 'AccountLockoutPolicy'
            Account_lockout_duration = 15
            Account_lockout_threshold = 5
            Reset_account_lockout_counter_after = 15
        }

        # 审核策略 - 登录事件
        AuditPolicySubcategory 'AuditLogon' {
            Name = 'Logon'
            AuditFlag = 'Success'
            Ensure = 'Present'
        }

        AuditPolicySubcategory 'AuditAccountLogon' {
            Name = 'Logoff'
            AuditFlag = 'Success'
            Ensure = 'Present'
        }
    }
}

ServerSecurityBaseline -OutputPath C:\DSC\Baseline

这个脚本定义了一个名为ServerSecurityBaseline的配置，目标节点是localhost。AccountPolicy资源用于设置密码和锁定策略，AuditPolicySubcategory资源用于启用特定子类别的审核。执行配置脚本会生成一个MOF文件，这个文件就是目标状态的序列化描述。接下来通过Start-DscConfiguration -Path C:\DSC\Baseline -Wait -Verbose -Force推送配置，DSC引擎会逐项检查并修正不符合项。

用户权限分配的关键细节

用户权限分配是安全基线中最容易出错的部分，因为权限名称在不同语言版本的操作系统上显示不同，但DSC使用的是权限的常量名称，这反而避免了本地化问题。UserRightsAssignment资源通过ConstantName属性指定权限，通过Identity属性指定被授予该权限的用户或组。以下示例展示了几个关键权限的配置：

UserRightsAssignment DenyBatchLogon {
    ConstantName = 'SeDenyBatchLogonRight'
    Identity = 'Guests'
    Ensure = 'Present'
}

UserRightsAssignment DenyRemoteInteractiveLogon {
    ConstantName = 'SeDenyRemoteInteractiveLogonRight'
    Identity = 'Guests'
    Ensure = 'Present'
}

UserRightsAssignment RestoreFiles {
    ConstantName = 'SeRestorePrivilege'
    Identity = 'BUILTIN\Administrators'
    Ensure = 'Present'
}

这里有几个容易踩的坑。第一，Identity字段必须使用SAM账户格式，域账户用DOMAIN\Username，本地账户直接用账户名，内置组用BUILTIN\GroupName。第二，UserRightsAssignment资源的行为是替换式而非追加式，也就是说如果你声明了SeRestorePrivilege只授予Administrators，那么当前拥有该权限的其他账户会被自动移除。这个特性在基线管理中非常有用，因为它确保了权限的精确控制，但如果你只想追加而不想移除现有权限，就需要额外处理。第三，某些权限如SeDenyNetworkLogonRight在配置后需要重启才能完全生效，虽然DSC会报告合规，但实际效果要到重启后才会体现。

安全选项的全面覆盖

SecurityOption资源是SecurityPolicyDsc模块中参数最多的资源，它对应本地安全策略中“安全选项”节点下的所有设置。这些设置控制着从账户行为到网络通信的方方面面。以下示例覆盖了几个高风险的配置项：

SecurityOption SecurityOptions {
    # 不显示上次登录用户名
    Interactive_logon_Do_not_display_last_user_name = 'Enabled'
    # 不缓存域凭据
    Interactive_logon_Number_of_previous_logons_to_cache = 0
    # 限制本地账户使用空白密码仅限控制台登录
    Accounts_Limit_local_account_use_of_blank_passwords_to_console_logon_only = 'Enabled'
    # 启用管理员账户批准模式
    User_Account_Control_Admin_Approval_Mode_for_the_Built-in_Administrator_account = 'Enabled'
    # 关机时清除虚拟内存页面文件
    Shutdown_Clear_virtual_memory_pagefile = 'Enabled'
    # 禁用访客账户
    Accounts_Guest_account_status = 'Disabled'
    # 启用客户端通信数字签名
    Microsoft_network_client_Digitally_sign_communications_always = 'Enabled'
    Microsoft_network_client_Digitally_sign_communications_if_server_agrees = 'Enabled'
    # 启用服务器端通信数字签名
    Microsoft_network_server_Digitally_sign_communications_always = 'Enabled'
    Microsoft_network_server_Digitally_sign_communications_if_client_agrees = 'Enabled'
}

SecurityOption资源的参数命名规则是将安全选项界面的路径用下划线连接。例如“交互式登录: 不显示最后的用户名”对应Interactive_logon_Do_not_display_last_user_name。这个命名规则在模块文档中有完整列表，但更高效的做法是使用Get-DscResource -Name SecurityOption -Syntax查看所有参数及其可接受的值。需要注意的是，某些安全选项之间存在依赖关系，比如启用客户端数字签名的同时如果服务器端未启用，可能导致某些旧版应用的通信中断，因此在应用到生产环境前必须在测试环境中验证。

注册表级别的深度加固

安全基线的很多要求超出了本地安全策略界面的覆盖范围，需要通过注册表键值来实现。RegistryResource是PSDesiredStateConfiguration模块内置的资源，可以直接声明注册表键值的目标状态。以下示例展示了禁用TLS 1.0和1.1、启用TLS 1.2的配置：

Registry DisableTLS10Server {
    Key = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server'
    ValueName = 'Enabled'
    ValueData = 0
    ValueType = 'Dword'
    Ensure = 'Present'
}

Registry DisableTLS10Client {
    Key = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client'
    ValueName = 'Enabled'
    ValueData = 0
    ValueType = 'Dword'
    Ensure = 'Present'
}

Registry EnableTLS12Server {
    Key = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server'
    ValueName = 'Enabled'
    ValueData = 1
    ValueType = 'Dword'
    Ensure = 'Present'
}

注册表资源的Ensure属性有三个值：Present表示键值必须存在且值匹配，Absent表示键值必须不存在，而如果只关心键存在但不关心具体值，可以用ValueData的忽略模式。在实际安全基线中，注册表配置往往数量庞大，建议将同类配置分组到不同的Configuration块中，或者使用配置数据文件（.psd1）来参数化键路径和值，提高可维护性。

Windows功能与服务的基线控制

减少攻击面的基本原则是卸载不必要的角色和功能、禁用不必要的服务。WindowsFeatureResource用于控制角色和功能的安装状态，ServiceResource用于控制服务的运行状态和启动类型。以下示例展示了移除不必要的SMB 1.0功能并禁用Print Spooler服务：

WindowsFeature RemoveSMB1 {
    Name = 'FS-SMB1'
    Ensure = 'Absent'
}

Service DisablePrintSpooler {
    Name = 'Spooler'
    State = 'Stopped'
    StartupType = 'Disabled'
    Ensure = 'Present'
}

Service资源的Ensure属性在这里表示服务本身必须存在（未被删除），但State和StartupType定义了它的运行状态。如果要彻底删除一个服务，需要使用其他机制，因为Service资源不支持Ensure = 'Absent'。对于WindowsFeature，Name参数的值需要与Get-WindowsFeature返回的Name属性一致，而不是DisplayName。在编写配置前，建议先在目标服务器上运行Get-WindowsFeature和Get-Service确认准确的名称。

配置漂移的持续检测与自动修复

一次性推送配置只能保证某一时刻的合规，真正的价值在于持续合规。DSC支持两种模式：Push模式和Pull模式。在Push模式下，可以通过LCM（Local Configuration Manager）设置定期自行检查。以下配置将LCM设置为每30分钟自动检查一次一致性，发现漂移就自动修复：

[DSCLocalConfigurationManager()]
Configuration LCMConfig {
    Node localhost {
        Settings {
            ConfigurationMode = 'ApplyAndAutoCorrect'
            ConfigurationModeFrequencyMins = 30
            RefreshMode = 'Push'
        }
    }
}

LCMConfig -OutputPath C:\DSC\LCM
Set-DscLocalConfigurationManager -Path C:\DSC\LCM

ConfigurationMode设置为ApplyAndAutoCorrect是关键，它告诉LCM不仅要应用配置，还要在后续每次检查时自动修正偏差。如果只需要报告偏差而不自动修复，可以设置为ApplyAndMonitor。在生产环境中，ApplyAndAutoCorrect是最常用的模式，因为它实现了真正的自愈能力。但需要注意的是，自动修复可能会覆盖管理员临时做出的手动调整，因此在变更管理流程中需要明确：所有永久性配置变更都必须通过修改DSC配置脚本并重新推送来实现，而不是直接在服务器上手动修改。

将基线配置模块化与分层管理

当安全基线变得复杂时，单个Configuration块会迅速膨胀到难以维护。DSC支持复合资源（Composite Resource），允许将一组相关配置封装成可复用的模块。例如，可以创建一个名为CisPasswordPolicy的复合资源，内部包含所有密码策略相关的AccountPolicy设置，然后在主配置中直接引用这个复合资源。更进一步，可以按照安全基线的分层结构组织配置：基础层包含所有服务器通用的安全设置，应用层包含特定角色（如Web服务器、数据库服务器）的附加设置，环境层包含生产、测试等环境特定的差异配置。这种分层方式通过配置数据文件实现，在编译MOF时根据节点角色注入不同的配置数据，避免为每种服务器类型维护一份完整脚本。

合规报告与审计证据的生成

DSC的合规状态可以通过Test-DscConfiguration命令随时查询。该命令返回True表示当前状态与配置完全一致，返回False表示存在偏差。结合Get-DscConfigurationStatus可以获取详细的配置历史记录。对于审计需求，可以将这些命令的输出定期导出为结构化数据。以下命令生成包含所有资源状态的详细报告：

$report = Get-DscConfigurationStatus -All
$report | Select-Object -ExpandProperty ResourcesInDesiredState | 
    Select-Object ResourceId, InDesiredState | 
    Export-Csv -Path C:\Reports\DSCCompliance.csv -NoTypeInformation

这个报告可以清晰地展示哪些资源处于合规状态、哪些发生了漂移。结合Windows事件日志中的DSC Operational日志（位于Applications and Services Logs\Microsoft\Windows\Desired State Configuration\Operational），可以构建完整的合规时间线。对于需要向审计人员证明配置合规性的场景，这些日志和报告比手动截图更有说服力，因为它们由系统自动生成且难以篡改。

常见问题与排查思路

DSC配置推送失败时，首先要查看Verbose输出。在执行Start-DscConfiguration时加上-Verbose参数，会显示每个资源的具体执行过程和错误信息。常见问题包括：模块未安装、资源名称拼写错误、参数值不符合资源定义的可接受范围、以及权限不足。SecurityPolicyDsc模块中的资源需要管理员权限才能执行Set操作，如果在非提升权限的会话中推送，会收到访问拒绝错误。另一个常见问题是MOF文件加密。当配置中包含密码等敏感信息时，DSC要求对MOF文件进行加密，这需要预先在目标节点上配置证书。如果不需要加密，可以在Configuration块中设置PsDscAllowPlainTextPassword = $true，但这会降低安全性，仅建议在测试环境中使用。配置漂移检测不生效的常见原因是LCM的ConfigurationModeFrequencyMins设置过长，或者LCM本身未正确配置，可以通过Get-DscLocalConfigurationManager检查当前LCM设置。

Windows Server的安全基线管理从手动操作走向声明式自动化，DSC是目前最原生的实现路径。它不需要额外的基础设施，不需要安装代理，所有组件都是Windows Server内置的。通过将安全基线转化为版本可控的代码，配置变更有了完整的审计轨迹，合规状态可以持续验证，配置漂移能够自动修复。对于正在构建安全运维体系的技术团队来说，掌握DSC声明式配置能力，是把安全基线从纸面要求落地为技术强制力的关键一步。