oracle角色创建不支持密码参数，所谓“带密码角色”实为通过identified by创建密码验证角色，需用set role显式激活，且密码区分大小写、受密码策略约束。
创建角色本身不支持密码参数
Oracle 的 CREATE ROLE 语句不接受密码参数，所谓“带密码保护的角色”是常见误解。角色本质是一组权限的容器，它没有认证能力，也不能独立登录——因此不存在“用密码启用角色”这种原生机制。
真正能实现“密码控制访问”的，是通过以下两种组合方式间接达成：
- 使用
IDENTIFIED BY创建 **密码验证角色（password-authenticated role）**，该角色需显式用SET ROLE role_name IDENTIFIED BY password激活 - 配合配置文件（
PROFILE）限制角色所授用户的密码策略，增强整体安全性
用 IDENTIFIED BY 创建可密码激活的角色
这是最接近“带密码保护”的标准做法。角色被创建时绑定密码，用户必须知道该密码才能在会话中启用它。
执行示例（需 DBA 权限）：
CREATE ROLE hr_analyst IDENTIFIED BY "Secur3$2026"; GRANT SELECT ON hr.employees TO hr_analyst; GRANT SELECT ON hr.departments TO hr_analyst;
授予角色给普通用户后，用户登录后默认不会激活该角色：
GRANT hr_analyst TO alice;
用户需主动执行：
SET ROLE hr_analyst IDENTIFIED BY "Secur3$2026";
否则即使已授角色，SELECT 查询也会报 ORA-00942: table or view does not exist（因权限未生效）。
注意点：
- 密码区分大小写（Oracle 11g+ 默认启用），且不能是纯数字或简单字串（受
VERIFY_FUNCTION约束） - 角色密码修改只能用
ALTER ROLE role_name IDENTIFIED BY new_password，不能用ALTER USER - 若角色已用
IDENTIFIED EXTERNALLY或IDENTIFIED GLOBALLY创建，则不能再加密码
为什么不能直接用 CONNECT / RESOURCE 替代？
预定义角色如 CONNECT、RESOURCE 均为 **no-authentication roles**（无认证角色），一旦授予即自动激活，无法做细粒度访问控制。
比如你把 RESOURCE 授给开发测试账号，他就立刻能建表、建过程——哪怕你只希望他在特定时段、用特定凭证才能执行 DDL。这时必须自建密码角色，并配合应用层逻辑（如调用前校验口令）或数据库触发器做二次控制。
典型误操作：
GRANT RESOURCE TO app_user; -- ❌ 自动获得 CREATE TABLE 权限，无法按需开关
正确替代思路：
- 新建
app_ddl_role IDENTIFIED BY "AppDdl@2026" - 仅在审批流程通过后，由运维脚本动态执行
SET ROLE app_ddl_role IDENTIFIED BY ... - 会话结束后角色自动失效，下次需重输密码
容易忽略的权限与审计风险
密码角色看似安全，但有三个隐蔽风险点：
- 角色密码明文出现在应用日志或 SQL 跟踪中（如开启
SQL_TRACE），建议禁用含敏感操作的会话级跟踪 - 用户可用
SELECT * FROM SESSION_ROLES查看当前已激活角色，但无法反推密码；不过若角色权限过大（如含EXECUTE ANY PROCEDURE），仍可能被滥用 - DBA 可随时用
ALTER ROLE ... NOT IDENTIFIED移除密码，使角色退化为自动激活角色——这意味着权限回收必须同步更新角色定义，不能只靠 revoke
生产环境建议搭配 AUDIT ROLE 和 UNIFIED AUDIT POLICY 记录所有 SET ROLE 操作，尤其关注非工作时间或非常规 IP 的激活行为。
