引言

迁移过程中大家把百分之九十的精力都放在了SQL语法兼容、性能调优上，百分之十的精力分给了数据迁移，很少有人重视用户和角色权限的规划。结果上个月碰到一个老客户，上线三个月被等保2.0测评直接打了不合格——开发、测试、运维共用一个sysdba高权限账号，弱密码用了半年没改，核心表谁都能删，整改改了半个月，耽误了原定的上线时间，损失不小。

说白了，用户和角色管理是数据库安全的第一道门，也是最后一道门。很多刚转KES的朋友，习惯了Oracle那套玩法，对着KES的权限体系摸不着头脑，也不知道KES本身做了哪些安全增强适配合规要求，今天这篇我把这么多项目里踩坑踩出来的经验、实操步骤、生产级配置模板全放出来，从概念创建到删除账号的正确姿势全覆盖，看完直接就能拿去生产用。

---

一、为什么KES的用户角色管理值得单独拿出来说？

做信创这两年，我最深的感受就是：现在对数据安全的要求真的不一样了。《数据安全法》《网络安全法》加上等保2.0的要求，对数据库权限管控的要求比之前严格太多，核心系统要求必须做到三权分立、最小权限、一人一号、审计可追溯，原来Oracle那套一个DBA管所有的玩法，放到现在很多都不合规。

KES作为当前国内市场占有率最高的国产关系型数据库，内核做了大量安全增强，支持等保要求的权限管控能力，但很多人不知道这些特性怎么用，甚至很多人安装的时候都没开三权分立，最后过测评的时候才回来整改，瞎折腾。

KES在权限体系上做了很多适配国内用户习惯的改进，比如兼容Oracle的权限模型，原生支持三权分立，密码复杂度、细粒度权限控制这些都是原生自带的，这些都是针对企业级安全做的优化，搞清楚这些，用KES做核心系统才安全。

---

二、核心概念梳理：先搞懂几个容易混的概念

很多新手刚用KES，上来就敲create user，结果踩一堆坑，本质上是概念没搞懂。我先把核心概念理清楚，和Oracle做个对比，大家一眼就能看懂：

概念	Oracle 11g/19c	KingbaseES V8/V9
登录身份	User同时具备登录权限和对象所有者身份	User默认带登录权限，Role默认不带，可互相转换
权限继承	支持用户分配多个角色，继承权限	完全支持权限继承，支持默认角色绑定
内置权限分离	无原生三权分立，需要手动配置	原生支持sys（系统管理员）、sao（安全管理员）、sso（审计管理员）三权分立，开箱即用符合等保要求
密码复杂度	原生支持	原生支持插件，默认开启符合合规要求的密码规则
细粒度权限	支持VPD行级权限	原生支持行级、列级权限控制

这里要重点强调三个KES特有的核心概念，很多人在这里踩坑：

1. 三权分立：KES默认安装的时候会问你要不要开启三权分立，生产环境一定要开！开启之后三个管理员权限互相制约：sys管数据库对象和存储，sao管用户角色权限，sso管审计，sys不能创建用户，sao不能改存储，sso不能改权限，从架构上避免了一个人权限过大违规操作，过等保必须要这个，我见过太多图省事安装的时候关了，最后整改哭都来不及。
2. 角色和用户的区别：最佳实践是角色管权限，用户管登录，创建一个角色对应一个岗位的权限，然后给每个员工创建一个用户，绑定这个角色，用户继承角色的所有权限。以后改权限只要改角色，所有用户自动生效，比一个个给用户改权限方便一万倍，也不容易乱。
3. 权限依赖：KES删除用户/角色之前必须先处理依赖，不然删不掉，这个后面实操我会讲正确步骤，很多人卡在这里半天。

---

三、全流程实操：从创建到删除，一步一步对着做

接下来就是核心的实操部分，所有SQL都是我在生产环境用过的，直接复制就能用，我把踩过的坑都标出来，大家别再踩。

3.1 初始化：安装完第一步要做的权限配置

安装完KES，如果你选了开启三权分立，默认会生成三个内置管理员账号，第一件事就是改默认密码，很多人安装完忘了改，这是极大的安全隐患：

-- 用sys账号登录初始化，修改三个内置管理员的默认密码
-- 注意：密码必须符合复杂度要求：至少8位，包含大小写、数字、特殊字符，不然会报错
ALTER ROLE sao WITH PASSWORD 'YourSaoStrongPass@2024';
ALTER ROLE sso WITH PASSWORD 'YourSsoStrongPass@2024';
ALTER ROLE system WITH PASSWORD 'YourSystemStrongPass@2024';

