SQL Server 2016:Alltid krypterad

SQL Server 2016 innehåller en databassäkerhetsfunktion som heter Alltid krypterad. Eftersom vi har lagt till Always Encrypted-stöd till SQL Server ODBC-drivrutinen kommer våra kunder att kunna dra nytta av den här funktionen.

Alltid krypterad skyddar SQL Server-data vid den punkt där den är mest mottaglig för attack:när dessa data används. Till exempel vid transaktioner och beräkningar. Detta skiljer sig från befintliga SQL Server-krypteringsfunktioner eftersom de kräver att data dekrypteras innan operationer kan utföras på den.

Krypteringsnyckeln som skyddar alltid krypterade kolumner lagras på applikationsmaskinen. Detta innebär att SQL Server inte kan dekryptera den alltid krypterade data. Om SQL Server-maskinen äventyras kommer angriparen endast att kunna komma åt Alltid krypterad data i chifferform.

För de flesta användare kommer funktionen Alltid krypterad att vara transparent, det vill säga att de är isolerade från funktionerna i Always Encrypted och behöver inte ändra vad de gör för att dra nytta av funktionen.

I applikationsänden görs krypteringen av mjukvarudrivrutinen som tillhandahåller klientgränssnittet för SQL Server. På Linux och UNIX är detta en ODBC-drivrutin, som transparent krypterar eller dekrypterar data beroende på färdriktningen. När det gäller Easysoft-drivrutinen aktiveras Always Encrypted genom att ställa in en anslutningssträngparameter.

Eftersom människor blir allt mer oroliga för att deras data är säkra i molnet, kommer Always Encrypted att vara tillgänglig i Azure SQL, den molnbaserade pay-as-you-go-versionen av SQL Server. Easysofts ODBC-drivrutin för Azure SQL kommer därför också att stödja Always Encrypted.

Genomgång:Arbeta med alltid krypterad kolumndata på Linux

Easysofts SQL Server ODBC-drivrutin gör att du kan uppdatera och fråga efter data som finns i alltid krypterade kolumner.

Skapa tabellen och generera krypteringsnycklarna

Dessa steg görs på SQL Server-maskinen.

Skapa en ny databas i SQL Server Management Studio 2016 CTP3 eller senare.
Skapa en tabell i den nya databasen som innehåller en eller flera kolumner vars innehåll du vill kryptera. Till exempel:
```
CREATE TABLE dbo.EncryptedTable( ID INT IDENTITY(1,1) PRIMÄRNYCKEL, Efternamn NVARCHAR(32), Lön INT INTE NULL);
```
Högerklicka på databasen. Från popup-menyn väljer du Uppgifter> Kryptera kolumner .
Alltid krypterad guide startar.
På Kolumnval expandera tabellerna och välj de kolumner som du vill kryptera.
Välj en krypteringstyp för varje kolumn.
Deterministisk - krypterar alltid till samma chiffertext, vilket gör att likvärdighetssökningar, sammanfogningar och grupper kan utföras.

Slumpmässigt genererar ett annat krypteringstextvärde för samma oformaterade text, vilket är säkrare, men som inte stöder några operationer.
Välj CEK_Auto1 (New) som krypteringsnyckel för varje kolumn, vilket är en ny automatiskt genererad nyckel. Välj Nästa .
På huvudnyckelkonfigurationssidan accepterar du standardinställningarna:

Fält Värde

Välj kolumnhuvudnyckel Generera kolumnhuvudnyckel automatiskt

Välj nyckelbutiksleverantör Windows certifikatarkiv

Välj kolumnhuvudnyckel Nuvarande användare
Använd Nästa för att fortsätta till Sammanfattning sida. Välj Slutför .
Vänta tills guiden är klar och välj sedan Stäng .

Fält	Värde
Välj kolumnhuvudnyckel	Generera kolumnhuvudnyckel automatiskt
Välj nyckelbutiksleverantör	Windows certifikatarkiv
Välj kolumnhuvudnyckel	Nuvarande användare

Exportera certifikaten

För att överföra certifikaten till Linux-maskinen måste du först exportera dem till Windows.

Skriv certmgr i ett kommandotolksfönster , för att starta snapin-modulen certifikat.
Det nya Alltid krypterade certifikatet kommer att finnas tillgängligt under Certifikat - Aktuell användare> Personligt> Certifikat .
Högerklicka på certifikatet (som kommer att kallas något i stil med Always Encrypted Auto Certificate1 ). Från popup-menyn väljer du Alla uppgifter> Exportera .
Certifikatexportguiden startar. Välj Nästa .
Välj Ja, exportera den privata nyckeln .
Acceptera standardinställningarna på sidan Exportera filformat. Välj Nästa .
Ange ett lösenord när du uppmanas. Välj Nästa .
Namnge och spara certifikatet när du uppmanas. Till exempel CMK_Auto1.pfx .
Använd Nästa och Slutför knappar för att slutföra guiden.

