SQL Server 2016:Immer verschlüsselt

SQL Server 2016 enthält eine Datenbanksicherheitsfunktion namens Always Encrypted. Da wir dem SQL Server ODBC-Treiber Unterstützung für Always Encrypted hinzugefügt haben, können unsere Kunden diese Funktion nutzen.

Always Encrypted schützt SQL Server-Daten an dem Punkt, an dem sie am anfälligsten für Angriffe sind:wenn diese Daten verwendet werden. Zum Beispiel bei Transaktionen und Berechnungen. Dies unterscheidet sich von bestehenden SQL Server-Verschlüsselungsfunktionen, da sie erfordern, dass Daten entschlüsselt werden, bevor Operationen darauf ausgeführt werden können.

Der Verschlüsselungsschlüssel, der Always Encrypted-Spalten schützt, wird auf dem Anwendungscomputer gespeichert. Dies bedeutet, dass SQL Server die Always Encrypted-Daten nicht entschlüsseln kann. Wenn der SQL Server-Computer kompromittiert wird, kann der Angreifer nur auf Always Encrypted-Daten in verschlüsselter Form zugreifen.

Für die meisten Benutzer ist die Always Encrypted-Funktion transparent, d. h. sie sind von der Funktionsweise von Always Encrypted isoliert und müssen ihre Aktivitäten nicht ändern, um von der Funktion zu profitieren.

Auf der Anwendungsseite erfolgt die Verschlüsselung durch den Softwaretreiber, der die Clientschnittstelle für SQL Server bereitstellt. Unter Linux und UNIX ist dies ein ODBC-Treiber, der Daten je nach Fahrtrichtung transparent verschlüsselt oder entschlüsselt. Im Fall des Easysoft-Treibers wird Always Encrypted durch Festlegen eines Parameters für die Verbindungszeichenfolge aktiviert.

Da die Menschen zunehmend besorgt sind, dass ihre Daten in der Cloud sicher sind, wird Always Encrypted in Azure SQL verfügbar sein, der Cloud-basierten Pay-as-you-go-Version von SQL Server. Der ODBC-Treiber von Easysoft für Azure SQL wird daher auch Always Encrypted unterstützen.

Walkthrough:Arbeiten mit Always Encrypted-Spaltendaten unter Linux

Mit dem SQL Server ODBC-Treiber von Easysoft können Sie Daten in Always Encrypted-Spalten aktualisieren und abfragen.

Erstellen Sie die Tabelle und generieren Sie die Verschlüsselungsschlüssel

Diese Schritte werden auf dem SQL Server-Rechner ausgeführt.

Erstellen Sie in SQL Server Management Studio 2016 CTP3 oder höher eine neue Datenbank.
Erstellen Sie in der neuen Datenbank eine Tabelle, die eine oder mehrere Spalten enthält, deren Inhalt Sie verschlüsseln möchten. Beispiel:
```
CREATE TABLE dbo.EncryptedTable( ID INT IDENTITY(1,1) PRIMARY KEY, LastName NVARCHAR(32), Salary INT NOT NULL);
```
Klicken Sie mit der rechten Maustaste auf die Datenbank. Wählen Sie im Popup-Menü Aufgaben> Spalten verschlüsseln aus .
Der Always Encrypted-Assistent wird gestartet.
Auf der Spaltenauswahl Seite, erweitern Sie die Tabellen und wählen Sie die Spalten aus, die Sie verschlüsseln möchten.
Wählen Sie für jede Spalte einen Verschlüsselungstyp aus.
Deterministisch - verschlüsselt immer mit demselben Chiffretext, wodurch Gleichheitssuchen, Verknüpfungen und Gruppieren nach durchgeführt werden können.

Randomisiert generiert einen anderen Chiffretextwert für denselben Klartext, der sicherer ist, aber keine Operationen unterstützt.
Wählen Sie CEK_Auto1 (New) als Verschlüsselungsschlüssel für jede Spalte, der ein neuer automatisch generierter Schlüssel ist. Wählen Sie Weiter .

Übernehmen Sie auf der Seite Master Key Configuration die Standardeinstellungen:

Field	Wert
Spaltenhauptschlüssel auswählen	Spaltenhauptschlüssel automatisch generieren
Wählen Sie den Schlüsselspeicheranbieter aus	Windows-Zertifikatspeicher
Spaltenhauptschlüssel auswählen	Aktueller Benutzer

