機密データにSQLServerの列(セル)レベルの暗号化を使用することを検討しています。最初に列を暗号化するときは問題はないはずですが、暗号化キーを毎年変更する必要があるという要件があります。この要件は問題があるようです。
仮定:機密データを含む列を含むテーブルには、5億レコードが含まれます。
以下は、実装について考えた手順です。暗号化/復号化プロセス中、データはオンラインになりますか?また、このプロセスにはどのくらい時間がかかりますか?
質問:列が復号化/暗号化されているとき、データはオンラインですか(クエリに使用できます)? SQL Serverは、データがオンラインのときにキーを変更できる機能を提供しますか?
BarDev
保存データの再暗号化は法外なものになります。更新する5億件のレコードは、膨大なログ、大量のデータIOを生成し、数日ではないにしても数時間続き、全体として非常に混乱を招きます。言うまでもなく、操作エラーにより、データベース全体が完全に暗号化されたままになる可能性があります(つまり、データベースを復号化するためのキーがありません)。
私がお勧めするのは、キー階層の上位にあるキーをローテーションすることです。
これと同様のスキームが大企業によって展開されることがよくあります。すべてのデータの再暗号化は、非常に法外なため、めったに行われません。複数の対称鍵を使用し、新しい鍵を頻繁に生成することで、対称鍵が危険にさらされた場合にプライバシーが失われる可能性を減らすことができます。対称鍵の復号化に使用される証明書をローテーションすると、データが同じ古い対称鍵で暗号化されていても、ローテーション後に侵害された証明書がデータにアクセスできなくなるため、証明書の侵害をある程度軽減できます。
確かに、証明書にアクセスできる場合はすべての対称鍵資料を抽出でき、証明書がローテーションすると、理論的には保存された鍵資料を使用してデータを復号化できる攻撃を想定できます(他の手段を使用) SQL Serverより)。しかし、これは、「ローテーションされる前に侵害された証明書にアクセスできる場合は、すべてのデータを復号化して復号化されたデータを保存できる」と言っていることと同じです。事実キーローテーションは、攻撃者にすでに失われているデータを回復します。
確かに、復号化/暗号化を実行するアプリケーションを作成できます(SELECT
データを出力し、復号化し、新しいキーで再暗号化し、UPDATE
で元に戻します-機密データはこの方法で暗号化されていない状態で保存されることはありません)。ただし、DBが大きくなるにつれて大きくなる、年間のキーローテーションに対してhugeのオーバーヘッドが発生します。再暗号化ダンスを行うのにかかる限り、2つのキーを維持しなければならないという問題もあります(成長率と暗号化の複雑さによっては、今は1時間、来年は数日になるかもしれません...)
年次変更要件の背後にあるビジネス/セキュリティロジックを評価し、復号化キーに適切な制御を実装し、代わりに「侵害または侵害の疑いがある場合」にキーを変更する要件を実装することで、同等のセキュリティを取得できるかどうかを確認できます。 ..