Cell Level Encryption – SQL Server Security

W pierwszym wpisie na temat zabezpieczeń i metody szyfrowania Cell Level Encryption napisałem „pozwala tylko na szyfrowanie określonych kolumn w bazie danych”. Jednak to stwierdzenie wymaga sprecyzowania. Metoda ta tak na prawdę pozwala na selektywne, granularne szyfrowanie. Po prostu na szyfrowania  poszczególnych wierszy w kolumnie za pomocą kluczy lub certyfikatów. Posługując się w tym celu dedykowanymi funkcjami. Technologia ta jest dość stara, Cell Level Encryption wprowadzono w SQL Server w wersji 2005 i nadal jest dostępne.

Praktyka czyni mistrza…

W przykładzie chcę zasymulować prostą sytuację.  Trzech użytkowników przy czym dwóch posługujących się odrębnymi kluczami do szyfrowania „swoich” danych. Coś takiego jak na schemacie.

No to zaczniemy od pustej bazy danych oraz dodania testowych użytkowników.

Następnie tworzymy podstawowe zestawy kluczy. Tematykę kluczy, certyfikatów szczegółowo poruszałem w wpisie Service Master Key, Database Master Key, certyfikaty, klucze czyli model szyfrowania w SQL Server do którego zapraszam.

Aby użytkownicy mogli posługiwać się wczesniej stworzynymi kluczami, muszą zostać im nadane odpowiednie GRANTy. Klucz SymmetricUserA  dla UserA, SymmetricUserB  dla UserB, natomias UserC nie posada uprawnień do żadnego z kluczy.

Kolejny krokiem jest zapewnienie odpowiedniego typy danych dla kolumn. Jest to wymóg tego Cell Level Encryption. Szyfrowane dane muszą być zapisywane do kolumny o typie danych binarnych – VARBINARY. Dla przykładu stworzona zostanie bardzo prosta tabelka.

Mamy wszystko, pozostaje nam szyfrować.

Funkcje dedykowane

Moment, moment. Przed przejściem dalej, chwilę trzeba poświęcić na prezentacje dedykowanych funkcji szyfrujących i deszyfrujących dane o których wspomniałem w wstępie.

Funkcje szyfrujące:

Funkcje deszyfrujące:

W przykładach  będę posiłkował się funkcjami ENCRYPTBYKEY oraz  DECRYPTBYKEY i wcześniej stworzonymi kluczami symetrycznymi, aby zapewnić wydajność szyfrowania jak i deszyfrowania.  Dlaczego tak a nie inaczej można przeczytać tutaj Klucz asymetryczny kontra klucz symetryczny?

Praktyka czyni mistrza, cd…

Szyfrowania lub/i deszyfrowania danych poprzedzamy poleceniem które służy do otwarcia i deszyfracji klucza symetrycznego.

Mając otwarty klucz można insertować dane do tabeli. Do szyfrowanie danych użyta została jedna z funkcji ENCRYPTBYKEY, który wymaga dwóch parametrów, ID naszego klucza symetrycznego oraz ciągu wartości, które uważamy za wrażliwe. Do tej samej tabeli, ten sam użytkownik możemy również wstawiać dane w postaci jawnej. Wiąże się z tym dodatkowy narzut kodu SQL. Dokładniej z konwersją danych do typu VARBINARY. Jak można zauważyć na tym polega selektywność tego rozwiązania, można szyfrować poszczególne wartości kolumny.

Analogicznie, odczyt danych wiąże się z odszyfrowanie za pomocą funkcji DECRYPTBYKEY a w przypadku danych jawnych z konwersją z typu binarnego VARBINARY.

Tak wyglądają przykładowe dane wstawione przez UserA.


Identyczne polecenia wykonane zostały przez użytkownika UserB.

UserB widzi tylko dane niewrażliwe wstawione przez UserA i oczywiście swoje. Klucz SymmetricUserB nie umożliwia deszyfracje i odwrotnie UserA nie będzie wstanie odszyfrować danych wrażliwych użytkownika UserB.

Trzeci użytkownik, UserC,  co oczywiste zobaczy tylko te dane, które nie podlegały szyfrowaniu przy wstawianiu do tabeli.

Wnioski

Zalety Cell Level Encryption:

  1. Granularna, specyficzna dla użytkownika kontrola nad szyfrowaniem poszczególnych wartości kolumny, a nie całej bazy danych (w porównaniu z użyciem Transparent Data Encryption – TDE, o tym będzie w kolejnym wpisie).
  2. Zachowane dane w pamięci, (w buffer cache) są zaszyfrowane (w przeciwienśtwiem do rozwiązania TDE). Deszyfracja następuje dopiero w momencie odpytania danych przez użytkownika. .

Wady Cell Level Encryption:

  1. Wymaga sporych zmian w aplikacji i analizy tabel w celu zlokalizowania poufnych danych, które należy zaszyfrować.
  2. Duża pracochłonność związana z zarządzaniem kluczami.
  3. Uniemożliwia indeksowanie danych i powoduje wpływ na wydajność, ponieważ indeksy na zaszyfrowanych kolumnach nie mogą być użyte podczas wyszukiwania wartości.
  4. Funkcje dedykowane do szyfrowania dla Cell Level Encryption zwracają tylko dane typu VARBINAR i dane wyjściowe są ograniczone do 8000 bajtów. Polecam ten link w tym temacie, https://blogs.msdn.microsoft.com/yukondoit/2005/11/23/sql-server-2005-encryption-encryption-and-data-length-limitations/

Z pasją poświęcam czas na zdobywanie wiedzy w zakresie szeroko rozumianej Data Platform. Zachwycony językiem skryptowym Windows PowerShell. Swoją wiedzę, doświadczenia i spostrzeżenia opisuję na blogu.

Leave a Reply

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *