Fala wycieków danych. Jak fintechy powinny się zabezpieczać?

Ostatnie miesiące przynoszą kolejne informacje o wyciekach danych, włamaniach do systemów i przejęciach zasobów firm, które jeszcze niedawno uchodziły za dobrze zabezpieczone. Incydenty dotykają sektora medycznego, turystycznego, księgowego, e-commerce i usług wykorzystywanych przez przedsiębiorców. Dla branży finansowej powinien być to szczególnie poważny sygnał ostrzegawczy. Fintechy, instytucje płatnicze, operatorzy bramek płatniczych, firmy pożyczkowe, dostawcy usług BNPL i rozwiązania KYC przechowują dane, które mogą bezpośrednio prowadzić do pieniędzy. Nie chodzi wyłącznie o imię, nazwisko czy adres e-mail. W systemach mogą znajdować się dokumenty identyfikacyjne, numery rachunków, historia transakcji, dane urządzeń, adresy IP, informacje o kontrahentach, tokeny dostępowe, klucze API czy szczegóły integracji z innymi usługami.

To właśnie dlatego wyciek danych z fintechu może mieć znacznie poważniejsze konsekwencje niż podobny incydent w zwykłym serwisie internetowym. Cyberprzestępca nie musi od razu próbować wypłacać pieniędzy. Może najpierw wykorzystać skradzione informacje do stworzenia bardzo wiarygodnego ataku, podszyć się pod operatora płatności, bank albo dział obsługi i nakłonić klienta do wykonania kolejnego kroku. W sektorze finansowym dane nie są wyłącznie informacją. Bardzo często są mapą prowadzącą do pieniędzy.

Dane finansowe pozwalają tworzyć znacznie skuteczniejsze oszustwa

Przestępca posiadający dane klienta zwykłego portalu może wysłać mu masową wiadomość phishingową. Przestępca posiadający dane klienta fintechu może zrobić coś znacznie bardziej niebezpiecznego. Może wiedzieć, z jakiego operatora płatności korzysta dana firma, na jaki rachunek wypłacane są środki, jakie transakcje zostały ostatnio wykonane, z jakich usług korzysta przedsiębiorca i jak wygląda jego dotychczasowa komunikacja z supportem. Na tej podstawie można przygotować wiadomość, która nie wygląda jak typowy scam, lecz jak naturalna kontynuacja prawdziwej relacji biznesowej.

Zamiast ogólnego komunikatu o blokadzie konta napastnik może napisać o problemie z konkretnym rozliczeniem, konieczności ponownej autoryzacji rachunku albo błędzie w wypłacie środków. Jeżeli wiadomość zawiera prawdziwą nazwę firmy, właściwego operatora płatności i autentyczne dane klienta, jej skuteczność może być nieporównywalnie większa niż w przypadku klasycznego phishingu. Dlatego fintech powinien zadawać sobie nie tylko pytanie: „czy ktoś może ukraść naszą bazę?”, ale przede wszystkim: „co będzie można zrobić po jej kradzieży?”

Hasło i 2FA to dopiero początek

Mocne hasła i uwierzytelnienie dwuskładnikowe nadal są podstawą ochrony dostępu, ale współczesna organizacja finansowa nie może opierać bezpieczeństwa wyłącznie na nich. System powinien być projektowany z założeniem, że jeden z jego elementów może zostać przełamany. Pracownik może paść ofiarą phishingu, administrator może przypadkowo ujawnić token, w używanej bibliotece może pojawić się podatność, a dostawca zewnętrzny może zostać skutecznie zaatakowany. Problem zaczyna się wtedy, gdy przejęcie jednego konta otwiera napastnikowi dostęp do niemal całej infrastruktury.

Dlatego krytyczne konta powinny korzystać z mocniejszych mechanizmów uwierzytelniania, w tym rozwiązań odpornych na klasyczny phishing, takich jak FIDO2 czy klucze sprzętowe. Równie ważna jest zasada najmniejszych uprawnień. Pracownik powinien mieć dostęp wyłącznie do tych danych i funkcji, które są rzeczywiście potrzebne do wykonywania jego obowiązków. Jeżeli konsultant ma sprawdzić status płatności, nie powinien automatycznie otrzymywać możliwości zmiany rachunku do wypłat, przeglądania pełnej dokumentacji KYC i eksportowania historii transakcji klienta.

