SQL Server 2016 Always Encrypted: Einfach zu implementieren, schwer zu knacken

Daten sind ein wichtiger Vermögenswert jedes Unternehmens, insbesondere Transaktionsdaten, die Geschäftsgeheimnisse wie Finanz- oder Krankenakten enthalten. Daten sind am anfälligsten bei der Übertragung zwischen dem Server, der sie speichert, und dem Client, der sie anfordert.

Der Standardansatz zur Gewährleistung der Sicherheit besteht darin, Daten auf dem Server zu verschlüsseln und das SSL-fähige HTTPS-Protokoll zu verwenden, um Daten während des Transports zu sichern. Was wäre jedoch, wenn wir das Sicherheitsniveau noch weiter erhöhen könnten, indem wir HTTPS verwenden und Daten in einem verschlüsselten Format über die Kommunikationsleitung senden, nur um Daten auf Clients zu entschlüsseln, die über gültige Zertifikate verfügen? Dieser Ansatz würde einen traditionellen Man-in-the-Middle-Angriff (MITM) erheblich erschweren.

Die Lösung von Microsoft für dieses Problem ist Always Encrypted, eine Möglichkeit, verschlüsselte Daten über die Pipeline zu senden und sie nur von Benutzern mit Zugriff auf gültige Zertifikate zu entschlüsseln. Selbst wenn der Angreifer die Daten erhält, wären die Daten ohne ein ordnungsgemäßes Zertifikat, das auf dem Client-Computer gespeichert ist, nutzlos.

Dieser Artikel beschreibt, wie Always Encrypted eingerichtet und verwendet wird, und wird jedem empfohlen, der wichtige Daten über die öffentlichen Kommunikationsleitungen sendet, auch wenn diese mit SSL gesichert sind.

Das Konzept hinter Always Encrypted

Always Encrypted ist eine clientseitige Verschlüsselungstechnologie, die Microsoft mit SQL Server 2016 eingeführt hat. Always Encrypted hält Daten automatisch verschlüsselt, nicht nur beim Schreiben, sondern auch beim Lesen durch eine genehmigte Anwendung. Im Gegensatz zur transparenten Datenverschlüsselung, bei der die Daten und Protokolldateien auf der Festplatte in Echtzeit verschlüsselt werden, die Daten jedoch von jeder Anwendung gelesen werden können, die die Daten abfragt, erfordert Always Encrypted, dass Ihre Clientanwendung einen Always Encrypted-fähigen Treiber verwendet, um mit dem zu kommunizieren Datenbank. Durch die Verwendung dieses Treibers überträgt die Anwendung verschlüsselte Daten sicher an die Datenbank, die dann später nur von einer Anwendung entschlüsselt werden können, die Zugriff auf den Verschlüsselungsschlüssel hat. Jede andere Anwendung, die die Daten abfragt, kann die verschlüsselten Werte ebenfalls abrufen, aber diese Anwendung kann die Daten nicht ohne den Verschlüsselungsschlüssel verwenden, wodurch die Daten unbrauchbar werden. Aufgrund dieser Verschlüsselungsarchitektur sieht die SQL Server-Instanz niemals die unverschlüsselte Version der Daten.

Derzeit sind die einzigen Always Encrypted-fähigen Treiber der .NET Framework-Datenanbieter für SQL Server, der die Installation von .NET Framework Version 4.6 auf dem Clientcomputer erfordert, und der JDBC 6.0-Treiber. Das wird sich wahrscheinlich mit der Zeit ändern, aber das sind die offiziellen Anforderungen von Always Encrypted, Stand April 2017.

Aber wozu brauchen wir diese Technologie? Es gibt ein paar gute Gründe, warum Always Encrypted verwendet werden sollte:

• Sicherheit – Daten mussten immer sicher sein. Jetzt, wo SSL kompromittiert wird, füllt Always Encrypted die Lücke mit einer weiteren Schutzebene für die Transportpipeline.
• Regulatorische Unterstützung – Daten müssen verschlüsselt und vor neugierigen DBA-Augen durch immer mehr Branchenvorschriften geschützt werden, vor allem in der Finanz- und Telekommunikationsbranche. Dies wird im PII-Standard („Personally Identifiable Information“) beschrieben, der besagt, dass Dinge wie Kreditkartennummern, Sozialversicherungsnummern, Namen und Adressen geschützt werden müssen, oder der Dateneigentümer streng bestraft werden kann.

So verwenden Sie Always Encrypted

Die Verwendung von Always Encrypted erfordert ein wenig Vorbereitung auf dem Datenbankserver, der die verschlüsselten Tabellen speichert. Die Vorbereitung ist ein zweistufiger Prozess:

• Erstellen Sie die Spaltenhauptschlüsseldefinition
• Erstellen Sie den Spaltenverschlüsselungsschlüssel

Spaltenhauptschlüssel

Was ist also ein Spaltenhauptschlüssel?

Der Spaltenhauptschlüssel ist ein Zertifikat, das in einem Windows-Zertifikatspeicher gespeichert ist (der in der Demo als Zertifikatspeicheroption verwendet wird), einem Hardware-Sicherheitsmodul eines Drittanbieters (ein generischer Name für Drittanbieterlösungen zum Installieren, Verwalten und Verwenden certificate ) oder Azure Key Vault (die cloudbasierte Lösung von Microsoft für die Zertifikatsverwaltung).

Die Anwendung, die die Daten verschlüsselt, verwendet den Spaltenhauptschlüssel, um verschiedene Spaltenverschlüsselungsschlüssel zu schützen, die die Verschlüsselung von Daten in den Spalten einer Datenbanktabelle handhaben. Die Verwendung von Zertifikatspeichern von SQL Server, die manchmal als Enterprise Key Manager bezeichnet werden, erfordert die Verwendung von SQL Server Enterprise Edition.

In diesem Artikel beschreiben wir die Verwendung eines selbstsignierten Zertifikats, das Sie im Microsoft Certificate Store des Windows-Betriebssystems speichern. Obwohl dieser Ansatz nicht die optimale Konfiguration ist, demonstriert er das Konzept von Always Encrypted – aber es muss auch gesagt werden, dass dieser Ansatz für Produktionsumgebungen nicht akzeptabel ist, wo die Zertifikatsverwaltung mit separaten, gesicherten Benutzerkonten erfolgen muss und vorzugsweise , auf separaten Servern.

Sie können eine Spaltenhauptschlüsseldefinition mithilfe der grafischen Benutzeroberfläche in SQL Server Management Studio (SSMS) oder mithilfe von T-SQL erstellen. Stellen Sie in SSMS eine Verbindung mit der SQL Server 2016-Datenbankinstanz her, in der Sie Always Encrypted verwenden möchten, um eine Datenbanktabelle zu schützen.

Erstellen und Verwenden von Spaltenhauptschlüsseln

Navigieren Sie im Objekt-Explorer zuerst zur Datenbank, dann zu Sicherheit und erweitern Sie dann den Ordner Always Encrypted Keys, um seine beiden Unterordner anzuzeigen, wie in den folgenden Abbildungen dargestellt:

Um den Spaltenhauptschlüssel zu erstellen, klicken Sie mit der rechten Maustaste auf den Ordner „ Column Master Keys “ und wählen Sie „ New Column Master Key “ aus. Geben Sie im Dialogfeld New Column Master Key einen Namen für den Spaltenhauptschlüssel ein, geben Sie an, ob der Schlüssel im Zertifikatspeicher des aktuellen Benutzers oder des lokalen Computers oder im Azure Key Vault gespeichert werden soll, und wählen Sie dann ein Zertifikat aus der Liste aus. Wenn keine Zertifikate vorhanden sind oder Sie ein neues selbstsigniertes Zertifikat verwenden möchten, klicken Sie auf die Schaltfläche Generate Certificate und dann auf OK . Dieser Schritt erstellt ein selbstsigniertes Zertifikat und lädt es in den Zertifikatspeicher des aktuellen Benutzerkontos, auf dem SSMS ausgeführt wird.

