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

摘要

数据库安全不是打开几个配置项就能完成的工作。一个可落地的安全方案，通常需要同时覆盖身份鉴别、最小权限、通信加密、静态数据加密、备份保护、审计留痕、异常告警和恢复演练。

本文以 TiDB 为基础，介绍这些控制措施的正确实现方式，并特别说明 TiDB 与 MySQL 在密码策略、账户锁定、连接限制、数据加密和审计配置方面的差异，避免直接照搬 MySQL 参数导致配置无效。

本文适合数据库管理员、安全工程师、架构师及合规负责人参考。

一、先明确能力边界

在设计方案前，需要先确认使用的 TiDB 版本和产品形态。不能把 TiDB Self-Managed、平凯数据库企业版和 TiDB Cloud 的能力混写在一起。

因此，本文所有配置都应先在与生产环境相同的版本中验证，再进入正式变更流程。

二、安全建设总体架构

建议将数据库安全划分为以下几个层面：

TiDB 能够提供其中一部分数据库能力，但防火墙、网络隔离、堡垒机、密钥管理平台、日志平台和安全运营流程仍需要在数据库之外建设。

三、身份鉴别与账户安全

3.1 启用密码复杂度策略

TiDB 的密码复杂度检查默认关闭。可以使用以下配置启用一个中等强度的全局密码策略：

SET GLOBAL validate_password.enable = ON;
SET GLOBAL validate_password.policy = 'MEDIUM';
SET GLOBAL validate_password.length = 12;
SET GLOBAL validate_password.mixed_case_count = 1;
SET GLOBAL validate_password.number_count = 1;
SET GLOBAL validate_password.special_char_count = 1;

上述策略要求新设置的密码至少 12 位，并包含大写字母、小写字母、数字和特殊字符。

密码复杂度策略只在创建或修改密码时检查，不会自动把已有弱密码变成强密码。启用后，应配合账户梳理和密码轮换计划逐步处理存量账户。

3.2 创建业务账户

业务账户应限制来源地址，并要求使用 TLS 连接：

CREATE USER 'app_user'@'10.0.0.%'
  IDENTIFIED BY '<由密码管理系统生成的随机密码>'
  REQUIRE SSL;

不建议在文档、工单或脚本中长期保存真实密码。生产密码应由密码管理系统生成和保管。

3.3 设置密码有效期

ALTER USER 'app_user'@'10.0.0.%'
  PASSWORD EXPIRE INTERVAL 90 DAY;

是否采用 90 天轮换，应结合组织制度、账户类型和应用改密能力确定。对于无法自动轮换密码的服务账户，还需要提前设计双账户切换或密钥托管流程，避免改密导致业务中断。

3.4 设置连续登录失败锁定

TiDB 的连续登录失败策略只支持账户级配置，不支持全局统一配置：

ALTER USER 'app_user'@'10.0.0.%'
  FAILED_LOGIN_ATTEMPTS 5
  PASSWORD_LOCK_TIME 1;

这表示该账户连续输入错误密码 5 次后锁定 1 天。

需要特别注意：

• PASSWORD_LOCK_TIME 的单位是天，不是秒或分钟。
• FAILED_LOGIN_ATTEMPTS 和 PASSWORD_LOCK_TIME 必须同时设置为非零值，策略才会生效。
• TiDB 不支持用一个全局变量把该策略自动应用到所有账户，需要逐账户配置。
• 如果安全制度要求“失败 5 次后锁定 30 分钟”，需要通过统一认证平台、数据库访问代理或其他外部安全控制实现，不能写成 TiDB 原生能力。

账户解锁命令如下：

ALTER USER 'app_user'@'10.0.0.%' ACCOUNT UNLOCK;

3.5 限制并发连接数

当前版本可以通过 MAX_USER_CONNECTIONS 限制账户同时建立的连接数：

ALTER USER 'app_user'@'10.0.0.%'
  WITH MAX_USER_CONNECTIONS 100;

该配置限制的是并发连接数，不是 MySQL 中的“每小时连接次数”。不要使用 MAX_CONNECTIONS_PER_HOUR 代替。

3.6 检查账户配置

SHOW CREATE USER 'app_user'@'10.0.0.%';
SHOW VARIABLES LIKE 'validate_password%';

生产环境还应定期检查：

• 是否存在空密码、弱密码或长期未使用账户；
• 是否仍有应用使用高权限账户；
• 是否存在来源地址为 % 且没有必要的账户；
• 离职或项目下线后，相关账户是否及时停用；
• 自动化程序是否仍在使用个人账户连接数据库。

四、基于角色的访问控制

4.1 按职责创建角色

