2. PI System身份与访问管理基础

在 PI System 中，权限问题的根源往往不是“某个人有没有权限”这么简单，而是“这个人是谁、以什么身份被识别、这个身份被映射成了什么、最终在哪个子系统里生效”。PI System 的身份与访问管理是一套跨组件的信任链：Windows 负责证明“你是谁”，PI Identities 负责把外部身份收拢成统一账户，PI Mapping 负责把身份翻译成 PI 内部可识别的安全主体，PI Trust 负责在特定场景下建立免密信任，而 PI AF、PI Data Archive、PI Vision 各自维护自己的身份与权限视图。理解这条链，才能解释“为什么 Windows 登录成功但 PI Vision 看不到画面”“为什么 AF 里能读但 Data Archive 拒绝写入”这类典型现象。

一、PI Identities：统一身份容器

PI Identities 是 PI System 中用于集中管理身份的安全对象，它本身不是 Windows 账户，也不是 PI Data Archive 的本地用户，而是一个“身份容器”。一个 Identity 可以包含：Windows 用户或组、PI Data Archive 本地用户、PI AF 身份、其他 Identity 的嵌套成员。它的价值在于把分散在各处的账户收拢为一个可复用的安全主体，权限只需授予 Identity，成员变化时不必逐台服务器改权限。

例如，某电厂把“运行值班员”定义为一个 Identity，成员包括域组 DOMAIN\PI_Operators 和本地账户 pi_shift_lead。之后在 PI AF 中给该 Identity 授予元素读取权限，在 PI Vision 中授予显示权限，在 PI Data Archive 中授予只读权限。人员轮换时只调整域组成员，三处权限自动跟随，这就是 Identity 的核心作用。

二、Windows 身份验证与 PI 映射

Windows 身份验证解决的是“操作系统层面你是谁”。当用户通过域登录访问 PI 客户端或 PI Vision 时，系统拿到的是 Windows 令牌，例如 DOMAIN\zhangsan。但 PI Data Archive 和 PI AF 并不直接使用 Windows SID 作为权限主体，因此需要 PI Mapping 把 Windows 身份翻译成 PI 内部身份。

PI Mapping 的典型形式是：DOMAIN\zhangsan → PI_Operators，即把 Windows 账户或组映射到某个 PI Identity。映射可以基于用户，也可以基于组，推荐基于组以减少维护量。映射生效后，用户在 PI Data Archive 中实际拥有的权限，来自其被映射到的 Identity 所获得的权限，而不是 Windows 账户本身。

三、PI Trust：特定场景下的免密信任

PI Trust 与 Mapping 不同。Mapping 解决“身份翻译”，Trust 解决“是否允许某来源免密访问”。当 PI 接口、PI 到 PI 连接、PI AF 服务或某些应用需要以服务账户方式连接 PI Data Archive 时，可以配置 Trust，使指定 IP、主机名或域账户在满足条件时无需再次输入密码即可建立连接。

Trust 的配置通常包含：信任名称、允许的来源（IP 或主机名）、允许的账户、允许的应用程序、以及是否要求加密。它是一把双刃剑：配置过宽会削弱安全性，配置过窄会导致接口断连。实践中应遵循最小化原则，只对必要主机、必要账户、必要应用开放，并定期审计 Trust 列表。

四、PI AF、PI Data Archive、PI Vision 的身份视图

三个子系统各自维护身份与权限，但依赖关系不同：

• PI Data Archive 身份：以 PI Identity、PI Mapping、PI Trust 为核心，控制点位读写、批量操作、接口连接等。它是数据层的最终守门人。
• PI AF 身份：AF 有自己的安全模型，可把 Windows 账户、PI Identity 或 AF 内建身份授予元素、属性、模板权限。AF 权限决定“能不能看到模型和属性”，但不自动等于“能不能读到 Data Archive 的原始值”。
• PI Vision 身份：PI Vision 依赖 Windows 身份验证和自身授权，决定用户能否登录、能否查看或编辑显示、能否访问特定 AF 元素。它通常通过后端服务账户访问 AF 和 Data Archive，因此前端用户权限与后端服务账户权限是两条线。

一个常见误区是：在 PI Vision 中给用户授予了显示权限，就认为用户能读到所有数据。实际上，PI Vision 后端服务账户若在 Data Archive 中没有对应点位读取权限，画面仍会显示“无数据”或报错。因此排查时必须同时检查前端用户授权和后端服务账户授权。

五、身份同步机制

身份同步不是单一动作，而是多个层面的同步：Windows 域组变更后，PI Mapping 若基于组，则成员变化自动生效；若基于用户，则需手动调整。PI Identity 的嵌套成员变更后，权限即时生效。PI AF 和 PI Vision 若引用 Windows 组或 PI Identity，也会随源变化而更新。但同步存在延迟和缓存，尤其是跨服务器、跨域或服务重启场景。

建议建立定期核对机制：每月导出 PI Identity 成员、PI Mapping 列表、PI Trust 列表、AF 安全配置和 PI Vision 授权清单，与域组实际成员比对。发现“已离职账户仍在 Identity 中”“Trust 指向已下线主机”等问题时及时清理。

六、实践中的核对清单

当出现权限异常时，可按以下顺序核对：

把这条信任链画清楚、定期核对，就能把大多数“权限看起来对、实际不生效”的问题定位到具体环节。身份与访问管理不是一次性配置，而是随人员、主机、接口变化持续维护的过程。