Objaśnienie szyfrowania SQL Server: TDE, szyfrowanie na poziomie kolumn i inne
Ochrona danych ma kluczowe znaczenie dla zapewnienia zgodności organizacji ze standardami zgodności regulacyjnej, takimi jak RODO, oraz dla spełnienia oczekiwań klientów i partnerów biznesowych. Naruszenie danych może nie tylko skutkować wysokimi grzywnami, ale także równie dużymi szkodami dla reputacji. Aby pomóc, Microsoft SQL Server obsługuje 5 różnych rodzajów szyfrowania do ochrony danych. W tym artykule wyjaśniono każdy z nich i gdzie powinny być używane.
szyfrowanie transportu SSL
podobnie jak strony internetowe, które zabezpieczają ruch między przeglądarką a serwerem, SQL Server może być skonfigurowany tak, aby używać Secure Sockets Layer (SSL) do szyfrowania ruchu podczas podróży między instancją serwera a aplikacją kliencką. Dodatkowo klient może zweryfikować tożsamość serwera za pomocą certyfikatu serwera. Protokół SSL chroni dane tylko podczas podróży przez sieć, ale w przeciwieństwie do większości innych form szyfrowania SQL Server, protokół SSL jest dostępny we wszystkich obsługiwanych wersjach serwera SQL i we wszystkich edycjach.
przed włączeniem SSL musisz zainstalować certyfikat na serwerze SQL. Najlepszym sposobem, aby to zrobić, jest zażądanie certyfikatu od własnego urzędu certyfikacji przedsiębiorstwa (CA). System Windows Server można skonfigurować jako urząd certyfikacji i skonfigurować klientów tak, aby ufali wystawianym certyfikatom. Alternatywnie, możliwe jest użycie certyfikatów z podpisem własnym, chociaż najlepiej nadaje się to do środowisk testowych.
SQL Server Transparent Data Encryption (TDE)
Transparent Data Encryption (TDE) w SQL Server chroni dane w spoczynku poprzez szyfrowanie danych bazy danych i plików dziennika na dysku. Działa przejrzyście dla istniejących aplikacji klienckich, więc nie trzeba ich zmieniać po włączeniu TDE. TDE wykorzystuje szyfrowanie w czasie rzeczywistym na poziomie strony. Strony są szyfrowane przed zapisaniem na dysk, bez zwiększania rozmiaru danych i plików dziennika, a strony są deszyfrowane po wczytaniu do pamięci. TDE jest dostępne tylko w korporacyjnych wersjach SQL Server. Działa również dla usługi Azure SQL Database, Azure SQL Data Warehouse i Parallel Data Warehouse.
szyfrowanie TDE ma strukturę hierarchiczną, z Windows Data Protection API (DPAPI) znajduje się na szczycie hierarchii i jest używane do szyfrowania service master key (SMK). Możesz użyć SMK do szyfrowania poświadczeń, połączonych haseł serwera i kluczy głównych bazy danych (DMK) znajdujących się w różnych bazach danych. SQL DMK to klucz symetryczny, który chroni prywatne klucze certyfikatów i klucze asymetryczne przechowywane w bazach danych.
SQL Server może generować samodzielnie podpisane certyfikaty do użytku z TDE lub możesz zażądać certyfikatu z urzędu certyfikacji (co jest bardziej powszechnym podejściem). Jeśli zdecydujesz się włączyć TDE, musisz wykonać kopię zapasową certyfikatu i klucza prywatnego powiązanego z certyfikatem. Będziesz musiał przywrócić lub dołączyć bazę danych na innym serwerze SQL. Jeśli włączysz TDE na dowolnej innej bazie danych SQL Server, systemowa baza danych tempdb również zostanie zaszyfrowana. Jeśli wyłączysz TDE, powinieneś zachować certyfikat i klucz prywatny, ponieważ części dziennika transakcji mogą pozostać szyfrowane do czasu wykonania pełnej kopii zapasowej.
TDE wymaga również klucza szyfrowania bazy danych (dek), który jest albo kluczem symetrycznym chronionym za pomocą certyfikatu przechowywanego w głównej bazie danych, albo kluczem asymetrycznym chronionym przez usługę wykorzystującą rozszerzalne zarządzanie kluczami (EKM), taką jak Microsoft Azure Key Vault. Pliki kopii zapasowych baz danych z obsługą TDE są szyfrowane za pomocą DEK, więc podczas operacji przywracania certyfikat chroniący DEK musi być dostępny.
klucze symetryczne używają tego samego hasła do szyfrowania i deszyfrowania danych. Klucze asymetryczne używają jednego hasła do szyfrowania danych (klucz publiczny) i innego hasła do deszyfrowania danych (klucz prywatny). Do tworzenia certyfikatów można użyć polecenia Utwórz certyfikat,a do tworzenia kluczy szyfrowania baz danych poleceń Utwórz klucz symetryczny i Utwórz klucz asymetryczny Transact-SQL.
szyfrowanie kopii zapasowych
szyfrowanie kopii zapasowych działa jak TDE, ale szyfruje kopie zapasowe SQL zamiast aktywnych danych i plików dziennika. Szyfrowanie kopii zapasowych jest dostępne w SQL Server 2014 i nowszych. Możesz określić szyfrowanie AES 128, AES 192, AES 256 lub potrójne DES i użyć certyfikatu lub klucza asymetrycznego przechowywanego w EKM. Dodatkowo możliwe jest jednoczesne włączenie szyfrowania TDE i kopii zapasowych, chociaż należy używać różnych certyfikatów lub kluczy.
podobnie jak w przypadku TDE, jeśli włączysz szyfrowanie kopii zapasowej, musisz również wykonać kopię zapasową certyfikatu lub klucza. Bez klucza lub certyfikatu plik kopii zapasowej nie może być użyty do przywrócenia danych. Kopie zapasowe mogą być również szyfrowane przy użyciu SQL Server Managed Backup to Microsoft Azure.
warto zauważyć, że jeśli używasz certyfikatu do szyfrowania kopii zapasowych, musisz mieć oryginalny certyfikat podczas przywracania danych. Oznacza to, że certyfikat musi mieć taki sam odcisk kciuka jak podczas tworzenia kopii zapasowej. Odnowienie certyfikatów lub zmiana ich w jakikolwiek sposób może spowodować zmianę odcisku kciuka.
szyfrowanie na poziomie kolumn/komórek
dostępne we wszystkich wersjach serwera SQL, szyfrowanie na poziomie komórek może być włączone w kolumnach zawierających poufne dane. Dane są szyfrowane na dysku i pozostają szyfrowane w pamięci, dopóki nie zostanie użyta funkcja DECRYPTBYKEY do ich odszyfrowania. Dlatego, chociaż dane SQL są szyfrowane, nie są bezpieczne poza zwykłym użyciem funkcji w kontekście użytkownika do ich odszyfrowania. Dodatkowo, ponieważ do odszyfrowania danych potrzebna jest funkcja, aplikacje klienckie muszą być zmodyfikowane tak, aby działały z szyfrowaniem na poziomie komórki.
zarządzanie kluczami szyfrowania
podobnie jak w przypadku TDE, przed użyciem szyfrowania na poziomie komórki należy utworzyć klucz główny (DMK). Istnieją cztery opcje szyfrowania informacji za pomocą szyfrowania na poziomie komórki:
- możesz użyć hasła do szyfrowania i odszyfrowania danych, ale musisz zaszyfrować procedury i funkcje przechowywane; w przeciwnym razie hasło można uzyskać w metadanych.
- asymetryczne klawisze zapewniają silne bezpieczeństwo, ale mogą mieć wpływ na wydajność.
- Klucze symetryczne są zwykle wystarczająco mocne i zapewniają dobrą równowagę między bezpieczeństwem a wydajnością.Certyfikaty
- zapewniają również dobrą równowagę między bezpieczeństwem a wydajnością i mogą być powiązane z użytkownikiem bazy danych.
zawsze zaszyfrowane
zawsze zaszyfrowane szyfruje poufne dane w aplikacjach klienckich bez ujawniania kluczy szyfrujących do silnika bazy danych, zapewniając oddzielenie właścicieli danych od menedżerów danych. Na przykład przy włączonej opcji zawsze szyfrowane możesz mieć pewność, że administratorzy bazy danych nie będą w stanie odczytać poufnych danych. Jak sama nazwa wskazuje, dane są szyfrowane w spoczynku i używane w systemie innych firm, takim jak Azure.
zawsze szyfrowane można skonfigurować dla poszczególnych kolumn bazy danych. Używane są dwa rodzaje kluczy: klucze szyfrowania kolumn i klucze główne kolumn. Klucze szyfrowania kolumn chronią dane w kolumnie, a klucze główne kolumny to „klucze chroniące klucze”, które szyfrują jeden lub więcej kluczy szyfrowania kolumn. Klucze główne kolumn są przechowywane w zewnętrznych zaufanych magazynach kluczy, takich jak usługa Azure Key Vault.
proces szyfrowania jest przezroczysty dla aplikacji klienckich, ale wymaga specjalnego sterownika na komputerach klienckich. Zawsze szyfrowane jest dostępne w SQL Server 2016 i nowszych, ale tylko w wersjach Enterprise. Ze względu na dodatkowe wymagania Po stronie klienta, zawsze szyfrowane najlepiej nadaje się do sytuacji, w których oddzielenie właścicieli danych i menedżerów jest podstawowym wymogiem.
