ログインのための証明書ベースの認証
TiDB は、ユーザーが TiDB にログインするための証明書ベースの認証方法をサポートしています。この方法では、TiDB はさまざまなユーザーに証明書を発行し、暗号化された接続を使用してデータを転送し、ユーザーがログインするときに証明書を検証します。このアプローチは、MySQL ユーザーが一般的に使用する従来のパスワードベースの認証方法よりも安全であるため、ユーザー数の増加。
証明書ベースの認証を使用するには、次の操作を実行する必要がある場合があります。
- セキュリティ キーと証明書を作成する
- TiDB とクライアントの証明書を構成する
- ユーザーのログイン時に検証するユーザー証明書情報を構成する
- 証明書を更新して置き換える
ドキュメントの残りの部分では、これらの操作を実行する方法を詳しく紹介します。
セキュリティ キーと証明書を作成する
OpenSSLを使用してキーと証明書を作成することをお勧めします。証明書の生成プロセスは、 TiDB クライアントとサーバー間で TLS を有効にするで説明したプロセスと似ています。次の段落では、証明書で検証する必要があるその他の属性フィールドを構成する方法を示します。
OpenSSLを使用してキーと証明書を作成することをお勧めします。証明書の生成プロセスは、 TiDB クライアントとサーバー間で TLS を有効にするで説明したプロセスと似ています。次の段落では、証明書で検証する必要があるその他の属性フィールドを構成する方法を示します。
CA キーと証明書を生成する
次のコマンドを実行して、CA キーを生成します。
sudo openssl genrsa 2048 > ca-key.pem上記のコマンドの出力:
Generating RSA private key, 2048 bit long modulus (2 primes) ....................+++++ ...............................................+++++ e is 65537 (0x010001)次のコマンドを実行して、CA キーに対応する証明書を生成します。
sudo openssl req -new -x509 -nodes -days 365000 -key ca-key.pem -out ca-cert.pem詳細な証明書情報を入力します。例えば:
Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:California Locality Name (e.g. city) []:San Francisco Organization Name (e.g. company) [Internet Widgits Pty Ltd]:PingCAP Inc. Organizational Unit Name (e.g. section) []:TiDB Common Name (e.g. server FQDN or YOUR name) []:TiDB admin Email Address []:s@pingcap.comノート:
上記証明書詳細のうち、
:
以降が入力内容です。
サーバーキーと証明書を生成する
次のコマンドを実行して、サーバーキーを生成します。
sudo openssl req -newkey rsa:2048 -days 365000 -nodes -keyout server-key.pem -out server-req.pem詳細な証明書情報を入力します。例えば:
Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:California Locality Name (e.g. city) []:San Francisco Organization Name (e.g. company) [Internet Widgits Pty Ltd]:PingCAP Inc. Organizational Unit Name (e.g. section) []:TiKV Common Name (e.g. server FQDN or YOUR name) []:TiKV Test Server Email Address []:k@pingcap.com Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:次のコマンドを実行して、サーバーの RSA キーを生成します。
sudo openssl rsa -in server-key.pem -out server-key.pem上記のコマンドの出力:
writing RSA keyCA 証明書の署名を使用して、署名付きサーバー証明書を生成します。
sudo openssl x509 -req -in server-req.pem -days 365000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem上記のコマンドの出力 (例):
Signature ok subject=C = US, ST = California, L = San Francisco, O = PingCAP Inc., OU = TiKV, CN = TiKV Test Server, emailAddress = k@pingcap.com Getting CA Private Keyノート:
ログインすると、TiDB は上記の出力の
subject
セクションの情報が一致しているかどうかをチェックします。
クライアントキーと証明書を生成する
サーバーキーと証明書を生成したら、クライアントのキーと証明書を生成する必要があります。ユーザーごとに異なるキーと証明書を生成する必要があることがよくあります。
次のコマンドを実行して、クライアント キーを生成します。
sudo openssl req -newkey rsa:2048 -days 365000 -nodes -keyout client-key.pem -out client-req.pem詳細な証明書情報を入力します。例えば:
Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:California Locality Name (e.g. city) []:San Francisco Organization Name (e.g. company) [Internet Widgits Pty Ltd]:PingCAP Inc. Organizational Unit Name (e.g. section) []:TiDB Common Name (e.g. server FQDN or YOUR name) []:tpch-user1 Email Address []:zz@pingcap.com Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:次のコマンドを実行して、クライアントの RSA キーを生成します。
sudo openssl rsa -in client-key.pem -out client-key.pem上記のコマンドの出力:
writing RSA keyCA 証明書の署名を使用して、クライアント証明書を生成します。
sudo openssl x509 -req -in client-req.pem -days 365000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.pem上記のコマンドの出力 (例):
Signature ok subject=C = US, ST = California, L = San Francisco, O = PingCAP Inc., OU = TiDB, CN = tpch-user1, emailAddress = zz@pingcap.com Getting CA Private Keyノート:
上記の出力の
subject
セクションの情報は、require
セクションのログイン検証用の証明書構成に使用されます。
証明書を確認する
次のコマンドを実行して、証明書を確認します。
openssl verify -CAfile ca-cert.pem server-cert.pem client-cert.pem
証明書が検証されると、次の結果が表示されます。
server-cert.pem: OK
client-cert.pem: OK
証明書を使用するように TiDB とクライアントを構成する
証明書を生成したら、対応するサーバー証明書またはクライアント証明書を使用するように TiDBサーバーとクライアントを構成する必要があります。
サーバー証明書を使用するように TiDB を構成する
TiDB 構成ファイルの[security]
セクションを変更します。この手順では、CA 証明書、サーバーキー、およびサーバー証明書が格納されるディレクトリを指定します。 path/to/server-cert.pem
、 path/to/server-key.pem
、 path/to/ca-cert.pem
独自のディレクトリに置き換えることができます。
[security]
ssl-cert ="path/to/server-cert.pem"
ssl-key ="path/to/server-key.pem"
ssl-ca="path/to/ca-cert.pem"
TiDB を起動してログを確認します。ログに次の情報が表示されれば、構成は成功です。
[INFO] [server.go:264] ["secure connection is enabled"] ["client verification enabled"=true]
クライアント証明書を使用するようにクライアントを構成する
クライアントがログインにクライアント キーと証明書を使用するようにクライアントを構成します。
MySQL クライアントを例にとると、 ssl-cert
、 ssl-key
、およびssl-ca
を指定することで、新しく作成されたクライアント証明書、クライアント キー、および CA を使用できます。
mysql -utest -h0.0.0.0 -P4000 --ssl-cert /path/to/client-cert.new.pem --ssl-key /path/to/client-key.new.pem --ssl-ca /path/to/ca-cert.pem
ノート:
/path/to/client-cert.new.pem
、/path/to/client-key.new.pem
、および/path/to/ca-cert.pem
、CA 証明書、クライアント キー、およびクライアント証明書のディレクトリです。それらを独自のディレクトリに置き換えることができます。
ログイン検証用のユーザー証明書情報を構成する
まず、クライアントを使用して TiDB に接続し、ログイン認証を構成します。次に、検証するユーザー証明書情報を取得して構成できます。
ユーザー証明書情報を取得する
ユーザー証明書情報は、X509 証明書の属性を確認するために使用されるrequire subject
、 require issuer
、 require san
、およびrequire cipher
によって指定できます。
require subject
: ログイン時のクライアント証明書のsubject
情報を指定します。このオプションを指定すると、require ssl
や x509 の設定は不要です。指定する情報は、 クライアントキーと証明書を生成するで入力したsubject
情報と一致しています。このオプションを取得するには、次のコマンドを実行します。
openssl x509 -noout -subject -in client-cert.pem | sed 's/.\{8\}//' | sed 's/, /\//g' | sed 's/ = /=/g' | sed 's/^/\//'require issuer
: ユーザー証明書を発行するCA証明書のsubject
情報を指定します。指定する情報は、 CA キーと証明書を生成するで入力したsubject
情報と一致しています。このオプションを取得するには、次のコマンドを実行します。
openssl x509 -noout -subject -in ca-cert.pem | sed 's/.\{8\}//' | sed 's/, /\//g' | sed 's/ = /=/g' | sed 's/^/\//'require san
: ユーザー証明書を発行するCA証明書のSubject Alternative Name
情報を指定します。指定する情報は、クライアント証明書の生成に使用されるopenssl.cnf
構成ファイルのalt_names
と一致しています。次のコマンドを実行して、生成された証明書の
require san
項目の情報を取得します。openssl x509 -noout -extensions subjectAltName -in client.crtrequire san
現在、次のSubject Alternative Name
チェック項目をサポートしています。- URI
- 知財
- DNS
複数のチェック項目をカンマでつないで設定できます。たとえば、ユーザー
u1
に対して次のようにrequire san
を構成します。create user 'u1'@'%' require san 'DNS:d1,URI:spiffe://example.org/myservice1,URI:spiffe://example.org/myservice2';上記の構成では、URI 項目
spiffe://example.org/myservice1
またはspiffe://example.org/myservice2
と DNS 項目d1
の証明書を使用して、u1
人のユーザーのみが TiDB にログインできます。
require cipher
: クライアントがサポートする暗号方式をチェックします。次のステートメントを使用して、サポートされている暗号方式のリストを確認します。SHOW SESSION STATUS LIKE 'Ssl_cipher_list';
ユーザー証明書情報の構成
ユーザー証明書情報 ( require subject
、 require issuer
、 require san
、 require cipher
) を取得したら、ユーザーの作成、権限の付与、またはユーザーの変更時にこれらの情報が検証されるように構成します。次のステートメントの<replaceable>
を対応する情報に置き換えます。
区切り文字としてスペースまたはand
を使用して、1 つまたは複数のオプションを構成できます。
ユーザーの作成時にユーザー証明書を構成します (
create user
):create user 'u1'@'%' require issuer '<replaceable>' subject '<replaceable>' san '<replaceable>' cipher '<replaceable>';権限を付与するときにユーザー証明書を構成します。
grant all on *.* to 'u1'@'%' require issuer '<replaceable>' subject '<replaceable>' san '<replaceable>' cipher '<replaceable>';ユーザーを変更するときにユーザー証明書を構成します。
alter user 'u1'@'%' require issuer '<replaceable>' subject '<replaceable>' san '<replaceable>' cipher '<replaceable>';
上記の構成後、ログイン時に次の項目が検証されます。
- SSL が使用されます。クライアント証明書を発行する CA は、サーバーで構成された CA と一致しています。
- クライアント証明書の
issuer
情報はrequire issuer
で指定した情報と一致します。 - クライアント証明書の
subject
情報はrequire cipher
で指定した情報と一致します。 - クライアント証明書の
Subject Alternative Name
情報はrequire san
で指定した情報と一致します。
上記のすべての項目が確認された後にのみ、TiDB にログインできます。それ以外の場合は、 ERROR 1045 (28000): Access denied
エラーが返されます。次のコマンドを使用して、TLS バージョン、暗号アルゴリズム、および現在の接続がログインに証明書を使用しているかどうかを確認できます。
MySQL クライアントを接続し、次のステートメントを実行します。
\s
出力:
--------------
mysql Ver 15.1 Distrib 10.4.10-MariaDB, for Linux (x86_64) using readline 5.1
Connection id: 1
Current database: test
Current user: root@127.0.0.1
SSL: Cipher in use is TLS_AES_256_GCM_SHA384
次に、次のステートメントを実行します。
show variables like '%ssl%';
出力:
+---------------+----------------------------------+
| Variable_name | Value |
+---------------+----------------------------------+
| ssl_cert | /path/to/server-cert.pem |
| ssl_ca | /path/to/ca-cert.pem |
| have_ssl | YES |
| have_openssl | YES |
| ssl_key | /path/to/server-key.pem |
+---------------+----------------------------------+
6 rows in set (0.067 sec)
証明書を更新して置き換える
キーと証明書は定期的に更新されます。次のセクションでは、キーと証明書を更新する方法を紹介します。
CA 証明書は、クライアントとサーバー間の相互検証の基礎となります。 CA 証明書を置き換えるには、古い証明書と新しい証明書の両方の認証をサポートする結合証明書を生成します。クライアントとサーバーで、最初に CA 証明書を置き換え、次にクライアント/サーバーキーと証明書を置き換えます。
CA キーと証明書を更新する
古い CA キーと証明書をバックアップします (
ca-key.pem
が盗まれたとします)。mv ca-key.pem ca-key.old.pem && \ mv ca-cert.pem ca-cert.old.pem新しい CA キーを生成します。
sudo openssl genrsa 2048 > ca-key.pem新しく生成された CA キーを使用して、新しい CA 証明書を生成します。
sudo openssl req -new -x509 -nodes -days 365000 -key ca-key.pem -out ca-cert.new.pemノート:
新しい CA 証明書を生成することは、クライアントとサーバー上のキーと証明書を置き換え、オンライン ユーザーが影響を受けないようにすることです。したがって、上記のコマンドで付加される情報は、
require issuer
情報と一致している必要があります。結合された CA 証明書を生成します。
cat ca-cert.new.pem ca-cert.old.pem > ca-cert.pem
上記の操作の後、新しく作成された結合 CA 証明書を使用して TiDBサーバーを再起動します。次に、サーバーは新しい CA 証明書と古い CA 証明書の両方を受け入れます。
また、クライアントが古い CA 証明書と新しい CA 証明書の両方を受け入れるように、古い CA 証明書を組み合わせた証明書に置き換えます。
クライアントキーと証明書を更新する
ノート:
以下の手順は、クライアントとサーバー上の古い CA 証明書を結合された CA 証明書に置き換えた後でのみ実行してください。
クライアントの新しい RSA キーを生成します。
sudo openssl req -newkey rsa:2048 -days 365000 -nodes -keyout client-key.new.pem -out client-req.new.pem && \ sudo openssl rsa -in client-key.new.pem -out client-key.new.pemノート:
上記のコマンドは、クライアント キーと証明書を置き換え、オンライン ユーザーが影響を受けないようにするためのものです。したがって、上記のコマンドで付加される情報は、
require subject
情報と一致している必要があります。結合された証明書と新しい CA キーを使用して、新しいクライアント証明書を生成します。
sudo openssl x509 -req -in client-req.new.pem -days 365000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.new.pemクライアント (MySQL など) が新しいクライアント キーと証明書を使用して TiDB に接続するようにします。
mysql -utest -h0.0.0.0 -P4000 --ssl-cert /path/to/client-cert.new.pem --ssl-key /path/to/client-key.new.pem --ssl-ca /path/to/ca-cert.pemノート:
/path/to/client-cert.new.pem
、/path/to/client-key.new.pem
、および/path/to/ca-cert.pem
、CA 証明書、クライアント キー、およびクライアント証明書のディレクトリを指定します。それらを独自のディレクトリに置き換えることができます。
サーバーキーと証明書を更新する
サーバーの新しい RSA キーを生成します。
sudo openssl req -newkey rsa:2048 -days 365000 -nodes -keyout server-key.new.pem -out server-req.new.pem && \ sudo openssl rsa -in server-key.new.pem -out server-key.new.pem結合された CA 証明書と新しい CA キーを使用して、新しいサーバー証明書を生成します。
sudo openssl x509 -req -in server-req.new.pem -days 365000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.new.pem新しいサーバーキーと証明書を使用するように TiDBサーバーを構成します。詳細はTiDBサーバーの構成を参照してください。