7.1 认证与授权

7.1 认证与授权

本节摘要：认证回答"你是谁"，授权回答"你能干什么"。Oracle 的权限体系分三层：系统权限、对象权限、角色，配最小权限原则使用。本节给出账号来源的三种方式、权限的发放纪律，并用一次全库权限梳理演示怎么把五年攒下的权限烂账理清。

一、安全的第一道门在哪

生产库的安全事故有个残酷的分布：外部黑客攻破核心库是小概率事件，"离职半年的外包账号还能连库"是大概率事件。第一道门不是防火墙，是账号的出生与死亡管理——谁创建、给什么权限、什么时候收回。把这扇门管理成册，后面两节（加密与审计）才有地基：账号都管不住的库，加密密钥的保管和审计记录的解读都无从谈起。

二、认证：账号从哪来

数据库账号有三种出生方式，安全等级与管理成本各不相同。数据库自带认证：账号口令存在库内，最简单，但口令策略要靠配置文件（Profile）强制——登录失败锁定、口令复杂度、有效期，一个 Profile 绑给业务账号就生效。操作系统认证：以 OS 用户身份免密登录本机实例（管理员常用），方便但只适合受控的管理通道。目录服务统一认证（企业目录/LDAP）：账号口令收归企业目录统一管理，离职即全局禁用——账号生命周期管理最省心，是中大型企业的正解。特权账号（SYSDBA）单独一类：远程特权登录依赖口令文件，口令文件本身要纳入保护；本机特权登录走操作系统组校验，能进 OS 管理组的人约等于能进库，两个世界的成员名单要一起管。

应用连库还有第四种形态：应用用固定账号连库，终端用户不直接见库。此时真正的访问控制发生在应用层，库只认应用——这带来一个安全隐患：任何拿到应用配置的人就是"超级用户"混进来了。代理认证（Proxy Authentication）是解药：终端用户通过应用代理身份连接，库上同时记录"应用账号加真实用户"，审计粒度从"应用"细化到"自然人"。

图 7-1：权限体系三层结构与发放纪律

三、授权：权限怎么发

权限三层结构与纪律如图，落到日常就是一张查询脚本包：

-- 梳理第一步：谁拿着最高危的权限
SELECT grantee, privilege, admin_option
  FROM dba_sys_privs
 WHERE privilege LIKE '%ANY%' OR granted_role = 'DBA'
 ORDER BY grantee;
-- 梳理第二步：直接授权旁路（绕过角色直接给人）
SELECT grantee, owner, table_name, privilege
  FROM dba_tab_privs
 WHERE grantee IN (SELECT username FROM dba_users)
   AND grantee NOT IN (SELECT role FROM dba_roles)
 ORDER BY grantee, owner;
-- 梳理第三步：休眠账号（长期未登录）
SELECT username, account_status, lock_date, created
  FROM dba_users
 WHERE account_status = 'OPEN'
   AND username NOT IN (SELECT DISTINCT username FROM dba_audit_session
                        WHERE timestamp > SYSDATE - 90);
-- 临时授权的到期自动收回：用调度作业在到期日执行回收
BEGIN
  dbms_scheduler.create_job(
    job_name => 'REVOKE_EXPIRED_GRANTS',
    job_type => 'PLSQL_BLOCK',
    job_action => 'BEGIN EXECUTE IMMEDIATE ''REVOKE app_read_role FROM tmp_contractor''; END;',
    start_date => SYSTIMESTAMP + INTERVAL '30' DAY,
    repeat_interval => NULL, auto_drop => TRUE);
END;
/
​

发放侧的正面清单同样要成文：新岗位入职发放哪个角色、敏感表（薪资、客户身份）的角色单独命名与审批、外包账号加连接来源限制（只允许从跳板机网段连入）——最后这条用触发器校验会话上下文或登录触发器实现，把"账号被盗"的爆炸半径压到网段之内。

四、案例：一次全库权限梳理

背景。 审计师第一问打回来后，团队对一套运行八年的核心库做权限梳理。库上有 412 个账号，文档记载的 60 个。

操作。 按三步脚本跑出三张清单：DBA 与 ANY 权限持有者 47 个（其中 11 个是离职人员账号）；直接授权旁路 1300 多条，大多是一次性救火时"先直接给一下"；休眠账号 89 个。随后开三场对齐会：与部门负责人逐个确认 47 个高危账号的去留；旁路授权按"业务仍需要则收编进角色、不需要则回收"分类处理；休眠账号先冻结观察 30 天再回收。

结果。 八周后：账号从 412 收敛到 173，高危权限持有者从 47 降到 6（全部是持证 DBA），旁路授权清零。审计师的答案从"不知道"变成"清单在此"。解读。 权限梳理的技术含量不高，难在组织：每个"先直接给一下"的背后都有一个当年的紧急时刻，回收它需要业务方点头。所以梳理要拿审计压力当杠杆，一次到位，并把"新授权必须走角色"写进变更流程防止回潮。变式。 若库接了统一目录认证，休眠账号与离职回收自动由目录侧完成，梳理焦点转向角色内部的权限膨胀——角色也是会发胖的，半年一审角色清单同样必要。

⚠️ 常见坑：把安全整改做成"一刀切收权"。权限收敛优先影响生产，先冻结观察再回收，并给业务方一个申诉窗口——安全团队最大的敌人不是审计师，是因误伤业务而失去的信任。

五、常见问题

问题一：应用该不该用一个"超级账号"连库？ 不该。按模块拆应用账号（订单一个、库存一个），每个账号只授予本模块的对象权限——爆炸半径从"全业务"缩到"单模块"，凭证泄漏的处置也变成换一个账号而不是全应用换锁。拆分成本很低，越晚拆越痛。

问题二：Profile 的口令策略会不会影响业务稳定性？ 配错会：有效期设置与应用的持久连接不兼容，口令到期瞬间连接池集体失败。稳妥做法是服务账号单独 Profile（长有效期加到期告警，到期前人工轮换），人的账号才用严格有效期。策略与对象分开配置，安全与稳定就能兼得。

问题三：怎么防止权限回收误伤业务？ 回收前设观察期：对疑似无用的授权，先在测试环境模拟回收、再在生产对该权限做短期审计（看真有没有人用），数据说话后再动手。回收是安全整改里最易翻车的动作，靠证据而不是靠猜。

问题四：特权账号的操作怎么约束？ 两层刹车：一是技术层，SYSDBA 登录强制审计加口令文件定期轮换；二是流程层，特权操作必须挂工单执行、双人复核高危动作。特别提醒口令文件的安全位置——它与库在不同存储上、访问权限收窄到管理员组，这个几 MB 的文件泄露，等于把整库的钥匙串送人。

本节要点回顾

• 认证三来源：库内认证配 Profile 策略、目录认证管生命周期、特权账号走口令文件加 OS 组双名单。
• 代理认证补盲区：应用固定账号的库只认应用不认人，代理认证把审计粒度细化到自然人。
• 三层权限与四纪律：按岗位建角色、DBA 严控、应用分 schema、休眠即冻结——最小权限是流程不是口号。
• 梳理三清单：高危权限、直接授权旁路、休眠账号——跑三段查询，开三场对齐会。

门管住了，但合法进门的人把数据带走呢？下一节让"带走的文件读不懂"——数据加密。