KES权限管理——从特权分类到导出控制

一、KES权限体系是怎么分层的？

很多新手刚接触KES的时候，会被各种权限名称绕晕：一会儿是管理特权，一会儿是系统特权，还有对象权限，还有角色和用户，分不清到底区别在哪。我先给大家理清楚底层逻辑，其实非常简单，KES用的是标准的RBAC（基于角色的访问控制）模型，核心逻辑就是：权限给角色，用户绑角色，批量管权限，比每个用户单独授权清晰一万倍。

从权限层级分，刚好对应我们今天讲的内容，一共分三大类核心权限：

管理特权：属于角色本身的属性，是最高层级的权限，决定了这个角色能不能做系统级的核心操作，比如是不是超级用户、能不能创建数据库、能不能做主从复制，这个是天生带的属性，不是后天授的。
系统特权：属于数据库层面的操作权限，允许你执行特定的系统级操作，比如能不能创建表、能不能创建视图、能不能创建角色，这个是需要手动授予的。
对象权限：是具体到某个数据库对象（表、视图、序列、函数等）的细粒度权限，比如你能不能读某张表、能不能改某张表、能不能删某张表，这个是最细粒度的权限，也是日常管控最多的。

搞清楚这个分层，后面就不会乱了，我们一个一个拆开讲，全带实操和踩坑提醒。

二、管理特权

管理特权是角色创建的时候就定义好的属性，后面可以改，核心作用是控制角色能不能做系统级的核心操作，我把常用的管理特权列出来，一个个讲：

管理特权	作用说明	危险等级
`SUPERUSER`	超级用户特权，拥有数据库最高权限，可以绕过所有权限检查，能做任何操作	⭐⭐⭐⭐⭐（最高危）
`LOGIN`	允许角色登录数据库，带这个属性的角色其实就是我们常说的"用户"，不带的就是纯角色，用来做权限分组	⭐
`CREATEDB`	允许创建新的数据库	⭐⭐
`CREATEROLE`	允许创建、修改、删除其他角色/用户	⭐⭐⭐
`REPLICATION`	允许做流复制，用来做主从集群的复制账号，只有需要做集群同步的账号才需要	⭐⭐⭐
`BYPASSRLS`	绕过行级安全检查，只有超级用户或者专门做行级安全管控的时候才用	⭐⭐⭐⭐

2.1 创建、修改、删除带管理特权的角色

（1）创建角色的时候指定管理特权

比如我们需要创建一个DBA助理角色，允许登录，能创建数据库和角色，不需要超级权限，命令如下：

sql 复制代码

CREATE ROLE dba_assist 
  WITH LOGIN 
       CREATEDB 
       CREATEROLE 
       PASSWORD 'YourPass123!@#';

如果要创建一个专门用来做主从复制的账号，只需要复制权限，不能登录做其他操作：

sql 复制代码

CREATE ROLE repl_user 
  WITH REPLICATION 
       LOGIN 
       PASSWORD 'ReplPass123!@#';

如果是创建一个纯权限角色，不需要登录，用来给用户批量授权：

sql 复制代码

CREATE ROLE biz_read_role NOLOGIN;

（2）修改已有角色的管理特权

比如原来的dba_assist没有复制权限，现在需要给他加上，命令：

sql 复制代码

ALTER ROLE dba_assist WITH REPLICATION;

如果要去掉某个特权，只需要加NO前缀就行，比如原来的dba_assist不小心给了超级权限，现在要收回：

sql 复制代码

ALTER ROLE dba_assist WITH NOSUPERUSER;

（3）删除不需要的角色

删除角色很简单，如果角色没有被任何用户依赖，可以直接删：

sql 复制代码

DROP ROLE IF EXISTS old_test_role;

这里要提前踩坑：如果角色已经被赋予给其他用户了，直接删会报错，很多人图省事会加CASCADE强制删：

sql 复制代码

-- 生产环境绝对不要随便这么写！
DROP ROLE IF EXISTS old_test_role CASCADE;

CASCADE会级联删除所有和这个角色相关的权限赋予关系，如果你这个角色是给10个开发用的，删了之后10个开发的权限都会丢，直接影响业务。我一般删角色之前，都会先查一遍这个角色被哪些用户拥有，确认没用了再删，后面我会给大家查询脚本。

2.2 管理特权的核心踩坑总结

