零信任不是简单用Windows Identity加ACL，而是每次文件访问都需动态验证身份、策略和上下文并默认拒绝；需自建SecureFileOpener封装层，在Open前执行策略评估，并抽象IFileAccessPolicy适配跨平台。
Windows Identity + ACL 不等于零信任
零信任不是给文件加个 WindowsIdentity 就完事。它要求每次访问都验证身份、检查策略、评估上下文（比如设备健康状态、网络位置），且默认拒绝。C# 原生没有“零信任文件访问”这个 API，你得自己拼装：用 WindowsIdentity 或 ClaimsPrincipal 做身份断言，用自定义策略引擎做实时决策，再通过 FileSecurity 或 AccessControlList 执行授权结果。
- ACL 是静态的、被动的——一旦设好就不管请求来源是否可信；零信任是动态的、主动的——每次
File.OpenRead()都该触发一次策略评估 - 别把
Thread.CurrentPrincipal当成策略执行点，它只负责“是谁”，不负责“能不能” - 真实场景中，策略可能依赖外部服务（如 Azure AD Conditional Access 状态），不能只查本地组成员关系
如何在 Open() 前插入策略校验
核心是拦截文件打开动作，在调用 FileStream 构造函数前完成策略判断。推荐用封装层而非重写系统 IO 类——既避免绕过安全检查，也方便注入上下文（如请求 IP、设备 ID）。
- 写一个
SecureFileOpener类，暴露OpenRead(string path, ClaimsPrincipal user, Dictionary<string object> context)</string> - 路径校验必须做规范化：
Path.GetFullPath(path)防止..\..\etc\passwd类绕过 - 策略函数返回
PolicyDecision.Deny时，直接抛SecurityException，不要静默失败——零信任要求明确拒绝信号 - 示例关键逻辑：
if (!policyEngine.Evaluate(user, path, context))<br> throw new SecurityException($"Access denied to {path} by policy");<br>return new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.None, 4096, FileOptions.None);
ACL 设置容易忽略的三个细节
即使策略放行，最终还得靠 Windows ACL 控制内核级访问。但 C# 的 File.SetAccessControl() 很容易配出“看似安全实则失效”的规则。
- 必须用
FileSystemRights.ReadData而非FileSystemRights.Read——后者不含遍历目录权限，会导致某些 .NET API（如Directory.GetFiles()）意外失败 - 继承标志要显式控制：
new InheritanceFlags(ContainerInherit | ObjectInherit)，否则子文件不会自动继承父目录策略 - 别忘了清理旧规则：
fileAcl.RemoveAccessRuleAll(rule)再AddAccessRule()，否则历史残留规则可能覆盖新策略
跨平台部署时策略执行点会漂移
.NET 6+ 支持跨平台，但 Windows ACL 在 Linux/macOS 上完全不可用。如果你的零信任逻辑硬编码了 FileSecurity，那在容器或 Linux 服务器上直接崩。
- 策略执行层必须抽象：定义
IFileAccessPolicy接口，Windows 实现用FileSecurity，Linux 实现用chmod+ 进程 UID 检查 + 自定义元数据标记 - 路径策略不能依赖驱动器盘符（
C:\），统一用 URI 形式表达资源标识，比如file://app-data/config.json - 测试时务必在目标环境跑通策略链：从身份解析 → 策略评估 → 底层访问控制，三步缺一不可
真正难的不是写几个 Allow/Deny 规则，而是让策略能感知运行时上下文，并在不同操作系统底层保持语义一致——这点常被本地开发时忽略。
