MySQLとのSecurity互換性

TiDBはMySQL 5.7と同様のセキュリティ機能をサポートし、MySQL 8.0の一部のセキュリティ機能もサポートしています。TiDBのセキュリティ機能は、実装においてMySQLとは異なります。

サポートされていないセキュリティ機能

• カラムレベルの権限。
• これらの権限属性: max_questions 、 max_updated 、およびmax_user_connections 。
• パスワード検証ポリシー。パスワードを変更するときに、現在のパスワードを検証する必要があります。
• 二重パスワードポリシー。
• Random password generation.
• 多要素認証。

MySQLとの違い

パスワード有効期限ポリシー

TiDB と MySQL のパスワード有効期限ポリシーには次の違いがあります。

• MySQL は、v5.7 および v8.0 でパスワード有効期限ポリシーをサポートしています。
• TiDB は、v6.5.0 以降でパスワード有効期限ポリシーをサポートしています。

TiDB の有効期限メカニズムは、次の点で MySQL と異なります。

• MySQL v5.7 および v8.0 では、クライアントとサーバーの構成を組み合わせて、クライアント接続に「サンドボックス モード」を有効にするかどうかを決定します。
• TiDB では、 security.disconnect-on-expired-password構成項目だけで、クライアント接続に対して「サンドボックス モード」を有効にするかどうかが決まります。

Password complexity policy

The password complexity policies of TiDB and MySQL have the following differences:

• MySQL v5.7 implements the password complexity policy by using the validate_password plugin.
• MySQL v8.0 では、 validate_passwordコンポーネントを使用してパスワードの複雑さのポリシーが再実装されています。
• TiDB では、v6.5.0 以降、組み込みのパスワード複雑さ管理機能が導入されています。

機能の実装には次の違いがあります。

• 機能を有効にします:

  • MySQL v5.7では、この機能はvalidate_passwordプラグインを使用して実装されています。プラグインをインストールすることで、この機能を有効化できます。
  • MySQL v8.0では、この機能はvalidate_passwordコンポーネントを使用して実装されています。この機能を有効にするには、コンポーネントをインストールしてください。
  • TiDBにはこの機能が組み込まれています。システム変数validate_password.enable使用してこの機能を有効にすることができます。

• 辞書チェック:

  • In MySQL v5.7, you can specify a file path using the validate_password_dictionary_file variable. The file contains a list of words that are not allowed to exist in passwords.
  • MySQL v8.0では、変数validate_password.dictionary_file使用してファイルパスを指定できます。このファイルには、パスワードに使用できない単語のリストが含まれています。
  • TiDBでは、システム変数validate_password.dictionaryを使用して文字列を指定できます。この文字列には、パスワードに使用できない単語のリストが含まれます。

パスワード失敗の追跡

TiDB と MySQL のパスワード失敗追跡ポリシーには、次の違いがあります。

• MySQL v5.7 はパスワード失敗の追跡をサポートしていません。
• MySQL v8.0 はパスワード失敗の追跡をサポートしています。
• TiDB は、v6.5.0 以降でパスワード失敗の追跡をサポートしています。

失敗した試行回数とアカウントのロック状態はグローバルに一貫している必要があり、分散データベースである TiDB は MySQL のように失敗した試行回数とロック状態をサーバーメモリに記録できないため、実装メカニズムは TiDB と MySQL で異なります。

• 自動的にロックされないユーザーの場合、次のシナリオで失敗した試行回数がリセットされます。

  • MySQL 8.0:

    • サーバーを再起動すると、すべてのアカウントの失敗した試行回数がリセットされます。
    • FLUSH PRIVILEGES実行すると、すべてのアカウントの失敗した試行回数がリセットされます。
    • ALTER USER ... ACCOUNT UNLOCK実行してアカウントのロックを解除すると、カウントはリセットされます。
    • アカウントが正常にログインすると、カウントはリセットされます。

  • TiDB:

    • ALTER USER ... ACCOUNT UNLOCK実行してアカウントのロックを解除すると、カウントはリセットされます。
    • When an account logs in successfully, the count is reset.

• 自動的にロックされるユーザーの場合、次のシナリオで失敗した試行回数がリセットされます。

  • MySQL 8.0:

    • サーバーを再起動すると、すべてのアカウントの一時ロックがリセットされます。
    • When FLUSH PRIVILEGES is executed, the temporary locking for all accounts is reset.
    • アカウントのロック時間が終了した場合、次回のログイン試行時にアカウントの一時ロックはリセットされます。
    • ALTER USER ... ACCOUNT UNLOCK実行してアカウントのロックを解除すると、アカウントの一時的なロックがリセットされます。

  • TiDB:

    • アカウントのロック時間が終了した場合、次回のログイン試行時にアカウントの一時ロックはリセットされます。
    • ALTER USER ... ACCOUNT UNLOCK実行してアカウントのロックを解除すると、アカウントの一時的なロックがリセットされます。