我见过最多的问题就是超级权限滥用，我之前碰到一个项目，整个项目组8个人，每个人都有超级权限，美其名曰"方便调问题"，结果去年出了事故，开发改bug的时候不小心把整个库给删了，找都找不回来。

这里给大家定一个死规则：整个生产环境，除了初始的system用户，最多再留1-2个超级用户，就是负责日常运维的核心DBA，其他人绝对不给超级权限。哪怕开发真的需要临时提权调问题，调完马上收回，不要一直开着。这个是血的教训，我见过太多因为超级权限滥用出的事故，千万不要抱有侥幸心理。

三、系统特权

系统特权和管理特权不一样，管理特权是角色的天生属性，系统特权是需要你手动授予的，核心作用是控制你能不能在数据库里做特定的操作，比如创建表、创建视图、创建函数这些。

常见的系统特权我给大家列出来，常用的其实就那几个：CREATE TABLE、CREATE VIEW、CREATE SEQUENCE、CREATE FUNCTION、CREATE SCHEMA，还有一类带ANY的特权，比如CREATE ANY TABLE，意思是你可以在任何模式下创建表，这个是高危特权。

3.1 系统特权的授予和撤销

（1）授予系统特权

比如给dba_assist授予创建表、创建序列、创建函数的权限：

sql 复制代码

GRANT CREATE TABLE, CREATE SEQUENCE, CREATE FUNCTION TO dba_assist;

如果要给角色授予在某个模式下创建对象的权限，命令是：

sql 复制代码

-- 允许dba_assist在biz模式下创建对象
GRANT CREATE ON SCHEMA biz TO dba_assist;

（2）撤销系统特权

比如要收回dba_assist创建表的权限：

sql 复制代码

REVOKE CREATE TABLE FROM dba_assist;

要收回在biz模式下创建对象的权限：

sql 复制代码

REVOKE CREATE ON SCHEMA biz FROM dba_assist;

3.2 系统特权的核心踩坑总结

第一个坑：随便给带ANY的系统特权 。很多新手图方便，给开发直接授CREATE ANY TABLE，意思就是开发可以在任何模式下创建任何表，哪怕是核心业务模式，这个非常危险，万一开发不小心把表建到核心业务模式里，很容易搞乱业务。只有DBA才需要给ANY类的特权，普通开发绝对不要给。

第二个坑：随便给public模式的CREATE权限，这个其实后面讲PUBLIC角色的时候还会再说，默认安装完之后，public模式给所有人开了CREATE权限，也就是任何用户都能在public下创建对象，这个是高危漏洞，必须收回，后面我会给大家操作命令。

四、对象权限

对象权限是最细粒度的权限，管控到具体每一张表、每一个视图、每一个序列，不同的对象有不同的权限，我给大家分类型理清楚：

对象类型	常见可用权限	高危权限
表（TABLE）	SELECT、INSERT、UPDATE、DELETE、TRUNCATE、REFERENCES、TRIGGER	DROP、TRUNCATE
视图（VIEW）	SELECT、INSERT、UPDATE、DELETE	DROP
序列（SEQUENCE）	USAGE、SELECT、UPDATE	一般只需要USAGE，不需要其他
函数（FUNCTION）	EXECUTE	EXECUTE给PUBLIC要小心
模式（SCHEMA）	CREATE、USAGE	CREATE

4.1 对象权限的授予和撤销

（1）给单个对象授权

比如我们要给业务用户app_user授予业务表biz_order的查询、新增、修改权限，不给删除和删除表的权限，命令是：

sql 复制代码

GRANT SELECT, INSERT, UPDATE ON TABLE biz.biz_order TO app_user;

这里注意，不要图省事写GRANT ALL ON，ALL会把DROP、TRUNCATE这些高危权限也一起给出去，很多人就是图省事吃了亏，开发不小心把表删了都找不到原因。我从来不会给普通用户ALL权限，都是把需要的权限一个一个列出来，绝对不多给。

（2）给整个模式下的所有同类对象授权

实际项目中我们一般都是按业务分模式，一个业务一个模式，给整个模式授权一次就够了，不用一张一张表授，比如给app_role授权biz模式下所有表的增删改查权限，给所有序列的USAGE权限：

sql 复制代码

-- 给所有表授权增删改查
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA biz TO app_role;
-- 给所有序列授权USAGE（自增列必须要这个权限，不然插入会报错）
GRANT USAGE ON ALL SEQUENCES IN SCHEMA biz TO app_role;

