Na bazy danych czyha wiele zagrożeń. Większość z nich wcale nie wiąże się z wykorzystaniem wyszukanych technik. Częściej naruszenie bezpieczeństwa jest efektem takich błędów, jak wadliwa konfiguracja bazy czy pozostawienie nośników zawierających kopie zapasowe bez odpowiedniego nadzoru. Dopiero potem pojawiają się bardziej złożone technicznie ataki.

Zagrożenia i ataki

Typowym zagrożeniem może być wykorzystanie podatności bądź to systemu operacyjnego, pod którego kontrolą pracuje serwer bazodanowy, bądź aplikacji bezpośrednio komunikującej się z bazą, czy wreszcie samego oprogramowania bazodanowego. Do tego dochodzą problemy z kontami umożliwiającymi dostęp do bazy. Tutaj możliwości jest bardzo dużo. Stale podkreśla się, że zagrożeniem dla danych są pracownicy.

Zobacz również:

• Przeglądarka Chrome będzie jeszcze jakiś czas akceptować pliki cookie
• Efekt synergii zmienia zasady pracy z danymi
• Wyjaśniamy czym jest SD-WAN i jakie są zalety tego rozwiązania

Kto zagraża bazom?

. Zwykli użytkownicy

Nie mają bezpośredniego dostępu do bazy, ale w codziennej pracy korzystają z aplikacji, których backendem jest baza.

. Użytkownicy uprzywilejowani

Ci, którzy mogą, a czasami muszą mieć bezpośredni dostęp do bazy, np. administratorzy, programiści, kontraktorzy.

. Pracownicy IT

Zatrudnieni w działach zajmujących się siecią i bezpieczeństwem, audytorzy. Nie muszą mieć bezpośredniego dostępu do bazy. Mogą podsłuchiwać ruch, korzystać z informacji dostarczanych przez inne systemy.

. Goście

Osoby, które mogą podłączyć się do sieci firmowej i, znając "namiary" na serwer bazodanowy, przeprowadzić celowany atak na określoną podatność.

Zestawienie z podziałem na grupy osób mogące zagrażać informacjom w bazach danych pokazuje, że nie tylko administrator bazy danych może być jedynym winowajcą. Kontynuując wątek kont, warto wspomnieć o innej pomijanej czasami kwestii - kontroli kont. Z reguły konta użytkowników bazodanowych dzieli się na konta zwykłe i uprzywilejowane. Tylko te drugie mają niestandardowe uprawnienia - przynajmniej w teorii. W rzeczywistości mamy wiele poziomów zwykłości i uprzywilejowania. Częstą praktyką ogólną, która rozciągana jest także na systemy bazodanowe, jest kontrola kont uprzywilejowanych, co jest słusznym podejściem, ale niestety dziurawym. Zdarza się bowiem, że przez nieuwagę konto zwykłe otrzyma w prezencie uprawnienia, których być może mieć nie powinno. Stanie się w pewnym sensie kontem uprzywilejowanym, ale nie zostanie objęte kontrolą. Może nawet częściej od tego występuje podejście stosowane przez leniwych administratorów. Jeżeli użytkownik nie może czegoś zrobić, to być może jest to problem uprawnień, więc na wszelki wypadek daje się pełnię praw testowo. Problem polega na tym, że testy te niekiedy nigdy się nie kończą.

Dostrzec atak

Jak już wspominaliśmy, stale podkreślanym problemem związanym z atakami na bazy danych jest niedocenianie źródeł ataków znajdujących się wewnątrz firmy - pracowników i kontraktorów. Nie muszą korzystać z wyszukanych narzędzi, których instalacja może być blokowana przez oprogramowanie typu endpoint protection - wystarczy Excel, który ma prostego klienta do komunikacji z bazą. Można podejmować próby logowania na konta domyślne (takie jak CTXSYS - hasło "ctxsys" czy MGWUSER hasło "mgwuser" w Oracle - wersja 10g wyeliminowała większość haseł domyślnych; konto SA w SQL Express w trybie mieszanym jest domyślnie puste; w Sybase "SA" może być puste lub mieć hasło "sasasa" itp.).

