Brytyjska platforma healthcare przetwarzająca wrażliwe dane zdrowotne z integracjami NHS wymagała gruntownej transformacji bezpieczeństwa - od współdzielonych kont IAM i braku logowania po warstwową ochronę infrastruktury, szyfrowanie i ciągły monitoring.
Branża
Medtech, Healthcare
Lokalizacja
Wielka Brytania
Czas
06.2025 - obecnie (stały retainer)
Firma
Pod NDA
Klient to brytyjska platforma zdrowia i wellbeing, która łączy użytkowników ze specjalistami medycznymi i usługami społecznymi. Platforma przetwarza wrażliwe dane zdrowotne i integruje się z systemami NHS, co wymaga zgodności z brytyjskim standardem Cyber Essentials Plus oraz GDPR. Wśród funkcjonalności znajdują się katalogi placówek medycznych, skierowania do specjalistów, zarządzanie kalendarzem oraz wyszukiwarka i silnik rekomendacji oparty o sztuczną inteligencję. Zespół inżynieryjny klienta jest niewielki i nie dysponował dedykowaną funkcją bezpieczeństwa ani infrastruktury - Devopsity pełni rolę jedynego partnera odpowiedzialnego za infrastrukturę chmurową i bezpieczeństwo operacyjne.
Devopsity wcześniej przeprowadziło modernizację infrastruktury klienta z EC2 do ECS Fargate z RDS. Po zakończeniu modernizacji współpraca przeszła w fazę wzmacniania bezpieczeństwa, która jest przedmiotem niniejszego opisu. To zlecenie realizowane jest w ramach naszych usług bezpieczeństwa i zgodności regulacyjnej.
W momencie rozpoczęcia współpracy środowisko AWS klienta nie miało żadnych formalnych zabezpieczeń. Platforma działała na gołych instancjach EC2, a wdrożenia odbywały się ręcznie przez SSH. Lista problemów bezpieczeństwa była poważna:
Brak zarządzania tożsamością. Dostęp do AWS opierał się na współdzielonych użytkownikach IAM z długotrwałymi kluczami. Nikt nie wymuszał MFA, nie istniał podział odpowiedzialności między środowiskiem deweloperskim a produkcyjnym i brakowało jakiejkolwiek ścieżki audytu. Poświadczenia leżały w plikach konfiguracyjnych otwartym tekstem, a członkowie zespołu przesyłali je sobie przez czat.
Brak ochrony infrastruktury. Grupy zabezpieczeń były nadmiernie otwarte - niektóre wpuszczały ruch z szerokich zakresów adresów. Nie było WAF-a, kilka magazynów danych nie miało szyfrowania w spoczynku, a sieć nie dzieliła serwisów na segmenty. Baza danych przyjmowała połączenia z dowolnego źródła w VPC zamiast wyłącznie z serwisów aplikacyjnych.
Brak widoczności. CloudTrail nie był włączony, więc nie istniał żaden zapis aktywności API. Monitoring CloudWatch działał w minimalnym zakresie. Brakowało skanowania podatności, punktu odniesienia dla zgodności regulacyjnej i scentralizowanego widoku stanu bezpieczeństwa. Gdyby poświadczenia zostały przejęte, nie byłoby sposobu, żeby to wykryć.
Luka w zgodności regulacyjnej stanowiła najpilniejszy problem biznesowy. Klient przetwarza dane zdrowotne powiązane z NHS i musiał wykazać zgodność z Cyber Essentials Plus oraz GDPR. Bez kontroli dostępu, szyfrowania, logowania audytowego i udokumentowanych praktyk bezpieczeństwa nie mógł spełnić tych wymagań - ani wiarygodnie zapewnić partnerów i użytkowników, że dane zdrowotne są obsługiwane odpowiedzialnie.
Wymieniliśmy cały model dostępu. Współdzieleni użytkownicy IAM zostali zlikwidowani i zastąpieni indywidualnie rozliczalnymi kontami:
Dostęp osób - skonfigurowaliśmy SSO, z którego korzystają wszyscy uprawnieni. Inżynierowie używają aws-vault do obsługi wiersza poleceń - narzędzie zarządza tymczasowymi poświadczeniami sesji STS i zapobiega zapisywaniu długotrwałych kluczy na dysku. Standardowy wzorzec wywołania - aws-vault exec profile-prod -- <polecenie> - gwarantuje, że każda operacja opiera się na krótkotrwałych poświadczeniach z weryfikacją MFA.
Dostęp serwisów - każdy serwis ECS Fargate otrzymał dedykowaną parę ról IAM: rolę wykonania zadania (do pobierania obrazów z ECR i zapisu logów do CloudWatch) oraz rolę zadania (do dostępu aplikacyjnego do Secrets Manager, SSM Parameter Store i pozostałych API AWS). Żadne dwa serwisy nie współdzielą roli. Każda rola stosuje zasadę minimalnych uprawnień - konkretne akcje API ograniczone do konkretnych ARN-ów zasobów, bez symboli wieloznacznych. Gdy na platformie pojawia się nowy serwis, tworzymy dla niego odrębną rolę z wyłącznie niezbędnymi uprawnieniami.
Dostęp CI/CD - GitHub Actions uwierzytelnia się w AWS przez federację OIDC z dedykowaną rolą IAM github-deployer-production. Polityka zaufania jest ograniczona do konkretnej organizacji GitHub, repozytorium i brancha wdrożeniowego. W GitHub nie przechowujemy żadnych kluczy dostępu AWS - poświadczenia są generowane w czasie wykonania przez STS i wygasają po zakończeniu pipeline’u. Uprawnienia roli wdrożeniowej aktualizujemy przez Terraform przy każdym dodaniu nowego serwisu.
Zarządzanie sekretami - przenieśliśmy wszystkie poświadczenia z plików tekstowych i zmiennych środowiskowych do AWS Secrets Manager. Hasła do baz danych, klucze API (w tym klucze OpenAI dla serwisu wzbogacania danych), ciągi połączeń Redis i tokeny integracji z usługami zewnętrznymi są przechowywane w Secrets Manager i wstrzykiwane do definicji zadań ECS przy uruchomieniu. SSM Parameter Store obsługuje konfigurację niewrażliwą według konwencji /{środowisko}/{nazwa-serwisu}/{nazwa-parametru}. W obrazach kontenerów nie ma niczego zapisanego na stałe - ten sam obraz działa na stagingu i produkcji, a konfiguracja specyficzna dla środowiska jest wstrzykiwana przy starcie.
Przeprojektowaliśmy architekturę sieciową tak, aby wymuszała wielowarstwową ochronę:
Grupy zabezpieczeń tworzą ścisły łańcuch reguł przychodzących. Application Load Balancer jest jedynym komponentem wystawionym do internetu (HTTPS na porcie 443). Każdy serwis ECS ma własną grupę zabezpieczeń, która przyjmuje ruch wyłącznie z grupy ALB na swoim konkretnym porcie. RDS przyjmuje tylko połączenia MySQL (port 3306) z grup zabezpieczeń serwisów ECS. OpenSearch przyjmuje połączenia wyłącznie z grup ECS. Żadna baza danych ani klaster wyszukiwania nie jest dostępny z internetu ani z serwisów, które nie potrzebują do nich dostępu. Wszystkie grupy zabezpieczeń są zdefiniowane w Terraform - żadna reguła nie powstawała ręcznie przez konsolę.
Szyfrowanie obejmuje wszystkie ścieżki danych. RDS MySQL korzysta z szyfrowania w spoczynku przez AWS KMS. OpenSearch szyfruje w spoczynku wszystkie dane indeksów i automatyczne migawki. Buckety S3 (w tym stan Terraform) używają szyfrowania po stronie serwera. Tymczasowa pamięć ECS Fargate jest domyślnie szyfrowana w spoczynku. Wszystkie publiczne punkty końcowe działają po HTTPS z certyfikatami SSL/TLS zarządzanymi przez AWS Certificate Manager z automatycznym odnawianiem.
Wdrożyliśmy pełne logowanie i monitoring tam, gdzie wcześniej nic nie istniało:
AWS CloudTrail rejestruje całą aktywność API we wszystkich regionach. Logi trafiają do dedykowanego bucketa S3 z włączonym wersjonowaniem i ochroną przed usunięciem. Daje to kompletną ścieżkę audytu każdej zmiany IAM, modyfikacji grup zabezpieczeń, wdrożenia ECS i operacji na danych. Walidacja plików logów CloudTrail jest aktywna, co pozwala wykryć próby manipulacji.
Amazon CloudWatch gromadzi metryki ze wszystkich komponentów infrastruktury - stan serwisów ECS (procesor, pamięć, liczba zadań), wydajność RDS (połączenia, IOPS, wolna pamięć), kondycja klastra OpenSearch (obciążenie pamięci, opóźnienie wyszukiwania, status klastra) oraz metryki ALB (czasy odpowiedzi, wskaźniki błędów, liczba zdrowych hostów). CloudWatch Container Insights zapewnia granularność na poziomie poszczególnych kontenerów.
Alarmy CloudWatch reagują na krytyczne progi istotne z perspektywy bezpieczeństwa - zadania ECS nieprzechodzące kontroli stanu, obciążenie pamięci OpenSearch przekraczające bezpieczne limity, wyczerpanie połączeń RDS oraz skoki wskaźnika błędów 5xx na ALB. Dzięki tym alarmom udało nam się proaktywnie wykryć i rozwiązać problem z obciążeniem pamięci OpenSearch (90–95% SysMemoryUtilization), zanim spowodował awarię wyszukiwania na produkcji.
Wszystkie serwisy ECS wysyłają ustrukturyzowane logi aplikacyjne do CloudWatch Logs przez sterownik awslogs, uporządkowane według serwisu i środowiska. Grupy logów stosują spójną konwencję nazewnictwa, co umożliwia śledzenie żądań między serwisami na potrzeby analizy incydentów.
Każdy opisany powyżej mechanizm bezpieczeństwa jest zdefiniowany i zarządzany w Terraform/Terragrunt. Repozytorium infrastruktury jest zorganizowane według konta, regionu i środowiska, z wielokrotnie wykorzystywanymi modułami dla grup zabezpieczeń, ról IAM, kluczy KMS i konfiguracji Secrets Manager. Zmiany w infrastrukturze bezpieczeństwa przechodzą przez ten sam proces recenzji pull requestów co każda inna zmiana - recenzent weryfikuje, czy polityki IAM stosują zasadę minimalnych uprawnień, czy reguły grup zabezpieczeń są restrykcyjne i czy ustawienia szyfrowania są poprawne, zanim zmiana zostanie wdrożona.
Takie podejście oznacza, że stan bezpieczeństwa jest wersjonowany, audytowalny (każda zmiana to commit z autorem i recenzją) i odtwarzalny. Jeśli reguła grupy zabezpieczeń wymaga zbadania, możemy prześledzić ją do konkretnego pull requesta, recenzenta i operacji terraform apply, która ją utworzyła.
Nakład pracy związany z komponentami odziedziczonymi z poprzedniej architektury okazał się większy niż zakładano. Bezpieczeństwo rywalizuje z ekonomią biznesową o uwagę i budżet, co tworzy unikalny zestaw ograniczeń. Te ograniczenia bywają wymagające, ale jednocześnie wymuszają pragmatyczne rozwiązania - a to sprawia, że praca nad nimi jest naprawdę satysfakcjonująca.
Fundament bezpieczeństwa jest gotowy, a współpraca kontynuowana jest jako stały retainer. Zarządzamy bezpieczeństwem operacyjnym produkcji, wdrażamy nowe serwisy z tymi samymi mechanizmami ochrony od pierwszego dnia i rozbudowujemy zabezpieczenia w miarę rozwoju platformy. W planach jest migracja do IAM Identity Center w celu zastąpienia użytkowników IAM scentralizowanym SSO. Na liście kolejnych kroków znajdują się AWS Security Hub, GuardDuty i Inspector - dodadzą wykrywanie zagrożeń oparte o uczenie maszynowe, scentralizowane zarządzanie wynikami bezpieczeństwa oraz ciągłe skanowanie podatności kontenerów.
Usługi AWS: Amazon ECS (Fargate), Amazon ECR, Application Load Balancer, Amazon RDS (MySQL), Amazon OpenSearch Service, AWS Secrets Manager, AWS Systems Manager Parameter Store, AWS KMS, AWS Certificate Manager, AWS IAM (OIDC Federation), Amazon CloudWatch, AWS CloudTrail, Amazon Route53, Amazon S3
Narzędzia: Terraform, Terragrunt, GitHub Actions, Docker
Devopsity przekształciło środowisko AWS klienta - od zerowego poziomu bezpieczeństwa do w pełni kontrolowanej infrastruktury z indywidualnie rozliczalnym dostępem, warstwową izolacją sieciową, szyfrowaniem na wszystkich warstwach i kompletną ścieżką audytu. Platforma spełnia teraz wymagania Cyber Essentials Plus i GDPR z udokumentowanymi dowodami na każdym poziomie.