这里还有一个很实用的命令，就是配置默认权限，以后你在这个模式下新建的对象，自动给角色授权，不用每次新建都手动授：

sql 复制代码

-- 以后biz模式下新建的表，自动给app_role授权增删改查
ALTER DEFAULT PRIVILEGES IN SCHEMA biz GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_role;
-- 新建的序列自动给USAGE权限
ALTER DEFAULT PRIVILEGES IN SCHEMA biz GRANT USAGE ON SEQUENCES TO app_role;

这个命令真的救了我无数次，之前没配置默认权限的时候，每次开发新建表，都要找DBA来授权，天天找你烦都烦死，配置完之后自动授权，省了超多事。

（3）撤销对象权限

比如要收回app_user对biz_order的修改权限：

sql 复制代码

REVOKE UPDATE ON biz.biz_order FROM app_user;

要收回整个模式下的所有表的删除权限：

sql 复制代码

REVOKE DELETE ON ALL TABLES IN SCHEMA biz FROM app_role;

4.2 对象权限的核心踩坑总结

第一个坑：忘了给序列的USAGE权限，这个是我刚接触KES的时候踩过最多的坑，很多人建完自增表，给了表的权限，结果插入数据的时候一直报"权限不足"，查半天找不到原因，就是忘了给序列的USAGE权限，自增列插入的时候要读序列的下一个值，必须要有USAGE权限，大家一定要记住，给表授权的时候别忘了给同模式下的序列授权。

第二个坑：给普通用户开放DROP权限，除了DBA和测试库的开发，生产环境任何普通用户都不要给DROP和TRUNCATE权限，应用账号只需要增删改查，绝对不需要删表的权限，哪怕是真的要删表，也是DBA来操作，不要给应用开这个权限。我之前碰到过一个应用漏洞，黑客拿到应用账号权限之后直接删了核心表，就是因为应用账号有DROP权限，这个教训真的太大了。

五、角色和用户授权

很多新手不知道角色的作用，喜欢直接给每个用户单独授权，结果时间长了，几十个用户，每个人权限都不一样，改一次权限要改几十个地方，很容易漏，出问题也不好查。

正确的做法是：按职责创建角色，给角色授权，然后把角色赋给对应用户，改权限的时候只要改角色就行，所有绑定这个角色的用户自动生效，非常好管理。我给大家举个实际的例子，实操一遍完整流程：

场景：我们业务系统有三类需要读业务库的用户：运营、数据分析师、运维，都只需要读权限，不需要写权限。

第一步：创建一个只读业务角色，不需要登录：

sql 复制代码

CREATE ROLE biz_read NOLOGIN;

第二步：给角色授权biz模式下所有表的只读权限，配置默认权限：

sql 复制代码

GRANT SELECT ON ALL TABLES IN SCHEMA biz TO biz_read;
ALTER DEFAULT PRIVILEGES IN SCHEMA biz GRANT SELECT ON TABLES TO biz_read;

第三步：创建具体用户，把只读角色赋给对应用户：

sql 复制代码

-- 创建运营用户
CREATE ROLE oper_user1 WITH LOGIN PASSWORD 'OperPass123!';
CREATE ROLE oper_user2 WITH LOGIN PASSWORD 'OperPass123!';
-- 创建数据分析师用户
CREATE ROLE analyst_user1 WITH LOGIN PASSWORD 'AnaPass123!';
-- 赋予只读角色
GRANT biz_read TO oper_user1, oper_user2, analyst_user1;

就这么简单，以后如果要加新的只读用户，只要创建完用户，一句GRANT biz_read TO 用户名就搞定了；以后如果要改权限，比如要加新的模式的只读权限，只要给biz_read加一次权限，所有用户自动就有了，比一个个用户改方便一万倍。

如果用户需要多个权限，比如开发既需要读业务库，又需要写测试库，只要把两个角色都赋给开发就可以了：

sql 复制代码

GRANT biz_read, dev_write TO dev_user1;

非常灵活，分层清晰。

六、撤销权限和删除角色

很多人操作权限的时候图快，不查依赖直接删，结果把线上业务搞崩了，我给大家说一下标准流程：

如果你要删除一个角色，第一步先查这个角色被哪些用户拥有，确认所有用户都不用了再删，查询语句我给大家写好了：

sql 复制代码

