System Softlab ERP oferuje dwa alternatywne systemy uprawnień: tzw. stary system praw oraz nowy (kontraktowy). Niniejszy artykuł porównuje oba systemy i przedstawia argumenty przemawiające za przejściem do nowego systemu praw.

Potrzeba biznesowa

W obecnym świecie praktycznie nie jest już możliwe prowadzenie działalności gospodarczej bez wspierającego ją systemu informatycznego. A im większa działalność, tym bardziej skomplikowany system jest potrzebny. W szczególności kadra zarządzająca potrzebuje systemu ERP, aby uzyskiwać wiarygodne i aktualne informacje o sytuacji przedsiębiorstwa i stanie jego zasobów. Bez nich nie jest w stanie podejmować właściwych decyzji biznesowych.

Systemy ERP pomagają zarządzać zasobami przedsiębiorstw. Aby móc nimi zarządzać, trzeba znać ich jakość i stan i posiadać narzędzia, które mogą na nie wpływać. Tych informacji i narzędzi dostarcza system informatyczny.

Ale jest to narzędzie obusieczne: w niewłaściwych rękach może stanowić zagrożenie dla przedsiębiorstwa. Jak wynika z raportu „Report to the Nations on Occupational Fraud and Abuse” (Association of Certified Fraud Examiners, Report to the Nations 2018 Global Study on Occupational Fraud and Abuse) opublikowanego w 2018 roku przez organizację ACFE, przedsiębiorstwa straciły średnio 5% przychodów w wyniku nadużyć. Najczęstszą przyczyną jest nieodpowiednia kontrola dostępu, w tym nadawanie zbyt szerokich uprawnień, upraszczanie procedur zatwierdzeń lub wręcz brak kontroli dostępu. Wg tego raportu aż 70% nadużyć zostało popełnionych przez pracowników na szczeblu kierowniczym, którzy często posiadają dość szerokie uprawnienia w systemie ERP.

Ze względu na złożoność współczesnych systemów ERP indywidualne zarządzanie uprawnieniami nie wchodzi w rachubę ze względów praktycznych, byłaby to zbyt żmudna i pracochłonna praca, niemożliwa do podtrzymania w dłuższym okresie. Dlatego systemy ERP centralizują zarządzanie uprawnieniami w formie tzw. systemu uprawnień.

Ograniczenia na dziś – co chcemy usprawnić

System Softlab ERP od początku swojego istnienia oferuje system uprawnień. W pierwszej wersji został on zaprojektowany jako centralne repozytorium: za pomocą jednego słownika nadajemy uprawnienia w całym systemie. Było to wygodne rozwiązanie na początku, gdy system nie był jeszcze bardzo skomplikowany.

Z czasem system Softlab rozrósł się, powstały nowe moduły, a w istniejących modułach nowe funkcjonalności. Zwiększyła się też skala wdrożeń. Te zmiany obnażyły pewne wady starego systemu praw, które zaczęły coraz bardziej doskwierać.

Zaistniała potrzeba wprowadzenia gruntownych zmian w systemie uprawnień. Pojawiły się wówczas dwa pomysły: modyfikować już istniejący system praw lub zaprojektować nowy system praw od początku. Ostatecznie zdecydowano się na drugie rozwiązanie, czyli utworzenie od podstaw nowego systemu praw. Nowy system miał przede wszystkim poprawiać ograniczenia i wady starego. Miał być również łatwo skalowalny w przyszłości, intuicyjny oraz uwzględniać uwagi klientów zebrane na przestrzeni lat funkcjonowania starego systemu.

Jakie wady starego systemu miał naprawić nowy system uprawnień?

Po pierwsze, centralne repozytorium uprawnień w praktyce okazało się mało przyjazne dla administratorów. Mnogość opcji skumulowanych w jednym miejscu i brak możliwości grupowania ich sprawiały, że trudno było się tego mechanizmu nauczyć i go stosować. Popełniano przy tym wiele błędów, co było groźnym zjawiskiem, gdyż oznaczało albo nieuprawniony dostęp, albo brak potrzebnego dostępu. Takie błędy musiały być naprawiane w trybie serwisowym.

Po drugie, stary system nie dało się prekonfigurować. Oznaczało to, że na nowych wdrożeniach uprawnienia trzeba konfigurować zawsze od początku, co zajmowało dużą ilość czasu.

Po trzecie, wraz z pojawieniem się systemu zarządzania zmianą zaistniała potrzeba skryptowania zmian w konfiguracji praw i dostarczania ich do różnych środowisk (deweloperskie, testowe, produkcyjne). Tego stary system nie potrafił dostarczyć.