パスワード再利用ポリシー

The password reuse policies of TiDB and MySQL have the following differences:

• MySQL v5.7 はパスワード再利用管理をサポートしていません。
• MySQL v8.0 supports password reuse management.
• TiDB supports password reuse management starting from v6.5.0.

TiDBとMySQLの実装メカニズムは一貫しています。どちらもmysql.password_historyのシステムテーブルを使用してパスワード再利用管理機能を実装しています。ただし、 mysql.userシステムテーブルに存在しないユーザーを削除する場合、TiDBとMySQLの動作は異なります。

• シナリオ：ユーザー（ user01 ）は通常の方法で作成されず、 INSERT INTO mysql.password_history VALUES (...)文を使用してuser01のレコードをmysql.password_historyシステムテーブルに追加することで作成されます。この場合、 user01のレコードはmysql.userシステムテーブルに存在しないため、 user01に対してDROP USER実行すると、TiDBとMySQLの動作が異なります。

  • MySQL: DROP USER user01実行すると、MySQL はmysql.userとmysql.password_historyからuser01探します。いずれかのシステムテーブルにuser01が含まれている場合、 DROP USER文は正常に実行され、エラーは報告されません。
  • TiDB: DROP USER user01実行すると、TiDBはmysql.userからのみuser01検索しようとします。関連レコードが見つからない場合、 DROP USER文は失敗し、エラーが報告されます。文を正常に実行し、 mysql.password_historyからuser01レコードを削除したい場合は、代わりにDROP USER IF EXISTS user01使用してください。

Authentication plugin status

TiDBは複数の認証方法をサポートしています。これらの方法は、 CREATE USERとALTER USER使用してユーザーごとに指定できます。これらの方法は、MySQLの同名の認証方法と互換性があります。

You can use one of the following supported authentication methods in the table. To specify a default method that the server advertises when the client-server connection is being established, set the default_authentication_plugin variable. tidb_sm3_password is the SM3 authentication method only supported in TiDB. Therefore, to authenticate using this method, you must connect to TiDB using TiDB-JDBC. tidb_auth_token is a JSON Web Token (JWT)-based authentication method used in TiDB Cloud, and you can also configure it for use in TiDB Self-Managed.

The support for TLS authentication is configured differently. For detailed information, see Enable TLS between TiDB Clients and Servers.

tidb_auth_token

tidb_auth_token JSON Web Token (JWT)ベースにしたパスワードレス認証方式です。v6.4.0では、 tidb_auth_token TiDB Cloudのユーザー認証にのみ使用されます。v6.5.0以降では、 tidb_auth_token TiDB Self-Managedのユーザー認証方式としても設定できます。 mysql_native_passwordやcaching_sha2_passwordなどのパスワードベースの認証方式とは異なり、 tidb_auth_tokenを使用してユーザーを作成する場合、カスタムパスワードを設定したり保存したりする必要はありません。TiDBにログインするには、ユーザーはパスワードの代わりに署名付きトークンを使用するだけで済むため、認証プロセスが簡素化され、セキュリティが向上します。

JWT

JWT consists of three parts: Header, Payload, and Signature. After being encoded using base64, they are concatenated into a string separated by dots (.) for transmission between the client and server.

ヘッダーには、3 つのパラメータを含む JWT のメタデータが記述されます。

• alg : 署名のアルゴリズム。デフォルトはRS256です。
• typ : トークンの種類 ( JWT )。
• kid : トークン署名を生成するためのキー ID。

Here is an example for Header:

{
  "alg": "RS256",
  "kid": "the-key-id-0",
  "typ": "JWT"
}

ペイロードはJWTの主要部分であり、ユーザー情報が格納されます。ペイロード内の各フィールドはクレームと呼ばれます。TiDBユーザー認証に必要なクレームは以下のとおりです。

• iss : CREATE USERときにTOKEN_ISSUER指定されていないか空に設定されている場合、このクレームは必要ありません。それ以外の場合、 iss TOKEN_ISSUERと同じ値を使用する必要があります。
• sub : このクレームは、認証されるユーザー名と同じである必要があります。
• iat: it means issued at, the timestamp when the token is issued. In TiDB, this value must not be later than the authentication time or earlier than 15 minutes before authentication.
• exp : トークンの有効期限のタイムスタンプ。認証時刻より前の場合、認証は失敗します。
• email : ユーザー作成時にメールアドレスをATTRIBUTE '{"email": "xxxx@pingcap.com"}で指定できます。ユーザー作成時にメールアドレスが指定されていない場合は、このクレームは空の文字列に設定する必要があります。それ以外の場合は、このクレームはユーザー作成時に指定された値と同じである必要があります。

ペイロードの例を次に示します。

{
  "email": "user@pingcap.com",
  "exp": 1703305494,
  "iat": 1703304594,
  "iss": "issuer-abc",
  "sub": "user@pingcap.com"
}

