Bezpieczeństwo baz danych

 


Bezpieczeństwo baz danych

 

Wstęp

Bazy danych często stanowią jeden z głównych elementów systemów IT – przechowują oraz  udostępniają informacje. Sama definicja bazy nie narzuca określonego sposobu organizacji danych, jednak obecnie najbardziej rozpoznawana na rynku jest baza relacyjna oraz związany z nią język SQL.  Implementacji „SQL-owych baz danych” są zapewne setki, choć zaledwie kilka z nich cieszy się szeroką popularnością. Takimi systemami są: Oracle Database, SQL Server, DB2, MySQL czy Postgresql. Przy okazji, warto wspomnieć, że istnieją również inne rozwiązania – alternatywne do wspomnianych powyżej - sposoby organizacji informacji,  jak choćby obiektowa baza danych (np. ZODB), czy baza danych XML (np. eXist).

W poniższym tekście zajmę się tematyką ochrony baz danych – głównie w kontekście baz relacyjnych. Poruszę takie zagadnienia jak:

  • ekspozycja bazy na poziomie sieci
  • poprawki bezpieczeństwa
  • użytkownicy z wykorzystaniem których działa baza danych
  • uprawnienia do plików bazodanowych – na poziomie systemu plików
  • ograniczenie funkcjonalności oferowanych przez bazę danych
  • logowanie (księgowanie) dostępu do bazy danych
  • szyfrowanie
  • bezpieczeństwo po stronie aplikacji korzystających z bazy danych
  • miejsce składowania danych w systemie plików
  • kopie zapasowe

Zanim przejdę do szczegółów zastanówcie się wcześniej nad pytaniem:


Dlaczego chronimy bazę danych?

Odpowiedź na to pytanie może wydać się prosta – aby realizować odpowiednie cele biznesowe, tj. aby system, który wykorzystuje bazę danych generował odpowiednie zyski dla organizacji.  Zilustrujmy to na następującym przykładzie.

Przykład: prywatna placówka medyczna posiada system umożliwiający rejestrację pacjentów on-line. W bazie danych przechowywane są również informacje o pacjencie oraz historii jego chorób.

Zyskiem z posiadania takiej bazy może być: wygoda pacjenta, ograniczenie dokumentacji papierowej oraz szybsze dodarcie do określonych informacji (oszczędność czasu pracowników kliniki). Ten cel biznesowy może być zagrożony np. przez:

  • czasowy brak dostępności bazy (pacjenci nie mogą się rejestrować, lekarze nie mają wglądu w historię choroby)
  • utratę poufności bazy (dane dostają się w niepowołane ręce; istnieje ryzyko np. złamania zapisów Ustawy o Ochronie Danych Osobowych)
  • nieuprawnioną zmianę informacji w bazie (może to spowodować chaos w działaniu placówki medycznej)

W powyższym przykładzie, odpowiednie zabezpieczenie tego typu bazy danych może zminimalizować powyższe zagrożenia, a tym samym pozytywnie wpłynąć na zysk kliniki.

Jako rodzaj informacji wymagającej ochrony wskazaliśmy dane osobowe / dane medyczne. Jakie jeszcze inne dane mogą być traktowane jako wrażliwe i wymagające ochrony? Odpowiedź na to pytanie pozostawię Wam, jednocześnie wskazując kilka możliwości:

  • Dane o charakterze finansowym (np. salda kont bankowych, informacje płacowe, numery kart kredytowych)
  • Hasła dostępowe do systemów (często użytkownicy posiadają takie same hasła dostępowe do wielu systemów – zatem uzyskanie informacji o hasłach z jednej bazy danych może prowadzić do uzyskania dostępu do wielu innych systemów)
  • Informacje stanowiące o przewadze konkurencyjnej firmy (np. dane klientów czy dostawców)
  • Wszystkie inne dane firmowe o charakterze poufnym

Niejako podsumowując dotychczas opisane kwestie, spójrzcie ramowo na następujące zagadnienie:

Planowanie prac związanych z bezpieczeństwem bazy danych

