服务账户隔离的核心是为每个服务创建专用账户并严格限定其权限范围。需按职能分配独立账户（如Linux用useradd -r创建nginx、mysql账户，Windows用NT SERVICE\虚拟账户），禁用交互登录；通过ACL/icacls精细控制文件与资源访问；在systemd或组策略中限制CPU、内存及系统调用能力；启用auditd或高级审计策略实现操作留痕，定期检查实际权限以消除冗余授权。
服务账户隔离不是“换个账号运行”就完事，而是让每个服务只拥有它真正需要的权限，且彼此之间无法越界访问。核心在于切断共享身份带来的连锁风险——一个服务被攻破，不该导致整个服务器失守。
为每个服务创建专用系统账户
避免所有服务共用 root、NETWORK SERVICE 或 IIS_IUSRS。应按服务职能分配独立账户，UID/GID 固定、禁用交互式登录：
- Linux 示例：用
useradd -r -s /sbin/nologin -d /var/lib/nginx nginx创建 Nginx 服务账户；MySQL、Redis 同理，分别使用 UID 1002、1003 - Windows 推荐使用虚拟账户（
NT SERVICE\MyServiceName），无需密码管理，由 SCM 自动维护生命周期 - UOS Server 等国产系统同样适用：系统用户（
-r）默认无家目录、无 shell、不设密码，更贴合服务场景
精细控制文件与资源访问权限
账户分离只是起点，关键还要限制该账户能碰哪些文件、注册表或网络端口：
- Linux 下用
setfacl设置 ACL：允许nginx读写/srv/web-content，同时显式拒绝mysql访问同一目录 - Windows 中通过
icacls为日志目录、配置文件夹设置 SACL：仅授予对应服务 SID 的“读取/写入”，移除 Users、Everyone 等泛化组权限 - IIS 网站必须绑定独立应用程序池，并将池标识设为专用账户（非 ApplicationPoolIdentity 默认值），再在网站匿名身份中启用“应用程序池标识”模拟
运行时环境与能力约束
即使账户和文件权限收紧，服务仍可能滥用 CPU、内存或系统调用。需在启动层强制限界：
- systemd 服务单元中配置：
User=nginx、MemoryLimit=512M、CPUQuota=50%、CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_CHOWN - Windows 服务属性中禁用“以本地系统帐户登录”，改用最小权限账户，并在组策略中启用“凭据防护”（Credential Guard）防止 LSASS 内存窃取
- 容器化部署时，用
--user指定非 root UID，配合--read-only和--cap-drop=ALL进一步收窄攻击面
监控与审计不可省略
隔离效果需可观测。没有日志记录的权限控制，等于没做：
- Linux 启用 auditd，监控关键路径如
/etc/passwd、/var/log/下的修改事件 - Windows 开启对象访问审核（gpedit.msc → 高级审计策略 → 对象访问），对服务目录添加审核规则，捕获事件 ID 4660（删除）、4670（权限变更）
- 定期用
accesschk.exe（Windows）或getfacl（Linux）检查服务账户实际持有的令牌权限，识别隐性继承或冗余授权
