Na ostatniej konferencji poświęconej SAP Security – wskazówki dla bezpieczeństwa dzieliłam się z Państwem wiedzą zdobytą podczas zarówno projektów reorganizacji SoD i uprawnień jak i codziennych zadań w ramach Managed Services. Dla tych z Państwa, którzy nie mogli uczestniczyć w konferencji przygotowałam krótkie podsumowanie.
Na samym początku zadaliśmy sobie pytanie co może być przyczyną decyzji o rozpoczęciu takiego przedsięwzięcia jakim jest Projekt Reorganizacji Uprawnień. Przykładowe scenariusze to:
Przypomnieliśmy sobie również podstawowe pojęcia z zakresu SoD - od ogółu do szczegółu:
Termin | Definicja |
---|---|
Matryca SoD | zbiór zdefiniowanych oraz opisanych konfliktów uprawnień w danym obszarze (np. FI, TR, SD, HR, Basis) |
Konflikt SoD | krytyczne zestawienie przynajmniej dwóch procesów biznesowych (np. wystawianie płac + zmiana konta bankowego, otwieranie okresów księgowych + zwalnianie dokumentów do płatności, konfiguracja systemu + import transportu) |
Ryzyko | opis konfliktu SoD z punktu widzenia biznesowego oraz możliwych konsekwencji wynikających z przypisanych uprawnień |
Proces | działanie biznesowe (np. otwieranie okresu księgowego, zwalnianie dokumentów do płatności) |
Authorization ID | zdefiniowane transakcje, raporty, tabele czyli wartości pól SAP sprawdzanych przez silnik zdefiniowanej i skonfigurowanej na systemie SAP matrycy. Wszystko to co chcemy wyłapać jako „krytyczne” w uprawnieniach kontrolowanych użytkowników |
Mitygacje | kontrola ryzyk, do których powinien zostać odebrany/zachowany dostęp dla określonych użytkowników; kontrole mogą być manualne, kompensacyjne, automatyczne, zgodne z zasadą „four eyes principle” |
SOD Segregation of duties | czyli każdy pracownik wykonuje wyłącznie swoją część procesu i nikt nie jest uprawniony do działań wykraczających poza stanowiskowe obowiązki! |
Planując PRU należy zaplanować przynajmniej poniższe 5 faz:
W trakcie projektu czeka na nas cała masa wyzwań oraz pułapek, na przykład gdy przeanalizujemy krytyczne dostępy na systemie SAP i wykryjemy kto ma przypisany profil SAP_ALL…
Może się okazać, że nie tak łatwo poszczególne osoby będą chciały oddać taki szeroki, wygodny dostęp. Argument: „jestem kluczowym użytkownikiem i potrzebuję szerokiego dostępu na cito w razie awarii na systemie”.
Kolejna niespodzianka dotyczy innego ważnego aspektu w projekcie. Otóż projekt reorganizacji uprawnień i SoD to projekt wybitnie interdyscyplinarny. Aby stworzyć perfekcyjny zespół projektowy musimy zaangażować i podzielić zadania zarówno wśród użytkowników biznesowych jak i technicznych (Zespół Autoryzacji, konsultanci modułowi, developerzy, Basis). Niestety, bardzo często gdy projekt ma w nazwie „autoryzacje” właściciela projektu często przypisuje się w zespołach IT:
Po zdefiniowaniu właścicieli tematów i zadań w każdej fazie projektu należy zastanowić się nad odpowiednimi narzędziami, które mogą być przydatne w projekcie reorganizacji uprawnień i SoD. Warto przyjrzeć się dostępnym w SAP oraz na rynku narzędziom, które redukują czasochłonność i automatyzują pracę zespołu projektowego. Poniżej podaję przykłady zestawienia narzędzi standardowych SAP z narzędziami SAST Suite.
Przykład wycinka matrycy HR w SAST Suite:
Fragment biblioteki krytycznej autoryzacji – transakcja PA30 + obiekt autoryzacyjny wraz z krytycznymi transakcjami:
Rezultat: po zdefiniowaniu wartości w orgsecie automatyczne utworzenie roli o nazwie: YFI_C_AC00:AA-DAILY wraz z uzupełnionymi poziomami organizacyjnymi
Rezultat: utworzenie roli z prześledzonego na wybranym użytkowniku trace’a.
Nie zapominajmy o pozostałych wyzwaniach Projektu Reorganizacji Uprawnień:
Gdyby zainteresowało Państwa szczególnie któreś z omówionych zagadnień, serdecznie zapraszam do kontaktu. Do usłyszenia na kolejnej konferencji SAP Security – wskazówki dla bezpieczeństwa!