TiDB パスワード管理

ユーザー パスワードのセキュリティを保護するために、TiDB は v6.5.0 以降、次のパスワード管理ポリシーをサポートしています。

• パスワードの複雑さに関するポリシー: 空のパスワードや脆弱なパスワードを防ぐために、強力なパスワードを設定するようユーザーに要求します。
• パスワードの有効期限ポリシー: ユーザーがパスワードを定期的に変更することを要求します。
• パスワード再利用ポリシー: ユーザーが古いパスワードを再利用できないようにします。
• 失敗したログインの追跡と一時的なアカウント ロック ポリシー: ユーザー アカウントを一時的にロックして、間違ったパスワードが原因で何度もログインに失敗した後、同じユーザーがログインを試みないようにします。

TiDB 認証資格情報storage

ユーザー ID の信頼性を確保するために、TiDB はパスワードを資格情報として使用して、ユーザーが TiDBサーバーにログインするときにユーザーを認証します。

このドキュメントで説明されているパスワードは、TiDB によって生成、保存、および検証された内部資格情報を指します。 TiDB は、ユーザーのパスワードをmysql.userシステム テーブルに格納します。

次の認証プラグインは、TiDB のパスワード管理に関連しています。

• mysql_native_password
• caching_sha2_password
• tidb_sm3_password

TiDB 認証プラグインの詳細については、 認証プラグインのステータスを参照してください。

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

TiDB では、パスワードの複雑さのチェックはデフォルトで無効になっています。パスワードの複雑さに関連するシステム変数を構成することにより、パスワードの複雑さのチェックを有効にして、ユーザーのパスワードがパスワードの複雑さのポリシーに準拠していることを確認できます。

パスワードの複雑さのポリシーには、次の機能があります。

• ユーザーパスワードをプレーンテキストで設定する SQL ステートメント ( CREATE USER 、 ALTER USER 、およびSET PASSWORDを含む) の場合、TiDB はパスワードの複雑さのポリシーに対してパスワードをチェックします。パスワードが要件を満たさない場合、パスワードは拒否されます。
• SQL 関数VALIDATE_PASSWORD_STRENGTH()を使用して、パスワードの強度を検証できます。

ノート：

• CREATE USERステートメントについては、作成時にアカウントをロックできる場合でも、許容できるパスワードを設定する必要があります。そうしないと、アカウントのロックが解除されたときに、このアカウントは、パスワードの複雑さに関するポリシーに準拠していないパスワードを使用して TiDB にログインできます。
• パスワード複雑度ポリシーの変更は、既存のパスワードには影響せず、新しく設定されたパスワードにのみ影響します。

次の SQL ステートメントを実行すると、パスワードの複雑性ポリシーに関連するすべてのシステム変数を表示できます。

mysql> SHOW VARIABLES LIKE 'validate_password.%';

+--------------------------------------+--------+
| Variable_name                        | Value  |
+--------------------------------------+--------+
| validate_password.check_user_name    | ON     |
| validate_password.dictionary         |        |
| validate_password.enable             | OFF    |
| validate_password.length             | 8      |
| validate_password.mixed_case_count   | 1      |
| validate_password.number_count       | 1      |
| validate_password.policy             | MEDIUM |
| validate_password.special_char_count | 1      |
+--------------------------------------+--------+
8 rows in set (0.00 sec)

各システム変数の詳細な説明については、 システム変数を参照してください。

パスワードの複雑さのポリシーを構成する

このセクションでは、パスワードの複雑さのポリシーに関連するシステム変数の構成例を示します。

パスワードの複雑さのチェックを有効にします。

SET GLOBAL validate_password.enable = ON;

ユーザー名と同じパスワードの使用をユーザーに許可しない:

SET GLOBAL validate_password.check_user_name = ON;

パスワードの複雑さレベルをLOWに設定します。

SET GLOBAL validate_password.policy = LOW;

パスワードの最小長を10に設定します。

SET GLOBAL validate_password.length = 10;

パスワードには、少なくとも 2 つの数字、1 つの大文字、1 つの小文字、および 1 つの特殊文字を含める必要があります。

SET GLOBAL validate_password.number_count = 2;
SET GLOBAL validate_password.mixed_case_count = 1;
SET GLOBAL validate_password.special_char_count = 1;

パスワードにmysqlやabcdの単語が含まれないようにする辞書チェックを有効にします。

SET GLOBAL validate_password.dictionary = 'mysql;abcd';

ノート：

• validate_password.dictionaryの値は文字列で、1024 文字以内です。パスワードに存在してはならない単語のリストが含まれています。各単語はセミコロン ( ; ) で区切られます。
• ディクショナリ チェックでは大文字と小文字が区別されません。

