MySQL :: MySQL 8.0 リファレンスマニュアル :: 6.4.4.6 HashiCorp Vault キーリングプラグインの使用

MySQL 8.0 リファレンスマニュアル / ... / HashiCorp Vault キーリングプラグインの使用

このページは機械翻訳したものです。

6.4.4.6 HashiCorp Vault キーリングプラグインの使用

注記

keyring_hashicorp プラグインは、商用製品である MySQL Enterprise Edition に含まれている拡張機能です。商用製品の詳細は、https://www.mysql.com/products/ を参照してください。

keyring_hashicorp キーリングプラグインは、バックエンドストレージのために HashiCorp Vault と通信します。プラグインは、HashiCorp Vault AppRole 認証をサポートしています。キー情報は、MySQL サーバーのローカル記憶域に永続的に格納されません。 (オプションのインメモリーキーキャッシュを中間記憶域として使用できます。) ランダムキー生成は MySQL サーバー側で実行され、その後、キーは Hashicorp Vault に格納されます。

keyring_hashicorp プラグインは、標準の MySQL キーリングサービスインタフェースを構成する関数をサポートしています。これらの関数によって実行されるキーリング操作には、次の 2 つのレベルでアクセスできます:

SQL インタフェース: SQL ステートメントで、セクション6.4.4.10「汎用キーリングキー管理関数」で説明されているユーザー定義関数 (UDF) をコールします。
C インタフェース: C 言語コードでは、セクション5.6.8.2「キーリングサービス」で説明されているキーリングサービス関数をコールします。

例 (UDF を使用):

SELECT keyring_key_generate('MyKey', 'AES', 32);
SELECT keyring_key_remove('MyKey');

keyring_hashicorp で許可されるキータイプの詳細は、セクション6.4.4.8「サポートされているキーリングキーのタイプと長さ」を参照してください。

keyring_hashicorp プラグインをインストールするには、セクション6.4.4.1「キーリングプラグインのインストール」にある一般的なキーリングのインストール手順と、ここにある keyring_hashicorp に固有の構成情報を使用します。プラグイン固有の構成には、HashiCorp Vault への接続および Vault 自体の構成に必要な証明書およびキーファイルの準備が含まれます。次の各セクションでは、必要な手順について説明します。

証明書とキーの準備

keyring_hashicorp プラグインには、HTTPS プロトコルを使用した HashiCorp Vault サーバーへのセキュアな接続が必要です。一般的な設定には、証明書とキーファイルのセットが含まれます:

company.crt: 組織に属するカスタム CA 証明書。このファイルは、HashiCorp Vault サーバーと keyring_hashicorp プラグインの両方で使用されます。
vault.key: HashiCorp Vault サーバーインスタンスの秘密キー。このファイルは、HashiCorp Vault サーバーで使用されます。
vault.crt: HashiCorp Vault サーバーインスタンスの証明書。このファイルは、組織の CA 証明書によって署名されている必要があります。

次の手順では、OpenSSL を使用して証明書およびキーファイルを作成する方法について説明します。 (すでにファイルがある場合は、HashiCorp Vault の設定に進みます。) 示されている手順は Linux プラットフォームに適用され、他のプラットフォームに対する調整が必要になる場合があります。

重要

これらの手順で生成される証明書は自己署名されており、あまりセキュアではない可能性があります。このようなファイルの使用経験がある場合は、登録された認証局から証明書/キーデータを取得することを検討してください。

会社キーと HashiCorp Vault サーバーキーを準備します。

次のコマンドを使用して、キーファイルを生成します:
```
openssl genrsa -aes256 -out company.key 4096
openssl genrsa -aes256 -out vault.key 2048
```
これらのコマンドは、会社の秘密キー (company.key) および Vault サーバーの秘密キー (vault.key) を保持するファイルを生成します。鍵はそれぞれ 4,096 ビットと 2,048 ビットのランダムに生成された RSA 鍵です。

各コマンドでは、パスワードの入力を求められます。 (テスト目的では、パスワードは必要ありません。無効にするには、-aes256 引数を省略します。)

キーファイルは機密情報を保持し、セキュアな場所に格納する必要があります。パスワードは後で必要になるため、書き留めて安全な場所に格納します。

(オプション) キーファイルの内容と有効性を確認するには、次のコマンドを使用します:
```
openssl rsa -in company.key -check
openssl rsa -in vault.key -check
```
会社の CA 証明書を作成します。

