SQL Server 2016 Întotdeauna criptat: ușor de implementat, greu de spart

Datele sunt un activ cheie al oricărei companii, în special datele tranzacționale care dețin secrete de afaceri, cum ar fi dosarele financiare sau de sănătate. Datele sunt cele mai vulnerabile în tranzit între serverul care le stochează și acel client care le solicită.

Abordarea standard pentru asigurarea securității este de a cripta datele de pe server și de a utiliza protocolul HTTPS activat pentru SSL pentru a securiza datele în transport. Dar dacă am putea crește și mai mult nivelul de securitate, folosind HTTPS și trimițând date în format criptat prin linia de comunicație, doar pentru a decripta datele clienților care au certificate valabile? Această abordare ar face mult mai dificil un atac tradițional „man-in-the-middle” (MITM).

Soluția Microsoft la această problemă este Always Encrypted, o modalitate de a trimite date criptate prin conductă și de a le decripta numai de către utilizatorii cu acces la certificate valide. Deci, chiar dacă atacatorul primește datele, fără un certificat corespunzător stocat pe computerul client, datele ar fi inutile.

Acest articol descrie cum să configurați și să utilizați Always Encrypted și este recomandat să le citiți oricui trimite date importante prin liniile publice de comunicare, chiar dacă sunt securizate cu SSL.

Conceptul din spatele Always Encrypted

Always Encrypted este o tehnologie de criptare la nivelul clientului pe care Microsoft a introdus-o cu SQL Server 2016. Always Encrypted păstrează datele criptate automat, nu numai atunci când sunt scrise, ci și atunci când sunt citite de o aplicație aprobată. Spre deosebire de Transparent Data Encryption, care criptează datele și fișierele jurnal de pe disc în timp real, dar permite ca datele să fie citite de orice aplicație care interogează datele, Always Encrypted solicită aplicației dvs. client să utilizeze un driver activat Always Encrypted pentru a comunica cu Bază de date. Prin utilizarea acestui driver, aplicația transferă în siguranță date criptate în baza de date care pot fi apoi decriptate ulterior numai de o aplicație care are acces la cheia de criptare. Orice altă aplicație care interogează datele poate prelua, de asemenea, valorile criptate, dar acea aplicație nu poate folosi datele fără cheia de criptare, făcând astfel datele inutile. Din cauza acestei arhitecturi de criptare, instanța SQL Server nu vede niciodată versiunea necriptată a datelor.

În acest moment, singurele drivere activate pentru Always Encrypted sunt furnizorul de date .NET Framework pentru SQL Server, care necesită instalarea .NET Framework versiunea 4.6 pe computerul client și driverul JDBC 6.0. Probabil că se va schimba în timp, dar acestea sunt cerințele oficiale Always Encrypted din aprilie 2017.

Dar de ce avem nevoie de această tehnologie? Există câteva motive bune pentru care ar trebui utilizat Always Encrypted:

• Securitate — Datele au trebuit întotdeauna să fie securizate. Acum că SSL este compromis, Always Encrypted umple golul cu un alt nivel de protecție a conductelor de transport.
• Suport de reglementare — Datele trebuie să fie criptate și ferite de privirile indiscrete ale DBA prin tot mai multe reglementări din industrie, în primul rând în industria financiară și a telecomunicațiilor. Acest lucru este descris în standardul PII („Informații de identificare personală”), care afirmă că lucruri precum numerele cardurilor de credit, numerele de securitate socială, numele și adresele trebuie protejate, altfel proprietarul datelor poate fi penalizat sever.

Cum să utilizați Always Encrypted

Utilizarea Always Encrypted necesită o cantitate mică de pregătire în serverul de baze de date care stochează tabelele criptate. Pregătirea este un proces în două etape:

• Creați definiția cheii principale de coloană
• Creați cheia de criptare a coloanei

Cheia principală a coloanei

Deci, ce este o cheie principală de coloană?

Cheia principală a coloanei este un certificat care este stocat într-un depozit de certificate Windows (care este folosit demo ca opțiune de stocare a certificatelor), un modul de securitate hardware de la terți (un nume generic pentru soluții terțe pentru instalarea, gestionarea și utilizarea certificate) sau Azure Key Vault (soluția Microsoft bazată pe cloud pentru gestionarea certificatelor).

Aplicația care criptează datele utilizează cheia principală a coloanei pentru a proteja diverse chei de criptare a coloanei care se ocupă de criptarea datelor din coloanele unui tabel al bazei de date. Utilizarea depozitelor de certificate de la SQL Server, care uneori sunt denumite Enterprise Key Manager , necesită utilizarea SQL Server Enterprise Edition.

