重要

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

TiDB クライアントとサーバーの間で TLS を有効にする

デフォルトでは、TiDB はサーバーとクライアント間の安全でない接続を許可します。これにより、チャネルトラフィックを監視するサードパーティは、サーバーとクライアントの間で送受信されるデータ (クエリコンテンツやクエリ結果など) を知り、場合によっては変更することができます。チャネルが信頼できない場合 (クライアントがパブリックネットワーク経由で TiDBサーバーに接続している場合など)、安全でない接続により情報漏洩が発生する可能性があります。この場合、セキュリティ上の理由から、TLS で保護された接続を要求することをお勧めします。

TiDBサーバーは、 TLS (Transport Layer Security) プロトコルに基づいた安全な接続をサポートしています。このプロトコルは MySQL の安全な接続と一致しており、MySQL クライアント、MySQL シェル、MySQL ドライバーなどの既存の MySQL クライアントによって直接サポートされています。 TLS は、SSL (セキュリティ Sockets Layer) と呼ばれることもあります。 SSL プロトコルには既知のセキュリティ脆弱性あるため、TiDB は SSL をサポートしません。 TiDB は、TLSv1.0、TLSv1.1、TLSv1.2、および TLSv1.3 のプロトコルをサポートします。

TLS で保護された接続が使用される場合、接続には次のセキュリティプロパティがあります。

機密性: トラフィックの平文は盗聴を避けるために暗号化されます。
整合性: トラフィックの平文は改ざんできません
認証: (オプション) クライアントはサーバーの ID を検証し、サーバーは中間者攻撃を回避するためにクライアントの ID を検証できます。

TLS で保護された接続を使用するには、まず TLS を有効にするように TiDBサーバーを構成する必要があります。次に、TLS を使用するようにクライアントアプリケーションを構成する必要があります。サーバーで TLS サポートが正しく構成されている場合、ほとんどのクライアントライブラリは TLS を自動的に有効にします。

MySQL と同様に、TiDB では、同じ TCP ポート上で TLS 接続と非 TLS 接続が可能です。 TLS が有効になっている TiDBサーバーの場合、暗号化された接続を通じて TiDBサーバーに安全に接続するか、暗号化されていない接続を使用するかを選択できます。次の方法を使用して、安全な接続の使用を要求できます。

すべてのユーザーに対して TiDBサーバーへの安全な接続を要求するようにシステム変数require_secure_transportを構成します。
ユーザーを作成する場合 ( create user )、または既存のユーザーを変更する場合 ( alter user ) にREQUIRE SSL指定します。これは、指定されたユーザーが TiDB にアクセスするために TLS 接続を使用する必要があることを指定します。ユーザーを作成する例を次に示します。
```
CREATE USER 'u1'@'%' IDENTIFIED BY 'my_random_password' REQUIRE SSL;
```

注記：
ログインユーザーがTiDB 証明書ベースのログイン認証使用して設定した場合、ユーザーは TiDB への暗号化された接続を有効にすることが暗黙的に要求されます。

安全な接続を使用するように TiDBサーバーを構成する

安全な接続を有効にするための関連パラメータについては、次の説明を参照してください。

auto-tls : 証明書の自動生成を有効にします (v5.2.0 以降)
ssl-cert : SSL証明書のファイルパスを指定します。
ssl-key : 証明書と一致する秘密キーを指定します
ssl-ca : (オプション) 信頼された CA 証明書のファイルパスを指定します。
tls-version : (オプション) 最小の TLS バージョンを指定します (例: 「TLSv1.2」)。

auto-tls安全な接続を許可しますが、クライアント証明書の検証は提供しません。証明書の検証と証明書の生成方法の制御については、以下のssl-cert 、 ssl-key 、およびssl-ca変数の構成に関するアドバイスを参照してください。

TiDBサーバーで独自の証明書を使用した安全な接続を有効にするには、TiDBサーバーの起動時に構成ファイルでssl-certとssl-keyの両方のパラメーターを指定する必要があります。クライアント認証にssl-caパラメータを指定することもできます ( 認証を有効にするを参照)。