パスワード複雑度チェックの例

システム変数validate_password.enableがONに設定されている場合、TiDB はパスワードの複雑さのチェックを有効にします。チェック結果の例を次に示します。

TiDB は、ユーザーの平文パスワードをデフォルトのパスワード複雑度ポリシーと照合してチェックします。設定されたパスワードがポリシーを満たさない場合、パスワードは拒否されます。

mysql> ALTER USER 'test'@'localhost' IDENTIFIED BY 'abc';
ERROR 1819 (HY000): Require Password Length: 8

TiDB は、ハッシュされたパスワードをパスワードの複雑さのポリシーに照らしてチェックしません。

mysql> ALTER USER 'test'@'localhost' IDENTIFIED WITH mysql_native_password AS '*0D3CED9BEC10A777AEC23CCC353A8C08A633045E';
Query OK, 0 rows affected (0.01 sec)

最初にロックされたアカウントを作成するときは、パスワードの複雑さのポリシーに一致するパスワードも設定する必要があります。そうしないと、作成に失敗します。

mysql> CREATE USER 'user02'@'localhost' ACCOUNT LOCK;
ERROR 1819 (HY000): Require Password Length: 8

パスワード強度検証機能

パスワードの強度を確認するには、 VALIDATE_PASSWORD_STRENGTH()関数を使用できます。この関数はパスワード引数を受け入れ、0 (弱い) から 100 (強い) までの整数を返します。

ノート：

この関数は、現在のパスワードの複雑さのポリシーに基づいてパスワードの強度を評価します。パスワードの複雑さのポリシーが変更された場合、同じパスワードでも異なる評価結果が得られる可能性があります。

次の例は、 VALIDATE_PASSWORD_STRENGTH()関数の使用方法を示しています。

mysql> SELECT VALIDATE_PASSWORD_STRENGTH('weak');
+------------------------------------+
| VALIDATE_PASSWORD_STRENGTH('weak') |
+------------------------------------+
|                                 25 |
+------------------------------------+
1 row in set (0.01 sec)

mysql> SELECT VALIDATE_PASSWORD_STRENGTH('lessweak$_@123');
+----------------------------------------------+
| VALIDATE_PASSWORD_STRENGTH('lessweak$_@123') |
+----------------------------------------------+
|                                           50 |
+----------------------------------------------+
1 row in set (0.01 sec)

mysql> SELECT VALIDATE_PASSWORD_STRENGTH('N0Tweak$_@123!');
+----------------------------------------------+
| VALIDATE_PASSWORD_STRENGTH('N0Tweak$_@123!') |
+----------------------------------------------+
|                                          100 |
+----------------------------------------------+
1 row in set (0.01 sec)

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

TiDB は、パスワードのセキュリティを向上させるためにユーザーが定期的にパスワードを変更する必要があるように、パスワード有効期限ポリシーの構成をサポートしています。アカウントのパスワードを手動で期限切れにするか、自動パスワード期限切れのポリシーを確立できます。

自動パスワード有効期限ポリシーは、グローバル レベルおよびアカウント レベルで設定できます。データベース管理者は、グローバル レベルで自動パスワード有効期限ポリシーを確立し、アカウント レベルのポリシーを使用してグローバル ポリシーを上書きすることもできます。

パスワードの有効期限ポリシーを設定する権限は次のとおりです。

• SUPERまたはCREATE USER権限を持つデータベース管理者は、手動でパスワードを期限切れにすることができます。
• SUPERつまたはCREATE USER権限を持つデータベース管理者は、アカウント レベルのパスワード有効期限ポリシーを設定できます。
• SUPERつまたはSYSTEM_VARIABLES_ADMINR権限を持つデータベース管理者は、グローバル レベルのパスワード有効期限ポリシーを設定できます。

手動有効期限

アカウントのパスワードを手動で期限切れにするには、 CREATE USERまたはALTER USERステートメントを使用します。

ALTER USER 'test'@'localhost' PASSWORD EXPIRE;

データベース管理者によってアカウントのパスワードが期限切れになるように設定されている場合、TiDB にログインする前にパスワードを変更する必要があります。手動の有効期限は取り消すことができません。

CREATE ROLEステートメントを使用して作成されたロールの場合、ロールはパスワードを必要としないため、ロールのパスワード フィールドは空です。このような場合、TiDB はpassword_expired属性を'Y'に設定します。これは、ロールのパスワードが手動で期限切れになることを意味します。この設計の目的は、役割がロック解除され、空のパスワードで TiDB にログインされるのを防ぐことです。 ALTER USER ... ACCOUNT UNLOCKステートメントによってロールがロック解除されると、パスワードが空であっても、このアカウントでログインできます。したがって、TiDB はpassword_expired属性を使用してパスワードを手動で期限切れにするため、ユーザーはアカウントに有効なパスワードを設定する必要があります。

