Współczesne bazy danych są oprogramowaniem tak skomplikowanym, powiązanym z innymi systemami operacyjnymi i aplikacjami, że ocena poziomu ich bezpieczeństwa z reguły opiera się na mało wiarygodnych danych. Wciąż brakuje obiektywnych mierników.

W każdej średniej wielkości firmie jest przynajmniej jedna baza danych przechowująca krytyczne dla przedsiębiorstwa informacje. Oprócz niezwykle popularnego w segmencie małych firm, choć nie tylko, serwera open source MySQL, w Polsce liczą się naprawdę tylko dwie bazy - Oracle i Microsoft SQL Server. Najczęściej wykorzystywane cechy dla naprawdę dużych instalacji to jednocześnie występujące - niezawodność, skalowalność, wieloplatformowość i bezpieczeństwo. Można odnieść wrażenie, że w najbliższych "wojnach marketingowych" bezpieczeństwo będzie szczególnie ważkim argumentem. Tym bardziej, że jest on trudno mierzalny.

Było źle, jest lepiej...

Historia błędów produktów Microsoftu jest zastanawiająca. Niektóre luki w bezpieczeństwie pozostawały niezałatane latami (taką historię ma np. Internet Explorer), inne były klasyfikowane jako krytyczne i łatane stosunkowo szybko, pozostałe zaś bagatelizowane do czasu pojawienia się eksploita. Na tym tle SQL Server nie odstaje od pozostałych produktów, również zawierał listę krytycznych luk w bezpieczeństwie. Można jednak zaryzykować tezę, że obecnie dostępne wersje tej bazy danych mają już za sobą okres lawinowo wykrywanych luk. Najgorsza pod względem bezpieczeństwa była i jest wersja SQL Server 2000, która doczekała się nawet robaków (SQL Spida, Slammer) roznoszących się przez eksploitowanie znanego od dawna błędu. Zagrożenie było bardzo poważne, gdyż wiele baz zostało w ten sposób zarażonych. Przyczyna takiej skali ataków jest typowa - brak aktualizacji oraz umożliwienie bezpośredniego połączenia z Internetu na port, na którym pracuje SQL Server (1433). Wielu administratorom instalującym maszyny Windows połączone z Internetem nie przychodziło do głowy zainstalowanie solidnej zapory sieciowej oddzielającej cenną bazę od sieci. Tymczasem zwykła zapora (choćby najprostszy firewall zainstalowany na Linuxie) i stosowanie wirtualnych sieci prywatnych (lub serwerów terminalowych) radykalnie zmniejszyłyby liczbę takich ataków, nawet gdyby serwer nie został zaktualizowany.

SQL Server jest zazwyczaj instalowany w środowisku korzystającym z Active Directory. Przy poważnym, a jednocześnie popularnym w Polsce błędzie polegającym na użyciu do pracy SQL Server konta administratora domeny Windows na dostępnej z Internetu maszynie, możliwa była kompromitacja całej domeny. Niejeden system został w ten sposób spenetrowany, najpoważniejsze błędy powstają bowiem wtedy, gdy na oczywiste luki w bezpieczeństwie aplikacji lub usługi nakładają się rażące niedopatrzenia administratorów.

SQL Server jest instalowany wyłącznie na platformie Windows i przez to mocno związany z bezpieczeństwem tego systemu. Większość włamań do baz danych Microsoftu odbywa się właśnie przez system operacyjny, bo eksploity przeznaczone dla Windows są publikowane bardzo często, a ich skuteczność jest wysoka. Jednocześnie w przeważającej liczbie systemów łaty nie są wciąż instalowane na bieżąco, bo przed ich wprowadzeniem do środowisk produkcyjnych należy wykonać gruntowne sprawdzenie w środowiskach testowych, a to wymaga czasu i zasobów. Wiele polskich firm nie posiada nawet minimalnego środowiska testowego, a środowisko testowe będące dokładną kopią produkcyjnego jest wykorzystywane w bardzo niewielu przedsiębiorstwach. Dla zarządów firm jest to często po prostu "nieuzasadniony wydatek". Jedną z wielu przyczyn niechęci do utrzymywania systemu Windows w stanie stuprocentowej aktualności jest także to, że niemal każda aktualizacja wymaga restartu całego systemu.

Wskutek spektakularnych problemów związanych z wirusami atakującymi bazy Microsoftu oraz pokaźną listą eksploitów dla Windows powstało złośliwe porównanie SQL Server do szwajcarskiego sera. Tymczasem najpoważniejsze luki w bazie zostały już załatane i dla jego najnowszej wersji trudno znaleźć tak dużą ich listę, jaką miały SQL Server 7.0 i 2000. Oczywiście na pewno zostaną wykryte nowe, ale przypuszczalnie nie będzie to następowało zbyt często.

Oracle nie integruje się w tak dużym stopniu z systemem operacyjnym jak SQL Server i ma to dobre strony. Po pierwsze, baza Oracle może pracować przy dość ograniczonych uprawnieniach systemu operacyjnego. Dzięki temu kompromitacja samej bazy nie oznacza automatycznie uzyskania przez atakującego uprawnień systemowych. Jest to też baza wieloplatformowa, więc napisanie robaka zarażającego wszystkie jej wersje nie jest prostym zadaniem. To, że w wersji dla systemów Unix nie ma np. błędu umożliwiającego przepełnienie bufora, wcale nie znaczy, że wersja dla Windows go nie posiada i odwrotnie. Tym niemniej szczególnie popularna w wielu firmach wersja Oracle 10g R2 dla platformy Linux x86 może być dobrym celem dla takiego ataku.

...będzie gorzej

Wielu specjalistów jest zdania, że szczególnie krytyczne luki w bezpieczeństwie bazy danych Oracle dopiero czekają na odkrycie. To co już udało się znaleźć przyprawia zaś o zawrót głowy. Ciekawą listę już opublikowanych alertów wraz z odpowiednimi komentarzami można znaleźć nahttp://www.red-database-security.com/advisory/published_alerts.html . Najpopularniejszym błędem była do niedawna możliwość modyfikacji dowolnych danych za pomocą odpowiedniej perspektywy i to przez użytkownika posiadającego minimalne uprawnienia (http://www.red-database-security.com/advisory/oracle_modify_data_via_inline_views.html ).

W ciągu ostatnich trzech lat baza Oracle przechodzi okres intensywnego rozwoju, a ponieważ jest to bardzo skomplikowana aplikacja, można oczekiwać, że na pewno zawiera błędy, które zechcą wykorzystać hakerzy. Aby lepiej uzmysłowić wagę problemu, Cesar Cerrudo, właściciel firmy Argeniss, która zajmuje się bezpieczeństwem informacji, wpadł na niecodzienny pomysł. Zamierzał opublikować odkryte błędy, tak aby przez tydzień prezentować jedną lukę dziennie. Plan ten nie został wcielony w życie, ale należy podejrzewać, że przynajmniej kilka bardzo poważnych luk jest już znanych włamywaczom. Zdają się to potwierdzać opublikowane niedawno informacje o kolejnych lukach w bazie Oracle, z których przeważająca większość jest krytyczna. Szczegóły, a także eksploity można znaleźć w Internecie na kilku listach mailingowych.

Walka na liczby

Historia błędów daje pojęcie o tym jak olbrzymia ilość pracy musi zostać wykonana i jak łatwo o pomyłkę. Obie bazy, SQL Server i Oracle, na pewno wciąż zawierają błędy, które wcześniej czy później zostaną odkryte. Do tej pory najpopularniejszym miernikiem bezpieczeństwa baz danych była liczba historycznych luk w bezpieczeństwie. Gdyby użyć tylko tego kryterium, Microsoft okazuje się zwycięzcą. Według firmy Next Generation Security Software, w wersjach SQL Server od 7.0 do 2005 włącznie odkryto tylko 59 luk, a dla baz Oracle (od 8.1.6 do 10g) aż 233. Wobec nich siedem błędów, które miał opublikować Cesar Cerrudo to niewiele. Należy jednak zwrócić uwagę, że ogólna liczba luk wcale nie jest dobrym miernikiem. Statystycznie większość włamań odbywa się nie przez eksploitowanie luki w samej bazie danych, ale przez naruszenie bezpieczeństwa systemu operacyjnego, na którym ta baza pracuje. Włamanie do systemu jest znacznie prostsze niż do bazy danych, choćby dlatego, że sam system jest popularniejszy, zawiera więcej składników i łatwiej znaleźć błąd, którym można się posłużyć.

Sprawa miernika bezpieczeństwa jest nadal otwarta, bo przy instalacji bazy Oracle na platformie Windows można eksploitować błąd systemu operacyjnego Microsoft, aby potem - posiadając odpowiednie uprawnienia systemowe - próbować uzyskać dostęp do bazy.

Błędy te można oczywiście wykorzystać również podejmując próbę włamania do bazy SQL Server. Z kolei gdy ta sama wersja Oracle dla innej platformy zostanie zainstalowana np. w systemie wykorzystującym Linux, włamywacz musi użyć innych narzędzi, ale Linux też ma błędy i również można je wykorzystać do uzyskania nieautoryzowanego dostępu do bazy.

Jak porównać bezpieczeństwo każdej z platform i czy w ogóle można to włączać do końcowego wyniku pomiaru bezpieczeństwa bazy? A jeśli najpopularniejsza wersja systemu operacyjnego zawiera poważne luki, zaś inny system ma ich względnie mało - jak to się przełoży na liczby? Czy uwzględniać specjalne zabiegi utrudniające włamanie do systemów operacyjnych (hardening), pod kontrolą których pracuje baza? Jak wziąć pod uwagę problem typowych ustawień systemu i bazy (out-of-the-box)? Jak uwzględnić najczęściej popełniane błędy w instalacji i konfiguracji? Niestety, trudno dać jednoznaczną odpowiedź na te pytania, ponieważ zbyt wiele czynników należy wziąć pod uwagę. Ale należy pamiętać, że proste i względnie łatwe porównanie liczby luk nie jest w pełni wiarygodnym miernikiem bezpieczeństwa.

Bez wątpienia pozostała jeszcze długa droga do zapewnienia wysokiego bezpieczeństwa baz danych. Jest to ciągła bitwa, która nieprędko, jeśli w ogóle kiedykolwiek zostanie przez kogoś wygrana.

<hr>Bardzo dobry podręcznik na temat bezpieczeństwa SQL Server można znaleźć na stroniehttp://www.windowsecurity.com/articles/Secure_SQL_Server.html . Dla bazy Oracle także jest dostępny taki podręcznik -http://www.petefinnigan.com/orasec.htm , zaś dokumentacja Oracle Database Security Guide, która znajduje się na firmowych stronach Oracle'a, zawiera wiele wskazówek dla administratorów.