Windows系统存储管理员无法访问的机密，特定签名程序可无交互访问

你的这个SecretKeeper用户+专用服务的思路抓准了权限隔离的核心，刚好能满足“管理员无法直接访问机密、只有签名程序能无交互获取”的需求，不过每个环节还有不少细节要打磨，我帮你拆解并补充关键要点：

一、SecretKeeper用户的创建与权限锁死 #

• 创建用户时，用工具生成足够复杂的随机密码（比如PowerShell里-join ((65..90)+(97..122)+(48..57) | Get-Random -Count 32 | % {[char]$_})就能生成32位混合密码），绝对不要把密码存在任何可被管理员读取的地方（脚本、注册表、配置文件都不行），生成后直接用于服务配置，之后就彻底丢弃。
• 严格限制该用户的权限：只授予它访问机密存储目录的最小必要权限，禁止它本地/远程登录（通过本地组策略的“拒绝本地登录”权限设置），绝不加入任何管理员组，甚至可以禁用该用户的交互式登录权限。

二、Windows服务的配置与安全加固 #

• 服务要设置为以SecretKeeper账户运行，启动类型设为“自动”，配置登录身份时直接填入密码，不要勾选“允许服务与桌面交互”，减少不必要的攻击面。
• 给服务设置严格的安全描述符：用sc sdset SecretKeeperService "D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;CR;;;S-1-5-80-XXXXXXX)"（其中S-1-5-80开头的是你的签名证书对应的SID，需要提前获取），确保只有管理员能修改服务配置，只有签名程序能和服务通信。

三、签名验证的核心逻辑实现 #

• 服务必须内置代码签名验证机制，这是实现“仅签名程序可访问”的关键：
  • 当外部程序发起机密访问请求时，服务先获取请求程序的文件路径，调用Windows API WinVerifyTrust验证该程序的数字签名是否匹配你指定的代码签名证书。
  • 验证时要做全链路检查：证书是否在信任链上、是否过期、是否被吊销，避免无效或伪造的签名绕过验证。验证通过后，服务再返回解密后的机密内容，全程无需用户交互。

四、机密的存储加密 #

• 即使是SecretKeeper用户的专属目录，也别存明文机密。建议用**DPAPI（数据保护API）**以SecretKeeper用户的身份加密机密，这样只有在该用户的上下文环境下才能解密；或者用EFS加密存储机密的文件夹，同样绑定SecretKeeper用户的身份，管理员没有该用户的私钥就无法解密。

五、规避管理员的潜在攻击路径 #

• 管理员虽然不能直接读取机密，但可能通过篡改服务程序、修改服务配置来获取权限。所以要给服务程序设置强文件权限，只有SecretKeeper用户和你信任的管理员能修改，同时开启Windows Defender Application Control（WDAC），禁止未签名的程序替换或修改服务文件。
• 绝对不要在任何脚本或日志中留下SecretKeeper用户的密码痕迹，创建用户时直接用命令行一次性完成配置，避免密码泄露。

内容的提问来源于stack exchange，提问作者NineBerry