Problem z ukierunkowanymi i dobrze przeprowadzonymi atakami jest taki, że dość trudno je zauważyć. Dzieje się tak ze względu na dużą liczbę połączeń obsługiwanych przez bazę. Według analityków firmy Forester, typowa baza może przyjmować do 20 tys. połączeń na sekundę. Bez dodatkowych mechanizmów ochronnych trudno dostrzec, co dokładnie się dzieje. Tym bardziej, jeżeli atakujący zdecyduje się na krótki, kilkusekundowy atak.

Zagrożeniem technicznym, który sieje największe spustoszenia w bazach, jest SQL Incjection. Mówi się także, że atak tego typu wypiera mający do niedawna palmę pierwszeństwa Cross Site Scripting i - mimo ogólnej powszechności - jest zabójczo skuteczny. Jak twierdzi Tom Cross z IBM X-Force, liczba ataków SQL Injection wzrosła z 2,5 tys. dziennie w 2007 r. do ok. 600 tys. dziennie w połowie 2009 r. Ataki SQL Injection w dużej mierze wiążą się z błędami w projektowaniu aplikacji webowych. Jeżeli atak się powiedzie, napastnik może np. pominąć konieczność zalogowania, wyciągać dane z bazy, wprowadzać w niej modyfikacje, czasami wykonywać polecenia systemowe, czy wreszcie potraktować bazę jako repozytorium dla kodu złośliwego.

Jak wspomniano, wiele zagrożeń dla bezpieczeństwa bazy wiąże się z konfiguracją kont użytkowników. Typowym problemem jest tutaj nadużywanie uprawnień. Polega ono na wykorzystywaniu przez użytkownika nadanych mu uprawnień niezgodnie z przeznaczeniem. Za przykład może posłużyć aplikacja obsługi transakcji: użytkownik, aby móc zaakceptować zlecenie, może otrzymać dostęp do danych płatnika (włącznie z numerem karty kredytowej czy danymi teleadresowymi) i potem je wykorzystać, ściągając np. listę numerów kart kredytowych z nazwiskiem i datą ważności karty. Pseudoataki tego typu są dość trudne do wykrycia bez specjalizowanych narzędzi. Użytkownik przecież niczego nie przełamuje ani nie omija.

Z powyższym łączy się także problem przyznawania nadmiernych uprawnień. Często użytkownicy mogą więcej, niż rzeczywiście potrzebują do wykonywania swoich zadań. Jeżeli mamy do czynienia ze zdeterminowanym sprawcą, który ma konto ze standardowymi uprawnieniami, to może on próbować zwiększyć swoje uprawnienia. Cel ten najczęściej jest osiągany przez przeprowadzenie ataków przepełnienia bufora wymierzonych przeciwko słabym punktom systemu. Wystarczy prześledzić bazy podatności, aby stwierdzić, że baza może być podatna na ten atak w wielu miejscach, np. błąd w usługach serwera bazodanowego czy błąd w stored procedures. Jak donosi Secunia, w 2009 r. zarówno dla baz Oracle, jak i Microsoftu czy MySQL, PostreSQL - zanotowano przynajmniej kilka podatności umożliwiających skuteczne zaatakowanie bazy.

Celem ataków mogą padać także protokoły sieciowe. Większość oprogramowania bazodanowego komunikuje się wykorzystując protokoły, które nie doczekały się publicznie dostępnej dokumentacji. Możliwe jest więc znalezienie w nich długo niezauważonej luki. Dzięki temu może dojść do obchodzenia mechanizmów uwierzytelniania czy przekazywania nieautoryzowanych zapytań, np. INSERT.

