logo_grc_gold_standardlogo_grc_gold_standardlogo_grc_gold_standardlogo_grc_gold_standard
  • Aktualności
  • Oferta
    • Produkty SAP GRC
    • Archer Integrated Risk Management (IRM) Platform
    • smartGRC
    • Zgodność z RODO/GDPR
    • Dedykowane szkolenia
    • 🆕 SAP Security & Authorizations
    • SAP Signavio
    • SAP FCM
  • Blog
  • O firmie
  • Kariera
  • Kontakt
  • Kariera
    • Aktualne oferty
    • Aplikuj
polski
✕
  • Home
  • Blog
  • Blog ekspertów
  • „GRC Ninja – Dostęp awaryjny – jak ugasić pożar w systemie ERP?” – podsumowanie rozmowy z kanału Youtube

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

20 września 2023

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.

  1. 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.

  1. 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.

Related posts

8 czerwca 2025

Case study: Jak firma z branży chemicznej osiągnęła dwucyfrową redukcję kosztów licencji SAP dzięki analizie FUE przed migracją


Read more
4 czerwca 2025

Rewolucja AI Już Tu Jest. Czy Jesteśmy Gotowi na Erę Nadzorowanej Sztucznej Inteligencji? (I Co Mówi o Tym EU AI Act?)


Read more
25 maja 2025

SAP RISE FUE to nie tylko nowa metryka – to zupełnie nowe podejście do licencjonowania SAP


Read more

SZUKAJ NA BLOGU

✕

OSTATNIE POSTY

  • 0
    Krytyczna Luka Bezpieczeństwa w Obsłudze RFC w SAP – CVE-2025-42989
    10 czerwca 2025
  • 0
    Case study: Jak firma z branży chemicznej osiągnęła dwucyfrową redukcję kosztów licencji SAP dzięki analizie FUE przed migracją
    8 czerwca 2025
  • 0
    Rewolucja AI Już Tu Jest. Czy Jesteśmy Gotowi na Erę Nadzorowanej Sztucznej Inteligencji? (I Co Mówi o Tym EU AI Act?)
    4 czerwca 2025
  • 0
    SAP RISE FUE to nie tylko nowa metryka – to zupełnie nowe podejście do licencjonowania SAP
    25 maja 2025

FACEBOOK

GRC Advisory

GRC ADVISORY

Siedziba firmy:
GRC Advisory Sp. z o.o.

ul. Strzegomska 140A
54-429 Wrocław
Oddział:
Quattro Business Park
al. Gen. T. Bora Komorowskiego 25D
31-476 Kraków

 kontakt@grcadvisory.com
 +48 12 352 11 35
 +48 71 726 24 87

Siedziba firmy:
GRC Solutions Sp. z o.o.

ul. Strzegomska 140A
54-429 Wrocław

_
_


 kontakt@grcsolutions.pl
 +48 12 352 11 35
 +48 71 726 24 87

FIRMA

  • Aktualności
  • Oferta
  • Kariera
  • Prywatność
  • Kontakt

NA SKRÓTY

10lat Access Control access request ARM Bezpieczeństwo SAP Certyfikat DEKRA cyberbezpieczeńśtwo cybersrcurity dostęp awaryjny Dostęp uprzywilejowany ERP GRC GRCAdvisory GRC Advisory GRC Ninja GRCSolutions identity management IDM ISO konferencja Archer GRC kontrole kontrole mitygujące Matryca SoD nadmiarowe uprawnienia obszary GRC SAP partnerstwo Process Control Przegląd okresowy RODO RSA Archer SAP SAP Access Control 12.0 sap blog SAP GRC sap knowledge SAP S4/HANA SAP Security sap training sap workflow SAP® AC 12.0 Segregation of Duties Separation of duties SoD UAR Zarządzanie ryzykiem

BLOG

  • 0
    Krytyczna Luka Bezpieczeństwa w Obsłudze RFC w SAP – CVE-2025-42989
    10 czerwca 2025
  • 0
    Case study: Jak firma z branży chemicznej osiągnęła dwucyfrową redukcję kosztów licencji SAP dzięki analizie FUE przed migracją
    8 czerwca 2025
  • 0
    Rewolucja AI Już Tu Jest. Czy Jesteśmy Gotowi na Erę Nadzorowanej Sztucznej Inteligencji? (I Co Mówi o Tym EU AI Act?)
    4 czerwca 2025
Copyright © GRC Advisory 2010 - . All rights reserved
polski
  • No translations available for this page