Jedno włamanie nie może oznaczać dostępu do wszystkiego

Bardzo istotnym elementem ochrony jest segmentacja infrastruktury. Najgorszy możliwy scenariusz to taki, w którym przestępca po uzyskaniu pierwszego dostępu może swobodnie przechodzić z jednego systemu do kolejnego. Przejęty serwer aplikacji prowadzi do bazy danych, baza do panelu administracyjnego, panel do systemu rozliczeń, a dalej znajdują się integracje bankowe, CRM, system KYC i narzędzia do wypłat. W takim modelu pojedyncza luka może uruchomić efekt domina.

Nowoczesna architektura powinna działać odwrotnie. Każdy krytyczny obszar powinien stanowić osobną warstwę zabezpieczeń. System obsługujący stronę internetową nie powinien automatycznie posiadać dostępu do infrastruktury odpowiadającej za wypłaty. Środowisko testowe nie powinno korzystać z pełnych danych produkcyjnych, a panele administracyjne powinny być dostępne tylko z określonych urządzeń i sieci. Nawet jeżeli napastnik dostanie się do jednego fragmentu infrastruktury, powinien napotkać kolejne bariery.

Klucze API mogą być cenniejsze niż hasła

Fintechy funkcjonują dzięki integracjom. Komunikują się z bankami, dostawcami kart, narzędziami KYC i AML, systemami księgowymi, sklepami internetowymi, aplikacjami mobilnymi czy rozwiązaniami antyfraudowymi. Oznacza to ogromną liczbę kluczy API, tokenów i innych sekretów, które stają się atrakcyjnym celem dla cyberprzestępców. Przejęcie odpowiednio uprzywilejowanego klucza API może dać napastnikowi więcej możliwości niż przejęcie konta zwykłego użytkownika.

Sekrety nie powinny być przechowywane bezpośrednio w kodzie ani w zwykłych plikach konfiguracyjnych. Powinny trafiać do dedykowanych systemów zarządzania sekretami, posiadać ograniczone uprawnienia i być regularnie rotowane. Firma powinna także posiadać możliwość natychmiastowego unieważnienia tokenów i kluczy, jeśli pojawi się choćby podejrzenie ich kompromitacji. Pierwszy raz nie powinno się szukać klucza API dopiero podczas rzeczywistego włamania.

Szyfrowanie jest ważne, ale nie rozwiązuje problemu

W przypadku wycieku danych często pojawia się pytanie, dlaczego określone informacje nie były zaszyfrowane. Szyfrowanie jest bardzo ważne, ale nie jest magicznym rozwiązaniem. Baza może być doskonale zabezpieczona na poziomie dysku, ale aplikacja musi przecież potrafić dane odszyfrować, aby z nich korzystać. Jeżeli atakujący przejmie aplikację lub konto z odpowiednimi uprawnieniami, może odczytywać dane w taki sam sposób jak legalny użytkownik.

Dlatego szyfrowanie musi być tylko jedną z warstw ochrony. Równie istotne są kontrola dostępu, segmentacja, tokenizacja, monitorowanie i odpowiednie zarządzanie kluczami kryptograficznymi. Warto również ograniczać zakres informacji dostępnych dla poszczególnych systemów. Moduł odpowiedzialny za raportowanie nie musi mieć pełnego dostępu do dokumentów KYC, a system obsługujący płatność nie zawsze musi znać wszystkie informacje o kliencie. Im mniej danych może zobaczyć dany komponent, tym mniej może z niego ukraść napastnik.

Najbezpieczniejsze dane to takie, których firma nie przechowuje

Jednym z najczęściej niedocenianych elementów cyberbezpieczeństwa jest minimalizacja danych. Firmy przez lata gromadzą kolejne informacje, tworzą kopie zapasowe, eksporty, pliki robocze i archiwa, a później zapominają o ich istnieniu. W efekcie w infrastrukturze mogą pozostawać dane, które od dawna nie są potrzebne do bieżącej działalności.

