Research SQL Server 2016CTP2 – 5/13

Bezpieczeństwo – kolejna część mojego badania nowości w SQL Server 2016CTP2 poświęcona jest właśnie badaniu nowości w zakresie bezpieczeństwa i to szeroko rozumianego.

Pojawiło się w tym zakresie kilka nowości. Część z nich była już od kilku miesięcy dostępna w wersji SQLAzure v12 o czym pisałem również tutaj na blogu.

Mamy do dyspozycji 3 nowe rozwiązania:

  • Row-Level Security
  • Dynamic Data Masking
  • Always Encrypted

Zanim przejdę do omówienia wspomnianych nowości należy wspomnieć o zmianach, które zaszły w TDE (Transparent Data Encryption). Pierwsza to wsparcie dla rozwiązań sprzętowych zastosowanych w procesorach Intel – AES-NI, co redukuje mniejszym obciążeniem procesora przy włączonym szyfrowaniu bazy danych TDE. Druga zmiana w TDE to wsparcie do In-Memory, w wersji SQL Server 2016 CTP2 jak włączymy TDE na bazie danych z obiektami In-Memory to In-Memory Log jest szyfrowany, dane MEMORY_OPTIMIZED_DATA w grupach plików nie są szyfrowane.

Pierwszą nowością jest Row-Level Security. Daje to możliwość budowania czegoś na wzór filtrów, tak by odpowiednie osoby widziały i mogły działać tylko na danych przefiltrowanych przez funkcję, którą utworzymy. Przykładu nie będę tutaj powtarzał, gdyż mógłby być identyczny jak test wykonany przez mnie na SQL Azure v12, dlatego chętnych odsyłam do tego wpisu – Row Level Security w SQL Azure v12

Druga nowość w serwerze SQL Server 2016CTP2 to Dynamic Data Masking, funkcjonalność, która również wcześniej pojawiła się w SQL Azure v12 i jest opisana w poście – Dynamic Data Masking w SQL Azure v12. Tutaj jednak inaczej trochę się to tworzy i korzysta, dlatego pokażę przykład.

Pierwszą rzeczą, którą musimy zrobić w wersji SQL Server 2016CTP2, aby korzystać z Dynamic Data Masking, to uruchomienie specjalnych traceflag.

Kolejnym krokiem jest utworzenie tabeli posiadające specjalne funkcje maskujące.

Dla kolumny FirstName ustawiliśmy funkcję, która na podstawie schematu będzie przysłaniać znaki, Phone# i Email korzystają z predefiniowanych masek default() i email().

Wstawmy teraz przykładowe dane i od razu zobaczmy zawartość, jako owner.

W wyniku tego otrzymujemy

Zróbmy teraz test Dynamic Data Masking. Tworzymy specjalnego użytkownika.

W wyniku otrzymujemy

Jak widzimy dane, które ustawiliśmy, jako maskowane są ukryte. Nie oznacza to, iż nie może użytkownik mający prawo do odczytu wydobyć ich, ale jest to wówczas świadome działanie, że chce mieć dane, które nie są maskowane.

W wyniku, czego otrzymamy

 

Jeżeli chcemy w ogóle usunąć dla danego użytkownika maskowania możemy nadać takie prawa, lub je odebrać

Można również całkowicie usunąć maskowanie z tabeli

Pamiętajmy, że mechanizm Dynamic Data Masking nie jest mechanizmem, który odbiera prawa dostępu do jakiś danych, czy też je szyfruje, tylko jak sama nazwa mówi maskuje nam dane, co w obecnych czasach ułatwia wiele scenariuszy, by dane nie były podsłuchane przez niepowołane osoby, czy też programy.

Ostatnia nowością uzupełniającą możliwości w zakresie bezpieczeństwa i szyfrowania SQL Server, jest nowa funkcjonalność Always Encrypted. Rozwiązanie to jest stworzone po to by dane poufne i wrażliwe jak np. numery kart kredytowych, przechowywać i przesyłać tylko i wyłącznie w postaci szyfrowanej. Wówczas to aplikacja kliencka dokonuje szyfrowania. Always Encrypted może używać dwa typy szyfrowania

  • Deterministyczną – typ taki zawsze w ten sam sposób dokonuje szyfrowania tej samej wartości tekstowej. Jest to typ słabszy ze względu bezpieczeństwa, ale umożliwia wykonywanie różnych innych operacji na podstawie danych zaszyfrowanych jak np.: połączenia, grupowania itp..
  • Losowy – najbardziej odporny typ na kryptoanalizę, za każdym razem ta sama wartość tekstowa po zaszyfrowaniu może mieć inną wartość, nie daje ten typ możliwości grupowań, indeksowania, wyszukiwani itp.

Ogólną idee Always Encrypted przedstawia poniższy rysunek (Źródło MSDN)”

 

W Object Explorer w zakładce SECURITY pojawiają się nowy folder Always Encrypted, gdzie możemy utworzyć odpowiednio COLUMN MASTER KEY DEFINITION, oraz COLUMN ENCRYPTION KEY.

Oczywiście, można to zrobić również przy użyciu poleceń TSQL

W powyższym przykładzie widzimy, że został zdefiniowany COLUMN MASTER KEY MyCMK, oraz klucz MyCEK korzystający z MyCMK, następnie została utworzona definicja tabeli, gdzie odpowiednie kolumny są szyfrowane przy użyciu tego klucza. Kolumna CustName ma ustawiony typ szyfrowania losowy, natomiast kolumna SSN ma ustawione szyfrowanie na deterministyczne.

Klient korzystający z AlwaysEncrypted musi też mieć włączone Always Encrypted w istniejącym połączeniu

Od strony developmentu po stronie klienta odsyłam do strony MSDN – Always Encrypted (client development)

Podsumowanie

Jak widzimy bardzo ciekawe nowe funkcjonalności pojawiły się w SQL Server 2016CTP2, część z nich była wcześniej dostępna już w tym roku w SQL Azure v12. Nowości w zakresie bezpieczeństwa czynią jeszcze bardziej SQL Server bezpieczny a zarazem elastyczny, jeśli chodzi o różne scenariusze dotyczące krytycznych, poufnych i wrażliwych danych przechowywanych i przetwarzanych na platformie SQL Server. Myślę, że warto poznać je bliżej. Tymczasem już niebawem kolejna część poświęcona nowością w SQL Server 2016CTP2 i ponownie wrócimy do bardzo lubianych przeze mnie rozwiązań In-Memory –zapraszam do śledzenia kolejnych części Research SQL Server 2016CTP2.

Share this article ...

Google Plus
Ihren LinkedIn Kontakten zeigen



Leave a Reply

Connect with:
  • This field its required.
  • This field its required.
    • Message is required