Przejrzyste szyfrowanie danych i zawsze szyfrowane

Jeśli chcesz przechowywać poufne dane w swojej bazie danych, możesz użyć szyfrowania danych . SQL Server obsługuje szyfrowanie za pomocą kluczy symetrycznych, kluczy asymetrycznych, certyfikatów i fraz haseł. Zakładam, że Ty, Czytelniku, znasz już te terminy. W tym artykule skupię się na dwóch z wielu opcji szyfrowania oferowanych przez SQL Server:

• Przejrzyste szyfrowanie danych (TDE)
• Zawsze szyfrowane (AE)

Przejrzyste szyfrowanie danych

Przejrzyste szyfrowanie danych (TDE) chroni dane w spoczynku, gdy nie są używane. Gdy dane są używane, SQL Server odszyfrowuje je automatycznie. Możesz użyć TDE do szyfrowania i deszyfrowania danych i plików dziennika w czasie rzeczywistym. Szyfrujesz dane za pomocą klucza szyfrowania bazy danych (DEK) , który jest kluczem symetrycznym. Jest on przechowywany w rekordzie rozruchowym bazy danych i dlatego jest dostępny już podczas procesu odzyskiwania bazy danych. Chronisz DEK za pomocą certyfikatu w głównej bazie danych. Możesz również użyć klucza asymetrycznego zamiast certyfikatu; jednak klucz asymetryczny musi być przechowywany w module EKM. TDE używa tylko szyfrowania AES i Triple DES. TDE zostało po raz pierwszy zaimplementowane w SQL Server w wersji 2012.

TDE można używać tylko w bazach danych użytkowników. Nie można wyeksportować klucza szyfrowania bazy danych. Ten klucz jest używany tylko przez aparat bazy danych programu SQL Server. Użytkownicy końcowi nigdy go nie używają. Nawet jeśli zmienisz właściciela bazy danych, nie musisz ponownie generować DEK.

TDE szyfruje dane na poziomie strony. Dodatkowo szyfruje również dziennik transakcji. Należy wykonać kopię zapasową certyfikatu używanego do ochrony DEK i klucza prywatnego używanego do ochrony certyfikatu natychmiast po włączeniu TDE. Jeśli chcesz przywrócić lub dołączyć zaszyfrowaną bazę danych do innej instancji SQL Server, musisz przywrócić zarówno certyfikat, jak i klucz prywatny, w przeciwnym razie nie będziesz mógł otworzyć bazy danych. Zwróć uwagę, że nie eksportujesz DEK, ponieważ jest on częścią samej bazy danych. Musisz zachować i utrzymywać certyfikat używany do ochrony DEK nawet po wyłączeniu TDE w bazie danych. Dzieje się tak, ponieważ części dziennika transakcji mogą być nadal zaszyfrowane. Certyfikat jest potrzebny do czasu wykonania pełnej kopii zapasowej bazy danych.

Zawsze szyfrowane

SQL Server 2016 Enterprise Edition wprowadza nowy poziom szyfrowania, a mianowicie Always Encrypted (AE) funkcja. Ta funkcja zapewnia ten sam poziom ochrony danych, co szyfrowanie danych w aplikacji klienckiej. W rzeczywistości, chociaż jest to funkcja SQL Server, dane są szyfrowane i deszyfrowane po stronie klienta. Klucze szyfrowania nigdy nie są ujawniane aparatowi bazy danych programu SQL Server. W ten sposób administrator nie może zobaczyć wrażliwych danych bez kluczy szyfrowania, po prostu mając uprawnienia administratora na instancji SQL Server z zaszyfrowanymi danymi. W ten sposób AE oddziela administratorów zarządzających danymi od użytkowników będących ich właścicielami.

Klawisze AE

