W korporacyjnej bazie mogą zdarzyć się przypadkowo lub złośliwie wykonane polecenia niszczące dane. Oprócz mechanizmów uprawnień związanych obiektami i użytkownikami, należy przemyśleć reguły, które zabezpieczą dane przed masowym kasowaniem lub nadpisywaniem. W ten sposób można chronić nie tylko dane, ale także całą strukturę bazy. Uniemożliwienie wykonania polecenia DROP USER ... CASCADE; (usuwa użytkownika wraz z wszystkimi jego obiektami) czy DROP TABLE... sprawi, że nawet celowe usunięcie obiektów będzie niemożliwe. To samo dotyczy komend UPDATE lub DELETE bez warunków czy polecenia TRUNCATE TABLE. Gdy takich poleceń nie może wykonać nawet administrator bazy, poziom bezpieczeństwa poważnie wzrasta.

Szyfrowanie

Nawet najlepsze zabezpieczenia dostępu nie zdadzą się na wiele, gdy nieuczciwy administrator lub podszywający się pod niego włamywacz, będzie mógł przechwycić nieszyfrowany ruch sieciowy. Miejscem wycieku danych może być połączenie od aplikacji do bazy danych, jeśli transmisja nie jest szyfrowana, dane są łatwo dostępne. Wystarczy dobry sniffer sieciowy.

Szyfrowanie komunikacji oraz ochrona dostępu nie mogą być jedynym zabezpieczeniem danych. Należy zadbać także o bezpieczeństwo wykonywanej kopii zapasowej. Złodziej danych może ukraść kopię i ją odtworzyć na innej maszynie, a wtedy mechanizmy ochrony danych nie działają tak dobrze. Aby to uniemożliwić, należy wdrożyć szyfrowanie kopii bezpieczeństwa. Potrafią to wszystkie najważniejsze narzędzia do wykonywania backupu, wiele z nich umożliwia oddzielenie funkcjonalności operatora kopii bezpieczeństwa od administratora bazy. Szyfrowanie kopii bezpieczeństwa musi być wdrożone także wtedy, gdy kasetki opuszczają daną lokalizację.

Dobry audyt

Istotą ochrony danych jest dobry audyt. Prawidłowo sporządzany powinien być wykonywany przez osobę spoza grona administratorów i obejmować także ich działania. Modelowe rozwiązanie było wykorzystywane w systemach Novell NetWare, gdzie administrator przygotowywał odpowiednie konto dla audytora, który sam nie posiadał żadnych uprawnień poza audytowymi. Ten sam model można wdrożyć także przy bazach danych, chociaż nie wszyscy producenci baz to wspierają.

W systemach Unix można centralizować przez sieć logi do jednej maszyny (za pomocą systemowego narzędzia syslog), przy czym administratorem tego komputera może być osoba spoza administratorów. Do takiego logu można dodatkowo przekazać zdarzenia z listenera bazy Oracle (monitorowanie pliku listener.log oprócz wbudowanych narzędzi do audytu) oraz zapisy z rejestru zdarzeń systemów Windows (za pomocą narzędzi winlogd albo NTSyslog). Wysłanie zdarzeń do sysloga umożliwia ich zbieranie razem ze zdarzeniami z maszyn typu UNIX oraz routerów, przełączników sieciowych czy firewalli. Dzięki oddzieleniu zbierania zdarzeń na hostach od ich analizy, audytorem może być ktoś, kto na badanym komputerze nie ma uprawnień systemowych.

O wiele dalej powinien pójść audyt w przypadku firmy, która przetwarza wrażliwe dane w różnych bazach albo jest zmuszona do rejestrowania aktywności ze względu na uwarunkowania prawne lub wewnętrzne regulacje. Opisane powyżej rozwiązania zapisują informacje o logowaniu użytkownika, o użyciu przez niego przywilejów, ale nie rejestrują informacji o samej aktywności w bazie. Produktem, który to umożliwi, jest Oracle Audit Vault, który potrafi monitorować bazy MS SQL Server (2000 i 2005), IBM DB2 UDB (8.2 oraz 9.5) i Sybase (ASE 12.5 i 15.2). Pobranie informacji o aktywności wszystkich użytkowników, włącznie z administratorami, oraz dobra analiza zebranych danych, daje audytorom potężne narzędzie.