Bezpieczeństwo

• To, co użytkownik może zrobić w IFS Cloud, kształtują przydzielone mu zestawy uprawnień, a zakres dodatkowo zawężają spółka i lokalizacja. Ocena sprawdza łączny skutek tych przydziałów dla każdego użytkownika.
• Macierz rozdziału obowiązków (SoD) wymienia pary czynności, których jedna osoba nie może łączyć, i jest sprawdzana względem zestawów uprawnień, które użytkownicy faktycznie mają.
• Model kilku nazwanych ról biznesowych, każda zbudowana z udokumentowanych zestawów uprawnień, zastępuje nadawanie dostępów przez kopiowanie kolegi.
• Dostajesz katalog ról, macierz SoD, listę konfliktów z kolejnością usuwania oraz procedurę przeglądu, którą zespół wykona bez mojego udziału.
• Nie certyfikuję zgodności. Robi to audytor. Praca daje dowody, o które pyta audytor, w formie, którą można odtworzyć.

Zestawy uprawnień rosnące latami

Zestaw uprawnień utworzony na potrzeby jednego zadania przed uruchomieniem produkcyjnym zostaje po jego zakończeniu, bo żaden element procesu go nie usuwa. Nowych użytkowników zakłada się przez skopiowanie doświadczonego kolegi, więc każda kopia przenosi jego nagromadzone uprawnienia na nową osobę. Po kilku wydaniach i paru reorganizacjach lista zestawów zawiera nakładające się pozycje, których nazwy nie opisują już tego, na co pozwalają.

Konflikty znajduje audytor, nie Ty

Dostęp wynika z przydzielonych zestawów uprawnień i jest zawężany przez spółkę i lokalizację, więc dwa niewinnie wyglądające zestawy mogą razem pozwolić jednej osobie wykonać obie połowy kontroli w obrębie tej samej spółki. Przykładowe pary w macierzy: założenie dostawcy i zatwierdzenie jego płatności, utworzenie zamówienia zakupu i przyjęcie towaru, wprowadzenie faktury dostawcy i jej zatwierdzenie, ustawienie limitu kredytowego klienta i zwolnienie zamówienia zablokowanego kredytowo, zaksięgowanie ręcznego dokumentu księgowego i jego zatwierdzenie. Jeśli nikt nie nałożył tych par na Twoje zestawy uprawnień, pierwsze pełne mapowanie robi zespół audytu, według swojego harmonogramu.

Przeglądy dostępów, których nie da się powtórzyć

Przegląd zbudowany na doraźnym eksporcie i arkuszu odpowiada na pytanie na jeden dzień. W następnym roku zaczyna się od zera, bo reguły, które decydowały o akceptowalności uprawnień, były w głowie osoby prowadzącej przegląd. Powtarzalny przegląd wymaga spisanych zasad: kto jest właścicielem każdej roli, co rola może robić i jakie kombinacje są zakazane.

Koszt otwartego konfliktu: każdy nierozwiązany konflikt wymusza kontrole kompensujące, takie jak ręczne zatwierdzenia i dodatkowe podpisy, które zabierają czas zespołom finansów i zakupów w każdym okresie, aż dostęp zostanie poprawiony u źródła.

Model łatwy w utrzymaniu zaczyna się od ról biznesowych i schodzi do zestawów uprawnień, zamiast zaczynać od pojedynczych użytkowników. Każda rola ma właściciela w biznesie, opisany cel, określony zbiór zestawów uprawnień oraz zapisaną listę czynności, których nie wolno jej dzielić z inną rolą. Nowy pracownik dostaje rolę z katalogu.

Gdy czynności nie da się rozdzielić, bo zespół jest za mały, model zapisuje wyjątek, wskazuje kontrolę kompensującą i przypisuje jej właściciela oraz datę przeglądu. Taki zapis audytor może przetestować.

1. Ocena stanu. Czytam stan obecny: zestawy uprawnień, to, co każdy z nich daje, oraz kto jakie zestawy ma. Wynikiem jest mapa nakładań, nieużywanych zestawów, użytkowników z nietypowo szerokim dostępem i konfliktów istniejących dziś. Dane lub dostęp do odczytu przygotowują Twoi administratorzy; w tej fazie nic się nie zmienia.
2. Projekt ról. Z właścicielami procesów w finansach, zakupach, sprzedaży i magazynie definiujemy role biznesowe i zestawy uprawnień potrzebne każdej z nich. Role opisujemy najpierw językiem biznesu, a dopiero potem mapujemy na IFS.
3. Macierz SoD. Uzgadniamy, które pary czynności są w Twojej organizacji zakazane, a potem testujemy względem nich zaprojektowane role i obecnych użytkowników. Pozostałe konflikty dostają kolejność usuwania, a nieuniknione udokumentowaną kontrolę kompensującą.
4. Rytm przeglądów. Przekazuję procedurę przeglądu: kto przegląda które role, jakie dowody powstają, jak zatwierdza się wyjątki i jak często przegląd się odbywa. Częstotliwość wynika z Twojego kalendarza audytów i tempa zmian stanowisk.

Zmiany w zestawach uprawnień wprowadzają Twoi administratorzy albo ja, najpierw w środowisku testowym, a potem są wdrażane Twoim zwykłym procesem zmian. Na produkcję nic nie trafia wyłącznie z mojej decyzji.

• Raport stanu obecnego: zestawy uprawnień, przydziały i nakładania
• Katalog ról z właścicielem biznesowym, celem i zestawami uprawnień każdej roli
• Macierz rozdziału obowiązków (SoD) dla Twoich procesów
• Lista konfliktów per użytkownik z kolejnością usuwania
• Rejestr kontroli kompensujących dla akceptowanych wyjątków
• Procedura przeglądu dostępów i wzór dowodów
• Omówienie dla audytu wewnętrznego lub zewnętrznego audytora
• Sesja przekazania, po której zespół wykona kolejny przegląd samodzielnie

Zakres zależy od liczby spółek, używanych modułów IFS Cloud i liczby użytkowników. Wycena powstaje po rozmowie zakresowej, a pisemny zakres uzgadniamy przed rozpoczęciem pracy.

• Osoby odpowiedzialne za finanse, IT lub audyt wewnętrzny, które dostały ustalenie dotyczące dostępów lub SoD i potrzebują trwałej naprawy.
• Klienci IFS Cloud przygotowujący się do audytu zewnętrznego lub zmiany audytora.
• Zespoły, które uruchomiły system jakiś czas temu, nie przeprojektowały ról i dziś zakładają użytkowników przez kopiowanie.
• Organizacje dodające spółki, lokalizacje lub moduły, które chcą mieć model ról, zanim dostępy się rozrosną.

To nie jest usługa dla kogoś, kto potrzebuje certyfikacji, testu penetracyjnego albo wdrożenia systemu zarządzania tożsamością. To inne zlecenia i powiem to na rozmowie.

Nazywam się Dariusz Myśliwiec. Pracuję z IFS od 18 lat (Apps 7.5–10 i IFS Cloud). Jestem IFS Certified Associate Consultant i mam certyfikat PRINCE2® 7.

Wybrani klienci z mojej pracy przy IFS: Fugro · LGC · BVI Medical · Betafence (PRÆSIDIAD) · Barlinek · NGK Ceramics · Newag · Oleofarm.