Asymmetric Key

Asymmetric Key to typ obiektu SQL Server wykorzystujący parę kluczy kryptograficznych do szyfrowania i podpisywania danych.

Para kluczy RSA w SQL Server

Asymmetric Key w Microsoft SQL Server jest obiektem kryptograficznym przechowywanym w konkretnej bazie danych. Reprezentuje parę kluczy: publiczny i prywatny. Klucz publiczny może służyć do szyfrowania danych albo weryfikowania podpisu, natomiast klucz prywatny jest potrzebny do odszyfrowania danych lub utworzenia podpisu cyfrowego. Rozdzielenie tych funkcji odróżnia kryptografię asymetryczną od kluczy symetrycznych, w których ten sam sekret jest używany do szyfrowania i odszyfrowania.

W SQL Server obiekty tego typu są oparte na algorytmie RSA. Klucz można utworzyć poleceniem CREATE ASYMMETRIC KEY, wskazując między innymi nazwę obiektu, algorytm oraz sposób ochrony klucza prywatnego. Dostępne warianty RSA obejmują rozmiary 512, 1024, 2048, 3072 i 4096 bitów, zależnie od wersji i konfiguracji używanego SQL Server. Przy nowych wdrożeniach należy uwzględnić wymagania bezpieczeństwa oraz kompatybilność aplikacji, ponieważ większy klucz zwiększa koszt operacji kryptograficznych.

Utworzenie i ochrona obiektu

Najczęściej klucz asymetryczny tworzy się w bazie danych za pomocą instrukcji podobnej do CREATE ASYMMETRIC KEY KluczAplikacji WITH ALGORITHM = RSA_2048 ENCRYPTION BY PASSWORD = '...'. Nazwa obiektu musi być unikatowa w zakresie bazy. Hasło użyte przy tworzeniu chroni klucz prywatny, a SQL Server przechowuje jego zaszyfrowaną postać. W praktycznej konfiguracji hasło nie powinno być wpisywane bezpośrednio do skryptów przechowywanych w repozytorium ani do logów wykonywania poleceń.

SQL Server może również chronić klucz prywatny przy użyciu Database Master Key, czyli głównego klucza bazy danych. Database Master Key jest z kolei zabezpieczany przez Service Master Key instancji albo przez hasło określone podczas tworzenia. Taki łańcuch ochrony ma znaczenie operacyjne: kopia zapasowa bazy powinna być traktowana razem z informacjami koniecznymi do odtworzenia kluczy, a przeniesienie samej definicji obiektu do innej bazy nie przenosi użytecznej pary kryptograficznej. Utrata klucza prywatnego może uniemożliwić odszyfrowanie wcześniej zabezpieczonych danych.

Szyfrowanie, podpisy i ograniczenia operacyjne

Do szyfrowania danych kluczem asymetrycznym służy funkcja EncryptByAsymKey, a do odszyfrowania funkcja DecryptByAsymKey. Podpis można utworzyć za pomocą SignByAsymKey i sprawdzić przez VerifySignedByAsymKey. Funkcje te przyjmują identyfikator klucza uzyskiwany między innymi przez AsymKey_ID. Klucz publiczny może być używany do weryfikacji podpisu bez ujawniania klucza prywatnego, ale operacja podpisywania wymaga dostępu do części prywatnej.

Kryptografia asymetryczna nie jest zwykle przeznaczona do szyfrowania dużych kolumn lub całych plików bezpośrednio. Rozmiar danych możliwych do zaszyfrowania zależy od rozmiaru klucza RSA i zastosowanego dopełnienia, dlatego przekroczenie limitu może zakończyć operację błędem albo wymagać podziału danych. W rozwiązaniach bazodanowych często stosuje się podejście hybrydowe: dane są szyfrowane kluczem symetrycznym, a sam klucz symetryczny jest zabezpieczany kluczem asymetrycznym. Asymmetric Key może też służyć do podpisywania modułów, procedur lub innych elementów kodu bazy, gdy wymagane jest potwierdzenie ich pochodzenia i integralności.

Uprawnienia i kontrola poprawności w SQL Server

Sam fakt istnienia obiektu Asymmetric Key nie oznacza, że każdy użytkownik bazy może wykonać operację z jego użyciem. Dostęp kontrolują uprawnienia do obiektu oraz uprawnienia związane z użyciem klucza prywatnego. Podczas analizy problemu należy sprawdzić, czy procedura wykonuje się w odpowiednim kontekście bezpieczeństwa, czy klucz znajduje się w tej samej bazie oraz czy Database Master Key może zostać automatycznie otwarty. Warto również potwierdzić zgodność identyfikatora klucza, nazwy obiektu i algorytmu z konfiguracją aplikacji.

Diagnostyka powinna obejmować odczyt metadanych z widoków katalogowych, sprawdzenie istnienia klucza, test kontrolnego szyfrowania i odszyfrowania oraz weryfikację podpisu na danych testowych. Należy odróżnić błąd uprawnień od błędu wynikającego z braku lub uszkodzenia Database Master Key, niezgodnego hasła, przeniesienia bazy bez kluczy albo próby zaszyfrowania zbyt dużej wartości. Przy pracy z SQL Server trzeba także zachować ostrożność podczas zmian nazw, odtwarzania kopii i migracji, ponieważ zgodność nazwy obiektu nie gwarantuje zachowania tego samego klucza prywatnego.