Hinweis: Sie sollten diese Schritte auf einem vertrauenswürdigen Computer ausführen, aber nicht auf dem Computer, der Ihre SQL Server-Instanz hostet. Auf diese Weise bleiben die Daten in SQL Server geschützt, selbst wenn der Hostcomputer kompromittiert wird.

Nachdem Sie also das Zertifikat erstellt und als Spaltenhauptschlüssel konfiguriert haben, müssen Sie es exportieren und an alle Computer verteilen, die Clients hosten, die Zugriff auf die Daten benötigen. Wenn eine Clientanwendung webbasiert ist, müssen Sie das Zertifikat auf den Webserver laden. Wenn es sich um eine Anwendung handelt, die auf den Computern der Benutzer installiert ist, müssen Sie das Zertifikat auf den Computern der einzelnen Benutzer einzeln bereitstellen.

Anwendbare Anleitungen zum Exportieren und Importieren von Zertifikaten für Ihr Betriebssystem finden Sie unter den folgenden URLs:

• Zertifikate exportieren
  • Windows 7 und Windows Server 2008 R2
  • Windows 8 und Windows Server 2012
  • Windows 8.1 und Windows Server 2012 R2
  • Windows 10 und Windows Server 2016
• Zertifikate importieren
  • Windows 7 und Windows Server 2008 R2
  • Windows 8 und Windows Server 2012
  • Windows 8.1 und Windows Server 2012 R2
  • Windows 10 und Windows Server 2016

Wenn Sie Zertifikate in den Zertifikatspeicher auf Computern mit einer Anwendung importieren, die die Daten verschlüsselt und entschlüsselt, müssen Sie die Zertifikate entweder in den Computerzertifikatspeicher oder den Zertifikatspeicher des Domänenkontos importieren, auf dem die Anwendung ausgeführt wird.

Spaltenverschlüsselungsschlüssel

Nachdem Sie einen Spaltenhauptschlüssel erstellt haben, können Sie Verschlüsselungsschlüssel für bestimmte Spalten erstellen. Der SQL Server 2016 ADO.NET-Treiber verwendet Spaltenverschlüsselungsschlüssel, um die Daten zu verschlüsseln, bevor sie an den SQL Server gesendet werden, und um die Daten zu entschlüsseln, nachdem sie von der SQL Server 2016-Instanz abgerufen wurden. Wie beim Spaltenhauptschlüssel können Sie Spaltenverschlüsselungsschlüssel mithilfe von T-SQL oder SSMS erstellen. Während Spaltenhauptschlüssel mit T-SQL einfacher zu erstellen sind, lassen sich Spaltenverschlüsselungsschlüssel mit SSMS einfacher erstellen.

Verwenden Sie zum Erstellen eines Spaltenverschlüsselungsschlüssels den Object Explorer , um eine Verbindung zur Datenbankinstanz herzustellen, navigieren Sie zur Datenbank, dann zu Security und erweitern Sie den Ordner Always Encrypted Keys . Klicken Sie mit der rechten Maustaste auf Column Encryption Keys und wählen Sie dann New Column Encryption Key aus. Geben Sie im Dialogfeld New Column Encryption Key einen Namen für den neuen Verschlüsselungsschlüssel ein, wählen Sie eine Column Master Key Definition in der Dropdown-Liste aus und klicken Sie dann auf OK . Sie können jetzt den Spaltenverschlüsselungsschlüssel in der Definition einer neuen Tabelle verwenden.

Erstellen einer Tabelle mit verschlüsselten Werten

