Sekcje

Przejdź na skróty do treści. | Przejdź do nawigacji


Baza wiedzy Publikacje Bezpieczeństwo bazy danych - weryfikacja (2)

Bezpieczeństwo bazy danych - weryfikacja (2)

Tekst jest kontynuacją artykułu Bezpieczeństwo baz danych.

Ograniczenie funkcjonalności oferowanych przez bazę danych

Zgodnie z wspomnianą wcześniej zasadą least privileges, zaleca się minimalizację instalowanych  oraz uruchamianych usług i fukncjonalnoś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:

  1. całe usługi (np. serwer http apache, w przypadku Oracle)
  2. 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)
  3. domyślnie instalowane bazy o charakterze "demo"


Przykładowe dalsze informacje

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

  1. Czy próby uwierzytelnienia (udane, nieudane) są logowane?
  2. Czy logowane są operacje (zapytania SQL) na bazie danych? 
  3. W jakim miejscu składowane są logi zawierające ww. informacje? Kto ma do nich dostęp? Czy są wykonywane kopie zapasowe logów?
  4. Czy logowanie następuje do bazy danych czy na poziomie systemu operacyjnego?
  5. 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

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

Przykładowe dalsze informacje

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 zaznaczamy 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?
  1. 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).
  2. 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).
  3. 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

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 rozdziału, poruszymy 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ą wskazujemy - w kontekście plików bazodanowych.

Zalecenia

  1. Czy pliki bazodanowe znajdują się na odpowiednim typie systemu plików (umożliwiającym nadanie odpowiednich uprawnień? np. NTFS a nie FAT?)
  2. 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?
  3. 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ą?)
  4. 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 z ogólne, a także elementy specyficzne dla samej bazy danych.

Zalecenia

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

Podsumowanie

W trzyczęściowym artykule przedstawiliśmy - naszym 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 staraliśmy 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

Czytaj dalej

 

--Michał Sajdak (michal.sajdak@securitum.pl)

Przydatne informacje? Polub nas na facebooku.

Nawigacja
 
Darmowy magazyn o ITsec

zine
Subskrybuj RSS:
RSS