等保2.0要求重命名/删除默认账户、修改默认口令，禁用或加固SCOTT等OPEN状态账户，确保XS$NULL为EXPIRED & LOCKED；严格实施最小权限与角色分离，回收非授权DBA等高危权限；禁止PUBLIC对UTL系列包的EXECUTE权限；落实表级及字段级访问控制（如VPD）。
查默认账户是否被修改或禁用
等保2.0明确要求“应重命名或删除默认账户，修改默认账户的默认口令”。oracle安装后自带大量默认用户（如sys、system、scott、hr等），其中部分账户处于open状态且口令为已知弱口令（如scott/tiger）。不处理就是直接失分项。
执行以下语句快速定位风险账户：
SELECT username, account_status, created FROM dba_users
WHERE username IN ('SYS','SYSTEM','SCOTT','HR','ANONYMOUS','XS$NULL')
ORDER BY created;
- 若
account_status为OPEN，必须立即改密或锁定：ALTER USER scott ACCOUNT LOCK;或ALTER USER system IDENTIFIED BY "<strong_password>"; -
XS$NULL是Oracle 11g+内置的伪用户，不能删除，但必须确保其状态为EXPIRED & LOCKED；若为OPEN，需联系DBA评估是否被异常启用 - 注意：
PUBLIC不是用户，但它的权限会自动继承给所有用户——别在dba_users里找它，而要查：SELECT grantee, privilege FROM dba_tab_privs WHERE grantee = 'PUBLIC' AND table_name LIKE 'UTL%';
验权限分配是否满足最小权限与角色分离
等保2.0要求“授予管理用户所需的最小权限”“实现管理用户的权限分离”，核心是杜绝一人身兼DBA、AUDITOR、OPERATOR三重角色。常见错误是让运维人员直接用SYSDBA连库执行日常操作。
先确认当前有哪些高危权限被泛滥授予：
SELECT grantee, granted_role FROM dba_role_privs
WHERE granted_role IN ('DBA', 'EXP_FULL_DATABASE', 'IMP_FULL_DATABASE', 'DATAPUMP_IMP_FULL_DATABASE')
AND grantee NOT IN ('SYS', 'SYSTEM');
- 如果结果中出现业务账号（如
APP_USER）或非DBA人员账号，立刻回收：REVOKE DBA FROM app_user; - 必须创建专用角色：例如
AUDITOR_ROLE只授SELECT ANY DICTIONARY和AUDIT_ADMIN，再单独授权给审计员；禁止直接将SELECT_CATALOG_ROLE授给开发账号 - 检查是否存在
GRANT ANY PRIVILEGE或GRANT ANY ROLE这类元权限——除SYS外，其他用户不应持有
看PUBLIC权限是否过度开放
PUBLIC不是用户也不是角色，但它是所有用户的隐式成员。一旦对PUBLIC授予EXECUTE权限（尤其是UTL_TCP、UTL_HTTP、UTL_SMTP、UTL_FILE），就等于把数据库变成攻击者的跳板。等保测评工具一扫就报“高危漏洞”。
运行这条语句识别风险点：
SELECT table_name, privilege FROM dba_tab_privs WHERE grantee = 'PUBLIC' AND table_name LIKE 'UTL%' AND privilege = 'EXECUTE';
- 只要结果非空，就必须撤销：
REVOKE EXECUTE ON UTL_HTTP FROM PUBLIC;（逐个执行，不要批量REVOKE ALL） - 撤销前务必确认业务系统是否依赖这些包——有些老报表或ETL脚本会直连调用
UTL_FILE写日志，贸然回收会导致任务失败 - 更稳妥的做法是：撤销
PUBLIC权限后，为真正需要的用户/角色显式授权，例如：GRANT EXECUTE ON UTL_FILE TO etl_role;
核用户级访问控制是否落地到表粒度
等保2.0要求“访问控制粒度应达到主体为用户级、客体为数据库表级”。光靠GRANT SELECT ON hr.employees TO app_user不算完——这只是粗粒度授权。三级系统还要求对敏感字段（如身份证号、薪资）做细粒度策略（VPD）或列级掩码（Data Redaction）。
验证是否真正在用VPD：
SELECT object_owner, object_name, policy_name, function_schema, policy_function
FROM dba_policies
WHERE object_owner NOT IN ('SYS','SYSTEM');
- 若结果为空，说明没启用VPD，仅靠传统授权不满足“客体为表级”的深度要求
- 若结果有记录，检查
policy_function是否真实生效（可模拟非授权用户查询，看是否返回空集或过滤后数据） - 注意：VPD策略函数必须在安全模式下编译（
CREATE OR REPLACE FUNCTION ... AUTHID DEFINER），否则可能被绕过
权限配置最易被忽略的其实是“动态变化”——上线新模块、交接管理员、更换外包团队时，没人清理历史授权。建议把dba_role_privs和dba_sys_privs导出成快照，每月比对差异。一次疏忽，可能让一个测试账号意外拿到UNLIMITED TABLESPACE，进而写满磁盘触发服务中断。