Nach dem Erstellen der Spaltenhauptschlüsseldefinition und der Spaltenverschlüsselungsschlüssel können Sie eine Tabelle zum Speichern der verschlüsselten Werte erstellen.

Bevor Sie dies tun, müssen Sie entscheiden, welche Art von Verschlüsselung verwendet werden soll, welche Spalten verschlüsselt werden sollen und ob Sie diese Spalten indizieren können. Mit dem Always Encrypted -Feature definieren Sie die Spaltengrößen normal, und SQL Server passt die Speichergröße der Spalte basierend auf den Verschlüsselungseinstellungen an. Nachdem Sie Ihre Tabelle erstellt haben, müssen Sie möglicherweise Ihre Anwendung ändern, um Befehle für diese Tabelle mit Always Encrypted auszuführen.

SQL Server 2016-Verschlüsselungstypen

Bevor Sie eine Tabelle erstellen, die verschlüsselte Werte enthalten soll, müssen Sie entscheiden, ob jede Spalte verschlüsselt werden soll oder nicht.

Erstens, wird diese Spalte zum Nachschlagen von Werten oder nur zum Zurückgeben dieser Werte verwendet?

Wenn die Spalte für Suchvorgänge verwendet werden soll, muss die Spalte einen deterministischen Verschlüsselungstyp verwenden , der Gleichheitsoperationen zulässt. Es gibt jedoch Einschränkungen bei der Suche nach Daten, die mit der Always Encrypted -Funktion verschlüsselt wurden. SQL Server 2016 unterstützt nur Gleichheitsoperationen, darunter equal to , not equal to , joins (die Gleichheit verwenden) und die Verwendung des Werts in der GROUP BY Klausel. Eine Suche mit LIKE wird nicht unterstützt. Darüber hinaus muss das Sortieren von Daten, die mit Always Encrypted verschlüsselt wurden, auf Anwendungsebene erfolgen, da SQL Server basierend auf dem verschlüsselten Wert und nicht auf dem entschlüsselten Wert sortiert.

Wenn die Spalte nicht zum Auffinden von Datensätzen verwendet wird, sollte die Spalte den randomisierten Verschlüsselungstyp verwenden. Diese Art der Verschlüsselung ist sicherer, unterstützt jedoch keine Suchen, Verknüpfungen oder Gruppierungsvorgänge.

Erstellen einer Tabelle mit verschlüsselten Spalten

Beim Erstellen von Tabellen verwenden Sie die normale CREATE TABLE Syntax mit einigen zusätzlichen Parametern innerhalb der Spaltendefinition. Drei Parameter werden innerhalb der ENCRYPTED WITH Syntax für die CREATE TABLE -Anweisung verwendet.

Der erste davon ist der Parameter ENCRYPTION_TYPE , der einen Wert von RANDOMIZED oder DETERMINISTIC . Der zweite ist der Parameter ALGORITHM , der nur den Wert RAEAD_AES_256_CBC_HMAC_SHA_256 akzeptiert. Der dritte Parameter ist COLUMN_ENCRYPTION_KEY , der Verschlüsselungsschlüssel, den Sie zum Verschlüsseln des Werts verwenden.

 CREATE TABLE [dbo].[Customers] ( [CustomerId] [int] IDENTITY(1,1), [TaxId] [varchar](11) COLLATE Latin1_General_BIN2 ENCRYPTED WITH (ENCRYPTION_TYPE = DETERMINISTIC, ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256', COLUMN_ENCRYPTION_KEY = YOUR_COLUMN_ENCRYPTION_KEY) NOT NULL, [FirstName] [nvarchar](50) NULL, [LastName] [nvarchar](50) NULL, [MiddleName] [nvarchar](50) NULL, [Address1] [nvarchar](50) NULL, [Address2] [nvarchar](50) NULL, [Address3] [nvarchar](50) NULL, [City] [nvarchar](50) NULL, [PostalCode] [nvarchar](10) NULL, [State] [char](2) NULL, [BirthDate] [date] ENCRYPTED WITH (ENCRYPTION_TYPE = RANDOMIZED, ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256', COLUMN_ENCRYPTION_KEY = YOUR_COLUMN_ENCRYPTION_KEY) NOT NULL PRIMARY KEY CLUSTERED ([CustomerId] ASC) ON [PRIMARY] ); GO