-- 查询某个角色被哪些用户拥有，把下面的biz_read换成你要查的角色名
SELECT u.rolname AS 所属用户名 
FROM sys_roles r 
JOIN sys_role_members rm ON r.oid = rm.roleid 
JOIN sys_roles u ON rm.member = u.oid 
WHERE r.rolname = 'biz_read';

查出来如果结果是空的，说明没有用户用这个角色，可以直接删；如果有结果，先确认这些用户是不是真的不需要这个角色了，把角色从用户那里收回再删：

sql 复制代码

-- 先从用户那里收回角色
REVOKE biz_read FROM user1, user2;
-- 再删角色
DROP ROLE biz_read;

绝对不要上来就DROP ROLE ... CASCADE，除非你明确知道你在做什么，不然真的会出大事。

如果你只是要收回角色给用户的权限，直接REVOKE就行：

sql 复制代码

REVOKE biz_read FROM old_user;

如果要收回角色本身的某个权限，比如收回biz_read对biz模式的SELECT权限：

sql 复制代码

REVOKE SELECT ON ALL TABLES IN SCHEMA biz FROM biz_read;

七、PUBLIC角色

PUBLIC角色是KES里一个特殊的默认角色，所有创建出来的用户/角色，默认都属于PUBLIC角色，也就是说，你给PUBLIC授什么权限，所有用户自动就有什么权限，这个特性如果不用好，就是最大的安全盲区。

默认安装完KES之后，PUBLIC角色有两个默认权限非常危险：

PUBLIC在public模式下有CREATE权限，也就是任何用户都能在public模式下创建对象，不管是不是普通用户；
PUBLIC在public模式下所有函数有EXECUTE权限，也就是任何用户都能执行public模式下的所有函数。

我做过很多次安全检查，十个项目有八个项目的PUBLIC权限没收紧，全是高危漏洞，我之前碰到过一个客户，有个外包开发离职之后，因为PUBLIC权限开着，他直接登录进去，在public模式下创建了一个恶意函数，拿到了服务器权限，把整个核心库加密了，差点要交赎金，这个就是典型的PUBLIC权限没收紧的问题。

7.1 收紧PUBLIC权限的标准步骤

我把标准命令给大家写好了，生产环境安装完之后第一时间就要跑：

sql 复制代码

-- 收回PUBLIC在public模式下的CREATE权限，只留USAGE（允许找对象）
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
-- 收回PUBLIC对public模式下所有函数的执行权限
REVOKE ALL ON ALL FUNCTIONS IN SCHEMA public FROM PUBLIC;
-- 收回PUBLIC对public模式下所有表的权限，有需要再单独授
REVOKE ALL ON ALL TABLES IN SCHEMA public FROM PUBLIC;

做完之后，如果确实有某些函数或者表需要给所有用户用，再单独授权，比如我们有一个公共的计算函数add，需要所有用户都能调用，那单独授就行：

sql 复制代码

GRANT EXECUTE ON FUNCTION public.add(int, int) TO PUBLIC;

这样就安全了，只开放必要的权限，其他全部收回来，从根源上避免恶意操作。

7.2 怎么查询当前PUBLIC有哪些权限？

我给大家写好了查询脚本，合规检查之前跑一遍就能看到所有给PUBLIC开放的权限，多余的直接收：

sql 复制代码

SELECT 
  table_schema, 
  table_name, 
  privilege_type 
FROM information_schema.table_privileges 
WHERE grantee = 'PUBLIC';

非常方便，跑出来一看就清楚了。

八、权限审计

很多人做权限审计的时候不知道怎么查，我把我日常用的所有查询脚本都整理在这里，全是生产环境用熟了的，直接复制就能用：

1. 查询所有用户自定义的角色/用户，过滤系统内置角色

sql 复制代码

SELECT 
  rolname AS 角色名,
  CASE WHEN rolsuper THEN '是' ELSE '否' END AS 是否超级用户,
  CASE WHEN rolcanlogin THEN '是' ELSE '否' END AS 是否允许登录,
  CASE WHEN rolcreaterole THEN '是' ELSE '否' END AS 能否创建角色,
  CASE WHEN rolcreatedb THEN '是' ELSE '否' END AS 能否创建数据库,
  CASE WHEN rolreplication THEN '是' ELSE '否' END AS 能否复制
FROM sys_roles 
WHERE rolname NOT LIKE 'sys_%' 
  AND rolname != 'postgres' 
  AND rolname != 'system';

这个脚本我每次做项目初始化之后都会跑一遍，一下子就能看到有多少多余的超级用户，太方便了。

