Role i uprawnienia w aplikacji firmowej: od obowiązków do reguł dostępu

Pracowniczka działu obsługi widzi w aplikacji wszystkie umowy klientów, choć w codziennej pracy potrzebuje tylko statusu swojej sprawy. Ktoś kiedyś nadał jej szeroki dostęp, żeby zdążyć z wdrożeniem. Od tego czasu zespół urósł, zmieniły się obowiązki, a ustawienia zostały. To przykład problemu projektowego: konto odpowiada na pytanie, kto się zalogował, ale samo nie rozstrzyga, co ta osoba może zrobić i z jakimi danymi.

Uprawnienia dobrze projektuje się od konkretnych zadań. Kto zakłada sprawę? Kto widzi dokument, poprawia dane albo zatwierdza zmianę? Czy kierownik może działać we wszystkich oddziałach, czy tylko w swoim? Odpowiedzi tworzą reguły, które można sprawdzić przed wdrożeniem. Nie trzeba zaczynać od długiej listy technicznych nazw ról. Trzeba wiedzieć, jaka praca ma zostać wykonana i gdzie kończy się odpowiedzialność osoby wykonującej zadanie.

W tym artykule używamy hipotetycznych przykładów z obsługi spraw, sprzedaży i pracy terenowej. Każdy pomaga przećwiczyć inną decyzję. Rzeczywiste zasady dostępu ustala się dla danych, zespołu i procesu konkretnej firmy. Dobrze przygotowany projekt powinien pozwolić wyjaśnić zarówno przyznanie dostępu, jak i jego brak osobie, która nie uczestniczyła w pierwszym spotkaniu z wykonawcą.

Zapisz czynności, zanim nazwiesz role

Zacznij od przejścia przez sprawę od początku do końca. W hipotetycznej firmie serwisowej koordynator przyjmuje zgłoszenie, technik dopisuje wynik wizyty, a osoba rozliczająca przygotowuje dokument dla klienta. Każda z tych osób potrzebuje części wspólnego obrazu, ale niekoniecznie tych samych działań. Technik może potrzebować adresu urządzenia i historii napraw, bez prawa do zmiany warunków handlowych. Osoba rozliczająca może potrzebować potwierdzenia wykonania, bez edycji notatek technicznych.

Dla każdej czynności zapisz obiekt i skutek. „Obsługa zgłoszeń” jest nazwą obszaru, nie regułą dostępu. Znacznie bardziej użyteczne jest zdanie: „Technik może dodać wynik do zlecenia przypisanego jego zespołowi, ale nie może usunąć wcześniej zatwierdzonego rozliczenia”. Taki zapis ujawnia, jakich danych dotyczy decyzja, kto ją podejmuje i czy przynależność do zespołu ma znaczenie. Pozwala też poprosić pracownika o potwierdzenie, czy opis odpowiada codziennej pracy.

Warto porozmawiać również o czynnościach rzadkich. Zastępstwo podczas urlopu, pomyłka w adresie czy pilna interwencja poza obszarem zwykłej pracy potrafią zburzyć tabelę przygotowaną wyłącznie dla spokojnego dnia. Nie muszą prowadzić do utworzenia roli „wszystko dla wszystkich”. Mogą oznaczać wskazaną osobę zastępującą, czasowy dostęp albo ścieżkę decyzji kierownika. Zanim wybierzecie mechanizm, obejrzyjcie kilka takich sytuacji z osobami, które naprawdę je obsługują. Przygotowanie tych rozmów przypomina pracę nad prototypem sprawdzanym z pracownikami: cenna jest informacja o tym, co faktycznie się dzieje, a nie tylko o tym, co powinno się dziać według schematu.

Sprawdź też, co zobaczy nowa osoba przed przypisaniem jej pierwszego zakresu. Konto bez jednostki nie powinno przypadkiem ujawniać spraw wszystkich oddziałów. Ustalcie, kto nadaje przydział i w jakiej kolejności konto staje się aktywne.

Oddziel rolę od zakresu danych

Rola jest wygodną nazwą zestawu możliwości, na przykład „koordynator serwisu”. Nie odpowiada jednak automatycznie na pytanie, które sprawy ten koordynator może zobaczyć. W organizacji z kilkoma oddziałami dwie osoby o tej samej roli mogą pracować na różnych listach klientów. W systemie potrzebne bywają więc zarówno uprawnienia do czynności, jak i ograniczenie zakresu danych. To rozróżnienie staje się szczególnie praktyczne, gdy system ma obsługiwać wiele oddziałów bez mieszania ich codziennych spraw.

Przy ustalaniu zakresu sprawdź widok listy, szczegóły rekordu, załączniki, wyszukiwarkę, powiadomienia i eksport. Każde z tych miejsc może odsłonić informację. Jeśli pracownik nie może otworzyć dokumentu, ale otrzymuje jego pełną treść w wiadomości albo pobiera go z eksportu, ograniczenie nie realizuje założonego celu. Nie oznacza to, że wszystkie elementy muszą działać identycznie. Oznacza, że trzeba je świadomie opisać i sprawdzić jako części jednego procesu.

