MySQL の暗号化: キーストア

新規コースの募集開始に向けて 「データベース」 役立つ記事の翻訳をご用意しました。

透過的データ暗号化 (TDE) は、 MySQL 用 Percona サーバー MySQL もかなり長い間使用されてきました。 しかし、TDE が内部でどのように機能するのか、また TDE がサーバーに与える影響について考えたことはありますか? この一連の記事では、TDE が内部でどのように動作するかを見ていきます。 暗号化を機能させるにはキーの保管が必要となるため、キーの保管から始めましょう。 次に、Percona Server for MySQL/MySQL での暗号化の仕組みと、Percona Server for MySQL の追加機能について詳しく見ていきます。

MySQL キーリング

キーリングは、サーバーがローカル ファイル (keyring_file) またはリモート サーバー (HashiCorp Vault など) 上のキーをクエリ、作成、削除できるようにするプラグインです。 キーは、取得を高速化するために常にローカルにキャッシュされます。

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

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

キーの保管時と取得時だけでなく、キーの実行時も、ストレージのタイプが異なると動作が若干異なるため、この分離は重要です。

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

サーバーベースのストア (Vault Server など) の場合、起動時にキー ID とキー ユーザーのみがロードされるため、すべてのキーを取得しても起動が遅くなるわけではありません。 キーは遅延してロードされます。 つまり、キー自体は、実際に必要な場合にのみ Vault からロードされます。 ダウンロードされたキーはメモリにキャッシュされるため、今後 Vault サーバーへの TLS 接続を通じてアクセスする必要はありません。 次に、キー ストアにどのような情報が存在するかを見てみましょう。

重要な情報には次のものが含まれます。

• キーID — キー識別子、例:
  INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1
• キータイプ — 使用される暗号化アルゴリズムに基づくキーのタイプ。可能な値: 「AES」、「RSA」、または「DSA」。
• キーの長さ — キーの長さ (バイト単位)、AES: 16、24 または 32、RSA 128、256、512、および DSA 128、256 または 384。
• user - キーの所有者。 キーがシステム (マスター キーなど) の場合、このフィールドは空です。 keyring_udf を使用してキーが作成された場合、このフィールドはキーの所有者を識別します。
• 鍵そのもの

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

キーの保存と削除にも違いがあります。

ファイルストレージが高速になります。 キー ストアはキーをファイルに XNUMX 回書き込むだけだと思う​​かもしれませんが、そうではありません。ここではさらに多くの処理が行われます。 ファイル ストレージの変更が行われるたびに、最初にすべてのコンテンツのバックアップ コピーが作成されます。 ファイルの名前が my_biggest_secrets だとすると、バックアップ コピーは my_biggest_secrets.backup になります。 次に、キャッシュが変更され (キーが追加または削除され)、すべてが成功すると、キャッシュがファイルにリセットされます。 サーバー障害などのまれなケースでは、このバックアップ ファイルが表示されることがあります。 バックアップ ファイルは、次回キーがロードされるとき (通常はサーバーの再起動後) に削除されます。

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

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

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

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

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

私が意味したのは？ クラスタ内の各サーバー (Percona サーバーなど) は、Percona サーバーがそのキーを保存する必要がある Vault サーバー上に個別の場所を持っている必要があります。 ストレージに保存された各マスター キーには、その識別子の中に Percona サーバーの GUID が含まれています。 どうしてそれが重要ですか？ Vault サーバーが 1 つだけあり、クラスタ内のすべての Percona サーバーがその 2 つの Vault サーバーを使用していると想像してください。 問題は明らかのようです。 すべての Percona サーバーが、id = 1、id = 2 などの一意の識別子のないマスター キーを使用した場合、クラスター内のすべてのサーバーは同じマスター キーを使用します。 GUID によって提供されるのは、サーバー間の区別です。 一意の GUID がすでに存在する場合、なぜサーバー間でキーを共有することについて話すのでしょうか? 別のプラグイン - keyring_udf があります。 このプラグインを使用すると、サーバー ユーザーは自分のキーを Vault サーバーに保存できます。 この問題は、ユーザーがサーバー XNUMX でキーを作成し、次にサーバー XNUMX で同じ 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 関数が失敗するはずはありませんか? 興味深いことに、XNUMX つのサーバーで同じことを実行しようとすると、エラーが発生します。

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

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

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

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

これで、keyring_udf を使用していてキーを Vault に保存したい場合に、Vault でのサーバーのパーティショニングが重要となる理由がわかりました。 Vault サーバー上でこの分離を実現するにはどうすればよいでしょうか?

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

--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」ディレクトリを作成します。 サーバー 2 の場合もすべて同様です。 mount_point/server1 または mount_point/server2 の最後のシークレットを削除すると、Vault サーバーはそれらのディレクトリも削除します。 パス分離を使用する場合は、マウント ポイントを XNUMX つだけ作成し、サーバーが別々のパスを使用するように構成ファイルを変更する必要があります。 マウント ポイントは、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 ユーティリティを使用して同じことを行うこともできます。 ただし、マウント ポイントの作成を自動化する方が簡単です。 この情報がお役に立てば幸いです。このシリーズの次の記事でお会いしましょう。

続きを読む：

• Sysbench と確率変数の分布

出所： habr.com