Zarządzanie kluczami szyfrującymi

Zarządzanie kluczami szyfrującymi w SQL Server obejmuje ich hierarchię, od klucza głównego usługi po klucze bazy.

Hierarchia kluczy w SQL Server

Zarządzanie kluczami szyfrującymi w Microsoft SQL Server opiera się na hierarchii, w której klucze wyższego poziomu służą do ochrony kluczy znajdujących się niżej. Na poziomie instancji znajduje się Service Master Key (SMK), czyli główny klucz usługi. Jest on tworzony automatycznie przy pierwszym uruchomieniu instancji SQL Server i chroniony przez mechanizmy systemu Windows. SMK zabezpiecza między innymi Database Master Keys przechowywane w bazach danych oraz dane uwierzytelniające używane przez funkcje instancji.

W każdej bazie danych może znajdować się Database Master Key (DMK). Ten klucz jest tworzony jawnie poleceniem CREATE MASTER KEY i służy do ochrony certyfikatów oraz kluczy asymetrycznych zapisanych w danej bazie. DMK jest chroniony hasłem podanym podczas tworzenia, a SQL Server może dodatkowo zaszyfrować jego kopię przy użyciu Service Master Key. Dzięki temu baza może automatycznie otwierać DMK w typowych operacjach, bez każdorazowego podawania hasła przez użytkownika.

Obiekty kryptograficzne dostępne w bazie

SQL Server udostępnia kilka rodzajów obiektów kryptograficznych. Certyfikat zawiera klucz publiczny, odpowiadający mu klucz prywatny oraz informacje pozwalające potwierdzić jego tożsamość. W bazie danych certyfikat może służyć do szyfrowania klucza symetrycznego, podpisywania modułów albo ochrony określonych danych. Klucz asymetryczny składa się z części publicznej i prywatnej, natomiast klucz symetryczny wykorzystuje ten sam sekret do szyfrowania i odszyfrowywania danych.

Klucz symetryczny można utworzyć między innymi poleceniem CREATE SYMMETRIC KEY, wskazując algorytm obsługiwany przez daną wersję SQL Server. Przed użyciem klucza w sesji trzeba go otworzyć poleceniem OPEN SYMMETRIC KEY, a po zakończeniu operacji można go zamknąć poleceniem CLOSE SYMMETRIC KEY. Dostęp do klucza jest kontrolowany przez uprawnienia, dlatego samo istnienie obiektu w bazie nie oznacza, że każdy użytkownik może wykorzystać go do odszyfrowania danych.

W praktyce warto oddzielać klucz używany do szyfrowania danych od mechanizmu, który chroni ten klucz. Takie podejście ogranicza zakres zmian przy rotacji i upraszcza kontrolę dostępu. W SQL Server certyfikat lub klucz asymetryczny może chronić klucz symetryczny, a Database Master Key chroni certyfikat albo klucz asymetryczny. Utrata odpowiedniego elementu nadrzędnego lub jego kopii zapasowej może uniemożliwić późniejsze odszyfrowanie danych.

Kopie zapasowe, rotacja i odzyskiwanie kluczy

Database Master Key należy zabezpieczyć niezależnie od kopii całej bazy. SQL Server pozwala wykonać jego kopię zapasową poleceniem BACKUP MASTER KEY, a następnie odtworzyć ją w razie potrzeby poleceniem RESTORE MASTER KEY. Podczas tworzenia kopii wymagane jest hasło, które chroni wyeksportowany klucz. Hasło to nie zastępuje samego klucza i powinno być przechowywane w sposób umożliwiający odzyskanie dostępu podczas awarii lub migracji.

Rotacja kluczy polega na okresowej wymianie klucza albo certyfikatu zgodnie z przyjętą polityką bezpieczeństwa, przy zachowaniu możliwości odczytu danych zaszyfrowanych wcześniejszym materiałem kryptograficznym. Samo usunięcie certyfikatu lub klucza bez sprawdzenia zależności może spowodować utratę dostępu do danych. Przed zmianą należy ustalić, które kolumny, procedury, funkcje, zadania i aplikacje korzystają z danego obiektu oraz czy istnieją aktualne kopie kluczy.

W środowiskach, w których materiał kryptograficzny jest przechowywany poza SQL Server, można użyć funkcji Extensible Key Management (EKM), jeżeli jest ona wspierana przez używaną konfigurację i dostawcę. W takim modelu SQL Server korzysta z zewnętrznego dostawcy kluczy, a sposób ich generowania, przechowywania, rotacji i odzyskiwania zależy również od tego dostawcy. Z tego powodu test odtworzenia powinien obejmować zarówno bazę danych, jak i dostęp do zewnętrznego magazynu kluczy.

Kontrola konfiguracji i diagnostyka dostępu

Diagnostyka problemów z kluczami w SQL Server powinna rozpocząć się od ustalenia, jaki obiekt wykonuje daną operację i na jakim poziomie hierarchii występuje błąd. Należy sprawdzić, czy Database Master Key istnieje, czy może zostać otwarty, czy certyfikat zawiera klucz prywatny oraz czy użytkownik ma wymagane uprawnienia do otwarcia i użycia klucza symetrycznego. Pomocne jest również sprawdzenie, czy aplikacja korzysta z właściwej bazy danych i właściwej nazwy obiektu kryptograficznego.

Objawem problemu może być błąd podczas odszyfrowywania danych po przeniesieniu bazy na inną instancję, odtworzeniu kopii zapasowej albo zmianie konta usługi. W takiej sytuacji trzeba zweryfikować relację między Database Master Key a Service Master Key nowej instancji. Automatyczne otwieranie DMK może wymagać ponownego dodania ochrony przez SMK, natomiast ręczne otwarcie DMK wymaga hasła użytego przy jego utworzeniu. Nie należy zastępować brakującego klucza nowym obiektem bez ustalenia, czy stare dane nadal muszą być odszyfrowywane.

Przy diagnostyce komputera, na którym działa narzędzie administracyjne lub aplikacja współpracująca z SQL Server, należy rozdzielić problem samej konfiguracji SQL Server od problemu systemu operacyjnego, sterownika, połączenia albo uprawnień konta. Sprawdzenie logów, ustawień połączenia, wersji używanego sterownika i poprawności certyfikatów pozwala określić, czy błąd powstaje przed dostępem do bazy, podczas otwierania klucza, czy dopiero przy operacji szyfrowania.