前言：

不管什么业务系统，无论是通用业务软件还是行业业务软件，都会有安全模块。

业务系统的安全其实非常复杂，在开发第一件事情就是去学习 安全领域知识。

我把目光放在了全球顶级的业务系统oracle fusion cloud applications suite。

当前我基本快完成了 复刻oracle fusion cloud applications suite 安全模块的任务。

DeepSeek成本极其低廉，利用适当的软件工程知识，完全可以取得很高的投资回报。
 

详细介绍Oracle Fusion Cloud Applications Suite 安全的数据安全策略，包括使用，实施等。

在 Oracle Fusion Cloud Applications Suite 中，数据安全策略（Data Security Policies, DSP） 决定了用户在通过功能安全进入某个页面后，具体能够看到哪些数据、对哪些数据行（Rows）拥有操作特权。

如果说“功能安全”控制的是界面的按钮与菜单（What you can do），那么“数据安全”控制的就是底层的数据行边界（What you can see）。

一、 数据安全策略的核心架构与底层原理

Oracle Fusion 的数据安全采用“基于实例集”的设计理念，其底层核心逻辑可以简化为：

谁（Grantee） 被允许对 什么范围的数据（Data Instance Set） 执行 什么操作（Actions/Instance Methods）。

1. 核心三要素

• 角色（Grantee）：通常是 Job Role 或 Duty Role（如财务经理、HR 专员）。
• 数据对象（Database Object / Resource）：数据库中的物理表或逻辑视图（如发票表 AP_INVOICES_ALL，员工表 PER_ALL_PEOPLE_F）。
• 数据实例/集（Instance Set / Condition）：利用 SQL 谓词（Where 条件）限制的数据集合。例如：WHERE bu_id = 300000001234（仅限 A 业务实体）。

2. 底层核心数据表

数据安全策略的运行时拦截和配置存储在以下 FND 共通安全表中：

• FND_OBJECTS：注册受保护的数据对象（如 PER_ALL_PEOPLE_F）。
• FND_OBJECT_INSTANCE_SETS：定义动态或静态的 SQL 过滤条件（Condition）。
• FND_GRANTS：核心授权表。将角色、对象、实例集和操作（Actions）显式绑定在一起。当用户登录时，系统会自动解析该表并拼接 SQL 谓词。

二、 数据安全策略的实施与配置方法

在实施 Oracle Fusion 时，配置数据安全策略主要通过以下两种完全不同的技术路径完成，具体取决于模块架构：

方法 A：基于 HCM 安全配置文件（HCM Security Profiles）—— 最常用

在人力资本管理（HCM）模块中，Oracle 将底层的 FND_GRANTS 抽象成了对业务顾问极度友好的图形化界面：

1. 定义配置文件：进入“管理人员安全配置文件（Manage Person Security Profiles）”或“组织安全配置文件”。
2. 设定限制条件：选择控制维度（如：按部门、按职位层级、或使用 “View All People” 释放全局权限）。
3. 绑定基准角色（Generate Data Role）：进入 “Assign Security Profiles to Role” 任务，将 Job Role（如 Line Manager）与刚刚定义的 Security Profile 绑定。
4. 系统自动编译：系统在后台会自动运行 LDAP 同步进程，自动在 FND_GRANTS 中生成底层的 SQL 谓词映射。

方法 B：基于 ERP/SCM 的业务实体（Business Unit / Ledger）控制

在财务（ERP）和供应链（SCM）中，数据安全通常与组织架构（Enterprise Structure）硬绑定：

1. 数据访问集（Data Access Sets）：控制总账（GL）中用户能访问哪些账簿（Ledger）或平衡段值（Legal Entities）。
2. 通过“用户数据访问（Manage User Data Access）”任务实施：
   • 选择用户与绑定的 Job Role（如 Accounts Payable Specialist）。
   • 选择安全维度（Security Context），例如 Business Unit。
   • 选择具体的安全值（Security Value），例如 US1 Business Unit。
