DB内の機密性の高い列を暗号化するための良い方法を見つけようとしています。私は、SQL Serverの組み込みの暗号化メカニズムがそのトリックを行うと思ったが、私は何かが欠けているか間違っているかのどちらかだと思った。SQL Server 2008の列暗号化
元の計画は、対称キーで暗号化された列を持つ表を作成し、その表から暗号化されていないデータを選択するビューを作成することでした。しかし、私は、ビューのselectステートメントでDecryptByKeyメソッドを使用する方法を理解することができませんでした。さらに、データが暗号化されずにビューに出てきてしまうので、接続が安全でなければ無意味になります。
私はすべての暗号化/復号化を私のアプリに持って来ると思っていました。私はDBは、独自のデータを復号化することが完全にできなかった場合は、DBを浸潤誰かがすべてで多くを行うことができないだろう
ことを考え出しました。
DB内の暗号化/復号化が単一のワークステーションではなくグローバルにパフォーマンスに影響を及ぼす可能性があるため、情報を復号化/暗号化しようとすると、サーバが省力化されます。
私のアプリには、暗号化が必要な各列のIVとキーが「ハードコード」されています。暗号化された情報をDBに送信し、暗号化された情報をDBから受信します。これはちょうどあなたの心の周りに混乱のためです、私はIVとキーをどこかに置かなければならないことを知っています...彼らは単にアプリケーションコードでは安全ではありません。
私はこのクレイジーなアイデアを考えていた：
クライアントアプリは、単一のキーとIVが含まれています。サーバーは、暗号化されたすべての列のキー/ IVを1つのテーブルに格納します。ただし、Keys/IVの値は、クライアントアプリが保持するKey/IVで暗号化されます。
起動時に、クライアントアプリケーションは、DBからすべてのキー/ IVをメモリにロードし、必要に応じて復号化して、サーバーから選択されたデータを表示します。
また、使用を許可されたキーをユーザーに参加させる関係もあります。だから、アプリは、ユーザーが見る権限を与えられた列のみを復号化します。
あなたはそのアイデアは勝っていると思われますか？そして、あなたの中には、クライアント/アプリ/ SQL Serverのシナリオを考えれば、どのように暗号化を実装したのでしょうか？
本当にそうだろうか？この計画は、社会保障番号、電話番号、クレジットカード番号などの機密性の高い「データのみ」の列を暗号化することを計画していました。私が通常は索引付けしない列。 – instantmusic
それでは大丈夫です。データを扱うだけで苦労するでしょう。報告に似ています。 IMHOはまだアプリケーションレベルでのセキュリティー、TPMを備えたサーバーと提供されたmeahcnisms（すなわち、ディスク暗号化）によるデータセキュリティーを処理します。 – TomTom