MySQL暗号化：キーストア

コース「データベース」の新しいセットの開始前夜に、私たちはあなたのために役立つ記事の翻訳を用意しました。

---

透過的データ暗号化（TDE）は、MySQLおよびMySQL用のPerconaServerで長い間使用されてきました。しかし、内部でどのように機能し、TDEがサーバーにどのような影響を与える可能性があるのか​​疑問に思ったことはありませんか？このシリーズの記事では、TDEが内部でどのように機能するかを見ていきます。暗号化が機能するために必要なので、キーの保存から始めましょう。次に、Percona Server for MySQL / MySQLで暗号化がどのように機能するか、およびPercona Server forMySQLで利用できる追加機能について詳しく見ていきます。

MySQLキーリング

キーリングは、サーバーがローカルファイル（keyring_file）またはリモートサーバー（HashiCorp Vaultなど）でキーを照会、作成、および削除できるようにするプラグインです。キーは常にローカルにキャッシュされ、取得を高速化します。



プラグインは、次の2つのカテゴリに分類できます。

• ローカルストレージ。たとえば、ローカルファイル（これをファイルベースのキーリングと呼びます）。
• リモートストレージ。たとえば、Vault Server（これをサーバーベースのキーリングと呼びます）。

キーの保存と取得時だけでなく、起動時も、ストレージの種類によって動作がわずかに異なるため、この分離は重要です。



ファイルストレージを使用する場合、起動時に、ストレージの内容全体（キーID、キーユーザー、キータイプ、およびキー自体）がキャッシュにロードされます。



バックエンドボールト（Vaultサーバーなど）の場合、起動時にキーIDとキーユーザーのみが読み込まれるため、すべてのキーを取得しても起動が遅くなることはありません。キーは遅延ロードされます。つまり、キー自体は、実際に必要な場合にのみVaultからロードされます。ロードされると、キーはメモリにキャッシュされるため、将来、VaultサーバーへのTLS接続を介してキーにアクセスする必要はありません。次に、キーストアにどのような情報が存在するかを見てみましょう。



重要な情報は次のとおりです。

• key id — , :
  
  INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1
• key type — , , : «AES», «RSA» «DSA».
• key length — , AES: 16, 24 32, RSA 128, 256, 512 DSA 128, 256 384.
• user — . , , Master Key, . keyring_udf, .

キーは、key_id、userのペアによって一意に識別されます。



キーの保管と廃棄にも違いがあります。



ファイルストレージはより高速です。キーストアはファイルへのキーの単純な1回限りの書き込みであると想定できますが、そうではありません。ここではさらに多くの操作が行われています。ファイルストレージを変更すると、最初にすべてのコンテンツのバックアップが作成されます。ファイルの名前がmy_biggest_secretsであるとすると、バックアップはmy_biggest_secrets.backupになります。次に、キャッシュが変更され（キーが追加または削除され）、すべてが成功すると、キャッシュがファイルにフラッシュされます。サーバーがクラッシュするなどのまれなケースでは、このバックアップファイルが表示される場合があります。バックアップファイルは、次にキーがロードされたとき（通常はサーバーの再起動後）に削除されます。



サーバーリポジトリにキーを保存または削除する場合、リポジトリは「キーの送信」/「キーの削除の要求」コマンドを使用してMySQLサーバーに接続する必要があります。



サーバーの起動速度に戻りましょう。ストレージ自体が起動速度に影響を与えるという事実に加えて、起動時にストレージから取得する必要のあるキーの数の問題もあります。もちろん、これはバックエンドストレージにとって特に重要です。起動時に、サーバーは暗号化されたテーブル/テーブルスペースに必要なキーを確認し、ストレージにキーを要求します。マスターキー（暗号化）を備えた「クリーンな」サーバーには、ストレージから取得する必要のあるマスターキーが1つ必要です。ただし、プライマリサーバーからバックアップサーバーにバックアップを復元する場合など、より多くのキーが必要になる場合があります。このような場合、マスターキーのローテーションを提供する必要があります。これについては今後の記事で詳しく説明しますが、ここでサーバーが複数のマスターキーを使用すると、特にサーバー側のキーストアを使用する場合、開始に少し時間がかかる場合があります。



それでは、keyring_fileについてもう少し話しましょう。 keyring_fileを開発していたとき、サーバーの実行中にkeyring_fileの変更を確認する方法についても心配していました。 5.7では、チェックはファイル統計に基づいて実行されましたが、これは理想的なソリューションではありませんでしたが、8.0ではSHA256チェックサムに置き換えられました。



keyring_fileを初めて実行すると、ファイル統計とチェックサムが計算されてサーバーによって記憶され、変更は一致する場合にのみ適用されます。チェックサムは、ファイルが変更されると更新されます。