În acest articol, descriem utilizarea unui certificat autosemnat pe care îl stocați în Magazinul de certificate Microsoft al sistemului de operare Windows. Deși această abordare nu este configurația optimă, demonstrează conceptul de Always Encrypted, dar trebuie să se precizeze, de asemenea, că această abordare nu este acceptabilă pentru mediile de producție , unde gestionarea certificatelor trebuie făcută cu conturi de utilizator separate, securizate și, de preferință, , pe servere separate.

Puteți crea o definiție a cheii principale de coloană utilizând interfața grafică din SQL Server Management Studio (SSMS) sau folosind T-SQL. În SSMS, conectați-vă la instanța bazei de date SQL Server 2016 în care doriți să utilizați Always Encrypted pentru a proteja un tabel al bazei de date.

Crearea și utilizarea cheilor principale de coloană

În Object Explorer, navigați mai întâi la baza de date, apoi la Securitate, apoi extindeți folderul Always Encrypted Keys pentru a afișa cele două subfoldere ale sale, așa cum se arată în următoarele figuri:

Pentru a crea cheia principală a coloanei, faceți clic dreapta pe folderul Column Master Keys și selectați New Column Master Key . În caseta de dialog New Column Master Key , tastați un nume pentru cheia principală de coloană, specificați dacă să stocați cheia în depozitul de certificate al utilizatorului curent sau al mașinii locale sau în Azure Key Vault, apoi selectați un certificat din listă. Dacă nu există certificate sau dacă doriți să utilizați un nou certificat autosemnat, faceți clic pe butonul Generate Certificate , apoi faceți clic pe OK . Acest pas creează un certificat autosemnat și îl încarcă în depozitul de certificate al contului de utilizator curent care rulează SSMS.

Notă: ar trebui să efectuați acești pași pe o mașină de încredere, dar nu pe computerul care găzduiește instanța dvs. SQL Server. În acest fel, datele rămân protejate în SQL Server chiar dacă computerul gazdă este compromis.

Deci, după ce ai creat certificatul și l-ai configurat ca cheie principală de coloană, trebuie să-l exporti și să îl distribui pe toate computerele care găzduiesc clienți care necesită acces la date. Dacă o aplicație client este bazată pe web, trebuie să încărcați certificatul pe serverul web. Dacă este o aplicație instalată pe computerele utilizatorilor, atunci trebuie să implementați certificatul individual pe computerul fiecărui utilizator.

Puteți găsi instrucțiuni aplicabile pentru exportul și importul certificatelor pentru sistemul dvs. de operare la următoarele adrese URL:

• Exportul certificatelor
  • Windows 7 și Windows Server 2008 R2
  • Windows 8 și Windows Server 2012
  • Windows 8.1 și Windows Server 2012 R2
  • Windows 10 și Windows Server 2016
• Import de certificate
  • Windows 7 și Windows Server 2008 R2
  • Windows 8 și Windows Server 2012
  • Windows 8.1 și Windows Server 2012 R2
  • Windows 10 și Windows Server 2016

Când importați certificate în depozitul de certificate pe computere cu o aplicație care criptează și decriptează datele, trebuie să importați certificatele fie în depozitul de certificate al mașinii, fie în depozitul de certificate al contului de domeniu care rulează aplicația.

Cheie de criptare a coloanei

După crearea unei chei principale de coloană, sunteți gata să creați chei de criptare pentru anumite coloane. Driverul SQL Server 2016 ADO.NET folosește chei de criptare a coloanelor pentru a cripta datele înainte de a le trimite către SQL Server și pentru a decripta datele după ce le preia din instanța SQL Server 2016. Ca și în cazul cheii principale de coloană, puteți crea chei de criptare a coloanei utilizând T-SQL sau SSMS. În timp ce cheile principale de coloană sunt mai ușor de creat folosind T-SQL, cheile de criptare a coloanei sunt mai ușor de creat folosind SSMS.

Pentru a crea o cheie de criptare a coloanei, utilizați Object Explorer pentru a vă conecta la instanța bazei de date, navigați la baza de date, apoi la Security și extindeți folderul Always Encrypted Keys . Faceți clic dreapta pe Column Encryption Keys , apoi selectați New Column Encryption Key . În caseta de dialog New Column Encryption Key , tastați un nume pentru noua cheie de criptare, selectați o Column Master Key Definition în lista derulantă și apoi faceți clic pe OK . Acum puteți utiliza cheia de criptare a coloanei în definirea unui nou tabel.

