SQL Server 2005-Verschlüsselung, asp.net und gespeicherte Prozeduren

Question

Ich muss eine Webanwendung mit SQL Server 2005, asp.net und ado.net schreiben.Ein Großteil der in dieser Anwendung gespeicherten Benutzerdaten muss verschlüsselt werden (siehe HIPAA).

In der Vergangenheit habe ich bei Projekten, die eine Verschlüsselung erforderten, den Anwendungscode verschlüsselt/entschlüsselt.Allerdings diente dies im Allgemeinen der Verschlüsselung von Passwörtern oder Kreditkarteninformationen, sodass nur eine Handvoll Spalten in einigen Tabellen vorhanden waren.Für diese Anwendung müssen weitaus mehr Spalten in mehreren Tabellen verschlüsselt werden. Daher gehe ich davon aus, dass die Verlagerung der Verschlüsselungsverantwortlichkeiten in die Datenschicht zu einer besseren Leistung führen wird, insbesondere angesichts der nativen Unterstützung mehrerer Verschlüsselungstypen durch SQL Server 2005.(Ich könnte vom Gegenteil überzeugt werden, wenn jemand echte, empirische Beweise hätte.)

Ich habe BOL konsultiert und bin ziemlich geschickt im Umgang mit Google.Daher möchte ich keine Links zu Online-Artikeln oder MSDN-Dokumentation (wahrscheinlich habe ich sie bereits gelesen).

Ein Ansatz, über den ich bisher nachgedacht habe, ist die Verwendung eines symmetrischen Schlüssels, der mithilfe eines Zertifikats geöffnet wird.

Die einmaligen Einrichtungsschritte sind also (theoretisch von einem DBA durchgeführt):

1. Erstellen Sie einen Hauptschlüssel
2. Sichern Sie den Hauptschlüssel in einer Datei, brennen Sie ihn auf CD und speichern Sie ihn extern.
3. Öffnen Sie den Hauptschlüssel und erstellen Sie ein Zertifikat.
4. Sichern Sie das Zertifikat in einer Datei, brennen Sie es auf CD und speichern Sie es extern.
5. Erstellen Sie mithilfe des Zertifikats den symmetrischen Schlüssel mit dem Verschlüsselungsalgorithmus Ihrer Wahl.

Jedes Mal, wenn eine gespeicherte Prozedur (oder ein menschlicher Benutzer über Management Studio) auf verschlüsselte Daten zugreifen muss, müssen Sie zuerst den symmetrischen Schlüssel öffnen, alle TSQL-Anweisungen oder Batches ausführen und dann den symmetrischen Schlüssel schließen.

Was die asp.net-Anwendung und in meinem Fall die Datenzugriffsschicht des Anwendungscodes betrifft, ist die Datenverschlüsselung völlig transparent.

Meine Fragen sind also:

1. Möchte ich den symmetrischen Schlüssel innerhalb des Sproc öffnen, ausführen und dann schließen?Die Gefahr, die ich sehe, besteht darin, was passiert, wenn bei der TSQL-Ausführung etwas schief geht und die Sproc-Ausführung des Codes nie die Anweisung erreicht, die den Schlüssel schließt.Ich gehe davon aus, dass dies bedeutet, dass der Schlüssel geöffnet bleibt, bis SQL die SPID beendet, auf der Sproc ausgeführt wurde.

2. Sollte ich stattdessen in Betracht ziehen, drei Datenbankaufrufe für jede bestimmte Prozedur durchzuführen, die ich ausführen muss (nur wenn eine Verschlüsselung erforderlich ist)?Ein Datenbankaufruf zum Öffnen des Schlüssels, ein zweiter Aufruf zum Ausführen des Sproc und ein dritter Aufruf zum Schließen des Schlüssels.(Jeder Aufruf wird in eine eigene Try-Catch-Schleife eingeschlossen, um die Wahrscheinlichkeit zu maximieren, dass ein offener Schlüssel letztendlich geschlossen wird.)

3. Irgendwelche Überlegungen, ob ich clientseitige Transaktionen verwenden muss (das heißt, mein Code ist der Client und initiiert eine Transaktion, führt mehrere Sprocs aus und schreibt dann die Transaktion fest, sofern sie erfolgreich ist)?

Answer 1

1) Schauen Sie in mit try..catch in SQL 2005. Leider gibt es keine ENDLICH, so dass Sie sowohl einzeln als den Erfolg und die Fehlerfälle behandeln müssen.

2) Nicht erforderlich, wenn (1) übernimmt die Reinigung.

3) Es ist nicht wirklich ein Unterschied zwischen Client und Server-Transaktionen mit SQL Server. Connection.BeginTransaction () mehr oder weniger ausführt „BEGIN TRANSACTION“ auf dem Server (System.Transactions und / Transaction macht das gleiche, bis es zu einer verteilten Transaktion gefördert wird). Was Bedenken offen / innerhalb einer Transaktion der Taste mehrmals zu schließen, ich weiß nicht von irgendwelchen Fragen bewusst zu sein.

Answer 2

Ich bin ein großer Fan von Option 3.

Stellen Sie sich für eine Minute vor, Sie würden sowieso eine Transaktionsinfrastruktur einrichten, bei der:

1. Immer wenn ein Aufruf des Datenspeichers erfolgen sollte und keine bestehende Transaktion gestartet wurde, wurde eine erstellt.
2. Wenn bereits eine Transaktion vorhanden ist, werden Aufrufe an den Datenspeicher in diese Transaktion eingebunden.Dies ist häufig für Geschäftsregeln nützlich, die durch Speicher-/Zur-Datenbank-Ereignisse ausgelöst werden.IE.Wenn Sie die Regel hätten, dass Sie bei jedem Verkauf eines Widgets eine WidgetAudit-Tabelle aktualisieren müssen, würden Sie den Widget-Audit-Insert-Aufruf wahrscheinlich in dieselbe Transaktion einschließen wollen, die dem Datenspeicher mitteilt, dass ein Widget verkauft wurde.
3. Immer wenn der ursprüngliche Aufrufer des Datenspeichers (aus Schritt 1) ​​fertig ist, wird die Transaktion festgeschrieben bzw. zurückgesetzt, was sich auf alle Datenbankaktionen auswirkt, die während des Aufrufs ausgeführt wurden (mittels try/catch/finally).

Sobald diese Art von Transaktion erstellt ist, ist es einfach, am Anfang (wenn die Transaktion eröffnet wird) einen offenen Schlüssel anzubringen und am Ende (kurz bevor die Transaktion endet) zu schließen.„Aufrufe“ an den Datenspeicher sind bei weitem nicht so teuer wie das Herstellen einer Verbindung zur Datenbank.Es sind wirklich Dinge wie SQLConnection.Open(), die Ressourcen verbrennen (auch wenn ADO.NET sie für Sie bündelt).

Wenn Sie ein Beispiel für diese Art von Codes wünschen, würde ich einen Blick auf NetTiers werfen.Es bietet eine recht elegante Lösung für die gerade beschriebene Transaktion (vorausgesetzt, Sie haben nicht bereits etwas im Sinn).

Nur 2 Cent.Viel Glück.

Answer 3

1. Sie können @@ Fehler verwenden, um zu sehen, ob Fehler während des Anrufs zu einem sproc in SQL.

aufgetreten

2. Nein zu kompliziert.

3. Sie können aber ich ziehe Transaktionen in SQL Server selbst verwenden.