2. AVEVA用户与角色管理基础
在AVEVA平台中，权限控制并不是“给某个人开一个账号”这么简单，而是围绕用户账户、角色、用户组三层对象建立的一套可复用、可审计的授权体系。理解这三者的分工，是后续做权限设计、最小权限收敛和操作审计的前提。本节围绕账户类型、角色定义、用户组结构、账户生命周期以及配置入口展开，并给出可直接参照的配置示例。
一、三层对象的分工
AVEVA平台（以System Platform、AVEVA Application Server、AVEVA Historian、AVEVA Operations Management Interface等组件的通用安全模型为例）的授权逻辑可以概括为：账户是“谁”，角色是“能做什么”，用户组是“把谁和什么权限批量绑定”。
- 用户账户（User Account）：标识一个可登录的主体，携带用户名、密码策略、所属组、启用状态等属性。账户本身不直接决定权限，权限来自其被授予的角色。
- 角色（Role）：一组权限的集合，例如“只读监视”“操作员”“工程师”“管理员”。角色是权限的最小复用单元，应尽量按职责划分，而不是按人划分。
- 用户组（User Group）：账户的集合，通常与Windows域组或平台本地组对应，用于批量授予角色。组是权限继承和批量管理的载体。
三者的关系是：账户加入组，组被授予角色，角色携带权限。这样当人员岗位变动时，只需调整其所属组，而不必逐个修改权限项。
二、用户账户类型
AVEVA平台中常见的账户类型有三类，配置入口和用途不同：
- 本地账户：在平台或节点本地创建，例如在System Platform的
Galaxy中通过IDE → Galaxy → Security → Users创建。适合独立部署、无域环境或少量固定账号。 - 域账户（Windows/AD）：由Active Directory统一管理，平台通过域组映射获得身份。适合企业级部署，便于集中停用和密码策略统一。
- 服务账户：供平台组件之间通信使用，例如Historian采集、Application Server与Galaxy通信。服务账户通常不用于人工登录，应设置强密码、禁止交互式登录，并单独归入服务组。
选择原则：人员账户优先用域账户，减少本地账号数量；服务账户必须独立命名并单独授权，避免与人员账户混用。
三、角色定义与权限粒度
角色定义的核心是“按职责划分、按最小权限授予”。一个可落地的角色划分示例如下：
| 角色 | 典型权限 | 适用对象 |
|---|---|---|
| Viewer | 查看画面、趋势、报表，只读 | 值班监视、参观人员 |
| Operator | Viewer权限 + 写值、报警确认、切换画面 | 现场操作员 |
| Engineer | Operator权限 + 修改画面、脚本、部署应用 | 自控工程师 |
| Admin | 全部权限，含用户与角色管理、审计日志 | 系统管理员 |
注意：不要为每个人单独建角色。角色数量应远少于账户数量。若出现“张三专用角色”，说明授权模型已经失控，应回到组和角色的复用设计。
四、用户组结构与继承
用户组通常与域组一一对应，命名建议采用GRP_<系统>_<职责>格式，例如GRP_PlantA_Operators。组可以嵌套：GRP_PlantA_Operators加入GRP_AllOperators，后者被授予Operator角色，从而实现跨装置的统一授权。
继承关系要遵循“权限只增不减、显式拒绝优先”的一般原则：子组继承父组角色；若某账户需要额外权限，应通过新增组实现，而不是直接改角色。这样审计时只需看组归属，就能还原权限来源。
五、账户生命周期管理
账户生命周期应覆盖五个状态：申请创建、启用、锁定/停用、注销、归档。关键控制点如下：
- 创建：由申请人提交岗位和所需角色，管理员按组分配，禁止直接授予Admin。
- 启用：首次登录强制改密；服务账户设置“密码永不过期”需有审批记录。
- 停用：人员离岗或转岗时，先移出业务组，再禁用账户，保留账户对象以便审计追溯。
- 注销：确认无任何服务依赖后删除或彻底禁用，并回收其角色绑定。
- 归档：保留账户创建、授权、变更、停用时间线，供审计查询。
六、配置入口与示例
以System Platform为例，主要配置入口包括：
- Galaxy用户与组：IDE → Galaxy → Security → Users / Groups，用于本地账户和组管理。
- 角色与权限：Security → Roles，定义角色及其对对象、画面、脚本的访问级别。
- 域映射：Security → Windows Groups，将AD组映射到平台组。
- 审计：Security → Audit Trail，查看登录、授权变更记录。
下面给出一个可参照的组与角色绑定示例（示例参数，非实测结果）：
组名 授予角色 说明
GRP_PlantA_Viewers Viewer 只读监视
GRP_PlantA_Operators Operator 写值、报警确认
GRP_PlantA_Engineers Engineer 画面与脚本修改
GRP_Platform_Admins Admin 平台管理，限2人
GRP_Service_Historian ServiceOnly 仅采集通信，禁止登录
配置完成后，用测试账户分别登录验证：Viewer账户应无法写值，Operator账户应能确认报警但不能部署，Engineer账户应能修改画面。若测试结果与预期不符，优先检查账户是否被加入了多个组、是否存在显式拒绝项，以及角色是否被直接授予了账户。
掌握账户、角色、组三者的分工和生命周期控制点后，后续的权限设计、最小权限收敛和操作审计才有稳定的对象基础。配置入口和命名规范应在项目初期就统一约定，避免后期返工。