Dlaczego debugowanie w systemach produkcyjnych SAP to nieskończone źródło zagrożeń dla bezpieczeństwa

Debugowanie w kluczowych systemach SAP to jeden z najłatwiejszych sposobów na uzyskanie pełnej kontroli nad systemem #SAP. Użytkownik z uprawnieniami do debugowania i modyfikowania powinien być traktowany jako stałe zagrożenie dla bezpieczeństwa SAP. Ale czym jest debugowanie i jak może stać się zagrożeniem?

Czym jest debugowanie?

Wielu z nas pamięta scenę, w której Neo nauczył się poruszać z prędkością pocisków, kontrolować i zatrzymywać zdarzenia, a także dowolnie manipulować otoczeniem – jest to dość przystępny opis na czym polega debugowanie czylina identyfikowaniu i naprawianiu błędów, wad czy usterek w oprogramowaniu, poprzez wykonywanie kodu linia po linii. Jest to podstawowa czynność programistyczna, używana także w środowiskach testowych, gdy źródło błędu nie jest oczywiste. Oprogramowanie działa jako sekwencja zmiennych, które zmieniają swoje wartości. Debugowanie polega na kontrolowanym wykonaniu, krok po kroku, polecenie po poleceniu, aby programiści mogli analizować przepływ sterowania i wartości dynamicznie. Aby zdebugować program, użytkownicy potrzebują odpowiednich uprawnień. Uprawnienia te należą do domeny programistycznej i, choć są powszechnie przyznawane i używane w środowiskach programistycznych i testowych, przyznawanie uprawnień do debugowania w systemach produkcyjnych należy traktować z należytą ostrożnością. W niniejszym artykule omówimy kluczowe aspekty i zalecenia dotyczące zezwalania na debugowanie na żywo w systemach produkcyjnych.

Jak to wygląda w świecie SAP?

Świat oprogramowania SAP może nie być tak spektakularny jak Matrix, ale to również seria zdarzeń i przepływów: zatrudnienie pracowników, zamówienia, faktury, kampanie marketingowe, sprzedaż online, urlopy macierzyńskie, ruchy towarowe itp. W rzeczywistości trudno znaleźć transakcję w rzeczywistym świecie, której nie można by zarejestrować w systemie SAP (W tym momencie można zastanowić się, czy zdarzenia świata rzeczywistego mają miejsce na świecie i są tylko rejestrowane w SAP, czy też dzieją się w oprogramowaniu, a my zachowujemy się zgodnie. Ale to na pewno nie pytanie na tą publikację 😎).

Jednak warto zadać sobie pytanie, jakie ryzyko wiąże się z dopuszczeniem do debugowania na żywo w systemach produkcyjnych i jakie zagrożenie może to stanowić. Rozważmy następujące przypadki:

1. Przerwa w dostępności usług: zasoby systemowe nie są nieograniczone, a błędy debugowania są łatwe do popełnienia. Nieodpowiednie zarządzanie debugowaniem w systemie produkcyjnym może spowodować przerwę w dostępie do usług, a system stanie się niedostępny dla innych użytkowników. Na przykład łatwo zablokować wiele tabel, transakcji, procesów roboczych itp.
2. Podatność na ataki: Debugowanie w systemie produkcyjnym daje dostęp do przepływu sterowania i danych, w tym do weryfikacji uprawnień. Prosta zmiana wartości zmiennej może oznaczać różnicę między trybem wyświetlania a edycji, więc weź pod uwagę, że masz dostęp do ekranu z uprawnieniami swojego użytkownika.
3. Dowolna manipulacja danymi: debugowanie na żywo w systemie produkcyjnym może również wiązać się ze zmianami w czasie rzeczywistym, tuż przed interakcją z bazą danych. Jeśli możesz dowolnie manipulować wszystkimi interakcjami z bazą danych podczas odczytu i zapisu, możliwości są niemal nieograniczone.
4. Wpływ na reputację firmy: Nawet jeśli organizacja nie jest zainteresowana żadnym z wymienionych zagrożeń, to brak zainteresowania może wpłynąć na zaufanie partnerów, co ostatecznie doprowadzi do zawieszenia wszelkiej współpracy z organizacją. Co prawda, większość przypadków debugowania na żywo to tylko próby użytkowników dążących do zakończenia swojej pracy, ale rolą oficerów bezpieczeństwa jest umożliwienie rozwijania procesów biznesowych przy minimalizacji ryzyka. A ryzyko związane z debugowaniem na żywo w systemach produkcyjnych zawsze będzie krytyczne.

Czy oznacza to, że debugowanie na żywo w systemie produkcyjnym powinno być surowo zabronione? Niekoniecznie. Istnieją sytuacje, gdy debugowanie w systemie produkcyjnym może być dopuszczalne, na przykład gdy niemożliwe lub bardzo kosztowne jest odtworzenie problemu występującego tylko w środowisku produkcyjnym.

Chociaż tego rodzaju powody uzasadniają przyznawanie uprawnień do debugowania w systemie produkcyjnym, rozwiązanie zawsze będzie zbyt rozbudowane. Przyznawanie pełnych uprawnień kontroli nad danymi i przepływem sterowania dla nieokreślonej grupy transakcji w odpowiedzi na potrzebę odtworzenia konkretnej sekwencji będzie zawsze nadmiernym środkiem. Innymi słowy, debugowanie na żywo w systemie produkcyjnym zawsze wiąże się z krytycznym ryzykiem.

Jak zminimalizować ryzyko?

Możliwe jest zaakceptowanie ryzyka tymczasowego lub stałego przyznawania tych uprawnień w systemie produkcyjnym, ale jeśli się na to zdecydujesz, traktuj to niemal jako przyznanie pełnych uprawnień kontrolnych. W takich przypadkach intensywna kontrola wszelkich interakcji jest konieczna. W każdym razie debugowanie w systemie produkcyjnym musi być ściśle kontrolowane; nie jest to możliwe za pomocą narzędzia kontroli dostępu lub oceny uprawnień. Dlatego konieczne jest ustanowienie automatycznego mechanizmu alertowania, najlepiej zgodnego z urządzeniami mobilnymi, który będzie informował nas, gdy użytkownicy rozpoczną debugowanie w środowisku produkcyjnym. A właśnie to jest jednym z przypadków użycia zaimplementowanych w rozwiązaniu SecurityBridge do wykrywania zagrożeń.

Podsumowując, debugowanie na żywo w systemach produkcyjnych SAP może być źródłem poważnych zagrożeń dla bezpieczeństwa. Chociaż istnieją sytuacje, w których debugowanie w systemie produkcyjnym może być konieczne, należy zawsze podejmować odpowiednie środki ostrożności i kontrolować takie działania. Wdrożenie systemu automatycznego alertowania to jeden ze sposobów na monitorowanie debugowania na żywo i minimalizowanie ryzyka związanego z tym procesem.

Co dalej?

Jeżeli nie masz kontroli nad debugowaniem w SAPie, bądź nie wiesz jak się za to zabrać specjaliści z firmy SNOK pomogą Ci w tym zadania. Sprawdzą jaka jest obecna konfiguracja, jakie są procedury i nadane uprawnienia i na koniec wdrożą oprogramowanie, które będzie Cię informować w czasie rzeczywistym czy zostały naruszone standardy bezpieczeństwa w SAP. 

Bądź jak Neo – kontroluj swoje otoczenie 😎 i napisz do nas: info@snok.ai