Indizierung mit Always Encrypted

Spalten mit verschlüsselten Daten können als Schlüsselspalten in Indizes verwendet werden, vorausgesetzt, dass diese Spalten mit dem Verschlüsselungstyp DETERMINISTIC verschlüsselt sind. Spalten, die mit dem RANDOMIZED Verschlüsselungstyp verschlüsselt wurden, geben eine Fehlermeldung zurück, wenn Sie versuchen, einen Index für diese Spalten zu erstellen. Spalten, die mit einem der beiden Verschlüsselungstypen verschlüsselt wurden, können als INCLUDE Spalten in Nonclustered-Indizes verwendet werden.

Da es sich bei verschlüsselten Werten um Indizes handeln kann, sind für mit Always Encrypted verschlüsselte Werte neben der Indizierung und Optimierung, die Sie normalerweise durchführen, keine weiteren Maßnahmen zur Leistungsoptimierung erforderlich. Zusätzliche Netzwerkbandbreite und mehr E/A sind die einzigen Nebeneffekte, die sich aus der größeren Größe der zurückgegebenen Werte ergeben.

Immer verschlüsselte Leistung

Die Leistung ist immer ein Schlüsselfaktor, insbesondere in diesem Fall, wenn wir den Aufwand für die Verschlüsselung zum üblichen Datenbankverkehr hinzufügen. Die beste Site zum Testen der Leistung ist SQL Performance, die die Abfrageausführung und die Festplattennutzung in verschiedenen Szenarien getestet hat:

Da bei Verschlüsselungs- und Entschlüsselungsprozessen CPU- und Festplattenarbeit geleistet werden muss, hat dies offensichtliche Auswirkungen auf die Menge des verwendeten Speicherplatzes und die Dauer der Abfragen. Da dies von Ihrer Umgebung beeinflusst wird – CPU-, RAM- und Festplattenfunktionen – sollten Sie testen, ob dies in der Produktion ein Problem darstellt.

Hinweis: Falls Sie mehr über die Leistungsoptimierung von Microsoft SQL Server erfahren möchten, lesen Sie bitte einen unserer vorherigen Artikel, So optimieren Sie die Leistung von Microsoft SQL Server.

Anwendungsänderungen

Was müssen Sie tun, um Always Encrypted ordnungsgemäß in Legacy-Code zu implementieren?

Eines der netten Dinge an der Always Encrypted-Funktion von SQL Server 2016 ist, dass Anwendungen, die bereits gespeicherte Prozeduren, ORMs oder parametrisierte T-SQL-Befehle verwenden, keine Anwendungsänderungen erfordern sollten, um Always Encrypted zu verwenden, es sei denn, es werden bereits ungleiche Operationen verwendet. Anwendungen, die SQL-Anweisungen als dynamisches SQL innerhalb der Anwendung erstellen und diese Befehle direkt für die Datenbank ausführen, müssen geändert werden, um die Parametrisierung ihrer Abfragen zu verwenden, eine empfohlene bewährte Sicherheitsmethode für alle Anwendungen, bevor sie die Always Encrypted-Funktion nutzen können.

Eine weitere Änderung, die erforderlich ist, damit Always Encrypted funktioniert, ist das Hinzufügen eines Verbindungszeichenfolgenattributs zur Verbindungszeichenfolge der Anwendung, die eine Verbindung zur Datenbank herstellt: Column Encryption Setting=enabled .