Zwróć uwagę na dane pochodne. Liczba otwartych spraw, nazwa klienta w podpowiedzi i historia ostatnich działań mogą być przydatne, ale w pewnym kontekście ujawniają więcej, niż zakładał projekt. Na etapie rozmowy wystarczy wskazać pytania: co dokładnie widać, komu i po jakiej czynności? W wyszukiwarce firmowych dokumentów z RAG podobny problem pojawia się przy wynikach wyszukiwania i cytatach. Ograniczenie dostępu do pliku powinno mieć sens także dla odpowiedzi, która korzysta z jego treści.

Jeśli kilka aplikacji ma korzystać ze wspólnego uwierzytelniania, przeczytaj o jednym logowaniu SSO. Rozpoznanie osoby nie zastępuje sprawdzenia jej uprawnień w każdej aplikacji.

Widoczność przycisku nie jest zabezpieczeniem

Interfejs może ukrywać działania niedostępne dla zalogowanej osoby. To pomaga w pracy, bo użytkownik nie musi oglądać przycisków, których nigdy nie użyje. Decyzja o dostępie nie powinna jednak kończyć się na wyglądzie ekranu. Serwer obsługujący żądanie musi sprawdzić, czy dana osoba rzeczywiście może wykonać operację na wskazanym obiekcie. OWASP zaleca kontrolowanie uprawnień dla każdego żądania oraz projektowanie dostępu tak, by odmowa była domyślnym wynikiem, gdy brakuje wyraźnej podstawy do jego przyznania.

Przykład pokazuje różnicę. Koordynatorka może otworzyć przypisane jej zlecenie pod adresem zawierającym identyfikator sprawy. Zmiana tej wartości w żądaniu nie powinna pozwolić jej zobaczyć dokumentu z innego zespołu tylko dlatego, że zna lub odgadła numer. Sprawdzenie musi uwzględnić osobę, czynność i konkretny rekord. Podobny problem dotyczy operacji wykonywanych automatycznie. W integracji przez API lub webhook konto techniczne również powinno mieć określony zakres dostępu, a nie bezterminowy zestaw uprawnień administratora tylko dlatego, że jest wygodny podczas pierwszego testu.

Błędy dostępu trzeba przy tym komunikować rozsądnie. Osoba obsługująca sprawę powinna wiedzieć, że nie może wykonać danej czynności i do kogo zgłosić potrzebę zmiany. Komunikat dla użytkownika nie musi ujawniać technicznej konfiguracji systemu ani szczegółów o danych, do których nie ma dostępu. Oddziel informację pomocną w pracy od szczegółów potrzebnych administratorowi do wyjaśnienia zdarzenia. To również element projektowania interfejsu, nie tylko konfiguracja zabezpieczeń.

Zaplanuj nadawanie, zmianę i odebranie dostępu

Projekt uprawnień zaczyna działać naprawdę wtedy, gdy pojawia się zmiana w zespole. Nowa osoba potrzebuje konta i sprawdzonego zestawu możliwości. Przy zmianie stanowiska poprzednie uprawnienia mogą już nie być potrzebne. Po zakończeniu współpracy dostęp powinien zostać odebrany zgodnie z ustaloną procedurą. Warto ustalić, kto inicjuje każdą z tych zmian, kto ją zatwierdza i jak sprawdza się jej wykonanie. Zadanie „dział IT zajmie się dostępami” jest dobrym początkiem rozmowy, ale nie opisuje jeszcze kolejnych kroków.

Osobną sytuacją jest praca tymczasowa: zastępstwo, projekt między zespołami albo wsparcie wykonawcy. Dla takiego dostępu ustal zakres, osobę odpowiedzialną i moment ponownego sprawdzenia. Termin może wynikać z daty zakończenia zadania, ale sama data nie rozwiązuje wszystkiego. Jeśli projekt się przedłuży, ktoś powinien podjąć nową decyzję. Jeśli skończy się wcześniej, potrzebna jest możliwość odebrania dostępu bez czekania na koniec pierwotnego okresu.

Lista kont technicznych zasługuje na podobny przegląd. Aplikacja może łączyć się z systemem księgowym, usługą wysyłki i repozytorium dokumentów. Każde połączenie ma właściciela, określone zadanie i sposób cofnięcia dostępu. Przy przejmowaniu kodu, kont i dokumentacji poproście o wykaz tych zależności. Dzięki temu zmiana wykonawcy nie zacznie się od poszukiwania konta, którego nazwa brzmi jak żart zespołu sprzed kilku lat.

Sprawdź wyjątki i ryzyko łączenia uprawnień

