Podział obowiązków: czym jest i jak go wdrożyć w małym zespole

Czym naprawdę jest podział obowiązków

Podział obowiązków dzieli wrażliwy proces na kroki i przypisuje te kroki różnym osobom, więc dokończenie procesu wymaga więcej niż jednej osoby. Termin pochodzi z księgowości, gdzie jest kluczową kontrolką wewnętrzną dużo dłużej, niż istnieją komputery, i przenosi tę samą logikę do IT i security.

NIST SP 800-53, amerykański federalny katalog kontrolek, szeroko przywoływany w europejskich programach security, definiuje to w kontrolce AC-5, „Separation of Duties". Kontrolka wymaga od organizacji zidentyfikowania i udokumentowania obowiązków poszczególnych osób, które wymagają rozdzielenia, oraz zdefiniowania autoryzacji dostępu do systemu, które to rozdzielenie wspierają. Wytyczne uzupełniające wprost formułują cel: separacja obowiązków „adresuje potencjał nadużycia autoryzowanych uprawnień i pomaga zredukować ryzyko złośliwego działania bez zmowy". Podaje przykłady, takie jak rozdzielenie funkcji biznesowych od funkcji wsparcia oraz zapewnienie, że osoby administrujące kontrolkami dostępu nie są tymi samymi osobami, które administrują logami audytowymi.

ISO 27001:2022 formułuje tę samą myśl w kontrolce Annex A 5.3. Wymaga, żeby „konfliktowe obowiązki i konfliktowe obszary odpowiedzialności" były rozdzielone, z jasno wskazanym celem redukcji ryzyka nadużycia, błędu i obejścia kontrolek bezpieczeństwa informacji. Sformułowanie warte zapamiętania jest takie, że żadna pojedyncza osoba nie powinna móc popełnić, ukryć i uzasadnić niewłaściwego działania. Każdy z tych trzech czasowników to osobna linia obrony, która znika, kiedy jedna osoba kontroluje cały proces.

Leżące u podstaw twierdzenie jest więc wąskie i konkretne. Zasada dotyczy garści procesów, w których pojedynczy aktor mógłby wyrządzić realną szkodę, i wymaga tylko, żeby kroki, które się wzajemnie sprawdzają, były w rękach różnych osób. Większość zadań w ogóle nie wymaga rozdzielenia.

Dlaczego jeden właściciel to ryzyko

Proces posiadany od początku do końca przez jedną osobę zawodzi po cichu na dwa sposoby.

Pierwszy to nadużycie. Jeśli ta sama osoba zakłada rekord dostawcy i zatwierdza płatności do niego, może zapłacić dostawcy, który istnieje tylko na papierze, i nigdzie w tym przepływie nie ma drugiej pary oczu. Wytyczne kontroli finansowej są zbudowane dokładnie wokół tego scenariusza. To też podręcznikowy przypadek, który audytorzy podnoszą jako pierwszy, bo jest konkretny, a strata bezpośrednia.

Drugi to błąd, który jest częstszy i mniej dramatyczny. Osoba, która zarówno wprowadza transakcję, jak i ją zatwierdza, nie ma nikogo, kto zauważyłby pomyłkę, zanim zacznie ona obowiązywać. Kontrolka, która łapie nadużycie, tym samym ruchem łapie uczciwe błędy, co po części tłumaczy, czemu przetrwała nawet w organizacjach bez żadnego powodu, żeby kogokolwiek podejrzewać.

Tradycja księgowa rozbija wrażliwy proces na cztery funkcje i mówi, że żadna osoba nie powinna trzymać więcej niż jednej z nich dla tej samej transakcji: autoryzacja (zatwierdzenie transakcji), piecza (kontrola nad zaangażowanym aktywem, czy to gotówką, danymi czy systemem), prowadzenie zapisów (utrzymywanie rekordu) oraz uzgadnianie (niezależne sprawdzenie, że dwa zestawy zapisów się zgadzają).

Nie musisz przyjmować tego słownictwa, ale to użyteczny test. Kiedy podejrzewasz, że proces jest zbyt skoncentrowany, zapytaj, ile z tych czterech funkcji kontroluje jedna osoba. Im więcej ich trzyma, tym bardziej proces zależy od tego, żeby ta jedna osoba była zarazem uczciwa i zawsze miała rację.