💣 踩坑提示：如果这里你改密码报错password fails to meet the requirements，百分之九十是密码太简单，KES默认开启了密码复杂度检查，不要关，符合合规要求，换个复杂密码就行。

记住：以后所有创建用户、角色、授权的操作，都要用sao账号登录操作，sys没有权限做这些，开启三权分立之后就是这样设计的，我见过好多人上来就用sys建用户，报错permission denied，找半天找不到原因，就是这个问题。

3.2 角色管理：创建、修改、删除全流程

我们以电商系统为例，要给运营团队创建一个运营角色，只能查询商品、修改订单状态，不能删数据，一步步来：

3.2.1 创建角色

-- 用sao登录后执行，NOLOGIN表示这个角色只是用来授权的，不能用来登录，符合最佳实践
CREATE ROLE role_ec_operation NOLOGIN;

-- 查看创建好的角色属性，确认是否正确
SELECT rolname, rolcanlogin, rolsuper FROM roles WHERE rolname = 'role_ec_operation';

结果显示rolcanlogin是f，就对了，我们就是要用来授权，不让直接登录。

3.2.2 给角色授权

权限分系统权限（比如连接数据库、使用schema）和对象权限（比如对表的增删改查）：

-- 1. 授予基础权限：允许连接电商数据库ecdb，允许使用ec这个schema
GRANT CONNECT ON DATABASE ecdb TO role_ec_operation;
GRANT USAGE ON SCHEMA ec TO role_ec_operation;

-- 2. 给商品表授予查询权限，给订单表授予查询+修改权限
GRANT SELECT ON TABLE ec.goods TO role_ec_operation;
GRANT SELECT, UPDATE ON TABLE ec.orders TO role_ec_operation;

-- 3. 实用技巧：给ec schema下所有现有表授予查询权限，不用一个个加
GRANT SELECT ON ALL TABLES IN SCHEMA ec TO role_ec_operation;

-- 4. 超级实用技巧：自动给未来在ec schema下新建的表授予权限，新建表不用重新授权
ALTER DEFAULT PRIVILEGES IN SCHEMA ec GRANT SELECT ON TABLES TO role_ec_operation;

💣 踩坑提示：很多人新建了表之后，发现角色访问不到，就是没加第四步的默认权限，每次新建表都要手动授权，加了这一句之后一劳永逸。

3.2.3 修改角色权限

运营岗后来要加一个新增订单的权限，原来的删除权限要收回来，怎么改：

-- 新增插入订单权限
GRANT INSERT ON TABLE ec.orders TO role_ec_operation;

-- 回收错误授予的删除权限
REVOKE DELETE ON TABLE ec.orders FROM role_ec_operation;

-- 修改角色属性：比如原来要改成可以登录，也可以改
ALTER ROLE role_ec_operation LOGIN;
-- 改回去就是ALTER ROLE role_ec_operation NOLOGIN;

-- 修改角色名称
ALTER ROLE role_ec_operation RENAME TO role_ecommerce_operation;

3.2.4 删除角色

很多人删角色报错role cannot be dropped because some objects depend on it，就是没处理依赖，正确的删除步骤是这样的：

-- 第一步：先查哪些用户绑定了这个角色
SELECT u.rolname AS user_name FROM auth_members m
JOIN roles r ON m.roleid = r.oid
JOIN roles u ON m.member = u.oid
WHERE r.rolname = 'role_ecommerce_operation';

-- 第二步：把角色从所有绑定的用户那里移除
REVOKE role_ecommerce_operation FROM user_zhangsan;

-- 第三步：如果角色拥有数据库对象，先转移所有权给对应管理员
ALTER TABLE ec.temp_table OWNER TO sys;

-- 第四步：最后删除角色
DROP ROLE role_ecommerce_operation;

按照这个步骤走，绝对不会报错，我第一次删角色卡了半小时，才搞清楚要先处理依赖，现在把步骤给你写清楚了，别再踩。

3.3 用户管理：创建、修改、删除实操

用户用来登录，一个人一个账号，绑定对应角色继承权限，绝对不要多人共用一个账号，过等保要求一人一号，出了问题也能追溯到个人。

我们给华东区运营张三创建一个账号，绑定刚才的运营角色：

-- 用sao登录创建用户，指定密码，设置默认角色，登录后自动激活角色权限
CREATE USER user_zhangsan WITH LOGIN PASSWORD 'Zs@Operation123' DEFAULT ROLE role_ec_operation;

-- 把角色授予用户，用户就继承所有权限
GRANT role_ec_operation TO user_zhangsan;

这里解释一下DEFAULT ROLE：就是用户登录之后，默认自动激活这个角色的权限，不用手动执行SET ROLE，非常方便，创建用户的时候直接指定就行。

3.3.1 修改用户

常见的修改场景：改密码、锁账号、换岗位改角色：

-- 改密码：用户自己可以改，管理员也可以帮所有用户改
ALTER USER user_zhangsan PASSWORD 'NewPass@Zs2024';

-- 锁账号：比如张三离职了，或者请假三个月，先锁账号，比直接删了好，留审计痕迹
ALTER USER user_zhangsan NOLOGIN;
-- 解锁就是ALTER USER user_zhangsan LOGIN;

-- 换岗位：张三转测试了，移除原来的运营角色，绑定测试角色
REVOKE role_ec_operation FROM user_zhangsan;
GRANT role_test TO user_zhangsan;
ALTER USER user_zhangsan DEFAULT ROLE role_test;

-- 限制并发连接：防止单个用户开太多连接占满资源，最多允许5个并发
ALTER USER user_zhangsan CONNECTION LIMIT 5;

-- 设置密码90天过期，符合合规要求，强制定期改密码
ALTER USER user_zhangsan PASSWORD EXPIRE INTERVAL 90 DAY;

3.3.2 删除用户

和删除角色一样，要先处理依赖，还有活跃连接，正确步骤：

-- 第一步：先锁账号，禁止新连接，防止删的过程中还有操作
ALTER USER user_zhangsan NOLOGIN;

-- 第二步：杀掉用户所有活跃连接，需要sys权限
SELECT terminate_backend(pid) FROM stat_activity WHERE usename = 'user_zhangsan';

-- 第三步：查看用户拥有哪些对象，转移所有权
SELECT n.nspname AS schema_name, c.relname AS object_name, c.relkind
FROM class c JOIN namespace n ON c.relnamespace = n.oid
WHERE c.relowner = (SELECT oid FROM roles WHERE rolname = 'user_zhangsan');
-- 转移所有对象所有权给对应管理员
REASSIGN OWNED BY user_zhangsan TO sys;

-- 第四步：删除用户所有的授权
DROP OWNED BY user_zhangsan;

-- 第五步：最后删除用户
DROP USER user_zhangsan;

这个步骤绝对没问题，我删了上百个闲置账号都是这么操作的，从来没报错。

3.4 三权分立实操：符合等保要求的DBA权限管理

刚才说了，KES的三权分立是核心安全特性，很多人不知道怎么用，我给大家举个实际例子：我们要创建一个安全管理员助理，只能创建业务用户，不能修改管理员权限，怎么做：

-- 用sao登录操作
-- 创建助理角色，不能登录
CREATE ROLE role_sao_assistant NOLOGIN;
-- 授予创建用户和角色的权限，不给修改管理员的权限
GRANT CREATE ROLE TO role_sao_assistant;
GRANT CREATE USER TO role_sao_assistant;
-- 创建助理用户，绑定角色
CREATE USER sao_li WITH LOGIN PASSWORD 'SaoLi@123456' DEFAULT ROLE role_sao_assistant;
GRANT role_sao_assistant TO sao_li;

这样，小李只能创建业务用户，改不了sao和sys的权限，实现了权限的最小化，非常灵活。

这里再强调一遍：生产环境必须开启三权分立，不要图省事关了，关了之后过不了等保，出了安全问题谁都担不起，只有测试环境可以关了图方便。

3.5 高级权限：行级、列级细粒度控制，满足高安全要求

现在很多核心业务要求细粒度权限，比如HR只能看自己部门的员工信息，财务才能看工资列，KES原生支持，不用第三方插件，实操给大家看：

3.5.1 列级权限：隐藏敏感列

员工表有工资列，普通HR只能看基本信息，不能看工资，只有财务能看：

-- 创建HR和财务角色
CREATE ROLE role_hr NOLOGIN;
CREATE ROLE role_finance NOLOGIN;

-- 给HR授予除了工资列之外的所有查询权限
GRANT SELECT (id, name, department, phone, entry_date) ON TABLE hr.employee TO role_hr;

-- 给财务授予所有列的权限
GRANT SELECT ON TABLE hr.employee TO role_finance;

测试一下：用HR账号登录执行SELECT * FROM hr.employee;，直接报错permission denied for column salary，完美，敏感列直接看不到，非常简单。

3.5.2 行级权限：只能看自己大区的数据

运营只能看自己大区的订单，每个运营登录后只能看到自己负责区域的数据，怎么实现：

-- 第一步：给订单表开启行级访问控制，需要表所有者或者sys操作
ALTER TABLE ec.orders ENABLE ROW LEVEL SECURITY;

-- 第二步：创建行级策略，规则是：当前会话设置的大区等于订单的大区，才能访问
CREATE POLICY policy_orders_by_dept ON ec.orders
FOR SELECT
USING (sales_dept = current_setting('app.current_dept', true)::text);

