Usługi / Fintech i instytucje finansowe
FintechProjektujemy i utrzymujemy infrastrukturę pod płatności, audyt i pik
Projektujemy, wdrażamy i utrzymujemy infrastrukturę pod płatności, audyt i pik. Zaczynamy od ścieżki transakcji: bramka, kolejka, baza, dane kartowe, RTO i kto zgłasza incydent. Potem stawiamy ślad zmian, SLO, test piku i dwa tory kopii. Kontrole DORA, KNF i PCI są w systemie. Zostajemy przy dyżurze, restore i raporcie.
Jak to składa się w całość
Od ścieżki płatności do śladu, piku i ciągłości
Najpierw rozumiemy bramkę, dane kartowe i RTO. Na tej podstawie składamy detekcję, obserwowalność, obciążenie i kopie. Wazuh, Grafana, k6 i Proxmox Backup Server służą do tej pracy na co dzień.
- Kontrole DORA, KNF i PCI są w infrastrukturze i w rytmie, razem z polityką.
- Oszczędność FinOps ustawiamy tak, żeby nie łamać SLO ani segmentacji CDE.
Trzymamy ślad zmiany, dostępu i incydentu
Logi z hostów, klastra, chmury i krawędzi schodzą do Wazuh. FIM na konfiguracji płatności. SCA pod CIS. Alert ma procedurę i retencję pod audytora. To podstawa DORA w operacji, razem z polityką.
Dostęp
SSO, MFA, PAM do produkcji. Każde wejście w śladzie.
Zmiana
Deploy, grant, zmiana SG. Powiązanie z biletem zmiany.
Incydent
Priorytet, czas detekcji, czas odpowiedzi. Materiał pod raportowanie.
PCI
Segmentacja, FIM na CDE, skrócony dostęp. Zakres kartowy jest osobną strefą.
Pilnujemy SLO transakcji i infrastruktury
p95 autoryzacji, kolejka, baza i błąd issuer schodzą do Grafany. Alert idzie, zanim kasa w sklepie poczuje timeout. Ćwiczenie failover ma metrykę, razem z protokołem.
Ścieżka
Bramka, kolejka, issuer, webhook. Każdy skok ma właściciela.
Multi-AZ
Utrata strefy w metryce. RTO spisane i mierzone.
Zmiana
Deploy widać na wykresie. Canary albo małe okno.
Raport
Dla ryzyka i dla engineeringu. Ten sam SLO, inny język.
Prowadzimy test piku przed kampanią i rozliczeniem
Scenariusz transakcji, tokenizacji, webhooków i raportów nocnych. Soak na wyciek puli. Wynik wiążemy z Grafaną. Pojemność ustalamy przed kampanią.
Model
Ruch z produkcji, uzupełniony planem kampanii.
Bramki
Timeout issuer, retry, idempotencja. Test to pokazuje.
Okno
Test na stage z danymi syntetycznymi. Produkcja ma osobne limity generatora.
Chaos
Osobna sesja: utrata bazy, kolejki, AZ.
Trzymamy restore w czasie RTO, na osobnych kluczach
Dwa tory, immutability, ćwiczenie odtworzenia bramki i bazy. Playbook offline. DORA wymaga dowodu restore, razem z oświadczeniem że kopia istnieje.
RTO i RPO
Per system płatności i per system pomocniczy. Inny budżet czasu.
Tory
Blisko i daleko, inne konta. Utrata jednego toru nie kasuje obu.
Ćwiczenie
Kalendarz restore, raport dla ryzyka.
Ludzie
Kto odtwarza, jaki DNS, jaki sekret, kto komunikuje.
Jak pracujemy
Od ścieżki płatności klienta do ćwiczenia ciągłości
Zaczynamy od systemów krytycznych i danych kartowych. Potem stawiamy ślad i SLO. Prowadzimy test piku. Zostajemy przy restore, failover i raporcie.
- Mapa Sprawdzamy CDE, bramki, kolejki, dostawców i RTO. Ustalamy, co jest w zakresie kartowym. Z tego wychodzi plan kontroli.
- Kontrole Stawiamy IAM, FIM, logi, segmentację i krawędź. Każde wejście na produkcję ma ślad.
- Odporność Ustawiamy multi-AZ, dashboard, dyżur i komunikację. SLO transakcji stoi obok SLO infrastruktury.
- Dowód Prowadzimy test obciążenia, failover i restore. Raport idzie do ryzyka i do engineeringu.
Rozmowa
Omówimy płatności, ślad i ciągłość
Na tej podstawie przygotujemy zakres: detekcja, SLO, test piku i restore.
Skontaktuj się