Jeden system, podwójna wartość | Dlaczego banki łączą narzędzia Observability i Security w jedną platformę

Dwa narzędzia, jeden problem – niewidoczność

Wyobraźmy sobie typowy poranek w banku z milionem aktywnych klientów. O godzinie 7.43 zaczyna rosnąć liczba błędów w module autoryzacji kart płatniczych. Zespół operacyjny patrzy w dashboard APM – widzi spowolnienie usługi, ale nie zna przyczyny. Równolegle, o 7.41, analityk SOC odnotowuje w SIEM anomalię: skokowy wzrost zapytań do API z jednej podsieci wewnętrznej. Dwa zdarzenia. Dwa systemy. Dwie godziny na korelację tego, co stało się w ciągu dwóch minut.

To nie jest scenariusz z podręcznika. To jeden z wariantów zdarzeń, z którymi mierzą się dziś polskie i europejskie banki średniej i dużej wielkości. Fragmentacja stosu narzędziowego nie jest wyłącznie problemem technicznym – jest problemem zarządczym. Gdy CISO i CTO patrzą na tę samą infrastrukturę przez dwa różne okna, za każdym razem tracą czas, który w świecie incydentów bezpieczeństwa mierzy się w sekundach.

Elastic – jedna platforma, wspólny cel

Zestawy funkcji dostępne w Elastic Observability i Elastic SIEM to dwa zintegrowane produkty zbudowane na tej samej platformie: Elasticsearch jako silnik indeksowania i wyszukiwania, Kibana jako warstwa wizualizacji i reguł, Beats i Elastic Agent jako mechanizm zbierania danych. To nie jest przypadkowa architektura – to konsekwentna decyzja projektowa, wynikająca z wieloletnich doświadczeń wielu zespołów inżynierskich korzystających z wymienionych narzędzi, której skutki są bardzo praktyczne dla środowisk bankowych.

Kluczowy wniosek: Brak korelacji danych ops i security nie jest luką techniczną – to luka decyzyjna. Bank nie może zarządzać tym, czego nie widzi w jednym miejscu.

Dane z obu warstw – metryki wydajności aplikacji, logi transakcyjne, zdarzenia bezpieczeństwa, anomalie sieciowe – trafiają do tego samego klastra. Oznacza to, że reguła korelacji w SIEM może odwoływać się do pola latency z APM. Alert bezpieczeństwa może być wzbogacony o kontekst: czy usługa była w tym momencie przeciążona? Czy trwało wdrożenie nowej wersji? Czy był to punkt w cyklu miesięcznym o podwyższonym ruchu?

– W praktycznym wdrożeniu, które realizowaliśmy w instytucji finansowej zatrudniającej ponad dwa tysiące pracowników i obsługującej portfel ponad 300 tysięcy klientów detalicznych, efektem uruchomienia wspólnej platformy było skrócenie średniego czasu identyfikacji incydentu (MTTD) z 47 minut do poniżej 9 minut. Nie dlatego, że zmienił się zespół. Dlatego, że zmienił się kontekst dostępny analitykowi w chwili podejmowania decyzji – podkreśla Łukasz Grudzień, Security Management Team Leader w Integrity Partners, firmie specjalizującej się we wdrożeniach rozwiązań Elastic.

DORA i NIS2. Regulacja jako architektoniczny wymóg

Digital Operational Resilience Act wszedł w życie 17 stycznia 2025 r. Dla sektora bankowego oznacza to konkretne obowiązki: klasyfikację i raportowanie incydentów ICT, testowanie odporności operacyjnej, zarządzanie ryzykiem po stronie dostawców. Artykuł 17 DORA wprost wskazuje na konieczność utrzymywania narzędzi do monitorowania, wykrywania i klasyfikacji zdarzeń.

Elastic odpowiada na te wymagania na kilku poziomach jednocześnie. Po pierwsze: centralne repozytorium zdarzeń z pełną ścieżką audytową umożliwia rekonstrukcję przebiegu incydentu dla potrzeb raportowania do KNF czy UKNF. Po drugie: gotowe dashboardy zgodności (compliance dashboards) w Elastic SIEM pozwalają mapować zdarzenia na kategorie incydentów ICT wymagane przez DORA. Po trzecie: alerty i reguły korelacyjne mogą działać w czasie rzeczywistym, spełniając wymóg ciągłego monitorowania.

NIS2 dokłada do tego obowiązek raportowania poważnych incydentów w ciągu 24 godzin od wykrycia. Przy rozproszonych narzędziach jest to zadanie, które pochłania zasoby. Przy wspólnym stosie – to kwestia przygotowanego wcześniej raportu i jednego kliknięcia.

Chmura hybrydowa. Widoczność end-to-end

Polskie banki, podobnie jak instytucje w całej Europie, funkcjonują dziś w środowiskach hybrydowych. Część infrastruktury pozostaje on-premises (systemy core banking, archiwum transakcyjne, infrastruktura krytyczna), część migruje do chmury publicznej (usługi front-end, analityka, środowiska deweloperskie). To rodzi fundamentalny problem widoczności: gdzie kończy się monitoring chmury, a zaczyna się monitoring centrum danych?

