TiDB 是一个分布式 NewSQL 数据库，由 PingCAP 公司开发。它兼容 MySQL 协议和生态，支持水平扩展、强一致性和高可用性。TiDB 的设计目标是为在线事务处理（OLTP）和在线分析处理（OLAP）提供一站式解决方案，适用于互联网、金融、游戏、大数据等场景。

TiDB 的主要特点：

1. 分布式架构：TiDB 采用分布式架构，支持数据的自动分片（Sharding）和动态扩展，可以轻松扩展到数百个节点，支持 PB 级别的数据存储。

2. 水平扩展：随着业务量的增长，可以无缝地添加更多的服务器节点来提升处理能力，无需停机维护或数据迁移。

3. 强一致性：TiDB 使用 Raft 协议来保证数据强一致性，确保即使在部分节点故障的情况下，数据仍然是一致的。

4. 高可用性：TiDB 的每个组件都支持高可用部署，即使多个节点同时故障，服务仍然可用，保证了业务的连续性。

5. MySQL 兼容：TiDB 兼容 MySQL 协议和生态，支持大多数 MySQL 语法和函数，用户可以无缝地将 MySQL 应用迁移到 TiDB。

6. 智能查询优化：TiDB 拥有智能的查询优化器，能够自动优化 SQL 查询，提高查询效率。

7. HTAP 能力：TiDB 与 TiKV、TiFlash 组件结合，可以实现混合事务/分析处理（HTAP），即在同一套系统上同时处理 OLTP 和 OLAP 负载。

TiDB 的组件：

• TiDB Server：无状态的 SQL 层，负责处理 SQL 语句，解析、优化和执行计划，最终生成分布式执行计划。
• PD (Placement Driver)：集群的元数据和调度中心，负责整个集群的数据分布和负载均衡。
• TiKV：分布式事务型键值数据库，是 TiDB 的存储引擎，支持水平扩展和高可用性。
• TiFlash：TiKV 的列式存储扩展，提供强大的分析查询能力，与 TiKV 共享相同的底层存储，支持实时 HTAP。

应用场景：

• 互联网业务：处理高并发、大数据量的互联网业务，如社交应用、电商网站等。
• 金融场景：满足金融行业对高可用性、强一致性和数据安全性的严格要求。
• 游戏场景：支持实时数据分析和复杂查询，提升游戏体验。
• 大数据处理：结合 TiFlash 组件，实现实时分析处理，提升数据处理效率。

总之，TiDB 是一个功能强大、灵活可扩展的分布式数据库，为现代应用提供了高性能、高可用性和高可扩展性的数据存储解决方案。（以上由文心一言生成）

TiDB是在需要高并发的场景经常见到的数据库，在大型的企业中会经常看到，虽然经常说他长得像MySQL数据库，但事实上其性能还是比较强的。本文就以等保三级为基础，参考28448，来简单说明一下TIDB的测评过程。

一、身份鉴别

a)应对登录的用户进行身份标识和鉴别，身份标识具有唯一性，身份鉴别信息具有复杂度要求并定期更换。

这一项的测评，根据28448测评要求，我们需要确认以下几点：

1、应核查用户在登录时是否采用了身份鉴别措施；

2、应核查用户列表确认用户身份标识是否具有唯一性；

3、应核查用户配置信息或测试验证是否不存在空口令用户

4、应核查用户鉴别信息是否具有复杂度要求并定期更换

TiDB数据库本身是采用了身份鉴别措施，在不同的TiDB集群，你可以使用同样的用户名，但在一个集群中，用户名是唯一的。

在 TiDB 中，密码复杂度检查默认未开启。通过配置密码复杂度相关的系统变量，你可以开启密码复杂度检查，并确保为账户设置的密码符合密码复杂度策略。

密码复杂度策略支持以下功能：

• 对采用明文方式设置用户密码的 SQL 语句（包括 CREATE USER、ALTER USER、SET PASSWORD），系统会根据密码复杂度策略检查该密码，如果该密码不符合要求，则拒绝该密码。
• 可以使用 SQL 函数 VALIDATE_PASSWORD_STRENGTH()评估给定密码的强度。

可以使用以下sql查看密码复杂度策略：

show variables like 'validate_password.%';

各位同僚要特别注意validate_password.enable这个，为OFF的话是绝对不能给完全符合的。