mysql> CREATE ROLE testrole;
Query OK, 0 rows affected (0.01 sec)

mysql> SELECT user,password_expired,Account_locked FROM mysql.user WHERE user = 'testrole';
+----------+------------------+----------------+
| user     | password_expired | Account_locked |
+----------+------------------+----------------+
| testrole | Y                | Y              |
+----------+------------------+----------------+
1 row in set (0.02 sec)

自動有効期限

パスワードの自動有効期限は、パスワードの経過時間とパスワードの有効期間に基づいています。

• パスワード経過時間: パスワードの最終変更日から現在の日付までの時間間隔。最後にパスワードが変更された時刻は、 mysql.userシステム テーブルに記録されます。
• パスワードの有効期間: パスワードを使用して TiDB にログインできる日数。

パスワードが有効期限を超えて使用された場合、サーバーは自動的にパスワードを期限切れとして扱います。

TiDB は、グローバル レベルおよびアカウント レベルでの自動パスワード有効期限をサポートしています。

• 世界レベル

  システム変数default_password_lifetimeを設定して、パスワードの有効期間を制御できます。デフォルト値0は、パスワードが無期限であることを示します。このシステム変数が正の整数Nに設定されている場合、パスワードの有効期間はN日間であり、 N日ごとにパスワードを変更する必要があることを意味します。

  グローバル自動パスワード有効期限ポリシーは、アカウント レベルのオーバーライドを持たないすべてのアカウントに適用されます。

  次の例では、パスワードの有効期間が 180 日のグローバル自動パスワード有効期限ポリシーを確立します。

  SET GLOBAL default_password_lifetime = 180;
  

• アカウントレベル

  個々のアカウントの自動パスワード有効期限ポリシーを確立するには、 CREATE USERまたはALTER USERステートメントでPASSWORD EXPIREオプションを使用します。

  次の例では、ユーザー パスワードを 90 日ごとに変更する必要があります。

  CREATE USER 'test'@'localhost' PASSWORD EXPIRE INTERVAL 90 DAY;
  ALTER USER 'test'@'localhost' PASSWORD EXPIRE INTERVAL 90 DAY;
  

  次の例では、個々のアカウントの自動パスワード有効期限ポリシーを無効にします。

  CREATE USER 'test'@'localhost' PASSWORD EXPIRE NEVER;
  ALTER USER 'test'@'localhost' PASSWORD EXPIRE NEVER;
  

  指定したアカウントのアカウント レベルの自動パスワード有効期限ポリシーを削除して、グローバル自動パスワード有効期限ポリシーに従うようにします。

  CREATE USER 'test'@'localhost' PASSWORD EXPIRE DEFAULT;
  ALTER USER 'test'@'localhost' PASSWORD EXPIRE DEFAULT;
  

パスワードの有効期限チェックの仕組み

クライアントが TiDBサーバーに接続すると、サーバーは次の順序でパスワードの有効期限が切れているかどうかを確認します。

1. サーバーは、パスワードが手動で期限切れとして設定されているかどうかを確認します。
2. パスワードの有効期限が手動で切れていない場合、サーバーは、パスワードの有効期間が構成された有効期間よりも長いかどうかを確認します。その場合、サーバーはパスワードを期限切れとして扱います。

期限切れのパスワードを処理する

パスワードの有効期限に対する TiDBサーバーの動作を制御できます。パスワードの有効期限が切れると、サーバーはクライアントを切断するか、クライアントを「サンドボックス モード」に制限します。 「サンドボックス モード」では、TiDBサーバーは期限切れのアカウントからの接続を許可します。ただし、このような接続では、ユーザーはパスワードのリセットのみが許可されます。

TiDBサーバーは、 「サンドボックス モード」で有効期限が切れたパスワードを持つユーザーを制限するかどうかを制御できます。パスワードの有効期限が切れたときの TiDBサーバーの動作を制御するには、TiDB 構成ファイルでsecurity.disconnect-on-expired-passwordパラメーターを構成します。

[security]
disconnect-on-expired-password = true

• disconnect-on-expired-passwordがtrue (デフォルト) に設定されている場合、パスワードの有効期限が切れると、サーバーはクライアントを切断します。
• disconnect-on-expired-passwordがfalseに設定されている場合、サーバーは「サンドボックス モード」を有効にし、ユーザーがサーバーに接続できるようにします。ただし、ユーザーはパスワードをリセットすることしかできません。パスワードがリセットされると、ユーザーは通常どおり SQL ステートメントを実行できます。