パラメータで指定されたすべてのファイルは PEM (Privacy Enhanced Mail) 形式です。現在、TiDB はパスワードで保護された秘密キーのインポートをサポートしていないため、パスワードなしで秘密キーファイルを提供する必要があります。証明書または秘密キーが無効な場合、TiDBサーバーは通常どおり起動しますが、クライアントは TLS 接続を通じて TiDBサーバーに接続できません。

証明書パラメータが正しい場合、TiDB は起動時に"INFO"レベルのログにmysql protocol server secure connection is enabledを出力します。

TLS 接続を使用するように MySQL クライアントを構成する

MySQL 5.7以降のバージョンのクライアントは、デフォルトで TLS 接続の確立を試みます。サーバーがTLS 接続をサポートしていない場合は、自動的に暗号化されていない接続に戻ります。バージョン 5.7 より前の MySQL のクライアントは、デフォルトで非 TLS 接続を使用します。

次の--ssl-modeパラメータを使用して、クライアントの接続動作を変更できます。

--ssl-mode=REQUIRED : クライアントは TLS 接続を必要とします。サーバー側が TLS 接続をサポートしていない場合、接続を確立できません。
--ssl-modeパラメータがない場合: クライアントは TLS 接続の使用を試みますが、サーバー側が暗号化接続をサポートしていない場合、暗号化接続を確立できません。その後、クライアントは暗号化されていない接続を使用します。
--ssl-mode=DISABLED : クライアントは暗号化されていない接続を使用します。

MySQL 8.x クライアントには、このパラメータに加えて 2 つの SSL モードがあります。

--ssl-mode=VERIFY_CA : --ssl-caを必要とする CA に対してサーバーからの証明書を検証します。
--ssl-mode=VERIFY_IDENTITY : VERIFY_CAと同じですが、接続先のホスト名が証明書と一致するかどうかも検証します。

MySQL 5.7および MariaDB クライアント以前の場合、 --ssl-verify-server-certを使用してサーバー証明書の検証を有効にできます。

詳細については、MySQL の暗号化された接続のためのクライアント側のコンフィグレーションを参照してください。

認証を有効にする

TiDBサーバーまたは MySQL クライアントでssl-caパラメーターが指定されていない場合、クライアントまたはサーバーはデフォルトで認証を実行しないため、中間者攻撃を防ぐことができません。たとえば、クライアントは偽装されたクライアントに「安全に」接続する可能性があります。サーバーとクライアントで認証用のssl-caパラメーターを構成できます。通常、必要なのはサーバーの認証のみですが、セキュリティをさらに強化するためにクライアントを認証することもできます。

MySQL クライアントから TiDBサーバーを認証するには:
1. TiDBサーバーでssl-certおよびssl-keyパラメータを指定します。
2. MySQL クライアントで--ssl-caパラメータを指定します。
3. MySQLクライアントでは少なくとも--ssl-mode ～ VERIFY_CAを指定してください。
4. TiDBサーバーで構成された証明書 ( ssl-cert ) が、クライアント--ssl-caパラメーターで指定された CA によって署名されていることを確認してください。それ以外の場合、認証は失敗します。
TiDBサーバーから MySQL クライアントを認証するには:
1. TiDBサーバーでssl-cert 、およびssl-caパラメータssl-key指定します。
2. クライアントで--ssl-certおよび--ssl-keyパラメータを指定します。
3. サーバー構成の証明書とクライアント構成の証明書の両方が、サーバーによって指定されたssl-caによって署名されていることを確認してください。

相互認証を行うには、上記の両方の要件を満たす必要があります。

デフォルトでは、サーバーからクライアントへの認証はオプションです。 TLS ハンドシェイク中にクライアントが識別証明書を提示しなくても、TLS 接続は確立できます。ユーザーを作成するとき ( CREATE USER )、または既存のユーザーを変更するとき ( ALTER USER ) にREQUIRE x509を指定して、クライアントの認証を要求することもできます。ユーザーを作成する例を次に示します。