3. 底层效果：该用户在进入“发票查询”页面时，系统底层的 SQL 引擎会自动追加类似 AND org_id = [US1_BU_ID] 的安全过滤，从根本上隔离了其他 BU 的财务数据。

三、 高级实施：自定义数据安全策略（Custom DSP）

当预设的（Seeded）数据安全策略无法满足企业特殊的合规需求时（例如：项目经理只能看到自己名下项目的财务报销单据），安全管理员需要在安全控制台进行扩展：

实施步骤：

1. 登录安全控制台（Security Console），找到目标 Duty Role（通常建议在 Duty 级别控制数据安全，而不是直接修改 Job Role）。
2. 切换到 Data Security Policies 标签页，点击 Create Data Security Policy。
3. 选择数据库对象（Database Object）：指定要保护的表（如 PO_HEADERS_ALL）。
4. 定义条件（Condition）：
   • 可以选择预设的条件，或点击 New Condition 编写自定义 SQL 谓词。
   • 示例：&TABLE_ALIAS.created_by = :NUMBER_PRINCIPAL_ID（实现只能看自己创建的数据）。
5. 指定动作（Actions）：勾选对该数据集允许的操作（如 Read、Update）。

四、 性能与排错最佳实践（Best Practices）

由于数据安全策略是在运行时（Runtime）动态修改 SQL 语句并注入到数据库执行的，设计或实施不当会引发严重的性能灾难（Performance Bottleneck）或权限漏洞。

• 避免使用高能耗的 SQL 谓词：在自定义 Condition 时，尽量避免在 WHERE 条件中使用复杂的 EXISTS 子查询或未建立索引的字段。这会导致全表扫描，使前端页面加载出现极长的白屏（Timeout）。
• 必须运行的关键基础进程：
  在通过 HDL 导入用户、或者手工分配了 Data Access 之后，必须前往“排程进程（Scheduled Processes）”提交以下基础作业，否则新配置的数据安全策略不会在前端生效：
  1. Retrieve Latest LDAP Changes（获取最新的 LDAP 变更）
  2. Import User and Role Application Security Data（导入用户和角色应用安全数据）
• 诊断安全问题：如果某个用户反映“看不到某些数据”，实施顾问可以使用拥有运行报表权限的账号，在 BI Publisher 中直接模拟该用户的安全上下文，或者联查 FND_GRANTS 表，确认底层数据授权是否成功生成。

如果您当前正处于项目实施阶段，您可以告诉我：

• 您目前是在配置 HCM（员工/薪酬）、ERP（财务/BU） 还是 自定义模块 的数据安全？
• 您的业务部门提出了什么样的特殊数据隔离需求（例如：跨法人实体限制、或者是极其复杂的条件过滤）？

我可以为您提供具体的底层配置逻辑或对应的 HDL 批量导入模板。

如果还在实施security console,如何考虑数据安全策略的实施？即实施阶段还没有到和业务（财务，HR，UX）绑定的节点

在项目实施的纯 Security Console 配置阶段（即业务组织架构、HR 员工、财务账簿尚未在系统中完全建立的真空期），数据安全策略的实施重点应放在“顶层架构设计”、“角色模型克隆（Clone）”以及“技术特权账号生命周期管理”上。

在这个节点，你不需要关注具体的业务数据安全配置（如配置某个 BU 或某条组织链），而是要为未来的业务落地搭好“安全的容器”。以下是具体的实施考虑和落地步骤：

一、 核心策略：剥离与克隆（Clone）

Oracle 官方的最佳实践严禁直接将 Seeded（系统自带）的 Job Role 分配给最终用户。在 Security Console 阶段，你的核心任务是建立企业自己的角色标准库。

1. 识别并分离“纯技术角色”与“业务角色”

• 技术角色（现在就可以定型）：如 IT Security Manager、Application Implementation Consultant。这些角色不需要绑定未来的财务、HR 组织架构。
• 业务角色（现在只建容器）：如 Accounts Payable Manager。现在不需要配置它的业务数据安全（Data Access），但要在 Security Console 中将其克隆为自定义角色（如 XX_ACCOUNTS_PAYABLE_MANAGER_JOB）。

