6.1 认证、角色与权限模型
6.1 认证、角色与权限模型
本节摘要：openGauss 的访问控制是三道闸：认证核验"你是谁"，角色与权限决定"你能做什么"，行级控制进一步约束"你能看哪些行"。多数安全整改的本质，是把"人人在一个角色里"的现状重构为最小权限分层。
场景代入：一次最小权限整改
等保整改通知单上写着："数据库存在应用账号具备管理员权限的情况，不符合最小权限原则，限期整改。"现场一查，应用连接串用的是初始管理员账号——开发期图省事，上线后没人敢动。这不是个例而是常态，它的危险在于：应用一旦被注入，攻击者拿到的就是满权限会话，读写任意表、删库、建账号一气呵成。本节沿着这次整改的全过程展开：怎么盘点现状、怎么分层重构、怎么平滑切换不炸业务。
认证闸：进门的规则
认证解决"你是谁、从哪来"。openGauss 的认证配置由认证文件与主配置共同决定：认证文件按"来源地址、库、用户、认证方式"逐条匹配，主配置控制监听范围与口令策略。交付必查四项：监听地址是否收窄到业务网段（默认全网段监听要改）；认证方式是否强制口令的加密协商（不允许明文传输口令的方式）；口令复杂度与有效期策略是否启用（1.2 节见过，默认开启）；连接数上限是否按业务规划设置。一个容易漏掉的坑：主备两台的认证文件与安全配置必须逐项一致，否则切换后应用连不上备机——5.3 节演练清单里那两处配置漂移，一半发生在这类文件上。
-- 创建分层角色的模板（示意） CREATE ROLE app_rw LOGIN PASSWORD 'App@12345'; -- 应用读写 CREATE ROLE app_ro LOGIN PASSWORD 'Rod@12345'; -- 只读（报表） CREATE ROLE dba_oncall LOGIN PASSWORD 'Onc@12345'; -- 运维值班 -- 授权按四层坐标系逐层给：库、模式、表 GRANT CONNECT ON DATABASE appdb TO app_rw; GRANT USAGE ON SCHEMA business TO app_rw; GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA business TO app_rw; GRANT SELECT ON ALL TABLES IN SCHEMA business TO app_ro; -- 默认权限：让未来新建的表自动带正确权限，避免新表漏授权 ALTER DEFAULT PRIVILEGES IN SCHEMA business GRANT SELECT ON TABLES TO app_ro;
权限闸：分层与默认收口
重构权限模型的五个标准动作。第一，盘点：从连接串与活跃会话反查所有账号在用哪些权限，找出超配的。第二，分层：应用读写、只读分析、运维值班、变更管理四类角色是常见划分，每人一签不共用。第三，收默认：库的公开连接权与模式的公开使用权收回，新建对象不再"天然可见"。第四，配默认权限：上例的 ALTER DEFAULT PRIVILEGES 让新建表自动继承正确授权，堵住"新表上线后报表查不到"这类工单。第五，灰度切换：应用账号替换分两步——先并行开新账号观察一周日志，再回收旧账号权限。整改案例的结局：应用切到 app_rw 后，一次注入尝试的会话因无 DDL 权限被挡在破坏线之前，安全团队第一次把数据库列为"有效防线"而不是"薄弱环节"。
图：三道访问控制闸门与权限分层
行级控制：同一张表，各看各的
当业务要求"分公司只看本分公司数据"时，传统做法是在每条查询里拼条件，漏拼一次就是越权事故。行级控制把这个条件下沉到内核：为表定义行级策略，策略按当前会话身份自动过滤，任何查询都不必（也不能）绕过。适用判断：数据按组织或租户天然分片、查询入口多且难以逐一收口时，值得上；如果只有一两个入口且代码可控，应用层过滤更简单。代价要如实告知业务：策略表达式在每行可见性判断时求值，复杂策略有可观测的扫描开销——这与第 3 章 MVCC 的可见性机制在同一条路径上，策略表达式越贵，扫描越慢。上线节奏：先在报表类低频接口试运行，观察执行计划变化，再逐步铺开到交易链路。
账号治理的常态化机制
权限重构是一次性工程，账号治理是常态化纪律，后者决定前者能维持多久。四项机制让治理不靠人自觉。定期盘点：每季度导出账号清单与权限矩阵，标记三个月未登录的休眠账号、权限超出岗位说明的账号，逐个处置——休眠账号是最常被忽视的攻击面。生命周期挂钩：人员入职离职与账号建立回收联动，离职当天账号禁用，交接期内用只读影子账号过渡。审批留痕：权限变更走工单，变更原因与审批人入档，测评时这就是"权限最小化有制度"的直接证据。敏感操作二次确认：变更管理类账号的 DDL 操作要求双人复核，高危语句在窗口期内执行。四项机制落地的团队，测评时的账号治理环节基本是走过场——评委翻着工单记录和季度盘点表，没什么可挑的。
行级控制的一个完整配置示例
行级控制值得看一个能跑的最小示例来建立手感。场景：订单表按大区隔离，华东账号只见华东订单。
-- 建立区域账号 CREATE USER east_mgr PASSWORD 'East@12345'; CREATE USER north_mgr PASSWORD 'North@12345'; -- 在订单表上定义行级策略：按会话用户名过滤大区 ALTER TABLE orders ENABLE ROW LEVEL SECURITY; CREATE ROW LEVEL SECURITY POLICY orders_region ON orders USING (region = CASE current_user WHEN 'east_mgr' THEN 'east' WHEN 'north_mgr' THEN 'north' ELSE region END); -- 验证：east_mgr 连接后查询，结果只含华东大区 SELECT count(*) FROM orders WHERE region = 'north'; -- east_mgr 看到的计数为 0
两个部署提醒：策略表达式里的分支不要过长，身份到区域的映射放系统表维护比硬编码在表达式里好维护；上线前用执行计划对比策略启用前后的扫描代价，确认衰减在可接受范围。这个示例可以直接搬进测试环境练手，五分钟建立对行级控制的具象认知。
现场问答三则
问答一："应用连接串里换了新账号，为什么有的接口还能跑有的报权限错误？"——新账号的授权漏了某个模式的默认权限，老账号权限是历史累积的"大而全"，切换必然暴露差异；用 6.1 的默认权限语句补齐再切换。问答二："给报表团队开个只读账号，是不是就安全了？"——只读挡住的是写破坏，挡不住大量数据被读走；报表账号还要叠加导出审计与行级或列级的敏感数据脱敏。问答三："密码有效期设多久合适？"——按行业合规下限执行即可，过短的强制改期反而催生"密码尾号递增"这类形式化合规；配套禁止最近口令重用与复杂度校验比单纯缩短周期更有效。三则问答都是权限整改现场的真实高频题，答案口径建议直接进运维手册。
权限矩阵模板：一页纸管清权限
把权限体系落成一页矩阵，评审与审计都靠它。矩阵的行是四类角色（应用读写、只读分析、运维值班、变更管理），列是四层对象（库、模式、表、列），格子里填权限动作。填完先做第一遍自检：有没有任何角色拥有跨层的多余权限——运维值班若带了 DDL，就要说明理由或剥离。第二遍对检：拿活跃账号的实际权限和矩阵对比，矩阵外的权限要么收权、要么修订矩阵——两者必须一致，不一致的矩阵比没有矩阵更危险，因为它制造"已有治理"的假象。矩阵定稿后挂进运维手册，每次权限变更同步修订并留版本号。测评现场的"权限最小化"检查，评委要的往往就是这份矩阵加一份最近的变更记录——一页纸的功夫，换来的是安全治理从口头到书面的跃迁。
认证配置的一致性校验
主备或集群环境下，认证配置的一致性值得一个专门的校验脚本：对齐比对各节点的认证文件条目数与内容摘要、口令策略参数、连接数上限、加密协商设置——任何一个差异都输出告警。脚本挂在两个时机执行：变更窗口之后（核对本次变更是否在所有节点同步落地）、切换演练之前（确认演练环境与生产同构）。它防的是最阴险的一类故障：配置差异平时无感，切换瞬间爆发——备机接管后应用连不上，故障从"主机坏了"升级成"切换失败"。这类校验脚本写起来不到五十行，防住的是最贵的那类事故。
本节要点回顾
- 三道闸门：认证管身份来源，权限管操作边界，行级管数据可见范围；
- 主备安全配置必须一致：认证文件与安全参数逐项对齐，纳入切换演练清单；
- 重构五动作：盘点、分层、收默认、配默认权限、灰度切换；
- 一人一签：角色不共用是账号审计的前提，共用账号在测评里必提整改；
- 行级控制有代价：策略表达式走可见性判断路径，先低频试运行再铺开。
门看住了、边界画清了，数据本身的防窃取与行为留痕是下一节的主题。