„GRC Ninja – Dostęp awaryjny – jak ugasić pożar w systemie ERP?” – podsumowanie rozmowy z kanału Youtube

Ten wpis jest podsumowaniem materiału filmowego dostępnego na kanale GRC.Ninja na YouTube prezentowanym w formule rozmowy z ekspertami GRC ds. bezpieczeństwa SAP: Filipem Nowak i Andrzejem Partyka. 

W dzisiejszych czasach, zarządzanie dostępem do systemów komputerowych stanowi jedno z najważniejszych wyzwań dla organizacji, które dbają o swoje bezpieczeństwo informacji. Jednakże nie każdy dostęp jest standardowym dostępem użytkownika. W rozmowie z ekspertami z kanału GRC Ninja – Filipem i Andrzejem omawiamy praktyki związane z zarządzaniem dostępem awaryjnym i uprzywilejowanym oraz zastanawiamy się, dlaczego ten temat jest tak ważny w dzisiejszym otoczeniu rynkowym. 

Dlaczego Zarządzanie Dostępem Awaryjnym i Uprzywilejowanym jest istotnym aspektem zarządzania bezpieczeństwem w systemach ERP – SAP?

W rozwoju technologii często żartem mówi się, że „najbezpieczniejszy system to taki, do którego nikt nie ma dostępu”. Jednakże takie podejście jest nieskuteczne, ponieważ organizacje potrzebują elastyczności w dostępie do systemów, szczególnie w sytuacjach awaryjnych.

Jak podkreślają nasi eksperci, wyzwanie polega na znalezieniu równowagi pomiędzy bezpieczeństwem a elastycznością działania. Bezpieczny system, który jest zbyt rygorystyczny w kwestii dostępu, może paraliżować pracę organizacji.

Jak powinien zatem wyglądać proces Zarządzania Dostępem Awaryjnym i Uprzywilejowanym?

Rozmówcy przedstawiają wzorcowy proces zarządzania dostępem awaryjnym i uprzywilejowanym. Proces ten obejmuje kilka kluczowych kroków:

1. Wnioskowanie i zatwierdzanie dostępu w trybie awaryjnym

Pierwszym krokiem jest proces wnioskowania o dostęp awaryjny lub uprzywilejowany. W ramach tego procesu, konsultanci lub administratorzy wybierają odpowiedni system lub konto oraz określają okres, w którym będą potrzebować dostępu. Następnie odpowiedni właściciel konta musi zatwierdzić taki wniosek, co stanowi gwarancję, że osoba ma odpowiednie kompetencje do uzyskania dostępu.

2. Uruchamianie sesji w trybie awaryjnym tzw. „Firefighter”

Po uzyskaniu zatwierdzenia, konsultant lub administrator może uruchomić sesję „Firefighter”. W systemach GRC, IDM lub PAM, ten proces może być różnie konfigurowany. Sesja ta pozwala na kontrolowany dostęp do systemu w sytuacjach awaryjnych, pracach serwisowych, pracach projektowych – na przykład przed startem projektu, tzw. Go-Live.

3. Weryfikacja Działań i Logów

Najważniejszym ogniwem całego procesu jest weryfikacja logów z sesji emergency access. To kluczowa procedura w zapewnieniu bezpieczeństwa konta uprzywilejowanego. System automatycznie gromadzi i przesyła logi z każdej sesji do kontrolera, co stanowi niezbędny krok w eliminacji ryzyka nadużycia. Właściwa weryfikacja jest wymagająca, ale niezwykle istotna, umożliwiając dokładną analizę działań podejmowanych podczas sesji i identyfikację potencjalnych zagrożeń. Dzięki temu procesowi organizacja może skutecznie chronić swoje zasoby i dane przed nieautoryzowanym dostępem oraz utratą poufnych informacji. Nie można bagatelizować tego etapu, ponieważ stanowi on fundamentalny element w utrzymaniu bezpieczeństwa systemów informatycznych oraz ochronie kluczowych zasobów przed ewentualnymi atakami lub nadużyciami.