CREATE ROLE 'app_readonly';
CREATE ROLE 'app_readwrite';
CREATE ROLE 'app_admin';

GRANT SELECT
  ON app_db.* TO 'app_readonly';

GRANT SELECT, INSERT, UPDATE
  ON app_db.* TO 'app_readwrite';

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX
  ON app_db.* TO 'app_admin';

建议的权限关系如下：

DROP 等高风险权限不应默认授予业务管理员。确需使用时，建议通过临时授权和变更审批完成。

4.2 把角色授予用户

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.%';

SET DEFAULT ROLE ALL
  TO 'app_service'@'10.0.0.%';

检查用户最终权限：

SHOW GRANTS FOR 'analyst'@'10.0.0.%';
SHOW GRANTS FOR 'app_service'@'10.0.0.%';

4.3 使用视图保护敏感字段

TiDB Self-Managed 不支持原生列级权限。对于手机号、证件号等字段，可以通过脱敏视图向受限用户提供数据：

CREATE VIEW app_db.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 app_db.user_profile;

GRANT SELECT
  ON app_db.user_profile_safe TO 'app_readonly';

REVOKE SELECT
  ON app_db.user_profile FROM 'app_readonly';

这里实现的是基于视图的脱敏，不是数据库原生动态脱敏。关键控制点是：受限角色只能访问脱敏视图，不能同时拥有基表查询权限，否则可以绕过脱敏。

对于复杂的按用户、部门或业务场景动态展示规则，建议在应用服务或专门的数据安全平台中实现。

五、传输加密

5.1 配置客户端与 TiDB 之间的 TLS

在 TiDB 配置文件 tidb.toml 中配置服务端证书：

[security]
ssl-ca = "/etc/tidb/ssl/ca.pem"
ssl-cert = "/etc/tidb/ssl/server-cert.pem"
ssl-key = "/etc/tidb/ssl/server-key.pem"
tls-version = "TLSv1.2"

tls-version = "TLSv1.2" 表示最低使用 TLS 1.2。证书和私钥配置完成后，还需要确认所有 TiDB 节点都能读取相关文件，并建立证书到期监控。

对于未启用安全增强模式的集群，可以在已使用 TLS 的管理会话中执行：

SET GLOBAL require_secure_transport = ON;

这会要求 TCP 客户端使用 TLS。开启安全增强模式的集群，应根据对应版本文档选择账户级 REQUIRE SSL 或证书鉴权方案，不要直接套用该变量。

5.2 配置双向证书认证

仅配置 CA 并不代表所有客户端都必须提供证书。如果需要双向认证，应对相应账户配置：

ALTER USER 'app_user'@'10.0.0.%' REQUIRE X509;

这时客户端除了校验服务端证书，还必须向 TiDB 提供由受信任 CA 签发的客户端证书。

5.3 客户端安全连接示例

mysql -h tidb.example.com -P 4000 -u app_user -p \
  --ssl-mode=VERIFY_IDENTITY \
  --ssl-ca=/etc/tidb/ssl/ca.pem

如果账户要求 X509，客户端还需要提供：

  --ssl-cert=/etc/tidb/ssl/client-cert.pem \
  --ssl-key=/etc/tidb/ssl/client-key.pem

登录后使用以下命令检查当前连接是否真正启用了 TLS：

SHOW STATUS LIKE 'Ssl%';

应确认 Ssl_cipher 和 Ssl_version 等字段存在有效值。

5.4 配置组件间 TLS

客户端到 TiDB 的 TLS，不会自动保护 TiDB、PD、TiKV、TiFlash、TiCDC 等组件之间的通信。组件间 TLS 需要按照官方文档分别配置证书，并在部署前验证所有组件和运维工具的连接方式。

在完整的安全方案中，这两类 TLS 都需要覆盖：

1. 应用、运维客户端与 TiDB Server 之间的连接；
2. TiDB 集群内部各组件之间的连接。

六、静态数据加密

6.1 配置 TiKV 静态加密

下面以 KMS 管理主密钥为例：

[security.encryption]
data-encryption-method = "aes256-ctr"
data-key-rotation-period = "168h"

[security.encryption.master-key]
type = "kms"
key-id = "<kms-key-id>"
region = "<region>"
endpoint = "<optional-kms-endpoint>"

其中：

• 主密钥由外部 KMS 管理，用于保护 TiKV 生成的数据密钥；
• 数据密钥由 TiKV 使用，并按照配置周期轮换；
• endpoint 通常是可选项，使用兼容 KMS、专用网络端点等场景时再配置；
• 实际参数应根据 AWS、Google Cloud、Azure 或所使用的兼容服务调整。

