MySQL での暗号化: マスターキーの使用

新規コースの募集開始に向けて 「データベース」 私たちは、MySQL の暗号化に関する一連の記事を公開し続けます。

このシリーズの前回の記事 (MySQL の暗号化: キーストア) Key Vault について話しました。 この記事では、マスター キーがどのように使用されるかを見て、エンベロープ暗号化の長所と短所について説明します。 

エンベロープ暗号化の背後にある考え方は、暗号化に使用されるキー (テーブルスペース キー) が別のキー (マスター キー) で暗号化されるということです。 テーブルスペース キーは、実際にはデータの暗号化に使用されます。 グラフ的には次のように表すことができます。

マスター キーはキーリングにあり、テーブルスペース キーは暗号化されたテーブルスペース ヘッダー (テーブルスペースのページ 0) にあります。 

上の図では:

• テーブル A はキー 1 (キー 1) で暗号化されます。 キー 1 はマスター キーを使用して暗号化され、テーブル A のヘッダーに暗号化されて保存されます。

• テーブル B はキー 2 で暗号化されます。 キー 2 はマスター キー (マスカー キー) を使用して暗号化され、テーブル B のヘッダーに暗号化されて格納されます。

• などなど。

サーバーがテーブル A を復号する必要がある場合、サーバーはストレージからマスター キーを取得し、テーブル A のヘッダーから暗号化されたキー 1 を読み取り、キー 1 を復号します。復号されたキー 1 はサーバーのメモリにキャッシュされ、テーブル A を復号するために使用されます。 。

InnoDB

InnoDB では、実際の暗号化と復号化は I/O 層で行われます。 つまり、ページはディスクにフラッシュされる直前に暗号化され、ディスクから読み取られた直後に復号化されます。