キーストアに関する多くの質問については、すでに説明しました。ただし、忘れられたり誤解されたりすることが多いもう1つの重要なトピックがあります。それは、サーバー間でのキーの共有です。



私が意味したのは？クラスタ内の各サーバー（たとえば、Perconaサーバー）は、Perconaサーバーがキーを格納する必要があるVaultサーバー上の個別の場所にある必要があります。ボールトに保存されている各マスターキーには、その識別子内にPerconaサーバーのGUIDが含まれています。どうしてそれが重要ですか？ Vault Serverが1つだけで、クラスター内のすべてのPerconaサーバーがその単一のVaultServerを使用しているとします。問題は明らかなようです。すべてのPerconaサーバーが一意の識別子なしでマスターキーを使用している場合（たとえば、id = 1、id = 2など）、クラスター内のすべてのサーバーは同じマスターキーを使用します。これがGUIDが提供するものであり、サーバー間の違いです。一意のGUIDがすでに存在するのに、なぜサーバー間でキーを共有することについて話すのですか？もう1つのプラグインがあります-keyring_udf。このプラグインを使用すると、サーバーユーザーは自分のキーをVaultサーバーに保存できます。この問題は、ユーザーがたとえばserver1でキーを作成してから、たとえば次のようにserver2で同じIDのキーを作成しようとしたときに発生します。

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1   
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1

待つ。両方のサーバーが同じVaultサーバーを使用していますが、server2でkeyring_key_store関数が失敗するべきではありませんか？興味深いことに、同じサーバーで同じことを実行しようとすると、エラーが発生します。

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0

そうです、ROB_1はすでに存在しています。



最初に2番目の例について説明しましょう。前に述べたように、keyring_vaultまたはその他のkeyringプラグインは、すべてのキーIDをメモリにキャッシュします。したがって、新しいキーを作成した後、ROB_1がserver1に追加され、このキーをVaultに送信するだけでなく、キーもキャッシュに追加されます。ここで、同じキーをもう一度追加しようとすると、keyring_vaultはこのキーがキャッシュに存在するかどうかを確認し、エラーをスローします。



最初のケースでは、状況が異なります。 Server1とserver2には別々のキャッシュがあります。 server1とVaultのキーキャッシュにROB_1を追加した後、server2のキーキャッシュが同期していません。 server2のキャッシュにROB_1キーがありません。したがって、ROB_1キーはkeyring_key_storeとVaultサーバーに書き込まれ、実際には前の値が上書きされます（！）。現在、VaultサーバーのキーROB_1は543210987654321です。興味深いことに、Vaultサーバーはそのようなアクションをブロックせず、古い値を簡単に上書きします。



これで、Vaultごとのサーバーによる分割が重要になる理由がわかりました。keyring_udfを使用していて、Vaultにキーを保存する場合です。 Vaultサーバーでこの分離をどのように提供しますか？



Vaultに分割する方法は2つあります。サーバーごとに異なるマウントポイントを作成することも、同じマウントポイント内で異なるパスを使用することもできます。これは例で最もよく説明されています。それでは、最初に個々のマウントポイントを見てみましょう。

--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = server1_mount
token = (...)
vault_ca = (...)

--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = sever2_mount
token = (...)
vault_ca = (...)

ここでは、server1とserver2が異なるマウントポイントを使用していることがわかります。パスを分割する場合、構成は次のようになります。

--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/server1
token = (...)
vault_ca = (...)
--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/sever2
token = (...)
vault_ca = (...)

この場合、両方のサーバーは同じmount_pointを使用しますが、パスは異なります。このパスに沿ってserver1に最初のシークレットが作成されると、Vaultは自動的に「server1」ディレクトリを作成します。 server2の場合、すべてが同じです。 mount_point / server1またはmount_point / server2の最後のシークレットを削除すると、Vaultサーバーもそれらのディレクトリを削除します。パス分割を使用している場合は、マウントポイントを1つ作成し、サーバーが個別のパスを使用するように構成ファイルを変更するだけで済みます。マウントポイントは、HTTPリクエストを使用して作成できます。 CURLを使用すると、次のように実行できます。

curl -L -H "X-Vault-Token: TOKEN" –cacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINT

すべてのフィールド（TOKEN、VAULT_CA、VAULT_URL、SECRET_MOUNT_POINT）は、構成ファイルのパラメーターに対応します。もちろん、Vaultユーティリティを使用して同じことを行うことができます。ただし、これにより、マウントポイントの作成を簡単に自動化できます。この情報がお役に立てば幸いです。このシリーズの次の記事でお会いしましょう。

続きを読む：

• システムベンチとランダム変数の分布