1. 项目概述1.1 核心需求解析GBase 8s作为国产关系型数据库管理系统在企业级应用中承担着核心数据存储与管理的职责。它支持完整的SQL标准提供高可用、高安全性的数据服务能力广泛应用于金融、政务、大型企业的核心业务系统。在实际运维过程中数据库管理员经常需要对用户权限进行精细化管理其中取消指定用户的EXTEND角色就是一个非常典型且高频的运维操作。先说清楚EXTEND角色到底是个什么东西。在GBase 8s的权限体系中角色Role是为批量授权而设计的权限集合载体管理员创建一个角色把若干权限打包给这个角色再通过GRANT语句把角色授予具体用户这样就避免了一条一条给用户授权带来的运维负担。而EXTEND角色并不是GBase 8s默认存在的系统角色它是数据库创建者或者管理员根据业务需要自行创建的一个自定义角色通常会被授予一些扩展性的操作权限比如访问特定的扩展模块、调用某些高级函数或者操作某些非标准的数据库对象。标题中提到的取消指定用户EXTEND角色从权限管理的视角来看本质上是执行REVOKE操作把原本授予某个用户的EXTEND角色回收回来。这项操作在真实的运维场景中很常见比如员工离职、岗位调整、权限收敛审查、安全合规整改都会触发这类需求。早些年我碰到过不少刚接触GBase 8s的同事一上来就习惯性用MySQL的习惯去操作认为把用户DROP掉就完事了结果发现用户删了之后应用侧各种报错因为其他关联权限还没处理干净。相比之下REVOKE角色操作做得干净利落不会误伤其他权限是权限调整的首选方案。这篇文章适合GBase 8s的数据库管理员、运维工程师、安全审计人员以及正在学习国产数据库迁移的开发者阅读。我会从角色权限体系的基础概念讲起一步步拆解取消EXTEND角色的完整操作流程同时会把实际操作中我踩过的坑和总结出来的经验一并分享出来。1.2 环境与前置条件说明在进入具体操作之前先把前置条件讲清楚避免大家照着文章操作到最后一步才发现环境不对白折腾一趟。数据库版本GBase 8s所有主流版本包括8.3、8.5等系列均支持角色管理和REVOKE操作但不同小版本的系统表结构可能存在细微差异建议在测试环境先行验证。操作系统GBase 8s支持主流Linux发行版如CentOS、RedHat、麒麟、统信UOS、AIX以及Windows Server平台本文操作涉及的系统命令在Linux环境下执行。操作权限执行REVOKE操作必须拥有相应的权限。如果你是以DBA身份登录通常是sysdba角色如果当前用户是普通用户需要确认是否拥有对该用户执行授权管理的权限。工具准备可以使用GBase 8s自带的dbaccess命令行工具也可以使用图形化管理工具GBaseDataStudio。本文全部使用dbaccess方式演示因为命令行方式最直接、最通用在无图形界面的服务器上也能操作。这里提醒一句GBase 8s的权限体系与美国数据库的标准权限模型如PostgreSQL的role体系在实现上有相似之处但又有自己的独特性格。如果要给一个刚上手的DBA打比方可以把GBase 8s里的用户理解为门禁卡持有人角色理解为门禁卡上的权限组USER向角色授权角色向数据库对象授权取消了用户的某个角色就相当于把这张门禁卡上的某个权限组划掉了。2. 深入理解GBase 8s的角色权限体系2.1 USER、ROLE与EXTEND角色的关系GBase 8s的权限体系可以分成三个层面来理解用户、角色、对象权限。用户是最基本的访问实体角色是权限的集合对象权限则是具体落在某个表、视图、存储过程、函数等数据库对象上的实际操作权利。在一个典型的业务系统里权限的配置路径是这样的创建用户 - 创建角色 - 把权限打包给角色 - 把角色授予用户这套分层设计的好处非常明显。假设系统里有三千个用户需要访问订单表如果不用角色管理员要执行三千条GRANT SELECT语句而如果建一个名为order_reader的角色把这个角色授予三千个用户一条语句就搞定了后续要回收权限时也只需要操作角色或操作用户变通空间大很多。EXTEND角色在这个体系中扮演的通常是高级功能扩展的角色。在GBase 8s中某些扩展功能模块默认不向普通用户开放管理员会创建一个EXTEND角色把使用这些扩展功能所需的权限统一下放。比如有的企业允许开发人员通过DBlink功能访问外部数据库管理员就可以创建EXTEND角色并授予DBlink相关的使用权限再把角色授予需要这个能力的开发账号。以上是对EXTEND角色使用场景的通用描述。具体到某个特定业务环境EXTEND角色到底包含哪些权限以数据库中的实际定义为准建议通过我后面介绍的系统表查询方法确认。2.2 EXTEND角色的典型授权操作在取消EXTEND角色之前有必要先了解它当初是怎么被授予的这样逆向操作时就能做到心中有数。判断一个用户当前是否拥有EXTEND角色可以通过以下方式查询。GBase 8s的系统表def_role中记录了角色的定义信息sysuserauths视版本不同有些版本的表名稍有差异中记录了用户和角色之间的授权关系。下面是我在实际环境中验证过的查询方法-- 查看角色是否存在及其定义信息 SELECT * FROM def_role WHERE rolename EXTEND; -- 查看指定用户被授予的角色 SELECT username, rolename, auth_type FROM sysuserauths WHERE username target_user;举个例子假设管理员给用户zhangsan授过EXTEND角色标准授权语句通常是这样的GRANT EXTEND TO zhangsan;看到这里有些熟悉其他数据库的朋友可能会问怎么没有带WITH ADMIN OPTION之类的子句GBase 8s的GRANT语法确实支持多种形式如果要让用户具备把EXTEND角色继续转授给其他用户的能力授权时还要加上授予选项比如GRANT EXTEND TO zhangsan WITH ADMIN OPTION;加了WITH ADMIN OPTION之后zhangsan就有了把这个角色再授予别人的权限。这一点在做权限回收时尤其要注意因为如果存在级联授权取消角色的操作会牵涉到更复杂的权限依赖关系后面我会专门讲这个坑。2.3 取消EXTEND角色的核心原理取消指定用户的EXTEND角色在SQL层面执行的语句是REVOKE核心语法如下REVOKE EXTEND FROM user_name;这条语句执行后系统会从sysuserauths或对应权限视图中移除user_name与EXTEND角色之间的授权关系。这里要特别区分一下REVOKE角色和REVOKE对象权限这两种操作的差别REVOKE角色是把整组权限的集合收回REVOKE对象权限是精确到某个表、某个视图上的具体权限。用一个例子来说明。假设zhangsan用户同时拥有EXTEND角色和ORDER表的SELECT权限执行REVOKE EXTEND FROM zhangsan之后zhangsan只是不再拥有EXTEND角色所捆板的那组权限但ORDER表上的SELECT权限如果没有通过EXTEND角色授予就依然保留。反过来说如果ORDER表上的SELECT权限是通过EXTEND角色授予的那取消EXTEND角色之后这个权限也会跟着一起失效。这是初学者最容易模糊的地方。还有一层需要理解取消角色和删除角色不是一回事。取消角色只是切断用户和角色之间的关联EXTEND角色这个权限模板依然存在于数据库中以后想再给别的用户授权直接用GRANT EXTEND TO另一个用户即可。真正删除角色需要执行DROP ROLE而且DROP ROLE前必须先把所有用户的该角色授权全部取消。这个操作顺序如果搞反了数据库会直接报错错误信息大致会提示role is granted to user。3. 实操准备连接数据库与权限确认3.1 使用dbaccess工具连接GBase 8sGBase 8s的命令行工具dbaccess是日常运维中使用频率最高的工具可以执行SQL语句和存储过程。连接方式有很多种我推荐在实际生产环境中使用以下几种。第一种方式直接指定数据库名和连接信息dbaccess -e your_databaseyour_server加上-e参数的含义是回显SQL语句和结果这样在批量执行脚本或者记录操作日志时非常有用。第二种方式适用于需要执行多个SQL文件或者批量操作的场景dbaccess your_databaseyour_server your_script.sql这种方式能把SQL文件里的内容一次性执行完适合自动化运维脚本。第三种方式如果服务器上配置了环境变量直接输入dbaccess不带参数进入交互式环境然后在提示符下选择数据库或者使用CONNECT语句CONNECT TO your_databaseyour_server USER your_username USING your_password;我个人的习惯是尽量在命令行里写全连接信息避免交互式环境在自动化运维中失控。毕竟生产环境操作讲究的是可记录、可追溯、可审计命令行方式天然满足这三个要求。3.2 确认当前用户是否具备REVOKE权限REVOKE操作不是谁都能执行的GBase 8s对权限回收的管控是有明确要求的。通常来说以下三类用户具备执行REVOKE EXTEND FROM指定用户的资格拥有sysdba角色的数据库管理员。拥有对该角色进行授权管理权限的用户也就是GRANT EXTEND TO user时使用的那把钥匙对应的人。被授予了WITH GRANT OPTION且该授权链路未断开的相关权限持有者。查询当前用户身份和角色的一种方法是-- 查看当前登录用户信息 SELECT CURRENT_USER, CURRENT_ROLE FROM systables WHERE tabid 1;注意在旧版本中CURRENT_ROLE可能不被支持可以查询用户对应的系统表确认。如果查询结果不好使最简单的办法是直接执行一条REVOKE语句试试数据库会毫不客气地报错——权限不足权限不足、没有权限等信息这比纠结系统表字段直观多了。顺便说一句在实际运维中我遇到过一种情况明明DBA账号能查询系统表但执行REVOKE时报权限不足。排查后发现是管理员连接数据库时使用的是普通用户身份登录到操作系统然后通过操作系统的信任连接方式进入数据库导致数据库层面的身份并非预期的DBA账号。这个坑希望各位注意连接时的身份确认非常重要不能只看你执行dbaccess时用的Linux账号是什么。3.3 查询指定用户当前具备的角色在动手取消EXTEND角色之前一定要先确认用户当前到底有没有这个角色以及是否还存在级联关系。这一步虽然简单却是整个操作中最值得花时间做扎实的环节。Windows环境的图形化管理工具GBaseDataStudio可以直接在安全管理器中看到用户角色关系但生产环境服务器上一般没图形界面所以我还是推荐在dbaccess里用SQL查询这里给出我自己常用的一套查询组合-- 查询指定用户被授予的所有角色精确查询 SELECT a.username, a.rolename, a.auth_type FROM sysuserauths a WHERE a.username zhangsan AND a.rolename EXTEND; -- 更全面的查询查看用户所有角色授权记录 SELECT username, rolename, auth_type FROM sysuserauths WHERE username zhangsan;auth_type字段的含义说明一下在GBase 8s的权限记录里不同的授权类型通过不同的取值来区分比如用户被授予角色、用户拥有对象权限等具体的取值含义可以参看对应版本的《GBase 8s SQL指南》中的系统表说明。如果查询不到任何记录说明该用户压根没有EXTEND角色强行执行REVOKE EXTEND会报“用户没有该角色”的相关错误。如果查询到记录还需要进一步确认一下是否有其他用户是通过这个用户获得EXTEND角色的-- 查询这个用户是否将EXTEND角色转授给了别人 SELECT username, rolename FROM sysuserauths WHERE rolename EXTEND AND grantor zhangsan;这个查询结果直接决定后面是否需要进行级联处理。我先把这个逻辑讲清楚如果zhangsan把EXTEND角色授予了lisi而现在管理员收回了zhangsan的EXTEND角色那么lisi的EXTEND角色是否保留取决于当初GRANT EXTEND TO zhangsan时是否带了WITH ADMIN OPTION以及数据库版本对级联回收的策略。我推荐的做法是遇到有转授关系的场景先查清楚链条再动手。4. 核心实操取消指定用户EXTEND角色的完整流程4.1 常规场景直接取消用户EXTEND角色最标准的操作流程我整理成了可以照着执行的步骤序列。第一步确认目标用户存在并查看其基本信息。如果用户信息都不存在后面的操作就没有意义了。SELECT username, usertype, defrole, status FROM sysusers WHERE username zhangsan;第二步确认EXTEND角色存在。SELECT rolename, owner FROM def_role WHERE rolename EXTEND;第三步确认该用户当前确实拥有EXTEND角色。这一步的SQL我在上一节已经给出这里就不重复了但强调一下这一步一定不能省尤其是生产环境别以为用户之前有现在就一定有权限管理的状态往往是你以为的只是你以为的。第四步执行取消操作。REVOKE EXTEND FROM zhangsan;第五步验证取消结果。重新执行第三步的查询确认sysuserauths中已经查不到zhangsan和EXTEND的关联记录。对于这个最简单的场景整个过程30秒就能完成。但在生产环境操作时有一个细节值得注意在执行REVOKE之前把当时的会话信息、执行时间、操作人所用的账号记录下来。别以为这是多余的真到了出问题回溯时这些记录能帮你省下大量扯皮的精力。REVOKE语句在事务中执行时可以搭配BEGIN WORK和COMMIT WORK来实现可控提交。如果发现误操作趁事务还没提交立即执行ROLLBACK WORK就能撤销。但是注意如果在dbaccess的自动提交模式下执行REVOKE语句执行完就立即生效没有反悔的机会。下面给出一个手动事务控制的示例BEGIN WORK; REVOKE EXTEND FROM zhangsan; -- 确认无误后提交 COMMIT WORK; -- 如果发现有异常则执行 ROLLBACK WORK;4.2 权限继承与级联场景的处理刚才提到过如果存在WITH ADMIN OPTION转授关系情况会稍微复杂一些。假设权限链路是这样的DBA - zhangsan带ADMIN OPTION - lisi现在要把zhangsan的EXTEND角色取消lisi该何去何从GBase 8s的处理策略在不同版本下可能有所不同但在大多数支持角色级联权限的版本中回收上游用户的ADMIN OPTION权限时下游用户通过该链路获得的授权也可能被连带回收具体需要查阅当前版本文档确认。为了避免这类不确定性带来的麻烦推荐的做法是在处理级联授权时先建立完整的权限依赖关系清单再动手操作。具体可以按下面的思路展开。先查询所有拥有EXTEND角色的用户以及对应的授权来源SELECT u.username, u.rolename, u.grantor FROM sysuserauths u WHERE u.rolename EXTEND;把查询结果整理成一个清单重点标记grantor字段看每个用户的EXTEND角色是谁给的。接下来根据实际业务需要分两种方式处理。方式一链路整体回收。把链条上所有用户的EXTEND角色全部取消然后从DBA层级重新向下授权。这种方式适合权限整改、安全合规季的场景让权限从头梳理一遍。方式二保留下游用户权限。在取消zhangsan的EXTEND角色之前先用DBA身份直接把EXTEND角色授予lisi确保lisi的权限不因链路断裂而受影响。然后再取消zhangsan的EXTEND角色。方式二的具体操作过程如下-- 以DBA身份先把EXTEND角色直接授予下游用户lisi GRANT EXTEND TO lisi; -- 再取消zhangsan的EXTEND角色 REVOKE EXTEND FROM zhangsan;注意这个顺序不能反。如果先取消了zhangsan的EXTEND角色lisi的EXTEND角色也连带取消掉之后再单独给lisi授权也行但中间会有一个权限空窗期如果系统恰好在这期间有依赖EXTEND角色的任务在运行可能会引发报错。生产环境操作要尽量减少对业务的影响时间窗。还有一点很关键就是在多级转授的场景下DBA - zhangsan - lisi - wangwu如果只处理中间层级链条下层的权限状态往往更难判断。我的建议是涉及三级以上链路的权限操作一定先在测试环境完整演练一遍确认数据库当前版本的级联回收策略再在生产环境执行。不要问我为什么这么强调问就是吃过亏。4.3 使用存储过程封装批量取消角色操作如果一个一个用户手动REVOKE太慢尤其是在季度权限审查时一次要清理几十个账号的场景封装一个存储过程来处理就高效得多。GBase 8s支持存储过程语言SPL即Stored Procedure Language可以写一个批量取消EXTEND角色的存储过程。下面给一个参考实现CREATE PROCEDURE batch_revoke_extend() DEFINE v_username VARCHAR(32); DEFINE v_cnt INT; LET v_cnt 0; FOREACH SELECT username INTO v_username FROM sysuserauths WHERE rolename EXTEND ORDER BY username DO BEGIN -- 跳过DBA账号生产环境要保护超级账号 IF v_username sysdba OR v_username informix THEN CONTINUE FOREACH; END IF; REVOKE EXTEND FROM v_username; LET v_cnt v_cnt 1; END END FOREACH; -- 输出处理结果信息 RAISE EXCEPTION 999, Processed || v_cnt || users; END PROCEDURE;注意上面的存储过程示例是一个演示结构实际的语法细节需要根据你当前数据库版本的SPL规范做适配。比如某些版本对RAISE EXCEPTION的第二个参数类型有要求某些版本要求FOREACH内部不能直接执行DDL语句等等。这个示例的主要价值在于提供实现思路遍历系统表筛选目标用户逐个执行REVOKE。执行批量取消操作时强烈建议先打印结果集确认目标用户列表没有误伤再真正执行。比如可以先写一个只查不删的版本把select结果输出到日志文件里人工确认后再切换到正式执行版本。权限操作最怕的就是全选了然后直接删除或回收风险极大。4.4 取消操作后的业务影响检查REVOKE执行完毕不代表任务结束。取消EXTEND角色之后还要做一轮业务影响检查确认没有造成意外故障。检查的核心思路是找出那些依赖EXTEND角色的业务功能进行针对性验证。那怎么知道哪些功能依赖EXTEND角色呢一个可行的方法是从数据库层面检索看看最近一段时间里哪些对象、哪些存储过程在运行时涉及了EXTEND角色相关的权限需求。如果业务系统本身有完善的权限梳理文档直接参考文档做功能测试就行。下面列一份我常用的检查清单供各位参考目标用户的会话是否还在运行是否占用了EXTEND角色才能访问的资源目标用户对应的应用系统功能模块是否正常是否有定时任务、存储过程调度还在使用目标用户身份执行数据库中是否有触发器、视图依赖了EXTEND角色才能访问的对象审计日志里有没有因为权限不足导致的新的告警信息说个实际案例。之前我处理过一个互联网金融客户的环境用户反馈取消EXTEND角色后某个报表任务突然失败。排查发现那个报表任务使用的数据库账号除了EXTEND角色之外还直接依赖EXTEND角色中打包的一组存储过程的执行权限权限回收之后报表存储过程的EXECUTE权限也一起失效了。这类问题在取消角色操作中最常见因为它属于间接权限依赖单看用户的直接授权记录根本发现不了。我的处理思路是先用DBA身份把报表任务真正需要的存储过程执行权限单独授予对应账号业务恢复后再回过头来审视当初EXTEND角色里是不是打包了太多本不该打包的权限。这就是权限设计上的最小权限原则问题了角色拆得太粗权限一收就容易连带误伤。5. 常见问题与排查技巧实录5.1 报错用户不存在或角色不存在的排查执行REVOKE EXTEND FROM某个用户时如果数据库返回用户不存在或者角色不存在类型的错误通常跑不掉下面这几个原因。第一用户名拼写错误。这个似乎很初级但在实际运维中出现的频率并不低。有些系统里用户名是全大写的有些是区分大小写的GBase 8s默认对标识符的处理在某些场景下会自动转成大写不注意的话容易对不上。解决方法是先从sysusers中把目标用户名原样查出来复制粘贴到REVOKE语句里不要手敲。第二查询系统表时没查到这个角色。这时候先把def_role表里的角色列表打出来看看确认角色真正的名字是不是EXTEND。有些环境里管理员建角色时命名习惯不同可能是EXTEND_ROLE、ROLE_EXTEND之类如果没有精确匹配当然会报不存在。第三误在错误的数据库实例上操作。多实例环境下A实例上创建的用户和角色在B实例上查肯定是不存在的。这个坑在大型企业尤其常见建议在操作前先执行dbaccess连接确认自己在哪个实例上。5.2 REVOKE执行成功但权限仍生效的原因分析有的DBA反馈执行了REVOKE EXTEND FROM user之后发现该用户还能访问EXTEND角色对应的资源看起来权限没有回收干净。这个问题的背后通常隐藏着两类原因。一类原因是用户还拥有其他角色而资源访问权限是通过那个角色获得的。比如用户除了EXTEND角色还有一个名为DEVELOPER的角色DEVELOPER角色里同样包含了对某些扩展模块的访问权限。这时候REVOKE EXTEND只能切断EXTEND角色的权限来源用户通过DEVELOPER角色获得的权限仍然有效。要彻底回收必须把所有涉及权限来源的角色全部处理。另一类原因是用户对某些对象拥有直接授权。用户可以直接被GRANT了某个存储过程的EXECUTE权限也可以被GRANT了某张表的SELECT权限这些直接授权不依赖任何角色取消角色时根本不会动到它们。所以在处理权限没回收干净的问题时不要急着下结论先把用户的权限全景图拉出来看系统里有几个关键视图可以查-- 查看用户的对象权限这里以表权限为例 SELECT tabname, grantor, grantee, tabauth FROM systabauth WHERE grantee zhangsan; -- 查看用户的过程权限 SELECT procname, grantor, grantee, probauth FROM sysprocauth WHERE grantee zhangsan;查询结果出来后逐一核对哪些权限是通过EXTEND角色间接获得的哪些是直接授予的。确认清楚再决定下一步是继续取消其他角色还是单独REVOKE对象权限。5.3 角色取消后无法重新授予的偶发问题这个现象也遇到不少次用户的EXTEND角色取消了过了一阵子业务需要又要重新给这个用户授予EXTEND角色结果执行GRANT EXTEND TO user时数据库报了权限错误。这个问题的根子通常不在当前这个用户身上而在于执行授权操作的这个人当前的权限状态发生了变化。举个例子如果之前是zhangsan通过WITH ADMIN OPTION把EXTEND角色授给lisi的后来zhangsan的EXTEND角色被取消了那zhangsan自然就丧失了继续授权的能力。这时候lisi再想让zhangsan帮忙重新授权肯定授不动。解决办法是找到当前依然具备EXTEND角色管理权限的用户通常是DBA由这个身份来执行重新授权。还有一种隐蔽的情况就是用户虽然被取消了EXTEND角色但是它的操作系统账号在数据库主机上依然保留着相应的sudo或者组权限导致数据库层面权限实际上没有完全失效。这个问题常见于数据库账号和操作系统账号共用一套密码体系的部分内部系统。处理时要统筹考虑数据库安全和系统安全两个层面。5.4 排查技巧速查表为了方便一线运维人员快速定位和解决问题下面整理一份速查表参考价值非常直接。现象可能原因排查重点解决方向REVOKE报用户不存在用户名拼写错误/大小写不一致sysusers表精确查询复制正确用户名后重试REVOKE报角色不存在角色名不同/在错误实例上操作def_role表角色列表确认角色名、确认实例REVOKE成功但权限仍在关联角色未处理/有直接授权用户完整权限全景图取消关联角色或直接REVOKE对象权限重新GRANT失败执行者权限状态变化检查操作人自身角色授权换DBA身份重新授权下游用户权限受影响ADMIN OPTION链路被切断查询grantor链路提前直接授权下游用户报表任务突然失败间接依赖EXTEND角色功能检查存储过程/作业调用链单独授权业务所需执行权5.5 权限操作时的审计与安全建议最后单独讲一下审计意识。GBase 8s的数据库审计功能是生产环境必须开启的取消EXTEND角色这种权限变更操作属于典型的高风险审计事件。在开启数据库审计的情况下REVOKE操作的记录会写入审计日志中包含操作人、操作时间、受影响的对象等关键信息。操作之前建议先确认审计功能是否处于开启状态-- 查看审计配置不同版本的查看方式略有差异 SELECT * FROM sysmaster:sysaudit;如果审计没开建议先在配置层面打开。安全合规讲究的是事前有审批、事中有记录、事后可追溯权限操作如果离开审计出了问题就是一笔糊涂账。我自己在操作生产环境时还有一个习惯执行任何REVOKE或GRANT操作之前先开启一个dbaccess日志记录会话把整个操作过程完整记录下来。具体做法是利用dbaccess的日志回显功能dbaccess -e your_databaseyour_server 21 | tee -a revoke_extend_$(date %Y%m%d).log这样操作结束后日志文件里就有完整的SQL语句和返回结果不管是后续自查还是提交审计材料都非常方便。6. 从EXTEND角色操作延伸到GBase 8s权限管理的通用建议6.1 角色权限规划要遵循最小权限原则取消EXTEND角色这个操作本身不难但真正考验DBA功底的是权限体系的规划。如果权限设计一开始就混乱后面每一次权限调整都会变成拆东墙补西墙。最小权限原则的核心含义是任何用户只拥有完成本职工作所必需的最小权限不多给一点。这个原则在EXTEND角色上的体现就是EXTEND角色里打包的权限应该严格限定在业务需要的范围内不要图省事把一堆扩展权限全塞进去。否则用户投诉我不能访问XX功能还好处理最怕的是权限过大带来的安全风险。实际规划的时候可以参考这个思路先梳理业务功能模块明确每个模块需要哪些数据库操作权限再按照岗位职责把用户分组最后为每组用户设计对应的角色角色的权限粒度要精细到表、视图、存储过程级别。在设计角色时可以遵循以下原则角色命名要语义化能体现用途比如为报表开发人员创建REPORT_DEV角色为数据分析人员创建ANALYST角色。一个角色尽量只服务于一类职责不要搞全能角色。权限变更走审批流程不能因为某个人要求就随手给角色加权限。以EXTEND角色为例如果业务反馈用户需要访问扩展模块与其直接把EXTEND角色授过去不如先细化确认用户真正需要的是模块里的哪几个功能然后把对应功能授权到具体对象上或者拆出更细粒度的子角色。这样做虽然前期麻烦一点但后续每次权限调整都能精准打击不用整天担心误伤。6.2 权限操作的变更管理与回滚方案权限变更和代码发布一样应该有变更管理流程。很多人觉得执行一条SQL而已没有必要搞那么复杂但生产环境的教训告诉我越是看起来简单的操作越要重视变更管理。一次完整的权限变更应该包含以下要素变更申请明确变更目标、变更影响范围、变更执行人。变更评审确认操作方案合理评估业务影响。操作窗口选择业务低峰期执行避开报表生成、定时任务执行等敏感时段。操作执行严格按照方案执行保留操作记录。验证与回滚方案提前写好回滚脚本也就是重新GRANT EXTEND的语句一旦验证发现问题能快速恢复。变更管理这句话似乎有点重但对于权限操作来说回滚方案尤其关键。因为权限回收一旦误操作影响的是实打实的业务访问能力而且在没有事务包裹的场景下执行了就是执行了没有CtrlZ可按。所以把回滚语句准备好是权限操作前的最后一道防线。比如本次取消EXTEND角色的回滚脚本就是下面这一条GRANT EXTEND TO zhangsan;把这条语句提前准备好真出了问题登录上去一条命令就恢复。不要等到出问题了再翻文档写SQL那种情况下的心理压力会让手速变得很慢。6.3 定期巡检与权限收敛权限管理不是一次性工作过了安全审查就万事大吉。用户的权限状态会随着人员流动、业务调整而不断变化定期巡检才能保证权限体系始终处于健康状态。我建议的巡检频率是至少每个季度做一次权限梳理。巡检的核心内容列出所有用户拥有的角色列表找出那些已经不活跃但依然保留权限的账号。列出所有角色包含的权限明细检核是否有权限过大或者权限过时的问题。比对离职员工名单确认离职员工的数据库账号已经被禁用或删除。重点审查带有ADMIN OPTION的授权关系确保没有失控的转授链路。针对EXTEND角色本身的巡检可以重点关注哪些用户拥有EXTEND角色、最近三个月这些用户是否还活跃、EXTEND角色里的权限是否依然匹配当前业务需求。有一个小技巧可以结合GBase 8s的审计日志分析各账号的登录情况和操作行为把那些长期不登录但依然保留权限的账号筛选出来作为权限清理的候选目标。这个办法比单纯看授权表更能反映真实使用情况因为授权表只告诉你有没有审计日志能告诉你用没用。7. 个人实操体会与踩坑经验写到这里关于取消EXTEND角色的操作和技术原理已经讲得比较透亮了。最后说几点我个人在实际操作中沉淀下来的体会。第一权限操作前多问自己一句这个用户被取消EXTEND角色之后他手上的活还干不干得动。看起来是个技术问题实际上是个业务问题。曾经有个客户找我做权限收敛安全团队点名要求取消某个用户的EXTEND角色理由是这个用户离职了。结果一查才发现这个离职用户的数据库账号还在定时跑批任务每天凌晨要给下游系统推送数据。如果当时没有提前查业务关联直接一条REVOKE下去第二天早上数据管道就断了。所以权限操作一定要和业务方确认不能只闷头执行安全指令。第二多实例环境下操作时连接信息一定要写清楚。GBase 8s支持在一个主机上部署多个实例dbaccess连接时如果不显式指定实例可能连到系统默认实例上然后你对着不是目标的那套库执行了REVOKE等于白操作一场。我自己吃过这个亏在测试环境操作时没指定实例REVOKE执行了一堆最后发现操作到了另一个开发实例上还得重新来一遍。第三遇到权限相关报错先冷静下来把SQL语句、用户名、角色名逐一核对不要急着反复试错。反复的试错操作在数据库审计日志里会留下一大堆失败记录本身就不怎么好看。准确、冷静、一次做对才是一个成熟DBA该有的操作风格。第四建议每个DBA都养成维护权限清单的习惯。无论是用Excel还是用GBase 8s的配置管理工具坚持记录每一次GRANT和REVOKE操作。这些记录在平时看着不起眼真到了做半年报安全审计、或者排查历史权限变更原因的时候它们能帮你节约大量时间。有一次我排查一个权限问题追溯到半年前某次GRANT记录才发现某用户在权限变更时被误授予了一个多余角色才导致后面一系列诡异问题。如果没有记录这个case大概率要花一整天才能查清楚。GBase 8s的权限管理是一个体系化的工程取消指定用户的EXTEND角色只是这个体系中一个具体而微的操作节点。把这一步操作搞清楚再去理解角色管理、权限继承、审计追踪的其他环节你会发现整张权限地图都清晰了不少。希望这篇文章能帮你少走一些弯路如果后续在实际操作中遇到其他问题也欢迎在评论区交流讨论。