365 日間有効な company.crt という名前の会社の CA 証明書ファイルを作成するには、次のコマンドを使用します (コマンドは単一行で入力します):
```
openssl req -x509 -new -nodes -key company.key
  -sha256 -days 365 -out company.crt
```
-aes256 引数を使用してキーの生成時にキーの暗号化を実行した場合、CA 証明書の作成時に会社のキーパスワードの入力を求められます。次に示すように、証明書ホルダー (つまり、自分または会社) に関する情報の入力も求められます:
```
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:
```
プロンプトに適切な値を入力します。
証明書署名リクエストを作成します。

HashiCorp Vault サーバー証明書を作成するには、新しく作成したサーバーキーに対して証明書署名リクエスト (CSR) を準備する必要があります。次の行を含む request.conf という名前の構成ファイルを作成します。 HashiCorp Vault サーバーがローカルホストで実行されていない場合は、適切な CN 値と IP 値を置き換え、必要に応じて他の変更を行います。
```
[req]
distinguished_name = vault
x509_entensions = v3_req
prompt = no

[vault]
C = US
ST = CA
L = RWC
O = Company
CN = 127.0.0.1

[v3_req]
subjectAltName = @alternatives
authorityKeyIdentifier = keyid,issuer
basicConstraints = CA:TRUE

[alternatives]
IP = 127.0.0.1
```
署名要求を作成するには、次のコマンドを使用します:
```
openssl req -new -key vault.key -config request.conf -out request.csr
```
出力ファイル (request.csr) は、サーバー証明書を作成するための入力として機能する中間ファイルです。
HashiCorp Vault サーバー証明書を作成します。

HashiCorp Vault サーバーキー (vault.key) と CSR (request.csr) の結合情報に会社の証明書 (company.crt) を使用して署名し、HashiCorp Vault サーバー証明書 (vault.crt) を作成します。これを行うには、次のコマンドを使用します (コマンドは単一行で入力します):
```
openssl x509 -req -in request.csr
  -CA company.crt -CAkey company.key -CAcreateserial
  -out vault.crt -days 365 -sha256
```
vault.crt サーバー証明書を役に立つようにするには、company.crt 会社の証明書の内容を追加します。これは、会社の証明書がリクエストでサーバー証明書とともに配信されるようにするために必要です。
```
cat company.crt >> vault.crt
```
テキストエディタで vault.crt ファイルを開くと、その内容は次のようになります:
```
-----BEGIN CERTIFICATE-----
... content of HashiCorp Vault server certificate ...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
... content of company certificate ...
-----END CERTIFICATE-----
```

HashiCorp Vault の設定

次の手順では、keyring_hashicorp プラグインのテストを容易にする HashiCorp Vault 設定を作成する方法について説明します。

重要

テスト設定は本番設定と似ていますが、HashiCorp Vault を本番で使用するには、自己署名されていない証明書の使用やシステムトラストストアへの会社の証明書の格納など、追加のセキュリティ上の考慮事項が必要です。運用要件を満たすために必要な追加のセキュリティステップを実装する必要があります。

次の手順では、証明書とキーの準備で作成された証明書およびキーファイルが使用可能であることを前提としています。ファイルがない場合は、そのセクションを参照してください。

HashiCorp Vault バイナリをフェッチします。

ご使用のプラットフォームに適した HashiCorp Vault バイナリを https://www.vaultproject.io/downloads.html からダウンロードします。

アーカイブの内容を抽出して、HashiCorp Vault 操作の実行に使用される実行可能な vault コマンドを生成します。必要に応じて、コマンドをインストールするディレクトリをシステムパスに追加します。

(オプション) HashiCorp Vault では、使いやすくするオートコンプリートオプションがサポートされています。詳細は、https://learn.hashicorp.com/vault/getting-started/install#command-completionを参照してください。
HashiCorp Vault サーバー構成ファイルを作成します。

次の内容を含む config.hcl という名前の構成ファイルを準備します。 tls_cert_file、tls_key_file および path の値は、使用しているシステムに適したパス名に置き換えてください。
```
listener "tcp" {
  address="127.0.0.1:8200"
  tls_cert_file="/home/username/certificates/vault.crt"
  tls_key_file="/home/username/certificates/vault.key"
}

storage "file" {
  path = "/home/username/vaultstorage/storage"
}

ui = true
```
HashiCorp Vault サーバーを起動します。

Vault サーバーを起動するには、次のコマンドを使用します。ここで、-config オプションは作成したばかりの構成ファイルへのパスを指定します:
```
vault server -config=config.hcl
```
このステップでは、vault.key ファイルに格納されている Vault サーバーの秘密キーのパスワードの入力を求められる場合があります。

サーバーが起動し、コンソールにいくつかの情報 (IP、ポートなど) が表示されます。

