6

SQL Server 2005、asp.net、および ado.net を使用して Web アプリケーションを作成する必要があります。このアプリケーションに保存されているユーザー データの多くは、暗号化する必要があります (HIPAA を参照)。

以前は、暗号化が必要なプロジェクトでは、アプリケーション コードで暗号化/復号化を行っていました。ただし、これは通常、パスワードやクレジット カード情報を暗号化するためのものでした。このアプリケーションでは、いくつかのテーブルのはるかに多くの列を暗号化する必要があるため、特に SQL Server 2005 がいくつかの暗号化タイプをネイティブでサポートしていることを考えると、暗号化の責任をデータ レイヤーにプッシュする方がパフォーマンスが向上すると思います。（誰かが実際の経験的証拠を持っていれば、そうではないと確信できます。）

私は BOL に相談したことがありますが、Google の使い方にはかなり慣れています。したがって、オンラインの記事や MSDN のドキュメントへのリンクは必要ありません (既に読んでいる可能性があります)。

これまでに頭を悩ませてきた 1 つのアプローチは、証明書を使用して開かれる対称キーを使用することです。

したがって、1 回限りのセットアップ手順は次のとおりです (理論的には DBA によって実行されます)。

  1. マスターキーを作成する
  2. マスター キーをファイルにバックアップし、CD に書き込み、オフサイトに保存します。
  3. マスター キーを開き、証明書を作成します。
  4. 証明書をファイルにバックアップし、CD に書き込み、オフサイトに保存します。
  5. 証明書を使用して、選択した暗号化アルゴリズムで対称キーを作成します。

次に、ストアド プロシージャ (または Management Studio を介した人間のユーザー) が暗号化されたデータにアクセスする必要があるときはいつでも、最初に対称キーを開き、tsql ステートメントまたはバッチを実行してから、対称キーを閉じる必要があります。

次に、asp.net アプリケーションに関する限り、そして私の場合はアプリケーション コードのデータ アクセス レイヤーに関する限り、データ暗号化は完全に透過的です。

だから私の質問は：

  1. 開いて、tsql ステートメント/バッチを実行し、対称キーをすべて sproc 内で閉じますか? 私が見る危険は、tsql の実行で何か問題が発生し、コード sproc の実行がキーを閉じるステートメントに到達しない場合です。これは、sproc が実行された SPID を SQL が強制終了するまで、キーが開いたままになることを意味すると思います。

  2. 代わりに、実行する必要がある特定のプロシージャに対して 3 つのデータベース呼び出しを行うことを検討する必要がありますか (暗号化が必要な場合のみ)。キーを開くための 1 回のデータベース呼び出し、sproc を実行するための 2 回目の呼び出し、およびキーを閉じるための 3 回目の呼び出し。(開いているキーが最終的に閉じられる可能性を最大化するために、各呼び出しは独自の try catch ループでラップされます。)

  3. クライアント側のトランザクションを使用するために必要な考慮事項はありますか (私のコードはクライアントであり、トランザクションを開始し、いくつかの sproc を実行し、成功すると仮定してトランザクションをコミットすることを意味します)?

4

3 に答える 3

3

1) SQL 2005 での TRY..CATCH の使用を検討してください。残念ながら FINALLY がないため、成功とエラーの両方のケースを個別に処理する必要があります。

2) (1) がクリーンアップを処理する場合は必要ありません。

3) SQL Server では、クライアント トランザクションとサーバー トランザクションの間に実際の違いはありません。Connection.BeginTransaction() は多かれ少なかれ、サーバー上で「BEGIN TRANSACTION」を実行します (分散トランザクションに昇格するまで、System.Transactions/TransactionScope も同じことを行います)。トランザクション内でキーを複数回開いたり閉じたりすることに関する懸念については、注意すべき問題はありません。

于 2008-09-12T22:41:47.177 に答える
1

私はオプション3の大ファンです。

とにかく次の場所でトランザクションインフラストラクチャをセットアップしようとしていたふりをします。

  1. 既存のトランザクションが開始されていない場合にデータストアへの呼び出しが行われるたびに、トランザクションが作成されました。
  2. トランザクションがすでに実行されている場合は、データストアへの呼び出しがそのトランザクションにフックします。これは、save/going-to-the-databaseイベントによって発生するビジネスルールに役立つことがよくあります。IE。ウィジェットを販売するたびにWidgetAuditテーブルを更新する必要があるというルールがある場合は、データストアにウィジェットが販売されたことを通知するトランザクションと同じトランザクションでウィジェット監査挿入呼び出しをラップすることをお勧めします。
  3. データストアへの元の呼び出し元（ステップ1から）が終了するたびに、トランザクションをコミット/ロールバックします。これは、呼び出し中に発生したすべてのデータベースアクションに影響します（try / catch / finalを使用）。

このタイプのトランザクションが作成されると、最初（トランザクションが開いたとき）に開いているキーを追加し、最後（トランザクションが終了する直前）にキーを閉じることが簡単になります。データストアへの「呼び出し」は、データベースへの接続を開くほど費用がかかりません。リソースを消費するのは、実際にはSQLConnection.Open（）のようなものです（ADO.NETがリソースをプールしている場合でも）。

これらのタイプのコードの例が必要な場合は、NetTiersを検討することを検討します。これは、先ほど説明したトランザクションに対して非常に洗練されたソリューションを備えています（まだ何かを考えていない場合）。

わずか2セント。幸運を。

于 2008-09-13T07:04:49.230 に答える
0

  1. @@error を使用して、SQL の sproc の呼び出し中にエラーが発生したかどうかを確認できます。

  2. いいえ、複雑ではありません。

  3. できますが、私は SQL Server 自体でトランザクションを使用することを好みます。

于 2008-09-12T22:10:42.900 に答える