Ograniczanie uprawnień

Ograniczanie uprawnień to stosowanie zasady najmniejszego przywileju przy nadawaniu praw do obiektów bazy.

Zasada najmniejszego przywileju w dostępie do danych

Ograniczanie uprawnień oznacza przyznawanie użytkownikowi, aplikacji albo grupie tylko takich praw, które są potrzebne do wykonania określonego zadania. Jeżeli konto ma odczytywać dane z jednej tabeli, nie powinno automatycznie otrzymywać możliwości ich modyfikowania, usuwania ani tworzenia nowych obiektów. Podobnie konto używane przez aplikację internetową zwykle nie potrzebuje uprawnień administratora całego silnika bazy danych. Zakres dostępu powinien wynikać z rzeczywistej funkcji konta, a nie z wygody jednorazowej konfiguracji.

Uprawnienia mogą dotyczyć różnych obiektów: baz, schematów, tabel, widoków, kolumn, procedur składowanych oraz funkcji. Najczęściej rozdziela się prawa odczytu, zapisu i administracji. Odczyt jest zwykle reprezentowany przez przywilej SELECT, dodawanie rekordów przez INSERT, zmianę danych przez UPDATE, a usuwanie przez DELETE. Prawa do tworzenia lub usuwania tabel, indeksów i innych obiektów powinny pozostać przy kontach administracyjnych albo kontach przeznaczonych do wdrażania zmian.

Role, dziedziczenie i zakres przyznanych praw

Praktycznym sposobem porządkowania dostępu jest używanie ról. Zamiast nadawać uprawnienia każdej osobie oddzielnie, administrator tworzy role odpowiadające obowiązkom, na przykład rolę tylko do odczytu, rolę operatora danych oraz rolę odpowiedzialną za utrzymanie struktury bazy. Użytkownik otrzymuje wtedy konkretną rolę, a nie szeroki zestaw pojedynczych praw. Ułatwia to przegląd konfiguracji, odebranie dostępu po zmianie obowiązków oraz wykrycie kont, które mają więcej uprawnień, niż faktycznie wykorzystują.

Trzeba sprawdzać nie tylko uprawnienia nadane bezpośrednio, ale również te odziedziczone przez członkostwo w rolach i grupach. W wielu systemach prawo może pochodzić z kilku poziomów: bezpośredniego nadania do tabeli, roli użytkownika, grupy systemowej albo uprawnienia obejmującego cały schemat. Odebranie jednego przywileju nie zawsze usuwa dostęp, jeśli identyczne prawo nadal wynika z innego źródła. Dlatego kontrola powinna obejmować efektywny zestaw uprawnień, czyli prawa, które konto rzeczywiście posiada po uwzględnieniu dziedziczenia.

Widoki i procedury jako bezpieczniejsza granica dostępu

Ograniczenie uprawnień nie musi polegać wyłącznie na udostępnieniu całej tabeli. Widok może zwracać tylko wybrane kolumny albo rekordy spełniające określony warunek. Dzięki temu konto raportowe może otrzymać prawo SELECT do widoku, bez dostępu do kolumn technicznych lub pomocniczych znajdujących się w tabeli źródłowej. Taki podział zmniejsza zakres danych dostępnych dla użytkownika i ogranicza ryzyko przypadkowego wykorzystania informacji do celu, którego nie przewidziano w projekcie.

Do wykonywania kontrolowanych zmian można użyć procedury składowanej. Konto aplikacji otrzymuje wówczas prawo uruchomienia konkretnej procedury, natomiast bezpośrednie prawa do tabel mogą zostać odebrane. Procedura może sprawdzać parametry, wymuszać dozwoloną kolejność operacji i ograniczać modyfikacje do wskazanego zakresu. Należy jednak pamiętać, że szczegóły działania zależą od silnika bazy danych, w tym od sposobu wykonywania procedury, właściciela obiektu i kontekstu uprawnień. Konfigurację trzeba więc potwierdzić w dokumentacji używanego produktu oraz przetestować na koncie o takim samym poziomie dostępu jak konto produkcyjne.

Przegląd uprawnień i bezpieczna korekta konfiguracji

Kontrolę dostępu warto rozpocząć od spisu kont, ról i obiektów, a następnie przypisać każdemu kontu właściciela oraz opis zastosowania. Należy sprawdzić konta nieużywane, konta współdzielone, uprawnienia nadane tymczasowo i prawa obejmujące większy zakres niż wymagany. Szczególnej uwagi wymagają przywileje administracyjne, możliwość tworzenia obiektów, zmiany struktury bazy oraz wykonywania operacji na wszystkich tabelach. Przegląd powinien uwzględniać także konta aplikacyjne, zadania automatyczne i narzędzia serwisowe, ponieważ nieinteraktywne konto również może wykorzystać zbyt szeroki dostęp.

Odbieranie praw należy wykonywać etapami: najpierw dokumentuje się aktualny stan, potem sprawdza wykorzystanie uprawnień, a następnie testuje zmianę w środowisku kontrolnym. Operacje odpowiadające odebraniu dostępu są często realizowane poleceniem REVOKE, lecz dokładna składnia, dziedziczenie i zachowanie po zmianie zależą od konkretnego silnika. Po korekcie trzeba zweryfikować zarówno scenariusze dozwolone, jak i odrzucone: odczyt właściwych danych, próbę zapisu, próbę usunięcia rekordu oraz próbę dostępu do obiektu spoza zakresu. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów i komputerów PC, natomiast sama konfiguracja uprawnień do bazy powinna być prowadzona zgodnie z dokumentacją używanego systemu oraz zakresem odpowiedzialności administratora.