Firma Microsoft oferuje szereg funkcji zabezpieczeń w programie SQL Server 2017, które są przydatne do różnych celów, w zależności od tego, co próbujesz chronić i przed jakimi zagrożeniami próbujesz chronić. Niektóre z tych funkcji bezpieczeństwa mogą mieć wpływ na wydajność, o których powinieneś wiedzieć, decydując, które z nich chcesz wdrożyć. Na wstępie omówię niektóre najważniejsze cechy kilku z tych funkcji bezpieczeństwa.
Przejrzyste szyfrowanie bazy danych (TDE)
Przezroczyste szyfrowanie danych (TDE) to forma szyfrowania SQL Server w stanie spoczynku, co oznacza, że pliki danych, plik dziennika, pliki tempdb oraz pełne, różnicowe i kopie zapasowe dziennika SQL Server będą szyfrowane po włączeniu TDE w bazie danych użytkownika . Chroni to Twoje dane przed uzyskaniem dostępu do tych baz danych lub plików kopii zapasowych bazy danych, o ile ta osoba nie ma również dostępu do Twoich certyfikatów i kluczy szyfrowania.
Początkowe skanowanie szyfrowania TDE dla bazy danych użytkownika użyje jednego wątku procesora w tle na plik danych w bazie danych (jeśli pliki danych znajdują się na oddzielnych dyskach logicznych), aby powoli wczytać całą zawartość pliku danych do pamięci z szybkością około 52 MB/s na plik danych (jeśli pliki danych znajdują się na osobnych dyskach logicznych).
Dane są następnie szyfrowane za pomocą wybranego algorytmu szyfrowania, a następnie zapisywane z powrotem do pliku danych z szybkością około 55 MB/s (na plik danych, jeśli znajdują się na osobnych dyskach logicznych). Te sekwencyjne szybkości odczytu i zapisu wydają się być celowo ograniczane i są spójne w moich testach na wielu systemach z różnymi rodzajami pamięci masowej.
Początkowy proces szyfrowania TDE odbywa się na poziomie strony, pod SQL Server, więc nie powoduje blokowania ani generowania aktywności dziennika transakcji, jak w przypadku przebudowy indeksu. Możesz wstrzymać skanowanie szyfrowania TDE, włączając globalny TF 5004, i cofnąć je, wyłączając TF 5004 i ponownie uruchamiając polecenie ALTER DATABASE dbNAME SET ENCRYTION ON, bez utraty postępu.
Wpływ szyfrowania/odszyfrowywania na procesor jest znacznie zmniejszony w SQL Server 2016 i nowszych, jeśli masz procesor obsługujący instrukcje sprzętowe AES-NI. W obszarze serwerów zostały one wprowadzone w rodzinie produktów Intel Xeon 5600 (Westmere-EP) dla serwerów dwuprocesorowych oraz w rodzinie produktów Intel Xeon E7-4800/8800 (Westmere-EX) dla serwerów cztero- i ośmioprocesorowych. Każda nowsza rodzina produktów Intel będzie również obsługiwać AES-NI. Jeśli masz wątpliwości, czy twój procesor obsługuje AES-NI, możesz poszukać „AES” w polu instrukcji wyjściowych z CPU-Z, jak widać na rysunku 1.
Rysunek 1:Wyjście CPU-Z z obsługą instrukcji AES
Po zaszyfrowaniu bazy danych za pomocą TDE trudno jest przewidzieć wpływ TDE na środowisko wykonawcze, ponieważ jest on całkowicie zależny od obciążenia. Jeśli na przykład twoje obciążenie mieści się w całości w puli buforów programu SQL Server, wtedy TDE będzie praktycznie zerowe. Z drugiej strony, jeśli twoje obciążenie składało się wyłącznie ze skanowania tabel, w których strona jest czytana, a następnie prawie natychmiast opróżniana, nałożyłoby to maksymalną karę. Maksymalna kara za niestabilne obciążenie we/wy jest zwykle mniejsza niż 5% w przypadku nowoczesnego sprzętu i SQL Server 2016 lub nowszego.
Dodatkowa praca związana z odszyfrowywaniem TDE ma miejsce, gdy odczytujesz dane do puli buforów z pamięci masowej, a dodatkowa praca związana z szyfrowaniem TDE ma miejsce, gdy zapisujesz dane z powrotem do pamięci masowej. Upewnienie się, że nie jesteś pod presją pamięci, posiadanie wystarczająco dużej puli buforów oraz dostrajanie indeksów i zapytań oczywiście zmniejszy wpływ TDE na wydajność. TDE nie szyfruje danych FILESTREAM, a zaszyfrowana baza danych TDE nie użyje natychmiastowej inicjalizacji plików dla swoich plików danych.
Przed SQL Server 2016, TDE i natywna kompresja kopii zapasowych nie działały dobrze razem. W przypadku programu SQL Server 2016 i nowszych można jednocześnie używać kompresji TDE i natywnej kopii zapasowej, o ile w poleceniu kopii zapasowej określisz wartość MAXTRANSFERSIZE większą niż 64 KB. Bardzo ważne jest również, aby być na bieżąco z aktualizacjami zbiorczymi, ponieważ pojawiło się wiele ważnych poprawek związanych z TDE zarówno dla SQL Server 2016, jak i SQL Server 2017. Wreszcie, TDE jest nadal funkcją tylko w wersji Enterprise, nawet po SQL Server 2016 SP1 (który dodał wiele funkcji tylko dla przedsiębiorstw do wersji standardowej).
Zabezpieczenia na poziomie wiersza (RLS)
Zabezpieczenia na poziomie wiersza (RLS) ograniczają dostęp do odczytu i dostęp do większości na poziomie zapisu na podstawie atrybutów użytkownika. RLS wykorzystuje tak zwaną kontrolę dostępu opartą na predykatach. SQL Server stosuje ograniczenia dostępu w warstwie bazy danych i będą stosowane przy każdej próbie dostępu do danych z dowolnej warstwy.
RLS działa, tworząc funkcję predykatu, która ogranicza wiersze, do których użytkownik może uzyskać dostęp, a następnie używa zasad bezpieczeństwa i predykatu bezpieczeństwa do zastosowania tej funkcji do tabeli.
Istnieją dwa typy predykatów zabezpieczeń, które są predykatami filtrów i predykatami blokowymi. Predykaty filtrowania dyskretnie filtrują wiersze dostępne do operacji odczytu (SELECT, UPDATE i DELETE), zasadniczo dodając klauzulę WHERE, która zapobiega wyświetlaniu przefiltrowanych wierszy w zestawie wyników. Predykaty filtrowania są stosowane podczas odczytywania danych z tabeli podstawowej, a użytkownik lub aplikacja nie będzie wiedziała, że wiersze są filtrowane z wyników. Z punktu widzenia wydajności ważne jest, aby mieć indeks sklepu wierszy, który obejmuje predykat filtra RLS.
Predykaty blokowe jawnie (z komunikatem o błędzie) operacji zapisu bloku (PO WSTAWIENIU, PO UPDATE, PRZED UPDATE i PRZED USUNIĘCIEM), które naruszyłyby predykat blokowy.
Predykaty filtrów i bloków są tworzone jako wbudowane funkcje z wartościami przechowywanymi w tabeli. Będziesz także musiał użyć instrukcji T-SQL CREATE SECURITY POLICY, aby zastosować i włączyć funkcję filtrowania do odpowiedniej tabeli bazowej
RLS został dodany w SQL Server 2016 i jest dostępny we wszystkich wersjach SQL Server 2016 i nowszych. RLS nie będzie działać z widokami Filestream, Polybase i indeksowanymi. RLS może pogorszyć wydajność wyszukiwania pełnotekstowego i może wymusić, aby zapytania indeksów magazynu kolumn kończyły się używaniem trybu wiersza zamiast trybu wsadowego. Ten wpis w blogu firmy Microsoft zawiera więcej informacji na temat wpływu RLS na wydajność. Dobry przykład wykorzystania Query Store do dostrojenia wydajności RLS znajduje się tutaj.
Maskowanie danych dynamicznych (DDM)
Dynamiczne maskowanie danych (DDM) może pomóc w ograniczeniu narażenia na wrażliwe dane, maskując je dla nieuprzywilejowanych użytkowników. DDM jest stosowane na poziomie tabeli, więc maskowanie danych ma wpływ na wszystkie zapytania, podczas gdy rzeczywiste reguły maskowania są stosowane w poszczególnych kolumnach tabeli.
Istnieją cztery typy masek danych, których można użyć, w tym domyślny, e-mail, niestandardowy ciąg i losowy. Maska domyślna zapewnia pełne domyślne maskowanie danych w zależności od typu danych. Na przykład typ danych ciągu otrzyma maskę „XXXX” zamiast rzeczywistych danych. Maska e-mail zwróci pierwszą literę rzeczywistego adresu e-mail, a następnie [email protected], niezależnie od rzeczywistego sufiksu domeny. Niestandardowa maska ciągu pokaże pierwszą i ostatnią literę ciągu, z niestandardowym wypełnieniem pośrodku. Wreszcie maska losowa służy do maskowania danych liczbowych i dostarczania losowej wartości w określonym zakresie. Maski danych można tworzyć za pomocą instrukcji CREATE TABLE lub instrukcji ALTER COLUMN.
Dynamiczne maskowanie danych nie zapewnia maskowania uprzywilejowanym użytkownikom, którzy nadal mogą bezpośrednio wysyłać zapytania do tabel i wyświetlać niemaskowane dane. Reguł maskowania nie można używać z kolumnami zaszyfrowanymi (zawsze szyfrowane), kolumnami obliczanymi ani z danymi Filestream. Jeśli istnieją indeksy w kolumnie, którą chcesz zamaskować, będziesz musiał usunąć indeks, utworzyć maskę w kolumnie, a następnie ponownie utworzyć indeks. Możliwe jest również wywnioskowanie wartości dla zamaskowanych kolumn danych, pisząc zapytania, które pozwalają użytkownikowi ostatecznie odgadnąć wartość zamaskowanej kolumny.
Dynamiczne maskowanie danych zostało wprowadzone w SQL Server 2016 i jest dostępne we wszystkich wersjach SQL Server. DDM nie ma być silnym środkiem bezpieczeństwa, takim jak rzeczywiste szyfrowanie, ale z drugiej strony jego wpływ na wydajność wydaje się być dość znikomy.
