Wtorek, 9:12. Ktoś loguje się do systemu SAP na koncie pracownika obsługi klienta. Hasło poprawne za pierwszym razem, więc żaden licznik nieudanych prób nie drgnie. Antywirus milczy, bo nie ma żadnego złośliwego pliku. Firewall milczy, bo ruch wygląda jak każdy inny. SIEM odnotowuje udane logowanie - jedno z kilkuset tego ranka - i na tym jego rola się kończy. Przez następne godziny to konto przegląda rekordy klientów. Najpierw setki, jak co dzień. Potem tysiące. Po południu licznik idzie w setki tysięcy, a nikt w firmie o tym nie wie.
Onno Coenen z SecurityBridge opisał ten scenariusz w artykule pod tytułem, który zostaje w pamięci na długo: gdyby ktoś dziś ukradł z SAP dwa miliony rekordów Waszych klientów - wiedzielibyście o tym? Dla większości organizacji szczera odpowiedź brzmi: nie.
W skrócie:
1/ Atakujący coraz rzadziej włamują się do SAP - logują się wykradzionymi, poprawnymi poświadczeniami i zachowują jak zwykli użytkownicy,
2/ SIEM i monitoring infrastruktury widzą logowanie, ale nie widzą, co użytkownik robi wewnątrz aplikacji SAP - to największe martwe pole (blind spot) w bezpieczeństwie SAP,
3/ RODO daje 72 godziny na zgłoszenie naruszenia do PUODO, ustawa o KSC 24 godziny na wczesne ostrzeżenie - oba zegary zakładają, że w ogóle jesteście w stanie incydent wykryć i opisać,
4/ Odpowiedzią jest monitoring natywny wewnątrz SAP - wykrywanie nietypowego dostępu do danych w czasie rzeczywistym plus materiał dowodowy na potrzeby śledztwa i regulatora.
Logowanie, które przechodzi każdą kontrolę
Przez lata firmy zbudowały solidną ochronę wokół infrastruktury: zarządzanie tożsamością, ochronę stacji roboczych, monitoring sieci, SIEM z całodobowym zespołem. To dobre inwestycje i nikt rozsądny ich nie podważa. Problem w tym, że atakujący odrobili tę samą lekcję. Zamiast wyważać drzwi, wchodzą z kluczem - poświadczeniami zdobytymi przez phishing, wyciek haseł albo przejęte konto serwisowe.
Od tego momentu wszystkie klasyczne kontrole działają na ich korzyść. Logowanie jest poprawne. Sesja wygląda zwyczajnie. Zapytania do bazy przechodzą przez standardowe transakcje. Z perspektywy SIEM to kolejny dzień pracy kolejnego użytkownika, bo SIEM zbiera zdarzenia z sieci, systemów operacyjnych i uwierzytelniania - a nie z wnętrza aplikacji biznesowej. Potrafi powiedzieć, że ktoś wszedł do SAP. Nie potrafi powiedzieć, co tam robi.
A właśnie w SAP leży to, co najcenniejsze. Umowy, dane rozliczeniowe, historia płatności, adresy, numery kont bankowych - w dużej organizacji setki tysięcy albo miliony rekordów klientów w tabelach jednego systemu. Pisaliśmy niedawno o włamaniu do Western Digital, gdzie napastnicy dotarli właśnie do danych w SAP. Ten wzorzec się nie starzeje - zmienia się tylko cena, jaką płaci ofiara.
Siedem pytań, na które trzeba będzie odpowiedzieć
Wyciek rzadko wychodzi na jaw od środka. Częściej dane klientów trafiają na sprzedaż w darknecie, dzwoni policja albo partner biznesowy pyta, skąd oszuści znają numery umów. Dopiero wtedy zaczyna się śledztwo - i wtedy padają pytania, które brzmią banalnie, dopóki nie trzeba na nie odpowiedzieć pod presją zarządu, klientów i regulatora naraz:
- Kiedy ta aktywność się zaczęła?
- Które konto SAP było używane?
- Jakie transakcje wykonano?
- Które dokładnie rekordy klientów przeglądano?
- Czy dane zostały pobrane lub wyeksportowane?
- Ilu klientów to dotyczy?
- Czy ta aktywność w ogóle została zatrzymana?
Wiedza o tym, że ktoś zalogował się do SAP, to jedno. Wiedza o tym, co zrobił po zalogowaniu, to zupełnie inna kategoria - i bez zapisu zdarzeń z wnętrza aplikacji zespół bezpieczeństwa skleja odpowiedzi z fragmentów logów różnych systemów, tygodniami, równolegle obsługując kryzys komunikacyjny. Organizacja prowadzi śledztwo i gasi pożar jednocześnie.
Regulator oczekuje faktów, nie przypuszczeń
Coenen pisze z perspektywy Azji i Pacyfiku: singapurska ustawa PDPA wymaga zgłoszenia naruszenia do komisji ochrony danych nie później niż trzy dni kalendarzowe od uznania go za podlegające zgłoszeniu, z karami sięgającymi 10% rocznego obrotu w Singapurze (przy obrocie powyżej 10 mln SGD) albo 1 mln SGD; australijski Privacy Act przewiduje kary do 50 mln AUD, trzykrotności uzyskanej korzyści albo 30% skorygowanego obrotu - w zależności od tego, która kwota jest najwyższa. Egzotyka? Tylko z pozoru, bo polskie i unijne przepisy zbudowane są na tym samym założeniu: organizacja ma wiedzieć, co się stało, zanim zacznie o tym mówić.
RODO w art. 33 daje 72 godziny na zgłoszenie naruszenia ochrony danych do PUODO, licząc od stwierdzenia naruszenia, a przy wysokim ryzyku art. 34 dokłada obowiązek zawiadomienia samych klientów. Za naruszenie obowiązków bezpieczeństwa i zgłaszania grozi kara do 10 mln EUR albo 2% światowego obrotu, a za naruszenie zasad przetwarzania - do 20 mln EUR albo 4%. Ustawa o KSC, o której pisaliśmy tydzień temu, idzie dalej: wczesne ostrzeżenie o incydencie poważnym w 24 godziny i zgłoszenie w 72 godziny, licząc od wykrycia. A kalendarz nie czeka: wniosek o wpis do wykazu podmiotów kluczowych i ważnych trzeba złożyć do 3 października 2026 - to już za dwa miesiące.
I tu wraca pułapka, którą znacie z tamtego wpisu. Wszystkie te zegary startują od wykrycia albo stwierdzenia naruszenia. Jeżeli nie macie czym wykryć, zegar formalnie nie startuje - ale organ nadzoru nie uzna tego za szczęśliwy traf, tylko za brak środków technicznych adekwatnych do ryzyka. A gdy pierwszym sygnałem wycieku jest telefon dziennikarza, na budowanie odpowiedzi jest już za późno.
„Sądzimy” kontra „wiemy”
Żaden dostawca i żaden zespół bezpieczeństwa nie zagwarantuje, że do naruszenia nigdy nie dojdzie. Różnica między firmą przygotowaną a nieprzygotowaną ujawnia się w pierwszym zdaniu komunikatu.
Firma bez widoczności w SAP mówi: „Sądzimy, że dane klientów mogły zostać naruszone. Skalę ustalamy.”
Firma z widocznością mówi: „Wiemy, które konto było używane, jakie transakcje wykonano, które rekordy przeglądano, kiedy to się działo i których klientów dotyczy. Aktywność została zablokowana.”
To są dwie zupełnie różne rozmowy z zarządem, z klientami i z regulatorem. Pierwsza otwiera kryzys o nieznanym koszcie i nieznanym czasie trwania. Druga zamyka incydent liczbami. A zaufanie klientów - jedyny zasób, którego nie odtworzycie z kopii zapasowej - przetrwa raczej tę drugą wersję.
Jak zlikwidować martwe pole
Skoro problemem jest brak widoczności wewnątrz aplikacji, rozwiązanie musi działać wewnątrz aplikacji. Dokładnie to robi platforma SecurityBridge, którą wdrażamy jako oficjalny partner w Polsce:
Threat Detection monitoruje zdarzenia wewnątrz SAP w czasie rzeczywistym i zgłasza alert wzbogacony o kontekst biznesowy - nie „użytkownik wykonał transakcję”, tylko „konto z obsługi klienta czyta dane w tempie i zakresie, który nie przypomina żadnego normalnego procesu”.
Data Loss Prevention pilnuje dostępu do wrażliwych danych: wykrywa nietypowe przeglądanie i pobieranie rekordów w momencie, gdy się dzieje, a nie po fakcie. Zespół bezpieczeństwa dostaje szansę przerwać eksfiltrację, zanim z systemu wyjdą miliony rekordów - a jeśli do incydentu dojdzie, platforma dostarcza materiał dowodowy: które konto, które transakcje, które dane, w jakim czasie.
Alerty trafiają do Waszego SIEM, więc dotychczasowe inwestycje nie idą do kosza - dostają brakującą warstwę, której same nie widzą.
Od czego zacząć
Nie od zakupu. Od szczerej odpowiedzi na pytanie, czy poranek z początku tego tekstu zostałby u Was zauważony.
Najszybszą drogą do tej odpowiedzi jest nasze bezpłatne badanie SNOK KSC-CHECK - 25 pytań w sześciu krokach, 8-12 minut, wynik od razu na ekranie i raport PDF e-mailem. Dwa z pięciu obszarów badania - Widoczność zdarzeń oraz Wykrywanie i reakcja - dotyczą dokładnie tego martwego pola, o którym tu mowa. To samoocena, nie audyt, ale porządkuje rozmowę o priorytetach lepiej niż niejedno spotkanie statusowe.
Drugi krok proponujemy zawsze ten sam, bo działa: umówcie z nami demo SecurityBridge, a potem przeprowadzimy proof of concept w Waszym środowisku SAP - na wybranym systemie, na Waszych scenariuszach, z alertami na realnych zdarzeniach. Po takim POC wiecie dokładnie, co platforma widzi u Was, a nie na slajdach. Zamiast dyskusji o architekturze dostajecie odpowiedź na pytanie z tytułu tego wpisu.
Z wrażliwymi danymi w SAP pracujemy na co dzień i na dużą skalę - dla Medicover zbudowaliśmy platformę procesów kadrowych obsługującą około 45 000 pracowników w 18 krajach i około 100 tysięcy zdarzeń kadrowych rocznie, projekt uznany przez SAP za oficjalną referencję, jedną z trzech w Polsce. Wiemy, jak wygląda odpowiedzialność za dane osobowe w systemach SAP, zanim jeszcze pojawi się słowo „incydent”.
Jeżeli badanie pokaże luki - albo jeżeli wolicie od razu przejść na poziom konkretnych systemów - napiszcie do nas. Pokażemy na żywo, jak wygląda wykrycie masowego odczytu danych w SAP, zanim zobaczy je ktoś, kto nie powinien.
Źródła
- Onno Coenen, If Someone Stole Two Million Customer Records from SAP Today… Would You Know?, LinkedIn Pulse, 27.07.2026
- RODO (rozporządzenie 2016/679), art. 33, 34 i 83 - EUR-Lex
- Ustawa z 23.01.2026 o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw (Dz.U. 2026 poz. 252)
- Personal Data Protection Act 2012 (Singapur), wymogi notyfikacyjne PDPC; Privacy Act 1988 (Australia) z nowelizacją 2022 - za artykułem źródłowym
- SecurityBridge - dokumentacja platformy: Threat Detection, Data Loss Prevention