Toksyczne kombinacje, których warto szukać

W pracy z tożsamością i dostępem „toksyczna kombinacja" to para uprawnień, które nie powinny być w rękach tej samej osoby, bo razem pozwalają jej samodzielnie dokończyć wrażliwy proces. To sformułowanie jest standardem w praktyce access governance. Nie musisz mapować setek takich kombinacji. Krótka lista pokrywa większość realnej ekspozycji dla firmy mid-market.

• Zakładanie lub edycja dostawcy i zatwierdzanie płatności do dostawców · Dlaczego jest niebezpieczna: Fikcyjny albo zmieniony dostawca może zostać opłacony bez żadnej niezależnej kontroli. Klasyczne nadużycie finansowe.
• Wnioskowanie o dostęp i zatwierdzanie wniosków o dostęp · Dlaczego jest niebezpieczna: Ktoś może nadać sobie, co chce, i sam to zatwierdzić.
• Nadawanie lub zarządzanie uprawnieniami użytkowników i zakładanie kont użytkowników · Dlaczego jest niebezpieczna: Jedna osoba może postawić konto i po cichu nadać mu podwyższone uprawnienia.
• Pisanie lub zmiana kodu i wdrażanie go na produkcję · Dlaczego jest niebezpieczna: Niesprawdzone albo złośliwe zmiany trafiają na systemy produkcyjne bez drugiego spojrzenia.
• Administrowanie kontrolkami dostępu i administrowanie logami audytowymi · Dlaczego jest niebezpieczna: Osoba, która może nadać dostęp, może też usunąć dowód, że to zrobiła. NIST AC-5 wskazuje to wprost.
• Przetwarzanie płac i zatwierdzanie zmian w płacach · Dlaczego jest niebezpieczna: Stawki płac albo odbiorcy mogą zostać zmienione i zatwierdzone tą samą ręką.

Przez wszystkie te przypadki przewijają się dwa wzorce. Pierwszy to samo-zatwierdzanie: każdy przypadek, w którym ta sama osoba wnioskuje i zatwierdza, jest konfliktem z definicji, bo krok zatwierdzenia niczego nie wnosi. Drugi to wzorzec działanie-i-zatarcie, gdzie ktoś może zarówno podjąć działanie, jak i zmienić jego zapis. Połączenie administratora dostępu z administratorem logów audytowych to najczystsza wersja tego wzorca, i dlatego integralność logów ma tak samo duże znaczenie jak kontrola dostępu.

Czemu audytorzy tego wymagają

Podział obowiązków pojawia się w każdym poważnym frameworku kontrolek, bo to jedna z najstarszych i najbardziej niezawodnych kontrolek wewnętrznych, i bo audytor faktycznie może to przetestować.

W ramach SOC 2 separacja konfliktowych obowiązków wspiera kilka wspólnych kryteriów Trust Services, zwłaszcza kryteria kontroli dostępu i kryteria zarządzania zmianą. Audytor będzie szukał dowodów, że wnioskowanie o dostęp i jego zatwierdzanie to osobne kroki, oraz że ludzie zmieniający oprogramowanie nie są jedynymi ludźmi zatwierdzającymi te zmiany przed trafieniem na produkcję.

W ramach ISO 27001 kontrolka Annex A 5.3 to jawny wymóg. Organizacja musi ustalić, które obowiązki są konfliktowe, i wprowadzić kontrolki, które je rozdzielą. Audytorzy certyfikujący oczekują dowodu, że o tym pomyślałeś, nie że osiągnąłeś idealny podział.

W raportowaniu finansowym Sarbanes-Oxley Act z 2002 roku uczynił podział obowiązków nazwanym wymogiem dla firm w swoim zakresie. Sekcja 404 wymaga od zarządu utrzymywania kontrolek wewnętrznych nad raportowaniem finansowym, a audytorzy szukają dowodu, że zapisy księgowe, zakładanie dostawców, płatności, płace i uzgadnianie nie są obsługiwane od początku do końca przez jedną osobę. SOX dotyczy spółek notowanych w USA, więc dla większości europejskich firm mid-market jest punktem odniesienia, nie bezpośrednim obowiązkiem, ale filozofia kontrolek, którą skodyfikował, to ta sama, którą dziś niosą SOC 2 i ISO 27001, a europejskie wymogi takie jak DORA i NIS2 opierają się na tych samych fundamentach access governance.

