Widok do kontroli dostępu

Widok do kontroli dostępu udostępnia wybrane dane bez przyznawania bezpośrednich uprawnień do tabel źródłowych.

Rola widoku w modelu uprawnień

Widok do kontroli dostępu jest obiektem logicznym bazy danych, którego definicja opiera się na zapytaniu zwracającym określone kolumny i wiersze. Użytkownik lub aplikacja otrzymuje dostęp do widoku zamiast bezpośredniego dostępu do tabel źródłowych. Dzięki temu można udostępnić tylko taki zakres informacji, jaki jest potrzebny do wykonania konkretnego zadania. Widok może pomijać kolumny zawierające dane techniczne, identyfikatory wewnętrzne albo inne pola, które nie powinny być prezentowane w danym kontekście.

Przykładowo tabela pracownicy może zawierać identyfikator, imię, nazwisko, stanowisko, wynagrodzenie i dane kontaktowe, natomiast widok przeznaczony dla wybranego odbiorcy może zwracać wyłącznie imię, nazwisko, stanowisko oraz służbowy adres poczty elektronicznej. Uprawnienie odczytu nadaje się wtedy do widoku, a nie do tabeli. Samo utworzenie widoku nie zawsze odbiera wcześniejsze uprawnienia do tabel źródłowych, dlatego konfigurację należy oceniać razem z istniejącymi uprawnieniami użytkowników, ról i grup.

Filtrowanie wierszy i ograniczanie kolumn

Kontrola dostępu za pomocą widoku może obejmować nie tylko wybór kolumn, lecz także filtrowanie rekordów. Warunek w definicji zapytania może ograniczyć wynik do określonego działu, oddziału, statusu albo zakresu danych. Jeżeli widok zawiera warunek typu WHERE status = 'aktywny', odbiorca widzi tylko rekordy spełniające ten warunek, o ile nie ma dodatkowej drogi dostępu do tabeli źródłowej. Takie rozwiązanie jest przydatne, gdy jedna tabela przechowuje dane dla wielu zakresów organizacyjnych, a poszczególne role powinny otrzymywać różne podzbiory informacji.

Widok nie jest jednak automatycznie gwarancją pełnej izolacji danych. Trzeba sprawdzić, czy użytkownik nie może odczytać tabeli innym zapytaniem, przez inny widok, procedurę albo konto techniczne aplikacji. Znaczenie ma także sposób wykonywania widoku przyjęty przez konkretny silnik bazy danych, w tym reguły sprawdzania uprawnień właściciela widoku i użytkownika wywołującego zapytanie. W środowisku, w którym wymagane jest ścisłe rozdzielenie rekordów między użytkownikami, sam filtr w widoku może wymagać uzupełnienia mechanizmem kontroli dostępu na poziomie wierszy, jeżeli dany silnik go obsługuje.

Uprawnienia, modyfikacja i ryzyka obejścia

Typowy schemat konfiguracji polega na utworzeniu widoku, nadaniu roli uprawnienia odczytu do tego widoku oraz odebraniu tej roli bezpośredniego prawa odczytu do tabel źródłowych. W SQL często wykorzystuje się do tego instrukcje CREATE VIEW, GRANT i REVOKE, ale szczegóły składni, nazewnictwo ról oraz reguły dziedziczenia uprawnień zależą od używanego systemu bazodanowego. Przed wdrożeniem należy sprawdzić definicję widoku, listę jego zależności i rzeczywisty efekt zapytań wykonywanych przez konto użytkownika.

Zmiana tabeli źródłowej może zmienić działanie widoku albo spowodować błąd podczas jego użycia. Dotyczy to między innymi usunięcia kolumny, zmiany typu danych, zmiany nazwy obiektu oraz modyfikacji funkcji użytych w zapytaniu. Warto testować widok na koncie o dokładnie takich samych uprawnieniach jak konto aplikacji, ponieważ administrator może uzyskać wynik pozytywny mimo braku uprawnienia wymaganego w normalnym scenariuszu. Należy również kontrolować widoki po zmianach schematu, rejestrować ich definicje w systemie kontroli wersji i okresowo weryfikować, czy zwracają wyłącznie zamierzony zakres danych.

Sprawdzenie widoku w działającej bazie

Diagnostyka widoku do kontroli dostępu powinna rozpocząć się od odczytania jego definicji oraz ustalenia, z jakich tabel, innych widoków i funkcji korzysta. Następnie należy sprawdzić uprawnienia przypisane bezpośrednio użytkownikowi i uprawnienia odziedziczone przez role. Istotne jest wykonanie testów pozytywnych i negatywnych: konto powinno móc odczytać dozwolony widok, ale nie powinno móc odczytać tabel źródłowych ani uzyskać niedozwolonych wierszy przez alternatywny obiekt bazy danych.

Podczas analizy warto porównać wynik widoku z tabelą źródłową, zweryfikować zachowanie dla różnych wartości filtrów i sprawdzić przypadki brzegowe, takie jak brak działu, nieaktywny rekord albo wartość NULL. Trzeba też ocenić wydajność zapytania, ponieważ złożony widok może wykonywać łączenia, sortowanie lub agregacje przy każdym użyciu. W przypadku nieprawidłowego działania serwis techniczny może przeanalizować konfigurację konta, definicję obiektu, błędy zapytań oraz wpływ zmian w schemacie na pracę aplikacji, bez utożsamiania samego widoku z fizycznym plikiem lub podzespołem komputera.