Role wynikają z odpowiedzialności.
Zanim dodamy logowanie, ustalamy zadania poszczególnych osób. Klient przegląda własną sprawę, pracownik wykonuje przydzieloną pracę, kierownik potwierdza odbiór, a administrator zarządza dostępem. Sama nazwa „konto firmowe” nie wyjaśnia jeszcze, kto powinien widzieć konkretną informację.
W firmie budowlanej wykonanie zadania i zamknięcie po odbiorze mogą należeć do różnych osób. W salonie klient sprawdza saldo pakietu, ale korekta rozliczenia wymaga uprawnienia obsługi. Projektowanie ról zaczyna się od tych decyzji, nie od uniwersalnego podziału na użytkownika i administratora.
Przygotuj listę działań: podgląd, dodanie, zmiana, akceptacja i usunięcie. Dla każdego wskaż odpowiedzialną rolę oraz zakres spraw. To praktyczny materiał do rozmowy, który nie wymaga technicznego opisu zabezpieczeń.
Dostęp obejmuje działanie oraz konkretną sprawę.
Pracownik może mieć prawo do zmiany statusu, ale tylko w swoich zleceniach. Kierownik widzieć jeden oddział, a właściciel kilka lokalizacji. Dlatego sprawdzamy zarówno rodzaj działania, jak i powiązanie użytkownika z danymi, na których chce je wykonać.
Znajomość identyfikatora nie powinna sama przyznawać dostępu. Klient nie może podejrzeć cudzej rezerwacji przez zmianę adresu. Zasada musi działać w warstwie serwerowej, a nie wyłącznie przez ukrywanie linków lub przycisków w przeglądarce.
OWASP zaleca domyślne odrzucanie nieprzyznanego dostępu oraz sprawdzanie go dla żądań w Authorization Cheat Sheet. Te wskazówki pomagają określić reguły; poprawność wymaga odpowiednich testów gotowej implementacji.
Zbieramy informacje potrzebne do zadania.
Jeśli aplikacja służy do zapisu na zajęcia, trzeba określić dane potrzebne do obsługi zapisu. Nie każde pole z istniejącego arkusza musi trafić do nowego formularza. Nadmiar informacji komplikuje działanie i zwiększa zakres odpowiedzialności za ich przechowywanie.
Dla pracownika ważne mogą być termin, miejsce i opis zlecenia, a nie pełna historia klienta. W raporcie kierownika mogą wystarczyć dane zbiorcze. Projektujemy widoki według rzeczywistej potrzeby, zamiast pokazywać każdemu wszystko, co znalazło się w systemie.
Firma określa także zasady przechowywania i usuwania informacji, z odpowiednią weryfikacją wymagań dla swojej działalności. Ten poradnik opisuje projekt produktu, nie daje oceny prawnej. Przykładowe dane naszych podglądów nie są bazą klientów ani dokumentacją rzeczywistych osób.
Ważne potwierdzenie ma określony zakres.
Akceptacja powinna wskazywać, co użytkownik zatwierdził. W kosztorysie liczą się pozycje i suma, a w zleceniu sprzątania powierzchnia oraz dodatki. Jeśli te informacje się zmienią, wcześniejsze potwierdzenie nie powinno automatycznie obejmować nowej wersji.
Ustalamy, kto może cofnąć decyzję i jak zachować historię. Korekta wpisu w pakiecie salonu przywraca właściwą usługę, a odbiór zadania budowlanego kończy określony etap. Uniwersalny przycisk „zatwierdź” bez znaczenia dla procesu utrudnia późniejsze wyjaśnienie sprawy.
W podglądzie warsztatu zmiana kosztorysu cofa akceptację. Produkcyjna aplikacja potrzebuje jeszcze tożsamości użytkownika, zapisu i odpowiedniej historii. Interakcja na lokalnych danych nie zastępuje rzeczywistego potwierdzenia klienta.
Historia pomaga wyjaśnić zmianę.
Ważne operacje można zapisywać z informacją, kto, kiedy i co zmienił. Pozwala to wyjaśnić korektę salda, przełożenie wizyty lub zamknięcie sprawy. Zakres historii dobieramy do produktu; nie wszystkie czynności wymagają identycznej ilości szczegółów.
Sam dziennik nie zastępuje kontroli dostępu. Musi mieć właściwe uprawnienia i nie powinien bez potrzeby kopiować wszystkich poufnych pól. Warto określić, które informacje są potrzebne obsłudze, a które dotyczą tylko diagnozy technicznej w odpowiednim środowisku.
W firmie z rotacją pracowników potrzebny jest również proces odebrania dostępu. Usunięcie osoby z listy zespołu nie musi oznaczać natychmiastowego zamknięcia wszystkich sesji w źle zaprojektowanym systemie. Ten przypadek powinien mieć własne wymaganie i test.
Testujemy także to, czego rola nie może zrobić.
Przy odbiorze próbujemy poprawnych działań każdej roli oraz prób bez uprawnienia. Klient nie zmienia cudzej sprawy, pracownik nie zatwierdza zadania kierownika, a konto po odebraniu dostępu nie wykonuje kolejnej operacji. Test odnosi się do konkretnych reguł firmy.
Dodatkowo sprawdzamy zmianę powiązań: przeniesienie pracownika do innego oddziału, nowego opiekuna sprawy i powrót do wcześniejszego widoku. Działanie powinno opierać się na aktualnych uprawnieniach, a nie przypadkowo zachowanym stanie ekranu.
W rozmowie o aplikacji opisz role, zakres danych i ważne akceptacje. Na tej podstawie przygotowujemy zakres interfejsu, zapisu i testów. Nie deklarujemy pełnego bezpieczeństwa produktu na podstawie samej obecności logowania albo wyniku pojedynczego skanera.
Przykład: pracownik, koordynator i administrator.
W przykładowej firmie serwisowej pracownik widzi przydzielone zlecenia i dopisuje wynik wizyty. Koordynator ustala termin, przydziela osoby i potwierdza zakończenie. Administrator zarządza dostępem, ale jego konto nie musi służyć do codziennej obsługi klientów. Dla każdej roli zapisujemy dozwolone działanie i zakres spraw.
Pracownik: własne przydzielone zlecenia; opis wykonania oraz zdjęcia przewidziane w zakresie. Bez zmiany kosztorysu po akceptacji klienta.
Koordynator: sprawy danego oddziału; terminy, przydział oraz odbiór wykonania. Działania w innych oddziałach wymagają odrębnego uprawnienia.
Administrator: nadawanie i odbieranie ról według uzgodnionych reguł. Ważne zmiany dostępu powinny mieć określoną odpowiedzialność i zapis potrzebny do wyjaśnienia działania.
Przy odbiorze sprawdzamy próby dozwolone i niedozwolone. Pracownik powinien móc zapisać wynik własnej wizyty, ale nie podejrzeć cudzej sprawy przez zmianę jej numeru. Odebranie dostępu wymaga weryfikacji istniejącej sesji. Plan tych prób łączy zadania firmy z regułami dostępu; gotowa implementacja wymaga właściwej kontroli.
Jaką decyzję podjąć dalej?
Jeżeli w obiegu uczestniczy podwykonawca, przeczytaj Dostęp partnera do aplikacji: jak ograniczyć go do właściwej sprawy?.
Dla pracy kilku osób na jednym stanowisku zobacz Wspólny tablet pracowników: jak rozdzielić użytkowników i zadania?.
Od decyzji do zakresu wykonania.
Zakres związany z tą decyzją opisujemy na stronie Systemy dla firm.
Praktyczny kontekst znajdziesz w opisie Aplikacja dla biura rachunkowego. To możliwy zakres dla branży, który dobieramy do konkretnej firmy.