Jak zadbać o bezpieczeństwo danych? Przegląd dostępnych rozwiązania w SQL Server

Zapewnienie bezpieczeństwa danych w porównaniu do tematyki wydajności to temat mniej popularny. Jednak obserwując chociażby ilość czyhających zagrożeń i globalnych ataków wymagania właścicieli danych w tej kwestii będą i muszą rosnąć z dnia na dzień. Wpis ten pokrótce ma na celu przybliżyć mechanizmy, rozwiązania, funkcjonalności Security w SQL Server z podziałem na:

  • Szyfrowanie danych
  • Kontrola dostępu
  • Monitoring

Przeglądając tą listę zastanów się, co używasz i co mógłbyś zaimplementować w swojej organizacji, aby zagwarantować/podnieść bezpieczeństwo danych.

Szyfrowanie danych

Cell-Level Encryption (od SQL Server 2008)

Metoda szyfrowania danych w spoczynku. Pozwala tylko na szyfrowanie określonych kolumn w bazie danych. Wymaganiem Cell-Level Encryption jest, aby kolumny szyfrowane były typu varbinary. Dane są szyfrowane za pomocą wbudowanej funkcji EncryptByKey podczas zapisu i odszyfrowywane podczas odczytu pod warunkiem użycia funkcji DecryptByKey. W tej metodzie szyfrowania dane załadowane do pamięci są w postaci szyfrogramu. Szyfrowanie możliwe poprzez: ciąg znaków, symetryczny klucz, asymetryczny lub certyfikat. Wspierane algorytmy to AES z 128, 196, 256-bitowymi kluczami oraz 3DES. Co ciekawe, funkcjonalność dostępna już w darmowej wersji SQL Server Express.

Transparent Data Encryption (od SQL Server 2008)

Transparent Data Encryption chroni całą bazę danych składowaną na dysku. Odszyfrowanie następuję podczas wczytania danych do pamięci i pozostają tam w takiej postaci. Szyfrowanie jest kompletnie transparentne dla aplikacji i nie wymaga implementacji żadnych zmian w kodzie. Dzięki tej funkcjonalności można szyfrować pliki bazy danych, pliki dzienników i pliki kopii zapasowych bez zmiany istniejących aplikacji. Szyfrowanie używa jak wyżej algorytmów AES i 3DES.

Zapewnienie bezpieczeństwa danych - TDE

Always Encrypted (od SQL Server 2016)

Always Encrypted chroni dane zarówno w czasie transmisji danych i w spoczynku. Mechanizm chroni dane na kilku poziomach: aplikacji, sieci, bazy danych. Pozwala na szyfrowanie danych tylko w określonych kolumnach. Aplikacja kliencka poprzez sterownik ADO.NET obsługuje rzeczywiste szyfrowanie i deszyfrowanie danych poza środowiskiem SQL Server. W ten sposób można kontrolować, kto ma dostęp do danych w niezaszyfrowanym stanie, co umożliwia wymuszenie oddzielenia ról i zminimalizowanie ryzyka dla danych szczególnie chronionych. Funkcja niezwykle przydatna, gdy zdecydujemy się przechowywać dane w chmurze publicznej.

Zapewnienie bezpieczeństwa danych - Always Encrypted

Bitlocker Drive Encryption (od Windows Server 2008R2)

Bitlocker nie jest funkcjonalnością SQL Server. Dane są chronione na poziomie systemu operacyjnego. Bitlocker Drive Encryption działa na poziomie woluminu i chroni dane w spoczynku przy użyciu algorytmu AES. Szyfrowanie dysków funkcją BitLocker ma na celu ochronę danych przed dostępem osób mających fizyczny dostęp do dysku. Bez odpowiedniego klucza szyfrowania dane są całkowicie bezużyteczne.

Connection Encrypting (od SQL Server 2008)

Bezpieczna komunikacja dostarczona protokołem TLS 1.1 lub najnowszym TLS 1.2 . Zapewnia poufność i integralność transmisji danych, poprzez utworzenie prywatnego połączenia przy użyciu kryptografii symetrycznej do szyfrowania transmisji danych.

Backup Encrypted (od SQL Server 2014)

Backup jest sam w sobie już elementem zapewnienia bezpieczeństwa. Jednak dodatkowo SQL Server obsługuję szyfrowania kopii zapasowych bazy danych bez potrzeby oprogramowania firm trzecich instalowanych na serwerze . Obsługiwane są algorytmy szyfrowania AES raz 3DES.

Kontrola dostępu

Row-Level Security (od SQL Server 2016)

Row-Level Security umożliwia kontrolowanie dostępu do wierszy w tabeli w oparciu o cechy użytkownika wykonującego zapytanie (np. grupy członkostwa lub wykonanie kontekstu). Funkcjonalność ogranicza wiersze, które mają być zwracane bez względu na użyje aplikacje, automatycznie stosując predykat do zapytań. Dostęp jest egzekwowany poprzez polisy bezpieczeństwa, które wywołują funkcję tablicową, jako predykat zabezpieczeń. W predykatem zabezpieczeń, wiersze są filtrowane przez „ciche” wykluczenie. O wystąpieniu filtrowania użytkownik nie jest informowany.

Zapewnienie bezpieczeństwa danych - Row-Level Security

Dynamic Data Masking (od SQL Server 2016)

Dynamic Data Masking to mechanizm ukrywania danych wrażliwych dla użytkowników niemających do nich uprawnień. Dynamiczne maskowanie danych zawiera kilka wbudowanych funkcji maskujących:

  • Default – zwraca dla ciągów znaków xxxx, dla typów numerycznych i binarnych 0, dla daty i czasu 01.01.2000 00:00:00.0000000
  • Email – zwraca adresy emailowy w postaci: aXXX@XXXX.com
  • Custom string – zwraca dane częściowo w zależności od niestandardowej definicji
  • Random – zwraca pełne maskowanie wartości poprzez użycie losowej wartości z określonego zakresu

