So steuern Sie, welche Benutzer SQL Server-Verschlüsselung mit symmetrischen Schlüsseln entschlüsseln können

Question

Ich untersuche die Verschlüsselung einiger sensibler Daten in SQL Server, z. B. Bankkontonummern und Sozialversicherungsnummern, um den neuen Landesgesetzen zu entsprechen. Ich verwende SQL Server 2008 als meine Datenbank mit .NET-Code. Ich habe .NET verwendet, um Passwörter zu verschlüsseln, aber dafür denke ich über die integrierte Verschlüsselung von Microsoft nach, indem ich einfach die wenigen Datenspalten verschlüssle, die ich mit einer einfachen Symmetric Key Encryption benötige. Wenn ich SQL Server-Verschlüsselung gehe, kann ich die Daten von externen Reporting-Tools und nicht nur in meiner .NET-Anwendung entschlüsseln. Hier ist das Beispiel, das ich bin mit: http://blog.sqlauthority.com/2009/04/28/sql-server-introduction-to-sql-server-encryption-and-symmetric-key-encryption-tutorial-with-script/

Es verwendet ein Zertifikat, das von SQL Server erstellt und dann der DecryptByKey Funktion, um die Daten zu entschlüsseln, aber ich versuche, um zu bestimmen, wie sicher es wirklich ist? Wie kann ich steuern, welche Benutzer Daten entschlüsseln können oder kann dies jemand tun, solange sie den symmetrischen Schlüssel öffnen und die Entschlüsselungsfunktion verwenden?

Answer 1

Sie haben zwei Alternativen:

1. Cryptographic Kontrolle. Damit können nur die Benutzer, die das Passwort kennen, die Daten entschlüsseln. Der Nachteil ist, dass der Benutzer bei jedem Zugriff auf die Daten das Entschlüsselungspasswort eingeben muss. Ein Bericht muss einen Password-Parameter enthalten, mit dem der Benutzer, der den Bericht ausführt, das Datenzugriffskennwort erhält. Die Anwendung muss das Passwort vom Benutzer anfordern. Websites müssen ein Passwort vom Besucher anfordern. Und so weiter und so weiter

2. Zugangskontrolle. Die Daten werden mit einem Schlüssel verschlüsselt, auf den SQL Server selbst Zugriff hat (die Encryption-Kette geht schließlich bis zum Service Master Key, der mit DPAPI verschlüsselt wird). Dies gibt Ihnen keinen besseren Schutz, als Ihnen SELECT oder SELECT geben würde: ist Zugriff Kontrolle, nicht kryptografische Kontrolle. Solch ein Schema schützt nur gegen unbeabsichtigten Verlust von Medien (jemand findet eine Diskette mit Ihrer Datenbank, oder Sie verlieren einen Laptop mit der Datenbank darauf). Sie können dasselbe erreichen, indem Sie Transparent Data Encryption oder die Verschlüsselung auf Dateiebene (BitLocker) verwenden.

Die gemeinsame Datenverschlüsselungs Szenario werden die Daten mit einem symmetrischen Schlüssel zu verschlüsseln, und dann encryt der symmetrische Schlüssel mit einem asymmetrischen Schlüssel (in der Regel der private Schlüssel eines Zertifikat). Der asymmetrische Schlüssel wird dann wiederum mit einem Passwort verschlüsselt, und dieses Passwort muss beim Versuch, auf Daten zuzugreifen, präsentiert werden. Der Hauptgrund für diese Umleitung auf zwei Ebenen ist die Passwortänderung: Wenn ein Passwort oder ein privater Schlüssel kompromittiert wird, wird der symmetrische Schlüssel mit einem anderen asymmetrischen Schlüssel neu verschlüsselt oder der asymmetrische Schlüssel wird mit einem anderen Passwort neu verschlüsselt. Auf diese Weise hat sich das Zugangspasswort geändert , ohne eine erneute Verschlüsselung aller Daten. Wenn der Zugriff direkt dem symmetrischen Schlüssel gewährt würde, würde eine Kennwortkompromittierung möglicherweise eine Neuverschlüsselung aller möglichen Terabytes von Daten erforderlich machen.

Die zwei Szenarien, die ich vorstelle, unterscheiden sich darin, ob der asymmetrische Schlüssel auch mit dem Datenbankhauptschlüssel verknüpft ist oder nicht. Fall 1) ist es nicht, Fall 2) ist es. Dies ist alles in Encryption Hierarchy erläutert.