Wenn Sie vertrauliche Daten in Ihrer Datenbank speichern müssen, können Sie Datenverschlüsselung verwenden . SQL Server unterstützt die Verschlüsselung mit symmetrischen Schlüsseln, asymmetrischen Schlüsseln, Zertifikaten und Kennwortsätzen. Ich gehe davon aus, dass Ihnen als Leser diese Begriffe bereits bekannt sind. In diesem Artikel werde ich mich auf zwei von vielen Verschlüsselungsoptionen konzentrieren, die von SQL Server bereitgestellt werden:
- Transparente Datenverschlüsselung (TDE)
- Immer verschlüsselt (AE)
Transparente Datenverschlüsselung
Die Transparent Data Encryption (TDE) schützt die Daten im Ruhezustand, wenn sie nicht verwendet werden. Wenn die Daten verwendet werden, entschlüsselt SQL Server sie automatisch. Sie können die TDE zur Echtzeitverschlüsselung und -entschlüsselung der Daten und Protokolldateien verwenden. Sie verschlüsseln die Daten mit dem Datenbankverschlüsselungsschlüssel (DEK) , was ein symmetrischer Schlüssel ist. Es wird im Datenbank-Boot-Record gespeichert und steht somit bereits während der Datenbankwiederherstellung zur Verfügung. Sie schützen den DEK mit einem Zertifikat in der Master-Datenbank. Anstelle des Zertifikats können Sie auch einen asymmetrischen Schlüssel verwenden; Der asymmetrische Schlüssel muss jedoch in einem EKM-Modul gespeichert werden. TDE verwendet nur die Verschlüsselungen AES und Triple DES. TDE wurde erstmals in SQL Server mit Version 2012 implementiert.
Sie können TDE nur für Benutzerdatenbanken verwenden. Sie können den Datenbankverschlüsselungsschlüssel nicht exportieren. Dieser Schlüssel wird nur von der SQL Server-Datenbank-Engine verwendet. Endbenutzer verwenden es nie. Auch wenn Sie den Eigentümer der Datenbank ändern, müssen Sie den DEK nicht neu generieren.
TDE verschlüsselt Daten auf Seitenebene. Darüber hinaus verschlüsselt es auch das Transaktionsprotokoll. Sie sollten das zum Schutz des DEK verwendete Zertifikat und den zum Schutz des Zertifikats verwendeten privaten Schlüssel unmittelbar nach der Aktivierung von TDE sichern. Wenn Sie die verschlüsselte Datenbank wiederherstellen oder an eine andere SQL Server-Instanz anhängen müssen, müssen Sie sowohl das Zertifikat als auch den privaten Schlüssel wiederherstellen, oder Sie können die Datenbank nicht öffnen. Beachten Sie erneut, dass Sie den DEK nicht exportieren, da er Teil der Datenbank selbst ist. Sie müssen das zum Schutz des DEK verwendete Zertifikat auch nach dem Deaktivieren des TDE in der Datenbank aufbewahren und pflegen. Dies liegt daran, dass Teile des Transaktionsprotokolls möglicherweise noch verschlüsselt sind. Das Zertifikat wird benötigt, bis Sie die vollständige Datenbanksicherung durchführen.
Immer verschlüsselt
SQL Server 2016 Enterprise Edition führt eine neue Verschlüsselungsebene ein, nämlich Always Encrypted (AE) Merkmal. Diese Funktion ermöglicht denselben Datenschutz wie die Verschlüsselung der Daten in der Client-Anwendung. Obwohl dies eine SQL Server-Funktion ist, werden die Daten tatsächlich auf der Clientseite verschlüsselt und entschlüsselt. Die Verschlüsselungsschlüssel werden der SQL Server-Datenbank-Engine niemals offengelegt. Auf diese Weise kann auch ein DBA keine vertraulichen Daten ohne die Verschlüsselungsschlüssel sehen, nur weil er über Sysadmin-Berechtigungen für die SQL Server-Instanz mit den verschlüsselten Daten verfügt. Auf diese Weise schafft AE eine Trennung zwischen den Administratoren, die die Daten verwalten, und den Benutzern, denen die Daten gehören.
AE-Schlüssel
Für Always Encrypted benötigen Sie zwei Schlüssel. Zuerst erstellen Sie den Spaltenhauptschlüssel (CMK) . Dann erstellen Sie den Spaltenverschlüsselungsschlüssel (CEK) und schützen Sie es mit dem CMK. Eine Anwendung verwendet den CEK, um die Daten zu verschlüsseln. SQL Server speichert nur verschlüsselte Daten und kann sie nicht entschlüsseln. Dies ist möglich, da die Spaltenhauptschlüssel nicht wirklich in einer SQL Server-Datenbank gespeichert werden. In der Datenbank speichert SQL Server nur den Link zu diesen Schlüsseln. Die Spaltenhauptschlüssel werden außerhalb von SQL Server an einem der folgenden möglichen Orte gespeichert:
- Windows-Zertifikatsspeicher für den aktuellen Benutzer
- Windows-Zertifikatsspeicher für den lokalen Computer
- Azure Key Vault-Dienst
- Ein Hardware-Sicherheitsmodul (HSM) , das Microsoft CryptoAPI oder Cryptography API:Next Generation unterstützt
Die Spaltenverschlüsselungsschlüssel werden in der Datenbank gespeichert. In einer SQL Server-Datenbank wird nur der verschlüsselte Teil der Werte von Spaltenverschlüsselungsschlüsseln zusammen mit den Informationen über den Speicherort von Spaltenhauptschlüsseln gespeichert. CEKs werden niemals als Klartext in einer Datenbank gespeichert. CMKs werden, wie erwähnt, tatsächlich in externen vertrauenswürdigen Schlüsselspeichern gespeichert.
Verwendung der AE-Tasten
Eine Anwendung kann die AE-Schlüssel und die Verschlüsselung mithilfe eines AE-fähigen Treibers verwenden, z. B. .NET Framework Data Provider für SQL Server Version 4.6 oder höher, Microsoft JDBC-Treiber für SQL Server 6.0 oder höher oder Windows ODBC-Treiber für SQL Server Version 13.1 oder höher. Die Anwendung muss parametrisierte Abfragen senden zu SQL-Server. Der AE-fähige Treiber arbeitet mit der SQL Server-Datenbank-Engine zusammen, um zu bestimmen, welche Parameter verschlüsselt oder entschlüsselt werden sollen. Für jeden Parameter, der verschlüsselt oder entschlüsselt werden muss, erhält der Treiber die für die Verschlüsselung erforderlichen Metadaten von der Datenbank-Engine, einschließlich des Verschlüsselungsalgorithmus, des Speicherorts des entsprechenden CMK und des verschlüsselten Werts für den entsprechenden CEK. Dann kontaktiert der Treiber den CMK-Speicher, ruft den CMK ab, entschlüsselt den CEK und verwendet den CEK, um den Parameter zu verschlüsseln oder zu entschlüsseln. Dann cachet der Treiber den CEK, um die nächste Verwendung desselben CEK zu beschleunigen. Die folgende Abbildung zeigt den Vorgang grafisch.
Die Abbildung stellt den gesamten Prozess in Schritten dar:
- Clientanwendung erstellt eine parametrisierte Abfrage
- Die Client-Anwendung sendet die parametrisierte Abfrage an den AE-fähigen Treiber
- Der AE-fähige Treiber kontaktiert SQL Server, um festzustellen, welche Parameter verschlüsselt oder entschlüsselt werden müssen, sowie den Speicherort des CMK und den verschlüsselten Wert des CEK
- Der AE-fähige Treiber ruft den CMK ab und entschlüsselt den CEK
- Der AE-fähige Treiber verschlüsselt den/die Parameter
- Der Treiber sendet die Abfrage an die Datenbank-Engine
- Die Datenbank-Engine ruft die Daten ab und sendet die Ergebnismenge an den Treiber
- Der Treiber führt bei Bedarf eine Entschlüsselung durch und sendet die Ergebnismenge an die Client-Anwendung
AE-Verschlüsselungstypen
Die Datenbank-Engine verarbeitet niemals die in den verschlüsselten Spalten gespeicherten Klartextdaten. Je nach Verschlüsselungsart sind jedoch einige Abfragen der verschlüsselten Daten möglich. Es gibt zwei Arten der Verschlüsselung:
- Deterministische Verschlüsselung , die immer denselben verschlüsselten Wert für denselben Eingabewert generiert. Mit dieser Verschlüsselung können Sie die verschlüsselte Spalte indizieren und Punktsuchen, Gleichheitsverknüpfungen und Gruppierungsausdrücke für die verschlüsselte Spalte verwenden. Ein böswilliger Benutzer könnte jedoch versuchen, die Werte zu erraten, indem er die Muster der verschlüsselten Werte analysiert. Dies ist besonders gefährlich, wenn die Menge möglicher Werte für eine Spalte diskret ist, mit einer kleinen Anzahl unterschiedlicher Werte.
- Randomisierte Verschlüsselung , das Daten auf unvorhersehbare Weise verschlüsselt.
AE-Demo:Erstellen der Objekte
Es ist an der Zeit, anhand von Democode zu zeigen, wie AE funktioniert. Lassen Sie uns zunächst eine Demo-Datenbank erstellen und verwenden.
USE master; IF DB_ID(N'AEDemo') IS NULL CREATE DATABASE AEDemo; GO USE AEDemo; GO
Erstellen Sie als Nächstes den CMK in der SSMS-GUI. Aktualisieren Sie im Objekt-Explorer den Ordner Datenbanken, um die AEDemo-Datenbank anzuzeigen. Erweitern Sie diesen Datenbankordner, erweitern Sie den Unterordner Security, dann den Unterordner Always Encrypted Keys, klicken Sie mit der rechten Maustaste auf den Unterordner Column Master Key und wählen Sie die Option New Column Master Key aus dem Popup-Menü. Schreiben Sie in das Textfeld Name AE_ColumnMasterKey, und stellen Sie sicher, dass Sie die Option Windows Certificate Store – Local Machine in der Dropdown-Liste Key Store auswählen, wie die folgende Abbildung zeigt.
Mit der folgenden Abfrage können Sie überprüfen, ob der CMK erfolgreich erstellt wurde.
SELECT * FROM sys.column_master_keys;
Als Nächstes erstellen Sie den CEK. Klicken Sie in SSMS im Objekt-Explorer mit der rechten Maustaste auf den Unterordner Column Encryption Keys direkt unter dem Unterordner Column Master Key und wählen Sie die Option New Column Encryption Key aus dem Popup-Menü. Nennen Sie den CEK AE_ColumnEncryptionKey und verwenden Sie den AE_ColumnMasterKey CMK, um ihn zu verschlüsseln. Ob die CEK-Erstellung erfolgreich war, können Sie mit der folgenden Abfrage prüfen.
SELECT * FROM sys.column_encryption_keys;
Derzeit nur die neuen binären Sortierungen, die Sortierungen mit dem BIN2 Suffix, werden für AE unterstützt. Lassen Sie uns daher eine Tabelle mit geeigneten Sortierungen für die Zeichenspalten erstellen.
CREATE TABLE dbo.Table1 (id INT, SecretDeterministic NVARCHAR(10) COLLATE Latin1_General_BIN2 ENCRYPTED WITH (COLUMN_ENCRYPTION_KEY = AE_ColumnEncryptionKey, ENCRYPTION_TYPE = DETERMINISTIC, ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256') NULL, SecretRandomized NVARCHAR(10) COLLATE Latin1_General_BIN2 ENCRYPTED WITH (COLUMN_ENCRYPTION_KEY = AE_ColumnEncryptionKey, ENCRYPTION_TYPE = RANDOMIZED, ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256') NULL );
AE-Demo:Einfügen der Daten
Jetzt können Sie versuchen, eine Datenzeile mit der folgenden Anweisung einzufügen.
INSERT INTO dbo.Table1 (id, SecretDeterministic, SecretRandomized) VALUES (1, N'DeterSec01', N'RandomSec1');
Sie erhalten den Fehler 206, Fehlertext:„Operand type clash:nvarchar is incompatible with nvarchar(4000) encoding with (encryption_type ='DETERMINISTIC', encryption_algorithm_name ='AEAD_AES_256_CBC_HMAC_SHA_256', column_encryption_key_name ='AE_ColumnEncryptionKey', column_encryption_key_database_name ='AEDemo')“ . SQL Server kann die Daten nicht verschlüsseln oder entschlüsseln. Sie müssen die Daten von einer Clientanwendung aus ändern. Sie können eine begrenzte Anzahl von Vorgängen für die Tabelle von SQL Server ausführen. Beispielsweise können Sie die TRUNCATE TABLE-Anweisung auf eine Tabelle mit AE-Spalten anwenden.
Ich habe eine sehr einfache Client-Windows-Konsolenanwendung in Visual C# erstellt. Die Anwendung ruft tatsächlich nur die Schlüssel ab und fügt eine einzelne Zeile in die Tabelle ein, die mit dem obigen Code erstellt wurde. Hier ist der C#-Code.
using System;
using System.Collections.Generic;
using System.Data;
using System.Data.SqlClient;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace AEDemo
{
class Program
{
static void Main(string[] args)
{
string connectionString = "Data Source=localhost; “ +
“Initial Catalog=AEDemo; Integrated Security=true; ” +
“Column Encryption Setting=enabled";
SqlConnection connection = new SqlConnection(connectionString);
connection.Open();
if (args.Length != 3)
{
Console.WriteLine("Please enter a numeric “ +
“and two string arguments.");
return;
}
int id = Int32.Parse(args[0]);
{
using (SqlCommand cmd = connection.CreateCommand())
{
cmd.CommandText = @"INSERT INTO dbo.Table1 “ +
“(id, SecretDeterministic, SecretRandomized)" +
" VALUES (@id, @SecretDeterministic, @SecretRandomized);";
SqlParameter paramid= cmd.CreateParameter();
paramid.ParameterName = @"@id";
paramid.DbType = DbType.Int32;
paramid.Direction = ParameterDirection.Input;
paramid.Value = id;
cmd.Parameters.Add(paramid);
SqlParameter paramSecretDeterministic = cmd.CreateParameter();
paramSecretDeterministic.ParameterName =
@"@SecretDeterministic";
paramSecretDeterministic.DbType = DbType.String;
paramSecretDeterministic.Direction = ParameterDirection.Input;
paramSecretDeterministic.Value = "DeterSec1";
paramSecretDeterministic.Size = 10;
cmd.Parameters.Add(paramSecretDeterministic);
SqlParameter paramSecretRandomized = cmd.CreateParameter();
paramSecretRandomized.ParameterName =
@"@SecretRandomized";
paramSecretRandomized.DbType = DbType.String;
paramSecretRandomized.Direction = ParameterDirection.Input;
paramSecretRandomized.Value = "RandomSec1";
paramSecretRandomized.Size = 10;
cmd.Parameters.Add(paramSecretRandomized);
cmd.ExecuteNonQuery();
}
}
connection.Close();
Console.WriteLine("Row inserted successfully");
}
}
}
Sie können den C#-Code von Visual Studio im Debugmodus ausführen oder die Anwendung erstellen. Dann können Sie die Anwendung AEDemo.exe von der Eingabeaufforderung oder von SSMS im SQMCMD-Modus ausführen.
AE-Demo:Lesen der Daten
Nachdem Sie die Anwendung ausgeführt haben, sollten Sie versuchen, die Daten aus derselben Sitzung in SSMS zu lesen, die Sie zum Erstellen der Tabelle verwendet haben.
SELECT * FROM dbo.Table1;
Sie können nur verschlüsselte Daten sehen. Öffnen Sie nun ein zweites Abfragefenster in SSMS. Klicken Sie mit der rechten Maustaste in dieses Fenster und wählen Sie Verbindung und dann Verbindung ändern. Klicken Sie im Verbindungsdialog unten auf die Schaltfläche Optionen. Geben Sie AEDemo als Datenbanknamen ein und klicken Sie dann auf die Registerkarte Zusätzliche Verbindungsparameter. Geben Sie im Textfeld „Column Encryption Setting=enabled“ ein (ohne doppelte Anführungszeichen). Klicken Sie dann auf Verbinden.
Versuchen Sie erneut, eine Zeile aus SSMS einzufügen. Verwenden Sie die folgende Abfrage.
INSERT INTO dbo.Table1 (id, SecretDeterministic, SecretRandomized) VALUES (2, N'DeterSec2', N'RandomSec2');
Ich habe wieder einen Fehler. Diese SSMS-Version, die ich verwende, kann Ad-hoc-Einfügungen immer noch nicht parametrisieren. Versuchen wir jedoch, die Daten mit der folgenden Abfrage auszulesen.
SELECT * FROM dbo.Table1;
Diesmal funktioniert die Abfrage und Sie erhalten das folgende Ergebnis:
ID-SecretDeterministic SecretRandomized
— ——————– —————-
1 DeterSec1 RandomSec1
2 DeterSec2 RandomSec2
AE-Einschränkungen
Sie haben bereits einige Einschränkungen von Always Encrypted gesehen, darunter:
- Nur BIN2-Sortierungen werden für Zeichenfolgen unterstützt
- Sie können nur Spalten mit deterministischer Verschlüsselung indizieren und einen begrenzten Satz von T-SQL-Operationen für diese Spalten verwenden
- Sie können keine Spalten mit randomisierter Verschlüsselung indizieren
- AE ist nur auf die Enterprise- und Developer-Editionen beschränkt
- Die Arbeit mit AE in SSMS kann schmerzhaft sein
Eine detailliertere Liste der AE-Einschränkungen finden Sie in der Online-Dokumentation. Beachten Sie aber auch die Stärken von AE. Es ist einfach zu implementieren, da es keine Änderungen in einer Anwendung erfordert, mit Ausnahme der Änderung von Verbindungszeichenfolgen. Die Daten werden Ende-zu-Ende verschlüsselt, vom Clientspeicher über das Netzwerk bis zum Datenbankspeicher. Selbst DBAs können die Daten nicht nur innerhalb von SQL Server anzeigen; sogar DBAs benötigen Zugriff auf den Schlüsselspeicher außerhalb von SQL Server, um den CMK zu lesen. AE und andere Verschlüsselungsoptionen in SQL Server bieten eine vollständige Palette von Möglichkeiten, und es liegt an Ihnen und dem zu lösenden Geschäftsproblem, die geeignete Methode auszuwählen.
Schlussfolgerung
Transparent Data Encryption ist extrem einfach zu bedienen. Allerdings ist der Datenschutz sehr eingeschränkt. TDE schützt nur die Daten im Ruhezustand. Always Encrypted ist jedoch wirklich eine leistungsstarke Funktion. Es ist dennoch nicht zu komplex zu implementieren und die Daten sind vollständig geschützt. Nicht einmal ein DBA kann es sehen, ohne Zugriff auf die Verschlüsselungsschlüssel zu haben. Hoffentlich werden die Einschränkungen für AE, insbesondere die Sortierungsbeschränkung, in den zukünftigen Versionen von SQL Server entfernt.
