Po pomyślnej migracji z DigitalOcean do AWS berlińska firma EdTech potrzebowała wzmocnienia bezpieczeństwa infrastruktury, aby spełnić wymagania niemieckich klientów korporacyjnych i przygotować się do certyfikacji ISO 27001.
Branża
EdTech
Lokalizacja
Berlin, Niemcy
Czas
03.2025 - obecnie (stały retainer)
Firma
Pod NDA
Klient to berlińska firma EdTech dostarczająca wielodostępową korporacyjną platformę szkoleniową i zarządzania nauczaniem, z której korzystają przedsiębiorstwa z regionu DACH. Platforma przechowuje dane szkoleniowe pracowników niemieckich i europejskich firm, a więc zgodność z niemieckim Datenschutz (federalną ustawą o ochronie danych osobowych) oraz GDPR to wymóg bazowy, nie opcja. Klient aktywnie przygotowuje się do certyfikacji ISO 27001, żeby otworzyć sobie drogę do większych kontraktów korporacyjnych - niemieckie zespoły zakupowe rutynowo wymagają ISO 27001 jako warunku podpisania umowy.
Devopsity wcześniej przeprowadziło migrację platformy klienta z DigitalOcean do AWS EKS. Po pomyślnym zakończeniu migracji współpraca przeszła w fazę wzmacniania bezpieczeństwa i przygotowania do certyfikacji ISO 27001, realizowaną w ramach naszych usług bezpieczeństwa i zgodności regulacyjnej.
Migracja z DigitalOcean do AWS rozwiązała problemy skalowalności i dała klientowi dostęp do usług klasy korporacyjnej. Infrastruktura produkcyjna działała stabilnie na EKS, ale z perspektywy bezpieczeństwa wciąż pozostawały istotne luki, które blokowały pozyskiwanie większych klientów korporacyjnych.
Brak izolacji między środowiskami. Konta development, staging i produkcja funkcjonowały w ramach jednego konta AWS. Błędna konfiguracja lub przejęcie środowiska deweloperskiego mogło doprowadzić do kompromitacji danych produkcyjnych. Zespoły zakupowe klientów korporacyjnych natychmiast wskazywały ten problem podczas ocen bezpieczeństwa.
Niekompletne zarządzanie tożsamością. Dostęp do AWS nie był jeszcze ustrukturyzowany pod kątem wymagań korporacyjnych. Brakowało wymuszania MFA na wszystkich kontach, scentralizowanego zarządzania uprawnieniami z podziałem na role i ścieżki audytu pozwalającej prześledzić, kto i kiedy uzyskiwał dostęp do poszczególnych zasobów.
Brak ochrony na warstwie aplikacji. Przed aplikacją nie stał żaden WAF, co narażało ją na typowe ataki webowe - SQL injection, cross-site scripting, automatyczne ataki botów. Dla platformy przetwarzającej dane pracowników klientów korporacyjnych to była niedopuszczalna luka.
Ograniczone szyfrowanie. Niemieckie przepisy Datenschutz wymagają wykazywalnej kontroli nad kluczami szyfrowania - administrator danych musi udowodnić, że sam zarządza kluczami chroniącymi dane pracowników, a nie tylko polega na domyślnym szyfrowaniu dostawcy chmury. Infrastruktura po migracji nie korzystała jeszcze z kluczy KMS zarządzanych przez klienta.
Brak narzędzi do zarządzania zgodnością. Brakowało ciągłego monitoringu zgodności, agregacji wyników bezpieczeństwa i wykrywania odchyleń konfiguracji. Przygotowanie do audytu ISO 27001 wymagałoby ręcznego kompletowania dowodów - żmudnego, czasochłonnego procesu, który trzeba by powtarzać przy każdym audycie nadzorczym.
Podsumowując: infrastruktura po migracji była stabilna i skalowalna, ale klient nie był w stanie przejść ocen bezpieczeństwa działów zakupów korporacji, nie mógł dążyć do ISO 27001 i nie potrafił wykazać zabezpieczeń, jakich niemieckie przedsiębiorstwa oczekują od dostawcy przetwarzającego dane ich pracowników.
Rozdzieliliśmy środowiska na trzy oddzielne konta w ramach AWS Organisation - osobne dla development, staging i produkcji. Takie rozwiązanie zapewnia twarde granice bezpieczeństwa między środowiskami. Przejęcie środowiska deweloperskiego nie daje dostępu do danych produkcyjnych, ponieważ znajdują się one w osobnym koncie AWS bez ścieżek dostępu między kontami, chyba że zostaną jawnie zdefiniowane.
Polityki Service Control Policies (SCP) wymuszają reguły ochronne w całej organizacji na wszystkich trzech kontach - blokują m.in. wyłączanie CloudTrail, usuwanie rejestratorów Config, tworzenie użytkowników IAM z dostępem konsolowym czy pozostawianie publicznie dostępnych bucketów S3. Te reguły obowiązują niezależnie od uprawnień poszczególnych ról IAM w ramach danego konta.
Każde konto posiada własny VPC z odpowiednią segmentacją podsieci - podsieci publiczne dla load balancerów, prywatne dla zasobów obliczeniowych i danych. Architektura jest identyczna we wszystkich trzech kontach, wdrażana z tych samych modułów Terraform ze zmiennymi specyficznymi dla środowiska.
Dostęp osób opiera się na dedykowanych użytkownikach IAM z obowiązkowym MFA we wszystkich trzech kontach. Użytkownicy są przypisani do grup odpowiadających funkcjom zawodowym (inżynierowie, deweloperzy, dostęp tylko do odczytu), a uprawnienia są dołączone do grup, nie do poszczególnych użytkowników. Narzędzie aws-vault jest obowiązkowe dla całego dostępu z wiersza poleceń - zarządza tymczasowymi poświadczeniami sesji STS z weryfikacją MFA przy każdej operacji. Migracja do IAM Identity Center jest w harmonogramie współpracy jako kolejne usprawnienie w obszarze tożsamości.
Wewnątrz klastrów EKS mechanizm IAM Roles for Service Accounts (IRSA) zapewnia odrębne uprawnienia IAM na poziomie pojedynczego poda. Każde obciążenie wymagające dostępu do AWS ma własne konto serwisowe Kubernetes powiązane z dedykowaną rolą IAM przez federację OIDC. Żadne dwa pody nie współdzielą roli IAM i nie istnieją role obejmujące cały klaster dla obciążeń aplikacyjnych. Oznacza to, że przejęty pod może uzyskać dostęp wyłącznie do tych zasobów AWS, na które pozwala jego rola IRSA - nie do całego konta.
External Secrets Operator łączy AWS Secrets Manager z Kubernetes. Sekrety aplikacyjne (poświadczenia bazodanowe, klucze API, tokeny integracyjne) przechowywane są w Secrets Manager i automatycznie synchronizowane jako natywne sekrety Kubernetes. Deweloperzy nie mają bezpośredniego kontaktu z Secrets Manager i nigdy nie obsługują produkcyjnych poświadczeń. Rola IRSA samego External Secrets Operator jest ograniczona wyłącznie do konkretnych sekretów, które musi synchronizować.
Polityki sieciowe Kubernetes stanowią dodatkową warstwę kontroli dostępu wewnątrz klastra, świadomą tożsamości serwisów. Komunikować się mogą tylko te pody, które tego potrzebują - przejęty pod w jednym serwisie nie jest w stanie dotrzeć do podów innego serwisu, nawet w ramach tego samego klastra.
AWS WAF stoi przed Application Load Balancerem i filtruje ruch, zanim dotrze do aplikacji. Zarządzane zestawy reguł blokują typowe ataki webowe - SQL injection, cross-site scripting i znane wzorce złośliwych botów. To była dokładnie ta luka, na którą wskazywały zespoły zakupowe klientów korporacyjnych.
WAF integruje się z ALB natywnie - nie jest potrzebny dodatkowy serwer proxy ani urządzenie pośredniczące. Zestawy reguł są zarządzane przez AWS i aktualizowane automatycznie w miarę identyfikacji nowych wzorców ataków. Reguły specyficzne dla klienta (listy dozwolonych adresów IP, ograniczanie częstotliwości żądań) dodajemy przez Terraform w razie potrzeby.
Wszystkie dane w spoczynku są szyfrowane przy użyciu kluczy AWS KMS zarządzanych przez klienta. Instancje RDS (PostgreSQL i MySQL), buckety S3 i wolumeny EBS korzystają z szyfrowania KMS. To kluczowe rozróżnienie z perspektywy niemieckich przepisów ochrony danych - klient może wykazać regulatorom i klientom korporacyjnym, że sam kontroluje klucze szyfrowania chroniące dane pracowników, a nie jedynie polega na domyślnym szyfrowaniu dostawcy chmury.
Wszystkie dane w tranzycie są chronione protokołem TLS. Publiczne punkty końcowe działają po HTTPS z certyfikatami zarządzanymi przez AWS Certificate Manager z automatycznym odnawianiem. Połączenia bazodanowe z podów aplikacyjnych do RDS korzystają z SSL.
AWS CloudTrail jest włączony we wszystkich regionach na wszystkich trzech kontach i rejestruje każde wywołanie API. Logi trafiają do dedykowanych bucketów S3 z wersjonowaniem, ochroną przed usunięciem i włączoną walidacją plików logów. Daje to kompletną, odporną na manipulacje ścieżkę audytu, jakiej oczekują audytorzy ISO 27001.
AWS Config rejestruje w trybie ciągłym wszystkie obsługiwane typy zasobów. Config śledzi każdą zmianę konfiguracji każdego zasobu AWS i prowadzi oś czasu umożliwiającą analizę historyczną - np. „jak wyglądała ta grupa zabezpieczeń przed zmianą z zeszłego tygodnia?”. Reguły Config monitorują zgodność z poziomami odniesienia bezpieczeństwa i zgłaszają odchylenia, gdy zasoby odbiegają od zgodnej konfiguracji.
CloudWatch gromadzi metryki i logi ze wszystkich komponentów infrastruktury. Logi podów EKS są dostarczane przez Fluent Bit do CloudWatch Logs, uporządkowane według przestrzeni nazw i serwisu. Alarmy CloudWatch reagują na progi istotne z perspektywy bezpieczeństwa - cykliczne restarty podów (potencjalna próba ataku), skoki wskaźnika błędów ALB oraz nagły wzrost zablokowanych żądań WAF sygnalizujący potencjalne ataki.
Dedykowane funkcje Lambda automatyzują tworzenie kopii zapasowych z replikacją między regionami dla krytycznych danych. Automatyczne kopie RDS zapewniają odtwarzanie bazy danych do dowolnego punktu w czasie. Całą infrastrukturę - wraz ze wszystkimi mechanizmami bezpieczeństwa - można odtworzyć z kodu Terraform. Procedury odtwarzania są opisane w runbookach i omawiane z zespołem inżynieryjnym klienta.
Każdy opisany powyżej mechanizm bezpieczeństwa jest zdefiniowany w Terraform - wielokontowa struktura Organization, polityki SCP, architektura sieciowa VPC, grupy zabezpieczeń, reguły WAF, klucze KMS, konfiguracje Secrets Manager, role IRSA, polityki sieciowe Kubernetes, CloudTrail i Config. Zmiany przechodzą przez recenzowane pull requesty ze szczególną uwagą na konsekwencje dla bezpieczeństwa. Te same moduły Terraform wdrażają identyczne poziomy odniesienia bezpieczeństwa na wszystkich trzech kontach - środowiska development i staging mają te same zabezpieczenia co produkcja.
Migracja początkowa koncentruje się na przeniesieniu obciążeń, architektury i optymalizacji kosztów. Bezpieczeństwo na tym etapie jest wystarczające, ale szybko wymaga dedykowanego skupienia, żeby dojść do standardu ISO 27001. Potraktowanie bezpieczeństwa jako odrębnego strumienia prac zaraz po migracji - zamiast dorabiania go w późniejszym terminie - pozwoliło uniknąć znacznego przerabiania.
Bezpieczeństwo to droga, nie punkt docelowy. Regularne wewnętrzne audyty i przesuwanie odpowiedzialności za bezpieczeństwo bliżej zespołów deweloperskich są kluczowe, ale same w sobie niczego nie gwarantują. Odchylenia konfiguracji mogą i będą się pojawiać - pytanie brzmi, czy wykryjemy je w godzinach, czy dopiero po miesiącach.
Współpraca kontynuowana jest jako stały retainer. Przygotowujemy się do pierwszego audytu certyfikacyjnego ISO 27001 klienta - wielokontowa architektura, szyfrowanie, zarządzanie dostępem, ścieżki audytu i monitoring zgodności były od początku projektowane z uwzględnieniem mapowania na kontrole ISO 27001. Wśród planowanych usprawnień znajdują się wdrożenie AWS Security Hub ze standardami CIS i FSBP do scentralizowanego zarządzania wynikami bezpieczeństwa, włączenie GuardDuty do wykrywania zagrożeń opartego o uczenie maszynowe oraz migracja z użytkowników IAM do IAM Identity Center w celu scentralizowanego SSO.
Usługi AWS: Amazon EKS, Amazon ECR, Application Load Balancer, AWS WAF, Amazon RDS (PostgreSQL, MySQL), AWS DMS, AWS Secrets Manager, AWS KMS, AWS IAM, Amazon CloudWatch, AWS CloudTrail, AWS Config, AWS Lambda, Amazon S3, AWS Certificate Manager, Amazon Route53
Narzędzia: Terraform, GitHub Actions, Docker, aws-vault, Fluent Bit, External Secrets Operator, Helm
Po zakończeniu migracji z DigitalOcean do AWS Devopsity wzmocniło infrastrukturę klienta - wdrożyło wielokontową architekturę z izolacją środowisk, szyfrowanie KMS z kluczami zarządzanymi przez klienta, ochronę WAF na warstwie aplikacji i ciągły monitoring zgodności. Platforma spełnia teraz wymagania weryfikacji bezpieczeństwa niemieckich klientów korporacyjnych i jest przygotowana do pierwszego audytu certyfikacyjnego ISO 27001.