达梦数据库作为国产数据库的领军产品，其安全机制和权限管理体系达到了B1级安全标准，采用"三权分立"或"四权分立"的安全模型，通过精细化的权限划分和严格的访问控制，将系统权限分散，避免权力过度集中，确保数据库系统的安全性和合规性。
“三权分立”安全机制
达梦数据库采用了一种重要的安全设计——“三权分立”（安全版本还有“四权分立”），将数据库管理权限划分为系统管理员、安全管理员和审计管理员三个相互独立又相互制约的角色。这种设计符合国家信息安全等级保护要求，特别适用于政府、金融等对数据安全要求严格的场景。
“四权分立“扩展
在安全版DM8中，可扩展为四权分立，新增数据库对象操作员(SYSDBO)角色，进一步分离对象管理权限 。四权分立下各角色权限变化：
SYSDBA 权限缩减：仅保留数据库创建、备份、还原等核心管理权限，去除数据操作权限。
SYSSSO 新增：负责数据库对象(表、视图等)的创建与管理，但无数据库维护权限。
SYSSSO与SYSAUDITOR ：权限范围与三权分立保持一致。
角色与权限管理体系
角色(Role)是将具有相同权限的用户组织在一起的权限集合。达梦通过角色实现权限的批量管理和分配，主要优势包括：
SYSDBA 权限聚合：将多个权限打包为一个角色。
用户分组：相同职能的用户分配相同角色。
动态生效：角色可临时启用/禁用。
这很像给用户分配不同的“职务”和“工作证”。下面这个表格汇总了核心的内置角色，可以快速了解其权限分工。
详见达梦数据库预设角色权限列表：
达梦数据库采用 权限 - 角色 - 用户 三级授权模型，权限验证流程如下：
权限检查顺序：
直接授予用户的权限
用户所属角色的权限(需角色处于启用状态)
PUBLIC角色的公共权限
权限冲突解决：
显式拒绝优先于允许
更细粒度的权限设置优先
角色与权限管理实战
了解角色后，关键在于如何将它们赋予用户。这主要通过 GRANT 和 REVOKE 语句实现。
授予角色与权限
将角色授予用户
GRANT RESOURCE TO user_developer;
如果需要该用户能将此角色转授他人，可以加上 WITH ADMIN OPTION。
GRANT RESOURCE TO user_developer WITH ADMIN OPTION;
直接授予系统权限
如果角色权限不完全匹配需求，可以直接授予精确的系统权限。
GRANT CREATE TABLE, CREATE VIEW TO user_developer;
授予对象权限
对于某个特定表（例如 dmhr.employee）的增删改查权限，需要单独授予。
GRANT SELECT, INSERT, UPDATE, DELETE ON dmhr.employee TO user_developer;
同样，可以使用 WITH GRANT OPTION 允许该用户转授此对象权限。
回收权限
当需要撤销权限时，使用 REVOKE 语句。
回收角色
REVOKE RESOURCE FROM user_developer;
回收系统权限
REVOKE CREATE VIEW FROM user_developer;
回收对象权限
回收对象权限时，如果当初授权时使用了 WITH GRANT OPTION，回收时通常需要加上 CASCADE 关键字进行级联回收。
REVOKE SELECT ON dmhr.employee FROM user_developer CASCADE;
角色管理示例
1、角色创建与授权
-- 创建语法： CREATE ROLE role_name [WITH IDENTIFIED BY password]; -- 授权示例： -- 创建角色 CREATE ROLE finance_role; -- 为角色授权 GRANT SELECT ON finance.accounts TO finance_role; GRANT INSERT, UPDATE ON finance.transactions TO finance_role; GRANT CREATE VIEW TO finance_role; -- 将角色授予用户 GRANT finance_role TO fin_user1, fin_user2;
2、角色启动与禁用
达梦支持动态启用/禁用角色，实现权限的临时调整：
-- 禁用角色(即时生效)
SP_SET_ROLE('finance_role', 0);
-- 启用角色
SP_SET_ROLE('finance_role', 1);
-- 验证角色状态
SELECT * FROM SESSION_ROLES;3、角色与权限冲突解决
当用户权限来源多样时，达梦按以下规则处理冲突：
显式拒绝优先：明确的REVOKE优先于GRANT
直接权限优先：直接授予用户的权限优先于角色权限
角色启用状态：仅启用状态的角色权限有效
冲突解决示例：
-- 场景设置 GRANT SELECT ON sales.orders TO user1; GRANT sales_role TO user1; -- 该角色有REVOKE SELECT ON sales.orders -- 权限检查结果：user1无SELECT权限(角色中的REVOKE优先)
4、查看角色和权限
-- 查看角色 -- -- 查看角色权限 SELECT * FROM DBA_SYS_PRIVS WHERE GRANTEE='RESOURCE'; -- 查看用户拥有的角色 SELECT * FROM DBA_ROLE_PRIVS WHERE GRANTEE='TEST_USER'; -- 查看权限 -- -- 查看用户拥有的系统权限 SELECT * FROM DBA_SYS_PRIVS WHERE GRANTEE = 'USER_NAME'; -- 查看用户拥有的角色 SELECT * FROM DBA_ROLE_PRIVS WHERE GRANTEE = 'USER_NAME'; -- 查看用户拥有的对象权限 SELECT * FROM DBA_TAB_PRIVS WHERE GRANTEE = 'USER_NAME'; -- 查看当前用户拥有的权限信息 SELECT * FROM SESSION_PRIVS;
权限分层模型
企业级应用建议采用三层权限模型：
基础权限层：通过预定义角色分配基本权限
业务权限层：按业务功能创建自定义角色
特殊权限层：直接为用户分配特定权限
最佳实践建议
最小权限原则：只授予用户完成其任务所必需的最小权限。
使用角色：尽量将权限打包成角色，然后赋予用户，而非直接授予用户权限。
定期审计：定期检查角色和用户的权限分配情况，及时清理不必要的权限。
流程指挥：敏感操作，关键权限需流程审批。
在实际应用中注意项：
权限规划先行：设计阶段明确权限分层模型。
持续审计监控：建立权限变更审计机制。
安全增强配置：结合国密算法等安全特性。
定期合规检查：确保符合等保要求。
参考：