disconnect-on-expired-passwordが有効な場合、アカウントのパスワードの有効期限が切れている場合、TiDB はそのアカウントからの接続を拒否します。このような場合、次の方法でパスワードを変更できます。

• 通常のアカウントのパスワードの有効期限が切れている場合、管理者は SQL ステートメントを使用してアカウントのパスワードを変更できます。
• 管理者アカウントのパスワードの有効期限が切れている場合、別の管理者が SQL ステートメントを使用してアカウントのパスワードを変更できます。
• 管理者アカウントのパスワードの有効期限が切れており、パスワードの変更を手伝ってくれる管理者が他にいない場合は、 skip-grant-tableメカニズムを使用してアカウントのパスワードを変更できます。詳細については、 パスワードを忘れた場合の手続きを参照してください。

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

TiDB は、以前のパスワードの再利用を制限できます。パスワードの再利用ポリシーは、パスワードの変更回数または経過時間、またはその両方に基づくことができます。

パスワードの再利用ポリシーは、グローバル レベルとアカウント レベルで設定できます。グローバル レベルでパスワード再利用ポリシーを確立し、アカウント レベルのポリシーを使用してグローバル ポリシーをオーバーライドすることもできます。

TiDB はアカウントのパスワード履歴を記録し、履歴からの新しいパスワードの選択を制限します。

• パスワードの再利用ポリシーがパスワードの変更回数に基づいている場合、新しいパスワードは、指定された数の最近のパスワードのいずれとも同じであってはなりません。たとえば、パスワード変更の最小回数が3に設定されている場合、新しいパスワードを以前の 3 つのパスワードのいずれとも同じにすることはできません。
• パスワードの再利用ポリシーが経過時間に基づいている場合、新しいパスワードは、指定された日数内に使用されたパスワードと同じであってはなりません。たとえば、パスワードの再利用間隔が60に設定されている場合、新しいパスワードを過去 60 日間に使用されたパスワードと同じにすることはできません。

ノート：

空のパスワードはパスワード履歴に記録されず、いつでも再利用できます。

グローバルレベルのパスワード再利用ポリシー

グローバルなパスワード再利用ポリシーを確立するには、 password_historyおよびpassword_reuse_intervalシステム変数を使用します。

たとえば、過去 6 回のパスワードと過去 365 日以内に使用されたパスワードの再利用を禁止するグローバル パスワード再利用ポリシーを確立するには、次のようにします。

SET GLOBAL password_history = 6;
SET GLOBAL password_reuse_interval = 365;

グローバル パスワード再利用ポリシーは、アカウント レベルのオーバーライドを持たないすべてのアカウントに適用されます。

アカウント レベルのパスワード再利用ポリシー

アカウント レベルのパスワード再利用ポリシーを確立するには、 CREATE USERまたはALTER USERステートメントでPASSWORD HISTORYおよびPASSWORD REUSE INTERVALオプションを使用します。

例えば：

過去 5 回のパスワードの再利用を禁止するには:

CREATE USER 'test'@'localhost' PASSWORD HISTORY 5;
ALTER USER 'test'@'localhost' PASSWORD HISTORY 5;

過去 365 日以内に使用されたパスワードの再利用を禁止するには:

CREATE USER 'test'@'localhost' PASSWORD REUSE INTERVAL 365 DAY;
ALTER USER 'test'@'localhost' PASSWORD REUSE INTERVAL 365 DAY;

2 種類の再利用ポリシーを組み合わせるには、 PASSWORD HISTORYとPASSWORD REUSE INTERVALの両方を使用します。

CREATE USER 'test'@'localhost'
  PASSWORD HISTORY 5
  PASSWORD REUSE INTERVAL 365 DAY;
ALTER USER 'test'@'localhost'
  PASSWORD HISTORY 5
  PASSWORD REUSE INTERVAL 365 DAY;

指定したアカウントのアカウント レベルのパスワード再利用ポリシーを削除して、グローバル パスワード再利用ポリシーに従うようにするには:

CREATE USER 'test'@'localhost'
  PASSWORD HISTORY DEFAULT
  PASSWORD REUSE INTERVAL DEFAULT;
ALTER USER 'test'@'localhost'
  PASSWORD HISTORY DEFAULT
  PASSWORD REUSE INTERVAL DEFAULT;

ノート：