残りのコマンドを入力できるように、vault server コマンドをバックグラウンドに置くか、続行する前に別の端末を開きます。
HashiCorp Vault サーバーを初期化します。

注記

この手順で説明する操作は、開封キーとルートトークンを取得するために Vault を初めて起動する場合にのみ必要です。その後の Vault インスタンスの再起動では、シール解除キーを使用したアンシールのみが必要です。

次のコマンドを発行します (Bourne シェル構文を想定):
```
export VAULT_SKIP_VERIFY=1
vault operator init -n 1 -t 1
```
最初のコマンドを使用すると、vault コマンドは、システムトラストストアに会社の証明書が追加されていないことを一時的に無視できます。自己署名 CA がそのストアに追加されていないという事実を補う。 (本番で使用するには、このような証明書を追加する必要があります。)

2 番目のコマンドは、シール解除のために 1 つのシール解除キーが存在する必要がある単一のシール解除キーを作成します。 (本番で使用する場合、インスタンスには複数のアンシールキーがあり、アンシールするために入力する必要があるキーはその数までです。開封キーは、会社内の主要な顧客に配信する必要があります。単一のキーを使用すると、ボールトを単一のキーカスタムによってシール解除できるため、セキュリティ上の問題とみなされる場合があります。)

Vault は、シール解除キーとルートトークンに関する情報に加えて、追加のテキストを返信する必要があります (実際のシール解除キーとルートトークンの値はここに示す値とは異なります):
```
...
Unseal Key 1: I2xwcFQc892O0Nt2pBiRNlnkHzTUrWS+JybL39BjcOE=
Initial Root Token: s.vTvXeo3tPEYehfcd9WH7oUKz
...
```
シール解除キーとルートトークンをセキュアな場所に格納します。
HashiCorp Vault サーバーをシール解除します。

Vault サーバをシール解除するには、次のコマンドを使用します:
```
vault operator unseal
```
開封キーの入力を求めるプロンプトが表示されたら、Vault の初期化時に以前に取得したキーを使用します。

Vault は、セットアップが完了し、ボールトがシールなしであることを示す出力を生成します。
HashiCorp Vault サーバーにログインし、そのステータスを確認します。

root としてログインするために必要な環境変数を準備します:
```
vault login s.vTvXeo3tPEYehfcd9WH7oUKz
```
このコマンドのトークン値は、Vault の初期化中に以前に取得した root トークンの内容に置き換えてください。

Vault サーバのステータスを確認します:
```
vault status
```
出力には次の行が含まれる必要があります (特に):
```
...
Initialized     true
Sealed          false
...
```
HashiCorp Vault の認証および記憶域を設定します。

注記

この手順で説明する操作は、Vault インスタンスの初回実行時にのみ必要です。後で繰り返す必要はありません。

AppRole 認証方式を有効にして、認証方式リストに含まれていることを確認します:
```
vault auth enable approle
vault auth list
```
Vault KeyValue ストレージエンジンを有効にします:
```
vault secrets enable -version=1 kv
```
keyring_hashicorp プラグインで使用するロールを作成および設定します (コマンドを単一行で入力します):
```
vault write auth/approle/role/mysql token_num_uses=0
  token_ttl=20m token_max_ttl=30m secret_id_num_uses=0
```
AppRole セキュリティポリシーを追加します。

注記

この手順で説明する操作は、Vault インスタンスの初回実行時にのみ必要です。後で繰り返す必要はありません。

以前に作成したロールに適切なシークレットへのアクセスを許可するポリシーを準備します。次の内容で mysql.hcl という名前の新しいファイルを作成します:
```
path "kv/mysql/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}
```
ポリシーファイルを Vault サーバーにインポートして mysql-policy という名前のポリシーを作成し、そのポリシーを新しいロールに割り当てます:
```
vault policy write mysql-policy mysql.hcl
vault write auth/approle/role/mysql policies=mysql-policy
```
新しく作成したロールの ID を取得し、セキュアな場所に格納します:
```
vault read auth/approle/role/mysql/role-id
```
ロールのシークレット ID を生成し、セキュアな場所に格納します:
```
vault write -f auth/approle/role/mysql/secret-id
```
これらの AppRole ロール ID およびシークレット ID の資格証明が生成された後、それらは無期限に有効なままである必要があります。これらを再度生成する必要はなく、継続的に使用するように keyring_hashicorp プラグインを構成できます。 AuthRole 認証の詳細は、https://www.vaultproject.io/docs/auth/approle.html を参照してください。

keyring_hashicorp 構成

プラグインライブラリファイルには、keyring_hashicorp プラグインとユーザー定義関数 (UDF)、keyring_hashicorp_update_config() が含まれています。プラグインが初期化および終了すると、UDF が自動的にロードおよびアンロードされるため、UDF を手動でロードおよびアンロードする必要はありません。

