数据库安全合规方案：等保三级/加密/审计/访问控制完整设计

摘要

数据安全合规是企业数字化转型的底线要求。在《数据安全法》《个人信息保护法》等法规驱动下，数据库安全已从可选项变为必选项。本文以 TiDB 为基础，系统设计覆盖传输加密（TLS）、存储加密（TDE）、基于角色的访问控制（RBAC）、全量审计追踪的数据库安全合规方案，并针对等保三级（信息系统安全等级保护三级）要求提供完整合规落地方案。

本文适合谁：负责数据库安全的 CISO/安全工程师/DBA 及合规负责人。

一、安全合规框架

1.1 合规驱动与法规要求

1.2 数据库安全分层模型

┌──────────────────────────────────────────┐
│              应用层安全                    │  OAuth2.0 / API Gateway / WAF
├──────────────────────────────────────────┤
│              网络层安全                    │  VPC / 安全组 / TLS / mTLS
├──────────────────────────────────────────┤
│              数据库层安全                   │  RBAC / TDE / 审计 / 脱敏
├──────────────────────────────────────────┤
│              数据层安全                    │  分类分级 / 加密 / 销毁 / 备份
├──────────────────────────────────────────┤
│              运维层安全                    │  操作审计 / 变更审批 / 自动化运维
└──────────────────────────────────────────┘

二、TiDB 安全特性总览

2.1 内置安全能力

三、等保三级合规设计

3.1 等保三级数据库控制点映射

3.2 身份鉴别配置

-- 创建用户并设置密码策略
CREATE USER 'app_user'@'10.0.0.%' IDENTIFIED BY 'Str0ng!Pass#2024';

-- 密码过期策略
ALTER USER 'app_user'@'10.0.0.%' PASSWORD EXPIRE INTERVAL 90 DAY;

-- 登录失败锁定
SET GLOBAL tidb_max_failed_login_attempts = 5;
SET GLOBAL tidb_failed_login_lockout_time = 1800;

-- 连接数限制
ALTER USER 'app_user'@'10.0.0.%' WITH MAX_CONNECTIONS_PER_HOUR 1000;

3.3 RBAC 访问控制

-- 创建角色并授权（最小权限原则）
CREATE ROLE 'app_readonly';
CREATE ROLE 'app_readwrite';
CREATE ROLE 'app_admin';
CREATE ROLE 'audit_viewer';

-- 只读角色：仅允许 SELECT
GRANT SELECT ON app_db.* TO 'app_readonly';

-- 读写角色：允许 SELECT/INSERT/UPDATE
GRANT SELECT, INSERT, UPDATE ON app_db.* TO 'app_readwrite';

-- 管理员角色：包含 DDL 权限
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX
    ON app_db.* TO 'app_admin';

-- 审计查看角色
GRANT SELECT ON mysql.* TO 'audit_viewer';

-- 将角色分配给用户
GRANT 'app_readonly' TO 'analyst'@'10.0.0.%';
GRANT 'app_readwrite' TO 'app_service'@'10.0.0.%';

-- 激活角色
SET DEFAULT ROLE ALL TO 'analyst'@'10.0.0.%';

权限矩阵：

四、数据加密方案

4.1 传输加密（TLS）

# TiDB Server TLS 配置（tidb-server.yaml）
security:
  ssl-ca: /etc/tidb/ssl/ca.pem
  ssl-cert: /etc/tidb/ssl/server-cert.pem
  ssl-key: /etc/tidb/ssl/server-key.pem

# 要求客户端证书（mTLS 双向认证）
require-secure-transport: true

# 客户端通过 TLS 连接
mysql -u app_user -p -h tidb-server --ssl-ca=/etc/tidb/ssl/ca.pem \
     --ssl-cert=/etc/tidb/ssl/client-cert.pem \
     --ssl-key=/etc/tidb/ssl/client-key.pem

# 验证 TLS 连接
mysql> SHOW VARIABLES LIKE '%ssl%';
+---------------------+------------------------------+
| Variable_name       | Value                        |
+---------------------+------------------------------+
| have_ssl            | YES                          |
| ssl_ca              | /etc/tidb/ssl/ca.pem         |
| require_secure_transport | ON                        |
+---------------------+------------------------------+

4.2 存储加密（TDE）

TiDB 支持透明数据加密（TDE），加密过程对应用完全透明：

# TiKV TDE 配置（tikv.toml）
[security]
[security.encryption]
data-encryption-method = "aes128-ctr"
[security.encryption.master-key]
type = "kms"
kms-region = "cn-north-1"
kms-endpoint = "https://kms.cn-north-1.amazonaws.com"
kms-key-id = "arn:aws:kms:cn-north-1:xxx:key/xxx"

4.3 敏感数据脱敏

-- 方案一：通过视图脱敏
CREATE VIEW user_profile_safe AS
SELECT
    user_id,
    CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4)) AS phone_masked,
    CONCAT(LEFT(id_card, 4), '********', RIGHT(id_card, 4)) AS id_card_masked,
    SHA2(real_name, 256) AS name_hash
