SQLSaaS
MySQL 迁移至金仓：权限隔离与数据安全增强
本文分析了 MySQL 权限管理的三大痛点：超级用户权限过大、对象所有权模糊及职责不分离。介绍了电科金仓数据库通过 Schema 级别天然隔离、三权分立安全模型及细粒度权限控制的解决方案。对比了两者在合规性、多租户隔离及隐私保护方面的差异，并提供平滑迁移建议，强调金仓在兼容基础上的安全增强特性，适用于金融、医疗及 SaaS 等对数据安全要求较高的场景。
本文分析了 MySQL 权限管理的三大痛点：超级用户权限过大、对象所有权模糊及职责不分离。介绍了电科金仓数据库通过 Schema 级别天然隔离、三权分立安全模型及细粒度权限控制的解决方案。对比了两者在合规性、多租户隔离及隐私保护方面的差异，并提供平滑迁移建议，强调金仓在兼容基础上的安全增强特性，适用于金融、医疗及 SaaS 等对数据安全要求较高的场景。
在 MySQL 中，拥有 SUPER 权限的用户几乎可以为所欲为：
-- MySQL 中，SUPER 权限用户几乎无所不能
-- 可以查看任何用户创建的表
SELECT * FROM user_a.sensitive_data;
-- 畅通无阻
-- 可以修改任何用户的对象
ALTER TABLE user_b.customer_info ADD COLUMN test VARCHAR(100);
-- 随意修改
-- 可以删除任何用户的数据
DROP TABLE user_c.important_table;
现实问题：
用户 A 创建的表，用户 B（如果权限够）可以直接操作，没有真正的所有权概念：
-- 用户 A 创建了工资表
CREATE TABLE salary ( emp_id INT, salary DECIMAL(10,2));
-- 用户 B（DBA）可以随意查看
SELECT * FROM user_a.salary;
-- 没有任何阻拦
-- 甚至可以修改结构
ALTER TABLE user_a.salary ADD COLUMN bonus DECIMAL(10,2);
现实问题：
系统管理、安全管理、审计管理往往集中在少数几个超级用户手中：
-- 同一个 DBA 账号
-- 既能配置系统参数
ALTER SYSTEM SET max_connections = 1000;
-- 又能分配权限
GRANT ALL ON database.* TO user1;
-- 还能查看和修改审计日志
DELETE FROM mysql.general_log WHERE user='dba';
-- 可以删除自己的操作记录
现实问题：
电科金仓数据库（KingbaseES）不仅高度兼容 MySQL 的语法和功能，更重要的是，它在权限管理上实现了质的飞跃。
在金仓数据库中，每个用户都有自己独立的 Schema 空间：
-- 用户 A 创建自己的敏感数据表
\c - user_a
CREATE TABLE sensitive_data ( id INT, customer_name VARCHAR(100), id_card VARCHAR(18));
-- 用户 B 即使是 DBA，也无法直接访问
\c - user_b
SELECT * FROM user_a.sensitive_data;
-- ERROR: permission denied for schema user_a
-- 除非 user_a 明确授权
\c - user_a
GRANT SELECT ON sensitive_data TO user_b;
解决了什么问题：
金仓数据库实现了真正的职责分离：
-- 系统管理员：负责系统配置，但看不到业务数据
\c - system
ALTER SYSTEM SET shared_buffers = '2GB';
-- 可以 SELECT * FROM business_user.orders;
-- ERROR: 不可以
-- 安全管理员：负责权限分配，但也看不到数据
\c - sso
GRANT SELECT ON business_user.orders TO analyst_user;
-- 可以 SELECT * FROM business_user.orders;
-- ERROR: 不可以
-- 审计管理员：独立记录所有操作
\c - sao
SELECT * FROM audit_log WHERE username = 'business_user';
-- 可以查看审计
-- 但无法修改业务数据，也无法删除审计记录
解决了什么问题：
-- 行级安全策略：同一张表，不同用户看到不同数据
CREATE POLICY sales_policy ON orders FOR SELECT USING(sales_region = current_user_region());
-- 列级权限控制：只能看到部分列
GRANT SELECT(order_id, customer_name, order_date) ON orders TO marketing_user;
-- 敏感的 price 和 discount 列不可见
-- 系统 ANY 权限：批量授权，灵活管理
GRANT SELECT ANY TABLE TO data_analyst;
-- 可以查询所有表，但不能修改
-- 备份权限隔离：备份人员看不到数据
CREATE USER backup_user SYSBACKUP;
-- 可以执行备份，但无法查询数据内容
解决了什么问题：
某城商行使用 MySQL 时，面临监管部门的质疑：
监管人员：'你们的 DBA 可以随意查看客户账户余额和交易记录，这违反了最小权限原则。'
技术负责人：'我们有严格的管理制度…'
监管人员：'制度是人执行的，技术上没有隔离，就存在风险。'
迁移到金仓数据库后：
-- 业务数据库管理员只能管理业务 Schema
\c - business_dba
CREATE TABLE business.transactions(...);
-- 可以 SELECT * FROM risk.blacklist;
-- ERROR: 跨 Schema 访问被拒绝
-- 安全管理员负责权限，但看不到数据
\c - security_admin
GRANT SELECT ON business.transactions TO auditor;
-- 可以 SELECT * FROM business.transactions;
-- ERROR: 不可以
-- 审计管理员独立记录
\c - audit_admin
SELECT * FROM backup_pri.dba_sys_privs;
-- 查看所有权限分配
-- 但无法修改权限，也无法访问业务数据
结果：顺利通过等保三级测评，监管部门给予高度评价。
某 SaaS 服务商为数百家企业提供云服务，最担心的就是数据串户。
使用 MySQL 时的困境：
-- 需要在应用层做大量的租户隔离逻辑
SELECT * FROM orders WHERE tenant_id = ?;
-- 每个查询都要加 tenant_id
-- 一旦疏忽，就可能造成数据泄露
使用金仓数据库后：
-- 为每个租户创建独立 Schema
CREATE SCHEMA tenant_company_a AUTHORIZATION user_a;
CREATE SCHEMA tenant_company_b AUTHORIZATION user_b;
-- 天然隔离，无需应用层额外处理
\c - user_a
SELECT * FROM orders;
-- 自动只能看到自己的数据
SELECT * FROM tenant_company_b.orders;
-- ERROR: 权限不足
技术总监反馈：'以前每次发版都提心吊胆，生怕哪里的 tenant_id 判断漏了。现在有了 Schema 级别的隔离，睡觉都踏实多了。'
某三甲医院的 HIS 系统存储着大量患者隐私数据。
使用金仓的备份恢复权限管理：
-- 启用备份恢复权限功能
ALTER SYSTEM SET backup_pri.enable_backup_pri = on;
CREATE EXTENSION backup_pri;
-- 创建专门的备份用户
CREATE USER backup_user SYSBACKUP;
-- 备份用户只能备份，不能查看数据
\c - backup_user
-- 可以执行物理备份 sys_basebackup -D /backup/path
-- 但不能查看患者数据
SELECT * FROM patient.medical_records;
-- ERROR: 权限不足
-- 查看权限分配情况
SELECT * FROM backup_pri.dba_sys_privs;
信息科主任反馈：'现在我可以自信地对患者说，您的隐私是安全的，不是因为我们的觉悟高，而是因为技术上做到了。'
| 功能维度 | MySQL | 电科金仓 | 实际意义 |
|---|---|---|---|
| Schema 隔离 | 不支持 | 原生支持 | 每个用户有独立空间，天然隔离 |
| 三权分立 | 不支持 | 完整实现 | 系统管理、安全管理、审计管理相互制衡 |
| 行级安全 | 需应用层实现 | 数据库原生支持 | 同一张表不同用户看到不同数据 |
| 列级权限 | 支持 | 支持且更灵活 | 精确控制到每一列 |
| 审计独立性 | DBA 可修改日志 | 审计管理员独立 | 审计记录无法被篡改 |
| 备份权限隔离 | 不支持 | 独立的 SYSBACKUP 权限 | 备份人员无法查看数据 |
| ANY 权限 | 不支持 | 支持 | 灵活的批量授权机制 |
| PUBLIC 角色管理 | 简单 | 精细化管理 | 更好地控制默认权限 |
很多企业担心从 MySQL 迁移会很复杂。实际上：
1. 高度的语法兼容
-- MySQL 的语句在金仓中基本可以直接运行
CREATE TABLE orders ( order_id INT PRIMARY KEY, customer_id INT, order_date DATE);
GRANT SELECT, INSERT ON orders TO user1;
-- 这些语句在金仓中完全兼容
2. 熟悉的管理工具
金仓提供类似 phpMyAdmin 的图形化管理界面，MySQL DBA 可以快速上手。
3. 完善的迁移工具
一键式数据迁移，最小化业务中断时间。
金仓在兼容的基础上，提供了 MySQL 没有的安全增强特性：
-- 金仓特有的 Schema 隔离
CREATE SCHEMA my_business AUTHORIZATION my_user;
-- 金仓特有的三权分立
CREATE USER security_admin WITH CREATEROLE;
CREATE USER audit_admin;
-- 金仓特有的 ANY 权限
GRANT SELECT ANY TABLE TO data_analyst;
-- 金仓特有的备份权限隔离
CREATE USER backup_user SYSBACKUP;
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
在线格式化和美化您的 SQL 查询（它支持各种 SQL 方言）。 在线工具，SQL 美化和格式化在线工具，online
解析 INSERT 等受限 SQL，导出为 CSV、JSON、XML、YAML、HTML 表格（见页内语法说明）。 在线工具，SQL 转 CSV/JSON/XML在线工具，online
CSV 与 JSON/XML/HTML/TSV/SQL 等互转，单页多 Tab。 在线工具，CSV 工具包在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML 转 Markdown 互为补充。 在线工具，Markdown 转 HTML在线工具，online