Potrzebujesz dwóch kluczy do Always Encrypted. Najpierw tworzysz klucz główny kolumny (CMK) . Następnie tworzysz klucz szyfrowania kolumny (CEK) i chroń go za pomocą CMK. Aplikacja używa CEK do szyfrowania danych. SQL Server przechowuje tylko zaszyfrowane dane i nie może ich odszyfrować. Jest to możliwe, ponieważ klucze główne kolumn nie są tak naprawdę przechowywane w bazie danych SQL Server. W bazie danych SQL Server przechowuje tylko łącze do tych kluczy. Klucze główne kolumn są przechowywane poza SQL Server, w jednym z następujących możliwych miejsc:

• Magazyn certyfikatów systemu Windows dla bieżącego użytkownika
• Magazyn certyfikatów systemu Windows dla komputera lokalnego
• Usługa Azure Key Vault
• Sprzętowy moduł bezpieczeństwa (HSM) , który obsługuje Microsoft CryptoAPI lub Cryptography API:Next Generation

Klucze szyfrowania kolumn są przechowywane w bazie danych. Wewnątrz bazy danych SQL Server przechowywana jest tylko zaszyfrowana część wartości kluczy szyfrowania kolumn, wraz z informacjami o lokalizacji kluczy głównych kolumn. CEK nigdy nie są przechowywane jako zwykły tekst w bazie danych. Jak wspomniano, CMK są faktycznie przechowywane w zewnętrznych zaufanych magazynach kluczy.

Korzystanie z klawiszy AE

Aplikacja może używać kluczy AE i szyfrowania przy użyciu sterownika obsługującego AE, takiego jak dostawca danych .NET Framework dla programu SQL Server w wersji 4.6 lub nowszej, sterownik Microsoft JDBC dla programu SQL Server 6.0 lub nowszego lub sterownik ODBC systemu Windows dla programu SQL Server w wersji 13.1 lub wyższy. Aplikacja musi wysyłać sparametryzowane zapytania do serwera SQL. Sterownik obsługujący AE współpracuje z aparatem bazy danych programu SQL Server w celu określenia, które parametry powinny być szyfrowane lub odszyfrowywane. Dla każdego parametru, który musi być zaszyfrowany lub odszyfrowany, sterownik uzyskuje metadane potrzebne do szyfrowania z aparatu bazy danych, w tym algorytm szyfrowania, lokalizację odpowiedniego CMK i zaszyfrowaną wartość odpowiedniej CEK. Następnie sterownik kontaktuje się ze sklepem CMK, pobiera CMK, odszyfrowuje CEK i używa CEK do zaszyfrowania lub odszyfrowania parametru. Następnie sterownik buforuje CEK, aby przyspieszyć następne użycie tego samego CEK. Poniższy rysunek przedstawia proces graficznie.

Rysunek przedstawia cały proces w krokach:

1. Aplikacja kliencka tworzy sparametryzowane zapytanie
2. Aplikacja kliencka wysyła sparametryzowane zapytanie do sterownika obsługującego AE
3. Sterownik z obsługą AE kontaktuje się z SQL Server, aby określić, które parametry wymagają szyfrowania lub odszyfrowania, lokalizację CMK i zaszyfrowaną wartość CEK
4. Sterownik obsługujący AE pobiera CMK i odszyfrowuje CEK
5. Sterownik z obsługą AE szyfruje parametr(y)
6. Sterownik wysyła zapytanie do silnika bazy danych
7. Silnik bazy danych pobiera dane i wysyła zestaw wyników do sterownika
8. Sterownik wykonuje odszyfrowanie, jeśli to konieczne, i wysyła zestaw wyników do aplikacji klienckiej

Typy szyfrowania AE

Aparat baz danych nigdy nie działa na danych zwykłego tekstu przechowywanych w zaszyfrowanych kolumnach. Jednak niektóre zapytania dotyczące zaszyfrowanych danych są możliwe, w zależności od typu szyfrowania. Istnieją dwa rodzaje szyfrowania:

• Szyfrowanie deterministyczne , który zawsze generuje tę samą zaszyfrowaną wartość dla tej samej wartości wejściowej. Za pomocą tego szyfrowania można indeksować zaszyfrowaną kolumnę i używać wyszukiwania punktów, sprzężeń równości i wyrażeń grupujących w zaszyfrowanej kolumnie. Jednak złośliwy użytkownik może spróbować odgadnąć wartości, analizując wzorce zaszyfrowanych wartości. Jest to szczególnie niebezpieczne, gdy zestaw możliwych wartości dla kolumny jest dyskretny, z niewielką liczbą odrębnych wartości.
• Szyfrowanie losowe , który szyfruje dane w nieprzewidywalny sposób.

Demo AE:tworzenie obiektów

Czas pokazać, jak działa AE, za pomocą kodu demonstracyjnego. Najpierw utwórzmy i używajmy demo bazy danych.

USE master;IF DB_ID(N'AEDemo') JEST NULL UTWÓRZ BAZĘ DANYCH AEDemo;GOUSE AEDemo;GO

Następnie utwórz CMK w SSMS GUI. W Eksploratorze obiektów odśwież folder Databases, aby wyświetlić bazę danych AEDemo. Rozwiń ten folder bazy danych, rozwiń podfolder Zabezpieczenia, następnie podfolder Zawsze szyfrowane klucze, kliknij prawym przyciskiem myszy podfolder Główny klucz kolumny i wybierz opcję Nowy główny klucz kolumny z wyskakującego menu. W polu tekstowym Nazwa wpisz AE_ColumnMasterKey i upewnij się, że wybrałeś opcję Magazyn certyfikatów systemu Windows — komputer lokalny na liście rozwijanej Magazyn kluczy, jak pokazano na poniższym rysunku.

Możesz sprawdzić, czy CMK został pomyślnie utworzony za pomocą następującego zapytania.

WYBIERZ * Z sys.column_master_keys;

Następnie tworzysz CEK. W SSMS, w Eksploratorze obiektów, kliknij prawym przyciskiem myszy podfolder Klucze szyfrowania kolumny pod podfolderem Klucz główny kolumny i wybierz opcję Nowy klucz szyfrowania kolumny z wyskakującego menu. Nazwij CEK AE_ColumnEncryptionKey i użyj AE_ColumnMasterKey CMK, aby go zaszyfrować. Możesz sprawdzić, czy tworzenie CEK powiodło się za pomocą następującego zapytania.

WYBIERZ * Z sys.column_encryption_keys;

Obecnie tylko nowe zestawienia binarne, zestawienia z BIN2 sufiksu, są obsługiwane dla AE. Dlatego stwórzmy tabelę z odpowiednimi sortowaniami dla kolumn znaków.

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, ALGORYTM ='AEAD_AES_256_CBC_HMAC_SHA_256') NULL);

Demo AE:wstawianie danych

Teraz możesz spróbować wstawić wiersz danych z następującą instrukcją.

WSTAW DO dbo.Table1 (id, SecretDeterministic, SecretRandomized)VALUES (1, N'DeterSec01', N'RandomSec1');

Pojawia się błąd 206, tekst błędu:„Operand typu kolizji:nvarchar jest niezgodny z nvarchar (4000) zaszyfrowanym za pomocą (encryption_type ='DETERMINISTIC', crypto_algorithm_name ='AEAD_AES_256_CBC_HMAC_SHA_256', column_encryption_AEcryption_Key_name_name ='kolumna) . SQL Server nie może szyfrować ani odszyfrowywać danych. Musisz zmodyfikować dane z aplikacji klienckiej. Możesz wykonać ograniczony zestaw operacji na tabeli z SQL Server. Na przykład możesz użyć instrukcji TRUNCATE TABLE w tabeli z kolumnami AE.

Stworzyłem bardzo prostą aplikację kliencką Windows Console w Visual C#. Aplikacja po prostu pobiera klucze i wstawia pojedynczy wiersz do tabeli utworzonej za pomocą powyższego kodu. Oto kod C#.

WYBIERZ *Z dbo.Table1;

WSTAW DO dbo.Table1 (id, SecretDeterministic, SecretRandomized)VALUES (2, N'DeterSec2', N'RandomSec2');

WYBIERZ * Z dbo.Table1;