之后运营登录后，只要执行一句SET app.current_dept = 'east_china';，之后查询只能看到华东区的订单，就算他想越权也看不了其他区的数据，非常安全。

💣 踩坑提示：开启行级权限之后，默认所有行都拒绝访问，所以必须创建策略，我第一次开了行级权限忘了建策略，所有业务用户都查不到数据，折腾了一个小时才找到问题，这个坑一定要记住。

3.6 运维常用查询：怎么查所有用户、角色和权限？

运维的时候经常要查权限，我把常用的查询SQL整理好了，直接存起来用：

-- 1. 查看所有可登录的用户，带创建时间
SELECT rolname AS user_name, rolcreatedat AS create_time, rolcanlogin, rolsuper, connection_limit
FROM roles WHERE rolcanlogin = true ORDER BY rolcreatedat;

-- 2. 查看某个用户绑定了哪些角色
SELECT r.rolname AS role_name
FROM auth_members m
JOIN roles r ON m.roleid = r.oid
JOIN roles u ON m.member = u.oid
WHERE u.rolname = 'user_zhangsan';

-- 3. 查看某个角色拥有哪些表权限
SELECT grantee, table_catalog, table_schema, table_name, privilege_type
FROM information_schema.role_table_grants
WHERE grantee = 'role_ec_operation'
ORDER BY table_schema, table_name;

-- 4. 查看所有默认权限配置
SELECT * FROM default_acl;

这些都是我平时运维天天用的，不用自己拼SQL，直接拿过去跑就行。

---

四、生产环境最佳实践：都是踩坑踩出来的经验

我把这么多年项目总结的最佳实践整理出来，照着做，权限肯定合规，也不会出安全问题：

4.1 权限规划原则

1. 最小权限原则：只给用户完成工作必须的权限，多一点都不给，比如运营不需要删表，就绝对不给drop权限。
2. 角色分组原则：按岗位/业务分组创建角色，权限给角色，用户绑定角色，不要直接给用户授权，方便管理。
3. 三权分立强制开启：生产环境必须开，过等保必须要，也更安全。
4. 一人一号：禁止多人共用一个账号，出了问题能追溯，也符合合规要求。
5. 超级管理员仅限运维用：业务绝对不能用sysdba之类的超级账号连接数据库，我见过太多业务用超级账号，误删核心表，哭都来不及。

4.2 密码管理

1. 强制开启密码复杂度，要求至少8位，包含大小写、数字、特殊字符，强制90天过期更换，KES直接支持，一句话就能设置。
2. 定期扫描弱密码，闲置账号，每季度清理一次，离职员工账号3天内锁定，7天内删除，保留审计记录。
3. 超级管理员密码专人保管，定期更换，绝对不能写在代码里。

4.3 审计管理

1. 对所有管理员操作、权限变更开启审计，用sso配置审计策略，审计日志至少保留6个月，符合合规要求。
2. 定期检查审计日志，发现越权操作、异常登录及时处理。

4.4 特殊场景注意

如果你用NFS存储KES的数据文件，一定要注意：NFS挂载目录的所有者必须是kingbase用户，权限设置成700，不然会报Operation not permitted，我之前踩过这个坑，折腾了一晚上才找到原因，这里给大家提个醒。

---

五、常见踩坑汇总，帮你省时间

我把平时碰到最多的问题整理出来，碰到问题直接对应找解决方法：

1. 开启三权分立后，sys创建用户报错permission denied：原因是三权分立后只有sao能创建用户，sys没有这个权限，用sao登录操作就好。
2. 创建用户报错password不符合要求：密码太简单，换符合要求的强密码。
3. 删除用户/角色报错有依赖：按我上面给的步骤，先杀连接，转移所有权，删除授权，再删除就好。
4. 新建表，角色没有权限访问：没设置默认权限，加上ALTER DEFAULT PRIVILEGES IN SCHEMA xxx GRANT ...就好。
5. 开启行级权限后，所有用户都查不到数据：没创建RLS策略，开启后默认拒绝所有，必须创建策略。

---

六、总结

用户和角色管理是KES数据安全的基础，也是信创迁移过等保的核心要求，很多人觉得这个东西简单，就是建个用户给个权限，其实里面的讲究很多，规划不好，要么不合规过不了测评，要么留下安全隐患，出了问题追悔莫及。

今天这篇文章从概念到实操，从踩坑到最佳实践，都是我这么多年项目里攒的真东西，没有一句水文，大家可以直接拿去生产用，如果你正在做KES的迁移或者运维，这篇应该能帮你少踩好几个坑。