Transparent Data Encryption pozwala zaszyfrować dane bazy Microsoft SQL Server bezpośrednio na dysku, bez zmian w działaniu aplikacji.

Na czym polega ta usługa

Usługa obejmuje skonfigurowanie mechanizmu Transparent Data Encryption w Microsoft SQL Server oraz zarządzanie kluczami szyfrowania.

Dla kogo ma sens

Usługa jest przydatna dla firm korzystających z Microsoft SQL Server, którym zależy na dodatkowym zabezpieczeniu danych na dysku.

Ile to trwa

Konfiguracja szyfrowania mieści się z reguły w standardowym czasie do 3 dni.

Warunki

Diagnoza wstępna i wycena są bezpłatne, a usługa objęta jest gwarancją do 12 miesięcy.

Jak działa szyfrowanie na poziomie pliku bazy

Transparent Data Encryption szyfruje dane w momencie zapisu na dysk (tzw. szyfrowanie „at rest") oraz odszyfrowuje je przy odczycie do pamięci — proces zachodzi na poziomie silnika bazy danych, więc aplikacja korzystająca z bazy nie wymaga żadnych zmian w kodzie ani w zapytaniach. Szyfrowane są pliki danych (MDF), pliki dziennika transakcji (LDF) oraz kopie zapasowe wykonywane po włączeniu mechanizmu. Kluczem wyjściowym całej hierarchii jest klucz główny bazy master (Database Master Key), na którym opiera się certyfikat serwera, a ten z kolei chroni klucz szyfrowania bazy (Database Encryption Key, DEK) używany bezpośrednio do szyfrowania danych. Taka wielowarstwowa struktura pozwala oddzielić ochronę samych danych od ochrony klucza, który je odblokowuje.

Warianty wdrożenia

Konfiguracja TDE różni się w zależności od punktu wyjścia. W przypadku nowej bazy danych szyfrowanie włącza się od razu przy jej zakładaniu, co eliminuje potrzebę późniejszej konwersji istniejących plików. Przy bazie już działającej proces przebiega inaczej — silnik musi przekonwertować wszystkie istniejące dane, co przy dużych bazach obciąża serwer i wydłuża czas wdrożenia. Osobnym wariantem jest migracja bazy zaszyfrowanej między serwerami — wymaga ona przeniesienia nie tylko plików bazy, ale również certyfikatu i klucza prywatnego, bez których docelowy serwer nie odczyta zaszyfrowanych danych. Możliwe jest też szyfrowanie wybranych baz na instancji, podczas gdy pozostałe pozostają nieszyfrowane — TDE działa niezależnie dla każdej bazy danych, nie dla całej instancji serwera naraz.

Błędy przy samodzielnej konfiguracji

Najczęstszym błędem jest włączenie szyfrowania bez wcześniejszego wykonania kopii zapasowej certyfikatu i klucza prywatnego. Jeśli te elementy nie zostaną zabezpieczone poza serwerem, a sam serwer ulegnie awarii, odzyskanie zaszyfrowanych danych z kopii zapasowej bazy staje się niemożliwe — kopia bazy bez pasującego certyfikatu jest bezużyteczna. Kolejny częsty problem to brak testowego odtworzenia bazy po wdrożeniu szyfrowania — administratorzy zakładają, że skoro baza działa, to backup też się odtworzy, a weryfikują to dopiero w sytuacji awaryjnej, gdy jest już za późno na poprawki. Zdarza się również pomijanie wpływu na wydajność — szyfrowanie i deszyfrowanie w locie obciąża procesor, co przy bazach z intensywnym ruchem transakcyjnym bywa odczuwalne i wymaga wcześniejszego sprawdzenia na środowisku testowym. Innym powtarzającym się błędem jest przechowywanie hasła do klucza prywatnego w tym samym miejscu co kopia certyfikatu, co w praktyce niweluje sens rozdzielenia zabezpieczeń.

Kiedy Transparent Data Encryption nie jest właściwym rozwiązaniem

TDE chroni dane wyłącznie w spoczynku, czyli w plikach zapisanych na dysku. Nie zabezpiecza danych przesyłanych między serwerem a aplikacją — do tego służy szyfrowanie połączenia (np. protokół TLS), które trzeba skonfigurować osobno. Nie chroni też danych w pamięci operacyjnej serwera ani przed dostępem osoby, która ma już uprawnienia administratora bazy danych — użytkownik z odpowiednimi uprawnieniami odczyta dane w formie jawnej, ponieważ deszyfrowanie następuje automatycznie po stronie silnika. Jeśli celem jest ograniczenie dostępu do konkretnych kolumn (np. numerów kart płatniczych) nawet dla administratorów bazy, właściwym mechanizmem jest szyfrowanie na poziomie kolumny (Always Encrypted) lub szyfrowanie funkcjami wbudowanymi w zapytania, nie TDE. Z kolei ochrona całego dysku serwera, w tym plików spoza bazy danych, wymaga osobnego rozwiązania systemowego do szyfrowania dysku, a nie mechanizmu działającego wyłącznie w obrębie silnika SQL Server.

Dodatkowe pytania klientów

Czy włączenie szyfrowania spowolni działanie bazy danych?

Obciążenie procesora rośnie, ponieważ dane są szyfrowane i deszyfrowane w locie, jednak w większości przypadków przy typowym obciążeniu różnica jest niewielka. Skala wpływu zależy od intensywności operacji odczytu i zapisu oraz od wydajności sprzętu, dlatego przed wdrożeniem na produkcji zalecane jest sprawdzenie zachowania bazy na środowisku testowym o zbliżonej charakterystyce ruchu.

Czy trzeba szyfrować całą instancję SQL Server, czy tylko wybrane bazy?

Szyfrowanie działa na poziomie pojedynczej bazy danych, więc można objąć nim tylko te bazy, które faktycznie przechowują dane wymagające dodatkowej ochrony, pozostawiając inne bez zmian. Wyjątkiem są bazy systemowe powiązane z daną bazą — np. tempdb zostaje zaszyfrowana automatycznie, gdy choć jedna baza użytkownika na danej instancji ma włączone TDE.

Co się stanie z kopiami zapasowymi wykonanymi przed włączeniem szyfrowania?

Kopie zapasowe wykonane przed włączeniem TDE pozostają w formie, w jakiej zostały zapisane, czyli nieszyfrowanej. Dopiero kopie wykonane po aktywacji mechanizmu są automatycznie szyfrowane i do ich odtworzenia wymagany jest certyfikat użyty w momencie tworzenia backupu.

Czy da się wyłączyć TDE, jeśli okaże się niepotrzebne?

Tak, mechanizm można wyłączyć, co uruchamia proces odwrotny — deszyfrowanie wszystkich danych bazy. Podobnie jak przy włączaniu, proces obciąża serwer proporcjonalnie do rozmiaru bazy i najlepiej planować go poza godzinami największego ruchu.

Czy certyfikat i klucz trzeba przechowywać w kilku miejscach?

Tak, to zalecana praktyka. Kopia certyfikatu i klucza prywatnego powinna być przechowywana poza serwerem, na którym działa baza — inaczej awaria dysku lub całego serwera oznacza utratę możliwości odtworzenia zaszyfrowanych danych z jakiejkolwiek kopii zapasowej.

Zarządzanie kluczami po wdrożeniu

Konfiguracja TDE nie kończy się na jednorazowym włączeniu szyfrowania. Certyfikat serwera ma zwykle określony termin ważności i wymaga odnowienia, zanim wygaśnie — jego wygaśnięcie nie przerywa działania bazy, ale komplikuje odtwarzanie starszych kopii zapasowych wykonanych przy jego użyciu. Dobra praktyka zakłada również okresową rotację klucza szyfrowania bazy, co ogranicza skutki potencjalnego wycieku klucza w przeszłości. Każda taka operacja — odnowienie certyfikatu, rotacja klucza, migracja na inny serwer — wymaga zachowania spójności między wszystkimi kopiami zapasowymi a odpowiadającymi im wersjami certyfikatu, dlatego prowadzona jest z dokumentowaniem, która kopia wymaga którego certyfikatu do odtworzenia.

Wdrożenie i utrzymanie Transparent Data Encryption to w praktyce nie tylko jednorazowa konfiguracja, ale też ustalenie procedury tworzenia i przechowywania kopii certyfikatów oraz kluczy, testowania odtwarzania danych i reagowania na zbliżający się termin wygaśnięcia certyfikatu — bez tego szyfrowanie bazy danych bywa źródłem problemów większych niż te, przed którymi miało chronić.

TDE a grupy dostępności i replikacja

W środowiskach korzystających z grup dostępności (Always On Availability Groups) lub z replikacji baz danych szyfrowanie wymaga dodatkowej uwagi. Certyfikat i klucz prywatny użyty do zaszyfrowania bazy na serwerze podstawowym muszą zostać zainstalowane również na każdym serwerze pełniącym rolę repliki — inaczej dołączenie bazy do grupy dostępności lub uruchomienie replikacji zakończy się błędem, ponieważ replika nie będzie w stanie odczytać przesyłanych danych. W praktyce oznacza to, że przy każdej zmianie certyfikatu (np. jego odnowieniu) konieczna jest synchronizacja tej zmiany na wszystkich serwerach uczestniczących w danej konfiguracji, nie tylko na serwerze głównym. Pominięcie tego kroku bywa źródłem sytuacji, w której replika przestaje synchronizować dane bez oczywistej przyczyny widocznej na pierwszy rzut oka w logach.

Wpływ na archiwizację długoterminową

Kopie zapasowe zaszyfrowanej bazy danych, przechowywane przez dłuższy czas — np. w ramach archiwizacji rocznej czy wymogów zgodności — pozostają zależne od certyfikatu użytego w chwili ich wykonania. Jeśli w międzyczasie certyfikat zostanie odnowiony lub klucz szyfrowania bazy poddany rotacji, starsze kopie nadal wymagają oryginalnej wersji certyfikatu do odtworzenia, a nie tej aktualnie używanej przez serwer. Dlatego przy długoterminowym przechowywaniu kopii zapasowych praktykowane jest archiwizowanie razem z danymi także odpowiadającej im wersji certyfikatu i klucza prywatnego, z opisem, do której kopii dany certyfikat się odnosi. Bez takiego powiązania odtworzenie archiwalnej kopii sprzed kilku lat może okazać się niemożliwe, mimo że sam plik kopii zapasowej jest technicznie sprawny.

Podsumowanie wdrożenia

Transparent Data Encryption bywa traktowane jako jednorazowa checklista do odhaczenia, tymczasem w praktyce jest to element, który trzeba uwzględnić w całym cyklu życia bazy danych — od pierwszego wdrożenia, przez rutynowe kopie zapasowe i testy ich odtwarzania, po migracje między serwerami i odnawianie certyfikatów. Konfiguracja tego mechanizmu na Microsoft SQL Server obejmuje więc nie tylko samo włączenie szyfrowania, ale też uporządkowanie procedur wokół kluczy i certyfikatów, tak aby zaszyfrowane dane pozostawały odzyskiwalne w każdej sytuacji, w której odtworzenie kopii okaże się potrzebne.

22 378 48 09

Microsoft SQL Server — konfiguracja Transparent Data Encryption (TDE)