权限矩阵必须覆盖角色、对象、操作三维度，对象路径需带schema前缀，update/insert须字段级控制，禁用all privileges；须结合profile绑定密码策略，并通过dba_tab_privs等视图反向生成基线，自动校验更新。
权限矩阵必须覆盖角色、对象、操作三维度
只按“用户→权限”二维列表设计，上线后必然出问题。真实生产环境里，同一个角色在不同PDB可能要访问不同schema下的同名表，而同一张表对开发和运维的UPDATE权限粒度也不同。矩阵至少得有三列：角色名、对象路径（如hr.employees）、允许的操作（SELECT、UPDATE(col1,col2)）。别用Excel手工维护——一旦字段变更或新增表，没人能及时同步。
- 对象路径必须带schema前缀，否则在CDB/PDB混用时会查不到权限来源
-
UPDATE和INSERT要拆到字段级，比如财务角色只能UPDATE(salary,bonus)，不能给整表 - 禁止出现“ALL PRIVILEGES”这种模糊项，审计时无法追溯具体能力边界
用DBA_TAB_PRIVS和DBA_ROLE_PRIVS反向生成基线
别从零画矩阵。先连上PDB，用已有用户跑一遍权限快照，再人工校准。很多团队卡在第一步：忘了切容器。在CDB$ROOT下查DBA_TAB_PRIVS看到的是全局视图，但实际生效的是当前PDB里的对象权限。
- 切到目标PDB：
ALTER SESSION SET CONTAINER = PROD_PDB; - 查角色所拥有的对象权限：
SELECT grantee, owner, table_name, privilege FROM DBA_TAB_PRIVS WHERE grantee IN (SELECT granted_role FROM DBA_ROLE_PRIVS WHERE grantee = 'APP_DEVELOPER'); - 把结果导出为CSV，用Python脚本按
grantee+owner+table_name去重合并，就是初始矩阵草稿
避免WITH ADMIN OPTION扩散失控
开发组长被授予CREATE TABLE带WITH ADMIN OPTION，他就能让组员自己建表——但这等于绕过DBA审批流程。矩阵里凡是标了“可传递”的权限，必须单独加一列“授权链深度”，且深度>1的行要高亮标记并每月复核。
-
WITH ADMIN OPTION只允许出现在DBA角色对二级管理员的授权中，普通角色禁用 - 查扩散链：
SELECT grantee, granted_role, admin_option FROM DBA_ROLE_PRIVS WHERE admin_option = 'YES'; - 发现
admin_option = 'YES'且不是DBA角色的记录，立刻REVOKE并走变更流程补授权
矩阵必须绑定Profile和密码策略
权限只是半截安全。一个能连库的账号如果密码永不过期、无锁定机制，矩阵再细也没用。Oracle的PROFILE不是可选项，是矩阵的强制配套字段。
- 每个角色对应一个Profile，比如
FINANCE_ANALYST_PROFILE必须设PASSWORD_LIFE_TIME = 90、FAILED_LOGIN_ATTEMPTS = 3 - 创建用户时强制指定：
CREATE USER fin_user IDENTIFIED BY xxx PROFILE FINANCE_ANALYST_PROFILE; - 矩阵表格里加一列“关联Profile”，空值视为未通过安全评审
真正难的不是列清楚权限，而是让矩阵活起来——每次新建用户、迁移PDB、上线新模块，都得触发矩阵校验脚本自动比对差异。手动作废的矩阵，三个月后就只剩参考价值。
