Pytaj o działanie, zasób i warunek
Rola „pracownik” mówi niewiele. Jedna osoba przygotowuje oferty, druga obsługuje reklamacje, a trzecia tylko ogląda raporty. Poprawny model dostępu odpowiada na pytanie: kto może wykonać jakie działanie na którym zasobie i pod jakim warunkiem. To bardziej precyzyjne niż jeden przełącznik dający dostęp do całego panelu.
W przykładowej firmie outsourcingowej opiekun powinien widzieć przypisanych klientów, kierownik cały zespół, a klient tylko własne dokumenty. Samo ukrycie pozycji menu nie realizuje tej zasady. OWASP rozróżnia uwierzytelnianie, czyli sprawdzenie tożsamości, i autoryzację, która dotyczy prawa do działania. Zalogowana osoba nie staje się automatycznie uprawniona do każdego rekordu.
Zbuduj małą macierz dostępu
Wypisz działania: odczyt, utworzenie, edycja, usunięcie, zatwierdzenie i eksport. Następnie przypisz im zakres danych. Edycja własnej sprawy jest inną możliwością niż edycja wszystkich spraw organizacji. Warto wyróżnić działania masowe, ponieważ eksport całej bazy może ujawnić więcej niż pojedynczy podgląd, choć oba bywają potocznie nazywane „czytaniem”.
Nie próbuj opisać od razu każdego przyszłego stanowiska. Zacznij od rzeczywistych ról i wyjątków występujących dziś. Nazwy powinny odzwierciedlać zadania, a nie konkretne osoby. Gdy pracownik zmieni dział, aktualizacja dostępu będzie polegała na przypisaniu właściwego zestawu możliwości, a nie szukaniu jego nazwiska w wielu fragmentach programu.
Pilnuj granic między organizacjami
W aplikacji obsługującej wiele firm identyfikator organizacji powinien być częścią kontroli dostępu do danych. Użytkownik nie może sam wybrać dowolnego klienta przez podmianę pola w żądaniu. Dotyczy to list, wyszukiwania, liczników i podpowiedzi, nie tylko pełnego widoku dokumentu. Nawet nazwa cudzej sprawy w autouzupełnianiu jest przekroczeniem granicy.
OWASP opisuje ryzyko bezpośrednich odwołań do obiektów bez odpowiedniej weryfikacji. Losowy identyfikator utrudnia zgadywanie, lecz nie zastępuje sprawdzenia, czy dany dokument należy do zakresu dostępnego użytkownikowi. Testuj tę regułę także w adresach załączników i funkcjach pobierających dane w tle.
Domyślnie nie przyznawaj nowej możliwości
Nowy moduł nie powinien automatycznie stawać się dostępny dla wszystkich dotychczasowych kont. Domyślna odmowa wymusza świadome przypisanie uprawnienia. OWASP zaleca tę zasadę i weryfikację każdego żądania. W praktyce warto mieć wspólne miejsce sprawdzania dostępu, aby kolejny ekran nie wymagał ręcznego odtwarzania całej logiki bezpieczeństwa.
Przy zamawianiu aplikacji w MyTworzymy.pl warto przedstawić macierz ról razem z opisem procesów. Firma obsługuje klientów z całej Polski, a taki dokument umożliwia jednoznaczne uzgodnienia niezależnie od miejsca pracy zespołu. Pozwala też odróżnić wygodę obsługi od dostępu, który byłby zbyt szeroki dla danej odpowiedzialności.
Zdefiniuj zastępstwa i odebranie uprawnień
Urlop, zmiana opiekuna i zakończenie współpracy powinny mieć własne procedury. Zastępstwo może wygasać w określonym terminie. Odebranie roli powinno wpływać na kolejne działania także w już otwartej sesji. Nie można zakładać, że użytkownik sam się wyloguje. Szczególnie ważne są operacje wykonywane przez integracje i zadania w tle, które mogą korzystać z odrębnych poświadczeń.
Zapisuj, kto nadał dostęp, jaki był jego zakres i kiedy go zmienił. Rejestr nie musi zawierać wszystkich danych klienta. Powinien umożliwiać wyjaśnienie decyzji administracyjnej. Dla awaryjnego konta z szerokimi uprawnieniami określ sposób przechowywania, użycia i przeglądu zdarzeń, zamiast udostępniać jedno wspólne hasło wszystkim pracownikom.
Testuj odmowę tak samo starannie jak sukces
Dla każdej istotnej funkcji przygotuj próbę dozwoloną i niedozwoloną. Klient może pobrać swój dokument, ale nie dokument drugiej firmy. Opiekun może zmienić przypisaną sprawę, ale nie zatwierdzić wyjątku finansowego, jeśli nie ma takiej roli. Po odebraniu uprawnienia wcześniejszy adres nie powinien nadal działać. OWASP rekomenduje testy z kontami o różnych zakresach.
W MyTworzymy.pl można omawiać rozwój programu razem z takimi warunkami odbioru, nie ograniczając rozmowy do liczby zakładek. To szczególnie istotne dla firm obsługujących wiele podmiotów z różnych regionów Polski. Przyrost funkcji nie powinien powodować przypadkowego rozszerzania dostępu do informacji innych klientów.
Przeglądaj role po zmianach organizacyjnych
Macierz zatwierdzona podczas wdrożenia z czasem przestaje odpowiadać rzeczywistości. Zaplanuj okresowy przegląd aktywnych kont, ról i integracji. Szukaj nie tylko nieużywanych kont, ale także dostępu nadanego „na chwilę”, który nigdy nie wygasł. Właściciel procesu powinien potwierdzać, że każda możliwość nadal ma uzasadnienie.
Użyteczny system nie zmusza administratora do ręcznego odgadywania zależności. Powinien pokazywać, z czego wynika prawo do działania: roli, przypisania do sprawy czy czasowego zastępstwa. Taka przejrzystość ułatwia korektę błędu bez przyznawania pełnych uprawnień tylko po to, by szybko ominąć zgłoszony problem z dostępem.
Sprawdź również sposób odmowy w interfejsie. Komunikat może wyjaśniać brak możliwości wykonania czynności, ale nie powinien przy okazji ujawniać istnienia prywatnego dokumentu innej firmy. Dobrze zaprojektowana informacja dla użytkownika i szczegółowy zapis dla administratora służą różnym odbiorcom. Nie muszą zawierać identycznego zakresu danych.