keyring_hashicorp プラグインは、次のテーブルに示す構成パラメータをサポートしています。これらのパラメータを指定するには、対応するシステム変数に値を割り当てます。

構成パラメータ	システム変数	必須
HashiCorp サーバー URL	`keyring_hashicorp_server_url`	いいえ
AppRole ロール ID	`keyring_hashicorp_role_id`	はい
AppRole シークレット ID	`keyring_hashicorp_secret_id`	はい
ストアパス	`keyring_hashicorp_store_path`	はい
認可パス	`keyring_hashicorp_auth_path`	いいえ
CA 証明書ファイルのパス	`keyring_hashicorp_ca_path`	いいえ
キャッシュ制御	`keyring_hashicorp_caching`	いいえ

サーバーの起動プロセス中に使用できるようにするには、--early-plugin-load オプションを使用して keyring_hashicorp をロードする必要があります。前述のテーブルに示されているように、プラグイン関連のいくつかのシステム変数は必須であり、設定する必要もあります。たとえば、サーバー my.cnf ファイルで次の行を使用して、プラットフォームの .so 接尾辞とファイルの場所を必要に応じて調整します:

[mysqld]
early-plugin-load=keyring_hashicorp.so
keyring_hashicorp_role_id='ee3b495c-d0c9-11e9-8881-8444c71c32aa'
keyring_hashicorp_secret_id='0512af29-d0ca-11e9-95ee-0010e00dd718'
keyring_hashicorp_store_path='/v1/kv/mysql'

MySQL Server は、AppRole 認証を使用して HashiCorp Vault に対して認証します。認証に成功するには、Vault にロール ID とシークレット ID の 2 つのシークレットを提供する必要があります。これらは、ユーザー名とパスワードの概念に似ています。使用するロール ID およびシークレット ID の値は、以前に実行した HashiCorp Vault の設定手順で取得した値です。 2 つの ID を指定するには、それぞれの値を keyring_hashicorp_role_id および keyring_hashicorp_secret_id システム変数に割り当てます。設定手順では、/v1/kv/mysql のストアパスも生成されます。これは、keyring_hashicorp_commit_store_path に割り当てる値です。

プラグインの初期化時に、keyring_hashicorp は構成値を使用して HashiCorp Vault サーバーへの接続を試みます。接続が成功すると、プラグインは名前に_commit_が含まれる対応するシステム変数に値を格納します。たとえば、接続が成功すると、プラグインは keyring_hashicorp_role_id および keyring_hashicorp_store_path の値を keyring_hashicorp_commit_role_id および keyring_hashicorp_commit_store_path に格納します。

実行時の再構成は、keyring_hashicorp_update_config() UDF を使用して実行できます:

SET ステートメントを使用して、前述のテーブルに示す構成システム変数に必要な新しい値を割り当てます。これらの割り当て自体は、進行中のプラグイン操作には影響しません。
keyring_hashicorp_update_config() を起動してプラグインを再構成し、新しい変数値を使用して HashiCorp Vault サーバーに再接続します。
接続が成功すると、プラグインは、名前に_commit_が含まれる対応するシステム変数に更新された構成値を格納します。

たとえば、デフォルト 8200 ではなくポート 8201 でリスニングするように HashiCorp Vault を再構成した場合は、次のように keyring_hashicorp を再構成します:

mysql> SET GLOBAL keyring_hashicorp_server_url = 'https://127.0.0.1:8201';
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT keyring_hashicorp_update_config();
+--------------------------------------+
| keyring_hashicorp_update_config()    |
+--------------------------------------+
| Configuration update was successful. |
+--------------------------------------+
1 row in set (0.03 sec)

初期化または再構成中にプラグインが HashiCorp Vault に接続できず、既存の接続がなかった場合、_commit_システム変数は文字列値変数に対して'Not committed'に設定され、ブール値変数に対して OFF に設定されます。プラグインが接続できないが、既存の接続があった場合、その接続はアクティブなままで、_commit_変数にはその接続に使用された値が反映されます。

注記

サーバーの起動時に必須のシステム変数を設定しない場合、または他のプラグイン初期化エラーが発生した場合、初期化は失敗します。この場合、実行時再構成手順を使用すると、サーバーを再起動せずにプラグインを初期化できます。

keyring_hashicorp プラグイン固有のシステム変数および UDF の詳細は、セクション6.4.4.13「キーリングシステム変数」およびセクション6.4.4.11「プラグイン固有のキーリングキー管理関数」を参照してください。

PREV HOME UP NEXT