web-dev-qa-db-ja.com

SQLServer列レベルの暗号化-ローテーションキー

機密データにSQLServerの列(セル)レベルの暗号化を使用することを検討しています。最初に列を暗号化するときは問題はないはずですが、暗号化キーを毎年変更する必要があるという要件があります。この要件は問題があるようです。

仮定:機密データを含む列を含むテーブルには、5億レコードが含まれます。

以下は、実装について考えた手順です。暗号化/復号化プロセス中、データはオンラインになりますか?また、このプロセスにはどのくらい時間がかかりますか?

  • 最初に列を暗号化します
  • 新年
  • 列を復号化する
  • 新しいキーで列を暗号化します。

質問:列が復号化/暗号化されているとき、データはオンラインですか(クエリに使用できます)? SQL Serverは、データがオンラインのときにキーを変更できる機能を提供しますか?

BarDev

保存データの再暗号化は法外なものになります。更新する5億件のレコードは、膨大なログ、大量のデータIOを生成し、数日ではないにしても数時間続き、全体として非常に混乱を招きます。言うまでもなく、操作エラーにより、データベース全体が完全に暗号化されたままになる可能性があります(つまり、データベースを復号化するためのキーがありません)。

私がお勧めするのは、キー階層の上位にあるキーをローテーションすることです。

  • 対称鍵を使用してデータを暗号化します。
  • 対称鍵を定期的に変更します。週に1回、新しいデータを生成し、新しいデータで新しいデータを暗号化しますが、古いデータは変更しないでください
  • 対称鍵を証明書で暗号化する
  • [〜#〜] decodebykeyautocert [〜#〜] を使用してデータを復号化し、正しい対称鍵の選択を自動的に処理します
  • 必要に応じて、対称鍵を暗号化する証明書をローテーションします。対称鍵は複数の証明書の暗号化をサポートしているため、新しい証明書を追加し、新しい証明書による暗号化をすべての対称鍵に追加してから、古い証明書を削除することは完全に可能です。

これと同様のスキームが大企業によって展開されることがよくあります。すべてのデータの再暗号化は、非常に法外なため、めったに行われません。複数の対称鍵を使用し、新しい鍵を頻繁に生成することで、対称鍵が危険にさらされた場合にプライバシーが失われる可能性を減らすことができます。対称鍵の復号化に使用される証明書をローテーションすると、データが同じ古い対称鍵で暗号化されていても、ローテーション後に侵害された証明書がデータにアクセスできなくなるため、証明書の侵害をある程度軽減できます。

確かに、証明書にアクセスできる場合はすべての対称鍵資料を抽出でき、証明書がローテーションすると、理論的には保存された鍵資料を使用してデータを復号化できる攻撃を想定できます(他の手段を使用) SQL Serverより)。しかし、これは、「ローテーションされる前に侵害された証明書にアクセスできる場合は、すべてのデータを復号化して復号化されたデータを保存できる」と言っていることと同じです。事実キーローテーションは、攻撃者にすでに失われているデータを回復します。

3
Remus Rusanu

確かに、復号化/暗号化を実行するアプリケーションを作成できます(SELECTデータを出力し、復号化し、新しいキーで再暗号化し、UPDATEで元に戻します-機密データはこの方法で暗号化されていない状態で保存されることはありません)。ただし、DBが大きくなるにつれて大きくなる、年間のキーローテーションに対してhugeのオーバーヘッドが発生します。再暗号化ダンスを行うのにかかる限り、2つのキーを維持しなければならないという問題もあります(成長率と暗号化の複雑さによっては、今は1時間、来年は数日になるかもしれません...)

年次変更要件の背後にあるビジネス/セキュリティロジックを評価し、復号化キーに適切な制御を実装し、代わりに「侵害または侵害の疑いがある場合」にキーを変更する要件を実装することで、同等のセキュリティを取得できるかどうかを確認できます。 ..

1
voretaq7