InnoDB では、暗号化はテーブルスペース レベルでのみ機能します。 また、デフォルトでは、すべてのテーブルが個別のテーブルスペースに作成されます (テーブルごとのファイルのテーブルスペース）。 つまり、テーブルを XNUMX つだけ含めることができるテーブルスペースが作成されます。 メインテーブルスペースにもテーブルを作成できますが（一般的なテーブルスペース）。 ただし、いずれの場合でも、テーブルは常に何らかのテーブルスペースに配置されます。 また、暗号化は表領域レベルで実行されるため、完全に暗号化されるか、暗号化されないかのどちらかになります。 つまり、メイン表スペース内の一部の表のみを暗号化することはできません。 

何らかの理由で file-per-table が無効になっている場合、すべてのテーブルがシステム テーブルスペース内に作成されます。 で MySQL 用 Percona サーバー innodb 変数を使用してシステムテーブルスペースを暗号化できますSYS表領域暗号化するか、暗号化スレッドを使用しますが、これはまだ実験的な機能です。 MySQLにはこれがありません。

次に進む前に、マスターキー ID の構造を確認する必要があります。 UUID、KEYで構成されますID とプレフィックス「INNODBKey」。 次のようになります: INNODBKey-UUID-KEYIDを指定します。

UUID は、暗号化されたテーブルスペースを持つサーバーの uuid です。 鍵ID は単に増加し続ける値です。 初めてマスターキーKEYを作成する場合ID は 1 です。キーのローテーション中、新しいマスターキーが作成されると、KEYID = 2 など。 マスター キーのローテーションについては、このシリーズの次の記事で詳しく説明します。

マスターキー識別子がどのようなものかを理解したので、暗号化されたテーブルスペースヘッダーを見てみましょう。 表領域が暗号化されると、暗号化情報がヘッダーに追加されます。 次のようになります。

キーIDはKEYですすでに説明したマスター キー ID からの ID。 UUID はサーバーの uuid であり、マスター キー識別子にも使用されます。 TABLESPACE KEY - サーバーによってランダムに生成された 256 ビットで構成されるテーブルスペースキー。 初期化ベクトル (IV) も、ランダムに生成された 256 ビットで構成されます (ただし、128 ビットである必要があります)。 IV は、AES 暗号化と復号化を初期化するために使用されます (256 ビットのうち、128 ビットのみが使用されます)。 最後に、TABLESPACE KEY と IV の CRC32 チェックサムがあります。

これまでずっと、ヘッダーにはテーブルスペースの暗号化されたキーが含まれていると言って、少し単純化していました。 実際、テーブルスペース キーと初期化ベクトルは、マスター キーを使用して一緒に保存および暗号化されます。 テーブルスペースキーと初期化ベクトルを暗号化する前に、それらの CRC32 が計算されることに注意してください。

なぜ CRC32 が必要なのでしょうか?

一言で言えば、マスターキーの有効性を保証するためです。 テーブルスペースキーと初期化ベクトルを復号化した後、チェックサムが計算され、ヘッダーに格納されている CRC32 と比較されます。 チェックサムが一致する場合、正しいマスター キーとテーブルスペース キーが得られます。 それ以外の場合、テーブルスペースは欠落としてマークされます (とにかく復号化できません)。

「鍵の検証はどの時点で行われるのですか?」と疑問に思うかもしれません。 答えは、サーバーの起動時です。 暗号化されたテーブル/テーブルスペースを持つサーバーは起動時に UUID、KEY を読み取りますヘッダーから ID を取得し、マスター キー ID を生成します。 次に、キーリングから必要なマスターキーを取得し、テーブルスペースキーを復号化し、チェックサムを検証します。 もう一度言いますが、チェックサムが一致する場合はすべて問題ありません。一致しない場合は、テーブルスペースが欠落しているとマークされます。

このシリーズの前回の記事 (MySQL の暗号化: キーストア)、サーバーベースのキーストアを使用する場合、サーバーは起動時にキー識別子のリスト、つまりキー ID とユーザー ID のみを受信することを覚えているかもしれません。これは、このペアがキーを一意に識別するためです。 ここで、サーバーの起動時に、テーブルスペースのキーを復号化できるかどうかを確認するために必要なすべてのキーを受信すると言います。 では、サーバーストレージの場合、初期化中にキーのみが読み込まれるのはなぜですかIDとユーザーすべてのキーではなく ID ですか? すべてのキーが必要なわけではないためです。 これは主にマスター キーのローテーションが原因です。 マスター キーがローテーションされると、新しいマスター キーがボールト内に作成されますが、古いキーは削除されません。 したがって、サーバーが必要としないキーがサーバーのキーストアに多数存在し、サーバーの起動時に取得されない可能性があります。

マスター キー暗号化の長所と短所について少しお話します。 最大の利点は、必要な暗号化キー (マスター キー) が XNUMX つだけであり、暗号化データとは別に保存されることです。 これにより、サーバーの起動が速くなり、ストレージが小さくなるため、管理が容易になります。 また、単一のマスターキーは簡単に再生成できます。

ただし、マスターキー暗号化には大きな欠点が XNUMX つあります。それは、表領域が tablespace_key で暗号化されると、常に同じキーで暗号化されたままになるということです。 ここではマスターキーをローテーションしても役に立ちません。 なぜこれがデメリットなのでしょうか？ MySQL には、突然のクラッシュやコア ファイルの作成につながる可能性のあるバグがあることがわかっています。 コア ファイルにはサーバー メモリ ダンプが含まれているため、ダンプには復号化されたテーブルスペース キーが含まれる場合があります。 さらに悪いことに、復号化された表領域キーはメモリに保存され、ディスクに交換することができます。 これらのファイルとスワップ パーティションにアクセスするには root 権限が必要であるため、これは欠点ではないと言えます。 はい。 ただし、root が必要になるのはしばらくの間だけです。 復号化された表領域キーにアクセスできるようになると、root 権限がなくても、引き続きそのキーを使用してデータを復号化できます。 さらに、ディスクが盗まれ、サードパーティのツールを使用してスワップ パーティション/コア ファイルが読み取られる可能性があります。 TDE の目標は、ディスクが盗まれた場合でも読み取れないようにすることです。 で MySQL 用 Percona サーバー 新しく生成されたキーを使用してテーブルスペースを再暗号化することができます。 この機能は暗号化スレッドと呼ばれ、この記事の執筆時点ではまだ実験段階です。

コースについて詳しく見る

続きを読む：

• MySQL の暗号化: キーストア

出所： habr.com