MySQL 8.0 リファレンスマニュアル


6.4.1.2 SHA-2 プラガブル認証のキャッシュ

MySQL には、ユーザーアカウントパスワードの SHA-256 ハッシングを実装する次の 2 つの認証プラグインが用意されています:

  • sha256_password: 基本 SHA-256 認証を実装します。

  • caching_sha2_password: SHA-256 認証 (sha256_password など) を実装しますが、パフォーマンスを向上させるためにサーバー側でキャッシュを使用し、適用性を高めるための追加機能を備えています。

このセクションでは、キャッシュ SHA-2 認証プラグインについて説明します。 元の基本 (非キャッシュ) プラグインの詳細は、セクション6.4.1.3「SHA-256 プラガブル認証」 を参照してください。

重要

MySQL 8.0 では、caching_sha2_passwordmysql_native_password ではなくデフォルトの認証プラグインです。 サーバー操作に対するこの変更の影響、およびサーバーとクライアントおよびコネクタとの互換性の詳細は、優先認証プラグインとしての caching_sha2_password を参照してください。

重要

caching_sha2_password プラグインで認証されるアカウントを使用してサーバーに接続するには、このセクションで後述するように、RSA キーペアを使用したパスワード交換をサポートするセキュアな接続または暗号化されていない接続を使用する必要があります。 どちらの方法でも、caching_sha2_password プラグインは MySQL 暗号化機能を使用します。 セクション6.3「暗号化された接続の使用」を参照してください。

注記

sha256_password という名前の sha256 は、プラグインが暗号化に使用する 256 ビットのダイジェスト長を表します。 caching_sha2_password という名前では、sha2 はより一般的に暗号化アルゴリズムの SHA-2 クラスを指し、256 ビット暗号化は 1 つのインスタンスです。 後者の名前を選択すると、プラグイン名を変更せずに、可能性のあるダイジェスト長を将来拡張するための領域が残されます。

caching_sha2_password プラグインには、sha256_password と比較して次の利点があります:

  • サーバー側では、インメモリーキャッシュを使用すると、再接続時に以前に接続したユーザーの再認証を高速化できます。

  • RSA ベースのパスワード交換は、MySQL がリンクされている SSL ライブラリに関係なく使用できます。

  • Unix ソケットファイルおよび共有メモリープロトコルを使用するクライアント接続のサポートが提供されます。

次の表に、サーバー側とクライアント側のプラグイン名を示します。

表 6.13 SHA-2 認証用のプラグインおよびライブラリ名

プラグインまたはファイル プラグインまたはファイル名
サーバー側プラグイン caching_sha2_password
クライアント側プラグイン caching_sha2_password
ライブラリファイル なし (プラグインは組み込み済み)

次の各セクションでは、SHA-2 プラガブル認証のキャッシュに固有のインストールおよび使用方法について説明します:

MySQL のプラガブル認証に関する一般的な情報については、セクション6.2.17「プラガブル認証」を参照してください。

SHA-2 プラガブル認証のインストール

caching_sha2_password プラグインは、サーバーおよびクライアントフォームに存在します:

  • サーバー側のプラグインはサーバーに組み込まれているため、明示的にロードする必要はなく、アンロードしても無効にすることができません。

  • クライアント側プラグインは libmysqlclient クライアントライブラリに組み込まれており、libmysqlclient に対してリンクされているすべてのプログラムで使用できます。

サーバー側プラグインは、sha2_cache_cleaner 監査プラグインをヘルパーとして使用して、パスワードキャッシュ管理を実行します。caching_sha2_password と同様に、sha2_cache_cleaner は組み込まれており、インストールする必要はありません。

SHA-2 プラガブル認証の使用

SHA-256 パスワードハッシュ用の caching_sha2_password プラグインを使用するアカウントを設定するには、次のステートメントを使用します。ここで、password は目的のアカウントパスワードです:

CREATE USER 'sha2user'@'localhost'
IDENTIFIED WITH caching_sha2_password BY 'password';

サーバーは caching_sha2_password プラグインをアカウントに割り当て、それを使用して SHA-256 を使用してパスワードを暗号化し、mysql.user システムテーブルの plugin および authentication_string カラムにそれらの値を格納します。

前述の手順では、caching_sha2_password がデフォルトの認証プラグインであると想定していません。 caching_sha2_password がデフォルトの認証プラグインである場合は、より単純な CREATE USER 構文を使用できます。

デフォルトの認証プラグインを caching_sha2_password に設定してサーバーを起動するには、サーバーオプションファイルに次の行を入力します:

