クライアントが MySQL サーバーに接続すると、サーバーはクライアントおよびクライアントホストによって指定されたユーザー名を使用して、mysql.user システムテーブルから適切なアカウント行を選択します。 次に、サーバーはクライアントを認証し、どの認証プラグインがクライアントに適用されるかをアカウント行から決定します:
サーバーがプラグインを検出できない場合は、エラーが発生し、接続の試行は拒否されます。
それ以外の場合、サーバーはそのプラグインを呼び出してユーザーを認証し、ユーザーが正しいパスワードを指定して接続を許可されているかどうかを示すステータスをサーバーに返します。
プラガブル認証により、次の重要な機能が有効になります:
認証方式の選択. プラガブル認証を使用すると、DBA は個々の MySQL アカウントに使用される認証方式を簡単に選択および変更できます。
外部認証. プラガブル認証を使用すると、クライアントは、
mysql.userシステムテーブル以外の場所に資格証明を格納する認証方法に適した資格証明を使用して MySQL サーバーに接続できます。 たとえば、PAM、Windows のログイン ID、LDAP、Kerberos などの外部認証方式を使用するプラグインを作成できます。プロキシユーザー: ユーザーが接続を許可されている場合、認証プラグインは接続ユーザーの名前とは異なるユーザー名をサーバーに返して、接続ユーザーが別のユーザー (プロキシユーザー) のプロキシであることを示すことができます。 接続が継続している間、プロキシユーザーはアクセス制御のためにプロキシユーザーの権限を持つものとして扱われます。 実際に、あるユーザーは別のユーザーを偽装します。 詳細については、セクション6.2.18「プロキシユーザー」を参照してください。
--skip-grant-tables オプションを付けてサーバーを起動した場合、サーバーはクライアント認証を実行せず、任意のクライアントが接続することを許可するため、認証プラグインはロードされたとしても使用されません。 これはセキュアではないため、--skip-grant-tables オプションを使用してサーバーを起動すると、skip_networking を有効にしてリモート接続も無効になります。
MySQL 8.0 には次の認証プラグインが用意されています:
ネイティブ認証を実行するプラグイン。つまり、MySQL でプラガブル認証が導入される前から使用されているパスワードハッシュ方式に基づく認証です。
mysql_native_passwordプラグインは、このネイティブパスワードハッシュ方式に基づいて認証を実装します。 セクション6.4.1.1「ネイティブプラガブル認証」を参照してください。SHA-256 パスワードハッシュを使用して認証を実行するプラグイン。 これは、ネイティブ認証で実現できるよりも強力な暗号化です。 セクション6.4.1.3「SHA-256 プラガブル認証」およびセクション6.4.1.2「SHA-2 プラガブル認証のキャッシュ」を参照してください。
ハッシュ化または暗号化を行わずに、サーバーにパスワードを送信するクライアント側のプラグイン。 このプラグインは、クライアントユーザーが指定したパスワードに正確にアクセスする必要があるサーバー側プラグインと組み合わせて使用されます。 セクション6.4.1.4「クライアント側クリアテキストプラガブル認証」を参照してください。
PAM (Pluggable Authentication Modules) を使用して外部認証を実行し、MySQL Server が PAM を使用して MySQL ユーザーを認証できるようにするプラグイン。 このプラグインでは、プロキシユーザーもサポートされています。 セクション6.4.1.5「PAM プラガブル認証」を参照してください。
Windows で外部認証を実行するプラグイン。これを使用すると、MySQL サーバーがネイティブの Windows サービスを使用して、クライアント接続を認証できます。 Windows にログインしたユーザーは、追加のパスワードを指定せずに、自分の環境内の情報に基づいて MySQL クライアントプログラムからサーバーに接続できます。 このプラグインでは、プロキシユーザーもサポートされています。 セクション6.4.1.6「Windows プラガブル認証」を参照してください。
LDAP (Lightweight Directory Access Protocol) を使用して認証を実行し、X.500 などのディレクトリサービスにアクセスして MySQL ユーザーを認証するプラグイン。 これらのプラグインは、プロキシユーザーもサポートしています。 セクション6.4.1.7「LDAP プラガブル認証」を参照してください。
それを使用するアカウントへのすべてのクライアント接続を妨げるプラグイン。 このプラグインのユースケースには、直接ログインを許可しないが、通常のユーザーに権限を公開せずに昇格された権限を持つストアドプログラムおよびビューを実行できる必要があるプロキシアカウントおよびアカウントを介してのみアクセスされるプロキシアカウントが含まれます。 セクション6.4.1.8「ログインなしのプラガブル認証」を参照してください。
Unix ソケットファイルを使用してローカルホストから接続するクライアントを認証するプラグイン。 セクション6.4.1.9「ソケットピア資格証明プラガブル認証」を参照してください。
アカウント資格証明をチェックし、成功または失敗をサーバーエラーログに記録するテストプラグイン。 このプラグインは、テストおよび開発のために、認証プラグインを作成する方法を示す例として使用されます。 セクション6.4.1.10「プラガブル認証のテスト」を参照してください。
プラガブル認証の使用に対する現在の制約 (どのコネクタがどのプラグインをサポートしているのかなど) については、プラガブルな認証の制約を参照してください。
サードパーティー製コネクタの開発者は、コネクタがプラガブル認証機能を活用できる範囲と、より準拠させるために実行する手順を確認するために、そのセクションを読むべきです。
独自の認証プラグインを作成することに関心がある場合は、Writing Authentication Pluginsを参照してください。
このセクションでは、認証プラグインをインストールおよび使用するための一般的な手順を示します。 特定のプラグインに固有の手順については、セクション6.4.1「認証プラグイン」 でそのプラグインについて説明しているセクションを参照してください。
通常、プラガブル認証では、サーバー側とクライアント側で対応するプラグインのペアが使用されるため、次のような特定の認証方法を使用します:
必要に応じて、適切なプラグインを含むプラグインライブラリをインストールします。 サーバーがサーバーホストを使用してクライアント接続を認証できるように、サーバー側プラグインを含むライブラリをインストールします。 同様に、クライアントホストごとに、クライアントプログラムで使用するクライアント側プラグインを含むライブラリをインストールします。 組込みの認証プラグインをインストールする必要はありません。
作成する MySQL アカウントごとに、認証に使用する適切なサーバー側プラグインを指定します。 アカウントがデフォルトの認証プラグインを使用する場合、account-creation ステートメントでプラグインを明示的に指定する必要はありません。
default_authentication_pluginシステム変数は、デフォルトの認証プラグインを構成します。クライアントが接続すると、サーバー側プラグインはクライアントプログラムに認証に使用するクライアント側プラグインを通知します。
アカウントがサーバーとクライアントプログラムの両方のデフォルトの認証方式を使用している場合、サーバーはクライアント側のプラグインが使用するクライアントと通信する必要はなく、クライアント/サーバーのネゴシエーションでラウンドトリップを回避できます。
mysql や mysqladmin などの標準 MySQL クライアントの場合、--default-auth= オプションは、プログラムが使用できるクライアント側プラグインに関するヒントとしてコマンド行で指定できますが、ユーザーアカウントに関連付けられたサーバー側プラグインが異なるクライアント側プラグインを必要とする場合、サーバーはこれをオーバーライドします。
plugin_name
クライアントプログラムがクライアント側プラグインライブラリファイルを見つけられない場合は、プラグインライブラリディレクトリの場所を示す --plugin-dir= オプションを指定します。
dir_name
プラガブル認証を使用すると、MySQL アカウントの認証方式を柔軟に選択できますが、クライアントとサーバー間の認証プラグインの非互換性のためにクライアント接続を確立できない場合があります。
特定のサーバー上の特定のアカウントへのクライアント接続を成功させるための一般的な互換性の原則は、クライアントとサーバーの両方がアカウントに必要な認証 method をサポートしている必要があることです。 認証方式は認証プラグインによって実装されるため、クライアントとサーバーは両方ともアカウントに必要な認証 plugin をサポートする必要があります。
認証プラグインの非互換性は様々な方法で発生する可能性があります。 例:
5.7.22 以下の MySQL 5.7 クライアントを使用して、
caching_sha2_passwordで認証される MySQL 8.0 サーバーアカウントに接続します。 MySQL 8.0 で導入されたプラグインが 5.7 クライアントで認識されないため、これは失敗します。 (この問題は、caching_sha2_passwordクライアント側サポートが MySQL クライアントライブラリおよびクライアントプログラムに追加されたときに、5.7.23 の時点で MySQL 5.7 で対処されます。)MySQL 5.5 クライアントを使用して、
sha256_passwordで認証される MySQL 5.6 サーバーアカウントに接続します。 MySQL 5.6 で導入されたプラグインが 5.5 クライアントで認識されないため、これは失敗します。MySQL 5.7 クライアントを使用して、
mysql_old_passwordで認証する 5.7 より前のサーバーアカウントに接続します。 これは、複数の理由で失敗します。 まず、このような接続には--secure-auth=0が必要ですが、これはサポートされなくなりました。 サポートされていても、5.7 クライアントは MySQL 5.7 で削除されたため、プラグインを認識しません。Community ディストリビューションの MySQL 5.7 クライアントを使用して、エンタープライズ専用 LDAP 認証プラグインのいずれかを使用して認証する MySQL 5.7 Enterprise サーバーアカウントに接続します。 Community クライアントに Enterprise プラグインへのアクセス権がないため、これは失敗します。
一般に、これらの互換性の問題は、同じ MySQL ディストリビューションのクライアントとサーバー間で接続が確立された場合には発生しません。 異なる MySQL シリーズのクライアントとサーバーの間で接続が行われると、問題が発生する可能性があります。 これらの問題は、MySQL で新しい認証プラグインが導入されたとき、または古い認証プラグインが削除されたときに、開発プロセスに固有です。 非互換性の可能性を最小限に抑えるには、サーバー、クライアントおよびコネクタを適時に定期的にアップグレードします。
MySQL クライアント/サーバープロトコルの様々な実装が存在します。 libmysqlclient C API クライアントライブラリは実装の一例です。 一部の MySQL コネクタ (通常は C で記述されていないコネクタ) では、独自の実装が提供されます。 ただし、すべてのプロトコル実装が同じ方法でプラグイン認証を処理するわけではありません。 このセクションでは、プロトコル実装者が考慮する必要がある認証の問題について説明します。
クライアント/サーバープロトコルでは、サーバーはデフォルトとみなす認証プラグインをクライアントに接続するように指示します。 クライアントが使用するプロトコル実装がデフォルトのプラグインをロードしようとし、そのプラグインがクライアント側に存在しない場合、ロード操作は失敗します。 これは、デフォルトのプラグインが、クライアントが接続しようとしているアカウントに実際に必要なプラグインではない場合、不要な障害です。
クライアント/サーバープロトコルの実装にデフォルトの認証プラグインの独自の概念がなく、サーバーによって指定されたデフォルトのプラグインを常にロードしようとすると、そのプラグインが使用できない場合はエラーで失敗します。
この問題を回避するには、クライアントで使用されるプロトコル実装に独自のデフォルトプラグインがあり、最初の選択肢として使用する必要があります (または、サーバーで指定されたデフォルトプラグインのロードに失敗した場合は、このデフォルトにフォールバックします)。 例:
MySQL 5.7 では、
libmysqlclientはmysql_native_passwordまたはmysql_options()のMYSQL_DEFAULT_AUTHオプションで指定されたプラグインのいずれかをデフォルトの選択として使用します。5.7 クライアントが 8.0 サーバーに接続しようとすると、サーバーは
caching_sha2_passwordをデフォルトの認証プラグインとして指定しますが、クライアントはmysql_native_passwordまたはMYSQL_DEFAULT_AUTHを介して指定された資格証明の詳細を送信します。クライアントがサーバーによって指定されたプラグインをロードするのは変更プラグインリクエストの場合のみですが、その場合はユーザーアカウントに応じて任意のプラグインを使用できます。 この場合、クライアントはプラグインのロードを試みる必要があり、そのプラグインが使用できない場合、エラーはオプションではありません。
このセクションの最初の部分では、セクション6.2.17「プラガブル認証」で説明しているプラガブルな認証フレームワークの適用基準に関する一般的な制約について説明します。 2 番目の部分では、サードパーティーコネクタ開発者が、コネクタがプラガブルな認証機能を利用できる範囲と、対応性を高めるために行うステップについて判断する方法について説明します。
ここで使用する「「ネイティブ認証」」という用語は、mysql.user システムテーブルに格納されているパスワードに対する認証を指します。 これは、プラガブルな認証が実装される前に古い MySQL Server で提供されていたものと同じ認証方法です。 「Windows ネイティブ認証」とは、Windows ネイティブ認証プラグイン (「Windows プラグイン」と略します) で実装された、すでに Windows にログインしているユーザーの資格証明を使用した認証を示します。
一般的なプラガブルな認証の制約
-
Connector/C++: このコネクタを使用するクライアントは、ネイティブ認証を使用するアカウントを介してのみサーバーに接続できます。
例外: コネクタは、
libmysqlclientに (静的ではなく) 動的にリンクするように構築された場合にプラガブルな認証をサポートし、最新バージョンのlibmysqlclientがインストールされている場合、またはコネクタが最新のlibmysqlclientに対してリンクするようにソースから再コンパイルされている場合にそのバージョンをロードします。サーバーからのデフォルトのサーバー側認証プラグインに関する情報を処理するコネクタの記述については、認証プラグインコネクタ - 書込みに関する考慮事項 を参照してください。
Connector/NET: Connector/NET を使用するクライアントは、ネイティブ認証または Windows ネイティブ認証を使用するアカウントを介してサーバーに接続できます。
Connector/PHP: このコネクタを使用するクライアントは、PHP 用の MySQL ネイティブドライバ (
mysqlnd) を使用してコンパイルされている場合、ネイティブ認証を使用するアカウントを通じてのみサーバーに接続できます。Windows ネイティブ認証: Windows プラグインを使用するアカウントを通じた接続は、Windows Domain セットアップを必要とします。 これがない場合、NTLM 認証が使用され、ローカル接続だけが可能になります。つまり、クライアントとサーバーを同じコンピュータ上で実行する必要があります。
プロキシユーザー: プロキシユーザーサポートは、プロキシユーザー機能を実装するプラグイン (つまり、接続しているユーザーの名前と異なるユーザー名を返す場合があるプラグイン) で認証されたアカウントを通じて、クライアントが接続できる範囲まで利用できます。 たとえば、PAM および Windows プラグインはプロキシユーザーをサポートしています。
mysql_native_passwordおよびsha256_password認証プラグインは、デフォルトではプロキシユーザーをサポートしていませんが、これを行うように構成できます。プロキシユーザーマッピングのサーバーサポート を参照してください。レプリケーション: レプリカは、ネイティブ認証を使用してレプリケーションユーザーアカウントを採用するだけでなく、必要なクライアント側プラグインが使用可能な場合は、非ネイティブ認証を使用するレプリケーションユーザーアカウントを介して接続することもできます。 プラグインは、
libmysqlclientに組み込まれている場合、デフォルトで利用できます。 それ以外の場合は、レプリカplugin_dirシステム変数で指定されたディレクトリのレプリカ側にプラグインをインストールする必要があります。FEDERATEDテーブル:FEDERATEDテーブルは、ネイティブ認証を使用するリモートサーバー上のアカウントを通じてのみリモートテーブルにアクセスできます。
プラガブルな認証とサードパーティーコネクタ
サードパーティーコネクタ開発者は、次のガイドラインを使用して、プラガブルな認証機能を利用するためのコネクタの準備と、対応性を高めるために行うステップについて判断できます。
-
変更が行われていない既存のコネクタは、ネイティブ認証を使用し、このコネクタを使用するクライアントは、ネイティブ認証を使用するアカウントを通じてのみサーバーに接続できます。 ただし、最新バージョンのサーバーに対してコネクタをテストして、このような接続が引き続き問題なく機能することを検証する必要があります。
例外: コネクタは、(静的ではなく) 動的に
libmysqlclientにリンクしている場合に、変更せずにプラガブルな認証を処理でき、最新バージョンのlibmysqlclientがインストールされている場合に、このバージョンをロードします。 -
プラガブルな認証機能を利用するには、
libmysqlclientベースのコネクタを、最新バージョンのlibmysqlclientに対して再リンクする必要があります。 これにより、コネクタは、現在libmysqlclientに組み込まれているクライアント側のプラグイン (PAM 認証に必要な平文プラグインや Windows ネイティブ認証に必要な Windows プラグインなど) を必要とするアカウントを通じた接続をサポートできるようになります。 現在のlibmysqlclientとのリンクによっても、コネクタは、デフォルトの MySQL プラグインディレクトリ (通常、ローカルサーバーのplugin_dirシステム変数のデフォルト値で指名されたディレクトリ) にインストールされたクライアント側にアクセスできるようになります。コネクタが動的に
libmysqlclientにリンクする場合、より新しいバージョンのlibmysqlclientがクライアントホストにインストールされていることと、コネクタが実行時にそれをロードすることを確認する必要があります。 コネクタが特定の認証方式をサポートする別の方法は、クライアント/サーバープロトコルに直接実装することです。Connector/NET は、このアプローチを使用して Windows ネイティブ認証をサポートします。
コネクタが、デフォルトのプラグインディレクトリとは異なるディレクトリから、クライアント側のプラグインをロードできる必要がある場合、クライアントユーザーがそのディレクトリを指定するための手段を実装する必要があります。 この候補としては、コネクタがディレクトリ名を取得できるコマンド行オプションまたは環境変数などがあります。 mysql や mysqladmin などの標準 MySQL クライアントプログラムは、
--plugin-dirオプションを実装します。 C API Client Plugin Interfaceも参照してください。コネクタでのプロキシユーザーのサポートは、このセクションで前述したように、コネクタがサポートする認証方式がプロキシユーザーを許可するかどうかによって異なります。