Innym problemem jest słabość mechanizmów audytu. Z reguły monitoruje się tylko to, co związane jest z niepowodzeniem i trudno o takie podejście mieć pretensje. Niestety, w rezultacie bardziej inteligentne ataki mogą pozostać niezauważone.

Zabezpieczenia

Standardowo

Zabezpieczenie baz danych można rozpatrywać na wielu płaszczyznach. Pierwszym etapem jest z pewnością planowanie oraz właściwe zaprojektowanie rozmieszczenia serwerów bazodanowych w infrastrukturze.

Samo planowanie struktury bazy, właściwości użytkowników, mechanizmów wymiany danych - to zupełnie osobny temat (kwestię tę pominiemy). Znacznie częściej administrator bezpieczeństwa dostaje jakiś "stan zastany" i nie ma wpływu na to, w jaki sposób ktoś inny zaprojektował system.

Większość nowoczesnych aplikacji działa według modelu trójwarstwowego, obejmującego: interfejs webowy, serwer aplikacyjny i bazę. Te trzy elementy powinny znajdować się w różnych strefach bezpieczeństwa. Dotyczy to głównie aplikacji, których interfejs dostępny jest z internetu. Dobrą praktyką i sprawą raczej oczywistą (choć, jak pokazuje praktyka - nie zawsze) jest umieszczanie bazy danych w odseparowanym i kontrolowanym środowisku, np. centrum danych. Poziom kontroli tamże, to sprawa dość dyskusyjna i sama lokalizacja bazy nie gwarantuje od razu bezpieczeństwa. Niemniej jednak segmentacja daje pewne możliwości, jak chociażby oddzielenie każdego elementu systemu urządzeniami kontroli dostępu, a co za tym idzie ograniczenie ryzyka.

Podstawowym sposobem ochrony baz danych jest hardening, który polega na zmianie i dostrojeniu domyślnych parametrów konfiguracyjnych. Nie jest to zadanie trudne (zwłaszcza że dostępnych jest wiele poradników na ten temat), ale niestety żmudne. Na szczęście, już od lat znakomite przewodniki hardeningowe przygotowuje ośrodek CIS (The Center for Internet Security). Na stronie tej organizacji (cisecurity.org) znajdziemy najbardziej aktualne poradniki dla baz MySQL, Oracle, MSSQL, Sybase czy DB2. I tak przede wszystkim należy usunąć konta domyślne i pozmieniać hasła tym, które są potrzebne i aktywować natywne mechanizmy audytu, np. alterowanie w przypadku wielokrotnych nieudanych prób logowań. Kolejnym krokiem jest dbanie o aktualność zarówno systemu operacyjnego, jak i samej bazy danych. Wreszcie należy pamiętać o okresowym przeprowadzaniu audytów bezpieczeństwa. Mogą one polegać na skanowaniu w poszukiwaniu podatności, weryfikacji konfiguracji bazy i systemu operacyjnego, czy też kontroli kont użytkowników ze szczególnym zwróceniem uwagi na uprawnienia.

Szyfrowanie

Kolejną rzeczą do zrobienia, jeżeli chcemy coś zabezpieczyć, jest sprawdzenie, czy da się wprowadzić jakieś mechanizmy kryptografii. Czasami w tę stronę popychają wymogi regulacji, np. PCI. Tak samo jest w przypadku baz danych. Mechanizmy szyfrowania baz danych koncepcyjnie można przyrównać do technik szyfrowania dysków. Istnieje więc możliwość szyfrowania zarówno całych baz danych, jak i operowania nieco bardziej precyzyjnie na obiektach. Mechanizmy szyfrujące nie pozostają jednak bez wpływu na wydajność baz danych, jak również często na zajmowaną przez nie przestrzeń.

