如何在 z/OS 中将 ACF2 访问规则转换为 RACF profiles？
大部分 RACF 定义可以自动生成。迁移时，需要先分析权限语义，再生成命令，并验证实际访问结果。ACF2 规则与 RACF profiles 并非一一对应：一条规则可能需要拆成多个 profiles，多个 UID 条件也可能需要转换为不同的 RACF groups。
直接替换权限名称最容易出错。ACF2 的部分权限可以独立授予，RACF 的访问级别则有层级关系。即使命令执行成功，转换后的授权范围也可能扩大。
1. 资源规则如何映射
先区分数据集访问规则和通用资源规则，它们在 RACF 中的定义方式不同。
| ACF2 对象 | RACF 对象 | 转换时要确认的内容 |
|---|---|---|
| 数据集访问规则 | DATASET 类中的 discrete 或 generic profile | 完整数据集名称、名称掩码、适用用户、访问条件 |
通用资源规则 $KEY(...) TYPE(...) | 相应资源类中的 general resource profile | 实际 SAF class、完整资源名、应用请求的访问级别 |
| 规则中的 UID 或角色条件 | profile 访问列表中的用户或组条目 | 条件实际匹配哪些账号，以及是否存在例外 |
数据集 profile 通常用 ADDSD 创建；通用资源 profile 用 RDEFINE 创建，再用 PERMIT 设置访问列表。
从实际 CLASMAP 确定资源类
ACF2 的三字符 TYPE 不能直接当作 RACF class 名称。应先查看当前系统的映射：
ACF
SHOW CLASMAP
例如，只有确认某个 TYPE 在当前系统中对应 FACILITY，才能将相关规则转换为 FACILITY profiles。还要核对自定义映射、多个 class 共用 TYPE 的情况，以及应用发出的实际 SAF 请求。Broadcom 的配置示例允许站点自行选择三字符 TYPE，因此不能仅凭名称推断资源类。参考：Broadcom 的 CLASMAP 配置示例
资源名称也需要重新计算。数据集规则可能受 $KEY、$PREFIX、NEXTKEY 等影响，通配符和规则选择顺序不能直接照搬到 RACF generic profile。转换前后应比较规则匹配的资源集合，尤其要检查更具体的 profile 是否覆盖了预期规则。
2. 访问权限如何映射
通用资源的 SERVICE 对应关系
Broadcom 给出的通用资源访问级别对应关系如下：
ACF2 SERVICE | RACF 访问级别 |
|---|---|
READ | READ |
UPDATE | UPDATE |
DELETE | CONTROL |
ADD | ALTER |
EXECUTE | EXECUTE |
这里的 ADD 和 DELETE 是通用资源的 SERVICE 名称，不能按字面理解为数据集的创建和删除权限。参考：Broadcom 的资源访问级别对照
名称对应并不意味着授权等效。ACF2 通用资源权限没有层级关系：允许 SERVICE(UPDATE)，不代表同时允许 SERVICE(READ)；RACF 的 UPDATE 则包含较低级别的访问。因此，对于只允许 UPDATE、明确禁止 READ 的源规则，直接使用 RACF ACCESS(UPDATE) 无法实现完全等效的授权。参考：Broadcom 对 READ 与 UPDATE 差异的说明
还要检查未限定 SERVICE 的 ALLOW，以及应用对访问级别的解释。对某个控制功能授予 READ，可能表示允许执行该功能，并不一定涉及读取数据。
数据集权限要单独处理
数据集规则通常按以下方向分析：
| ACF2 数据集权限 | RACF 转换方向 | 需要检查的差异 |
|---|---|---|
READ | READ | 同时核对程序库的执行权限 |
WRITE | 通常为 UPDATE；部分 VSAM 操作涉及 CONTROL | RACF 授权还会包含读取能力 |
ALLOC | 通常涉及 ALTER | ALTER 包含更广的数据集操作能力 |
EXEC | 程序库上的 EXECUTE | 数据集用途及其他已授予权限 |
判断时需要考虑一条规则中的全部权限。IBM 的迁移指南给出了上述转换方向，但它面向较早的 OS/390 环境，具体命令和限制仍需按目标 z/OS 版本核对。参考：IBM ACF2 迁移指南
RACF 数据集的 UPDATE 允许读写，EXECUTE 主要用于程序库；CONTROL 对 VSAM 与非 VSAM 数据集的意义也不同。如果源规则只允许某项操作，却禁止 RACF 同一级别包含的其他操作，就需要将其列为例外，重新设计授权。参考：IBM 数据集访问权限说明
日志要求也要迁移。ACF2 的 LOG 或数据集权限中的 L 表示允许并记录访问，不能转换为拒绝。RACF 的授权和审计设置需要分别设计。参考：Broadcom 对数据集 A、L、P 的说明
3. 用户和组结构如何映射
ACF2 Logon ID 通常对应 RACF user profile，但规则中的 UID(...) 不能直接作为 RACF user ID 使用。迁移时，应先读取站点的 UID 构成定义，再计算每个 UID 条件实际匹配的 Logon ID 集合。
建议为每个授权条件保留以下映射记录：
源规则 → 匹配的 Logon ID 集合 → 目标 RACF group → PERMIT 条目
例如，某个 UID 条件匹配所有薪资查询人员，就可以建立 PAYREAD 组，并将这些账号连接到该组。如果源系统已采用角色，则根据角色成员和实际授权设计目标组。
设计用户和组结构时，还要注意：
- 部门、岗位等字段组合形成的条件，必须保留原有的组合含义。分别创建“部门组”和“岗位组”并授权，可能把原来的交集扩大为并集。
- UID 条件转换为组成员后，需要在账号入职、调岗和离职时同步成员关系。
- ACF2 UID string 与 UNIX 数字 UID 是不同概念；USS 的 UID/GID、HOME 等属性应单独迁移。
- 管理权限、资源访问权限和 profile 所有权应分别设计，不能把 ACF2 特权字段批量替换成 RACF
SPECIAL或OPERATIONS。
4. RACF 命令示例
假设已确认以下条件：
USER001、USER002是已创建的普通 RACF 用户。SECROOT和作为数据集高层限定符的PAY已存在。- DATASET generic profile 检查及所需的增强通配符设置已启用。
PAY.DATA.**范围内没有改变示例结果的更具体 profiles。- 源规则允许查询组读取和执行；维护组允许读取、写入和执行，但不允许分配或删除。
在这些条件下，可生成以下命令：
ADDGROUP PAYREAD SUPGROUP(SECROOT) OWNER(SECROOT)
ADDGROUP PAYUPD SUPGROUP(SECROOT) OWNER(SECROOT)
CONNECT USER001 GROUP(PAYREAD) AUTHORITY(USE)
CONNECT USER002 GROUP(PAYUPD) AUTHORITY(USE)
ADDSD 'PAY.DATA.**' GENERIC OWNER(SECROOT) UACC(NONE)
PERMIT 'PAY.DATA.**' CLASS(DATASET) ID(PAYREAD) ACCESS(READ)
PERMIT 'PAY.DATA.**' CLASS(DATASET) ID(PAYUPD) ACCESS(UPDATE)
SETROPTS GENERIC(DATASET) REFRESH
示例中的名称和授权需要替换为已确认的迁移结果，ADDSD 参数也应按目标系统的命令参考核对。参考：IBM ADDSD 命令
对于通用资源，假设应用确实检查 FACILITY 类的 APP1.ACTION，请求 READ，且该类已启用并采用 RACLIST：
RDEFINE FACILITY APP1.ACTION OWNER(SECROOT) UACC(NONE)
PERMIT APP1.ACTION CLASS(FACILITY) ID(PAYREAD) ACCESS(READ)
SETROPTS RACLIST(FACILITY) REFRESH
CLASSACT、generic 检查和缓存刷新要求取决于资源类及当前配置，需要纳入迁移配置。参考：IBM FACILITY profile 配置示例
5. 推荐哪些工具或脚本
zSecure 用于分析和核查
IBM zSecure Audit for ACF2 支持分析 ACF2 配置、生成报告及处理 SMF 数据，也可以通过 CARLa 自动生成定制报告，适合用来盘点源授权、整理转换输入。具体能力需要根据已购买的组件和版本确认，其报告功能不能视为完整的 ACF2 到 RACF 自动转换器。参考：IBM zSecure Audit for ACF2 产品说明
迁移后，可以用 RACF 数据库卸载工具 IRRDBU00 导出目标定义，供脚本比较。它读取的是 RACF 数据库，不负责转换 ACF2 数据库。参考：IBM IRRDBU00 说明
专用转换工具需要适配站点
可以评估包含转换工具的迁移服务。例如，CROZ 的公开案例介绍了一种根据 ACF2 数据生成 RACF 命令，并按客户命名规则和组结构调整的工具。这并不表示有可直接下载、适用于所有环境的通用程序。采购前，应确认输入格式、例外处理、版本支持和交付范围。参考：CROZ 迁移案例
自编脚本应从已审定的映射表生成命令
REXX 或 Python 都可以生成命令，建议分阶段处理：
规则导出 → 解析与条件展开 → 权限差异审查 → 目标映射表 → RACF 命令
下面的 Python 示例只处理已审定的通用资源授权，不解析原始 ACF2 规则：
# 用户、组和目标 profiles 已预先创建。
# access 已完成权限层级和应用语义审查。
approved_grants = [
("FACILITY", "APP1.ACTION", "PAYREAD", "READ"),
]
for resource_class, profile, principal, access in approved_grants:
print(
f"PERMIT {profile} CLASS({resource_class}) "
f"ID({principal}) ACCESS({access})"
)生产脚本还需要校验名称和字段、检测重复授权，并保留每条命令对应的源规则。遇到不支持的条件时，应输出例外清单，停止该项转换，避免静默丢弃条件。
6. 如何确认转换正确
先在隔离测试环境中加载生成的定义，再比较同一用户、同一资源、同一请求级别和同一访问条件下的访问结果。
测试至少应覆盖：
- 原来允许、转换后仍应允许的访问。
- 原来拒绝、转换后仍应拒绝的访问。
- UID 条件边界、例外用户及多组成员。
- 通配符覆盖边界，以及更具体 profiles 的影响。
PROGRAM、LIB、SOURCE、时间条件、退出例程和特权账号带来的授权。
UACC(NONE) 只限定默认访问权限，仍需检查访问列表和其他授权途径。SMF 中已发生的访问可以帮助构造测试，但无法覆盖所有潜在授权。
切换前，还要处理测试期间的规则增量，准备数据库备份、应急账号和回退步骤。验收应以实际允许与拒绝的结果，以及已确认的权限差异为依据，成功创建的 profiles 数量不足以说明转换正确。
备注：内容仅供参考。