Verwenden Sie die Schaltfläche Weiter Schaltfläche, um zur Zusammenfassung zu gelangen Seite. Wählen Sie Fertig stellen .
Warten Sie, bis der Assistent abgeschlossen ist, und wählen Sie dann Schließen .

Zertifikate exportieren

Um die Zertifikate auf den Linux-Rechner zu übertragen, müssen Sie sie zuerst unter Windows exportieren.

Geben Sie in einem Eingabeaufforderungsfenster certmgr ein , um das Zertifikate-Snap-In zu starten.
Das neue Always Encrypted-Zertifikat ist unter Zertifikate – Aktueller Benutzer> Persönlich> Zertifikate verfügbar .
Klicken Sie mit der rechten Maustaste auf das Zertifikat (das so etwas wie Always Encrypted Auto Certificate1 heißen wird ). Wählen Sie im Popup-Menü Alle Aufgaben> Exportieren aus .
Der Assistent zum Exportieren von Zertifikaten wird gestartet. Wählen Sie Weiter .
Wählen Sie Ja, privaten Schlüssel exportieren .
Akzeptieren Sie die Standardeinstellungen auf der Seite Exportdateiformat. Wählen Sie Weiter .
Geben Sie ein Passwort ein, wenn Sie dazu aufgefordert werden. Wählen Sie Weiter .
Benennen und speichern Sie das Zertifikat, wenn Sie dazu aufgefordert werden. Beispiel:CMK_Auto1.pfx .
Verwenden Sie die Schaltfläche Weiter und Fertig stellen Schaltflächen, um den Assistenten abzuschließen.

Installieren der Zertifikate unter Linux

Übertragen Sie die exportierten Zertifikate auf den Linux-Computer, von dem aus Sie auf die Always Encrypted-Spalten zugreifen möchten:

Kopieren Sie das soeben exportierte Zertifikat nach ~/ssl/private auf dem Linux- oder UNIX-Computer, auf dem Sie den SQL Server-ODBC-Treiber installiert haben.
~ ist das Basisverzeichnis des Benutzers, der die Anwendung ausführt, die über den Easysoft ODBC-Treiber eine Verbindung zu SQL Server herstellt. ~/ssl/private ist der Ort, an dem die in den Treiber integrierte OpenSSL-Schicht versucht, ein persönliches Zertifikat zu laden. Erstellen Sie das Verzeichnis, falls es nicht vorhanden ist. Zum Beispiel:
```
$ mkdir -p ~/ssl/private$ cd ~/ssl/private$ mv /tmp/CMK_Auto1.pfx .
```
Um das Zertifikat mit dem SQL Server ODBC-Treiber zu verwenden, müssen Sie die darin enthaltene Passphrase entfernen. Dazu muss OpenSSL auf dem Rechner installiert sein. (Dies ist nur zum Entfernen der Passphrase erforderlich, für andere Vorgänge verwendet der SQL Server-ODBC-Treiber eine integrierte OpenSSL-Schicht.) Entfernen Sie die Passphrase mit den folgenden Befehlen. Wenn Sie nach der Sekunde zur Eingabe der Passphrase aufgefordert werden Befehl, drücken Sie RETURN, ohne etwas einzugeben. Dadurch wird die Passphrase auf nichts gesetzt.
```
$ openssl pkcs12 -in CMK_Auto1.pfx -nodes -out temp.pemEnter Importpasswort:*******MAC verifiziert OK$ openssl pkcs12 -export -in temp.pem -out nopassphrase.p12Enter Exportpasswort:Verifizierung - Geben Sie das Exportpasswort ein:$
```
Zum Laden des Zertifikats verwendet der SQL Server-ODBC-Treiber Metainformationen, die er von SQL Server über die verschlüsselte Spalte erhält. Der Zertifikatsname, den der Treiber von SQL Server erhält, hat das Format my/thumbprint . Sie müssen diese Namenskonvention für das Zertifikat verwenden. Verwenden Sie OpenSSL, um den Fingerabdruck des Zertifikats anzuzeigen, und benennen Sie das Zertifikat dann in einem Unterverzeichnis namens my um:
```
$ openssl x509 -in temp.pem -fingerprint -noout | tr -d ":"SHA1 Fingerprint=EFC1940E545941D6C05C763361403F55A5DEF0E8$ mkdir my$ cp nopassphrase.p12 my/EFC1940E545941D6C05C763361403F55A5DEF0E8$ ln -s my My
```
Hinweis Beim Testen ist uns aufgefallen, dass SQL Server das Zertifikat manchmal My/thumbprint . Der symbolische Link im obigen Beispiel umgeht diese Inkonsistenz.

