2

SQLServerに共有ホスティングを使用します。主キー列（自動生成ID）とvarchar列を暗号化したかったのです。私は周りを検索してTDEに出くわしました。しかし、共有ホスティングなので、私はそれを使用することはできません。だから、代替案を探していました。データはすでにテーブルにあるため、アプリケーションからの暗号化は現在不可能です。そして、上記のvarchar列を使用して検索するSQLステートメントはたくさんあります。したがって、パフォーマンスも問題になります。

ありがとう、開発者

4

2 に答える 2

1

主キー列を暗号化（自動生成ID）

また、ID が暗号化されている場合、どのようにしてレコードを見つけることができますか?? 「暗号化された ID で検索します」と答えると、キーをソルトしていないことを失格とします...

そして今、本当の問題です。あなたは共有ホスティングに展開すると言いましたが、暗号化が提供することを期待している種類の保護については言及していません. 問題は鍵の管理です。データはキーで暗号化され、サーバーはその dtaa を何らかの方法で復号化する必要があります。どのように問題を回避しても、他のすべてのキーを復号化するために使用されるルート キーも共有ホスティングでは、データへの道のりでわずかなバンプしか達成できません。フェンスを設置するには、共有ホスティングの範囲外のどこかからキーを取得する必要があります。アプリケーションは、ユーザーと対話するときにルート キーを復号化するためのパスワードを要求しますが、これは実際には不可能です。ルート オブ トラストは、TDE でもコラムナー暗号化でもまったく同じ問題を抱えているため、TDE は何も解決しないことに注意してください。プライバシーが必要な場合は、プライベート ホスティングを使用してください。

そして、質問に答えるために：

また、列暗号化を使用する場合、主キーを暗号化することはありません。そうすることはまったく無意味です。そして、共有ホスティング環境であらゆる種類のプライバシーを主張することは夢物語です. 保護できる唯一のことは、せいぜい、偶発的なメディアの損失 (フリー マーケットでホストしている HDD が見つかること) です。

于 2012-06-20T12:20:30.420 に答える
0

Dev、あなたの場合、唯一の選択肢はアプリケーションから暗号化することだと思います。

または、テーブルの名前を変更し、名前を変更したテーブルの代わりに VIEW に置き換えることもできます。既存のすべてのデータを暗号化します: update real_table set field1 = call_encrypt_function(field1), field2 = call_encrypt_function(field2) そのビューでは、real_table から call_decrypt_function(field1),call_decrypt_function(field2) を選択できます。挿入と更新については、INSTEAD OF INSERT および INSTEAD OF UPDATE トリガーを習得する必要があります。もちろん、そのオブジェクトには WITH ENCRYPTION を使用する必要があります。XP_CRYPT でそのアプローチを見ましたが、私は無料のソリューションを好みます。SQL Server は、基本的な暗号化機能を無料で提供しています。

于 2013-03-27T05:50:55.460 に答える