关于口令有效期，TiDB 支持通过设置密码过期策略，要求用户定期修改密码，从而提高密码的安全性。可以手动将指定账户的密码设置为过期，也可以建立密码自动过期策略。自动过期策略分为全局级别和账户级别，管理员可以在全局级别建立密码过期策略，也可以使用账户级别密码过期策略覆盖全局级别策略。

TiDB 支持在全局级别和账户级别设置自动密码过期：

• 全局级别自动密码过期

  你可以设置系统变量 default_password_lifetime来控制密码生存期。该变量默认值为 0，表示禁用自动密码过期。如果设置该变量的值为正整数 N，则表示允许的密码生存期为 N 天，即必须在 N 天之内更改密码。

  全局自动密码过期策略适用于所有未设置账户级别覆盖的账户。

show variables like 'default_password_lifetime';

b)应具有登录失败处理功能，应配置并启用结束会话、限制非法登录次数和当登录连接超时自动退出等相关措施。

根据28448测评要求，我们需要确认以下几点：

• 应核查是否配置并启用了登录失败处理功能；
• 应核查是否配置并启用了限制非法登录功能,非法登录达到一定次数后采取特定动作,如账户锁定等；
• 应核查是否配置并启用了登录连接超时及自动退出功能；

TiDB 支持限制账户持续尝试登录，防止用户密码被暴力破解。当账户连续登录失败次数过多时，账户将被临时锁定。

每个账户的登录失败次数和锁定时间是可配置的，你可以使用 CREATE USER、ALTER USER语句的 FAILED_LOGIN_ATTEMPTS和 PASSWORD_LOCK_TIME选项。FAILED_LOGIN_ATTEMPTS和 PASSWORD_LOCK_TIME选项的可设置值如下：

• FAILED_LOGIN_ATTEMPTS：N。表示连续登录失败 N 次后，账户将被临时锁定。N 取值范围为 0 到 32767。
• PASSWORD_LOCK_TIME：N | UNBOUNDED。N 表示登录失败后，账户将被临时锁定 N 天。UNBOUNDED 表明锁定时间无限期，账户必须被手动解锁。N 取值范围为 0 到 32767。

我们可以通过以下语句查看登录失败处理策略：

show variables like '%FAILED_LOGIN_ATTEMPTS%';
show variables like '%PASSWORD_LOCK_TIME%';

会话超时时间，则和MySQL差不多，通过wait_timeout去控制

• wait_timeout，控制与 Java 应用连接的非交互式空闲超时时间。在 TiDB v5.4 及以上版本中，默认值为 28800秒，即空闲超时为 8 小时。在 v5.4 之前，默认值为 0，即没有时间限制。

查看该参数，我们可以通过以下参数：

show variables like '%timeout%';

c)当进行远程管理时，应采取必要措施防止鉴别信息在网络传输过程中被窃听；

在28448中，这项是这么要求的：核查是否采用加密等安全方式对系统进行远程管理,防止鉴别信息在网络传输过程中被窃听。

默认情况下，TiDB 允许服务端与客户端之间的不安全连接，因而具备监视信道流量能力的第三方可以知悉 TiDB 服务端与客户端之间发送和接受的数据，包括但不限于查询语句内容、查询结果等。若信道是不可信的，例如客户端是通过公网连接到 TiDB 服务端的，则不安全连接容易造成信息泄露，建议使用 TLS 连接确保安全性。

TiDB 服务端支持启用基于 TLS（传输层安全）协议的安全连接，协议与 MySQL 安全连接一致，现有 MySQL Client 如 MySQL Shell 和 MySQL 驱动等能直接支持。TLS 的前身是 SSL，因而 TLS 有时也被称为 SSL，但由于 SSL 协议有已知安全漏洞，TiDB 实际上并未支持。TiDB 支持的 TLS/SSL 协议版本为 TLSv1.2 和 TLSv1.3。

查看是否开启SSL，可以通过以下sql：

show variables like '%ssl%';

d) 应采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术对用户进行身份鉴别，且其中一种鉴别技术至少应使用密码技术来实现。

截至本文完稿前应该还没有数据库能够实现双因子。云平台那个用户名+密码+动态OTP我感觉应该是算的但是前辈们说最多给部分符合。

二、访问控制

a) 应对登录的用户分配账户和权限；

在28448中，是这么要求的：

• 应核查是否为用户分配了账户和权限及相关设置情况;

• 应核查是否已禁用或限制匿名、默认账户的访问权限；

TiDB的用户存储在mysql.user表，我们可以通过以下sql查看：