Windows Firewall

Zapora systemu Windows zapobiega nieautoryzowanemu dostępowi komputera, ograniczając aktywność portów komunikacyjnych (TCP, jak i UDP) do wybranego zestawu wstępnie zatwierdzonych portów i / lub aplikacji. Domyślnie zapora systemu Windows zamyka port 1433 (domyślny port TCP/IP dla domyślnych wystąpień programu SQL Server), uniemożliwiając dostęp do serwera bazy danych. Administratorzy, aby zezwolić na dostęp są zmuszeni otworzyć port, aby udrożnić ruch do instancji SQL Server.

Active Directory

Z pozoru niepowiązane, ale uwierzytelnianie w usłudze Active Directory zapewnia ważną funkcję zabezpieczającą w zakresie ochrony danych. Zcentralizowane zarządzanie tożsamością dzięki Active Directory umożliwia alternatywne uwierzytelnianie SQL Server, które byłby uciążliwe w przypadku stosowania chociażby wymuszania zmian haseł. Active Directory umożliwia korzystanie z protokołu zabezpieczeń Kerberos, a także dodatkowych zasady haseł.

Just Enough Administration

Just Enough Administration jest, co prawda funkcją bezpieczeństwa związana z Windows Server, zaprojektowaną, aby dostarczać minimalną liczbę uprawnień do administracji systemem. Doskonale się w celu redukcji ryzyka związanego z nadmiernymi uprawnieniami dla administratora.

Uprawnienia

Zadaniem administratora jest efektywne zarządzanie dostępem do SQL Server i baz danych. W tym celu tworzymy loginy, konfigurujemy odpowiednie uprawnienia oraz przypisujemy role. Przypisywane uprawnienia i rolę określają, jakie działania mogą być wykonywane przez użytkowników oraz do jakich danych mogą mieć oni dostęp. Uprawnienia możemy podzielić na dwa poziomy, dotyczące uprawnień instancji SQL Server oraz poziomu bazy danych.

Procedury składowane oraz widoki

Procedury składowane oraz widoki oferują korzyści wynikające z ograniczania dostępu do tabel i zapytań ad hoc, wprost definiując działania, które użytkownicy mogą wykonać. Procedury składowane z punktu zapewnienia bezpieczeństwa pozwala programistą hermetyzację zadań, aby zapewnić powtarzalność wykonania. Ponad to definiują akceptowane i wymagane parametry niezbędne do zwracania wartości skalarnych bądź zestawów danych. Widoki będące tylko do odczytu, to zdefiniowane kwerendy będące optymalizowane pod kątek wydajności.

Zapytania parametryzowane

Parametryzowane zapytania chronią przed atakiem SQL injection. Jeśli nie ma możliwości użycia procedur składowanych, należy nadal używać parametrów podczas tworzenia dynamicznych zapytań SQL. Procedury składowane są korzystne pod względem konserwacji i ponownego wykorzystania, ale zapytania sparametryzowane są ważnym podejściem do ochrony zapytań na poziomie aplikacji.

Przełączanie kontekstu

Wykorzystanie klauzuli EXECUTE AS pozwala to na wybór konkretnego kontekstu, w którym uruchamia się polecenie. Szczególnie użyteczne, aby nie przyznawać jawnie uprawnień dla określonej grupy użytkowników a jednocześnie umożliwić wykonanie pewnych operacji. EXECUTE AS może być użyte w dowolnej instrukcji T-SQL.

Monitoring

Audyt (od SQL Server 2008)

Audyt obejmuje śledzenie i rejestrowanie zdarzeń występujących na poziomie bazy danych lub instancji SQL Server. Wbudowane audyty śledzą próby logowania (domyślnie nieudane próby), aby rejestrować podejrzane próby połączenia. SQL Server umożliwia użycie rozszerzonych zdarzeń podczas tworzenia audytu, co pozwala administratorom tworzyć niestandardowe audyty różnych zdarzeń, które pomogą śledzić i zapobiegać szkodliwym działaniom. Zdarzenia audytu mogą być zapisywane do dziennika zdarzeń lub pliku audytu.

Podsumowanie

Jak można zauważyć elementów jest sporo, nie tylko z obszaru SQL Server, które przekładają się na zapewnienie bezpieczeństwa danych. Szczegóły dotyczące wymienionych rozwiązań będę prezentował w kolejnych wpisach. Jeśli już teraz potrzebujesz szczegółów lub masz pytania w kwestii implementacji pewnych rozwiązań, zapraszam do kontaktu.

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.

3 Comments

  1. Adrian Chodkowski

    Bardzo fajny wpis! Z funkcjonalnościami SQL 2016 trzeba uważać bo nie działają one w 100% tak jak mogłoby się wydawać – Dynamic Data Masking czy RLS można ominąć budując odpowiedni warunek w WHERE. Ogólnie rzecz biorąc implementacja tych mechanizmów ma mniejszy lub większy wpływ na wydajność – np. w moich testach RLS niemal zawsze powodował, że w planie z indeksem kolumnowym miałem przetwarzanie wierszowe a nie batchowe.. Takich niuansów spotkałem wiele jak np. TDE a użycie kompresji itd. Zaciekawiła mnie funkcjonalność BitLocker i zastanawiam się jaki ma ona wpływ na wydajność bazy danych – udało Ci się może coś takiego testować?

Leave a Reply

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