Bezpieczeństwo i integralność naszych transakcji finansowych
Banki takie jak nasz korzystają ze specjalistycznej infrastruktury serwerowej do obsługi odrębnych obszarów operacyjnych. W zależności od wymogów architektonicznych i przepisów finansowych główne rodzaje serwerów obejmują:
1. Serwery systemu bankowego (core banking)
Serwery te stanowią centralny trzon operacyjny, odpowiadający za obsługę rachunków klientów, transakcji oraz zgodności regulacyjnej:
- Serwery przetwarzania transakcji: Realizują autoryzację płatności w czasie rzeczywistym, kontrole antyfraudowe i rozliczenia (np. SWIFT, SEPA).
- Serwery zarządzania rachunkami: obsługują zdarzenia w cyklu życia rachunku (otwarcie/zamknięcie), naliczanie odsetek oraz monitorowanie płynności.
- Serwery do zapewniania zgodności regulacyjnej: automatyzują kontrole AML (przeciwdziałanie praniu pieniędzy), ścieżki audytu i raportowanie (np. MSSF, RODO).
2. Serwery rejestru
Odpowiada za prowadzenie niezmiennych zapisów finansowych:
- Serwery księgi głównej: rejestrują zapisy księgowe metodą podwójnego zapisu na kontach, zapewniając zgodność ze standardami rachunkowości, takimi jak MSSF.
- Serwery technologii rozproszonego rejestru (DLT): Systemy oparte na blockchainie, służące do płatności transgranicznych, weryfikacji KYC oraz prowadzenia rejestrów transakcji odpornych na manipulacje.
3. Serwery komunikacji zewnętrznej
Umożliwiają bezpieczną interakcję z podmiotami zewnętrznymi:
- Serwery EBICS: obsługują standard Electronic Banking Internet Communication Standard dla płatności SEPA, szeroko stosowany w Niemczech, Francji i Szwajcarii.
- Serwery Host-to-Host (H2H): bezpośrednie połączenia SFTP/FTPS dla transakcji korporacyjnych o dużym wolumenie (np. masowe przetwarzanie list płac).
- Serwery bramek API: udostępniają interfejsy RESTful do inicjowania płatności w czasie rzeczywistym i agregacji rachunków (zabezpieczone za pomocą OAuth2/mTLS).
- Serwery interfejsu Swift: łączą bank z siecią Swift w celu wymiany komunikatów międzybankowych (SCORE to zamknięta grupa użytkowników Swift przeznaczona do dostępu dla podmiotów korporacyjnych, a nie typ serwera).
4. Serwery baz danych
Centralne repozytoria ustrukturyzowanych danych finansowych:
- Serwery danych klientów: przechowują dokumenty KYC, historię transakcji oraz analitykę behawioralną.
- Serwery katalogu produktów: zarządzają ofertą obejmującą m.in. kredyty, kredyty hipoteczne i oprocentowanie depozytów.
5. Serwery bezpieczeństwa i infrastruktury
Zapewniają integralność systemów i zgodność z wymogami regulacyjnymi:
- Serwery Hardware Security Module (HSM): zabezpieczają klucze kryptograficzne wykorzystywane do podpisów cyfrowych oraz szyfrowania SSL/TLS.
- Serwery zapory sieciowej/VPN: Zapewniają segmentację sieci i bezpieczny dostęp zdalny dla pracowników.
- Serwery odtwarzania awaryjnego: Przechowują systemy zapasowe zapewniające ciągłość działania w razie awarii.
Nowoczesne banki często wdrażają architektury hybrydowe, łącząc lokalne serwery systemów centralnych z węzłami DLT w chmurze, co zapewnia skalowalność. Na przykład bank może korzystać z lokalnych serwerów bankowości centralnej IBM wraz z serwerami księgi rachunkowej hostowanymi w AWS w celu uzgadniania danych w czasie rzeczywistym. Takie modułowe podejście równoważy wymogi zgodności, wydajność i innowacyjność.
Banki muszą pogodzić konsolidację serwerów, służącą efektywności, z zachowaniem izolacji ze względów bezpieczeństwa i zgodności z przepisami. Poniżej przedstawiamy podział na serwery, które można łączyć, oraz te, których łączyć nie należy, w oparciu o ograniczenia techniczne i praktykę branżową:
Serwery, które można łączyć
1. Serwery WWW/aplikacyjne
- Metoda łączona: wirtualizacja (VMware, KVM) lub konteneryzacja (Docker/Kubernetes)
- Przykład: Hostowanie wielu portali bankowych (detalicznych, korporacyjnych, mobilnych) w klastrze hiperwizorów z równoważeniem obciążenia.
2. Serwery baz danych
- Metoda łączona: wielodostępne bazy danych w chmurze (AWS RDS, Azure SQL)
- Bazy danych podstawowych systemów bankowych oparte na Oracle/MS SQL mogą współistnieć z systemami analitycznymi opartymi na PostgreSQL/MongoDB w hybrydowych środowiskach chmurowych.
3. Zewnętrzne bramy komunikacyjne
- Metoda łączona: ujednolicone bramy API (Apigee, MuleSoft)
- Usługi EBICS, SWIFT i SFTP mogą działać na współdzielonej infrastrukturze z mikrousługami dedykowanymi poszczególnym protokołom.
4. Serwery odtwarzania awaryjnego
- Metoda łączenia: geo-redundancja w układzie active-active
- Repliki systemów bankowości podstawowej oraz zapasowe serwery ksiąg mogą korzystać ze wspólnych klastrów odtwarzania awaryjnego.
5. Serwery middleware
- Metoda łączenia: Enterprise Service Bus (ESB)
- Kierowanie płatności, kontrole zgodności oraz usługi przewalutowania skonsolidowane na platformach IBM Integration Bus/SAP PI.
Serwery, które powinny pozostać odizolowane
1. Serwery główne do przetwarzania transakcji
- Uzasadnienie: Separacja (fizyczna lub w drodze ścisłej segmentacji) zawęża zakres stosowania mechanizmów kontrolnych PCI DSS i SOC 2
- Przykład: monitory transakcji CICS działające na IBM zSystems nie mogą współdzielić sprzętu z innymi obciążeniami.
2. Serwery ze sprzętowymi modułami bezpieczeństwa (HSM)
- Uzasadnienie: poziom 3 normy FIPS 140-2/140-3 wymaga dedykowanego sprzętu odpornego na manipulacje
- Wdrożenie: moduły HSM firm Thales/Gemalto obsługujące podpisy cyfrowe i klucze szyfrujące.
3. Systemy ksiąg rozliczeniowych działające w czasie rzeczywistym
- Przyczyna: Księgowanie metodą podwójnego zapisu wymaga atomowości operacji
- Przykład: serwery księgi głównej Oracle Financial Services z bezpośrednio podłączonymi nośnikami NVMe.
4. Serwery raportowania regulacyjnego
- Uzasadnienie: Dzienniki audytu muszą być chronione przed modyfikacją i przechowywane przez okresy wymagane przez RODO i przepisy AML; rozdzielenie ułatwia wykazanie tego obowiązku.
- Konfiguracja: wyodrębnione instancje SQL Server dla raportów MiFID II/FATCA.
5. Systemy autoryzacji bankomatów i terminali POS
- Przyczyna: umowa o gwarantowanym poziomie usług (SLA) na poziomie dostępności 99,999% oraz wymogi dotyczące segmentacji sieci
- Architektura: systemy IBM Power Systems z redundantnymi sieciami SAN opartymi na Fibre Channel.
Ograniczenia techniczne:
- Centralne systemy bankowe przetwarzające duże wolumeny operacji wymagają dedykowanych połączeń sieciowych o wysokiej przepustowości
- Standard PCI DSS wymaga, aby przechowywane numery kart (PAN) były nieczytelne, a środowisko danych posiadaczy kart – wyodrębnione w ramach segmentacji
- Program Swift Customer Security Programme (CSP) wymaga, aby infrastruktura Swift znajdowała się w chronionej, zabezpieczonej strefie
Z powodzeniem skonsolidowaliśmy 80% serwerów niekrytycznych (web/app/middleware), pozostawiając systemy kluczowe/HSM/księgi w pełni odizolowane.
Zabezpieczenie serwerów księgi głównej w chmurze wymaga wielowarstwowych zabezpieczeń dostosowanych do wrażliwości danych finansowych. Na podstawie najlepszych praktyk bezpieczeństwa AWS oraz wdrożeń właściwych dla sektora bankowego przedstawiamy poniżej uporządkowane podejście:
1. Technologia niezmiennego rejestru
Należy stosować dedykowane bazy danych typu rejestr z kryptograficzną weryfikacją każdej transakcji:
- Łańcuchowanie kryptograficzne: każda transakcja jest haszowana i powiązana z poprzednim wpisem, co tworzy niezmienny ślad audytowy.
- Wbudowane mechanizmy kontroli integralności: baza danych automatycznie weryfikuje własną historię, co zapobiega nieuprawnionej ingerencji w dane.
- Zapytania w stylu SQL: Zapewniają zgodność z istniejącymi systemami finansowymi, a jednocześnie dodają zabezpieczenia znane z technologii blockchain.
2. Izolacja sieci
- Architektura VPC: serwery księgi należy wdrażać w podsieciach prywatnych bez publicznego dostępu do internetu.
- Grupy zabezpieczeń: ograniczenie ruchu przychodzącego do określonych portów (np. PostgreSQL/Aurora) z wcześniej zatwierdzonych zakresów adresów IP.
- Punkty końcowe VPC: wykorzystanie AWS PrivateLink do bezpiecznej komunikacji między serwerami księgi a usługami takimi jak S3/KMS, bez wystawiania danych do publicznej sieci.
3. Szyfrowanie
- W spoczynku: dane księgi są szyfrowane w Amazon Aurora kluczami zarządzanymi przez AWS KMS, z automatyczną rotacją kluczy.
- Podczas przesyłania: wymuszanie protokołu TLS 1.3 we wszystkich połączeniach klient–serwer oraz między usługami.
- Szyfrowanie po stronie klienta: Wstępne szyfrowanie danych wrażliwych (np. sald rachunków) przed zapisem z użyciem AWS Encryption SDK.
4. Kontrola dostępu
- Role IAM: przypisywanie szczegółowych uprawnień (na przykład ról umożliwiających wyłącznie dodawanie danych), aby zapobiec przypadkowemu lub złośliwemu usunięciu danych.
- Poświadczenia tymczasowe: należy wykorzystywać AWS STS do udzielania dostępu ograniczonego czasowo na potrzeby prac konserwacyjnych.
- Wymuszanie MFA: należy wymagać tokenów sprzętowych (YubiKey) dla kont root/administratora.
5. Monitorowanie i audyt
- Alerty w czasie rzeczywistym: należy skonfigurować AWS CloudWatch tak, aby generował alerty w przypadku nietypowych wzorców transakcji (np. przelewów powyżej 1 mln EUR).
- Dzienniki aktywności: wszystkie modyfikacje księgi są rejestrowane za pośrednictwem AWS CloudTrail zintegrowanego z narzędziami SIEM.
- Zautomatyzowane audyty: cotygodniowe uruchamianie reguł AWS Config w celu weryfikacji stanu szyfrowania i zasad sieciowych.
6. Compliance i ład korporacyjny
- Segmentacja strefowa: oddzielne środowiska księgi DEV/TEST/PROD z wykorzystaniem AWS Organizations.
- Zautomatyzowane raporty: Generowanie raportów zgodności z PCI DSS/RODO za pomocą AWS Audit Manager.
- Audyty zewnętrzne: Należy planować coroczne testy penetracyjne z udziałem partnerów zatwierdzonych przez AWS.
7. Odtwarzanie po awarii
- Replikacja międzyregionalna: utrzymywanie szyfrowanych replik księgi w regionach AWS we Frankfurcie i Sztokholmie.
- Odtwarzanie do wskazanego punktu w czasie: ciągłe kopie zapasowe umożliwiają przywrócenie danych do dowolnej sekundy w okresie retencji (do 35 dni).
- Kopie zapasowe odizolowane od sieci (air-gapped): kwartalne migawki ksiąg rachunkowych przechowywane w AWS Backup Vault z siedmioletnim okresem retencji.
Aby zapobiec rozprzestrzenianiu się złośliwych wpisów na serwery odtwarzania awaryjnego (DR), banki stosują wielowarstwowe strategie bezpieczeństwa, które izolują kopie zapasowe, wymuszają ścisłą kontrolę dostępu i weryfikują integralność danych. Poniżej przedstawiono techniczne omówienie kluczowych środków:
1. Niezmienne kopie zapasowe w konfiguracji Write-Once-Read-Many (WORM)
- Cel: uniemożliwienie oprogramowaniu ransomware modyfikowania lub szyfrowania danych kopii zapasowych.
Wdrożenie: Należy wykorzystać AWS S3 Object Lock lub Azure Blob Immutable Storage, aby uniemożliwić usunięcie lub modyfikację danych w określonym okresie przechowywania. Do kopii zapasowych plików należy zastosować kryptograficzne funkcje skrótu (SHA-256); każda manipulacja unieważnia skrót i uruchamia alerty.
2. Replikacja izolowana (air-gapped) i offline
- Izolacja sieci: Serwery DR należy umieszczać w oddzielnym VPC/VLAN bez dostępu przychodzącego z internetu. Należy stosować jednokierunkową replikację (podstawowy → DR) za pomocą narzędzi takich jak AWS Storage Gateway lub Azure Site Recovery, blokując synchronizację zwrotną.
- Fizyczna izolacja (air-gapping): w przypadku systemów krytycznych należy utrzymywać kopie zapasowe na taśmach lub nośniki offline, które łączą się z siecią wyłącznie w zaplanowanych oknach replikacji.
3. Mechanizmy kontroli dostępu w modelu zero trust
- Uwierzytelnianie: Należy wymusić uwierzytelnianie wieloskładnikowe (MFA) dla wszystkich interfejsów zarządzania DR (np. AWS SSO, Azure AD Conditional Access). Role IAM należy przypisywać zgodnie z zasadą najmniejszych uprawnień (np. wyłącznie `s3:GetObject`).
- Bezpieczeństwo sieci: Ruch replikacyjny należy ograniczyć do tuneli IPsec VPN lub połączeń AWS Direct Connect/Azure ExpressRoute. Należy wdrożyć systemy wykrywania włamań (IDS), takie jak Snort lub Suricata, do monitorowania kanałów replikacji.
4. Weryfikacja integralności danych
- Kontrole przed replikacją: Przed replikacją należy skanować dane źródłowe pod kątem złośliwego oprogramowania za pomocą narzędzi takich jak ClamAV lub CrowdStrike Falcon. Porównywać sumy kontrolne przed transferem i po nim, aby wykryć ingerencję.
- Audyty po replikacji: Należy wykorzystywać AWS Config lub Azure Policy do egzekwowania zasad szyfrowania i dostępu na serwerach DR. Codzienne kontrole integralności należy planować za pomocą skryptów (np. weryfikacja `sha256sum`).
5. Logicznie wydzielone środowiska
6. Zautomatyzowane testy przełączania awaryjnego
- Symulowane ataki: użycie narzędzi takich jak Chaos Monkey do symulowania infekcji oprogramowaniem typu ransomware i weryfikacji odporności serwerów DR. Pomiar docelowego czasu odtworzenia (RTO) i docelowego punktu odtworzenia (RPO) w trakcie ćwiczeń.
- Analiza kryminalistyczna: należy przechowywać przez 90 dni dzienniki VPC Flow Logs oraz zdarzenia CloudTrail, aby móc prześledzić anomalie replikacji.
Wdrożenie niezmiennych kopii zapasowych ma kluczowe znaczenie dla ochrony danych przed ransomware, przypadkowym usunięciem oraz naruszeniami wymogów zgodności. Na podstawie standardów branżowych oraz narzędzi takich jak AWS, Veeam i Azure najlepsze praktyki są następujące:
1. Wymuszanie niezmienności na poziomie warstwy przechowywania danych
- Należy stosować konfiguracje WORM (Write-Once-Read-Many) z wykorzystaniem pamięci obiektowej z funkcją S3 Object Lock (AWS), Azure Immutable Blob Storage lub Veeam Hardened Repositories.
- Włącz blokady retencji, aby zapobiec przedwczesnemu usunięciu lub modyfikacji, nawet przez administratorów.
2. Przyjęcie strategii kopii zapasowych 3-2-1-1
- 3 kopie danych (kopia podstawowa + dwie kopie zapasowe)
- 2 typy nośników danych (np. dysk + chmura)
- 1 kopia zewnętrzna (w odrębnej lokalizacji geograficznej)
- 1 kopia niezmienna (odizolowana fizycznie lub z włączoną funkcją WORM).
3. Wdrożenie rygorystycznych kontroli dostępu
- Dostęp oparty na rolach (RBAC): ograniczanie uprawnień za pomocą ról IAM (np. polityk dostępu do skarbca AWS Backup).
- Uwierzytelnianie wieloskładnikowe (MFA): należy wymusić jego stosowanie w interfejsach zarządzania kopiami zapasowymi (np. Azure AD Conditional Access).
- Izolacja sieciowa: Należy przechowywać kopie zapasowe w prywatnych podsieciach/VPC bez publicznego dostępu do internetu.
4. Szyfrowanie danych typu end-to-end
- Dane w spoczynku: Należy stosować AES-256 lub klucze zarządzane przez KMS (AWS, Azure).
- W trakcie transmisji: TLS 1.3 dla kanałów replikacji.
- Szyfrowanie po stronie klienta: Szyfrowanie wrażliwych pól przed utworzeniem kopii zapasowej (np. AES-256 w rozwiązaniu Veeam z kluczami zarządzanymi przez użytkownika).
5. Automatyzacja przechowywania i walidacji
- Zasady retencji: Należy zdefiniować RPO/RTO i zautomatyzować reguły cyklu życia danych (np. siedmioletni okres retencji w AWS Backup Vault).
- Weryfikacja sum kontrolnych: sprawdzenie integralności danych przed replikacją i po niej (np. za pomocą funkcji skrótu SHA-256).
- Regularne audyty: należy stosować narzędzia takie jak AWS Config lub Veeam SureBackup do testowania odtwarzania danych.
6. Warstwowe zabezpieczenia w środowiskach hybrydowych
7. Zapewnienie zgodności z przepisami i nieodwracalności
- Zablokować ustawienia niezmienności po zakończeniu testów (np. stan „Enabled and locked” w usłudze Azure).
- Zgodność z regulacjami: dostosowanie do wymogów RODO (GDPR), HIPAA lub SOX z wykorzystaniem narzędzi takich jak AWS Audit Manager.
- Audyty przeprowadzane przez podmioty zewnętrzne: Należy zaplanować coroczne testy penetracyjne (np. z udziałem partnerów zatwierdzonych przez AWS).
Przykładowy przebieg procesu z wykorzystaniem AWS i Veeam
1. Kopia podstawowa: Veeam Backup & Replication do kontenera S3 z funkcją Object Lock.
2. Replikacja: AWS DataSync do regionu dodatkowego (Frankfurt → Sztokholm).
3. Weryfikacja: codzienne dzienniki CloudTrail oraz kwartalne testy odtwarzania danych.
4. Retencja: 90-dniowy okres niezmienności z szyfrowaniem KMS.
Łącząc mechanizmy niezmienności danych, kontrolę dostępu oraz hybrydową redundancję, organizacje mogą uzyskać kopie zapasowe odporne na ataki ransomware, spełniając jednocześnie wymogi w zakresie zgodności regulacyjnej.