2. 查询某个用户拥有的所有角色

sql 复制代码

-- 把下面的'dev_user1'换成你要查的用户名
SELECT r.rolname AS 拥有的角色名
FROM sys_roles r 
JOIN sys_role_members rm ON r.oid = rm.roleid 
JOIN sys_roles u ON rm.member = u.oid 
WHERE u.rolname = 'dev_user1';

删角色之前跑一遍，确认哪些用户在用，不会乱删。

3. 查询某个用户/角色在指定模式下的所有对象权限

sql 复制代码

-- 把'app_user'换成用户名，'biz'换成模式名
SELECT 
  p.table_name AS 表名,
  p.privilege_type AS 权限类型
FROM information_schema.table_privileges p 
WHERE p.grantee = 'app_user' 
  AND p.table_schema = 'biz';

权限审计的时候跑一遍，一下子就能看到这个用户有没有不该有的DROP权限，一目了然。

4. 查询所有超级用户

sql 复制代码

SELECT rolname AS 超级用户名 FROM sys_roles WHERE rolsuper = true AND rolcanlogin = true;

定期跑一遍，看看有没有多余的超级用户，有的话马上收回权限。

5. 查询30天没登录的用户

sql 复制代码

SELECT 
  rolname AS 用户名,
  last_login AS 最后登录时间
FROM sys_user_stat 
WHERE last_login < current_date - interval '30 days'
  AND rolcanlogin = true;

定期清理不用的僵尸账号，避免不用的账号被人利用，这个也是合规要求的。

九、数据导出控制

很多人觉得权限管控到表就够了，其实数据导出是很多人忽略的点，有了SELECT权限就能导出全表数据，如果被人拿走了整个库的敏感数据，那损失就大了，我给大家讲几个常用的管控方法，都是实操能用的：

9.1 从权限根源限制

最基础的就是，不需要访问敏感数据的用户，绝对不给敏感表的SELECT权限，只给脱敏视图的权限，我给大家举个实操例子：

我们有一张用户表user_info，里面有身份证号、手机号这些敏感信息，普通运营只需要看用户名和注册时间，不需要看完整的敏感信息，我们就这么做：

原表user_info只有超级管理员能访问，普通用户没有权限；
创建一个脱敏视图，给普通用户用：

sql 复制代码

CREATE VIEW user_info_view AS 
SELECT 
  id,
  username,
  -- 身份证只留最后四位，中间打码
  CONCAT('************', RIGHT(id_card, 4)) AS id_card,
  -- 手机号打码
  CONCAT('***********', RIGHT(mobile, 4)) AS mobile,
  create_time
FROM user_info;

给普通用户只授予视图的SELECT权限，不给原表的权限：

sql 复制代码

GRANT SELECT ON user_info_view TO biz_read;

这样就算普通用户导出数据，拿到的也是脱敏后的，不会泄露完整的敏感信息，这个方法非常实用，也符合合规要求。

9.2 所有导出操作留痕

对于需要导出数据的用户，我们要开启审计日志，所有导出操作都留痕，出了问题能溯源，KES自带审计插件，配置也很简单：

修改kingbase.conf配置文件，加上：

ini 复制代码

shared_preload_libraries = 'sysaudit'
sysaudit.enable = on
-- 记录所有SELECT查询和COPY操作
sysaudit.audit_functions = 'select,copy'

重启数据库生效，之后所有的查询和导出操作都会记录到审计日志里，哪个用户什么时候导出了什么数据，都能查到，就算出了问题也能溯源。

9.3 避免批量导出

对于只能通过应用访问的应用账号，我们可以在连接层限制最大返回结果集，一次最多返回1000行，就算应用账号被拿下，也不能一次导出全表的所有数据，降低泄露风险。

对于需要登录服务器运维的用户，只给需要的用户开放服务器登录权限，普通开发不需要登录数据库服务器，就不要开，避免用户直接用COPY命令导出全表数据。

十、完整生产配置案例

我给大家整理了一个标准的生产环境权限配置完整流程，我每个项目都用这个流程，大家直接拿走套就行：

场景：生产业务系统，三类角色：核心DBA、开发人员（只需要读生产，写测试）、应用账号（只能访问业务表，增删改查，不能删表）

完整步骤：

sql 复制代码

