Islandzka firma fintech obsługująca rynek amerykański potrzebowała certyfikacji SOC2 Type II i pozytywnego przejścia weryfikacji due diligence dużego banku amerykańskiego. Devopsity podniosło istniejącą infrastrukturę AWS do standardów SOC2, wdrożyło pełny stos zabezpieczeń i objęło całodobowy nadzór nad bezpieczeństwem w ramach umowy SLA.
Branża
Fintech, finansowanie nieruchomości
Lokalizacja
Stany Zjednoczone / Islandia
Czas
2025 - obecnie (stały retainer)
Firma
Pod NDA
Klient to islandzka firma fintech zarejestrowana w USA, oferująca bezgotówkową alternatywę dla tradycyjnych kaucji najmu. Dzięki ich platformie najemcy mogą wprowadzić się do mieszkania bez wpłacania jednorazowego depozytu, a właściciele mają gwarancję dostępności środków w razie potrzeby. Firma liczy ok. 20 pracowników w Stanach Zjednoczonych i Islandii i nie posiada dedykowanego zespołu ds. bezpieczeństwa ani infrastruktury.
Platforma przetwarza transakcje finansowe i przechowuje wrażliwe dane osobowe oraz finansowe najemców i właścicieli. Bezpieczeństwo i zgodność regulacyjna to warunek konieczny działania, nie opcja. Klient musiał uzyskać certyfikację SOC2 Type II, żeby spełnić wymagania partnerów biznesowych, oraz pomyślnie przejść weryfikację due diligence dużego banku amerykańskiego - dwa kamienie milowe decydujące o dalszym rozwoju firmy. To zlecenie realizowane jest w ramach naszych usług bezpieczeństwa i zgodności regulacyjnej.
Devopsity dołączyło do projektu na etapie wejścia na produkcję. Środowiska przedprodukcyjne (development, staging) istniały już wcześniej, ale nie spełniały standardów wymaganych przez SOC2. Naszym zadaniem było podniesienie całej infrastruktury do poziomu zgodnego z SOC2 Type II - zarówno przez rozbudowę środowiska produkcyjnego, jak i wdrożenie mechanizmów bezpieczeństwa na wszystkich warstwach.
Brak funkcji bezpieczeństwa w organizacji. Dwudziestoosobowy zespół skupiał się na rozwoju produktu. Nikt nie zajmował się monitoringiem bezpieczeństwa, analizą podatności, badaniem zagrożeń ani utrzymywaniem zgodności regulacyjnej. Klient potrzebował zewnętrznego Cloud SOC (Security Operations Center) działającego w trybie ciągłym - nie jednorazowego audytu.
Wymóg certyfikacji SOC2 Type II. Partnerzy bankowi i klienci korporacyjni traktowali SOC2 jako minimum. SOC2 Type II wymaga nie tylko wdrożenia zabezpieczeń, ale udowodnienia, że działają one skutecznie przez dłuższy czas. To oznacza ciągłe gromadzenie dowodów, a nie sprint przygotowawczy tuż przed audytem.
Nadchodząca weryfikacja due diligence przez duży bank amerykański. Ocena banku obejmowała zarządzanie tożsamością i dostępem, szyfrowanie, zarządzanie podatnościami, wykrywanie incydentów i reagowanie na nie, a także kopie zapasowe i odtwarzanie danych. Negatywny wynik oznaczałby zablokowanie kluczowego partnerstwa.
Infrastruktura musiała bezpiecznie obsługiwać transakcje finansowe. Mikroserwisy komunikujące się przez granice sieciowe, bazy danych z danymi finansowymi i frontend dla użytkowników końcowych - wszystko wymagało zaprojektowania z myślą o bezpieczeństwie od pierwszego dnia produkcji.
Rozbudowaliśmy i przebudowaliśmy infrastrukturę produkcyjną AWS z wykorzystaniem Terraform, wbudowując mechanizmy bezpieczeństwa w każdą warstwę architektury.
Architektura sieciowa opiera się na dwóch oddzielnych VPC - Application VPC i Data VPC - połączonych przez VPC Peering. Takie rozdzielenie sprawia, że warstwa danych (bazy RDS, broker wiadomości RabbitMQ, ElastiCache Redis) nie ma bezpośrediego dostępu do internetu. Serwisy aplikacyjne z Application VPC łączą się z warstwą danych wyłącznie przez połączenie peeringowe i tylko na ściśle określonych portach wymuszonych przez grupy zabezpieczeń. Nawet jeśli kontener aplikacyjny zostanie przejęty, atakujący nie uzyska z niego dostępu do internetu w Data VPC. Z kolei uzyskanie dostępu sieciowego do Application VPC nie wystarczy do dotarcia do baz danych - trzeba jeszcze pokonać połączenie peeringowe i przejść przez reguły grup zabezpieczeń.
W Application VPC serwisy ECS Fargate działają w prywatnych podsieciach rozmieszczonych w strefach us-east-1a i us-east-1b. Jedynym komponentem dostępnym z internetu jest Application Load Balancer w podsieciach publicznych. Frontend jest serwowany z bucketa S3 przez CloudFront. Bastion host zapewnia kontrolowany dostęp administracyjny do serwisów wewnętrznych - ograniczony grupami zabezpieczeń do autoryzowanych adresów IP.
Każda grupa zabezpieczeń, podsieć, tablica routingu, połączenie peeringowe i lista kontroli dostępu (ACL) jest zdefiniowana w Terraform. Żaden element infrastruktury sieciowej nie powstawał ręcznie przez konsolę AWS.
Dostęp wszystkich użytkowników opiera się na kontach IAM z obowiązkowym MFA. Narzędzie aws-vault zarządza tymczasowymi sesjami STS przy każdej operacji z poziomu wiersza poleceń. Devopsity pełni rolę strażnika dostępu - każde żądanie uprawnień jest oceniane pod kątem zasady minimalnych uprawnień, zatwierdzane lub odrzucane, a decyzja jest dokumentowana jako materiał dowodowy na potrzeby audytu SOC2.
Każdy serwis ECS i każda instancja EC2 posiada dedykowaną rolę IAM ograniczoną wyłącznie do niezbędnych akcji API i konkretnych zasobów (ARN). Żadne dwa serwisy nie współdzielą ról. Dostęp do bastion hosta jest ograniczony do autoryzowanych administratorów przez reguły grup zabezpieczeń filtrujące po źródłowym adresie IP.
Wszystkie dane uwierzytelniające aplikacji - hasła do baz danych, klucze API, tokeny integracyjne - przechowywane są w AWS Secrets Manager. W kodzie źródłowym i plikach konfiguracyjnych nie ma żadnych poświadczeń zapisanych na stałe. Klucze KMS zarządzane przez klienta szyfrują wszystkie dane w spoczynku: w RDS, ElastiCache, DynamoDB, S3 i na wolumenach EBS.
Wdrożyliśmy pełen stos natywnych usług bezpieczeństwa AWS i obsługujemy go codziennie jako zewnętrzna funkcja bezpieczeństwa klienta:
AWS Security Hub pełni rolę centralnego panelu, gromadzącego wyniki z GuardDuty, Inspector i Config w jednym priorytetyzowanym widoku. Devopsity przegląda Security Hub codziennie w ramach umowy SLA - wyniki krytyczne uruchamiają natychmiastowe dochodzenie, a wyniki o wysokim priorytecie są naprawiane w ustalonych ramach czasowych.
Amazon GuardDuty zapewnia ciągłe wykrywanie zagrożeń na podstawie VPC Flow Logs, zdarzeń zarządzania CloudTrail i logów zapytań DNS. Wyniki o krytycznym i wysokim priorytecie uruchamiają alerty PagerDuty, dzięki czemu zespół operacyjny Devopsity jest powiadamiany w czasie rzeczywistym.
Amazon Inspector prowadzi ciągłe skanowanie podatności obrazów kontenerów w ECR oraz instancji EC2. Obrazy są skanowane przy każdym wypchnięciu do ECR i automatycznie ponownie sprawdzane po opublikowaniu nowych CVE. Instancje EC2 (bastion hosty) są skanowane pod kątem podatności na poziomie systemu operacyjnego.
AWS Config monitoruje zgodność infrastruktury, rejestrując w trybie ciągłym wszystkie typy zasobów. Reguły Config wykrywają odchylenia konfiguracji - nieszyfrowany wolumen, zbyt szeroko otwartą grupę zabezpieczeń, wyłączoną usługę logowania - i przekazują wyniki do Security Hub.
Wdrożyliśmy automatyczne nakładanie poprawek bezpieczeństwa na instancje EC2 za pośrednictwem AWS Systems Manager. Systemy są aktualizowane na bieżąco, bez ręcznej interwencji. Status zgodności łatania jest śledzony w Systems Manager i stanowi część pakietu dowodów SOC2.
Zamiast traktować SOC2 jako doroczne ćwiczenie przygotowawcze do audytu, zaprojektowaliśmy architekturę ciągłej zgodności. Platforma Vanta integruje się ze stosem bezpieczeństwa AWS i na bieżąco pobiera dowody zgodności: konfiguracje IAM, status szyfrowania, status logowania, wyniki skanowania podatności, przeglądy dostępu i status łatania. Vanta automatycznie przypisuje te dane do kryteriów SOC2 Trust Service.
Oznacza to, że stan zgodności SOC2 klienta jest zawsze aktualny. Kiedy audytor przystępuje do oceny, dowody są już zgromadzone i uporządkowane. Bez gorączki na ostatnią chwilę, bez ręcznego kompletowania materiałów, bez luk w dokumentacji.
Zaprojektowaliśmy i wdrożyliśmy plan reagowania na incydenty zintegrowany z powiadomieniami na Slacku. Wyniki z GuardDuty i Security Hub o krytycznym i wysokim priorytecie automatycznie tworzą incydenty w PagerDuty. Devopsity pełni rolę pierwszej linii reakcji - klasyfikuje zdarzenie, prowadzi dochodzenie i przeprowadza naprawę w ramach SLA. Plan reagowania obejmuje udokumentowane kryteria klasyfikacji, ścieżki eskalacji, procedury komunikacji i szablony przeglądów poincydentowych.
Zespół regularnie ćwiczy plan reagowania, aby zapewnić sprawne odtwarzanie usług podczas rzeczywistych zdarzeń. Procedury DR obejmują przywracanie baz danych (RDS point-in-time recovery), ponowne wdrożenie aplikacji (cofnięcie definicji zadań ECS z ECR) oraz odtwarzanie danych z kopii zapasowych.
Wdrożyliśmy strategię tworzenia kopii zapasowych z 7-letnią retencją, zgodną z wymogami regulacyjnymi branży finansowej. Automatyczne kopie RDS umożliwiają odtwarzanie baz danych do dowolnego punktu w czasie. Dedykowane funkcje Lambda z orkiestracją Step Functions obsługują zaplanowane kopie zapasowe z replikacją między regionami dla krytycznych danych. Polityki cyklu życia S3 przenoszą starsze kopie przez kolejne klasy przechowywania, optymalizując koszty długoterminowej retencji. Procedury odtwarzania są opisane w runbookach i regularnie testowane.
Pipeline CI/CD działa na GitLab CI z GitLab Runnerem wdrożonym w Application VPC. Pipeline automatyzuje proces budowania, testowania i wdrażania, zapewniając spójne i powtarzalne wdrożenia bez ręcznej interwencji. Obrazy kontenerów trafiają do ECR, gdzie Inspector skanuje je automatycznie. Wdrożenia do ECS realizowane są metodą rolling update z walidacją kontroli stanu.
Wdrożyliśmy automatyczne skalowanie harmonogramowe - zadania cron podnoszą zasoby w godzinach pracy i redukują je poza szczytem. Klient płaci za moc obliczeniową tylko wtedy, gdy jest rzeczywiście potrzebna. Rozmiary zasobów są dobierane na podstawie danych o wykorzystaniu z CloudWatch. Alarmy CloudWatch monitorują anomalie wydajnościowe i nieoczekiwane skoki kosztów, które mogą wskazywać na przejęte lub błędnie skonfigurowane zasoby.
Był to złożony projekt, mimo że wyjściowa infrastruktura na pierwszy rzut oka wyglądała na zaprojektowaną z myślą o bezpieczeństwie. Dodatkowe wymagania ze strony nowych partnerów biznesowych i nieustannie zmieniający się krajobraz zagrożeń tworzą stałą potrzebę doskonalenia i innowacji. SOC2 to nie jednorazowe odznaczenie - to ciągłe zobowiązanie operacyjne wymagające dedykowanych narzędzi i zdyscyplinowanej codziennej praktyki.
Certyfikacja SOC2 i weryfikacja bankowa to pierwsze kamienie milowe - współpraca kontynuowana jest jako stały retainer Cloud SOC. Devopsity w dalszym ciągu pełni funkcję centrum operacji bezpieczeństwa klienta: codziennie przegląda Security Hub w ramach SLA, utrzymuje aktualne dowody zgodności w Vanta, reaguje na wyniki z GuardDuty i Inspector oraz wspiera klienta przy kolejnych weryfikacjach ze strony nowych partnerów bankowych i zarządców nieruchomości. Wśród planowanych usprawnień znajdują się migracja z użytkowników IAM do IAM Identity Center (scentralizowane SSO) oraz rozszerzenie ochrony GuardDuty o ECS Runtime Monitoring.
Usługi AWS: Amazon ECS (Fargate), Amazon ECR, Amazon EC2 (bastion hosty, GitLab Runner), Application Load Balancer, Amazon CloudFront, Amazon RDS, Amazon ElastiCache, Amazon MQ (RabbitMQ), Amazon DynamoDB, AWS Security Hub, Amazon GuardDuty, Amazon Inspector, AWS Config, AWS WAF, AWS IAM, AWS Secrets Manager, AWS KMS, AWS Systems Manager, Amazon CloudWatch, AWS CloudTrail, AWS Lambda, AWS Step Functions, Amazon SNS, Amazon SQS, Amazon SES, AWS Certificate Manager, Amazon Route53, Amazon S3
Narzędzia: Terraform, GitLab CI, Docker, aws-vault, PagerDuty, Vanta
Devopsity podniosło istniejącą infrastrukturę AWS klienta do standardów SOC2 Type II - wdrożyło architekturę dwóch VPC z izolacją warstwy danych, warstwowe grupy zabezpieczeń, szyfrowanie KMS, ciągłe skanowanie podatności i wykrywanie zagrożeń w czasie rzeczywistym. Całość zdefiniowana w Terraform. Klient pomyślnie przeszedł weryfikację due diligence dużego banku amerykańskiego i kontynuuje proces certyfikacji SOC2 Type II z automatycznym gromadzeniem dowodów zgodności.