SQL Server 2016 の行レベル セキュリティ機能で Always Encrypted 機能を使用することはできますか? そして、特定のユーザーが表示する行に関して、異なる EncryptionKeys で行を暗号化しますか?
1 に答える
1
それは役に立ちます。簡単に言えば、今日の AE と RLS では簡単にはできません。
AE は現在、列スコープです。特定の列暗号化キー (CEK) を使用して列全体を暗号化します。テーブル内の複数の列をそれぞれ独自の CEK で暗号化できますが、それでも列の範囲が限定されます。現在の AE 実装では、行を論理的にグループ化し、独自のキーで暗号化することはできません。これが本当に重要な場合は、https://connect.microsoft.com/SQLServer/feedback/からチームに提案を送信できます。
とはいえ、規制や企業ポリシーの要件を満たすことを除けば、現在提案されている設計から得られるものはあまりありません。ユーザー (またはユーザーのグループ) の数が非常に少ないため、行のグループの数が非常に少ない場合を除き、すぐに CEK の急増に遭遇します。管理するのは難しいことではありませんが、それでも面倒で、多くの作業が必要になる可能性があります。たとえば、各ユーザーまたはユーザーのグループには、アプリまたはワークステーションにプッシュされたキーにアクセスするための独自のキーまたはシークレットが必要です。複雑で可動部品が多いということは、故障のリスクが高くなることを意味します。さらに、監査シーズン中はさらに「楽しい」場合があります（もちろん、監査人によって異なります）。
あなたの目標をもう一度述べるとしたら、1. データは常に権限のない人から守られていること 2. 許可されたユーザーは、閲覧が許可されているデータのみを閲覧できること
正しく実装された AE は、#1 の要件を満たします。キーがないと、暗号文だけが表示されます。確かに、力ずくで攻撃したり、暗号化アルゴリズムや SQL Server の実装の欠陥を見つけたりすることはできますが、ハリウッドが私たちに信じさせたいと思っているよりもはるかに簡単な方法があります。
RLS は、ほとんどの状況で #2 に対処します。実装はクエリ プロセッサ レベルで行われるため、RLS を回避することは非常に困難です。それが可能になるには、RLS にバグがなければなりません。RLS フィルターが暗号化されていない列に基づいている場合 (実際には暗号化されている必要があります)、クライアントが危険にさらされない限り、誰かがメモリ/ネットワークから秘密を傍受する可能性はありません。
したがって、CEK が 1 つしかない場合でも、両方の要件が満たされます。これにより、管理する表面積が小さくなり、長期的には生活がずっと楽になります。これにより、ほとんどの場合、より安全な環境が得られます。別々のキーを持つことで、紙の上では多層防御に優れたレイヤーが追加されますが、実際には、他の領域 (アラート、ユーザー教育など) でより多くの成果が得られます。
于 2015-11-19T17:44:38.510 に答える