必须先审计服务实际权限再最小化配置：检查登录身份、进程特权、文件注册表访问行为；禁用交互式登录；精确授予SeServiceLogonRight；NTFS权限按目录收敛；彻底移出高风险组；按服务类型匹配权限模型；建立启动验证、事件日志监控与SACL审计闭环。
windows服务运行权限必须严格控制，不能靠“大概够用”来配置。核心思路是：先审计它实际用了哪些权限，再只保留必需项，其余全部剥离。
服务账户权限现状审计
不查清楚当前权限，就无法做最小化。重点看三类内容：
- 服务登录身份：在“服务”管理控制台（services.msc）中打开每个关键服务属性，确认“登录身份”是LocalService、NetworkService，还是自定义账户；
- 进程特权列表：以该服务账户身份运行whoami /priv，检查是否持有SeDebugPrivilege、SeTakeOwnershipPrivilege等高危特权；
- 文件与注册表访问行为：用Process Monitor（Sysinternals工具）过滤目标服务PID，观察其真实读写路径——比如某日志服务只访问C:\App\Logs，却拥有整个C:\盘的读取权，就是典型越权。
最小权限配置的刚性操作项
不是“尽量少给”，而是按基线逐项落实：
- 禁用交互式登录：在lusrmgr.msc中编辑服务账户属性，取消勾选“允许用户通过远程桌面服务登录”和“用户下次登录时须更改密码”，并勾选“密码永不过期”（需配套人工复核机制）；
- 精确授予SeServiceLogonRight：用secpol.msc或PowerShell命令Set-UserRightsAssignment -Account "svc_web" -Policy "Log on as a service"，仅此一项，不加其他；
- NTFS权限按目录收敛：用icacls设置继承阻断+显式授权，例如icacls "C:\MyApp\Data" /inheritance:d /grant:r "svc_web:(OI)(CI)(RX)"，确保无多余写入或执行权限；
- 从高风险组彻底移出：确认该账户不在Administrators、Remote Desktop Users、Power Users等组内，可用net user svc_web /domain（域环境）或net localgroup（本地）验证。
服务类型匹配权限模型
不同服务对系统资源的依赖差异大，不能统一降权：
- IIS应用池：使用ApplicationPoolIdentity内置账户最安全；若需自定义，只赋予站点物理路径的(OI)(CI)RX和日志目录的W权限；
- 数据库服务（如SQL Server）：账户需SeLockMemoryPrivilege（锁定内存）和数据目录Modify权限，但严禁FullControl或系统盘写入；
- 审计/监控类服务（如ADAudit Plus）：必须加入Event Log Readers组，并单独授予管理审核和安全日志用户权限，不可用管理员身份运行。
持续验证与异常捕获
配置完不是终点，要建立可验证闭环：
- 每次变更后，用sc qc [服务名]确认登录账户已生效；
- 启动服务，观察事件查看器→Windows日志→系统中是否有7041（服务登录失败）或7031（意外终止）事件；
- 定期导出4688（新进程创建）日志，筛选服务账户启动的进程，比对其令牌权限是否始终符合基线；
- 对关键服务启用SACL审计，例如用icacls "C:\App" /setintegritylevel "M"并配置对象访问审核策略，捕获越权尝试。