TiKV 静态加密覆盖的不只是 SST，还包括 WAL、MANIFEST 和相关临时文件。

6.2 静态加密不是按表启用

TiKV 静态加密是组件级能力，不能只对某几张“敏感表”开启。检查清单应写成“确认承载用户数据的 TiKV、TiFlash 等组件已正确启用静态加密”，而不是“检查敏感表是否开启 TDE”。

对于已经运行的集群，启用加密后只保证新写入的文件被加密，原有文件会随着后台 compaction 逐步重写。因此，变更完成后还要制定验证和观察计划，不能只检查配置文件。

6.3 补齐其他数据副本

完整的静态数据保护还需要检查：

静态加密不能代替访问控制。拥有合法数据库高权限的用户仍可能通过 SQL 读取明文数据，因此必须与 RBAC、审计和运维审批配合使用。

6.4 加密 BR 快照备份

tiup br backup full \
  --pd <pd-address> \
  --storage <backup-storage> \
  --crypter.method aes256-ctr \
  --crypter.key-file /secure/path/br.key

备份密钥应与备份数据分开保存，并纳入密钥备份、权限控制和轮换制度。密钥丢失后，加密备份将无法恢复。

仅完成“备份成功”还不够，必须定期进行恢复演练，并验证恢复环境能够正确取得解密密钥。

七、数据库审计

7.1 先确认产品是否支持

数据库审计不能笼统描述成所有 TiDB 版本都自带的能力：

• 使用平凯数据库企业版时，应按照企业版审计功能文档配置；
• 使用 TiDB Cloud 时，应确认当前套餐、集群版本和云平台是否支持数据库审计；
• 如果当前产品不支持合规所需的数据库审计，需要使用数据库访问代理、专业数据库审计产品或其他经过评估的外部方案补齐；
• 普通日志或慢查询日志不能直接等同于完整的数据库审计日志。

7.2 平凯数据库企业版审计配置示例

SET GLOBAL tidb_audit_enabled = ON;
SET GLOBAL tidb_audit_log = '/var/log/tidb/tidb-audit-%e.log';
SET GLOBAL tidb_audit_log_format = 'JSON';
SET GLOBAL tidb_audit_log_max_filesize = 1024;
SET GLOBAL tidb_audit_log_reserved_days = 180;
SET GLOBAL tidb_audit_log_redacted = ON;

启用审计功能后，还需要配置过滤器和过滤规则。以下示例记录所有用户的连接、查询和审计配置事件：

SELECT audit_log_create_filter('all_events', '{}');
SELECT audit_log_create_rule('%@%', 'all_events');

全量审计可能带来性能和存储开销。生产环境应先进行容量评估和压力测试，再决定记录全部事件，还是按账户、事件类型和敏感对象配置过滤规则。

7.3 审计日志应记录的主要信息

审计记录通常需要覆盖：

• 事件类型；
• 用户与当前角色；
• 连接标识；
• 客户端 IP 和端口；
• 涉及的数据库和表；
• SQL 文本或脱敏后的 SQL 文本；
• 执行结果和错误原因；
• 受影响行数；
• 审计配置自身的启停和修改操作。

具体字段应以目标版本的官方审计文档为准，不应自行假定字段名。

7.4 审计日志集中管理

推荐的数据流转方式如下：

TiDB 审计日志
    ↓
日志采集组件
    ↓
集中日志或安全分析平台
    ↓
告警、检索、报表、留存与取证

集中平台应具备：

• 审计日志传输加密；
• 严格的查看和删除权限；
• 防篡改或受控删除能力；
• 统一时间同步；
• 存储容量与保留期限监控；
• 审计采集中断、日志写入失败等异常告警。

7.5 建议的审计告警场景

告警平台可以通知安全人员，但不要把“告警后自动锁定账户”描述成 TiDB 审计功能自带的能力。是否进行自动处置，应结合误报风险、业务连续性和审批机制单独设计。

7.6 审计容量估算

审计存储不能只按 SQL 文本长度估算。建议使用下面的方式：

每日原始容量
= 实际平均审计记录大小
× 每秒被审计事件数
× 86400

在此基础上，还要考虑日志平台的索引开销、副本数、压缩率、增长余量和保留期限。最终数据应来自与生产负载相近的实际测试，而不是使用一个固定的通用数值。

八、网络与运行环境保护

数据库安全不能只依赖数据库账户。建议同时落实以下措施：