-- 1. 创建基础角色
-- 核心DBA角色，只有超级DBA用
CREATE ROLE dba_role WITH LOGIN SUPERUSER CREATEDB CREATEROLE REPLICATION PASSWORD 'DbaPass_2026!';
-- 开发只读角色，生产环境用
CREATE ROLE dev_read_role NOLOGIN;
-- 应用访问角色，生产业务用
CREATE ROLE app_role NOLOGIN;

-- 2. 收紧PUBLIC权限，第一步必须做
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
REVOKE ALL ON ALL FUNCTIONS IN SCHEMA public FROM PUBLIC;

-- 3. 给各个角色授权
-- 开发只读角色：biz模式所有表只读
GRANT SELECT ON ALL TABLES IN SCHEMA biz TO dev_read_role;
ALTER DEFAULT PRIVILEGES IN SCHEMA biz GRANT SELECT ON TABLES TO dev_read_role;

-- 应用角色：biz模式所有表增删改查，序列USAGE，不给DROP/TRUNCATE
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA biz TO app_role;
GRANT USAGE ON ALL SEQUENCES IN SCHEMA biz TO app_role;
ALTER DEFAULT PRIVILEGES IN SCHEMA biz GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_role;
ALTER DEFAULT PRIVILEGES IN SCHEMA biz GRANT USAGE ON SEQUENCES TO app_role;

-- 4. 创建具体用户，赋予角色
-- 创建DBA用户
CREATE ROLE dba_laohan WITH LOGIN PASSWORD 'LhPass_2026!';
GRANT dba_role TO dba_laohan;

-- 创建开发用户
CREATE ROLE dev_zhangsan WITH LOGIN PASSWORD 'ZsPass_2026!';
GRANT dev_read_role TO dev_zhangsan;

-- 创建应用用户
CREATE ROLE biz_app WITH LOGIN PASSWORD 'AppPass_2026!';
GRANT app_role TO biz_app;

-- 5. 权限检查，跑脚本确认
-- 检查应用用户权限，确认没有DROP/TRUNCATE
SELECT table_name, privilege_type 
FROM information_schema.table_privileges 
WHERE grantee = 'biz_app' AND table_schema = 'biz';
-- 检查PUBLIC权限，确认没有多余权限
SELECT * FROM information_schema.table_privileges WHERE grantee = 'PUBLIC';
-- 检查超级用户，确认只有一个
SELECT rolname FROM sys_roles WHERE rolsuper = true AND rolcanlogin = true;

整个流程下来，权限清晰，分层明确，最小权限原则也满足，合规也能过，直接套就行。

十一、总结

做了这么多年权限管理，我总结了几个核心原则，只要记住这几条，就不会出大问题：

最小权限原则：只给用户完成工作必须的权限，多一点都不给，开发只要读生产，就绝对不给写权限，应用只要增删改查，就绝对不给删表权限。
角色分层管理：永远用角色批量管理权限，不要给单个用户单独授权，改权限只要改角色，效率高不容易错。
定期权限审计：每个季度跑一次审计脚本，清理僵尸账号，收回多余权限，离职员工的账号一定要第一时间删除，三个月不用的测试账号一定要锁。
PUBLIC权限必须收紧：安装完第一时间就收，默认的权限绝对不能用，只开放必要的权限。
敏感数据必须脱敏：敏感数据绝对不能给普通用户开放原始表权限，只给脱敏视图，从根源上避免敏感数据泄露。

权限管理是数据安全的第一道防线，也是最后一道防线，很多人觉得数据库跑通业务就完事了，其实权限没做好，哪天出了误删或者数据泄露，哭都来不及。这篇文章里所有的命令、脚本、流程都是我在几十个生产项目里打磨出来的，都是实打实踩坑踩出来的经验，大家直接拿去用就可以，省下你踩坑的时间。

最后------同行者计划

无论您是金仓用户、客户，还是生态合作伙伴；无论您是技术岗还是业务岗，是管理者还是一线工程师------只要您对数据库市场有敏锐的洞察，身边有潜在的业务需求，您就是我们最珍视的同行者。

为什么加入"同行者计划"？

最好的合作是"共赢"。只需提供真实线索，后续的跟进、转化由金仓团队接手。朋友们将获得从 "即时激励" 到 "长期权益" 的全方位回报。

如何提供线索？

https://bbs.kingbase.com.cn/collectionForm/10013

一键填写表单即可，金仓将及时跟踪反馈。

一次线索推荐，可能促成一次系统的国产化替代；一条关键信息，可能为行业生态带来新的活力。