Niektóre czynności zmieniają wagę, gdy jedna osoba może wykonać je wszystkie. Ktoś może przygotować nowego odbiorcę płatności, zatwierdzić zmianę i uruchomić przelew. W innym procesie ta sama osoba tworzy ofertę oraz samodzielnie zmienia warunki poza zwykłymi limitami. Przedstaw te kombinacje właścicielowi procesu i zapytaj, czy potrzebna jest dodatkowa akceptacja. Nie każda organizacja ma ten sam podział zadań, więc decyzja powinna wynikać ze skutków operacji i rzeczywistej obsady zespołu.

Zgoda przełożonego ma sens, gdy wiadomo, czego dotyczy. Powinna wskazywać sprawę, proponowaną zmianę i osobę uprawnioną do jej zatwierdzenia. Jeżeli po wysłaniu prośby zmienią się istotne dane, system może wymagać ponownej oceny nowej wersji. Ten sam problem opisujemy przy zatwierdzaniu działań agenta AI: potwierdzenie musi odnosić się do konkretnego działania. Rola osoby zatwierdzającej nie powinna być jedynie ozdobną nazwą na ekranie.

Szczegółowa macierz uprawnień pomaga pokazać te zależności. Może mieć wiersze odpowiadające czynnościom, kolumny dla ról oraz dopisek opisujący zakres danych. Zapisz również, co dzieje się po odmowie, kto może przydzielić zastępstwo i jak obsłużyć pomyłkę. Dokument nie musi przypominać instrukcji obsługi elektrowni. Ma umożliwić zespołowi porównanie ustaleń z działającym systemem i zauważenie brakującego wyjątku przed pierwszą prawdziwą sprawą.

Przetestuj dostęp na konkretnych kontach i danych

Do prób przygotuj co najmniej dwa konta o różnych zakresach i przykładowe sprawy przypisane do różnych zespołów. Sprawdź podstawową pracę: otwarcie listy, wyszukanie rekordu, dodanie informacji oraz wykonanie dozwolonej operacji. Następnie sprawdź próby dostępu do obcej sprawy, eksportu, załącznika i historii zmian. Ważny jest nie tylko komunikat w przeglądarce. Weryfikacja powinna objąć również odpowiedź serwera oraz rzeczywisty stan danych po próbie.

Uwzględnij zmianę sytuacji w trakcie sesji. Pracownik może stracić dostęp po przeniesieniu do innego zespołu, a konto integracyjne może mieć odebrane prawo do zapisu. Ustalcie oczekiwane zachowanie i warunki, w których nowa decyzja o uprawnieniu ma zostać zastosowana. Próba powinna także pokazać, czy użytkownik może dalej zobaczyć dane zapisane wcześniej na urządzeniu. Sposób obsługi lokalnych kopii zależy od architektury i zasad projektu, dlatego nie warto obiecywać jednego zachowania dla wszystkich aplikacji.

Takie przypadki wpisz do kryteriów odbioru aplikacji razem z osobą odpowiedzialną za ocenę. Przy przeglądzie ograniczeń asystenta przydają się także zasady z artykułu o testowaniu asystenta AI: pozytywna odpowiedź nie wystarczy, potrzebne są przykłady, przy których poprawnym wynikiem jest odmowa. To praktyczny sposób sprawdzenia granicy, którą wcześniej uzgodniliście na papierze.

Osoba z odpowiednim uprawnieniem musi jeszcze móc wykonać swoje zadanie. Przy projektowaniu ekranów zapoznaj się także z zasadami tworzenia dostępnego formularza firmowego, który można obsłużyć klawiaturą i czytnikiem ekranu.

Przygotuj brief o dostępie do danych

Do rozpoczęcia projektu nie jest potrzebna idealna tabela wszystkich uprawnień. Przygotuj opis kilku ról, jedną reprezentatywną sprawę i listę danych, które pojawiają się na kolejnych etapach. Zaznacz, gdzie występują różne oddziały, zewnętrzni współpracownicy i decyzje wymagające zatwierdzenia. Dopisz sytuacje, w których obecny sposób nadawania dostępu powoduje zwłokę albo daje ludziom informacje, których nie potrzebują. To wystarczy, by wspólnie wskazać pierwsze pytania i granice dalszej analizy.

W briefie opisz rodzaje dokumentów i systemów, nie przekazując haseł ani kluczy dostępu. Jeżeli do rozmowy potrzebne są przykładowe dane, ustalcie bezpieczny sposób ich przygotowania i zakres informacji. W projekcie oprogramowania na zamówienie Archifutura może przełożyć te ustalenia na role, reguły dostępu i scenariusze odbiorowe. A jeśli nie masz pewności, od którego procesu zacząć, wyślij krótki opis projektu. Napisz, kto wykonuje pracę i gdzie obecny dostęp pomaga albo przeszkadza. Resztę pytań ustalimy w rozmowie.