Installera certifikaten på Linux

Överför de exporterade certifikaten till Linux-maskinen från vilken du vill komma åt kolumnerna Alltid krypterad:

Kopiera certifikatet du just har exporterat till ~/ssl/private på Linux- eller UNIX-datorn där du har installerat SQL Server ODBC-drivrutinen.
~ är hemkatalogen för användaren som ska köra programmet som ansluter till SQL Server via Easysoft ODBC-drivrutinen. ~/ssl/private är platsen där OpenSSL-lagret som är inbyggt i drivrutinen kommer att försöka ladda ett personligt certifikat från. Skapa katalogen om den inte finns. Till exempel:
```
$ mkdir -p ~/ssl/private$ cd ~/ssl/private$ mv /tmp/CMK_Auto1.pfx .
```
För att använda certifikatet med SQL Server ODBC-drivrutinen måste du ta bort lösenfrasen som den innehåller. För att göra detta måste OpenSSL vara installerat på maskinen. (Detta är bara nödvändigt för att ta bort lösenfrasen, för andra operationer använder SQL Server ODBC-drivrutinen ett inbyggt OpenSSL-lager.) Ta bort lösenfrasen med följande kommandon. När du tillfrågas om lösenfrasen efter andra kommando, tryck på RETURN utan att ange något. Detta kommer att ställa in lösenfrasen till ingenting.
```
$ openssl pkcs12 -in CMK_Auto1.pfx -nodes -out temp.pemEnter Import Password:*******MAC verified OK$ openssl pkcs12 -export -in temp.pem -out nopassphrase.p12Enter Export Password:Verifierar - Ange exportlösenord:$
```
För att ladda certifikatet använder SQL Server ODBC-drivrutinen metainformation som den tar emot från SQL Server om den krypterade kolumnen. Certifikatnamnet som drivrutinen får från SQL Server har formatet my/thumbprint . Du måste använda denna namnkonvention för certifikatet. Använd OpenSSL för att visa certifikatets tumavtryck och byt sedan namn på certifikatet i en underkatalog som heter my:
```
$ openssl x509 -in temp.pem -fingerprint -noout | tr -d ":"SHA1 Fingerprint=EFC1940E545941D6C05C763361403F55A5DEF0E8$ mkdir my$ cp nopassphrase.p12 my/EFC1940E545941D6C05C7633561$ mypresmypre 
 Obs Under testningen märkte vi att SQL Server ibland döpte certifikatet till My/thumbprint . Den symboliska länken i exemplet ovan fungerar runt denna inkonsekvens.
 
```

Installera SQL Server ODBC-drivrutinen

SQL Server ODBC-drivrutinen tillhandahåller inte bara anslutningslagret mellan applikationen och SQL Server, den hanterar även kryptering/dekryptering av data som lagras i Alltid krypterad kolumner.

Installera och licensiera SQL Server ODBC-drivrutinen. För instruktioner om hur du gör detta, se SQL Server ODBC-drivrutinens dokumentation. Om din applikation är 64-bitars, ladda ner 64-bitarsversionen av ODBC-drivrutinen. Annars, använd 32-bitarsversionen av drivrutinen, oavsett operativsystemets arkitektur.

En ODBC-datakälla innehåller anslutningsstränginformationen som gör det möjligt för SQL Server ODBC-drivrutinen att ansluta till SQL Server-målinstansen. På vår maskin lagras ODBC-datakällor i /etc/odbc.ini . Detta datakällextrakt visar relevanta inställningar för Alltid krypterade kolumner:

[SQLSERVER_2016]Driver=Easysoft ODBC-SQL Server SSL # Måste använda SSL-versionen av driverServer=maskin\sqlserver_instanceDatabase=database_with_always_encrypted_dataUser=användare # Detta kan vara en Windows- eller SQL Server-login.Password=passwordTrusted_Connection=Ja # Ställ detta till Nej för en SQL Server loginColumnEncryption=Aktiverad data Alltid krypterad eller aktiverad # till # infoga i en Alltid krypterad kolumn inställd på Aktiverad

Obs Om din anslutning misslyckas med felet "SSL-anslutning misslyckades i syscall", saknar ditt system en "slumpenhet". Se Entropy attribut i SQL Server ODBC-drivrutinsmanualen för information om vad du ska göra åt detta.

Infoga data i en alltid krypterad kolumn

Vi har nu skapat en tom tabell med Always Encrypted-kolumner och ställt in vår Linux-klientmaskin så att SQL Server ODBC-drivrutinen kan arbeta med Always Encrypted Data. Därefter måste vi fylla i tabellen med data.

För att infoga data i en Alltid krypterad kolumn måste ett program:

Använd en parametriserad infogning, dvs. INSERT INTO EncryptedTable VALUES (?, ?).
Detta gör det möjligt för SQL Server ODBC-drivrutinen att skilja mellan kolumnvärdena (som den behöver för att kryptera) och SQL-satstexten (som måste förbli i vanlig text; med Alltid krypterad, kom ihåg, SQL Server gör ingen dekryptering).
Beskriv explicit datatypen för parametrarna.
SQL Server tillhandahåller inte nödvändig information om en Always Encrypted-kolumn för SQL Server ODBC-drivrutin för att upptäcka datatypen genom att använda SQLDescribeParam .

Här är ett Perl-exempel som visar hur man gör detta:

# Använd Perl DBI / DBD:ODBC för att infoga data i Always Encrypted columns.use strict;use warnings;use DBI;my $data_source =q/dbi:ODBC:SQLSERVER_2016/;my $h =DBI->connect( $data_source) eller dö "Kan inte ansluta till $data_source:$DBI::errstr";$h->{RaiseError} =1;my $s =$h->prepare(q/insert into EncryptedTable values(?, ?)/);my $lastname='Smith';my $salary=25000;# Ställ in datatypen för målkolumnerna.# Kan inte använda SQLDescribeParam med alltid krypterade kolumner.$s->bind_param(1, $lastname, DBI ::SQL_WVARCHAR);$s->bind_param(2, $salary, DBI::SQL_INTEGER);$s->exekvera($lastname,$salary);$h->koppla från;

Här är ett C-exempel som visar hur man gör detta:

#include #include #include #include #include #include #include #define LASTNAME_LEN 6SQLHENV henv =SQL_NULL_HENV; // EnvironmentSQLHDBC hdbc =SQL_NULL_HDBC; // AnslutningshandtagSQLHSTMT hstmt =SQL_NULL_HSTMT; // Statement handleSQLRETURN retcode;SQLCHAR strLastName[]="Jones";SQLINTEGER pSalary=25000;SQLLEN lenLastName=0;int main () { // Allocate environment retcode =SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE); // Set ODBC Version retcode =SQLSetEnvAttr(henv, SQL_ATTR_ODBC_VERSION, (SQLPOINTER*)SQL_OV_ODBC3, 0); // Allocate Connection retcode =SQLAllocHandle(SQL_HANDLE_DBC, henv, &hdbc); // Anslut till DSN retcode =SQLConnect(hdbc, (SQLCHAR*) "MyDSN", SQL_NTS, (SQLCHAR*) NULL, 0, NULL, 0); // Allocate Statement Handle retcode =SQLAllocHandle(SQL_HANDLE_STMT, hdbc, &hstmt); // Bind parametrar till alla fält 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, &pLön, 0, NULL); retcode =SQLPrepare(hstmt, (SQLCHAR*)"INSERT INTO [dbo].[EncryptedTable] ([Efternamn],[Lön]) VALUES (?,?)", SQL_NTS); lenLastName=strlen((char*)strEfternamn); retcode =SQLExecute(hstmt);exit:printf ("\nComplete.\n"); // Fria handtag // Statement if (hstmt !=SQL_NULL_HSTMT) SQLFreeHandle(SQL_HANDLE_STMT, hstmt); // Anslutning if (hdbc !=SQL_NULL_HDBC) { SQLDisconnect(hdbc); SQLFreeHandle(SQL_HANDLE_DBC, hdbc); } // Environment if (henv !=SQL_NULL_HENV) SQLFreeHandle(SQL_HANDLE_ENV, henv); returnera 0;}

Nu är kolumnerna fyllda, vi kan använda isql för att hämta data:

$ /usr/local/easysoft/unixODBC/bin/isql.sh -v SQLSERVER_2016SQL> välj * från EncryptedTable+----+----------+-------- ----+| ID | Efternamn | Lön |+----+-----------+-------+| 1 | Smith | 25000 |+----+-----------+--------+

Vi hade drivrutinloggning aktiverad i vår datakälla. Följande utdrag från drivrutinsloggen visar att:

SQL Server tillhandahåller certifikatnamnet som metainformation om kolumnen.
Kolumndata krypteras i SQL Server-änden och förblir därför krypterad under överföring. SQL Server ODBC-drivrutinen på klienten dekrypterar kolumnvärdena och returnerar dem sedan i vanlig text till applikationen.

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.B.F.6 .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:Krypterad kolumn.);...'A..zs..I..N.]r..p.-..$....S;.].km6.....3cr.OhR ..j*.....fj....ARN{V.F.....DETAIL:EVP_DecryptInit returnerar 1DETAIL:EVP_DecryptUpdate returnerar 1, 0DETAIL:EVP_DecryptUpdate returnerar 1, 16DETAIL:EVP_DecryptFinal returnerar 1, 0PKTDUMP:dataS.h. Se även
  Använda dataskyddad med ett Azure Key Vault från Linux
 Använda dataskyddad med ett anpassat nyckellager från Linux