select user,host from mysql.user;

结合访谈的结果进行判定。

b) 应重命名或删除默认账户，修改默认账户的默认口令；

在28448中，是这么要求的：

• 应核查是否已经重命名默认账户或默认账户已被删除；

• 应核查是否已修改默认账户的默认口令；

TiDB 在数据库初始化时会生成一个 'root'@'%'的默认账户，这点和MySQL差不多，访谈管理员是否修改默认的密码。

c) 应及时删除或停用多余的、过期的账户，避免共享账户的存在；

根据上一项的检查结果，并与配合人员访谈各在用账户的使用情况。

d) 应授予管理用户所需的最小权限，实现管理用户的权限分离；

基本做不到，视情况给部分符合。

e) 应由授权主体配置访问控制策略，访问控制策略规定主体对客体的访问规则；

此项默认符合。

f) 访问控制的粒度应达到主体为用户级或进程级，客体为文件、数据库表级；

默认符合。

g)应对重要主体和客体设置安全标记,并控制主体对有安全标记信息资源的访问；

默认不符合。

三、安全审计

a) 应启用安全审计功能，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计；

根据28448的要求，本项的核查点如下：

• 应核查是否开启了安全审计功能;
• 应核查安全审计范围是否覆盖到每个用户;应核查是否对重要的用户行为和重要安全事件进行审计

和MySQL大差不差，TiDB的审计依旧是通过general_log去控制，如果需要查看审计是否开启，需要查看general_log是否开启。

可以通过下列的sql去查询：

show global variables like '%general%'

如果说使用了云上的TiDB，即TiDB-cloud，可以在控制台查看输出审计的日志，前提是开启了依托于云平台的审计功能。

b) 审计记录应包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息；

输入以下命令查看日志信息是否足够详细：

在28448中，这一项是这么要求的：

应核查审计记录信息是否包括事件的日期和时间、主体标识、客体标识、事件类型、事件是否成功及其他与审计相关的信息。

可以通过以下sql查看general_log日志，

select * from general_log

会输出包含以下字段的日志：

• 在 TiDB 配置项 log.level为 "info"或 "debug"时，通过查询 "GENERAL_LOG"字符串可以定位到该功能在日志中的所有记录。日志会记录以下内容：
  • conn：当前会话对应的 ID
  • user：当前会话用户
  • schemaVersion：当前 schema 版本
  • txnStartTS：当前事务的开始时间戳
  • forUpdateTS：事务模式为悲观事务时，SQL 语句的当前时间戳。悲观事务内发生写冲突时，会重试当前执行语句，该时间戳会被更新。重试次数由 max-retry-count配置。事务模式为乐观事务时，该条目与 txnStartTS等价。
  • isReadConsistency：当前事务隔离级别是否是读已提交 (RC)
  • current_db：当前数据库名
  • txn_mode：事务模式。可选值：OPTIMISTIC（乐观事务模式），或 PESSIMISTIC（悲观事务模式）
  • sql：当前查询对应的 SQL 语句

如果是通过控制台输出的日志，则字段会有所不同，详情参考英文文档：

TiDB-colud官方文档

c) 应对审计记录进行保护，定期备份，避免受到未预期的删除、修改或覆盖等；

根据28448的要求，应核查是否采取了保护措施对审计记录进行保护;应核查是否采取技术措施对审计记录进行定期备份,并核查其备份策略。

全量备份包含集群某个时间点的全量数据，但是不包含其他时间点的更新数据，而 TiDB 日志备份能够将业务写入 TiDB 的数据记录及时备份到指定存储中。如果你需要灵活的选择恢复的时间点，即实现 Point-in-time recovery (PITR)，可以开启日志备份，并定期执行快照（全量）备份。

为了不过多拖累服务器的容量，我们一般是开启定期的快照备份。

快照备份功能可作为全量备份的方法，运行 tiup br backup full命令可以按照固定的周期（比如 2 天）进行全量备份。

访谈管理员的备份策略。

d) 应对审计进程进行保护，防止未经授权的中断。

测试使用非审计管理员中断审计进程，是否能成功，询问和检查是否安装第三方审计进程保护软件。

四、入侵防范

a) 应遵循最小安装的原则，仅安装需要的组件和应用程序；

根据28448的要求，我们应该核查下列内容：

• 1)应核查是否遵循最小安装原则:

• 2)应核查是否未安装非必要的组件和应用程序

TiDB拥有非常多的扩展插件，可以通过下列命令查询安装的扩展插件：