FROM user_profile;

-- 方案二：应用层动态脱敏（推荐框架集成）
-- 在应用层通过 MyBatis 拦截器或 ORM 插件实现
-- 脱敏规则：
--   - 手机号：中间4位替换为 ****
--   - 身份证：保留前4后4位
--   - 银行卡：保留前4后4位
--   - 姓名：仅保留姓，名替换为 *

五、审计追踪

5.1 TiDB Audit Log 配置

# TiDB 审计日志配置
[audit-log]
enable = true
# 审计事件类型
  # ALL：记录所有事件
  # DML：记录数据操作
  # DDL：记录结构操作
  # GENERAL：记录常规查询
record-general-queries = true

# 审计输出方式
[audit-log]
# 输出到文件
file-path = "/var/log/tidb/audit.log"
max-file-size = 1024  # MB
max-log-days = 180     # 保留6个月（等保三级要求）

5.2 审计数据流转

TiDB Audit Log → Filebeat → Kafka → Logstash → Elasticsearch
                                               ↓
                                         Kibana 审计仪表盘
                                               ↓
                                         告警规则（异常操作检测）

5.3 审计分析规则

# 审计告警规则
audit_alerts:
  - name: "批量数据导出"
    condition: "SELECT COUNT(*) > 10000 AND audit_user NOT IN ('etl_user', 'report_user')"
    severity: "warning"
    action: "通知安全团队"

  - name: "非授权 DDL 操作"
    condition: "audit_event IN ('DROP', 'TRUNCATE', 'ALTER') AND audit_user NOT IN ('db_admin')"
    severity: "critical"
    action: "立即通知安全负责人并记录工单"

  - name: "异常登录"
    condition: "audit_event = 'FAILED_LOGIN' AND count > 5 within 10min"
    severity: "critical"
    action: "触发账户锁定，通知安全管理员"

  - name: "敏感数据访问"
    condition: "table_name IN ('user_profile', 'payment_info') AND audit_user NOT IN ('app_service')"
    severity: "warning"
    action: "记录审计日志并通知数据安全负责人"

5.4 审计日志格式

TiDB 审计日志结构化输出，包含以下字段：

六、等保三级落地检查清单

6.1 检查项

七、FAQ

Q1：TiDB TDE 对性能有多大影响？

实测数据显示，TiDB TDE（AES-128-CTR）对写入性能的影响约 3-5%，对读取性能的影响小于 2%。主要开销来自加密引擎的初始化与密钥轮换，正常读写场景下几乎无感知。建议在 POC 阶段用实际负载验证。

Q2：审计日志会占用多少存储空间？

审计日志大小取决于业务 QPS 和 SQL 长度。以中等规模（5000 QPS，平均 SQL 200 字节）估算，日均审计日志约 80-100GB，6 个月约 15-18TB。建议使用 Elasticsearch 集群存储，配合冷热数据分层降低成本。

Q3：等保三级认证需要 TiDB 单独过检吗？

等保三级认证以"信息系统"为单位，而非单个组件。TiDB 作为数据库组件需满足等保三级中关于数据库安全的控制项要求。建议在等保测评前，按照本文检查清单逐项验证，确保 TiDB 配置符合要求。

Q4：如何实现密钥的自动轮换？

TiDB TDE 支持 KMS 外部密钥管理。通过云厂商 KMS（如阿里云 KMS、AWS KMS）可实现：1) 密钥自动轮换（通常每年一次）；2) 密钥权限分离（数据库加密使用密钥，但无法导出密钥明文）；3) 密钥使用审计。

八、总结

数据库安全合规需要从身份鉴别、访问控制、传输加密、存储加密、审计追踪五个维度系统建设。TiDB 提供了满足等保三级要求的内置安全能力，关键落地要点：

• TLS 强制加密：所有客户端连接启用 TLS 1.2+，敏感场景使用 mTLS
• RBAC 最小权限：按角色分离权限，避免超级用户滥用
• TDE 存储加密：敏感数据加密存储，密钥由 KMS 外部管理
• 全量审计追踪：SQL 级审计日志保留 6 个月以上，支持异常检测告警

九、下一步行动

1. 获取 TiDB 安全合规白皮书：下载完整的安全架构设计与等保三级落地方案 → 安全合规则解决方案
2. 咨询 TiDB 安全团队：获取针对您行业的安全合规定制建议 → 联系 PingCAP
3. 试用 TiDB Cloud 安全功能：体验 TLS/TDE/Audit 等安全特性 → TiDB Cloud 免费试用
4. 阅读 TiDB 安全管理文档：获取详细的安全配置指南 → TiDB 文档概览

相关资源

• TiDB 安全管理文档
• TiDB TLS 配置指南
• TiDB RBAC 权限管理
• TiDB Audit Log 文档
• TiDB Cloud 安全特性
• PingCAP 安全合规白皮书