CREATE USER 'u1'@'%'  REQUIRE X509;

注記：
ログインユーザーがTiDB 証明書ベースのログイン認証使用して設定した場合、ユーザーは TiDB への TLS 接続を有効にすることが暗黙的に要求されます。

現在の接続で暗号化が使用されているかどうかを確認する

SHOW STATUS LIKE "%Ssl%";ステートメントを使用して、暗号化が使用されているかどうか、暗号化された接続で使用される暗号化プロトコル、TLS バージョン番号など、現在の接続の詳細を取得します。

暗号化された接続での結果の次の例を参照してください。結果は、クライアントがサポートする TLS バージョンまたは暗号化プロトコルによって異なります。

SHOW STATUS LIKE "Ssl%";

+-----------------------+------------------------------------------------------->
| Variable_name         | Value                                                 >
+-----------------------+------------------------------------------------------->
| Ssl_cipher            | TLS_AES_128_GCM_SHA256                                >
| Ssl_cipher_list       | RC4-SHA:DES-CBC3-SHA:AES128-SHA:AES256-SHA:AES128-SHA2>
| Ssl_server_not_after  | Apr 23 07:59:47 2024 UTC                              >
| Ssl_server_not_before | Jan 24 07:59:47 2024 UTC                              >
| Ssl_verify_mode       | 5                                                     >
| Ssl_version           | TLSv1.3                                               >
+-----------------------+------------------------------------------------------->
6 rows in set (0.0062 sec)

公式 MySQL クライアントの場合、 STATUSまたは\sステートメントを使用して接続ステータスを表示することもできます。

mysql> \s
...
SSL: Cipher in use is TLS_AES_128_GCM_SHA256
...

サポートされている TLS バージョン、キー交換プロトコル、および暗号化アルゴリズム

TiDB でサポートされる TLS バージョン、鍵交換プロトコル、および暗号化アルゴリズムは、公式 Go ライブラリによって決定されます。

オペレーティングシステムの暗号化ポリシーと使用しているクライアントライブラリも、サポートされるプロトコルと暗号スイートのリストに影響を与える可能性があります。

サポートされている TLS バージョン

TLSv1.0 (デフォルトでは無効)
TLSv1.1
TLSv1.2
TLSv1.3

tls-version構成オプションを使用すると、使用できる TLS バージョンを制限できます。

使用できる実際の TLS バージョンは、OS の暗号化ポリシー、MySQL クライアントのバージョン、およびクライアントで使用される SSL/TLS ライブラリによって異なります。

サポートされているキー交換プロトコルと暗号化アルゴリズム

TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256

証明書、キー、CA をリロードする

証明書、キー、または CA を置き換えるには、まず対応するファイルを置き換えてから、実行中の TiDB インスタンスでALTER INSTANCE RELOAD TLSステートメントを実行して、元の構成から証明書 ( ssl-cert )、キー ( ssl-key )、および CA ( ssl-ca ) を再ロードします。パス。この方法では、TiDB インスタンスを再起動する必要はありません。

新しくロードされた証明書、キー、および CA は、ステートメントが正常に実行された後に確立された接続で有効になります。ステートメントの実行前に確立された接続は影響を受けません。

監視

TiDB v5.2.0 以降、 Ssl_server_not_afterおよびSsl_server_not_beforeステータス変数を使用して、証明書の有効性の開始日と終了日を監視できます。

SHOW GLOBAL STATUS LIKE 'Ssl\_server\_not\_%';

+-----------------------+--------------------------+
| Variable_name         | Value                    |
+-----------------------+--------------------------+
| Ssl_server_not_after  | Nov 28 06:42:32 2021 UTC |
| Ssl_server_not_before | Aug 30 06:42:32 2021 UTC |
+-----------------------+--------------------------+
2 rows in set (0.0076 sec)

こちらも参照

TiDB コンポーネント間で TLS を有効にする。