署名は、ヘッダーとペイロード データに署名するために使用されます。

使用法

TiDB Self-Managed ユーザーの認証方法としてtidb_auth_token設定して使用するには、次の手順を実行します。

1. Configure auth-token-jwks and auth-token-refresh-interval in the TiDB configuration file.

   たとえば、次のコマンドを使用して JWKS の例を取得できます。

   wget https://raw.githubusercontent.com/CbcWestwolf/generate_jwt/master/JWKS.json
   

   Then, configure the path of the example JWKS in config.toml:

   [security]
   auth-token-jwks = "JWKS.json"
   

2. tidb-server起動し、定期的に JWKS を更新してauth-token-jwksで指定されたパスに保存します。

3. tidb_auth_tokenでユーザーを作成し、必要に応じてREQUIRE TOKEN_ISSUERとATTRIBUTE '{"email": "xxxx@pingcap.com"}を使用してissとemail指定します。

   たとえば、 tidb_auth_tokenを持つユーザーuser@pingcap.com作成します。

   CREATE USER 'user@pingcap.com' IDENTIFIED WITH 'tidb_auth_token' REQUIRE TOKEN_ISSUER 'issuer-abc' ATTRIBUTE '{"email": "user@pingcap.com"}';
   

4. 認証用のトークンを生成して署名し、MySQL クライアントのmysql_clear_textプラグインを使用して認証します。

   Install the JWT generation tool via go install github.com/cbcwestwolf/generate_jwt (this tool is only used for testing tidb_auth_token). For example:

   generate_jwt --kid "the-key-id-0" --sub "user@pingcap.com" --email "user@pingcap.com" --iss "issuer-abc"
   

   公開鍵とトークンは次のように出力。

   -----BEGIN PUBLIC KEY-----
   MIIBCgKCAQEAq8G5n9XBidxmBMVJKLOBsmdOHrCqGf17y9+VUXingwDUZxRp2Xbu
   LZLbJtLgcln1lC0L9BsogrWf7+pDhAzWovO6Ai4Aybu00tJ2u0g4j1aLiDdsy0gy
   vSb5FBoL08jFIH7t/JzMt4JpF487AjzvITwZZcnsrB9a9sdn2E5B/aZmpDGi2+Is
   f5osnlw0zvveTwiMo9ba416VIzjntAVEvqMFHK7vyHqXbfqUPAyhjLO+iee99Tg5
   AlGfjo1s6FjeML4xX7sAMGEy8FVBWNfpRU7ryTWoSn2adzyA/FVmtBvJNQBCMrrA
   hXDTMJ5FNi8zHhvzyBKHU0kBTS1UNUbP9wIDAQAB
   -----END PUBLIC KEY-----
   
   eyJhbGciOiJSUzI1NiIsImtpZCI6InRoZS1rZXktaWQtMCIsInR5cCI6IkpXVCJ9.eyJlbWFpbCI6InVzZXJAcGluZ2NhcC5jb20iLCJleHAiOjE3MDMzMDU0OTQsImlhdCI6MTcwMzMwNDU5NCwiaXNzIjoiaXNzdWVyLWFiYyIsInN1YiI6InVzZXJAcGluZ2NhcC5jb20ifQ.T4QPh2hTB5on5xCuvtWiZiDTuuKvckggNHtNaovm1F4RvwUv15GyOqj9yMstE-wSoV5eLEcPC2HgE6eN1C6yH_f4CU-A6n3dm9F1w-oLbjts7aYCl8OHycVYnq609fNnb8JLsQAmd1Zn9C0JW899-WSOQtvjLqVSPe9prH-cWaBVDQXzUJKxwywQzk9v-Z1Njt9H3Rn9vvwwJEEPI16VnaNK38I7YG-1LN4fAG9jZ6Zwvz7vb_s4TW7xccFf3dIhWTEwOQ5jDPCeYkwraRXU8NC6DPF_duSrYJc7d7Nu9Z2cr-E4i1Rt_IiRTuIIzzKlcQGg7jd9AGEfGe_SowsA-w
   

   Copy the preceding token in the last line for login:

   mycli -h 127.0.0.1 -P 4000 -u 'user@pingcap.com' -p '<the-token-generated>'
   

   ここで紹介するMySQLクライアントがmysql_clear_passwordプラグインをサポートしていることを確認してください。3 マイクリデフォルトでこのプラグインをサポートし、有効化します。5 MySQLコマンドラインクライアント使用している場合は、 --enable-cleartext-pluginオプションを使用してこのプラグインを有効化する必要があります。

   mysql -h 127.0.0.1 -P 4000 -u 'user@pingcap.com' -p'<the-token-generated>' --enable-cleartext-plugin
   

   トークンの生成時に誤った--subが指定された場合 ( --sub "wronguser@pingcap.com"など)、このトークンを使用した認証は失敗します。

jwt.ioが提供するデバッガーを使用してトークンをエンコードおよびデコードできます。