Crearea unui tabel cu valori criptate

După ce ați creat definiția cheii principale de coloană și cheile de criptare a coloanei, puteți crea un tabel pentru a păstra valorile criptate.

Înainte de a face acest lucru, trebuie să decideți ce tip de criptare să utilizați, ce coloane să criptați și dacă puteți indexa aceste coloane. Cu caracteristica Always Encrypted , definiți dimensiunile coloanei în mod normal, iar SQL Server ajustează dimensiunea de stocare a coloanei pe baza setărilor de criptare. După ce vă creați tabelul, poate fi necesar să vă schimbați aplicația pentru a executa comenzi pe acest tabel utilizând Always Encrypted .

Tipuri de criptare SQL Server 2016

Înainte de a crea un tabel care să conțină valori criptate, trebuie să decideți dacă fiecare coloană trebuie sau nu criptată.

În primul rând, această coloană va fi folosită pentru a căuta valori sau doar pentru a returna acele valori?

Dacă coloana va fi utilizată pentru căutări, coloana trebuie să utilizeze un tip de criptare deterministă , care permite operațiuni de egalitate. Cu toate acestea, există limitări la căutarea datelor care au fost criptate prin utilizarea funcției Always Encrypted . SQL Server 2016 acceptă numai operațiuni de egalitate, care includ joins equal to , not equal to , (care folosesc egalitatea) și folosind valoarea din clauza GROUP BY . Orice căutare folosind LIKE nu este acceptată. În plus, sortarea datelor care sunt criptate folosind Always Encrypted trebuie făcută la nivel de aplicație, deoarece SQL Server va sorta pe baza valorii criptate, mai degrabă decât pe valoarea decriptată.

Dacă coloana nu va fi utilizată pentru localizarea înregistrărilor, atunci coloana ar trebui să utilizeze tipul de criptare aleatorie. Acest tip de criptare este mai sigur, dar nu acceptă căutări, alăturari sau operațiuni de grupare.

Crearea unui tabel cu coloane criptate

Când creați tabele, utilizați sintaxa normală CREATE TABLE cu câțiva parametri suplimentari în definiția coloanei. Trei parametri sunt utilizați în sintaxa ENCRYPTED WITH pentru CREATE TABLE .

Primul dintre acestea este parametrul ENCRYPTION_TYPE , care acceptă o valoare RANDOMIZED sau DETERMINISTIC . Al doilea este parametrul ALGORITHM , care acceptă doar o valoare RAEAD_AES_256_CBC_HMAC_SHA_256 . Al treilea parametru este COLUMN_ENCRYPTION_KEY , care este cheia de criptare pe care o utilizați pentru a cripta valoarea.

 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

Indexarea cu Always Encrypted

Coloanele care conțin date criptate pot fi folosite ca coloane cheie în cadrul indicilor, cu condiția ca acele coloane să fie criptate utilizând tipul de criptare DETERMINISTIC . Coloanele criptate folosind tipul de criptare RANDOMIZED returnează un mesaj de eroare atunci când încercați să creați un index pe acele coloane. Coloanele criptate utilizând oricare dintre tipurile de criptare pot fi utilizate ca coloane INCLUDE în cadrul indecșilor non-cluster.

Deoarece valorile criptate pot fi indexuri, nu sunt necesare măsuri suplimentare de reglare a performanței pentru valorile criptate cu Always Encrypted dincolo de indexarea și reglarea pe care le efectuați în mod normal. Lățimea de bandă suplimentară a rețelei și I/O mai mari sunt singurele efecte secundare care rezultă din dimensiunea crescută a valorilor returnate.

Performanță întotdeauna criptată

Performanța este întotdeauna un factor cheie, mai ales în acest caz, când adăugăm suprasarcina de criptare la traficul obișnuit al bazei de date. Cel mai bun site pentru a testa performanța este SQL Performance, care a testat execuția interogărilor și utilizarea discului în diferite scenarii:

Întrucât există lucrări de CPU și hard disk care trebuie efectuate cu procese de criptare și decriptare, există un impact evident asupra cantității de spațiu de stocare utilizată și a duratei interogărilor. Deoarece acest lucru este influențat de mediul dvs. – caracteristicile CPU, RAM și disc – ar trebui să testați dacă acest lucru va prezenta o problemă în producție.

Notă: În cazul în care doriți să aflați mai multe despre optimizarea performanței Microsoft SQL Server, vă rugăm să consultați unul dintre articolele noastre anterioare, Cum să reglați Microsoft SQL Server pentru performanță.