Planowanie to może wyglądać następująco:

  • Inwentaryzacja baz danych oraz przechowywanych w nich informacji (np. baza opisana w przykładzie powyżej, przechowująca dane medyczne)
  • Określenie wartości skatalogowanych baz danych (istotne dane będziemy objąć szczególnie wysoką ochroną).
  • Określenie czynników mogących zagrozić poprawnemu funkcjonowaniu bazy (np. zewnętrzny atak z poziomu Internetu, awaria sprzętowa serwera, atak z sieci LAN, itd.) - wraz z prawdopodobieństwem wystąpienia (tzw. ryzykiem)
  • Określenie odporności naszej bazy na wszelakie zagrożenia określone powyżej (tym w głównej mierze zajmiemy się w naszym artykule).
  • Rekonfiguracja bazy danych, jeśli jej odporność na wskazane wcześniej zagrożenia jest niska.

Czytelnikowi może nasunąć się pytanie, ile czasu warto poświęcić na realizację całego powyższego procesu? Możemy odpowiedzieć – adekwatnie do wartości przechowywanych przez nas danych. Co to precyzyjnie oznacza, Czytelnik powinien odpowiedzieć we własnym zakresie, analizując swój kontekst. Zainteresowanych tego typu szacowaniami odsyłamy do tematyki analizy ryzyka, a sami przechodzimy do konkretnych działań, które można wykonać przy weryfikacji bezpieczeństwa bazy danych.

 

Weryfikacja bezpieczeństwa bazy danych

Bezpieczeństwo bazy danych może być zagrożone na różne sposoby, poniżej omówię kilka kategorii zagadnień, na które moim zdaniem warto zwrócić uwagę. Pamiętajmy, że kompromitacja zabezpieczeń tylko z jednej grupy jest w stanie poważnie zagrozić bezpieczeństwu całej bazy danych - zatem weryfikacja bezpieczeństwa tego typu systemu powinno być wykonywana całościowo.

Każda z poniższych kategorii zawiera wypunktowane zalecenia, umożliwiające zaplanowanie we własnym zakresie audytu bezpieczeństwa czy testów penetracyjnych bazy danych.

 

Ekspozycja na poziomie sieci

Baza danych często udostępniana jest w sieci (czy to lokalnej, czy np. Internecie) – na bezpieczeństwo bazy danych można więc spojrzeć jak na bezpieczeństwo każdej innej usługi sieciowej (jak np. serwer webowy, serwer DNS, itd.).

Zalecenia

Sugerujemy zweryfikować takie elementy jak:

  • Na jakich interfejsach sieciowych / portach nasłuchują usługi bazodanowe ? (niekiedy nie jest konieczne nasłuchiwanie bazy danych na wszystkich interfejsach sieciowych ani na interfejsie dostępnym do Internetu).
  • Czy istnieje możliwość ataku na usługę z poziomu sieci ? – mamy tutaj na głównie myśli podatności w obsłudze protokołu komunikacyjnego (w lokalizacji tego typu podatności przydatny może być tzw. skaner podatności; skuteczne ataki w tym miejscu mogą wynikać również z braku wykonywania aktualizacji bezpieczeństwa w systemie, o czym piszemy w dalszej części tekstu)
  • Czy w wykorzystywanej przez nas bazie, znane są inne specyficzne elementy, charakterystyczne dla komponentu nasłuchującego ? (np. ochrona za pomocą hasła komponentu nasłuchującego).

Przykładowe dalsze informacje

Bezpieczeństwo komponentu Listener w Oracle (do wersji 9 Oracle, domyślnie komponent ten posiada puste hasło dostępowe, umożliwiające przejęcie kontroli nad listenerem)

http://www.net-security.org/dl/articles/Integrigy_OracleDB_Listener_Security.pdf

Weryfikację nasłuchiwania na określonych interfejsach sieciowych można wykonać np. linuksowym poleceniem: # netstat -tulpn

W tym przypadku poniżej, usługa mysqld nasłuchuje jedynie na interface lokalnym (127.0.0.1):

tcp   0   0 127.0.0.1:3306     0.0.0.0:*     LISTEN      28852/mysqld

 

Informacje o robaku Slammer (atakującego SQL Server)

Przykład alertu zgłaszanego przez oprogramowanie klasy IDS (intrusion detection system) - snort

[**] [1:2003:8] MS-SQL Worm propagation attempt [**]