Wenn diese Einstellung der Verbindungszeichenfolge hinzugefügt wird, fragt der ADO.NET-Treiber den SQL Server, ob der ausführende Befehl verschlüsselte Spalten enthält und wenn ja, welche Spalten verschlüsselt sind. Für Anwendungen mit hoher Auslastung ist die Verwendung dieser Einstellung möglicherweise nicht die beste Methode, insbesondere wenn ein großer Prozentsatz der ausgeführten Befehle keine verschlüsselten Werte enthält.

Folglich stellt .NET Framework eine neue Methode für das SqlConnection-Objekt namens SqlCommandColumnEncryptionSetting , die drei mögliche Werte hat:

• Disabled – Es gibt keine Always Encrypted-Spalten oder -Parameter, die für die Abfragen verwendet werden können, die mit diesem Verbindungsobjekt ausgeführt werden.
• Enabled – Es werden Always Encrypted-Spalten und/oder -Parameter für die Abfragen verwendet, die mit diesem Verbindungsobjekt ausgeführt werden.
• ResultSet – Es gibt keine Always Encrypted-Parameter. Das Ausführen von Abfragen mit diesem Verbindungsobjekt gibt jedoch Spalten zurück, die mit Always Encrypted verschlüsselt wurden.

Hinweis: Beachten Sie, dass die Verwendung dieser Methode potenziell eine erhebliche Menge an Änderungen an Ihrem Anwendungscode erfordern kann. Ein alternativer Ansatz besteht darin, Ihre Anwendung so umzugestalten, dass sie andere Verbindungen verwendet.

Für die beste Leistung von SQL Server empfiehlt es sich, nur die Metadaten zu Always Encrypted für die Abfragen anzufordern, die Always Encrypted verwenden. Dies bedeutet, dass in Anwendungen, für die ein großer Prozentsatz der Abfragen Always Encrypted verwendet, die Verbindungszeichenfolge aktiviert werden sollte und die spezifischen Abfragen innerhalb der Anwendung SqlCommandColumnEncryptionSetting als Disabled angeben sollten. Für Anwendungen, für die die meisten Abfragen keine Always Encrypted-Werte verwenden, sollte die Verbindungszeichenfolge nicht aktiviert werden, und SqlCommandColumnEncryptionSetting sollte je nach Bedarf für Abfragen, die Always Encrypted-Spalten verwenden, auf Enabled oder ResultSet festgelegt werden. In den meisten Fällen können Anwendungen einfach das Verbindungszeichenfolgenattribut aktivieren, und die Anwendungsleistung bleibt unverändert, während die verschlüsselten Daten verwendet werden.

Ist Always Encryption die Mühe wert?

Kurze Antwort? Ja auf jeden Fall!

Es trägt nicht nur dazu bei, viele potenzielle Sicherheitsbedenken zu vermeiden und bietet SQL-Entwicklern zusätzliche Sicherheitsfunktionen, sondern macht Ihr System auch konformer, was in zahlreichen Branchen von entscheidender Bedeutung ist, von der Telekommunikation bis zum Banken- und Versicherungswesen. Es ist auch wichtig zu beachten, dass Always Encrypted unter den im Artikel genannten technischen Voraussetzungen mit minimalen Anwendungsänderungen an bestehenden Systemen implementiert werden kann .

Obwohl Sie möglicherweise benutzerdefinierte Lösungen verwenden, um denselben Effekt zu erzielen, wird diese Technologie mit der neuen Version von SQL Server gebündelt und kann sofort verwendet werden. Es ist auch wichtig zu beachten, dass es sich um eine neue Technologie handelt, deren Verwendung noch einige Einschränkungen aufweist und einige zusätzliche Hardware-Demenads hinzufügt.

Es gibt jedoch praktisch keinen Grund, Always Encrypted nicht zu verwenden, es sei denn, sie sind ein Deal-Breaker für Ihre Umgebung und Sie haben eine Anwendung, die außerhalb des Intranets Ihres Unternehmens verteilt wird.