Globalny fintech na styku tradycyjnych finansów i aktywów cyfrowych potrzebował Cloud SOC (Security Operations Center) na poziomie bankowym. Devopsity wdrożyło pełen stos zabezpieczeń AWS, uruchomiło codzienne operacje bezpieczeństwa w ramach SLA i pomogło klientowi przejść weryfikację due diligence dużego banku amerykańskiego.
Branża
Fintech, aktywa cyfrowe
Lokalizacja
Wielka Brytania / Kajmany
Czas
01.2025 - obecnie (stały retainer)
Firma
Pod NDA
Klient to globalna platforma fintech działająca na styku tradycyjnych finansów i aktywów cyfrowych. System zarządzania portfelami inwestycyjnymi obsługuje klasyczne ETF-y i papiery wartościowe równolegle z kryptowalutami i NFT dla klientów na całym świecie. Firma zatrudnia ok. 50 pracowników i aktywnie ubiega się o brytyjską licencję bankową - co oznacza konieczność spełnienia tych samych rygorystycznych standardów bezpieczeństwa, operacyjnych i regulacyjnych co duże instytucje finansowe.
Devopsity zostało zaangażowane przez firmę programistyczną pełniącą rolę zespołu deweloperskiego klienta. Naszym zadaniem jest rola dedykowanego partnera ds. infrastruktury chmurowej i bezpieczeństwa operacyjnego - de facto zewnętrzne Cloud SOC (Security Operations Center) klienta. To zlecenie realizowane jest w ramach naszych usług bezpieczeństwa i zgodności regulacyjnej.
Devopsity wcześniej przeprowadziło szybką migrację platformy klienta z Heroku do AWS, a następnie modernizację polegającą na przejściu do ECS. Migracja priorytetyzowała szybkość - opuszczenie Heroku przed deadline’em biznesowym. Oba projekty się powiodły, ale bezpieczeństwo zostało zaadresowane w minimalnym zakresie. Kilka miesięcy po uruchomieniu produkcji na AWS przegląd Well-Architected Review ujawnił znaczne zaległości w elementach bezpieczeństwa o wysokim ryzyku.
Zarządzanie tożsamością i dostępem było chaotyczne. Dostęp do AWS opierał się na rozproszonych użytkownikach IAM z niespójnym wymuszaniem MFA. Część z nich posiadała długotrwałe klucze dostępu, które nie były rotowane. Nie istniało scentralizowane zarządzanie tożsamością, SSO ani ustrukturyzowany proces przyznawania, przeglądania i odbierania dostępu. Poświadczenia serwisów były obsługiwane niespójnie - część w Secrets Manager, reszta w zmiennych środowiskowych lub plikach konfiguracyjnych.
Oprócz podstawowej higieny IAM wymagania regulacyjne prospektu klienta nakładały znacznie surowszy obowiązek: pełne rozwiązanie Privileged Access Management na warstwie uwierzytelniania z krótkotrwałymi poświadczeniami i nagrywaniem sesji. To nie był element opcjonalny - to oczekiwanie regulacyjne bezpośrednio powiązane z wnioskiem o licencję bankową.
Brak monitoringu bezpieczeństwa. Nie było wdrożenia Security Hub, GuardDuty ani Inspector. Klient nie miał scentralizowanego widoku stanu bezpieczeństwa, skanowania podatności, wykrywania zagrożeń ani sposobu, żeby dowiedzieć się o problemie, zanim przerodzi się w pełny incydent. Wyniki przeglądu Well-Architected Review leżały w arkuszu kalkulacyjnym bez procesu naprawczego.
Luka w zgodności regulacyjnej stanowiła najpilniejszy problem biznesowy. Klient ubiegał się o brytyjską licencję bankową i musiał pomyślnie przechodzić weryfikacje due diligence partnerów finansowych. Przeglądy te wymagały dowodów scentralizowanego zarządzania dostępem, szyfrowania kluczami zarządzanymi przez klienta, ciągłego zarządzania podatnościami, procedur reagowania na incydenty, logowania audytowego, długoterminowej retencji danych oraz kontroli uprzywilejowanego dostępu z audytowalnością na poziomie sesji. Żaden z tych elementów nie był wdrożony.
Duży bank amerykański już zgłosił zastrzeżenia podczas wstępnej oceny partnerstwa. Bez wykazanej praktyki operacji bezpieczeństwa klient nie mógł kontynuować procesu ubiegania się o licencję bankową, nie mógł przejść weryfikacji partnerów i ryzykował utratę relacji instytucjonalnych kluczowych dla rozwoju firmy.
Zastąpiliśmy chaotyczną konfigurację użytkowników IAM wdrożeniem AWS IAM Identity Center na poziomie konta zarządzającego AWS Organisation. Cały dostęp osób przepływa teraz przez SSO z obowiązkowym MFA dla każdego użytkownika. Rozproszone konta IAM z czasów migracji zostały zlikwidowane - nie istnieją żadni użytkownicy IAM z hasłami konsolowymi.
Poszliśmy dalej niż podstawowe uruchomienie SSO. Nieudane próby logowania SSO są monitorowane przez filtr metryki CloudWatch, który uruchamia alert przez SNS na Slack. Daje to zespołowi widoczność potencjalnych ataków typu credential stuffing lub brute-force na warstwie tożsamości.
Wszystkie żądania dostępu ze strony zespołu deweloperskiego (pracującego przez zewnętrzną firmę programistyczną) przechodzą przez Devopsity. Oceniamy każde żądanie pod kątem zasady minimalnych uprawnień, przyznajemy odpowiedni zestaw uprawnień i dokumentujemy decyzję na potrzeby audytu. Ta rola strażnika zarządzania dostępem jest kluczowym elementem naszego SLA operacji bezpieczeństwa.
Po stronie serwisów każdy kontener ECS Fargate działa z dedykowaną parą ról IAM - rolą wykonania zadania i rolą zadania - każda ograniczona do ściśle określonych akcji API i ARN-ów zasobów. Bastion hosty (EC2) korzystają z profili instancji z ograniczonymi rolami IAM do administracyjnego dostępu do serwisów wewnętrznych. Pipeline’y CI/CD uwierzytelniają się przez federację OIDC, bez długotrwałych kluczy dostępu.
Wszystkie poświadczenia zostały przeniesione do AWS Secrets Manager z włączoną automatyczną rotacją haseł bazodanowych. Sekrety zapisane na stałe w kodzie zostały całkowicie wyeliminowane. Klucze KMS zarządzane przez klienta zapewniają szyfrowanie wszystkich danych w spoczynku.
Aby zaadresować wymóg PAM wynikający z prospektu, przeprowadziliśmy ewaluację serii komercyjnych rozwiązań PAM w ramach ustrukturyzowanych testów koncepcyjnych. Żaden z ocenianych produktów nie spełnił pełnego zestawu wymagań - jedne nie zapewniały wystarczającej granularności nagrywania sesji, inne wprowadzały nieproporcjonalną złożoność operacyjną, a koszty licencji kilku kolejnych nie były uzasadnione wobec pozostawionych luk. Po zakończeniu ewaluacji klient zdecydował się na budowę własnego rozwiązania PAM dostosowanego do swoich konkretnych wymagań regulacyjnych. Devopsity aktywnie wspiera ten rozwój, dostarczając wytyczne architektoniczne i ekspertyzę integracji z AWS.
Wdrożyliśmy pełen stos natywnych usług bezpieczeństwa AWS i ustanowiliśmy wokół niego praktykę operacyjną.
AWS Security Hub pełni rolę centralnego panelu. Działa w eu-west-1 z dwoma aktywnymi standardami - AWS Foundational Security Best Practices (FSBP) v1.0.0 i CIS AWS Foundations Benchmark v1.4.0. Funkcja AutoEnableControls jest aktywna, więc nowe kontrole są uwzględniane automatycznie w miarę ich publikowania przez AWS. Security Hub gromadzi wyniki z GuardDuty, Inspector, Config i IAM Access Analyzer w jednym priorytetyzowanym widoku.
Amazon GuardDuty zapewnia głębokie wykrywanie zagrożeń, daleko wykraczające poza podstawowy monitoring API. Włączyliśmy pełen zestaw typów ochrony: S3 Protection do wykrywania anomalnych wzorców dostępu do danych, RDS Login Events do monitorowania anomalii uwierzytelniania bazodanowego, Lambda Network Logs do wykrywania podejrzanych połączeń wychodzących z funkcji serverless oraz EBS Malware Protection do skanowania podłączonych wolumenów. Runtime Monitoring działa z agentem ECS Fargate wdrożonym na wszystkich skonteneryzowanych serwisach - zapewnia widoczność w czasie rzeczywistym na poziomie procesów wewnątrz uruchomionych kontenerów, nie tylko wywołań API. Wyniki GuardDuty o priorytecie HIGH i MEDIUM trafiają przez EventBridge i SNS na kanał Slack.
Amazon Inspector prowadzi ciągłe skanowanie podatności na wielu typach zasobów obliczeniowych. Instancje EC2, obrazy kontenerów ECR, funkcje Lambda i ich kod - wszystko jest skanowane. Obrazy ECR są skanowane automatycznie przy wypchnięciu i ponownie sprawdzane po opublikowaniu nowych CVE. Funkcje Lambda są skanowane przy wdrożeniu i ponownie weryfikowane pod kątem nowo ujawnionych podatności.
AWS Config rejestruje w trybie ciągłym wszystkie obsługiwane typy zasobów, w tym globalne zasoby IAM (role, użytkownicy, polityki, grupy) rejestrowane codziennie. Reguły Config są zarządzane przez Security Hub - standardy FSBP i CIS aktywują setki zarządzanych reguł obejmujących ACM, ALB, CloudTrail, KMS, RDS, S3, IAM i inne usługi.
To praktyka operacyjna odróżnia nasze podejście od samego włączenia usług. Devopsity przegląda Security Hub codziennie w ramach umowy SLA. Wyniki są klasyfikowane według ważności: krytyczne uruchamiają natychmiastowe dochodzenie, ważne są naprawiane w ustalonych ramach czasowych, a średnie i niskie trafiają do rejestru i są planowane do realizacji.
Efekt: średni czas naprawy podatności spadł z ponad 48 godzin do 8 godzin - poprawa o 83%. Ręczne nakłady na bezpieczeństwo zmniejszyły się o 93%.
Bezpieczeństwo sieciowe opiera się na modelu warstwowym z wszystkimi regułami zdefiniowanymi w Terraform. Jedynym komponentem wystawionym do internetu jest ALB, a CloudFront pełni rolę warstwy dystrybucji treści. Serwisy ECS przyjmują ruch wyłącznie z grupy zabezpieczeń ALB. RDS i OpenSearch przyjmują połączenia tylko z grup zabezpieczeń serwisów ECS. ElastiCache stosuje ten sam wzorzec. Żadna baza danych ani pamięć podręczna nie jest dostępna z internetu.
Wszystkie dane w spoczynku są szyfrowane kluczami KMS zarządzanymi przez klienta - RDS, OpenSearch, ElastiCache, S3 i wolumeny EBS. Dane w tranzycie są chronione protokołem TLS z certyfikatami zarządzanymi przez ACM. Klient kontroluje własne klucze szyfrowania, co jest konkretnym wymogiem regulatorów finansowych oceniających suwerenność danych.
W produkcji działają dwa wieloregionalne ślady CloudTrail, oba z włączoną walidacją plików logów i integracją z CloudWatch Logs:
Główny ślad (zarządzany przez Terraform, eu-west-1) dostarcza logi do w pełni prywatnego bucketa S3. Polityka bucketa ogranicza zapis wyłącznie do usługi CloudTrail z warunkami SourceArn - żaden inny podmiot nie może zapisywać do logu audytowego ani go modyfikować. Razem oba ślady przechwytują każde wywołanie API we wszystkich regionach.
Wdrożyliśmy strategię kopii zapasowych z 7-letnią retencją zgodną z wymogami przechowywania dokumentacji w branży finansowej. Niedawne kopie znajdują się w S3 Standard, po czym przechodzą przez Infrequent Access do Glacier, a ostatecznie do Glacier Deep Archive zgodnie z politykami cyklu życia. Dedykowane funkcje Lambda obsługują replikację między regionami dla krytycznych danych. Procedury odtwarzania po awarii są opisane w runbookach i testowane podczas corocznych ćwiczeń symulacyjnych.
Każdy mechanizm bezpieczeństwa jest zdefiniowany w Terraform. Security Hub, GuardDuty, Inspector, Config, CloudTrail, IAM Identity Center, role IAM, grupy zabezpieczeń, klucze KMS, konfiguracje Secrets Manager, funkcje Lambda obsługujące kopie zapasowe i polityki cyklu życia S3 - wszystko jest wersjonowane, recenzowane i wdrażane przez standardowy pipeline Terraform. Zmiany w infrastrukturze bezpieczeństwa przechodzą przez recenzję pull requestów ze szczególną uwagą na zakres polityk IAM i reguły grup zabezpieczeń.
Konsekwencja się opłaca. Wczesne podejście z pasywnym monitoringiem bezpieczeństwa nie pozwalało utrzymać SLA ani akceptowalnego czasu reakcji. Przejście na ustrukturyzowany codzienny przegląd z jasną klasyfikacją ważności okazało się punktem zwrotnym, który obniżył średni czas naprawy o 83%.
Gotowe rozwiązania PAM dla AWS są wyraziste w swoich założeniach i mogą nie pasować do konkretnych wymagań regulacyjnych. Czasem trzeba postawić na budowę zamiast zakupu - zwłaszcza gdy wymogi regulacyjne precyzyjnie definiują granularność nagrywania sesji i mechanikę krótkotrwałych poświadczeń.
Faza wzmacniania bezpieczeństwa przerodziła się w stały retainer Cloud SOC. Devopsity nadal pełni funkcję centrum operacji bezpieczeństwa klienta - codziennie przegląda Security Hub w ramach SLA, zarządza żądaniami dostępu, naprawia podatności, utrzymuje poziomy odniesienia zgodności i wspiera proces ubiegania się o licencję bankową. Wśród planowanych usprawnień znajdują się wdrożenie AWS WAF v2 na ALB w celu ochrony na warstwie aplikacji oraz włączenie agregacji Security Hub między regionami dla zunifikowanego widoku bezpieczeństwa.
Usługi AWS: Amazon ECS (Fargate), Amazon ECR, Amazon EC2 (bastion hosty), Application Load Balancer, Amazon CloudFront, Amazon RDS, Amazon OpenSearch Service, Amazon ElastiCache, AWS Security Hub, Amazon GuardDuty (z Runtime Monitoring), Amazon Inspector, AWS Config, AWS IAM Identity Center, AWS IAM, AWS Secrets Manager, AWS KMS, Amazon CloudWatch, AWS CloudTrail, AWS Lambda, Amazon SNS, AWS Systems Manager, AWS Chatbot, AWS Budgets, AWS Cost Anomaly Detection, Amazon S3, AWS Certificate Manager, Amazon Route53
Narzędzia: Terraform, GitHub Actions, Docker, aws-vault
Devopsity przekształciło zabezpieczenia klienta z postmigracyjnego minimum w kompletną praktykę utrzymania bezpieczeństwa na poziomie bankowym. Średni czas naprawy podatności skrócił się o 83% (z ponad 48 godzin do 8 godzin), ręczne nakłady na bezpieczeństwo zmniejszyły się o 93%, klient pomyślnie przeszedł weryfikację due diligence dużego banku amerykańskiego i osiągnął gotowość do ubiegania się o licencję bankową.