Uprawnienia w aplikacji wewnętrznej ustala się raz i zwykle nigdy nie przegląda. Dlatego warto zaprojektować je tak, by nie wymagały przeglądów.
Konta imienne
Jedno konto na osobę. Konto wspólne uniemożliwia ustalenie, kto wykonał operację, i jest pierwszą rzeczą, która mści się przy każdym sporze.
Wyjątek bywa robiony dla stanowisk zmianowych — jeden komputer w magazynie, kilka osób w ciągu dnia. Rozwiązaniem nie jest wspólne konto, tylko szybkie przełączanie użytkownika, na przykład kodem albo kartą. Logowanie hasłem przy każdej operacji zostanie obejście pierwszego dnia.
Role, nie uprawnienia pojedyncze
Zestaw dostępów przypisany do stanowiska. Nadawanie uprawnień osobno każdemu użytkownikowi rozjeżdża się w ciągu roku i nikt już nie wie, kto co może.
Ról powinno być kilka, nie kilkanaście. Jeśli dla każdej osoby powstaje własna rola, wróciliśmy do uprawnień indywidualnych, tylko pod inną nazwą.
Domyślnie brak dostępu
Nowy użytkownik nie widzi nic, dopóki nie dostanie roli. Odwrotna zasada oznacza, że co jakiś czas ktoś zobaczy dane, których nie powinien.
Ta sama reguła obowiązuje przy dodawaniu nowych funkcji. Nowy ekran domyślnie niedostępny dla wszystkich to jedyny sposób, żeby rozwój aplikacji nie poszerzał uprawnień po cichu.
Zapis zdarzeń
Kto, kiedy i co zmienił. Przy danych finansowych i osobowych to nie luksus, tylko warunek wyjaśnienia jakiejkolwiek nieprawidłowości.
Warto zapisywać także wartość sprzed zmiany i po niej. Sama informacja, że rekord był edytowany, rzadko wystarcza do rozstrzygnięcia sporu. Trzeba przy tym z góry ustalić, jak długo te zapisy przechowujemy, bo rosną szybciej niż same dane.
Odbieranie dostępu
Powiązane z zakończeniem współpracy, nie z pamięcią przełożonego. Konta byłych pracowników są najczęstszą luką w narzędziach wewnętrznych.
Konta się blokuje, a nie usuwa — inaczej znika powiązanie z historią operacji. Dotyczy to również kont partnerów i podwykonawców, gdzie zakończenie współpracy powinno odcinać dostęp jednym działaniem.
Logowanie wspólne z firmowym
Jedno konto do wszystkich narzędzi upraszcza i nadawanie, i odbieranie dostępu. Warto to przewidzieć przed budową, a nie po.
Jeśli firma korzysta z poczty w usłudze, która udostępnia logowanie zewnętrzne, zwykle da się je wykorzystać. Wtedy wyłączenie konta pocztowego automatycznie zamyka dostęp do aplikacji.
Dostęp z zewnątrz
Konta dla klientów rządzą się innymi prawami niż konta pracowników: zakładane samodzielnie, z ograniczonym zakresem danych. Szerzej opisuje to tekst o panelu klienta. Mieszanie obu rodzajów kont w jednym mechanizmie ról kończy się pomyłką, której skutki widać na zewnątrz firmy.
Przegląd
Nawet dobrze zaprojektowane role wymagają okresowego spojrzenia: kto ma dostęp, do czego i czy nadal go potrzebuje. Wystarczy zestawienie użytkowników z rolami, dostępne dla właściciela aplikacji, i wpisanie tej czynności w rytm utrzymania.