tiup list --installed；

b) 应关闭不需要的系统服务、默认共享和高危端口；

这一项给不适用。数据库不涉及。

c) 应通过设定终端接入方式或网络地址范围对通过网络进行管理的管理终端进行限制；

根据28448的要求，我们需要核查配置文件或参数是否对终端接入范围进行限制。

在TiDB的官方文档没找到类似的描述，可以参考MySQL的设置，对每个账户的监听ip进行限制，此处不再赘述。

d) 应提供数据有效性检验功能，保证通过人机接口输入或通过通信接口输入的内容符合系统设定要求；

对数据库来说该项直接不适用。一般是应用或者管理软件才会有这一项。

e) 应能发现可能存在的已知漏洞，并在经过充分测试评估后，及时修补漏洞；

根据漏洞扫描的结果描述。

f) 应能够检测到对重要节点进行入侵的行为，并在发生严重入侵事件时提供报警。

数据库不涉及此项，不适用。

五、恶意代码防范

应采用免受恶意代码攻击的技术措施或主动免疫可信验证机制及时识别入侵和病毒行为，并将其有效阻断。

数据库不涉及此项，直接不适用。

六、可信验证

可基于可信根对计算设备的系统引导程序、 系统程序、重要配置参数和应用程序等进行可信验证，并在应用程序的关键执行环节进行动态可信验证，在检测到其可信性受到破坏后进行报警，并将验证结果形成审计记录送至安全管理中心。

直接不适用。

七、数据完整性

a)应采用校验技术或密码技术保证重要数据在传输过程中的完整性，包括但不限于鉴别数据、重要业务数据、重要审计数据、重要配置数据、重要视频数据和重要个人信息等；

传输完整性，一般看SSL有没有开就行。

b) 应采用校验技术或密码技术保证重要数据在存储过程中的完整性，包括但不限于鉴别数据、重要业务数据、重要审计数据、重要配置数据、重要视频数据和重要个人信息等。

存储完整性，TiDB使用bcrypt算法对用户的密码进行加密，其余数据需要借助第三方加密插件。

八、数据保密性

a)应采用密码技术保证重要数据在传输过程中的保密性，包括但不限于鉴别数据、重要业务数据和重要个人信息等；

传输保密性，一般看SSL有没有开就行。

b)应采用密码技术保证重要数据在存储过程中的保密性，包括但不限于鉴别数据、重要业务数据和重要个人信息等。

存储保密性，TiDB存在静态加密功能。

静态加密 (encryption at rest) 即在存储数据时进行数据加密。对于数据库，静态加密功能也叫透明数据加密 (TDE)，区别于传输数据加密 (TLS) 或使用数据加密（很少使用）。SSD 驱动器、文件系统、云供应商等都可进行静态加密。但区别于这些加密方式，若 TiKV 在存储数据前就进行数据加密，攻击者则必须通过数据库的身份验证才能访问数据。例如，即使攻击者获得物理机的访问权限时，也无法通过复制磁盘上的文件来访问数据。

部署好一个 TiDB 集群后，大部分用户数据会存储在 TiKV 和 TiFlash 节点上。此外，一些元数据会存储在 PD 节点上，例如用作为 TiKV Region 边界的二级索引密钥。为了能够充分发挥静态加密的优势，所有组件都需要启用加密功能。此外，进行加密时，也需要对备份、日志文件和通过网络传输的数据进行加密。

此处不再赘述，可以参考：

TiDB加密

九、数据备份恢复

a)应提供重要数据的本地数据备份与恢复功能；

咨询甲方备份策略和备份恢复测试相关。

b)应提供异地实时备份功能，利用通信网络将重要数据实时备份至备份场地；

需要注意的是三级要求的异地备份是实时备份。

c)应提供重要数据处理系统的热冗余，保证系统的高可用性。

看所在服务器是否集群部署。

十、剩余信息保护

a) 应保证鉴别信息所在的存储空间被释放或重新分配前得到完全清除；

退出后需要重新输入用户名密码的话直接给符合。

b) 应保证存有敏感数据的存储空间被释放或重新分配前得到完全清除。

这个需要问甲方说有没有针对存放敏感信息的存储介质做废弃处理。比如建立敏感数据的擦除机制，硬盘报废后进行物理毁坏处理等等。

以上就是TiDB数据库有关等保三级的测评项的一些解析。有些不对的地方欢迎大家在评论区指出。