[Classification: Misc Attack] [Priority: 2]

 04/19-23:16:14.032636 202.x.x.x:3352 -> x.x.x.x:1434

 UDP TTL:116 TOS:0x0 ID:55339 IpLen:20 DgmLen:404

 Len: 376

 [Xref => http://vil.nai.com/vil/content/v_99992.htm][Xref => http://cgi.nessus.org/plugins/dump.php3?id=11214][Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=2002-0649][Xref => http://www.securityfocus.com/bid/5311][Xref => http://www.securityfocus.com/bid/5310]

 

Poprawki bezpieczeństwa

Jak wspomnieliśmy wyżej, często udane ataki na bazę danych związane są z brakiem aktualizacji samej bazy danych. W tym przypadku idea ataku może być następująca:

W  oprogramowaniu bazy danych znajdowana jest krytyczna luka, umożliwiająca zdobycie pełnej kontroli nad bazą danych z poziomu sieci.

W Internecie udostępniony jest exploit (program umożliwiający zautomatyzowane zaatakowanie systemu).

Producent bazy danych udostępnia aktualizację. Po jej wgraniu, ewentualne uruchomienie ww. exploitu nie powiedzie się, jednak gdy aktualizacja nie zostanie wykonana, wrogi kod może umożliwić przejęcie kontroli nad bazą.

Zalecenia

Rozważając kwestię aktualizacji bazy danych warto zadać sobie pytania:

  • Czy posiadamy wykupiony pakiet umożliwiający instalowanie tego typu poprawek ? (w przypadku niektórych baz danych – np. Oracle – stanowić to może spory koszt)
  • Czy aktualizacje bazy danych są wykonywane?
  • Czy baza instalowana jest jako pakiet systemu operacyjnego, czy niezależnie?
  • Czy weryfikowana jest integralność aktualizacji ? (czy wiemy skąd pochodzą aktualizacje?  jeśli udałoby się dostarczyć nam wrogą aktualizację – istnieje możliwość zdalnego przejęcia kontroli nad bazą)
  • Czy aktualizacje wykonywane są ręcznie czy automatycznie? (niekiedy same aktualizacje mogą spowodować niepoprawne działanie całej bazy danych  - manualne aktualizacje pozostawiają administratorowi możliwość szybkiej reakcji na ewentualne problemy)
  • Czy aktualizacje sprawdzane są wcześniej na serwerach testowych?

 

Przykładowe dalsze informacje

Informacje o wprowadzeniu poprawek do bazy danych Oracle (w tym łatających luki umożliwiające pełen, nieuwierzytelniony dostęp z poziomu sieci):

http://www.oracle.com/technology/deploy/security/pdf/2004alert68.pdf

 

Użytkownicy z wykorzystaniem których działa baza danych

Aby ograniczyć wpływ negatywnych skutków naruszenia bezpieczeństwa na cały system, warto rozważyć uprawnienia użytkownika systemu operacyjnego, z wykorzystaniem którego uruchomiona jest baza.

Przykład: W Internecie dostępna jest aplikacja umożliwiająca dostęp do poczty elektronicznej w firmie. System działa w oparciu o bazę danych MySQL. Baza działa z uprawnieniami użytkownika systemu operacyjnego root (administrator), a aplikacja wykorzystuje użytkownika bazodanowego posiadającego uprawnienia administracyjne w bazie danych. Skuteczny atak z poziomu Internetu na aplikację prowadzi do:

  • możliwości odczytu e-maili dowolnego użytkownika,
  • możliwości odczytu innych danych znajdujących się w bazie danych na tym serwerze,
  • możliwości pełnego dostępu do systemu operacyjnego i atakowanie dalszych systemów w firmie

Zalecenia

  • Czy użytkownik systemu operacyjnego, z wykorzystaniem którego uruchomiona jest usługa bazodanowa, posiada uprawniania administracyjne? (należy unikać takiej sytuacji)
  • Czy powyższy użytkownik posiada dodatkowe uprawnienia, niewymagane koniecznie do działania bazy danych ? (np. uprawniania w systemie plików do wielu zasobów w systemie operacyjnym)
  • Czy istnieje możliwość interaktywnego zalogowania się na użytkownika bazodanowego - np. z wykorzystaniem SSH ? (nie powinniśmy oferować takiej możliwości)

Przykładowe dalsze informacje

Unikanie uruchamiania usług SQL Server z uprawnieniami kont administracyjnych:

http://www.sqlservercentral.com/blogs/brian_kelley/archive/2008/06/12/avoid-domain-admin-level-accounts-for-sql-server.aspx

Konfiguracja środowiska chroot w celu ograniczania ekspozycji systemy operacyjnego po ewentualnym ataku na usługę sieciową

 

Użytkownicy bazodanowi

Kolejnym istotnym elementem przy weryfikacji bezpieczeństwa bazy danych jest określenie uprawnień użytkowników definiowanych na poziomie bazy danych. Ogólna zasada mówi, że powinniśmy działać zgodnie z tzw. zasadą least privileges, wg. uprawnienia użytkowników bazodanowych powinny być najmniejszymi, które są wymagane do prawidłowego działania całości systemu.

Zalecenia

  • Czy wybrani użytkownicy bazodanowi nie posiadają nadmiernych uprawnień ? (np. uprawnienia administracyjne do bazy dla użytkownika bazodanowego skonfigurowanego w aplikacji webowej).
  • Czy w systemie wykonane jest mapowanie użytkowników bazodanowych na użytkowników systemu operacyjnego (popularne szczególnie w systemach Windows). Jeśli tak, to czy mapowanie jest poprawne?
  • Jakie konta bazodanowe mają uprawnienia administracyjne?
  • Którzy użytkownicy posiadają dostęp anonimowy do bazy danych ? (konta dzielone bez hasła – mamy tu na myśli konta typu guest).
  • Czy możliwy jest dostęp do bazy za pomocą użytkowników / haseł domyślnych ? (np. kombinacja DBSNMP/DBSNMP w bazie Oracle)
  • Czy użytkownicy bazodanowi posiadają wystarczająco złożone hasła dostępowe?

Przykładowe dalsze informacje

Zbiór informacji o tematyce haseł użytkowników - baza Oracle

http://www.red-database-security.com/whitepaper/oracle_passwords.html

Oprogramowanie cain & abel, umożliwiające m.in. łamanie hashów haseł dla wybranych baz SQL

 

Ograniczenie funkcjonalności oferowanych przez bazę danych

 Zgodnie z wspomnianą wcześniej zasadą least privileges, zaleca się minimalizację instalowanych  oraz uruchamianych usług i funkcjonalności bazodanowych. W wielu przypadkach, takie domyślne funkcjonalności nie są wymagane do prawidłowego działania bazy.

Zalecenia

 Zalecenia zależą od konkretnej implementacji bazy danych. Dodatkowymi funkcjonalnościami mogą być przykładowo:

  • całe usługi (np. serwer http apache, w przypadku Oracle)
  • konkretne procedury czy grupy procedur i funkcji bazodanowych (np. procedura xp_cmdshell w systemie SQL Server, umożliwiająca wykonanie polecenia systemu operacyjnego, użytkownikowi bazodanowemu)
  • domyślnie instalowane bazy o charakterze "demo"

Przykładowe dalsze informacje

 Dokumentacja hardeningowa dla SQL Server 2005 (rozdział SQL Server Settings): https://www.cisecurity.org/tools2/sqlserver/CIS_SQL2005_Benchmark_v1.2.0.pdf

 

Logowanie (księgowanie) dostępu do bazy danych

 Aby zapewnić systemowi właściwość zwaną rozliczalnością, należy w odpowiedni sposób logować (księgować) operacje wykonywane na bazie danych. Tego typu logi mogą okazać się przydatne, gdy będziemy potrzebowali prześledzić ewentualną historię zdarzeń, przy naruszeniu bezpieczeństwa bazy danych – w takim przypadku będziemy wiedzieć jaka operacja,  kiedy oraz przez kogo została wykonana na bazie.

Zalecenia

  • Czy próby uwierzytelnienia (udane, nieudane) są logowane?
  • Czy logowane są operacje (zapytania SQL) na bazie danych?
  • W jakim miejscu składowane są logi zawierające ww. informacje? Kto ma do nich dostęp? Czy są wykonywane kopie zapasowe logów?
  • Czy logowanie następuje do bazy danych czy na poziomie systemu operacyjnego?
  • Czy księgowanie wykonywane jest jedynie lokalnie czy również na zdalny system?

 

Szyfrowanie

Jako "szyfrowanie" rozumiemy w tym przypadku mechanizmy zapewniające poufność, integralność oraz bezpieczne uwierzytelnienie użytkowników łączących się z bazą. Zastosowane mechanizmy kryptograficzne zależą od typu danych, które chronimy, a także specyfiki systemu IT, w którym dane te są przetwarzane. Mechanizmy te  możemy je rozważać co najmniej w kilku perspektywach:

Zalecenia

  • Czy proces uwierzytelnienia jest odpowiednio zabezpieczony? (czy dane uwierzytelniające – np. hasło przesyłane są w sieci w bezpieczny sposób?)
  • Czy wszystkie dane przesyłane  pomiędzy klientem bazodanowym a serwerem są zaszyfrowane? (zapewnienie poufności i integralności transmisji).
  • Czy szyfrowany dostęp do bazy jest wymuszany na klientach bazodanowych?
  • Czy dane znajdujące się w bazie danych przechowywane są w formie zaszyfrowanej? (zapewnienie poufności)

Przykładowe dalsze informacje

Wymuszanie szyfrowania (komunikacji klient-serwer) na bazie SQL Server:

http://msdn.microsoft.com/en-us/library/ms189067.aspx

http://msdn.microsoft.com/en-us/library/ms191192.aspx

 

Bezpieczeństwo w warstwie aplikacji korzystających z bazy danych

Tematyka związana z zagadnieniem bezpieczeństwa aplikacji jest bardzo szeroka. W tekście jedynie zaznaczę jej pewne powiązanie z bezpieczeństwem baz danych.

Jednym z częstych błędów bezpieczeństwa w aplikacjach, wpływających na bezpieczeństwo bazy danych jest SQL injection.  Istota problemu polega na możliwości nieautoryzowanej zmiany zapytania SQL generowanego po stronie aplikacji. Takie działanie umożliwia często atakującemu na pełen dostęp do bazy danych - zarówno w trybie odczytu jak i zapisu. Niekiedy również ta droga prowadzi do otrzymania dostępu na poziomie systemu operacyjnego.

Dla porządku, warto również w tym momencie wspomnieć o innych, często spotykanych problemach mogących prowadzić do naruszenia bezpieczeństwa bazy danych:

  • Przechowywanie po stronie klienckiej informacji dostępowych do serwera bazodanowego. Problem występuje często w aplikacjach desktopowych - na lokalnych stacjach użytkowników (np. w rejestrze systemu Windows) przechowywane są login/hasło użytkownika mającego pełen dostęp do bazy danych.
  • Brak odpowiednich mechanizmów kryptograficznych służących do zabezpieczenia połączenia pomiędzy klientem a serwerem (więcej informacji w punkcie: "szyfrowanie" - w niniejszym artykule)

Zalecenia

  • Czy w aplikacji następuje odpowiednia walidacja danych otrzymywanych od użytkowników?
  • Czy aplikacja korzysta z jednego użytkownika bazodanowego w celu łączenia się do bazy danych (w przypadku wystąpienia SQL injection, taka konfiguracja umożliwia atakującemu dostęp do całej bazy- jest to szczególnie groźne gdy użytkownik ten ma uprawnienia administracyjne na bazie).
  • Czy aplikacja korzysta z tzw. zapytań parametryzowanych w celu dostępu do danych (mechanizm ten, odpowiednio zaimplementowany potrafi niemal w 100% ochronić przed SQL injection).
  • Czy po stronie klienckiej przechowywane są dane dostępowe do serwera bazodanowego? (dane użytkownika mającego pełen dostęp do bazy danych)

 

Przykładowe dalsze informacje

SQL injection wg OWASP

Przykład bardziej zaawansowanych rozważań o SQL injection

 

Miejsce składowania danych w systemie plików

Ostatecznie baza danych przechowuje informacje na systemie plików (choć w określonych przypadkach dane te mogą być przechowywane np. jedynie w pamięci). Dostęp do tych plików uzyskujemy zazwyczaj nie w sposób bezpośredni (dostęp do pliku) tylko przy pomocy zapytania SQL (łącząc się z tzw. RDBMS, który między innymi dba o weryfikację uprawnień użytkowników łączących się z bazą). Użytkownicy (zazwyczaj lokalni) mający dostęp do plików przetwarzanych przez RDBMS mogą spróbować uzyskać do nich dostęp bezpośredni, tym samym omijając mechanizmy uwierzytelnienia i autoryzacji oferowane przez bazę.

Kolejną kwestią związaną z umiejscowieniem plików bazodanowych jest nieprzerwany dostępu do całej bazy. Jeśli utracony zostanie dostęp do danych w systemie plików (np. z powodu awarii dysku twardego), tracony jest również dostęp do konkretnych przetwarzanych danych. Warto zatem rozważyć wdrożenie odpowiednich mechanizmów zapewniających nieprzerwane działanie bazy w przypadku tego typu awarii.

Na koniec, poruszę jeszcze jedną kwestię związaną z dostępnością całego systemu. Otóż niekiedy, przetwarzane w bazie informacje składowane są na tej samej partycji, co pliki wchodzące w skład systemu operacyjnego, na którym uruchomiona jest baza danych. W przypadku zapełnienia takiej partycji, często przestaje działać poprawnie cały system operacyjny. Być może warto zatem wydzielić osobną partycję przechowującą pliki bazodanowe - w stosunku do partycji systemowej.

Zaznaczmy jeszcze, że tematyka wysokiej dostępności bazy jest bardzo szeroka - w niniejszym tekście jedynie ją wskazuję - w kontekście plików bazodanowych.

Zalecenia

  • Czy pliki bazodanowe znajdują się na odpowiednim typie systemu plików (umożliwiającym nadanie odpowiednich uprawnień? np. NTFS a nie FAT?)
  • Czy pliki bazodanowe na poziomie systemu plików dostępne są (odczyt/zapis)  tylko dla użytkownika z wykorzystaniem którego działa baza danych?
  • Czy awaria miejsca przeznaczonego na składowanie danych bazy powoduje niedostępność do bazy danych ? (czy mamy wdrożone mechanizmy RAID? czy wykorzystujemy redundantnie podłączoną macierz zewnętrzną?)
  • Czy dane składujemy na partycji oddzielnej od systemowej?

 

Kopie zapasowe

Z racji na wysoką wartość informacji przetwarzanych w bazach danych, koniecznością jest wykonywanie okresowych kopii bezpieczeństwa bazy. Przy wykonywaniu backupów warto rozważyć kwestie, łączące się z realizacją kopii zapasowych w ogóle, a także elementy specyficzne dla samej bazy danych.

Zalecenia

  • Czy wykonywane są kopie zapasowe wszystkich instancji baz danych?
  • Czy wykonywana jest kopia zapasowa bazy systemowej ? (często brak takiej kopii może oznaczać problemy przy próbie przywrócenia danych z backupu)
  • Czy wykonywane są testy poprawności wykonywania kopii zapasowych (próba pełnego odtworzenia bazy z wykonanej wcześniej wykonanej kopii)
  • Na jakie nośniki wykonywane są kopie zapasowe? (trwałość)
  • Czy dane na zużytych nośnikach usuwa się w sposób trwały?
  • W jaki sposób chroni się nośniki zawierające backupy - przed dostępem osób nieuprawionych?

 

Podsumowanie

W artykule przedstawiłem - moim zdaniem - najistotniejsze elementy dotyczące bezpieczeństwa bazy danych. Pewne aspekty - jak np. bezpieczeństwo fizyczne, dostępność bazy, bezpieczeństwo sieci czy systemu operacyjnego, na którym przetwarzane są informacje - zostały wskazane jedynie hasłowo. Jednakże wskazując zalecania starałem się formułować je w na tyle ogólnej formie, aby każdy z czytelników mógł dostosować i rozszerzyć je pod własne, specyficzne potrzeby - każda bowiem baza danych wymaga dedykowanego spojrzenia na bezpieczeństwo przechowywanych w niej informacji.

________________________

Polecana Literatura:

Implementing Database Security and Auditing: Includes Examples for Oracle, SQL Server, DB2 UDB, Sybase

The Database Hacker's Handbook: Defending Database Servers

Dokumentacje hardeningnowe The Center for Internet Security

Komentarze

Prześlij komentarz