2. 自定义角色的克隆原则

• 只克隆 Job Role 和 Duty Role：在 Security Console 中，使用 "Copy Role" 功能。选择 "Copy top role and inherit segregate privileges"。
• 保留 Aggregate Privileges (AP)：正如我们在第一个问题中讨论的，AP 是高内聚的“原子特权”。克隆时，让你的自定义角色直接继承原生的 AP，千万不要去拆解或修改 AP 内部的数据条件。

二、 实施阶段的“技术特权”管理（无业务数据期的安全）

由于此时没有 HR 员工数据，实施人员使用的都是“实施用户（Implementation Users / 技术账号）”。这些账号不受任何业务数据策略限制，权力极大，必须在安全控制台做好控制。

1. 严格控制全局最高特权角色

在没有跟业务绑定前，实施顾问最喜欢滥用 Application Implementation Consultant (AIC) 角色。

• 风险：AIC 拥有系统全局所有模块的配置和全量数据读写权（View All）。
• 实施动作：在 Security Console 中，建立特权账号申请与审批台账。AIC 角色只能分配给各个模块的首席顾问，且必须设定失效日期（Expiration Date）。

2. 在安全控制台预设“密码与锁定策略”

在与业务绑定前，先在 Security Console 的 Administration 标签页中，把企业的安全红线（合规基线）配好：

• 密码复杂度：设置长度、特殊字符、历史密码不可重复次数。
• 防暴力破解：设置密码错误 5 次自动锁定账号 30 分钟。
• 通知模板：配置好用户被创建、密码被重置时发出的全局邮件模板（可在未对接正式邮件服务器前先完成文本设计）。

三、 为未来的“数据安全绑定”预留技术接口

虽然现在没有业务数据，但为了防止未来业务上线时权限架构崩塌，必须在 Security Console 里做好以下技术预留：

1. 梳理自定义 Duty Role 的数据安全策略 (DSP)

如果在实施早期，业务部门已经提出了超越标准系统的特殊隔离需求（例如：华东区的审计员只能审计华东区的单据，而系统标准只有按 BU 隔离），你现在就需要做：

• 在 Security Console 中找到对应的自定义 Duty Role。
• 进入 Data Security Policies，查看系统自带的 FND_OBJECTS 谓词。
• 技术预留：编写好未来需要用到的自定义 SQL 谓词（Condition）草稿，保存在实施设计文档中，等待业务表单数据灌入后进行测试。

2. 规划“岗位-角色”映射矩阵（SPR Matrix）

在安全控制台阶段，开始同步编制 Security Promotion Matrix（安全矩阵表）：

• 纵轴：未来的业务岗位（如：北京分公司财务专员）。
• 横轴：在 Security Console 中已经克隆好的自定义 Job Role（如：XX_AP_SPECIALIST_JOB）。
• 数据安全映射列（预留项）：在矩阵中留出一列叫 "Expected Data Context"。写明这个岗位未来在系统上线时，应该在外部（如“管理用户数据访问”或“HCM安全配置文件”中）被塞入什么业务值。

总结：当前节点的交付物

如果在当前的纯 Security Console 阶段收尾，你的数据安全实施交付物不应该是系统里的配置结果，而应该是以下技术资产：

1. 《企业自定义角色命名规范与清单》（全部在 Security Console 中 Clone 完毕并带 XX_ 前缀）。
2. 《全局安全控制台安全策略配置基线》（密码、锁定、LDAP 同步频率）。
3. 《特权实施账号阶段性回收计划》（AIC 等高危账号的清理时间表）。

如果您需要，我可以为您提供一份标准的《实施阶段特权账号（AIC/安全经理）安全管理与审计复核表》，帮助您在项目早期规避安全合规风险。您目前负责的是哪几个核心模块（如：只有ERP，还是包含HCM、SCM等全套）的早期安全规划？

