Bezpieczeństwo i uprawnienia

Bezpieczeństwo i uprawnienia to zbiorcze określenie mechanizmów kontroli dostępu i ochrony danych w systemie bazodanowym.

Zakres pojęcia bezpieczeństwa w systemie bazodanowym

Bezpieczeństwo i uprawnienia obejmują mechanizmy, które określają, kto może połączyć się z bazą danych, jakie obiekty może odczytywać lub zmieniać oraz w jaki sposób system rejestruje wykonane operacje. Należy rozróżnić uwierzytelnianie od autoryzacji. Uwierzytelnianie potwierdza tożsamość użytkownika, usługi albo aplikacji, natomiast autoryzacja sprawdza, czy rozpoznany podmiot ma prawo wykonać określoną czynność. Samo poprawne zalogowanie nie oznacza więc automatycznie dostępu do wszystkich tabel, widoków, procedur czy schematów.

Kontrola dostępu może być nadawana bezpośrednio pojedynczym kontom, ale w praktyce częściej wykorzystuje się role lub grupy. Rola skupia zestaw uprawnień, na przykład możliwość odczytu określonych danych albo wykonywania wybranych procedur. Takie rozdzielenie ułatwia odebranie dostępu po zmianie stanowiska, ogranicza liczbę wyjątków i zmniejsza ryzyko pozostawienia aktywnych uprawnień. Podstawową zasadą jest najmniejszy zakres przywilejów potrzebny do wykonania konkretnego zadania. Konto aplikacji powinno otrzymywać tylko te prawa, których wymaga działanie programu, a konto administracyjne nie powinno być używane do zwykłej pracy.

Uwierzytelnianie, role i zakres dostępu do danych

Bezpieczna konfiguracja zaczyna się od właściwego sposobu uwierzytelniania. Hasła powinny być przechowywane przez system w postaci odpornej na bezpośrednie odtworzenie, a ich przesyłanie podczas logowania powinno odbywać się przez chronione połączenie, jeżeli platforma i konfiguracja tego wymagają. W środowiskach, które to obsługują, dodatkowym zabezpieczeniem może być uwierzytelnianie wieloskładnikowe albo wykorzystanie zewnętrznego dostawcy tożsamości. Ważne jest także wyłączenie nieużywanych kont, usunięcie kont domyślnych oraz ograniczenie dostępu z niepotrzebnych adresów sieciowych.

Uprawnienia powinny być projektowane osobno dla odczytu, wstawiania, aktualizowania i usuwania danych. Nie każda aplikacja potrzebuje prawa do kasowania rekordów, a użytkownik wykonujący raport może wymagać wyłącznie odczytu. Ograniczenia można dodatkowo nakładać na poziomie schematu, tabeli, widoku, procedury lub pojedynczych kolumn, zależnie od możliwości konkretnego silnika. Widoki mogą udostępniać tylko wybrane pola, a procedury mogą wykonywać kontrolowane operacje bez ujawniania bezpośredniego dostępu do tabel bazowych. Trzeba jednak sprawdzić, czy dziedziczenie uprawnień przez role nie powoduje przypadkowego rozszerzenia dostępu.

Ochrona połączeń, danych i śladów audytowych

Kontrola uprawnień nie zastępuje ochrony danych podczas przesyłania i przechowywania. Połączenia między aplikacją a bazą powinny być zabezpieczone szyfrowaniem transportowym, aby ograniczyć możliwość przechwycenia danych logowania oraz treści zapytań. Certyfikaty używane do weryfikacji połączenia muszą być sprawdzane, ponieważ samo włączenie szyfrowania bez potwierdzenia tożsamości drugiej strony nie zapewnia pełnej ochrony przed podstawieniem serwera. W przypadku kopii zapasowych należy kontrolować również ich dostępność, miejsce przechowywania i sposób szyfrowania.

Audyt pozwala ustalić, kto i kiedy wykonał operację oraz czy doszło do prób dostępu zakończonych odmową. Rejestrowanie powinno obejmować zdarzenia istotne dla bezpieczeństwa, takie jak logowania, zmiany uprawnień, modyfikacje konfiguracji i operacje na szczególnie ważnych obiektach. Nadmierne rejestrowanie wszystkich zapytań może jednak zwiększać koszty przechowywania i utrudniać analizę. Logi muszą być chronione przed modyfikacją przez zwykłych użytkowników, a ich przegląd powinien uwzględniać nietypowe godziny pracy, nagły wzrost liczby błędów autoryzacji oraz użycie kont uprzywilejowanych. Sam audyt nie blokuje niepożądanej operacji, ale dostarcza dowodów potrzebnych do wykrycia i odtworzenia zdarzenia.

Diagnostyka błędów dostępu i bezpieczna korekta konfiguracji

Problem z uprawnieniami często objawia się komunikatem o odmowie dostępu, brakiem tabeli w wynikach zapytania, niemożnością wykonania zapisu albo błędem połączenia aplikacji z bazą. Najpierw należy ustalić, którego konta faktycznie używa program, do jakiego serwera i instancji się łączy oraz czy wskazany obiekt znajduje się w oczekiwanym schemacie. Następnie warto porównać wymagane działanie z rzeczywistymi uprawnieniami konta i sprawdzić dziedziczenie praw przez role. Nie należy rozwiązywać błędu przez nadanie pełnych uprawnień administracyjnych, ponieważ usuwa to objaw kosztem zwiększenia ryzyka.

Podczas korekty należy zmieniać pojedyncze elementy, zapisać poprzednią konfigurację i przetestować zarówno działanie dozwolone, jak i operacje, które powinny pozostać zablokowane. Trzeba również sprawdzić, czy zmiana nie wpłynęła na inne aplikacje, zadania automatyczne lub kopie zapasowe. Jeżeli problem wystąpił po aktualizacji programu, zmianie hasła, odtworzeniu bazy albo migracji na inny komputer, przyczyną może być rozbieżność między nazwą konta, metodą uwierzytelniania, konfiguracją połączenia i uprawnieniami obiektów. Diagnostyka laptopa lub komputera PC może obejmować analizę konfiguracji aplikacji, usług systemowych, zapory oraz lokalnych logów, bez ujawniania haseł i innych danych uwierzytelniających.