What measures has TiDB taken to ensure data security?

This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: TIDB 在数据安全做了哪些保障

| username: residentevil

【TiDB Usage Environment】Production Environment
【TiDB Version】V6.4.8
【Encountered Issues: Problem Phenomenon and Impact】 After deploying the TiDB cluster, although it can be used normally, there are concerns about data security risks, such as:
1. Whether Grafana monitoring will expose data from business tables
2. Whether there are risks with the OpenAPI interface [by default, I see no authentication function]

| username: Miracle | Original post link

Grafana supports executing database SQL queries. To avoid exposing business table data, it should be controlled from the database permissions.

| username: xfworld | Original post link

Grafana monitors the status information and data of the entire TiDB cluster, but does not include actual business data.

The OpenAPI interface can be fixed within a certain subnet and not exposed to the outside…

No one would put TiDB directly on the public network, right… :see_no_evil:

| username: 小龙虾爱大龙虾 | Original post link

What you mentioned is a problem; it should be placed in an intranet environment for better security.

| username: 有猫万事足 | Original post link

The protection here in OpenAPI is only TLS.
The other party cannot access it without the certificate you generated.
If the internal API requires authentication, it would be too heavy and severely affect the call efficiency.
If the other party has already infiltrated to the extent that they can obtain the generated certificate, I think whether or not to authenticate doesn’t really matter anymore.

| username: 江湖故人 | Original post link

I didn’t see Prometheus and Grafana accounts in the TiDB system table, so business data won’t be exposed. I guess TiDB’s status information is transmitted to Prometheus through an API.

| username: 江湖故人 | Original post link

I’m very curious about what your company uses OpenAPI for.

| username: Fly-bird | Original post link

The biggest concerns for data security should be account security, data encryption at rest, and secure communication between various components of the cluster. Security risks in monitoring are relatively minimal.

| username: dba远航 | Original post link

The security design of TiDB is not very high; first, you need to ensure that it is used in a secure environment.

| username: hey-hoho | Original post link

Where did this come from? :thinking:

| username: tidb菜鸟一只 | Original post link

  1. Grafana contains information about the entire cluster, at most region information, but no business table data, so there is no exposure risk.
  2. The OpenAPI interface does have potential risks, but if your TiDB is on an internal network, theoretically, access to your database can only be through the firewall. You can only open the 4000 port of the TiDB server, and do not open other ports for access by other IPs, only allowing internal cluster access. If the other party can log in to your internal cluster host, then OpenAPI is not needed…
| username: tidb菜鸟一只 | Original post link

However, the data in TiDB’s Grafana is obtained from Prometheus. Prometheus also retrieves data from the OpenAPI and does not directly connect to the database…

| username: Miracle | Original post link

Grafana can be configured with multiple data sources, not necessarily Prometheus. If you configure a MySQL data source, you can display MySQL table data, right?

| username: tidb菜鸟一只 | Original post link

Doesn’t that require an account and password first? Once you have the account and password, do you still need to configure the data source in Grafana? Can’t you just query directly? The Grafana that comes with TiDB is by default only configured with the Prometheus data source. Configuring other data sources requires a password…

| username: residentevil | Original post link

I see that the official documentation mentions OpenAPI interfaces related to monitoring, but I didn’t see any authentication, which raises security concerns.
For example: TiDB 集群监控 API | PingCAP 文档中心

| username: residentevil | Original post link

The permissions related to database accounts will definitely be consolidated properly (authorized IP, password, etc.), but I couldn’t find the login account information used in Grafana in the mysql.user table.

| username: residentevil | Original post link

I guess those using TiDB are all within an internal network, haha.

| username: onlyacat | Original post link

The API of PD might have risks, but since it’s all within the internal network, worrying about this is probably useless…

| username: onlyacat | Original post link

The Grafana account is managed by Grafana itself. After initialization, you can change it on the Grafana page.

| username: tidb菜鸟一只 | Original post link

The login account on Grafana is not the database account password, but the Grafana account password, which is stored in Grafana’s SQLite3 database. It is not the same as the TiDB account password.