Wspólnym wątkiem przez wszystkie z nich jest to, że audytorzy tak naprawdę nie oceniają, czy twój zespół jest wystarczająco duży, żeby rozdzielić każdy obowiązek. Oceniają, czy zidentyfikowałeś konflikty i potrafisz wykazać, na podstawie zapisów, że każdy z nich jest kontrolowany.

Jak to zrobić w małym zespole

Uczciwa trudność to wielkość zespołu. Firmy na wczesnym etapie i szczupłe organizacje rutynowo mają jedną albo dwie osoby odpowiedzialne za rozwijanie, wdrażanie i zatwierdzanie tego samego zadania, po prostu dlatego, że nie ma wystarczająco ludzi. To najczęstszy powód, dla którego ten temat wydaje się niemożliwy, i ma on uznaną odpowiedź.

Zacznij od zaakceptowania, że pełna separacja to spektrum, nie przełącznik. Celem nie jest wykreowanie dodatkowych etatów. Celem jest upewnienie się, że żadna pojedyncza osoba nie ma niekontrolowanej władzy nad wrażliwym procesem, i umiejętność pokazania, jak to zapewniasz.

Pracuj w tej kolejności:

Zidentyfikuj swoje prawdziwe konflikty. Większość firm ma niewielką liczbę naprawdę wrażliwych procesów: płatności i zakładanie dostawców, nadawanie dostępu i uprawnień, wypuszczanie kodu na produkcję. Zmapuj, kto dziś może wykonać każdy krok. Tabela toksycznych kombinacji powyżej to lista startowa. Szukasz każdej osoby, która trzyma obie połówki pary.

Podziel te, które możesz, tanio. Niektóre rozdzielenia nic nie kosztują, kiedy już je zauważysz. Osoba, która wnioskuje o dostęp, nie musi być tą, która go zatwierdza, nawet w zespole liczącym dziesięć osób, bo zatwierdzającym może być manager albo osoba na równorzędnym stanowisku w innej funkcji. Przeniesienie zatwierdzenia na inną osobę to często zmiana konfiguracji, nie zatrudnienie.

Dla reszty użyj kontrolek kompensujących. Tam, gdzie zespół naprawdę nie może podzielić obowiązku, frameworki oczekują kontrolek kompensujących zamiast pełnej separacji, i mówią o tym wprost. Wytyczne ISO 27001 5.3 stanowią, że tam, gdzie rozdzielenie jest trudne, zwłaszcza w małych organizacjach, należy rozważyć inne kontrolki, takie jak monitorowanie działań, audit trail i nadzór kierownictwa. Praktyka SOC 2 akceptuje te same substytuty: udokumentowany wtórny przegląd, niezależny nadzór albo rotację obowiązków.

Trzy kontrolki kompensujące o największej wadze:

• Niezależny przegląd. Ktoś, kto nie wykonał danego działania, sprawdza je po fakcie. Manager, który co miesiąc przegląda wszystkie płatności powyżej progu, albo zewnętrzny księgowy, który przegląda księgi, to legalna kontrolka kompensująca dla obowiązku, którego nie da się podzielić. Osoba przeglądająca musi być niezależna od działania, a przegląd musi zostawiać zapis.
• Audit trail i logowanie. Jeśli jedna osoba wykonuje wrażliwe działanie, system zapisuje, kto co zrobił i kiedy, w logu, którego ta osoba nie może zmienić. Logowanie nie zapobiega złemu działaniu, więc jest kontrolką detekcyjną, a nie prewencyjną, ale odporny na manipulację ślad plus regularny niezależny przegląd razem przybliżają ochronę, jaką dałaby separacja.
• Podwójna akceptacja. Dla działań o najwyższym ryzyku wymagaj, żeby dwie osoby zatwierdziły je, zanim wejdą w życie, nawet jeśli jedna osoba je zainicjowała. Drugi podpis przy dużych płatnościach albo wymagany code review przed wdrożeniem przywraca drugą parę oczu w punkcie decyzji. To często najbardziej praktyczna kontrolka dla małego zespołu, bo dodaje punkt kontrolny bez dzielenia całego procesu.