Installieren des SQL Server ODBC-Treibers

Der SQL Server ODBC-Treiber stellt nicht nur die Konnektivitätsebene zwischen der Anwendung und SQL Server bereit, er verarbeitet auch die Verschlüsselung/Entschlüsselung von Daten, die in Always Encrypted-Spalten gespeichert sind.

Installieren und lizenzieren Sie den SQL Server-ODBC-Treiber. Anweisungen hierzu finden Sie in der Dokumentation zum SQL Server-ODBC-Treiber. Wenn Ihre Anwendung 64-Bit ist, laden Sie die 64-Bit-Version des ODBC-Treibers herunter. Verwenden Sie andernfalls unabhängig von der Architektur des Betriebssystems die 32-Bit-Version des Treibers.

Eine ODBC-Datenquelle enthält die Informationen zur Verbindungszeichenfolge, die es dem SQL Server-ODBC-Treiber ermöglichen, eine Verbindung mit der SQL Server-Zielinstanz herzustellen. Auf unserem Rechner werden ODBC-Datenquellen in /etc/odbc.ini gespeichert . Dieser Datenquellenauszug zeigt die relevanten Einstellungen für Always Encrypted-Spalten:

[SQLSERVER_2016]Driver=Easysoft ODBC-SQL-Server SSL # Muss die SSL-Version von driverServer=machine\sqlserver_instanceDatabase=database_with_always_encrypted_dataUser=user verwenden # Dies kann eine Windows- oder SQL Server-Anmeldung sein.Password=passwordTrusted_Connection=Yes # Setzen Sie dies auf No für eine SQL Server-Anmeldung zum # Einfügen in eine Always Encrypted-Spalte, die auf Aktiviert gesetzt ist

Hinweis Wenn Ihre Verbindung mit dem Fehler „SSL-Verbindung bei Systemaufruf fehlgeschlagen“ fehlschlägt, fehlt Ihrem System ein „Randomness Device“. Siehe Entropy -Attribut im SQL Server ODBC-Treiberhandbuch für Informationen darüber, was Sie dagegen tun können.

Einfügen von Daten in eine immer verschlüsselte Spalte

Wir haben jetzt eine leere Tabelle mit Always Encrypted-Spalten erstellt und unseren Linux-Clientcomputer so eingerichtet, dass der SQL Server-ODBC-Treiber mit Always Encrypted-Daten arbeiten kann. Als nächstes müssen wir die Tabelle mit Daten füllen.

Um Daten in eine Always Encrypted-Spalte einzufügen, muss eine Anwendung:

Verwenden Sie eine parametrisierte Einfügung, d. h. INSERT INTO EncryptedTable VALUES (?, ?).
Dadurch kann der SQL Server-ODBC-Treiber zwischen den Spaltenwerten (die er verschlüsseln muss) und dem SQL-Anweisungstext (der im Klartext bleiben muss; denken Sie daran, dass SQL Server bei Always Encrypted keine Entschlüsselung durchführt) unterscheiden. P>
Beschreiben Sie explizit den Datentyp der Parameter.
SQL Server stellt nicht die erforderlichen Informationen über eine Always Encrypted-Spalte für den SQL Server-ODBC-Treiber bereit, um den Datentyp mithilfe von SQLDescribeParam zu ermitteln .

Hier ist ein Perl-Beispiel, das zeigt, wie das geht:

# Verwenden Sie Perl DBI / DBD:ODBC, um Daten in Always Encrypted-Spalten einzufügen.verwenden Sie strict;verwenden Sie Warnungen;verwenden Sie DBI;my $data_source =q/dbi:ODBC:SQLSERVER_2016/;my $h =DBI->connect( $data_source) or die "Can't connect to $data_source:$DBI::errstr";$h->{RaiseError} =1;my $s =$h->prepare(q/insert into EncryptedTable values(?, ?)/);my $lastname='Smith';my $salary=25000;# Legt den Datentyp der Zielspalten fest.# SQLDescribeParam kann nicht mit Always Encrypted-Spalten verwendet werden.$s->bind_param(1, $lastname, DBI ::SQL_WVARCHAR);$s->bind_param(2, $salary, DBI::SQL_INTEGER);$s->execute($lastname,$salary);$h->disconnect;

Hier ist ein C-Beispiel, das zeigt, wie das geht:

#include #include #include #include #include #include #include #define NACHNAME_LEN 6SQLHENV henv =SQL_NULL_HENV; // UmgebungSQLHDBC hdbc =SQL_NULL_HDBC; // VerbindungshandleSQLHSTMT hstmt =SQL_NULL_HSTMT; // Statement handleSQLRETURN retcode;SQLCHAR strLastName[]="Jones";SQLINTEGER pSalary=25000;SQLLEN lenLastName=0;int main () { // Umgebung zuweisen retcode =SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &henv); // ODBC-Version festlegen retcode =SQLSetEnvAttr(henv, SQL_ATTR_ODBC_VERSION, (SQLPOINTER*)SQL_OV_ODBC3, 0); // Verbindung zuweisen retcode =SQLAllocHandle(SQL_HANDLE_DBC, henv, &hdbc); // Mit DSN verbinden retcode =SQLConnect(hdbc, (SQLCHAR*) "MyDSN", SQL_NTS, (SQLCHAR*) NULL, 0, NULL, 0); // Anweisungshandle zuweisen retcode =SQLAllocHandle(SQL_HANDLE_STMT, hdbc, &hstmt); // Parameter an alle Felder binden retcode =SQLBindParameter(hstmt, 1, SQL_PARAM_INPUT, SQL_C_CHAR, SQL_WVARCHAR, LASTNAME_LEN, 0, strLastName, LASTNAME_LEN, &lenLastName); retcode =SQLBindParameter(hstmt, 2, SQL_PARAM_INPUT, SQL_C_LONG, SQL_INTEGER, 0, 0, &pSalary, 0, NULL); retcode =SQLPrepare(hstmt, (SQLCHAR*)"INSERT INTO [dbo].[EncryptedTable] ([LastName],[Gehalt]) VALUES (?,?)", SQL_NTS); lenLastName=strlen((char*)strLastName); retcode =SQLExecute(hstmt);exit:printf ("\nComplete.\n"); // Freie Handles // Anweisung if (hstmt !=SQL_NULL_HSTMT) SQLFreeHandle(SQL_HANDLE_STMT, hstmt); // Verbindung if (hdbc !=SQL_NULL_HDBC) { SQLDisconnect(hdbc); SQLFreeHandle (SQL_HANDLE_DBC, hdbc); } // Umgebung if (henv !=SQL_NULL_HENV) SQLFreeHandle(SQL_HANDLE_ENV, henv); gib 0 zurück;}

Jetzt sind die Spalten gefüllt, wir können isql verwenden, um die Daten abzurufen:

$ /usr/local/easysoft/unixODBC/bin/isql.sh -v SQLSERVER_2016SQL> select * from EncryptedTable+----+----------+-------- ----+| Ausweis | Nachname | Gehalt |+----+----------+------------+| 1 | Schmied | 25000 |+----+----------+------------+

Wir hatten die Treiberprotokollierung in unserer Datenquelle aktiviert. Der folgende Auszug aus dem Treiberprotokoll zeigt das:

SQL Server liefert den Zertifikatsnamen als Metainformationen über die Spalte.
Die Spaltendaten werden auf der SQL Server-Seite verschlüsselt und bleiben daher während der Übertragung verschlüsselt. Der SQL Server-ODBC-Treiber auf dem Client entschlüsselt die Spaltenwerte und gibt sie dann im Klartext an die Anwendung zurück.

1. M.S.S.Q.L._.C.E.R.T.I.F.I.C.A.T.E._.S.T.O.R.E.7.C.u.r.r.e.n.t.U.s.e.r./.m.y./.7.2.8.8.1.8.C.5.F.B.2.C.6.E.B.F.C.2.5.3.D.B.C.8.3.D.B.C.1.2 .8.9.0.8.3.E..R.S.A._.O.A.E.P.......8.I.D.................@.......... L.a.s.t.N.a.m.e........Q.......8....S.a.l.a.r.y.........2. PKTDUMP:Verschlüsselte Spalte.);...'A..zs..I..N.]r..p.-..$....S;.].km6.....3cr.OhR ..j*.....fj....ARN{V.F.....DETAIL:EVP_DecryptInit gibt 1 zurückDETAIL:EVP_DecryptUpdate gibt 1 zurück, 0DETAIL:EVP_DecryptUpdate gibt 1 zurück, 16DETAIL:EVP_DecryptFinal gibt 1 zurück, 0PKTDUMP:dataS.m.i.t.h. Siehe auch
  Verwendung von Data Protected mit einem Azure Key Vault unter Linux
 Verwenden von geschützten Daten mit einem benutzerdefinierten Schlüsselspeicher von Linux