Oczywiście część informacji fintech musi przechowywać przez określony czas ze względu na obowiązki prawne, księgowe, regulacyjne czy AML. Nie oznacza to jednak, że każdy dokument, eksport czy plik testowy powinien istnieć bezterminowo. Stare kopie dokumentów, dawne eksporty CSV, zapomniane backupy i pliki testowe mogą stać się najłatwiejszym celem ataku. Czasami największym ryzykiem nie jest główna baza produkcyjna, lecz przypadkowy plik pozostawiony kilka lat wcześniej przez jednego z pracowników.

Fintech powinien wiedzieć, że ktoś właśnie kradnie dane

Ochrona nie może sprowadzać się do blokowania dostępu. Równie ważna jest możliwość wykrycia, że dzieje się coś nietypowego. Jeżeli konto wykonujące zwykle kilkaset operacji dziennie nagle generuje milion zapytań, administrator loguje się z nowego urządzenia, system zaczyna wykonywać masowe eksporty albo aplikacja komunikuje się z nieznanym wcześniej hostem, powinien pojawić się automatyczny alarm.

Dobre logowanie zdarzeń, systemy SIEM, EDR/XDR, analiza anomalii i monitorowanie transferów danych mogą znacząco skrócić czas obecności napastnika w systemie. Jest to niezwykle ważne także już po wykryciu incydentu. Firma musi być w stanie ustalić, kiedy rozpoczął się atak, które systemy zostały naruszone i jakie dane zostały pobrane. Brak logów może sprawić, że nawet po zatrzymaniu włamania organizacja nie będzie wiedziała, jaka była rzeczywista skala problemu.

Najsłabszym ogniwem może być zewnętrzny dostawca

Duże wycieki coraz częściej pokazują, że przedsiębiorca może zostać dotknięty incydentem, mimo że jego własna infrastruktura nie została bezpośrednio zhakowana. Wystarczy, że skutecznie zaatakowany zostanie dostawca oprogramowania, chmury, księgowości, KYC, CRM albo helpdesku. Dla przestępcy zaatakowanie jednego dostawcy obsługującego setki czy tysiące firm może być znacznie bardziej opłacalne niż atakowanie każdej z nich osobno.

Z tego powodu zarządzanie ryzykiem dostawców powinno być jednym z kluczowych elementów bezpieczeństwa fintechu. Nie wystarczy podpisać umowy powierzenia danych i uznać temat za zamknięty. Firma powinna wiedzieć, jakie dane otrzymuje kontrahent, gdzie je przechowuje, kto posiada do nich dostęp, jak długo są przechowywane oraz jakie procedury zostaną uruchomione po incydencie. To także jeden z istotnych elementów DORA, które od 17 stycznia 2025 roku znacząco zwiększyło wymagania dotyczące odporności cyfrowej podmiotów sektora finansowego i zarządzania ryzykiem związanym z dostawcami ICT.

Bezpieczeństwa nie testuje się raz na kilka lat

Kolejnym błędem jest przekonanie, że przeprowadzony kiedyś audyt albo pentest oznacza, że system jest bezpieczny. Fintech zmienia się niemal bez przerwy. Dochodzą nowe funkcje, integracje, biblioteki, pracownicy i dostawcy, a jednocześnie pojawiają się kolejne podatności i techniki ataków. Pentest wykonany trzy lata temu mówi przede wszystkim o stanie systemu sprzed trzech lat.

Testy penetracyjne, przeglądy kodu, skanowanie zależności, kontrola konfiguracji i analiza infrastruktury powinny być procesem ciągłym. Bezpieczeństwo musi być uwzględnione już podczas projektowania nowych funkcji, a nie dopiero po ich wdrożeniu. Szczególnego znaczenia nabiera to w przypadku aplikacji finansowych, gdzie nawet pozornie niewielka podatność może prowadzić do przejęcia konta, manipulacji transakcją albo dostępu do danych identyfikacyjnych.

Backup nie ochroni przed kradzieżą danych

Kopie zapasowe są niezwykle ważne, ale należy pamiętać o ich ograniczeniach. Backup może uratować przedsiębiorstwo po awarii, błędzie administratora czy ataku ransomware. Nie cofnie jednak wycieku danych. Jeżeli cyberprzestępca pobierze bazę klientów, jej późniejsze odtworzenie z kopii zapasowej nie ma żadnego znaczenia dla poufności skradzionych informacji.