在security console中，在定制角色的时候是不是需要定义数据安全策略？

不一定，这取决于你克隆/定制角色的类型以及你的定制目的。

在安全控制台（Security Console）定制角色时，关于是否需要定义数据安全策略（Data Security Policies, DSP），可以分为以下三种具体情况：

1. 绝大多数情况：不需要（由系统自动或后续业务节点处理）

如果你只是在做标准的作业角色（Job Role）定制，你在 Security Console 里不需要去手动创建或修改数据安全策略。

• 原因：当你在 Security Console 中使用 "Copy Role" 克隆一个 Job Role（例如从 Accounts Payable Manager 克隆为 XX_AP_MANAGER）并选择 "Copy top role" 时，新角色会自动继承原角色所包含的所有底层数据安全策略（Data Security Policies）。
• 后续如何绑定数据：这些继承下来的策略通常是“参数化”的。具体的业务数据边界（比如这个角色到底能看 A 业务实体还是 B 业务实体），不需要在 Security Console 里配置，而是等项目到了业务绑定节点后，通过 “管理用户数据访问”（Manage User Data Access） 或 “HCM安全配置文件”（HCM Security Profiles） 动态注入。

2. 只有一种情况：绝对需要（打破系统标准隔离逻辑）

只有当企业提出了非常极端的、打破 Oracle 标准产品逻辑的数据隔离需求时，你才必须在 Security Console 定制角色时定义数据安全策略。

• 举个例子：系统标准的采购员角色，默认数据安全策略是“按业务实体（Business Unit）隔离”。
• 特殊需求：业务部门要求：“采购员不仅能看到自己 BU 的数据，还必须能看到他自己创建的（Created By = 自己）跨 BU 的所有历史采购单”。
• 实施动作：此时标准的功能和数据绑定失效了。你必须在 Security Console 中找到对应的 Duty Role，进入 Data Security Policies 标签页，点击 Create Data Security Policy，手动选择底层数据库对象（如 PO_HEADERS_ALL），并手写 SQL 谓词条件（如 &TABLE_ALIAS.created_by = :NUMBER_PRINCIPAL_ID）。

3. 一种特殊角色：必须保持“干净”（技术管理类角色）

如果像你之前提到的，你正在定制的是 IT Security Manager（IT 安全经理） 或 Application Implementation Consultant（实施顾问） 这种纯技术、纯管理类的 Job Role：

• 实施原则：绝对不要去给它们定义或添加数据安全策略。
• 原因：这些角色需要的是全局的、技术性的功能操作权限（Function Privileges），它们在底层几乎没有、也不应该有任何业务数据安全策略（DSP）。给它们手动加 DSP 不仅无法限制其技术特权，反而容易导致安全控制台的 LDAP 索引同步报错。

🛠️ 实施阶段的避坑指南（Best Practice）

在当前纯 Security Console 实施阶段，如果你需要新建一个自定义角色，最稳妥的步骤是：

1. 只做复制（Copy）和继承（Inherit）：在 Security Console 里只负责克隆出 XX_ 前缀的 Job Role。
2. 检查 DSP 列表：进入新角色的配置界面，确认 Data Security Policies 标签页里有系统自动带过来的、由 ORA_ 或 FND_ 开头的标准策略行（这就代表“容器”已经准备好了）。
3. 保持原样，直接保存：不要点击 “Create Data Security Policy” 去添加自定义行，直接点击 Save and Close。把数据限权的悬念留到未来的业务配置节点。

如果你现在正在 Security Console 界面中尝试给某个特定的角色做调整，你可以告诉我：

• 这个角色的名称/代码是什么？
• 业务部门目前是否已经向你提出了某些明确的数据隔离想法（例如：某个岗位只能看特定类别的数据）？

我们可以一起评估这个需求到底属于“情况 1”（未来在业务节点配）还是“情况 2”（现在必须在 Security Console 里手写 SQL 谓词）。