W ramach tej funkcji istnieje kilka rodzajów logów dostępnych do weryfikacji działań podejmowanych przez użytkowników firefighter. Oto niektóre z najważniejszych rodzajów logów dla systemu SAP, które można przeglądać w narzędziu emergency acces:

• Dziennik transakcji (Transaction Log), który przechwytuje wykonanie transakcji z transakcji STAD w systemie SAP, zawiera różne informacje dotyczące działań przeprowadzanych w systemie. Konkretne informacje, które są przechowywane w tym dzienniku, obejmują: Czas i data: Zapisuje dokładny moment, w którym dana transakcja została wykonana. To pozwala na dokładne określenie czasu i chronologii działań. Nazwa użytkownika: Rejestruje identyfikator użytkownika, który dokonał transakcji. Dzięki temu można zidentyfikować osobę odpowiedzialną za konkretne działania. Nazwa transakcji: Zawiera nazwę konkretnej transakcji SAP, która została wykonana. To pozwala na identyfikację, które funkcje lub operacje były wykonywane oraz inne przydatne dodatkowe informacje

• Dziennik zmian: Przechwytuje dziennik zmian z obiektów dokumentów zmiany (tabele CDPOS i CDHDR). „Dziennik zmian” (Change Log) w systemie SAP przechwytuje szczegółowe informacje na temat zmian dokonanych w danych w obiektach dokumentów zmiany, które są rejestrowane w tabelach CDPOS i CDHDR. Oto jakie dane są zazwyczaj przechowywane w dzienniku zmian: Typ zmiany: Określa rodzaj zmiany dokonanej w danych. Może to być np. utworzenie nowego rekordu, zmiana istniejącego rekordu, usunięcie rekordu, itp. Nazwa użytkownika: Informuje, który użytkownik dokonał danej zmiany. To pozwala na identyfikację osoby odpowiedzialnej za zmianę. Czas i data zmiany: Rejestruje dokładny moment, w którym zmiana została dokonana. To umożliwia określenie chronologii zmian. Nazwa obiektu zmiany: Wskazuje, które konkretne obiekty lub tabele danych były modyfikowane. Stary wartość (poprzednia wartość): Zapisuje wartość danych przed dokonaniem zmiany. To pozwala na porównanie poprzednich i nowych danych. Nowa wartość: Przechowuje wartość danych po dokonaniu zmiany. Jest to istotne, aby poznać, jakie dokładnie zmiany zostały wprowadzone. Numer dokumentu zmiany: Każda zmiana jest zazwyczaj numerowana, co pozwala na śledzenie historii zmian dla danego obiektu.

• Dziennik systemowy: Przechwytuje informacje o debugowaniu i zamianie z transakcji SM21.

• Dziennik audytu bezpieczeństwa: Przechwytuje dziennik audytu bezpieczeństwa z transakcji SM20.
• Dziennik poleceń systemowych: Przechwytuje zmiany w poleceniach systemowych z transakcji SM49.

Wsparcie Narzędziami

Chociaż proces ten można zrealizować ręcznie, eksperci zalecają korzystanie z narzędzi, takich jak narzędzia klasy IDM lub PAM. Narzędzia te automatyzują wiele etapów procesu i pomagają w zarządzaniu dostępem w sposób bardziej efektywny i bezpieczny. Eksperci wpominają o dwóch narzędzia SAP GRC Access Control i moduł Emergency Access oraz smartGRC i moduł SmartAccess.

Podsumowanie

Zarządzanie dostępem awaryjnym i uprzywilejowanym stanowi kluczowy element strategii bezpieczeństwa informatycznego każdej organizacji. Warto zrozumieć, że zapewnienie bezpieczeństwa nie oznacza paraliżowania pracy organizacji. Właściwie skonfigurowane procesy i narzędzia mogą pomóc w utrzymaniu równowagi pomiędzy bezpieczeństwem a elastycznością dostępu.

Kanał GRC Ninja zaprasza do subskrypcji i obserwowania kolejnych odcinków, które szczegółowo omówią różne aspekty zarządzania dostępem awaryjnym i uprzywilejowanym oraz pokażą, jak ten proces może być zaimplementowany w praktyce.