应剥离SYSTEM/root等高危内置账号权限，改用最小化权限专用服务账户：Windows新建隔离用户并限制登录权限，Linux创建无登录系统用户并精确授权路径访问，配置后验证启动与日志监控。

系统内置特殊账号（如 Windows 的 SYSTEM、LocalService，Linux 的 root、daemon）默认拥有过高权限，直接用于运行服务会显著扩大攻击面。剥离其权限并改用最小化权限的专用服务账户，是安全加固的关键一步。

识别并停止使用高危内置账号

先确认当前服务是否以 SYSTEM（Windows）或 root（Linux）身份运行：

• Windows：用 services.msc 查看“登录身份”列，或执行 sc qc 服务名 查看 OBJNAME 字段；避免设为 LocalSystem，除非明确需要内核级访问。
• Linux：运行 ps -eo pid,user,args | grep 服务名，若显示 root 且非必要，应调整。
• 禁用 LocalService、NetworkService 等通用账号运行自定义服务——它们共享权限上下文，一旦被攻破，横向风险极高。

创建专用低权限服务账户

不复用普通用户账号，也不用已有系统账号，而是新建隔离账户：

• Windows：用 net user svc_app01 P@ssw0rd123 /add /passwordchg:no 创建，再通过 secpol.msc → 本地策略 → 用户权限分配 剥离其交互登录、关机等无关权利，仅保留 作为服务登录 和 在本地登录（如需调试）。
• Linux：用 useradd -r -s /usr/sbin/nologin -d /var/lib/appsvc appsvc 创建无家目录、禁止登录的系统用户；确保其主组仅为 appsvc，不加入 wheel 或 sudo 组。
• 关键原则：该账户只对服务所需路径（如 /opt/myapp、/var/log/myapp）拥有 r-x 或 rw- 权限，其余全部拒绝。

重配置服务以使用新账户

修改后务必验证服务能否正常启动和运行：

• Windows：用 sc config 服务名 obj= ".\svc_app01" password= "P@ssw0rd123" 更新；随后 sc failure 服务名 reset= 86400 actions= restart/60000/restart/60000/""/0 配置失败自动恢复，避免因权限问题导致服务静默退出。
• Linux（systemd）：编辑 /etc/systemd/system/myapp.service，添加 User=appsvc 和 Group=appsvc；若需访问网络或特定设备，用 SupplementaryGroups=netdev 精确授权，而非给 whole group access。
• 重启前检查：Windows 运行 whoami /groups /fo list 模拟该账号上下文；Linux 执行 sudo -u appsvc ls -l /var/lib/myapp 验证路径可访问性。

持续监控与权限收敛

权限设置不是一次性的，需纳入运维闭环：

• 定期审计：Windows 可导出 Get-Process -IncludeUserName | Where-Object {$_.UserName -match "SYSTEM|LocalService"}；Linux 使用 auditctl -w /etc/passwd -p wa -k usermod 跟踪账号变更。
• 日志聚焦：将服务日志中所有 Access Denied、Permission denied 事件接入 SIEM，它们往往暴露遗漏的权限缺口。
• 升级时重检：每次服务更新或 OS 补丁后，重新验证账户权限是否仍满足最小化要求——新版本可能新增文件读写或注册表访问需求。