Różne oblicza ochrony bazy danych

Bezpieczeństwo bazy danych zależy nie tylko od starań producenta. Na ogólne zagrożenie ma wpływ poziom nadanych uprawnień, a także codzienna praca administratorów.

Centralnym miejscem składowania informacji z firmowych systemów i aplikacji są bazy danych. Razem z aplikacjami tworzą skomplikowany system. Mechanizm uprawnień dostępu bywa na tyle zagmatwany, że prawie nikt nie podejmuje prób ograniczania ich poziomów. Skutki mogą być niebezpieczne - od kradzieży, podmiany lub usunięcia części danych, aż do całkowitego zniszczenia treści, z której korzysta aplikacja.

Niszczące błędy

Wiele aplikacji pracuje z bazą na poziomie uprawnień systemowych, choć nie jest to potrzebne. Zazwyczaj przyczyną jest niedopatrzenie lub niewiedza deweloperów, którzy tę aplikację tworzyli. To poważne zagrożenie, gdyż wykorzystanie podatności takiej jak SQL Injection w podatnym polu umożliwia wykonanie prawie dowolnej komendy SQL, w tym usunięcie tabeli (DROP TABLE) czy jej wyczyszczenie (TRUNCATE TABLE). W niektórych instalacjach, gdzie aplikacja loguje się na konto, które jest właścicielem przestrzeni tabel (TABLESPACE), można usunąć całą przestrzeń tabel razem z obiektami, plikami i powiązaniami, wydając polecenie w postaci DROP TABLESPACE nazwa_tbspc INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS;. To spowoduje nieodwracalną utratę danych zapisanych we wszystkich obiektach tam istniejących. Jest to duże niedopatrzenie, ale nadal spotykane, zwłaszcza w sytuacji, gdy deweloper korzystał z konta o uprawnieniach do modyfikacji schematu i danych, a następnie to samo konto zapisał w kodzie aplikacji i nie odwołał zbędnych już uprawnień.

Zobacz również:

  • IDC CIO Summit – potencjał drzemiący w algorytmach
  • Dzięki nowym przepisom, walka z nadużyciami w komunikacji elektronicznej będzie łatwiejsza
  • Dlaczego warto korzystać z VPN w 2024 roku?

Pierwszym zadaniem naprawczym powinno być sprawdzenie uprawnień, jakie są potrzebne do wykonania danej operacji, a następnie wprowadzenie ograniczeń na to, co dany użytkownik może zrobić w bazie. Jeśli aplikacja na niektórych tabelach wykonuje wyłącznie operacje odczytu, to użytkownik nie powinien mieć tam uprawnień zmiany tabeli (ALTER), czyszczenia (TRUNCATE), tworzenia (INSERT), usuwania (DELETE) ani modyfikacji krotek (UPDATE). Jeśli to tylko możliwe, warto korzystać z nadawania i odwoływania uprawnień per user, korzystając z ról, które udaje się precyzyjnie dostroić do potrzeb związanych z operacjami wykonywanymi przez aplikację.

Boczną ścieżką do bazy

Jeśli włamywacz pozna hasło i sposób połączenia się do bazy danych, na pewno z tej informacji skorzysta, łącząc się z bazą w podobny sposób, jak zrobiłaby to aplikacja. Dzięki temu otrzyma dostęp do kompletu danych i będzie mógł pobrać lub zmienić zapisy w tych samych tabelach, z których korzysta aplikacja. Operacje takie jak pobranie czy aktualizacja danych mogą być sprawnie wykonane. Nawet jeśli w aplikacji wprowadzono audyt aktywności pracowników, niewiele firm porównuje go z prawdziwą aktywnością w bazie.

Najlepszym rozwiązaniem jest wprowadzenie granularnych zestawów uprawnień dla każdego użytkownika, ochrona szczególnie istotnych zasobów i skorzystanie z możliwości zablokowania logowania wybranych użytkowników do bazy danych poza normalnym interfejsem aplikacji. Możliwości takie dostarczy na przykład Database Vault w bazie Oracle 12c, gdzie będzie możliwa o wiele dokładniejsza ochrona uwzględniająca sposób nawiązania połączenia. Niekiedy wystarczy podział sieci na segmenty i ochrona za pomocą zapory sieciowej. Ma to sens, jeśli na stacjach roboczych nie ma żadnej aplikacji, która musiałaby się do tej bazy łączyć bezpośrednio.

Ograniczyć uprawnienia

Podstawowym problemem związanym z bezpieczeństwem są zbyt wysokie uprawnienia przydzielane pojedynczym osobom, a także kontom, z których korzystają aplikacje. Zasada minimalnych przywilejów koniecznych zakłada przydzielenie uprawnień, które są niezbędne do wykonania danego polecenia, ale poziom jest trudno ustalić. W obecnie eksploatowanych bazach danych pozyskanie informacji o uprawnieniach jest trywialne, ale znacznie trudniej jest określić minimalny poziom dostępu niezbędny do wykonania danej operacji. Z tego powodu uprawnienia przydzielane są "na zapas", by aplikacja działała poprawnie. Zjawisko to można spotkać zwłaszcza wtedy, gdy dostawca oprogramowania od początku nie projektował go pod kątem zasady minimalnych, koniecznych przywilejów.

