アプリサーバーとキーサーバー間のDEKおよびKEK（暗号化キー）の交換
私のアプリケーションでは、mysqlデータベースに挿入する前にユーザーのデータを暗号化する必要があります。私は、AESアルゴリズムを使用して、256ビットのハッシュを使用してデータを暗号化しています（これをデータ暗号化キー、つまりDEKと呼んでいます）。
システムをより安全にするために、DEKをプレーンテキストでアプリサーバーに保存する代わりに、暗号化された形式（en_dek）でアプリサーバーに保存されます。 DEKを暗号化するためのキーは、完全に別のサーバーに格納され、キー暗号化キー（KEK）と呼ばれます。したがって、データを暗号化/復号化するたびに、最初にKEKを使用してen_dekを復号化し、実際のDEKを取得します。次に、このDEKを使用してユーザーのデータを暗号化/復号化します。
今私の質問は：
[1]キーサーバーに（en_dek +データ）を送信する必要がありますか、それともアプリサーバーにKEKをフェッチする必要がありますか？安全な方法はどれですか？
[2]これらの方法には両方とも、攻撃者がこれらのサーバーのいずれかにアクセスできる場合、KEKとDEKの両方を知ることができるという欠陥があります。どうすればこれを防ぐことができますか？
[3]キーローテーションについて話すとき、2つのキー（DEKとKEK）のどちらがローテーションされますか？
（en_dek + data）をキーサーバーに送信する必要がありますか、それともアプリサーバーにKEKをフェッチする必要がありますか？安全な方法はどれですか？
キーを送信するen_dek処理するキーサーバーには、 ハードウェアセキュリティモジュール が高レベルで機能する方法がほとんどあります。このアプローチの利点は、キーマテリアルがアプリケーションサーバーに触れないことです。そのため、アプリケーションサーバーが侵害されると、現在メモリ内にあるキーだけが解読され、解読要求がキーサーバーに送信される可能性があります。ただし、攻撃者がマスターキー自体に自動的にアクセスすることはありません。これは重要です。
別のシステムにデータを送信して復号化することについてすでに話しているので、単純にデータを送信して、アプリケーションサーバーからキーを完全に隠す方が良いのではないでしょうか。
このようなスキームでは、キーのセキュリティは、それが格納されているサーバーまたはHSMのセキュリティに完全に依存します。通常、真のHSMは、電子機器に非常に慣れていない限り、キーの保護に適度に優れています。
これらの方法には、攻撃者がこれらのサーバーのいずれかにアクセスできる場合、KEKとDEKの両方を知ることができるという欠陥があります。どうすればこれを防ぐことができますか？
専用のHSMを使用する場合を除いて、これはできません。これは、基本的に、構築について話し合っていることです。スキームを簡略化し、暗号化操作専用の1台のサーバーにキーを保持し、そのサーバーをロックしておきます。
これらの2つのポイントの詳細については、 暗号化ストレージに関するOWASPルール を参照してください。
キーのローテーションについて話すとき、2つのキー（DEKとKEK）のどちらがローテーションされますか？
理想的には、両方です。 DEKは固定サイズであり、DEKの数はそれほど多くないはずなので、KEKの回転はより簡単になるはずです。大量のデータを暗号化している場合は、DEKのローテーションが難しくなることがあります。
OWASPページから、私ができるよりも良いと言っています：
鍵の再生成とは、データを復号化し、新しい鍵で再暗号化するプロセスを指します。定期的にデータのキーを再生成すると、古いキーの未検出の侵害からデータを保護できます。適切な鍵更新期間は、鍵のセキュリティによって異なります。専用のハードウェアセキュリティモジュールで保護されたキーで保護されたデータは、3年ごとに鍵の再生成のみが必要な場合があります。分割されて2つのアプリケーションサーバーに保存されたキーで保護されたデータは、毎年キーの再生成が必要になる場合があります。