[mysqld]
default_authentication_plugin=caching_sha2_password

これにより、caching_sha2_password プラグインが新しいアカウントにデフォルトで使用されます。 その結果、プラグインに明示的に名前を付けずに、アカウントを作成してそのパスワードを設定できます:

CREATE USER 'sha2user'@'localhost' IDENTIFIED BY 'password';

default_authentication_plugincaching_sha2_password に設定した場合の別の結果は、アカウントの作成に他のプラグインを使用するには、そのプラグインを明示的に指定する必要があることです。 たとえば、mysql_native_password プラグインを使用するには、次のステートメントを使用します:

CREATE USER 'nativeuser'@'localhost'
IDENTIFIED WITH mysql_native_password BY 'password';

caching_sha2_password は、セキュアなトランスポートを介した接続をサポートしています。 このセクションで後述する RSA の構成手順に従うと、暗号化されていない RSA 接続を介した暗号化されたパスワード交換もサポートされます。 RSA サポートには、次の特性があります:

  • サーバー側では、RSA 秘密キーペアファイルと公開キーペアファイルに 2 つのシステム変数が指定されます: caching_sha2_password_private_key_path および caching_sha2_password_public_key_path。 使用するキーファイルの名前がシステム変数のデフォルト値と異なる場合、データベース管理者はサーバーの起動時にこれらの変数を設定する必要があります。

  • サーバーは、caching_sha2_password_auto_generate_rsa_keys システム変数を使用して RSA キーペアファイルを自動的に生成するかどうかを決定します。 セクション6.3.3「SSL および RSA 証明書とキーの作成」を参照してください。

  • Caching_sha2_password_rsa_public_key ステータス変数には、caching_sha2_password 認証プラグインで使用される RSA 公開キーの値が表示されます。

  • RSA 公開鍵を所有しているクライアントは、あとで説明するように、接続プロセス中にサーバーと RSA 鍵ペアベースのパスワード交換を実行できます。

  • caching_sha2_password および RSA 鍵ペアベースのパスワード交換で認証されるアカウントによる接続の場合、サーバーはデフォルトで RSA 公開鍵をクライアントに送信しません。 クライアントは、必要な公開キーのクライアント側コピーを使用するか、サーバーから公開キーをリクエストできます。

    公開キーの信頼できるローカルコピーを使用すると、クライアントはクライアント/サーバープロトコルでラウンドトリップを回避でき、サーバーから公開キーをリクエストするよりも安全です。 一方、サーバーから公開キーをリクエストする方が便利で (クライアント側ファイルの管理は不要)、セキュアなネットワーク環境で受け入れられる場合があります。

    • コマンドラインクライアントの場合は、--server-public-key-path オプションを使用して RSA 公開キーファイルを指定します。 --get-server-public-key オプションを使用して、サーバーから公開キーをリクエストします。 次のプログラムは、2 つのオプションをサポートしています: mysql, mysqlsh, mysqladmin, mysqlbinlog, mysqlcheck, mysqldump, mysqlimport, mysqlpump, mysqlshow, mysqlslap, mysqltest, mysql_upgrade

    • C API を使用するプログラムの場合は、mysql_options() をコールして、MYSQL_SERVER_PUBLIC_KEY オプションとファイル名を渡して RSA 公開キーファイルを指定するか、MYSQL_OPT_GET_SERVER_PUBLIC_KEY オプションを渡してサーバーから公開キーをリクエストします。

    • For replicas, use the CHANGE REPLICATION SOURCE TO statement (from MySQL 8.0.23) or CHANGE MASTER TO statement (before MySQL 8.0.23) with the SOURCE_PUBLIC_KEY_PATH | MASTER_PUBLIC_KEY_PATH option to specify the RSA public key file, or the GET_SOURCE_PUBLIC_KEY | GET_MASTER_PUBLIC_KEY option to request the public key from the source. グループレプリケーションの場合、group_replication_recovery_public_key_path および group_replication_recovery_get_public_key システム変数は同じ目的で使用されます。

    いずれの場合も、有効な公開キーファイルを指定するオプションが指定されている場合は、サーバーから公開キーをリクエストするオプションよりも優先されます。