Podejmując decyzję o zastosowaniu szyfrowania, należy przeanalizować zawartość baz danych. Wybierając model szyfrowania, trzeba rozważyć to, co dokładnie chcemy szyfrować. Może się okazać, że nie ma potrzeby szyfrowania całych baz, a tylko ich fragmenty. Być może nie chcemy chronić wszystkich kolumn czy tabel, a tylko te zawierające numery pesel i kart kredytowych. Idąc dalej, w przypadku kolumny z numerami kart być może wystarczy szyfrowanie tylko ostatnich 4-6 znaków? Warto także pamiętać o indeksowaniu. Jeżeli zostaną zaszyfrowane pola indeksowane, wówczas można spodziewać się znacznego wzrostu apetytu na zasoby systemowe - każdorazowe odwołanie do takiego pola będzie wymagało przeprowadzenia deszyfracji.

Niektóre systemy bazodanowe mają wbudowane mechanizmy szyfrujące, np. MS SQL 2008 Transparent Data Encryption (TDE). TDE chroni dane w spoczynku (logi i pliki danych). Rolą tego mechanizmu nie jest więc szyfrowanie transmisji. Klucz umożliwiający szyfrowanie (DEK) przechowywany jest w rekordzie startowym (boot record) bazy danych. Warto odnotować, że uruchomienie tego mechanizmu nie wpływa negatywnie na przestrzeń zajmowaną przez bazę.

Podobny mechanizm stosuje także Oracle. Chodzi tu o Transparent Database Encryption, występujący w dwóch odsłonach: TTE i TCE. Pierwsza -Tablespace Encryption - umożliwia szyfrowanie wybranych tabel i została wprowadzona w wersji 10g Release2; druga - Column Encryption - pozwala na szyfrowanie wybranych kolumn i po raz pierwszy pojawiła się w wersji 11g. Również od wersji 11g Oracle wspiera obsługę modułów HSM (Hardware Security Module). A ponieważ każdy system szyfrowania jest na tyle bezpieczny, na ile dobrze chronione są klucze szyfrujące, warto wesprzeć się technologią firm trzecich. W tym zakresie w Polsce dość dużą popularnością cieszą się chociażby SafeNet czy Thales (nCipher). Producenci ci oferują m.in. właśnie platformy HSM.

Mechanizmy szyfrowania zbliżone w działaniu do TDE są dostępne nie tylko dla użytkowników produktów gigantów bazodanowych. Z niewielką pomocą z zewnątrz mogą się tą technologią cieszyć np. użytkownicy MySQL. Firma CritoTech sprzedaje rozwiązanie ezNcrypt, które umożliwia szyfrowanie tabel z wykorzystaniem AES 256.

Narzędziownia

Z narzędziowego punktu widzenia po części można wykorzystać to, co już mamy: zapory ogniowe i IPS-y. Powinny one blokować podejrzany ruch na podstawie analizy protokołów sieciowych. Dobre IPS-y mogą też skutecznie powstrzymywać ataki nakierowane na podatność aplikacji, bazy lub samego serwera. Jeżeli w sieci wprowadzono strefy bezpieczeństwa wymuszane przez VLAN-y, ACL czy zapory ogniowe, to należy ograniczyć bezpośredni dostęp do bazy danych i odseparować zwykłych użytkowników. Z kolei dostęp, który pozostanie otwarty, powinien być ściśle monitorowany - zwłaszcza w przypadku kont o podwyższonych uprawnieniach.

