Rozdział obowiązków (SoD) – teoria i praktyka cz.1
Przedsiębiorstwa, w ramach swojego dynamicznego rozwoju zaczynają zauważać potrzebę automatyzacji procesów biznesowych. Dodatkowo, aby zarządzać kluczowymi procesami biznesowymi należy stopniowo zwiększać zaangażowanie poszczególnych pracowników, a przez to również liczbę użytkowników dla systemów wspierających zarządzanie przedsiębiorstwem (np. SAP).
Pracownicy zaczynają wykonywać swoje codzienne obowiązki bezpośrednio korzystając z kont w systemach. Awans, zmiana stanowiska, bądź zwykłe rozszerzenie obowiązków pracownika wiąże się z nadaniem bądź modyfikacją uprawnień w systemie. W organizacji, mającej świadomość rozdziału obowiązków (ang. Segregation of Duties, SoD) przed wykonaniem tego działania powinna zostać przeprowadzona analiza uprawnień (nazywana czasami symulacją). Powodem takiej analizy jest mitygacja jednego z podstawowych ryzyk wewnętrznych dla organizacji – zbyt szerokiego dostępu pojedynczego użytkownika do systemu. Ryzyko tego typu jest najczęściej niewidoczne, ale jego materializacja może mieć realne przełożenie również na kondycję finansową całego przedsiębiorstwa.
Konflikt rozdziału obowiązków (SoD) powstaje, kiedy jeden użytkownik może wykonać w systemie (np. SAP), lub pomiędzy systemami czynności, które z punktu widzenia:
- kontroli wewnętrznej firmy
- bezpieczeństwa procesów w firmie
- dobrych praktyk biznesowych
- regulacji prawnych
Należy jednak mieć świadomość tego, że rozdział obowiązków nie rozwiązuje całkowicie kwestii potencjalnych nadużyć. Jego celem jest minimalizacja ryzyka, ponieważ wymaga ono umowy pomiędzy dwoma lub więcej pracownikami. Trudność ustanowienia takiej umowy i jej utrzymanie w tajemnicy przez długi czas powoduje, że rozdział obowiązków zwiększa szanse na wykrycie tego typu nadużyć występujących wewnątrz organizacji.
Ponadto, należy zdawać sobie sprawę z braku możliwości rozwiązania wszystkich konfliktów rozdziału obowiązków w organizacji (np. z powodu wykonywanych obowiązków lub przyjętej struktury organizacyjnej). W takim celu należy już na etapie budowy matrycy SoD brać pod uwagę wdrożenie odpowiednich mechanizmów kontrolnych – kontroli mitygujących dla danych ryzyk. Kontrole mitygujące powinny być okresowo testowane i monitorowane, w celu zapewnienia efektywnej i skutecznej mitygacji ryzyk SoD.
Stowarzyszenie ISACA*, w ramach swoich najlepszych praktyk przygotowała bazową listę konfliktów SoD generującą wysokie ryzyko. Tabela poniżej prezentuje przykłady takich ryzyk (w języku angielskim):
Task / Function 1 | Task / Function 2 | Description of Risk |
---|---|---|
Vendor Master Maintenance | Process Vendor Invoices | Maintain a fictitious vendor and enter a Vendor invoice for automatic payment |
AP Payments | Vendor Master Maintenance | Maintain a fictitious vendor and create a payment to that vendor |
Process Vendor Invoices | AP Payments | Enter fictitious vendor invoices and then render payment to the vendor |
Maintain Purchase Order | Process Vendor Invoices | Purchase unauthorized items and initiate payment by invoicing |
Maintain Purchase Order | Goods Receipts to PO | Enter fictitious purchase orders for personal use and accept the goods through goods receipt |
Process Vendor Invoices | Goods Receipts to PO | Enter fictitious vendor invoices and accept the goods via goods receipt |
Maintain Purchase Order | AP Payments | Enter a fictitious purchase order and enter the covering payment |
Vendor Master Maintenance | Maintain Purchase Order | Create a fictitious vendor and initiate purchases to that vendor |
Należy mieć świadomość, że wprowadzenie zarządzania konfliktami rozdziału obowiązków jest ciągłym procesem, posiadającym etapy bądź kroki. Aby umożliwić uzyskanie pełnej kontroli nad nim oraz uzyskać zgodność np. z ustawą SOX (Sarbanesa-Oxleya) kadry zarządzające decydują się na wdrożenie odpowiedniego narzędzia klasy GRC. Przykładami takich rozwiązań są np. dedykowane narzędzie SAP – SAP Access Control bądź smartGRC (moduł: smartSoD).
Na rysunku poniżej zaprezentowano jego kluczowe elementy. Kroki te zostaną omówione w kolejnych częściach artykułu.
Krok 1: Budowa Matrycy SoD – Rozpoznanie ryzyk
Aby rozpocząć wdrożenie procesu identyfikacji i rozwiązywania konfliktów rozdziału obowiązków w organizacji pierwszym i kluczowym krokiem jest zbudowanie Matrycy konfliktów rozdziału obowiązków - tzw. Matrycy SoD.
Matryca SoD prezentuje w graficzny sposób wszystkie kluczowe elementy procesów biznesowych, dla których połączenie dostępu dla użytkownika (a w efekcie potencjalna możliwość wykonania przez niego działań) będzie miało realny wpływ na działalność przedsiębiorstwa. Dla każdego połączenia (najczęściej jest to matryca w postaci równoczesnego dostępu do dwóch funkcji / czynności w systemie) ma miejsce zdefiniowanie poziomu ryzyka, numeru, wskazanie osoby odpowiedzialnej oraz ustalany jest opis wskazujący na zakres wpływu wynikający z tego połączenia uprawnień na organizację.
Najczęściej matryca taka powstaje na podstawie najlepszych praktyk dla biznesu, z uwzględnieniem specyfiki działalności organizacji. Aby umożliwić jak najlepsze zrozumienie zasad działania organizacji (przebieg procesów, niestandardowe rozwiązania czy też wyjątki w procesie) dobrym rozwiązaniem jest najszersze zaangażowanie kluczowych użytkowników biznesowych w warsztaty dotyczące budowy Matrycy.
W Warsztatach poza użytkownikami biznesowymi powinien uczestniczyć dział IT (odpowiedzialny za uprawnienia w systemie) oraz dział Audytu (odpowiedzialny za kontrolę nad rozdziałem obowiązków oraz ewentualne mitygacje konfliktów SoD).
Celem warsztatów jest wypracowanie konkluzji odnośnie konfliktów występujących w danym obszarze / procesie, a także dla konfliktów międzyobszarowych (występujących pomiędzy różnymi obszarami). Produktem Warsztatów, przydatnym również z perspektywy audytorskiej, jest przeanalizowanie uzgodnionych konfliktów pod kątem istniejących (bądź planowanych) mechanizmów kontrolnych występujących w organizacji. Ich okresowe testowanie może być potencjalnym elementem polityki mitygacji konfliktów SoD.
Ustalony poziom ryzyka może mieć również wpływ na sposób postępowania i raportowania dla poszczególnych użytkowników, już na przyszłych etapach rozwiązywania konfliktów SoD. Sposób postępowania (wraz z remediacją i mitygacją) zostanie omówiony w kolejnych częściach artykułu.
Na marginesie warto dodać, że możliwa jest również analiza konfliktów rozdziału obowiązków dotycząca dostępu do systemu dla użytkowników technicznych (działu IT / wsparcia). Zasady budowy matrycy oraz postępowanie w kolejnych krokach nie różni się zbytnio od procedur stosowanych dla konfliktów biznesowych.
Krok 2: Budowa reguł SoD i ich weryfikacja
Kolejnym krokiem w efektywnym zarządzaniu ryzykiem rozdziału obowiązków jest przeniesienie ustaleń dotyczących Matrycy SoD na język „techniczny”, czyli utworzenie reguł SoD. Przed budową reguł należy jednak podjąć decyzję odnośnie używanego narzędzia do analiz. Analizy mogą być wykonywane z użyciem specjalistycznych narzędzi (np. smartSoD bądź SAP GRC Access Risk Analysis (ARA)), bądź ręcznie. W wypadku korzystania z specjalistycznych narzędzi należy uwzględnić wymagany układ prezentacji reguł, który będzie następnie zaimportowany do aplikacji.
Dla poszczególnych funkcji należy przygotować listę aktywności bądź transakcji oraz autoryzacji (np. dla systemów SAP są to obiekty / pola / wartości), które w technicznym rozumieniu pozwalają na wykonanie danej czynności biznesowej w systemie. Źródłem mapowania funkcji z Matrycy SoD do aktywności / transakcji oraz obiektów autoryzacyjnych może być wstępnie zbiór najlepszych praktyk dla wybranego środowiska, należy jednak pamiętać o tym żeby dostosować go do specyficznych wymagań.
Aby jak najlepiej dostosować budowane reguły do działania organizacji należy, poza rozwiązaniami standardowymi, rozważyć również wdrożone rozwiązania dedykowane dla organizacji. W ich ocenie pod kątem zasadności ich dodania do matrycy SoD powinni, poza specjalistami IT, uczestniczyć również programiści – autorzy rozszerzeń. Efektem ustaleń powinno być przygotowanie informacji odnośnie sprawdzanych obiektów autoryzacyjnych oraz przyporządkowanie istniejących rozszerzeń do funkcji z Matrycy SoD.
W kolejnej części
W kolejnej części artykułu omówione zostanie podejście do rozwiązywania konfliktów. W jego ramach określone zostaną kluczowe kroki procesu: analiza, remediacja oraz mitygacja. Dodatkowo wskazane zostaną działania jakie powinny zostać wykonane po stronie organizacji aby rozwiązanie konfliktów SoD nie było tylko jednorazową próbą uzyskania zgodności ale zostało dołączone do codziennych procedur działania przedsiębiorstwa.
O Autorze
Łukasz DudekStarszy Konsultant w Dziale Usług Doradczych, GRC Advisory
Starszy Konsultant GRC specjalizujący się w zakresie przygotowania i wdrażania matrycy konfliktów rozdziału obowiązków (SoD), zarówno na poziomie ryzyk IT jak i ryzyk biznesowych. Członek zespołów dla zróżnicowanych projektów wdrożeniowych rozwiązań klasy GRC (Governance, Risk and Compliance), od takich realizowanych dla średnich przedsiębiorstw aż do projektów, które dotyczą ponad 2000 użytkowników.
* ISACA "Best Practices to resolve Segregation of Duties conflicts in any ERP environment"