Dlatego fintech musi chronić jednocześnie dostępność, integralność i poufność danych. Można mieć doskonały plan odtworzenia infrastruktury po awarii, a jednocześnie bardzo słabe mechanizmy wykrywania nieautoryzowanego eksportu informacji. W praktyce bezpieczeństwo powinno obejmować zarówno pytanie „jak szybko uruchomimy system ponownie?”, jak i „czy zauważymy, że ktoś właśnie kopiuje całą bazę klientów?”.

Pierwsze godziny po ataku są kluczowe

Nie istnieje zabezpieczenie dające stuprocentową gwarancję ochrony. Dlatego fintech powinien mieć przygotowany scenariusz na sytuację, w której atak rzeczywiście się powiedzie. Pierwsze działania obejmują ograniczenie dostępu napastnika, zabezpieczenie logów i materiału dowodowego, unieważnienie podejrzanych sesji, rotację tokenów i kluczy, kontrolę kont administracyjnych oraz sprawdzenie, czy atakujący nie pozostawił sobie dodatkowej możliwości powrotu do systemu.

Równolegle należy ustalić zakres naruszenia i potencjalne obowiązki regulacyjne oraz informacyjne. Kluczowe jest jednak to, aby takie działania nie były improwizowane. Procedury reagowania powinny istnieć przed atakiem i powinny być regularnie ćwiczone. Symulacja incydentu potrafi ujawnić problemy, których nie pokazuje nawet najlepiej przygotowana dokumentacja: brak odpowiedniej osoby decyzyjnej, brak dostępu do logów, problem z kontaktem z dostawcą albo sytuację, w której nikt nie wie, kto ma prawo odłączyć dany system od produkcji.

Cyberbezpieczeństwo nie jest już sprawą informatyków

W fintechu cyberbezpieczeństwo nie może być traktowane jako temat pozostawiony administratorom i programistom. Skuteczny atak może zatrzymać działalność firmy, doprowadzić do strat finansowych, uruchomić obowiązki wobec regulatorów, spowodować odpływ klientów i wywołać poważny kryzys reputacyjny. Cyberbezpieczeństwo jest dziś elementem zarządzania ryzykiem całego przedsiębiorstwa.

DORA dodatkowo wzmacnia tę zmianę podejścia, przesuwając odpowiedzialność za cyfrową odporność organizacji także na poziom zarządu. Władze firmy powinny rozumieć ryzyko ICT, zapewniać odpowiednie zasoby, kontrolować politykę bezpieczeństwa i mieć świadomość konsekwencji korzystania z zewnętrznych dostawców. Sam zakup kolejnego firewalla czy systemu ochronnego nie rozwiązuje problemu, jeżeli cała organizacja pozostaje źle zaprojektowana pod względem bezpieczeństwa.

Pytanie nie brzmi już: „czy ktoś nas zaatakuje?”

Fintechy są atrakcyjnym celem właśnie dlatego, że łączą w jednym miejscu dane osobowe, informacje finansowe, dostęp do środków i integracje z innymi systemami. Nie oznacza to, że sektor finansowy jest gorzej chroniony od innych branż. Wręcz przeciwnie – zwykle poziom zabezpieczeń jest tu znacznie wyższy. Jednocześnie potencjalna nagroda dla atakującego również jest znacznie większa.

Dlatego najważniejsze pytanie nie powinno dziś brzmieć: „czy ktoś spróbuje się do nas włamać?” Próby będą się pojawiać niezależnie od wielkości firmy. Znacznie ważniejsze jest inne pytanie: „co stanie się, jeśli pewnego dnia komuś się uda?”

Jeżeli przejęcie jednego konta, jednej aplikacji albo jednego dostawcy wystarczy, aby uzyskać dostęp do całej infrastruktury i ogromnej części danych klientów, to właśnie tam znajduje się największy problem. Dobrze zabezpieczony fintech to nie taki, do którego nie da się włamać. To taki, w którym jedno skuteczne włamanie nie prowadzi automatycznie do katastrofy.