暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

PolarDB-X 企业级特性之三权分立

小希 2024-02-27
153
背景

看到以上的场景,可能不少 DBA 都会感同身受;同时,老板还可能会担心 DBA 的人品,就比如去年才发生了某科技公司删库导致业务瘫痪的事件。当然现在连很多小公司或开发团队也懂得象征性地设置一些数据库账号权限(不少时候可能会为了便捷而混用权限账号),但如果对于已经初具规模的企业来说的话,即使已经严格划分为有 SUPERUSER 权限的 DBA 账号和按需授权的开发账号,老板仍会担心 DBA 有权限访问业务敏感数据、或者授权给不明身份人士、甚至可以通过审计日志看到不同业务部门对数据库的操作,总之“只手遮天”的 DBA 仿佛就是把握了企业数据的命脉。

针对以上问题,PolarDB-X 新增支持三权分立模式,打破了传统数据库运维由 DBA 行使特权的独立控制体系,使得数据库管理员 DBA、安全管理员 DSA 和审计管理员 DAA 三者的权责更加清晰。其中:

数据库管理员(DBA, Database Administrator):只具备 DDL 权限
安全管理员(DSA,Department Security Administrator):只具备管理角色(Role)或用户(User)以及为其他账号授予权限的权限
审计管理员(DAA,Data Audit Administrator):只具备查看审计日志的权限

该功能特性强调的是通过访问层次上的控制体系,来从数据库层面降低安全风险。

原理简介

以 Oracle 这一款王者级别的数据库管理系统为例,其从 Oracle 10g 开始推出了 Database Vault [2]这一运维安全体系框架。在这套框架内,其定义了数据库中以下三种核心职责:

账号管理:包括创建、修改、删除用户账号
安全管理:设置账户对数据库的访问权限,授权用户对数据库表上可执行的操作
资源管理:管理数据库系统的资源,但无权访问业务数据,比如进行定期备份、性能监控与调优等操作

可以看出,其核心思想是将原来单一的数据库管理员超级权限进行拆分。在此基础上,PolarDB-X 的三权分立管理模式则结合了分布式数据库的特点,将权限信息保存在独立的 GMS 元数据中心,并且权限职责划分得更加清晰明确,下表展示了三权分立与默认模式的权限区别:
权限
默认模式
三权分立-DBA
三权分立-DSA
三权分立-DAA
DML
✔️



DQL
✔️



DAL
✔️



DDL
✔️
✔️


账号角色管理
✔️

✔️

审计日志
✔️


✔️

其中,具体的权限分类如下所示:

DML 包括 INSERT、UPDATE、DELETE语句权限
DQL 包括 SELECT语句权限
DAL 包括 EXPLAIN、SHOW、sql限流等语句权限
DDL 包括 CREATE TABLE / VIEW / INDEX、DROP TABLE / VIEW / INDEX等语句权限
账号角色管理包括 CREATE USER / ROLE、GRANT、REVOKE 等语句权限
审计日志则包括对 information_schema 下 polardbx_audit_log 系统表的访问权限

功能场景展示

功能开启 开启三权分立模式均为白屏化操作

1 在 PolarDB-X 控制台开启三权分立:

2 依次创建安全管理员账号和审计管理员账号:


3. 创建成功后可以看到三个管理员账号:


下面将将结合具体的场景、以上述三个类型管理员的身份来演示不同类型的SQL操作,并展示三权分立支持的核心功能,其中三类管理员的账号名分别如下所示:

系统管理员:admin_dba
安全管理员:admin_security
审计管理员:admin_audit

场景一 隔离敏感数据



场景二 隔离权限授予



场景三 隔离sql日志


SQL
复制代码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
-- 登录admin_audit
mysql> select USER();
+-----------------------------+
| USER() |
+-----------------------------+
| admin_audit@100.120.138.141 |
+-----------------------------+
1 row in set (0.00 sec)

mysql> use information_schema;
Database changed
mysql> select USER_NAME,HOST,PORT,AUDIT_INFO,ACTION,TRACE_ID from polardbx_audit_log where SCHEMA = 'tmall';
+----------------+-----------------+------+--------------------------------------------------------------------+-------------+------------------+
| USER_NAME | HOST | PORT | AUDIT_INFO | ACTION | TRACE_ID |
+----------------+-----------------+------+--------------------------------------------------------------------+-------------+------------------+
| admin_security | 100.120.137.141 | 9635 | CREATE USER 'tmall_dev'@'192.168.0.%' IDENTIFIED BY 'polarX123456' | CREATE_USER | 13aaef15fd004000 |
| admin_security | 100.120.137.141 | 9635 | grant select,insert,update on tmall.* to 'tmall_dev'@'192.168.0.%' | GRANT | 13aaef5d78804000 |
+----------------+-----------------+------+--------------------------------------------------------------------+-------------+------------------+
2 rows in set (0.01 sec)

关于详细使用方法与实践可参考官方文档

总结

回过头来看,三权分立是不是能彻底解决在开篇背景中提到的删库跑路的问题呢?事实上,看完这篇文章,你会知道并不能;如果想知道如何避免删库等操作带来的风险,可以参考系列文章《PolarDB-X 如何拯救误删数据的你》。

那么三权分立究竟带来了什么呢?三权分立本质就是权力的分散,而这并不意味着会导致效率的低下;相反实行分责制度,避免一些误操作的风险,还可以有效降低敏感数据泄露的风险。

笔者相信,在数据保护越来越严格、企业操作规范越来越健全的如今,三权分立模式将为需要管理大规模数据库的企业降低运维风险、提供敏感数据访问保护,从而企业不仅能够同时减少来自内、外部的威胁,还能满足相应的合规需求。
参考

1https://docs.oracle.com/en/database/oracle/oracle-database/21/dvadm/oracle-database-vault-schemas-roles-and-accounts.html#GUID-4E1707B4-F9BB-4131-9D3E-90BB273F2832
2https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html

若有收获,就点个赞吧


「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论