Z jakimi mechanizmami nadawania zabezpieczeń, dającymi możliwości wykonywania operacji na bazie danych, związane są zagadnienia zarządzania kontami, użytkownikami i uprawnieniami?
A. Z atrybutami.
B. Z przywilejami systemowymi.
C. Z regułami.
D. Z przywilejami obiektowymi.
Pytanie z egzaminu CKE, czerwiec 2014 (arkusz E.14-X-14.05).
W tym pytaniu chodzi o przywileje systemowe, czyli uprawnienia pozwalające wykonywać operacje na poziomie całego systemu bazy danych, a nie tylko na pojedynczej tabeli czy widoku. Zarządzanie kontami, użytkownikami i uprawnieniami to typowo administracyjny obszar pracy z bazą. Przykładowo w systemach takich jak Oracle czy podobnych rozwiązaniach administrator może nadawać uprawnienia typu CREATE USER, ALTER USER, DROP USER, CREATE SESSION albo GRANT ANY PRIVILEGE. To właśnie one decydują, kto może utworzyć konto, zmienić hasło użytkownika, nadać rolę lub pozwolić komuś logować się do bazy. Z mojego doświadczenia warto to kojarzyć z zasadą najmniejszych uprawnień: użytkownik dostaje tylko tyle praw, ile faktycznie potrzebuje do pracy. To dobra praktyka branżowa, bo ogranicza skutki pomyłki, włamania albo źle napisanej aplikacji. Przywileje systemowe są więc podstawą bezpiecznej administracji bazą danych i kontroli dostępu na wyższym poziomie.
W tym zagadnieniu łatwo pomylić kilka pojęć, bo wszystkie brzmią trochę jak elementy zabezpieczeń. Atrybuty mogą opisywać cechy użytkownika, konta, kolumny albo obiektu w bazie, ale same w sobie nie są mechanizmem nadawania praw do wykonywania operacji administracyjnych. Nie tworzy się kont użytkowników za pomocą atrybutów i nie nadaje się nimi globalnych uprawnień typu możliwość logowania czy zarządzania innymi kontami. Reguły również nie są właściwą odpowiedzią w tym kontekście. W różnych systemach mogą oznaczać zasady walidacji, polityki bezpieczeństwa, mechanizmy kontroli dostępu albo logikę działania aplikacji, ale pytanie dotyczy konkretnie uprawnień dających możliwość wykonywania operacji na bazie danych. Najczęstszy błąd polega tu na myśleniu, że każda zasada bezpieczeństwa to od razu uprawnienie administracyjne. Przywileje obiektowe są bliżej tematu, ale dotyczą dostępu do konkretnych obiektów, na przykład tabel, widoków, procedur czy sekwencji. Pozwalają wykonać SELECT, INSERT, UPDATE, DELETE albo EXECUTE na wskazanym obiekcie. To ważne, ale nie wystarcza do zarządzania kontami i użytkownikami. Administrator, który ma tylko przywilej SELECT do tabeli, nie powinien przez to móc tworzyć nowych kont. Do takich działań służą przywileje systemowe, bo działają na poziomie całej bazy lub jej konfiguracji. Moim zdaniem to rozróżnienie jest bardzo praktyczne: obiektowe prawa są dla pracy na danych, a systemowe dla administracji i bezpieczeństwa.