重要

このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

MySQL とのSecurity互換性

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

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

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

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構成項目だけで、クライアント接続に対して「サンドボックスモード」を有効にするかどうかが決まります。

パスワードの複雑さに関するポリシー

TiDB と MySQL のパスワード複雑性ポリシーには、次の違いがあります。

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

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

機能を有効にします:
- MySQL v5.7では、 validate_passwordプラグインを使用してこの機能が実装されています。プラグインをインストールすることで、この機能を有効にすることができます。
- MySQL v8.0 では、 validate_passwordコンポーネントを使用してこの機能が実装されています。コンポーネントをインストールすることで、この機能を有効にすることができます。
- TiDB の場合、この機能は組み込まれています。システム変数validate_password.enableを使用してこの機能を有効にすることができます。
辞書チェック:
- MySQL v5.7 では、 validate_password_dictionary_file変数を使用してファイルパスを指定できます。ファイルには、パスワードに存在できない単語のリストが含まれています。
- 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実行してアカウントのロックを解除すると、カウントがリセットされます。
  - アカウントが正常にログインすると、カウントはリセットされます。
- ティDB:
  - ALTER USER ... ACCOUNT UNLOCK実行してアカウントのロックを解除すると、カウントがリセットされます。
  - アカウントが正常にログインすると、カウントはリセットされます。
自動的にロックされるユーザーの場合、次のシナリオでは失敗した試行回数がリセットされます。
- MySQL 8.0:
  - サーバーを再起動すると、すべてのアカウントの一時的なロックがリセットされます。
  - FLUSH PRIVILEGESを実行すると、すべてのアカウントの一時ロックがリセットされます。
  - アカウントのロック時間が終了すると、次回のログイン試行時にアカウントの一時ロックがリセットされます。
  - ALTER USER ... ACCOUNT UNLOCKを実行してアカウントのロックを解除すると、アカウントの一時的なロックがリセットされます。
- ティDB:
  - アカウントのロック時間が終了すると、次回のログイン試行時にアカウントの一時ロックがリセットされます。
  - ALTER USER ... ACCOUNT UNLOCKを実行してアカウントのロックを解除すると、アカウントの一時的なロックがリセットされます。

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

TiDB と MySQL のパスワード再利用ポリシーには、次の違いがあります。

MySQL v5.7 はパスワード再利用管理をサポートしていません。
MySQL v8.0 はパスワード再利用管理をサポートしています。
TiDB は、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使用します。

認証プラグインのステータス

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

次の表に示すサポートされている認証方法のいずれかを使用できます。クライアントとサーバー間の接続を確立するときにサーバーが通知するデフォルトの方法を指定するには、 default_authentication_plugin変数を設定します。 tidb_sm3_password 、TiDB でのみサポートされている SM3 認証方法です。したがって、この方法を使用して認証するには、 TiDB-JDBC使用して TiDB に接続する必要があります。 tidb_auth_token 、 TiDB Cloudで使用される JSON Web Token (JWT) ベースの認証方法で、TiDB Self-Hosted で使用するように構成することもできます。

TLS 認証のサポートは異なる方法で構成されます。詳細については、 TiDBクライアントとサーバー間のTLSを有効にするを参照してください。

認証方法	サポート
`mysql_native_password`	はい
`sha256_password`	いいえ
`caching_sha2_password`	はい、5.2.0以降
`auth_socket`	はい、5.3.0以降
`tidb_sm3_password`	はい、6.3.0以降
`tidb_auth_token`	はい、6.4.0以降
`authentication_ldap_sasl`	はい、7.1.0以降
`authentication_ldap_simple`	はい、7.1.0以降
TLS 証明書	はい
LDAP の	はい、7.1.0以降
パム	いいえ
ed25519 (マリアDB)	いいえ
GSSAPI (MariaDB)	いいえ
ファイド	いいえ

`tidb_auth_token`

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

JWT

JWTは、ヘッダー、ペイロード、署名の3つの部分で構成されています。これらはbase64でエンコードされた後、ドットで区切られた文字列（ . ）に連結され、クライアントとサーバー間で送信されます。

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

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

ヘッダーの例を次に示します。

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

ペイロードは JWT の主要部分であり、ユーザー情報を保存します。ペイロード内の各フィールドはクレームと呼ばれます。TiDB ユーザー認証に必要なクレームは次のとおりです。

iss : TOKEN_ISSUERが指定されていないか、 CREATE USERときに空に設定されている場合、このクレームは必要ありません。それ以外の場合、 iss TOKEN_ISSUERと同じ値を使用する必要があります。
sub : このクレームは、認証されるユーザー名と同じである必要があります。
iat : issued atを意味し、トークンが発行されたときのタイムスタンプです。TiDB では、この値は認証時間より遅くてはならず、認証の 15 分前より早くてはなりません。
exp : トークンの有効期限が切れるタイムスタンプ。認証時刻より早い場合、認証は失敗します。
email : ユーザーの作成時にATTRIBUTE '{"email": "xxxx@pingcap.com"}で電子メールを指定できます。ユーザーの作成時に電子メールが指定されていない場合、このクレームは空の文字列として設定する必要があります。それ以外の場合、このクレームはユーザーの作成時に指定された値と同じである必要があります。

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

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

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

警告

ヘッダーとペイロードの base64 エンコードは可逆的です。機密情報を添付しないでください。
tidb_auth_token認証方法では、トークンをプレーンテキストで TiDB に送信するために、クライアントがmysql_clear_passwordプラグインをサポートしている必要があります。したがって、 tidb_auth_token使用する前にクライアントとサーバー間のTLSを有効にするを行う必要があります。

使用法

TiDB セルフホストユーザーの認証方法としてtidb_auth_token設定して使用するには、次の手順を実行します。

TiDB 構成ファイルでauth-token-jwksとauth-token-refresh-intervalを構成します。
たとえば、次のコマンドを使用してサンプルの JWKS を取得できます。
```
wget https://raw.githubusercontent.com/CbcWestwolf/generate_jwt/master/JWKS.json
```
次に、 config.tomlのサンプル JWKS のパスを設定します。
```
[security]
auth-token-jwks = "JWKS.json"
```
tidb-server起動し、定期的に JWKS を更新してauth-token-jwksで指定されたパスに保存します。
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"}';
```

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

go install github.com/cbcwestwolf/generate_jwtから JWT 生成ツールをインストールします (このツールはtidb_auth_tokenテストにのみ使用されます)。例:

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

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

ログインの最後の行にある上記のトークンをコピーします。

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

ここで、MySQL クライアントがmysql_clear_passwordプラグインをサポートしていることを確認します。マイクリデフォルトでこのプラグインをサポートし、有効にします。 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"など)、このトークンを使用した認証は失敗します。

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