caching_sha2_password プラグインを使用するクライアントの場合、サーバーへの接続時にパスワードがクリアテキストとして公開されることはありません。 パスワード転送の方法は、セキュアな接続と RSA 暗号化のどちらを使用するかによって異なります:

  • 接続がセキュアな場合、RSA キーペアは不要であり、使用されません。 これは、TLS を使用して暗号化された TCP 接続と、Unix ソケットファイルおよび共有メモリー接続に適用されます。 パスワードはクリアテキストとして送信されますが、接続がセキュアであるためスヌープできません。

  • 接続がセキュアでない場合は、RSA キーペアが使用されます。 これは、TLS および名前付きパイプ接続なしで暗号化されない TCP 接続に適用されます。 RSA は、パスワードのスヌーピングを防ぐために、クライアントとサーバー間のパスワード交換にのみ使用されます。 サーバーは、暗号化されたパスワードを受信すると復号化します。 繰り返し攻撃を防ぐために、スクランブルが暗号化で使用されます。

クライアント接続プロセス中にパスワード交換に RSA キーペアを使用できるようにするには、次の手順を使用します:

  1. セクション6.3.3「SSL および RSA 証明書とキーの作成」 の手順を使用して RSA 秘密キーと公開キーのペアのファイルを作成します。

  2. 秘密キーファイルと公開キーファイルがデータディレクトリにあり、private_key.pem および public_key.pem (caching_sha2_password_private_key_path および caching_sha2_password_public_key_path システム変数のデフォルト値) という名前である場合、サーバーはそれらを起動時に自動的に使用します。

    それ以外の場合、キーファイルに明示的に名前を付けるには、システム変数をサーバーオプションファイルのキーファイル名に設定します。 ファイルがサーバーデータディレクトリにある場合、ファイルのフルパス名を指定する必要はありません:

    [mysqld]
    caching_sha2_password_private_key_path=myprivkey.pem
    caching_sha2_password_public_key_path=mypubkey.pem

    キーファイルがデータディレクトリに配置されていない場合、またはキーファイルの場所をシステム変数値で明示的にする場合は、フルパス名を使用します:

    [mysqld]
    caching_sha2_password_private_key_path=/usr/local/mysql/myprivkey.pem
    caching_sha2_password_public_key_path=/usr/local/mysql/mypubkey.pem
  3. パスワード生成時に caching_sha2_password で使用されるハッシュ丸めの数を変更する場合は、caching_sha2_password_digest_rounds システム変数を設定します。 例:

    [mysqld]
    caching_sha2_password_digest_rounds=10000
  4. サーバーを再起動してから接続し、Caching_sha2_password_rsa_public_key ステータス変数値を確認します。 実際に表示される値は、次に示す値とは異なりますが、空でない必要があります:

    mysql> SHOW STATUS LIKE 'Caching_sha2_password_rsa_public_key'\G
    *************************** 1. row ***************************
    Variable_name: Caching_sha2_password_rsa_public_key
            Value: -----BEGIN PUBLIC KEY-----
    MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDO9nRUDd+KvSZgY7cNBZMNpwX6
    MvE1PbJFXO7u18nJ9lwc99Du/E7lw6CVXw7VKrXPeHbVQUzGyUNkf45Nz/ckaaJa
    aLgJOBCIDmNVnyU54OT/1lcs2xiyfaDMe8fCJ64ZwTnKbY2gkt1IMjUAB5Ogd5kJ
    g8aV7EtKwyhHb0c30QIDAQAB
    -----END PUBLIC KEY-----

    値が空の場合は、鍵ファイルに関するいくつかの問題がサーバーで見つかっています。 エラーログをチェックして、診断情報を確認してください。

RSA キーファイルを使用してサーバーを構成した後、caching_sha2_password プラグインで認証されるアカウントには、これらのキーファイルを使用してサーバーに接続するオプションがあります。 前述のように、このようなアカウントでは、セキュアな接続 (RSA が使用されない場合) または RSA を使用してパスワード交換を実行する暗号化されていない接続のいずれかを使用できます。 暗号化されていない接続が使用されるとします。 例:

shell> mysql --ssl-mode=DISABLED -u sha2user -p
Enter password: password

sha2user によるこの接続試行の場合、サーバーは caching_sha2_password が適切な認証プラグインであると判断し、それを呼び出します (CREATE USER 時に指定されたプラグインであるため)。 プラグインは、接続が暗号化されていないことを検出したため、RSA 暗号化を使用してパスワードを送信する必要があります。 ただし、サーバーは公開鍵をクライアントに送信せず、クライアントは公開鍵を提供しなかったため、パスワードを暗号化できず、接続に失敗します:

ERROR 2061 (HY000): Authentication plugin 'caching_sha2_password'
reported error: Authentication requires secure connection.

RSA 公開キーをサーバーにリクエストするには、--get-server-public-key オプションを指定します:

shell> mysql --ssl-mode=DISABLED -u sha2user -p --get-server-public-key
Enter password: password