Po czwarte, administrator systemu uprawnień nie powinien być zdefiniowany jako użytkownik o uprawnieniach sysadmin na serwerze bazy danych ze względów bezpieczeństwa.

Jako dodatkowe założenie przyjęto, że przejście ze starego systemu uprawnień na nowy powinno być możliwie jak najprostsze, a w razie wystąpienia nieprzewidzianych problemów powinna istnieć możliwość szybkiego powrotu do starej wersji.

Jak to usprawniliśmy

Zrezygnowano z podejścia centralnego w konfiguracji praw. W nowym podejściu prawa są konfigurowane w kontekście słownika lub rejestru, na którym aktualnie pracuje użytkownik. Technicznie zostało to rozwiązane poprzez dodanie do każdego słownika i rejestru specjalnego szczegółu Administracja uprawnieniami.

Rys. 1. Nowy system uprawnień: nadawanie uprawnień dla rejestru zamówień od odbiorców

Rys. 2. Stary system uprawnień: centralne repozytorium nadawania uprawnień

W starym systemie uprawnień, prawa nadawane były w kontekście operatorów systemu lub w kontekście elementów hierarchii organizacyjnej firmy. Oznaczało to, że każde wdrożenie musiało zaczynać konfigurację praktycznie „od zera”. W nowym systemie istnieją tzw. funkcje praw, które są kontenerami zawierającymi zbiór uprawnień. I to jest siła nowego systemu uprawnień. Możliwe jest zebranie w funkcji praw uprawnień do funkcjonalności, a potem można grupowo nadawać uprawnienia użytkownikom przypisując im tę funkcję praw. Co więcej, można zdefiniować funkcję praw, która zbiera uprawnienia pozwalające zrealizować proces w systemie, czyli definiujące rolę użytkownika. Przypisanie takiej funkcji użytkownikowi da mu dostęp do procesu. System standardowo dostarcza wiele funkcji praw, które mogą być od razu wykorzystane lub dostosowane do potrzeb klienta na wdrożeniu.

Rys. 3. Prekonfigurowane ustawienia systemu uprawnień

W starym systemie uprawnień nie można skryptować zmian wprowadzonych w konfiguracji uprawnień. Nowe podejście umożliwia wygenerowanie skryptu SQL, który następnie można umieść w systemie zarządzania zmianą. W ten sposób raz utworzona konfiguracja uprawnień może być łatwo dostarczona na inne warianty środowiska pracy (np. baza testowa, baza produkcyjna). To rozwiązanie jest zalecane szczególnie tam, gdzie został wdrożony system zarządzania zmianą. Pozwala on na skrócenie czasu dostarczania zmian w zakresie konfiguracji praw.

Rys. 4. Generowanie skryptu SQL zawierającego konfigurację uprawnień

System ERP może uruchamiać systemy uprawnień w zależności od konfiguracji, część użytkowników może działać w starym systemie praw, a pozostali w nowym. W ten sposób na czas testów i weryfikacji poprawności konfiguracji nowego systemu można wyznaczyć kluczowych użytkowników, którzy będą działać w nowym systemie praw i jednocześnie testować rozwiązania nie utrudniając pracy pozostałym użytkownikom. W razie wystąpienia jakichkolwiek problemów istnieje szybka możliwość powrotu do starego systemu praw.

Rys. 5. Włączanie/wyłączanie nowego systemu uprawnień

Rys. 6. Przyłączanie indywidualnych użytkowników do nowego systemu praw

W starym systemie uprawnień administrator aplikacji musiał być jednocześnie użytkownikiem o uprawnieniach sysadmin na serwerze, co często było w sprzeczności z polityką bezpieczeństwa. W nowej wersji systemu praw administrator systemu nadający uprawnienia nie potrzebuje uprawnień sysadmin.

Jakich korzyści dostarcza ww. opisana funkcjonalność?

1. Zmniejszenie pracochłonności konfiguracji praw (wykorzystanie funkcji praw).
2. Możliwość skryptowania zmian:
   1. idealne rozwiązanie dla systemu zarządzania zmianą,
   2. konfigurację i testy nowego systemu praw można wykonać na bazie testowej, a potem przenieść zmiany za pomocą skryptu wygenerowanego automatycznie przez aplikację.
3. Predefiniowane ustawienia ułatwiające i przyspieszające konfigurację.
4. Możliwość działania w trybie hybrydowym – część użytkowników może działać w starym systemie, a reszta w nowym.
5. Możliwość szybkiego włączania i wyłączania trybu działania w nowym lub starym systemie uprawnień.
6. Większe bezpieczeństwo: konto administratora systemu praw nie musi posiadać uprawnień sysadmin serwera bazy danych.

Artykuł powiązany: System uprawnień – kontrola dostępu do danych

Autor wpisu: Krzysztof Fiutek