Proszę spisać zasoby i akcje, przypisać je do obowiązków służbowych, oddzielić rolę od własności konkretnego rekordu i nadawać najmniejsze niezbędne uprawnienia. Autoryzację należy egzekwować po stronie serwera, wrażliwe akcje audytować, a konta, dostępy tymczasowe i testy zabronionych scenariuszy regularnie weryfikować.
Role i uprawnienia w aplikacji webowej określają, kto może widzieć dane i wykonywać konkretne akcje. Prosty podział na użytkownika i administratora szybko się rozpada wraz z rozwojem. Wsparcie musi mieć wgląd w sprawę bez możliwości zmiany ceny, kierownik zatwierdzać tylko działania swojego zespołu, a zewnętrzny współpracownik mieć dostęp do wybranego projektu przez ograniczony czas.
Bezpieczny model powstaje na podstawie rzeczywistych zadań, własności zasobów i zasady najmniejszych uprawnień. Kontrola musi działać na serwerze przy każdej operacji, a nie tylko ukrywać przycisk w interfejsie. Jednocześnie powinna pozostać zrozumiała dla administratora, testowalna dla zespołu programistów i audytowalna w razie incydentu lub zmian kadrowych.
Modeluj akcje i zasoby przed nazwami ról
Należy zebrać zadania użytkowników i rozłożyć je na zasób, akcję i zakres. Samo uprawnienie do zamówień nie wystarcza; trzeba rozróżnić odczyt, utworzenie, edycję, zatwierdzenie, eksport i anulowanie. Zakresem może być własny rekord, zespół, oddział lub cała organizacja. Taka macierz ujawni zarówno niebezpieczne połączenia uprawnień, jak i brak odpowiedzialności.
Dopiero wtedy należy pogrupować uprawnienia w role odpowiadające rzeczywistej pracy. Nazwa „menedżer” może mieć w różnych działach odmienne znaczenie, dlatego rolę należy uzupełnić opisem i właścicielem. Nie należy tworzyć nowej roli dla każdej osoby. Wyjątki należy rozwiązywać dostępem ograniczonym w czasie lub jasną regułą, w przeciwnym razie model nie będzie możliwy do utrzymania.
- źródło i konkretna dozwolona akcja
- zakres danych własnych, zespołowych lub firmowych
- warunki zatwierdzania i poufności
- odpowiedzialna rola i właściciel uprawnienia
Łącz rolę z własnością i kontekstem
Sama rola często nie wystarcza. Redaktor może edytować tylko przydzielone projekty, a klient tylko własne zamówienia. Serwer weryfikuje więc także powiązanie użytkownika z konkretnym obiektem, organizacją i stanem. Jeśli rekord został zatwierdzony, ta sama rola może już nie mieć prawa zmieniać ceny. Reguły kontekstowe proszę dokumentować jako część procesu domenowego.
Należy unikać autoryzacji opartej na danych od klienta, na przykład na przesłanym ID organizacji bez serwerowej weryfikacji członkostwa. Każde zapytanie i mutacja muszą korzystać z zaufanego kontekstu tożsamości. Przy operacji zbiorczej trzeba sprawdzać każdy cel lub bezpiecznie ograniczoną kolekcję, a nie tylko pierwszy rekord.
Zaprojektuj administrację i dostęp tymczasowy
Administrator musi widzieć, dlaczego użytkownik ma określone uprawnienie, kto je przyznał i do kiedy obowiązuje. Krytyczne role należy przydzielać w ramach zatwierdzonego procesu i chronić uwierzytelnianiem wieloskładnikowym. Domyślna rola nowego konta powinna być minimalna. Zaproszenie, zmiana zespołu i dezaktywacja muszą aktualizować dostęp bez ręcznej ingerencji w bazę danych.
Dział wsparcia może potrzebować tymczasowego wglądu w stan konta klienta lub działania w jego imieniu. Taką możliwość należy technicznie ograniczyć, ograniczyć w czasie, wyraźnie oznaczyć i objąć audytem. Wrażliwa operacja może wymagać dodatkowego potwierdzenia. Nie należy udostępniać hasła klienta ani uniwersalnego konta administratora, które uniemożliwia przypisanie działania konkretnej osobie.
Egzekwuj reguły na serwerze i audytuj wrażliwe działania
Interfejs może ukryć niedozwolony przycisk, ale serwer musi odrzucić bezpośrednie żądanie. Autoryzację umieść w wielokrotnie używanej warstwie blisko operacji domenowej, aby nie została pominięta w nowym endpoincie lub zadaniu wsadowym. Odpowiedź nie powinna ujawniać istnienia cudzego wrażliwego obiektu bardziej, niż to konieczne.
Wpis audytowy przy istotnej zmianie zawiera wykonawcę, akcję, obiekt, czas, bezpieczny powód i wynik. Nie należy niepotrzebnie przechowywać całej wrażliwej treści. Log należy chronić przed modyfikacją przez zwykłego administratora i ustawić retencję zgodnie z ryzykiem i obowiązkami. Audyt pomaga w dochodzeniu, ale nie zastępuje prewencji.
Testuj zabronione ścieżki i regularnie weryfikuj uprawnienia
Testy automatyczne obejmują zarówno dozwoloną, jak i zabronioną akcję dla każdej wrażliwej kombinacji roli, własności i stanu. Warto spróbować zmienić ID w URL, użyć starego zaproszenia, bezpośrednio wywołać API i wykonać operację zbiorczą z jednym cudzym rekordem. Test regresyjny należy dodawać przy każdym incydencie lub nowej regule.
Należy regularnie sprawdzać aktywne konta, kluczowe role, tymczasowe wyjątki i tożsamości techniczne. Odejście pracownika lub zamknięcie projektu musi uruchamiać odebranie dostępu. Warto monitorować nietypowe odmowy i zmiany ról, ale alarmy interpretować w kontekście. Model należy aktualizować wraz z procesem, a nie dopiero wtedy, gdy stara rola zaczyna oznaczać wszystko.
- dozwolony scenariusz dla każdej roli roboczej
- odmowa dostępu do cudzego zasobu
- wygasłe zaproszenie i dezaktywowany użytkownik
- przegląd tymczasowych i uprzywilejowanych uprawnień
- audyt każdej zmiany krytycznej roli
Najczęstsze pytania
Jaka jest różnica między rolą a uprawnieniem?
Uprawnienie zezwala na konkretną akcję na zasobie. Rola grupuje uprawnienia według obowiązków służbowych. Rzeczywisty dostęp może dodatkowo zależeć od własności, organizacji i stanu rekordu.
Czy wystarczy ukryć niedozwoloną funkcję w interfejsie?
Nie. Ukrycie poprawia użyteczność, ale klienta można obejść. Serwer musi przy każdej operacji weryfikować tożsamość, uprawnienia i kontekst obiektu docelowego.
Czy wsparcie powinno mieć konto administratora?
Tylko uprawnienia niezbędne do wsparcia, najlepiej tymczasowe i audytowane. Uniwersalne współdzielone konto administratora zwiększa skutki błędu i uniemożliwia ustalenie odpowiedzialności za konkretne działanie.
Źródła i dalsza lektura
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