Elastic Agent, jako zunifikowany kolektor danych, eliminuje tę granicę. Jeden agent zbiera dane z serwerów fizycznych, maszyn wirtualnych, kontenerów Kubernetes, usług chmurowych AWS, Azure i GCP. Wszystkie zdarzenia niezależnie od warstwy i lokalizacji trafiają zunifikowane do jednego klastra i podlegają tym samym regułom detekcji. Dla CISO oznacza to jedno – brak martwych stref.

– Dodatkową przewagą Elastic w kontekście wdrożeń bankowych jest wyjątkowa elastyczność modeli instalacji. Dzięki różnorodnym dostępnym metodom wdrożenia platforma pozwala precyzyjnie dopasować architekturę do wymogów regulacyjnych i infrastrukturalnych konkretnej instytucji. Banki działające w środowiskach o najwyższych wymaganiach bezpieczeństwa mogą skorzystać z wdrożenia on-premises air gapped – całkowicie odizolowanego od sieci zewnętrznych, spełniającego najbardziej restrykcyjne normy ochrony danych – wyjaśnia Łukasz Grudzień z Integrity Partners.

Instytucjom stawiającym na chmurę prywatną Elastic oferuje wdrożenia w oparciu o Elastic Cloud Enterprise (ECE) oraz Elastic Cloud on Kubernetes (ECK), które zapewniają pełną kontrolę nad infrastrukturą przy jednoczesnym zachowaniu elastyczności zarządzania klastrem. Wreszcie, banki gotowe na korzystanie z chmury publicznej mogą wybrać wdrożenie w modelu Elastic Cloud lub serverless – eliminując konieczność zarządzania infrastrukturą i skupiając zasoby wyłącznie na analityce i bezpieczeństwie. Niezależnie od wybranego modelu, platforma pozostaje ta sama – co oznacza spójne reguły detekcji, ten sam interfejs i te same dashboardy zgodności regulacyjnej.

Ekonomia jednej platformy

Argument kosztowy jest w rozmowach z zarządami banków często decydujący. Utrzymanie osobnych licencji dla SIEM, APM, systemu logowania i platformy metryk generuje koszty nie tylko finansowe, ale także koszty integracyjne (utrzymanie połączeń między systemami), szkoleniowe (dwa lub trzy odrębne interfejsy, dwie filozofie pracy) oraz operacyjne (dwa zestawy reguł, dwa kalendarze aktualizacji, dwa kontrakty serwisowe).

DORA w liczbach: Artykuł 19 DORA wymaga zgłoszenia poważnego incydentu ICT w ciągu 4 godzin od jego sklasyfikowania. Wspólny stos Observability + SIEM skraca czas klasyfikacji – a tym samym realnie wpływa na zdolność banku do dotrzymania tego terminu.

– Konsolidacja na Elastic nie eliminuje wszystkich tych kosztów, ale istotnie je redukuje. W przytoczonym wcześniej wdrożeniu łączna redukcja kosztów licencyjnych po przejściu z trzech osobnych narzędzi na Elastic wyniosła 34% w perspektywie trzyletniej. Efekt ten był jednak wtórny wobec głównego zysku – skrócenia czasu reakcji na incydenty i poprawy jakości raportowania regulacyjnego – zaznacza ekspert z Integrity Partners.

Teza, którą warto postawić zarządowi

W rozmowach z komitetami ryzyka i zarządami banków coraz częściej pada pytanie: czy jesteśmy gotowi na DORA? Odpowiedź zwykle skupia się na procesach i dokumentacji. Rzadziej pada pytanie o narzędzia, które te procesy mają obsługiwać.

Tymczasem architektura narzędziowa to nie szczegół techniczny, to fundament operacyjnej odporności. Bank, który monitoruje swoją infrastrukturę przez pięć różnych systemów, nie ma jednej prawdy o stanie swojego środowiska. Ma pięć częściowych prawd, które ktoś musi ręcznie złożyć w całość. W środowisku regulacyjnym, takim jak DORA, gdzie liczy się czas reakcji, pełna ścieżka audytowa i zdolność do natychmiastowego raportowania to luksus, na który sektor bankowy nie może sobie pozwolić.

Elastic Observability i Elastic SIEM to nie dwa produkty, które można wdrożyć równolegle. To jedna platforma, która przestaje pytać: „czy to problem operacyjny, czy bezpieczeństwa?” – i zaczyna odpowiadać: „oto pełny obraz zdarzenia, oto jego kontekst, oto rekomendowane działanie”.

Jeden stos. Podwójna wartość. I żadnych martwych stref.

Artykuł przygotował zespół ekspercki Integrity Partners, firmy wdrożeniowej specjalizującej się w implementacjach Elastic w środowiskach bankowych i finansowych. Autorzy realizują projekty SIEM, Observability oraz compliance (DORA/NIS2) w instytucjach sektora finansowego w Polsce i regionie CEE.