この場合、サーバーは RSA 公開鍵をクライアントに送信し、クライアントはこの鍵を使用してパスワードを暗号化し、その結果をサーバーに返します。 プラグインは、サーバー側で RSA 秘密キーを使用してパスワードを復号化し、パスワードが正しいかどうかに基づいて接続を受け入れるか拒否します。

または、サーバーで必要な RSA 公開キーのローカルコピーを含むファイルがクライアントにある場合は、--server-public-key-path オプションを使用してファイルを指定できます:

shell> mysql --ssl-mode=DISABLED -u sha2user -p --server-public-key-path=file_name
Enter password: password

この場合、クライアントは公開キーを使用してパスワードを暗号化し、結果をサーバーに返します。 プラグインは、サーバー側で RSA 秘密キーを使用してパスワードを復号化し、パスワードが正しいかどうかに基づいて接続を受け入れるか拒否します。

--server-public-key-path オプションで指定されたファイル内の公開キー値は、caching_sha2_password_public_key_path システム変数で指定されたサーバー側ファイル内のキー値と同じである必要があります。 鍵ファイルに有効な公開鍵値が含まれているが、その値が正しくない場合は、アクセス拒否のエラーが発生します。 鍵ファイルに有効な公開鍵が含まれていない場合は、その鍵をクライアントプログラムで使用できません。

クライアントユーザーは、次の 2 つの方法で RSA 公開キーを取得できます:

  • データベース管理者は、公開鍵ファイルのコピーを提供できます。

  • 他の方法でサーバーに接続できるクライアントユーザーは、SHOW STATUS LIKE 'Caching_sha2_password_rsa_public_key'ステートメントを使用して、返されたキー値をファイルに保存できます。

SHA-2 プラガブル認証のキャッシュ操作

サーバー側では、caching_sha2_password プラグインはメモリー内キャッシュを使用して、以前に接続したクライアントの認証を高速化します。 エントリは、account-name/password-hash のペアで構成されます。 キャッシュは次のように機能します:

  1. クライアントが接続すると、caching_sha2_password はクライアントとパスワードが一部のキャッシュエントリと一致するかどうかを確認します。 その場合、認証は成功します。

  2. 一致するキャッシュエントリがない場合、プラグインは mysql.user システムテーブルの資格証明と照合してクライアントの検証を試みます。 これが成功すると、caching_sha2_password はクライアントのエントリをハッシュに追加します。 それ以外の場合、認証は失敗し、接続は拒否されます。

このように、クライアントが最初に接続すると、mysql.user システムテーブルに対する認証が行われます。 その後、クライアントが接続すると、キャッシュに対する認証が高速になります。

エントリの追加以外のパスワードキャッシュ操作は、caching_sha2_password の代わりに次のアクションを実行する sha2_cache_cleaner 監査プラグインによって処理されます:

  • 名前が変更または削除されたアカウント、または資格証明または認証プラグインが変更されたアカウントのキャッシュエントリがクリアされます。

  • FLUSH PRIVILEGES ステートメントの実行時にキャッシュを空にします。

  • サーバーの停止時にキャッシュを空にします。 (これは、サーバーの再起動後もキャッシュが永続しないことを意味します。)

キャッシュのクリア操作は、後続のクライアント接続の認証要件に影響します。 ユーザーアカウントごとに、次のいずれかの操作後のユーザーの最初のクライアント接続では、セキュアな接続 (TLS 資格証明、Unix ソケットファイルまたは共有メモリーを使用して TCP を使用して確立) または RSA キーペアベースのパスワード交換を使用する必要があります:

  • アカウントの作成後。

  • アカウントのパスワード変更後。

  • アカウントの RENAME USER の後。

  • FLUSH PRIVILEGES の後。

FLUSH PRIVILEGES はキャッシュ全体をクリアし、caching_sha2_password プラグインを使用するすべてのアカウントに影響します。 その他の操作では、特定のキャッシュエントリがクリアされ、操作の一部であるアカウントにのみ影響します。

ユーザーが正常に認証されると、アカウントに影響する別のキャッシュクリアイベントが発生するまで、アカウントはキャッシュに入力され、後続の接続にセキュアな接続または RSA キーペアは必要ありません。 (キャッシュを使用できる場合、サーバーはクリアテキストパスワード転送を使用せず、セキュアな接続を必要としないチャレンジレスポンスメカニズムを使用します。)


関連キーワード:  sha, サーバー, 認証, 接続, キー, caching, パスワード, アカウント, key, キャッシュ