Ale narzędzia standardowe to nie wszystko. Coraz większą popularnością cieszą się systemy z serii DAM (Database Activity Monitoring). W ostatnim czasie (2009 r.) ubyło na tym rynku kilku konkurentów. Zrezygnowali nawet giganci, np. Symantec. To, rzecz jasna, ucieszyło konkurentów i umocniło ich pozycję. Obecnie do ścisłej czołówki tego segmentu rynkowego można zaliczyć firmy, takie jak: Imperva, Sentrigo Secerno czy Netezza (dawniej Tizor). W tym obszarze próbują swoich sił także inni znani z innych rozwiązań dostawcy, np. IBM, który niedawno przejął firmę Guardium. Rozwiązania DAM charakteryzują się tym, że obok innych funkcjonalności rozumieją język zapytań bazodanowych, a przy tym potrafią korelować określone zdarzenia, tworzyć profile zachowań i monitować oficera bezpieczeństwa w razie wykrycia istotnych odchyleń. Siłą rozwiązań DAM jest to, że w przeciwieństwie do natywnych mechanizmów ochronnych baz danych, można stosować je w środowiskach heterogenicznych, gdzie funkcjonują bazy pochodzące od różnych producentów i w różnych wersjach. W niektórych wypadkach system DAM pełni rolę narzędzia DLP, wykrywając np. dużą liczbę zapytań odwołujących się do pola zwierającego numery PESEL.

Cechą najlepszych rozwiązań DAM jest to, że posługują się nie tylko sygnaturami, ale "rozumieją" kontekst, w jakim przesyłane są zapytania. Kontekst mogą tworzyć: pora dnia, segment sieci, z którego pochodzi aktywność, rodzaj aplikacji, z której następuje połączenie, czy użytkownik wykonujący zapytanie. Możliwa jest zatem ochrona przed atakami o nieznanych systemowi sygnaturach. Metoda działania jest więc podobna jak w przypadku rozwiązań NBAD. Najpierw DAM uczy się typowego zachowania w sieci, bada interakcje i tworzy profil. Następnie wychwytuje wszelkie anomalie. Secerno na przykład chwali się, że w większości przypadków na stworzenie modelu bazowego wystarczy dzień. Ponadto szanujący się DAM powinien umożliwiać filtrację zapytań. Można więc wskazać białe lub czarne listy zapytań. Rozwiązania tego typu prowadzą także dziennik wszystkich aktywności związanych z bazą danych, a więc są w stanie dostarczyć dowodów w razie podejrzenia naruszenia bezpieczeństwa. W idealnej sytuacji DAM powinien również zostać zintegrowany z systemem zarządzania incydentami (SIEM). DAM-y mogą być wpinane do sieci w trybie inline i pracować zarówno w trybie monitoringu, jak i blokowania. W początkowej fazie wdrożenia włączany jest ten pierwszy, a dopiero po weryfikacji następuje przełączenie do drugiego. Problem polega na tym, że wiele firm nie może zdecydować się na przełączenie w tryb blokowania i mimo posiadania odpowiedniego rozwiązania, nadal pada ofiarą ataków.

Moduł do ochrony kryptograficznej nCipher nShield 6000e (Thales) ze złączem PCI Express. Wydajność - 6000 podpisów cyfrowych wykonywanych przy użyciu algorytmu RSA z kluczem 1024-bitowym.

Na rynku obecne są także narzędzia określane mianem bazodanowych zapór ogniowych. Niektórzy stawiają znak równości między nimi a DAM-ami, inni podkreślają różnice. Nomenklatura jednak nie jest tu najważniejsza. Faktem jest, że taka zapora rozumie sposób komunikacji baz danych. Przykładem takiego narzędzia może być dostępny na licencji GPL GreenSQL. Jest to proxy (w postaci oprogramowania), które pracuje inline między aplikacją a bazą danych, przechwytując zapytania SQL. Jako że jest to produkt open source, znajdziemy w nim wsparcie dla darmowych baz, takich jak MySQL i PostgreSQL. Jego głównym zadaniem jest kontrola zapytań i blokowanie tych, które nie są dozwolone. GreenSQL działa na podstawie sygnatury oraz analizy heurystycznej.

Częściowo bazy danych mogą chronić również rozwiązania DLP, posiadające konektory/agentów do poszczególnych rodzajów baz. W tym przypadku ochrona skupiona jest przede wszystkim na kontroli zawartości bazy, a nie na składaniu zapytań czy formie komunikacji. Jeżeli określona polityką bezpieczeństwa informacja próbuje opuścić bazę danych, DLP blokuje jej wypływ.