• パスワード再利用ポリシーを複数回設定すると、最後に設定した値が有効になります。
• PASSWORD HISTORYおよびPASSWORD REUSE INTERVALオプションのデフォルト値は 0 です。これは、再利用ポリシーが無効になっていることを意味します。
• ユーザー名を変更すると、TiDB はmysql.password_historyシステム テーブル内の対応するパスワード履歴を元のユーザー名から新しいユーザー名に移行します。

ログイン失敗の追跡と一時的なアカウント ロック ポリシー

TiDB は、アカウントのログイン試行の失敗回数を追跡できます。パスワードがブルート フォースによってクラックされるのを防ぐために、TiDB はログイン試行が指定回数失敗した後にアカウントをロックできます。

ノート：

• TiDB は、グローバル レベルではなく、アカウント レベルでの失敗したログインの追跡と一時的なアカウント ロックのみをサポートします。
• ログイン失敗とは、クライアントが接続の試行中に正しいパスワードを提供できなかったことを意味し、不明なユーザーまたはネットワークの問題による接続の失敗は含まれません。
• アカウントの失敗したログインの追跡と一時的なアカウント ロックを有効にすると、アカウントがログインを試みるときに、アカウントは追加のチェックの対象となります。これは、特に同時実行性の高いログイン シナリオで、ログイン操作のパフォーマンスに影響します。

ログイン失敗追跡ポリシーを構成する

CREATE USERまたはALTER USERステートメントでFAILED_LOGIN_ATTEMPTSおよびPASSWORD_LOCK_TIMEオプションを使用して、ログイン試行の失敗回数と各アカウントのロック時間を構成できます。使用可能な値のオプションは次のとおりです。

• FAILED_LOGIN_ATTEMPTS : N。ログインにN連続して失敗すると、アカウントは一時的にロックされます。 N の値の範囲は 0 ～ 32767 です。
• PASSWORD_LOCK_TIME : N |無制限。
  • N は、連続してログインに失敗すると、アカウントがN日間一時的にロックされることを意味します。 N の値の範囲は 0 ～ 32767 です。
  • UNBOUNDED 、ロック時間が無制限であり、アカウントを手動でロック解除する必要があることを意味します。 N の値の範囲は 0 ～ 32767 です。

ノート：

• 1 つの SQL ステートメントで構成できるのはFAILED_LOGIN_ATTEMPTSまたはPASSWORD_LOCK_TIMEだけです。この場合、アカウントのロックは有効になりません。
• アカウントのロックは、 FAILED_LOGIN_ATTEMPTSとPASSWORD_LOCK_TIME両方が 0 でない場合にのみ有効です。

アカウント ロック ポリシーは次のように構成できます。

ユーザーを作成し、アカウント ロック ポリシーを構成します。パスワードを 3 回連続で間違えると、アカウントが 3 日間一時的にロックされます。

CREATE USER 'test1'@'localhost' IDENTIFIED BY 'password' FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LOCK_TIME 3;

既存のユーザーのアカウント ロック ポリシーを変更します。パスワードが 4 回連続して間違って入力されると、アカウントは手動でロック解除されるまで無期限にロックされます。

ALTER USER 'test2'@'localhost' FAILED_LOGIN_ATTEMPTS 4 PASSWORD_LOCK_TIME UNBOUNDED;

既存のユーザーのアカウント ロック ポリシーを無効にします。

ALTER USER 'test3'@'localhost' FAILED_LOGIN_ATTEMPTS 0 PASSWORD_LOCK_TIME 0;

ロックされたアカウントのロックを解除する

次のシナリオでは、連続したパスワード エラーの数をリセットできます。

• ALTER USER ... ACCOUNT UNLOCKステートメントを実行すると。
• 正常にログインできたら.

次のシナリオでは、ロックされたアカウントのロックを解除できます。

• ロック時間が終了すると、次回のログイン試行時にアカウントの自動ロック フラグがリセットされます。
• ALTER USER ... ACCOUNT UNLOCKステートメントを実行すると。

ノート：

連続してログインに失敗したためにアカウントがロックされた場合、アカウント ロック ポリシーを変更すると、次のような影響があります。

• FAILED_LOGIN_ATTEMPTSを変更しても、アカウントのロック状態は変わりません。変更されたFAILED_LOGIN_ATTEMPTSアカウントのロックが解除され、再度ログインが試行された後に有効になります。
• PASSWORD_LOCK_TIMEを変更しても、アカウントのロック状態は変わりません。アカウントが再度ログインを試みると、変更されたPASSWORD_LOCK_TIME有効になります。その際、TiDB は新しいロック時間に達したかどうかをチェックします。はいの場合、TiDB はユーザーのロックを解除します。