SQL Server 2005、asp.net、およびado.netを使用してWebアプリケーションを作成する必要があります。このアプリケーションに格納されているユーザーデータの多くは、暗号化する必要があります(HIPAAを読む)。SQL Server 2005の暗号化、asp.netおよびストアドプロシージャ
過去に暗号化が必要なプロジェクトでは、アプリケーションコードで暗号化/復号化されました。しかし、これは一般的にパスワードやクレジットカードの情報を暗号化するためのものでした。このアプリケーションでは、複数のテーブルの列を暗号化する必要があるため、暗号化の責任をデータレイヤーに押し込むことは、特に複数の暗号化タイプに対してSQL Server 2005のネイティブサポートが行われた場合より優れています。 (誰かが実証的な証拠を持っていれば他には確信が持てるかもしれません)
私はBOLと相談しましたが、私はかなりグッドを熟知しています。だから私はオンラインの記事やMSDNのドキュメントへのリンクを望んでいない(おそらく私はそれを読んでいる可能性が高い)。
私が今までに頭を抱えたのは、証明書を使用して開かれた対称キーを使用することです。だから、一回のセットアップ手順は、(理論的にはDBAによって実行される)
:
- CDに焼くとオフサイトに保存し、
- にファイルへのマスターキーをバックアップマスターキー を作成します。
- マスターキーを開いて証明書を作成します。
- 証明書をファイルにバックアップし、CDに書き込んでオフサイトに保管します。
- 証明書を使用して選択した暗号化アルゴリズムで対称鍵を作成します。
ストアドプロシージャ(または管理者による人間ユーザー)が暗号化されたデータにアクセスする必要がある場合は、最初に対称キーを開いてから、tsqlステートメントまたはバッチを実行してから対称キーを閉じます。
asp.netアプリケーションに関する限り、私のケースではアプリケーションコードのデータアクセスレイヤーでは、データの暗号化は完全に透過的です。
は、だから私の質問は以下のとおりです。
は、私は、オープンTSQL文/バッチを実行して、すべてのSPROC内の対称キーを閉じますか?私が見る危険は、何かがtsqlの実行に間違っていて、コードの実行がキーを閉じる文に決して達しない場合です。これは、sqlがsprocが実行されたSPIDを強制終了するまで、キーが開いたままであることを意味します。
代わりに、実行する必要のある任意のプロシージャ(暗号化が必要な場合のみ)に対して3回のデータベース呼び出しを行うことを検討する必要がありますか?キーを開くデータベース呼び出し、sprocを実行するための2回目の呼び出し、キーを閉じる3回目の呼び出し。
クライアントサイドのトランザクションを使用する必要があります(つまり、自分のコードがクライアントであることを意味します)。トランザクションを実行し、いくつかのsprocsを実行した後、トランザクションは成功したと見なします)。
私の証明書のパスワードをdba(情報を抽出する前にアプリケーション層からキーを開くためにSQL文を実行する)から保護するために2を探しています。それは良い習慣だと思いますか? (http://stackoverflow.com/questions/21213393/sql-server-how-to-limit-access-to-encrypted-column-even-from-dba)。ありがとう –