web-dev-qa-db-ja.com

SQL Server 2016で常に暗号化されたAND列レベルの暗号化を組み合わせる

SQL Server 2016を使用して機密性の高い列データを暗号化する必要があり、確定的アプローチを使用してこれらの列を暗号化するために、常に暗号化（AE）機能を選択しました。

AE確定的暗号化では、これらの暗号化された列に対する不等式、範囲、またはLIKEクエリは許可されないため、対称キー（列レベル）暗号化技術を使用して、これらのタイプの列の暗号化を試みました。

特定の列（不等式、範囲、またはLIKEクエリを必要としない）にAE機能を実装し、不等式、範囲、またはLIKEクエリを生成する必要がある列に対称キー型暗号化を実装することは良い方法ですか？

パフォーマンス、セキュリティ、メンテナンスを考慮して、AE暗号化と列レベルの暗号化を1つのテーブルで組み合わせるのは良い習慣ですか？

専門家のアドバイスをお願いします。

sql-serversql-server-2016encryptionalways-encrypted
7
Sri

SQL Serverの複数の暗号化タイプに関する決定的な「ベストプラクティス」リストにまだ出会っていませんが、あなたの状況では、おそらく以下をお勧めします。

  1. Always Encryptを使用して必要なデータを暗号化する
    • その新しい辛さ。 2016年です。お楽しみください。
    • セキュリティの向上-キーはデータベースの外部に保存されるため、DBAはデータを復号化できません。
    • その他のオプション 個々のクエリを調整し、機能のパフォーマンスへの影響を軽減します。
    • 列レベルの暗号化のようにクエリを変更するのではなく、ドライバーパラメーターを構成するだけでよいため、データベース側とアプリ側の両方で最も簡単に実装できます（TDEがオプションでない場合）。
    • 追加の復号化負荷は、アプリケーション（特にドライバー）の問題になります（DBAとしては問題ありません）。
    • この機能は新しいので、しばらくの間、改善および最適化される可能性があります（私の意見）。
  2. 検索する必要がある列については、 ハッシュ値を作成 で検索します。
    • データのセキュリティを維持しますが、ルックアップには非常に効率的です。すべての行を復号化したり、デフォルトでテーブルスキャンしたりするオーバーヘッドなしで、通常の行を検索するパフォーマンスを実現できます。必要に応じて、さらにパフォーマンスを上げるためにインデックスを作成できます。
      • アプリはユーザー入力を受け取ってハッシュし、そのハッシュ値を使用して、テーブルに保存されているハッシュバージョンをクエリします。このルックアップは高速であり、目的の行のみを解読できるのに対して、結果セットの一部として実際には必要ない行を解読できます。
    • これの設計は、検索する必要がある列の数と、WHERE句で複数の列を使用するか、個別の列を使用するかによって異なります。
    • 余裕がある限り、パフォーマンスにとって余分なスペースは価値があります。
  3. 列レベルの暗号化を使用しないでください
    • 検索を行うには、列全体を復号化する必要があります。これは、暗号化されていないハッシュ列よりも効率が悪くなります。つまり、テーブルが大きくなるほど、この方法は非効率になります。 100万行は、フィルターが1行しか返さない場合でも、CPUを使用して100万行を復号化する必要があることを意味します。検索を実行できるからといって、それが高性能であるとは限りません。
    • 同じテーブル内で2つの暗号化機能を長期間維持することは、混乱していて、せいぜい部族の知識になっていることがわかります。

列レベルの暗号化を使用して＃2を実装することもできますが、適切な制約がないため、一般的に常に暗号化よりもCLEを選択する理由がわかりません。

暗号化をアプリケーションの問題にすることについて冗談を言っていますが、多くの場合、データベースは多くの場合、本来よりもはるかに多くのビジネスロジックと奇抜な機能に悩まされています。一部の計算をアプリケーション側に戻すオプションがある場合、それが一般的に最良のオプションであり、トラブルシューティングや一般的なチューニングが悪夢になるのを防ぐのに役立ちます。

もちろん、代替案を十分にテストする必要があります。 CLEまたはコンボが見つかった場合は、特定のシナリオに最適です。

追加の読み：

10
LowlyDBA