Modificări ale aplicației

Ce trebuie să faceți pentru a implementa corect Always Encrypted în codul moștenit?

Unul dintre lucrurile frumoase despre caracteristica Always Encrypted a SQL Server 2016 este că aplicațiile care folosesc deja proceduri stocate, ORM-uri sau comenzi T-SQL parametrizate nu ar trebui să necesite modificări ale aplicației pentru a utiliza Always Encrypted, cu excepția cazului în care sunt deja utilizate operațiuni fără egalitate. Aplicațiile care construiesc instrucțiuni SQL ca SQL dinamic în cadrul aplicației și execută acele comenzi direct în baza de date trebuie modificate pentru a utiliza parametrizarea interogărilor lor, o practică recomandată de securitate pentru toate aplicațiile, înainte de a putea profita de caracteristica Always Encrypted.

O altă modificare necesară pentru ca Always Encrypted să funcționeze este adăugarea unui atribut șir de conexiune la șirul de conexiune al aplicației care se conectează la baza de date: Column Encryption Setting=enabled .

Cu această setare adăugată la șirul de conexiune, driverul ADO.NET întreabă serverul SQL dacă comanda de execuție include coloane criptate și, dacă da, ce coloane sunt criptate. Pentru aplicațiile cu încărcare mare, este posibil ca utilizarea acestei setări să nu fie cea mai bună practică, mai ales dacă un procent mare de comenzi executate nu includ valori criptate.

În consecință, .NET Framework oferă o nouă metodă pe obiectul SqlConnection numită SqlCommandColumnEncryptionSetting , care are trei valori posibile:

• Disabled — Nu există coloane sau parametri Always Encrypted de utilizat pentru interogările care sunt executate prin utilizarea acestui obiect de conexiune.
• Enabled — Există coloane și/sau parametri întotdeauna criptați în uz pentru interogările care sunt executate prin utilizarea acestui obiect de conexiune.
• ResultSet — Nu există parametri Always Encrypted. Cu toate acestea, executarea de interogări folosind acest obiect de conexiune returnează coloane criptate folosind Always Encrypted.

Notă: Rețineți că utilizarea acestei metode poate necesita o cantitate semnificativă de modificare a codului aplicației dvs. O abordare alternativă este refactorizarea aplicației pentru a utiliza diferite conexiuni.

Pentru cea mai bună performanță a SQL Server, este înțelept să solicitați doar metadatele despre Always Encrypted pentru acele interogări care utilizează Always Encrypted. Aceasta înseamnă că în aplicațiile pentru care un procent mare de interogări utilizează Always Encrypted, șirul de conexiune ar trebui să fie activat, iar interogările specifice din cadrul aplicației ar trebui să specifice SqlCommandColumnEncryptionSetting ca Disabled . Pentru aplicațiile pentru care majoritatea interogărilor nu folosesc valori Always Encrypted, șirul de conexiune nu ar trebui să fie activat, iar SqlCommandColumnEncryptionSetting ar trebui să fie setat pentru Enabled sau ResultSet , după cum este necesar, pentru acele interogări care folosesc coloane Always Encrypted. În cele mai multe cazuri, aplicațiile sunt capabile să activeze pur și simplu atributul șir de conexiune, iar performanța aplicației va rămâne neschimbată în timpul utilizării datelor criptate.

Merită efortul Întotdeauna criptat?

Răspuns scurt? Da cu siguranta!

Nu numai că ajută la prevenirea o mulțime de potențiale probleme de securitate și oferă dezvoltatorilor SQL caracteristici de securitate suplimentare, dar vă face și sistemul mai compatibil, ceea ce este vital în mai multe industrii, de la telecomunicații la banca și asigurări. De asemenea, este important să rețineți că, având în vedere cerințele tehnice menționate în articol, Always Encrypted poate fi implementat cu modificări minime ale aplicației pentru sistemele existente .

Deși este posibil să utilizați soluții personalizate pentru a obține același efect, această tehnologie este livrată cu noua versiune de SQL Server și poate fi utilizată imediat. De asemenea, este important de reținut, deoarece aceasta este o tehnologie nouă, există încă unele limitări în ceea ce privește utilizarea ei și adaugă câteva demenad hardware suplimentare.

Cu toate acestea, cu excepția cazului în care acestea sunt un deal-breaker pentru mediul dvs. și aveți o aplicație care este distribuită în afara intranetului companiei dvs., practic nu există niciun motiv să nu utilizați Always Encrypted.