Zapisz to. Ta część jest pomijana przez zespoły, a to właśnie ona decyduje, czy kontrolka przechodzi. Konflikt, który zidentyfikowałeś, z nazwaną kontrolką kompensującą i zapisem pokazującym, że kontrolka jest faktycznie wykonywana, przechodzi. Ten sam konflikt pozostawiony niejawnie to finding. Audytorzy rzadko proszą małą firmę o restrukturyzację zespołu. Proszą o sformalizowanie i udokumentowanie tego, co firma już robi, żeby kontrolka była powtarzalna i weryfikowalna, zamiast zależeć od pamięci jednej osoby.

Sprawdza się krótki, prosty rejestr: wypisz każdy wrażliwy proces, kto może wykonać każdy krok, jakie istnieją konflikty i kontrolkę kompensującą dla każdego konfliktu, którego nie możesz wyeliminować. Ten jeden dokument odpowiada na większość tego, o co zapyta audytor, i podwójnie służy jako twoja własna mapa tego, gdzie leży realne ryzyko.

Gdzie podział obowiązków mieści się w szerszym obrazie

Podział obowiązków to jedna kontrolka spośród kilku, które razem odpowiadają na pytanie, kto może co robić i dlaczego. Działa najlepiej, kiedy otaczające go dyscypliny są na miejscu. Least privilege utrzymuje dostęp każdej osoby wystarczająco wąski, żeby konfliktów, którymi musisz zarządzać, było mało. Przeglądy dostępów to moment, w którym okresowo sprawdzasz, czy rozdzielenia, które ustawiłeś, wciąż są prawdziwe po zmianach ról. A access governance to szerszy program, który spina identyfikację konfliktów, własność i dowody razem. Czytaj to razem z access governance, least privilege i przeglądami dostępów.

Źródła

• NIST SP 800-53 Rev. 5, AC-5 Separation of Duties (treść kontrolki i wytyczne uzupełniające) · https://csf.tools/reference/nist-sp-800-53/r5/ac/ac-5/ (definicja, cel, sformułowanie „bez zmowy", przykład kontrola dostępu kontra logi audytowe)
• NIST CSRC, SP 800-53 Rev. 5 control catalogue · https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final (główne źródło dla kontrolki AC-5)
• ISO 27001:2022 Annex A 5.3 Segregation of Duties, ISMS.online · https://www.isms.online/iso-27001/annex-a-2022/5-3-segregation-of-duties-2022/ (cel kontrolki, sformułowanie „popełnić, ukryć, uzasadnić", kontrolki kompensujące dla małych organizacji)
• ISO 27001 5.3 implementation guidance, ISMS.online · https://www.isms.online/iso-27001/annex-a-2022/how-to-implement-iso-27001-2022-annex-a-control-5-3-segregation-of-duties/ (monitorowanie, audit trail, nadzór tam, gdzie separacja jest niewykonalna)
• Segregation of duties (authorisation, custody, record keeping, reconciliation), SailPoint · https://www.sailpoint.com/identity-library/segregation-duties (cztery funkcje księgowe)
• Top Segregation of Duties Conflicts and How to Fix Them, SecurEnds · https://www.securends.com/blog/segregation-of-duties-conflicts/ (przykłady toksycznych kombinacji, konflikt dostawca-płatność)
• Separation of Duties: Combating Toxic Combinations with SoD Controls, Veza · https://veza.com/blog/separation-of-duties-combating-toxic-combinations-with-sod-controls/ (definicja toksycznej kombinacji i wzorce samo-zatwierdzania)
• The SOC 2 Catch-22 That Holds Small Companies in Place, Warren Averett · https://warrenaverett.com/insights/soc-2-catch-22 (konflikty SoD w małych zespołach i kontrolki kompensujące pod SOC 2)
• Segregation of Duties for SOX Compliance, SecurEnds · https://www.securends.com/blog/segregation-of-duties-for-sox-compliance/ (oczekiwania Sekcji 404 SOX, własność end-to-end, której szukają audytorzy)
• SOC 2 CC8 change-management and segregation of duties, Design Compliance and Security · https://www.designcs.net/soc-2-cc8-common-criteria-related-to-change-management/ (separacja rozwijania kodu od wdrożenia, nacisk na dokumentację)