1. TiDB 客户端端口仅向应用网段、运维网段或数据库代理开放；
2. PD、TiKV、TiFlash 和管理接口不直接暴露给业务网或公网；
3. 运维访问经过堡垒机、统一身份认证和审批；
4. 生产环境禁止共用个人账户，禁止多人共享同一高权限密码；
5. 高权限操作通过受控管理入口执行；
6. 证书、KMS、备份存储和日志平台分别实施最小权限；
7. 定期扫描过期证书、开放端口、弱口令和过度授权；
8. 对 TiDB Dashboard、Grafana 和操作系统账户同样实施身份鉴别和访问控制。

慢查询监控属于性能管理手段，不能单独作为“入侵防范”措施。异常访问检测应主要依靠连接审计、网络安全设备和安全分析平台。

九、备份恢复与业务连续性

安全合规不仅要求防止数据泄露，也要求在故障、误操作或攻击后能够恢复。

建议至少建立以下机制：

• 根据业务恢复目标制定快照备份和日志备份策略；
• 备份文件启用加密，并与生产集群隔离保存；
• 备份账户仅拥有必要的访问权限；
• 定期验证备份完整性；
• 定期执行恢复演练，并记录恢复时间和数据恢复点；
• 对关键备份保留异地副本；
• 防止普通数据库管理员同时拥有删除生产数据和删除全部备份的权限；
• 将密钥恢复纳入灾难恢复预案。

Raft 多副本可以提高可用性并应对部分节点故障，但不能替代备份。误删除、错误更新或逻辑损坏可能被同步到所有副本，仍需依靠备份和时间点恢复处理。

十、数据库安全控制映射

下面的表格用于说明 TiDB 能够为安全建设提供哪些支撑，不代表启用相关功能后即可自动满足全部合规要求。

需要特别说明：Raft 和校验机制主要解决一致性、可用性及介质损坏检测问题，不能直接等同于防止有权限人员恶意篡改数据。

十一、上线检查清单

建议为每一项保留配置截图、SQL 查询结果、日志样例、测试记录和审批记录，作为检查及测评证据。

十二、常见问题

1. 能否用一个全局参数设置所有账户失败 5 次后锁定？

不能。TiDB 只支持账户级连续登录失败策略，需要对每个账户使用 FAILED_LOGIN_ATTEMPTS 和 PASSWORD_LOCK_TIME 配置。

2. 能否原生设置失败 5 次后锁定 30 分钟？

不能。TiDB 的 PASSWORD_LOCK_TIME 单位为天。如果制度必须要求锁定 30 分钟，需要由外部认证或访问控制系统实现。

3. 开启 TLS 后，客户端是否一定使用加密连接？

不一定。配置服务端证书只是让 TiDB 具备接受 TLS 连接的能力。还需要使用 require_secure_transport、账户级 REQUIRE SSL 或 REQUIRE X509 强制执行，并在客户端启用证书校验。

4. TDE 能否只对敏感表开启？

不能。TiKV 静态加密是组件级配置，不是表级配置。

5. TDE 对性能有多大影响？

没有适用于所有环境的固定数值。性能影响与硬件、存储、缓存命中率、算法、读写比例和数据规模有关，应在 POC 阶段使用真实业务负载测试，不建议在文章中直接承诺固定百分比。

6. KMS 开启自动轮换后，所有数据是否会立即使用新密钥重写？

不会简单地立即完成全量重写。TiKV 的数据密钥轮换、外部 KMS 主密钥轮换及已有文件重写是不同过程，需要按照官方机制分别理解和验证。

7. TiDB 是否自带完整数据库审计？

取决于产品形态。平凯数据库企业版和部分 TiDB Cloud 产品提供数据库审计能力，使用前应确认版本、套餐和启用条件，不能默认所有 TiDB 部署都支持。

8. 完成本文配置后是否等于通过等保三级？

不等于。等保测评以完整信息系统为对象，数据库只是其中一个组成部分。网络、主机、应用、人员、制度、运维和应急响应等措施也必须同时满足要求。

十三、总结

TiDB 数据库安全建设应重点落实以下原则：

1. 不直接照搬 MySQL 参数，所有配置以目标 TiDB 版本文档为准；
2. 密码复杂度可以全局设置，但连续登录失败锁定必须逐账户配置；
3. 通过 RBAC 和最小权限减少高权限账户的使用；
4. 同时保护客户端通信和集群组件间通信；
5. 静态加密需要覆盖 TiKV、TiFlash、备份、临时文件和日志等不同数据副本；
6. 数据库审计必须明确产品边界，并配合集中存储、长期留存和异常告警；
7. 多副本不能代替备份，备份成功也不能代替恢复演练；
8. 技术配置只能支撑合规，最终仍需要制度、流程和测评共同完成。

安全方案的目标不是堆叠功能，而是确保每项控制都真实生效、能够验证、有人负责，并且在发生问题时可以追溯和恢复。