Nowość w tej dziedzinie przyniesie baza Oracle 12c - zostanie do niej wprowadzona opcja monitorowania uprawnień, z których naprawdę korzystają aplikacje i użytkownicy. Możliwości analizy roli dla użytkownika, sesji czy nawet całej bazy dostarczy pakiet DBMS_PRIVILEGE_CAPTURE. Za jego pomocą można będzie przechwycić wykorzystane uprawnienia, a następnie obejrzeć te, z których użytkownik bazy skorzystał (dla uprawnień systemowych jest to perspektywa DBA_USED_SYSPRIVS), wraz z informacjami, skąd uprawnienia pochodzą. Ustalenie niepotrzebnych uprawnień systemowych umożliwi perspektywa DBA_UNUSED_SYSPRIVS. Można będzie utworzyć do niektórych zadań własną rolę zawierającą niezbędne uprawnienia, nadać je użytkownikowi za pomocą roli, a oryginalne zbyt wysokie - odwołać. Rejestracja obejmuje także zmianę przywilejów w trakcie pracy.

Narzędzie Database Vault, które mocno rozszerzy ochronę danych Oracle, w wersji 12c będzie już zainstalowane - do jego uruchomienia wystarczy wstępna konfiguracja zabezpieczeń i restart bazy danych. Pakiet analizy uprawnień jest własnością SYS i użytkownik, który ma z niego skorzystać, musi mieć uprawnienia do jego uruchomienia.

Ochronić dane przed administratorem

Dzięki nowym rolom będzie można przeprowadzać operacje takie jak strojenie bazy danych, nie posiadając przy tym uprawnień systemowych do całej bazy. Obecnie do strojenia bazy Oracle administratorzy posiadają pełne uprawnienia, a do niektórych zadań logują się jako SYSDBA. Warto odejść od tego, nadając minimalne uprawnienia, dzięki czemu administrator odpowiedzialny za wydajność bazy danych będzie mógł ją stroić, ale nie będzie mógł manipulować kontami dostępu, nie będzie też miał pełnych uprawnień systemowych.

Aby zminimalizować ryzyko związane z pracą administratorów, można podzielić pracę z bazą na:

- zarządzanie kontami (administrator kont)

- backup

- użycie narzędzi eksportu danych, takich jak data base pump

- zarządzanie kluczami szyfrującymi

- strojenie bazy danych i wprowadzanie poprawek

- audyt (oficer bezpieczeństwa); wykonanie audytu można podzielić na dwie role: administrator audytu, który ustawia opcje, oraz osoba przeglądająca audyt, która nie ma żadnych uprawnień poza przeglądaniem zapisu.

Po odwołaniu niepotrzebnych uprawnień dla konta administratora baz danych i wprowadzeniu ograniczeń dostępu do wybranych obszarów (do tego celu posłuży Database Vault) administrator może nadal zarządzać bazą, ale nie ma dostępu do poufnych danych. Z kolei administrator kont również nie będzie mógł przeczytać danych oznaczonych jako szczególnie chronione, a oficer bezpieczeństwa przeglądający audyt nie ma żadnych uprawnień do bazy, poza prowadzeniem audytu. Ponieważ mechanizm audytu jest niezależny od zarządzania uprawnieniami, można będzie określić, nie tylko kto i kiedy nadał uprawnienia, ale także jak postępowały zmiany przywilejów w czasie.

Ograniczenie uprawnień jest istotne dla firm, które regularnie zatrudniają pracowników kontraktowych. Można zewnętrznym użytkownikom nadać uprawnienia wyłącznie do obiektów, nad którymi pracują, prowadząc przy tym dogłębny audyt tego, co ci ludzie robią w bazie.

Aby zmniejszyć ryzyko kradzieży danych przez odtworzenie backupu na innej maszynie, odtworzona kopia bezpieczeństwa jest tak samo chroniona jak oryginalna instancja produkcyjna. Ochrona obejmuje także możliwość użycia narzędzia data pump, służącego do importu i eksportu danych z bazy. Przy nadawaniu uprawnień do eksportu danych można określić także zakres obiektów, które dany administrator jest w stanie wyeksportować tą drogą. W ten sposób dział deweloperski może pobrać swój schemat, nad którym pracuje, ale nie może dokonać pełnego eksportu bazy, zawierającego poufne informacje.

Strefa bezpieczna

Ciekawą opcją Database Vault jest strefa chroniona (realm). Zadaniem strefy w wersji Oracle 12c będzie ograniczenie działań użytkowników w chronionych obiektach, przy czym ochrona ta będzie transparentna i usunie w locie niepotrzebne uprawnienia. Można blokować dostęp do danych innym osobom poza uprawnionymi. Można uwzględniać przy tym także sposób zalogowania do bazy, gdyż Database Vault będzie rozpoznawać adres IP inicjujący połączenie, a także informacje o samym połączeniu oraz sposobie jego zestawienia (czy pochodzi bezpośrednio ze stacji roboczej, czy od aplikacji).

Blokada dostępu działa nawet wtedy, gdy użytkownik jest właścicielem obiektu lub ma uprawnienia systemowe, takie jak SELECT ANY TABLE. W ten sposób można łatwo zablokować polecenia niszczące dane, takie jak usunięcie tabeli czy przestrzeni tabel. Ochrona ta jest również selektywna - administrator może na przykład wydać polecenie rekompilacji perspektywy (ALTER VIEW nazwa COMPILE;) odwołującej się do chronionych danych, ale nie przejrzy zawartości przez nią dostarczanej. To samo dotyczy informacji wykorzystywanej do strojenia bazy - by nie dopuścić do wycieku informacji za pomocą odpowiednio przygotowanych poleceń analizy wydajności i strojenia bazy.

W bazie produkcyjnej warto zablokować próby zmian struktury tabel, wprowadzając ochronę przed wykonaniem poleceń ALTER TABLE na wszystkich tabelach wykorzystywanych przez aplikację, niezależnie od poziomu uprawnień zalogowanego użytkownika. Blokada ta będzie również dostępna w wersji 12c.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200