Atak na chmurę: najczęstsze błędy w konfiguracji AWS i jak je wykryć w logach

Dlaczego konfiguracja AWS jest tak często najsłabszym ogniwem

Bezpieczna platforma vs niebezpieczna konfiguracja klienta

AWS jako platforma jest bardzo dobrze zabezpieczona: centra danych, fizyczna ochrona, redundancja, kryptografia, separacja tenants – to wszystko działa, o ile nie sabotuje tego konfiguracja po stronie klienta. W praktyce większość ataków na chmurę AWS nie wynika z włamań do infrastruktury Amazona, ale z prostych, ludzkich błędów: zbyt szerokich uprawnień, publicznych bucketów S3, otwartych portów administracyjnych czy braku monitoringu logów.

Na poziomie marketingu często pojawia się skrót myślowy „przeniesiemy się do AWS, będzie bezpieczniej”. Taka zmiana rzeczywiście zwiększa bezpieczeństwo fizyczne i dostępność, ale jednocześnie drastycznie zwiększa liczbę możliwych opcji konfiguracyjnych. Jeśli zespół nie rozumie ich konsekwencji, to chmura zamiast wzmacniać bezpieczeństwo, staje się akceleratorem incydentów.

Kluczowe jest rozróżnienie: AWS odpowiada za bezpieczeństwo chmury, a klient za bezpieczeństwo tego, co w tej chmurze uruchamia i jak to konfiguruje. To, które porty są otwarte, jakie role IAM mają Twoje aplikacje, czy S3 ma włączoną blokadę publicznego dostępu – to wszystko jest w Twojej gestii. Atakujący nie szukają luk w hypervisorze Amazona. Znacznie szybciej znajdą źle skonfigurowany bucket z kopiami zapasowymi lub klucze AWS w publicznym repozytorium Git.

Model odpowiedzialności współdzielonej i typowe nieporozumienia

Model odpowiedzialności współdzielonej AWS dzieli obszary obowiązków. Po stronie AWS są m.in.: bezpieczeństwo fizyczne center danych, warstwa sieciowa i hypervisor, sprzęt, niektóre komponenty systemowe w usługach zarządzanych. Po stronie klienta: konfiguracja usług, zarządzanie użytkownikami i uprawnieniami IAM, ochrona danych (szyfrowanie, dostęp), konfiguracja sieci w ramach VPC, reagowanie na incydenty.

Do realnych incydentów często prowadzą trzy nieporozumienia:

• przekonanie, że „AWS jako dostawca zadba o całe bezpieczeństwo” – skutkujące brakiem polityk IAM, brakiem MFA, otwartymi Security Groups;
• traktowanie konta AWS jak kolejnego serwera – bez rozróżnienia na poziomy uprawnień i bez dedykowanych procesów dostępu;
• ignorowanie logów – zakładanie, że „jak coś się stanie, to będzie wiadomo”, bez faktycznego skonfigurowania CloudTrail, CloudWatch i VPC Flow Logs.

Jeśli model odpowiedzialności jest na etapie deklaracji w prezentacji, a nie jest przełożony na polityki, role, alarmy i procedury, to prędzej czy później wydarzy się incydent. Atak na chmurę najczęściej zaczyna się od małego przeoczenia, które latami „nie przeszkadzało”.

Skala usług i ryzyko błędu ludzkiego

AWS oferuje dziesiątki usług, każda z własnymi przełącznikami bezpieczeństwa, logami, integracjami z IAM. Konfiguracja VPC, NACL, Security Groups, ról IAM, polityk S3, zasad KMS, ustawień API Gateway – to wszystko tworzy gęstą sieć zależności. Wystarczy jedna nieprzemyślana zmiana, aby powstała luka, której nikt od razu nie zauważy.

Im większa organizacja, tym więcej osób dotyka konfiguracji AWS: developerzy, DevOps, administratorzy bezpieczeństwa, dostawcy zewnętrzni. Każdy może niechcący otworzyć niepotrzebny port, dać nadmiarowe uprawnienia roli, zostawić tymczasowy bucket publiczny po testach. Bez centralnej polityki i monitoringu logów błędy te pozostają niewidoczne – do momentu, aż wykorzysta je atakujący lub zewnętrzny skaner.

Ludzie popełniają błędy, narzędzia automatyzujące (Terraform, CloudFormation, CI/CD) też. Różnica polega na tym, że błąd zautomatyzowany skaluje się znacznie szybciej: jedna wadliwa polityka IAM może trafić na kilkadziesiąt kont AWS, setki instancji i usług. Wtedy pojedynczy incydent staje się problemem obejmującym całą organizację.

Mechanika realnych incydentów – od drobnego przeoczenia do przejęcia konta

Typowy scenariusz ataku na chmurę AWS zaczyna się od małego wycieku lub nadmiernego uprawnienia. Przykładowo:

• developer wrzuca klucz AWS do publicznego GitHuba;
• w CI/CD używany jest użytkownik IAM z polityką AdministratorAccess;
• w S3 przechowywany jest export bazy danych w bucketcie bez blokady publicznego dostępu;
• Security Group otwiera SSH na 0.0.0.0/0.

Atakujący korzysta z ogólnodostępnych skanerów i botów. Silniki te automatycznie wykrywają klucze AWS w repozytoriach kodu, publiczne zasoby S3 czy otwarte porty. Po pozyskaniu pierwszego dostępu wchodzi w sekwencję: rekonesans (Describe*, List*), eskalacja uprawnień (tworzenie nowych ról, modyfikacja polityk), persistence (tworzenie kont serwisowych, dodanie kluczy), eksfiltracja (kopiowanie danych z S3, snapshoty EBS), monetizacja (kopanie kryptowalut w EC2, ransomware).

Wszystkie te kroki zostawiają ślady w logach: CloudTrail, VPC Flow Logs, S3 access logs, logach usług zarządzanych. Świadome czytanie tych danych pozwala wykryć atak dużo wcześniej, gdy jest jeszcze tylko nietypową zmianą roli lub dziwną próbą listowania bucketów z nowego IP.

Podstawowe mechanizmy logowania i audytu w AWS – z czego korzystać

CloudTrail jako główne źródło prawdy o akcjach w API

CloudTrail rejestruje wywołania API w Twoim koncie AWS: kto (identity), co (eventName), kiedy (eventTime), z jakiego IP (sourceIPAddress) i z jakiego kontekstu (userAgent). To podstawowe źródło informacji o tym, co działo się w konfiguracji i zarządzaniu zasobami. Bez CloudTrail śledzenie przyczyn incydentu jest w praktyce niemożliwe.

Kluczowe aspekty konfiguracji CloudTrail z perspektywy ataku na chmurę:

• Trail organizacyjny – w AWS Organizations warto włączyć CloudTrail poziomu organizacji, zapisujący zdarzenia ze wszystkich kont do centralnego bucketa S3.
• Eventy management i data – logi management events (np. CreateUser, AttachRolePolicy) są obowiązkowe; data events (operacje na obiektach S3, funkcjach Lambda) są droższe, ale krytyczne przy ochronie danych.
• Integracja z CloudWatch Logs – pozwala tworzyć metryki i alarmy na podstawie zapytań do logów (np. każde użycie konta root, każda próba CreateAccessKey dla konkretnego użytkownika).

Analiza CloudTrail to przede wszystkim patrzenie na wzorce: sekwencje zdarzeń, zmiany zachowania użytkownika, nietypowe regiony, nowe rodzaje akcji, które wcześniej nie występowały. Atak na chmurę rzadko zaczyna się od kasowania wszystkiego; zwykle od kilku niepozornych Describe* i List*, które w logach widać bardzo dobrze.

CloudWatch Logs i metryki – operacyjne spojrzenie na bezpieczeństwo

CloudWatch to dwa główne elementy: metryki (liczby, np. CPU, liczba requestów) oraz logi (strumienie tekstowe z aplikacji i usług AWS). Z punktu widzenia bezpieczeństwa ważne są oba poziomy.

CloudWatch Logs gromadzi między innymi:

• logi aplikacji (za pomocą CloudWatch Agent lub integracji w ECS/EKS/Lambda),
• logi API Gateway, Load Balancerów, Lambd, RDS, WAF, GuardDuty,
• skopiowane logi CloudTrail (dla tworzenia metryk i alarmów).

Na bazie logów można tworzyć filtry metryk, które liczą wystąpienia określonych wzorców, a następnie generują alarmy. Przykłady:

• filtr wyłapujący „eventName”:”ConsoleLogin”,”errorMessage”:”Failed authentication” powiązany z alarmem typu „zbyt wiele nieudanych logowań w krótkim czasie”;
• filtr szukający „eventName”:”CreateUser” lub „eventName”:”PutUserPolicy” – do alertowania na wszystkie działania modyfikujące IAM;
• filtr obejmujący nietypowe regiony (np. eventSource z regionu, którego nie używasz).

Metryki CloudWatch przydają się też do wykrywania ataków sieciowych (nagły wzrost 4xx/5xx na ALB, skoki w ruchu wychodzącym z EC2, zwiększona liczba invokacji Lambda) i aplikacyjnych (wzrost błędów uwierzytelniania, przekroczenia limitów, gwałtowne zwiększenie liczby requestów z jednego IP).

VPC Flow Logs, logi load balancerów i S3 – widoczność ruchu i dostępu do danych

VPC Flow Logs rejestrują metadane ruchu sieciowego w Twoich VPC: źródło, cel, port, protokół, ilość przesłanych danych, akcję (ACCEPT/REJECT). Nie pokazują treści pakietów, ale są idealne do wykrywania:

• skanowania portów (wiele prób połączeń na różne porty z jednego IP),
• brute force (powtarzające się próby na porty 22, 3389 z jednego lub wielu IP),
• nietypowego ruchu wychodzącego (duży wolumen danych do nieznanego IP/regionu),
• ruchu między segmentami VPC, który nie powinien mieć miejsca.

Logi z ALB/ELB/NLB pozwalają zobaczyć, jakie IP trafiają na Twoje endpointy, jakie kody odpowiedzi zwraca aplikacja, jak wygląda ścieżka żądań. W połączeniu z WAF można wykryć próby SQLi, XSS, path traversal, a także nadużycia API (np. nietypowe wzorce w query string).

S3 Server Access Logging i CloudTrail data events dla S3 są kluczowe, jeśli bucket może być celem ataku. Dostarczają informacji o tym, które IP, z jakich kont, o jakiej porze czytają/zmieniają obiekty. Dzięki nim można odróżnić normalne odczyty aplikacji od masowego, nieoczekiwanego „zrzucania” danych przez atakującego.

GuardDuty, Security Hub, Config – warstwa korelacji i detekcji

Zamiast ręcznie przeszukiwać logi, lepiej wykorzystać warstwę usług, które robią wstępną analizę i korelację za nas:

• GuardDuty – usługa detekcji zagrożeń. Analizuje CloudTrail, VPC Flow Logs, logi DNS (Route 53), a także integruje się z innymi sygnałami. Wykrywa m.in. nieautoryzowane użycie kluczy, anomalie sieciowe, kontakt z malicious IP, skanowanie portów, nietypowe zachowania IAM.
• Security Hub – agreguje wyniki z GuardDuty, Config, Inspector i innych źródeł w postaci „findings”. Ułatwia priorytetyzację problemów konfiguracyjnych (np. publiczne S3, brak MFA, otwarte SG) i integrację z systemami ticketowymi.
• AWS Config – rejestruje zmiany konfiguracji zasobów oraz weryfikuje je względem reguł (managed lub custom). Daje możliwość odpowiedzi na pytania typu: kiedy dokładnie ten Security Group został otwarty na 0.0.0.0/0, kto to zrobił, jaka była poprzednia konfiguracja.

Te trzy usługi tworzą warstwę „inteligencji” ponad surowymi logami. Nie zastąpią analizy CloudTrail czy VPC Flow Logs, ale znacząco przyspieszą wykrycie ataku i namierzenie konkretnych błędów konfiguracji AWS.

Konto root i dostęp uprzywilejowany – klasyczne pole minowe

Najgroźniejsze błędy wokół konta root

Konto root w AWS ma pełną kontrolę nad kontem: może usuwać zasoby, zmieniać ustawienia rozliczeń, dezaktywować CloudTrail, modyfikować IAM, zamykać całe konto. Z punktu widzenia atakującego przejęcie root to jackpot. Dlatego najcięższe incydenty bezpieczeństwa w chmurze zaczynają się od błędów związanych z tym kontem.

Najczęściej spotykane błędy:

• Używanie konta root do codziennej pracy (np. logowanie do konsoli developerów tym kontem, wykonywanie zwykłych operacji administracyjnych zamiast używania ról IAM).

Jak prawidłowo „uziemić” konto root

Bezpieczna konfiguracja konta root polega na tym, żeby dało się z niego skorzystać w awarii, ale żeby w praktyce nikt go nie używał na co dzień. Z perspektywy logów chodzi też o to, żeby każde użycie root było widocznym „czerwonym światłem”.

Podstawowe kroki twardnienia:

• MFA obowiązkowe – najlepiej klucz sprzętowy (FIDO/U2F) lub dedykowana aplikacja w odseparowanym urządzeniu. Brak MFA na root powinien być traktowany jak incydent, nie „techniczny dług”.
• Unikanie kluczy dostępowych root – jeśli Access Key do root istnieje w logach, to pierwszy kandydat do natychmiastowego usunięcia. Root powinien być używany wyłącznie interaktywnie (console login) i tylko od święta.
• Dedykowana, „zimna” skrzynka mailowa – konto e‑mail powiązane z root nie powinno być zwykłym mailem administratora logującego się zewsząd. Osobny adres, z silnym MFA, najlepiej bez integracji z korporacyjnym SSO.
• Minimalne wykorzystanie – root przydaje się przy kilku operacjach (np. zmiana danych rozliczeniowych, niektóre ustawienia Organizations). Wszystko inne powinno iść przez role IAM.

W praktyce najlepszy test: jeśli w ciągu miesiąca w CloudTrail pojawia się więcej niż jedno logowanie root – konfiguracja wymaga przeglądu.

Jak w logach wykrywać nadużycia konta root

Użycie konta root powinno zawsze generować głośny alert. Da się to zrobić niemal w całości na bazie CloudTrail i CloudWatch.

• CloudTrail: eventName = ConsoleLogin, userIdentity.type = Root – każdy taki rekord to login root do konsoli. Jeśli responseElements.ConsoleLogin ma wartość Failure, a prób jest wiele, widać próby odgadnięcia hasła (czasem z zainfekowanych stacji wewnątrz firmy).
• CloudTrail: CreateAccessKey z userIdentity.type = Root – sytuacja krytyczna. Tworzenie klucza dostępowego dla root to klasyczny sygnał kompromitacji lub bardzo poważnego błędu proceduralnego.
• Zmiany krytycznej konfiguracji – DisableCloudTrail, UpdateTrail, DeleteTrail, PutAccountPublicAccessBlock (dla S3) wywołane przez root. Takie sekwencje często oznaczają próbę „wyczyszczenia śladów”.

Technicznie najprościej założyć w CloudWatch Logs filtr metryki typu:

{ ($.userIdentity.type = "Root") && ($.eventName = "ConsoleLogin") && ($.responseElements.ConsoleLogin = "Success") }

i powiązać go z alarmem SNS kierującym zdarzenia do systemu SIEM, na e-mail on-call lub na Slacka. Drugi filtr – na każde pojawienie się "CreateAccessKey" z Root – powinien mieć najwyższy priorytet eskalacji.

Role uprzywilejowane i ich nadużycia

Root to wierzchołek góry lodowej. W praktyce większość „root‑level” szkód da się wyrządzić rolami i użytkownikami z uprawnieniami administracyjnymi: AdministratorAccess, politykami własnymi obejmującymi "Action":"*" albo rolami z uprawnieniami service control (Organizations, CloudTrail, IAM).

Typowe zaniedbania:

• jedna wspólna rola „Admin” używana przez kilkudziesięciu administratorów (brak indywidualnej odpowiedzialności),
• brak wymogu MFA do przyjmowania roli uprzywilejowanej,
• brak rozdzielenia ról: ten sam podmiot może i tworzyć użytkowników, i zarządzać rozliczeniami, i modyfikować CloudTrail.

W logach widać to po eventach typu AssumeRole z roleArn zawierającym np. „Admin”, „PowerUser”, „SecurityAudit”, a dalej po sekwencjach akcji uprzywilejowanych wykonywanych „w imieniu” tej roli.

Jak w logach rozpoznać eskalację uprawnień

Eskalacja przywilejów rzadko zaczyna się „głośno”. Częściej wygląda to jak seria niepozornych wywołań API, które dopiero w całości tworzą niebezpieczny wzorzec. Warto patrzeć na kombinacje:

• CreateUser / CreateAccessKey / PutUserPolicy – tworzenie nowego użytkownika i natychmiastowe przypisywanie mu szerokich uprawnień. Jeśli zdarzenia pochodzą z konta serwisowego lub automatu CI/CD, coś jest nie tak z pipeline’em.
• AttachUserPolicy / AttachRolePolicy z policyArn zawierającym AdministratorAccess lub własną politykę z "Action":"*". Wzorzec: najpierw kilka Describe*, potem Attach*, potem intensywny ruch na S3/EC2/IAM.
• AssumeRole z nieoczekiwanych źródeł – jeśli rola administracyjna miała być używana tylko interaktywnie (AWS SSO, IAM Identity Center), a nagle pojawia się assumedRole z poświadczeń długoterminowych (AccessKey), widać problem.

Dobrym trikiem jest budowa w CloudWatch filtrów typu „pierwsze użycie uprawnienia”. Jeśli w logach pojawia się po raz pierwszy eventName z grupy iam:Create*, iam:Put*, iam:Attach* dla danej tożsamości – wysyłany jest alert. To ogranicza hałas i skupia uwagę na zmianach w powłoce kontroli dostępu.

IAM – zbyt szerokie uprawnienia i toksyczne kombinacje ról

Polityki „*:*” i nadawanie uprawnień wprost do użytkownika

Najczęstszy błąd w IAM to „szybki fix”: dołożenie użytkownikowi roli „AdministratorAccess”, bo „coś nie działa, a trzeba już wdrożyć”. Drugi – dopisywanie polityk inline bez żadnej standaryzacji i późniejszego przeglądu.

Główne antywzorce:

• Polityki z "Action":"*" i/lub "Resource":"*" – szczególnie poza ściśle kontrolowanymi kontami sandbox. Najgorzej, gdy są przypięte wprost do użytkownika, zamiast do roli.
• Polityki inline na poziomie użytkownika – trudne do audytu, łatwo je przeoczyć przy recenzji konfiguracji. Gdy atakujący przejmie taki użytkownik, dostaje cały „ukryty” pakiet uprawnień.
• Brak separacji obowiązków – jedna rola może i modyfikować IAM, i zarządzać CloudTrail, i kasować S3. W tej sytuacji kompromitacja prowadzi od razu do pełnego przejęcia.

W logach CloudTrail widać to przez sekwencje PutUserPolicy, PutRolePolicy, AttachUserPolicy, AttachRolePolicy. Jeśli takie zdarzenia występują regularnie i bez procesu akceptacji (np. brak powiązania z ticketem w systemie change management), w efekcie pojawia się „IAM spagetthi”, którego nikt nie kontroluje.

Toksyczne kombinacje ról i ścieżki samonadawania uprawnień

Niebezpieczne są nie tylko pojedyncze polityki, ale i ich kombinacje. Dwa pozornie „bezpieczne” przywileje mogą dawać razem możliwość wyboru dowolnej roli, a potem eskalacji do administratora.

Typowe scenariusze:

• iam:PassRole + prawo tworzenia zasobów – jeśli rola ma iam:PassRole na zbyt szerokim Resource, a jednocześnie może tworzyć np. funkcje Lambda, zadania ECS albo instancje EC2 z user‑data, to w praktyce pozwala wykonywać kod w kontekście dowolnej roli. To klasyczna eskalacja pionowa.
• iam:UpdateAssumeRolePolicy – jeśli ktoś może zmodyfikować trust policy roli uprzywilejowanej, może dopisać siebie lub inną rolę jako zaufanego principal i potem swobodnie ją przyjmować.
• iam:CreatePolicyVersion – możliwość tworzenia nowej wersji istniejącej polityki i ustawiania jej jako domyślnej nawet bez prawa zmiany samego obiektu polityki. W efekcie niepozorny użytkownik może „podmienić” logikę przyznawania dostępu.

W praktyce warto szukać w CloudTrail sekwencji:

1. Describe* / List* na IAM (np. ListRoles, GetRole),
2. iam:UpdateAssumeRolePolicy lub iam:PassRole,
3. AssumeRole do nowej, uprzywilejowanej roli,
4. intensywne operacje na zasobach (S3, EC2, RDS, CloudTrail).

Takie łańcuchy warto modelować jako reguły w SIEM lub w narzędziach typu Detective/GuardDuty (część scenariuszy GuardDuty wykrywa już zbyt szerokie iam:PassRole). Jeśli organizacja ma własny lake logów (Athena, OpenSearch), można cyklicznie uruchamiać zapytania wychwytujące powiązane eventy w krótkim oknie czasowym.

Statyczna analiza IAM i powiązanie z logami

Same logi nie pokażą, czy polityka jest „zła” – pokażą tylko, że została użyta. Dlatego niezbędne jest połączenie statycznej analizy IAM z dynamicznym monitoringiem.

Przydatne elementy:

• AWS IAM Access Analyzer – identyfikuje zasoby udostępnione na zewnątrz (trust policies, S3, KMS, SQS, SNS) oraz nadmiernie szerokie uprawnienia. Jego wyniki dobrze jest korelować z logami: jeśli polityka oznaczona jako ryzykowna jest intensywnie używana, to wysoki priorytet remediacji.
• AWS Config + reguły pod IAM – wykrycie użytkowników bez MFA, polityk z "Action":"*", ról bez ograniczenia Condition w trust policy. Dla każdego „non‑compliant” zasobu można potem sprawdzić, czy jest używany w CloudTrail.
• Okresowe zapytania do CloudTrail – przykładowo Athena query liczące, ile razy dana rola wykonała akcje typu iam:*, s3:* na bucketach oznaczonych tagiem „sensitive=true”.

Istotą jest rozróżnienie „martwych” nadmiarowych uprawnień (ciągle złych, ale mniej pilnych) od tych, których ktoś realnie używa. Logi pozwalają tę różnicę zobaczyć czarno na białym.

Publiczne zasoby S3 i inne „otwarte drzwi” do danych

Najczęstsze błędne konfiguracje S3

Bucket S3 rzadko „sam” staje się publiczny. Zwykle to efekt pośpiechu przy konfiguracji aplikacji, migracji danych albo źle zrozumianej dokumentacji. Najczęstsze źródła wycieków:

• Bucket policy dopuszczająca "Principal":"*" – szczególnie z akcjami s3:GetObject lub s3:ListBucket. Często miało to być tymczasowe ułatwienie dla testów.
• ACL na poziomie obiektu – stare mechanizmy ACL pozwalają na przyznanie „public-read” pojedynczym obiektom, co trudno kontrolować w dużym bucketcie.
• Wyłączone blokady publicznego dostępu (Block Public Access) na poziomie konta lub bucketa, bo „przeszkadzało w integracji CDN/partnera”.

W efekcie dane, które miały być dostępne tylko z aplikacji backendowej, są indeksowane przez wyszukiwarki, trafiają do cache i kopii w zewnętrznych systemach. Z perspektywy atakującego to „prezent za darmo”, bo nie musi łamać żadnych zabezpieczeń.

Jak w logach rozpoznać, że bucket S3 jest nadużywany

Wyciek danych z S3 widać w logach na kilka sposobów. W zależności od konfiguracji można korzystać z:

• CloudTrail data events dla S3 – każdy GetObject, PutObject, DeleteObject z informacją o źródłowym IP i tożsamości.
• S3 Server Access Logs – metadane żądań HTTP, w tym user‑agent, kody odpowiedzi, wielkość przesyłanych danych.
• CloudFront logs – jeśli bucket siedzi za CDN, większość ruchu zobaczymy tam.

Objawy nadużyć:

• Nagły wzrost GetObject z jednego IP lub małego zakresu IP, zwykle w krótkim czasie i na wielu kluczach równocześnie (sekwencyjne „zrzucanie” plików).
• Duży wolumen danych wychodzących – skok w metryce BytesDownloaded skorelowany z CloudTrail/S3 logs.
• Zapytania z niespodziewanych regionów – np. 99% normalnego ruchu pochodzi z Europy, a nagle pojawiają się setki tysięcy GetObject z Azji czy Ameryki Południowej.
• ListBucket wykonywany przez podmioty, które normalnie tylko czytają konkretne obiekty – sygnał, że ktoś próbuje zorientować się w zawartości bucketa.

Dobrym podejściem jest stworzenie w CloudWatch metryk na podstawie CloudTrail data events:

• liczba GetObject z adresów IP spoza dopuszczalnych prefixów (np. firmowy VPN, IP dostawców),

Monitorowanie dostępu do S3 i korelacja z konfiguracją

Same anomalie w logach ruchu do bucketa nie wystarczą, jeśli nie widać od razu, jak bucket jest skonfigurowany. Potrzebne jest połączenie trzech perspektyw: polityki bucketa, ustawień Block Public Access oraz faktycznego użycia w logach.

Praktyczny workflow:

1. Okresowe zrzuty konfiguracji S3 – np. AWS Config lub własny skrypt wywołujący GetBucketPolicy, GetPublicAccessBlock, GetBucketAcl.
2. Kategoryzacja bucketów – na podstawie tagów (np. classification=public/internal/confidential) oraz właściciela (tag owner/system).
3. Korelacja z logami – sprawdzenie, czy:
   • bucket deklarowany jako „internal” ma ruch z publicznych adresów IP,
   • bucket z wyłączonym Block Public Access ma intensywne GetObject spoza oczekiwanych AS/regionów,
   • ktoś modyfikuje politykę S3 (PutBucketPolicy, PutPublicAccessBlock) tuż przed skokiem ruchu.

Przykładowe zapytanie w Athena nad CloudTrail data events dla S3 może łączyć tabelę z eventami z tabelą z „snapshotem” konfiguracji bucketów (wrzuconym wcześniej do S3) po nazwie bucketa. Dzięki temu da się zidentyfikować np. wszystkie GetObject na bucketach oznaczonych jako confidential, które pochodzą z niezaufanych IP.

GuardDuty, Access Analyzer i kontrola ekspozycji S3

Usługi zarządzane AWS potrafią sprawnie wychwytywać typowe błędy konfiguracyjne wokół S3, ale ich sygnały trzeba rozumieć w kontekście logów.

• Amazon GuardDuty – generuje alerty dla:
  • nieoczekiwanego ListBuckets / ListObjects z rzadkich lokalizacji,
  • dużych transferów z S3 wykonywanych z podejrzanych ASN,
  • operacji administracyjnych na politykach S3 wykonywanych przez wcześniej nieużywane tożsamości.

  Dobre praktyki to przypisanie priorytetów (severity) do typów zdarzeń i automatyczne dogrywanie kontekstu (np. klasyfikacji bucketa) w pipeline SIEM.

• AWS IAM Access Analyzer (S3) – skanuje polityki bucketów i ACL-i, wykrywając zasoby dostępne:
  • anonimowo (Principal":"*"),
  • dla innych kont AWS,
  • dla określonych organizacji (AWS Organizations).

  Wyniki z Access Analyzer można łączyć z użyciem – bucket oznaczony jako „publiczny przez konfigurację”, ale nieużywany przez zewnętrzne adresy IP, to inny priorytet niż bucket intensywnie wykorzystywany z Internetu.

Jeśli GuardDuty zgłasza podejrzane GetObject, a Access Analyzer pokazuje, że bucket jest faktycznie publiczny, to sygnał, że nie chodzi o „fałszywy pozytyw”, tylko realne ryzyko wycieku. W takiej sytuacji triage obejmuje nie tylko IP źródłowe i user‑agent, ale też szybkie oszacowanie, jaką część obiektów mógł pobrać atakujący.

Security Groups, NACL i VPC – niewidoczne „dziury w płocie”

Konfiguracje, które otwierają VPC szerzej niż się wydaje

Najbardziej bolesne błędy sieciowe w AWS zwykle nie wynikają z pojedynczej Security Group, lecz z kombinacji SG, NACL i tras w VPC. W efekcie zasób, który miał być „dostępny tylko z wnętrza VPN”, jest osiągalny wprost z Internetu lub z innych kont.

Najczęstsze problemy:

• Security Groups z 0.0.0.0/0 na wrażliwych portach – SSH (22), RDP (3389), bazy danych (3306, 5432, 1433), Elasticsearch/OpenSearch (9200/9300). Dotyczy to nie tylko EC2, ale także RDS (SG przypięte do instancji DB) czy EFS.
• „Shared” SG używane w wielu systemach – jedna grupa bezpieczeństwa, która przez lata zbierała reguły „na szybko”, a dziś jest przypięta do kilkudziesięciu instancji w różnych środowiskach.
• NACL, które „nic nie blokują” – ustawione na allow‑all, bo „psuły ruch”, przez co realnie jedyną tarczą zostają SG i konfiguracja instancji.
• Publiczne subnety dla systemów backendowych – instancje mają publiczne IP, a SG pozwalają na ruch przychodzący z dowolnego źródła, chociaż usługa powinna być dostępna wyłącznie przez ALB/NLB lub VPCE.

Jak w logach rozpoznać błędy sieciowe i próby ataków

Aby wychwycić skutki złej segmentacji w VPC, potrzebne są logi blisko warstwy sieciowej. Podstawą są:

• VPC Flow Logs – ruch na poziomie ENI (interface’u sieciowego), z informacją o źródłowym i docelowym IP, porcie, protokole i flagach akceptacji/odrzucenia.
• CloudTrail – zmiany w konfiguracji SG, NACL, trasach VPC, bramach internetowych i NAT.
• Load Balancer Access Logs – warstwa L7, szczególnie przydatna przy WAF i HTTP(S).

Typowe sygnały ostrzegawcze w VPC Flow Logs:

• Stałe skany portów – wiele połączeń REJECT lub ACCEPT z jednego IP na różne porty w krótkim czasie; często na instancje z publicznym IP.
• Nietypowe protokoły – ruch UDP lub ICMP z/do instancji, które normalnie obsługują wyłącznie HTTP(S).
• Niespodziewany ruch lateralny – komunikacja między subnetami lub SG, które nie powinny się „widzieć” (np. serwery aplikacyjne łączące się bezpośrednio z innymi VPC bez peeringu/Transit Gateway).
• Połączenia z/do IP przypisanych do innego regionu/providerów VPN – pomocne jest utrzymywanie list dozwolonych ASN i geolokacji.

Korelacja z CloudTrail pozwala związać anomalie w ruchu z konfiguracją. Jeśli w logach pojawia się AuthorizeSecurityGroupIngress z CIDR 0.0.0.0/0 na SSH, a chwilę później VPC Flow Logs pokazują masowy skan portu 22 na tej instancji, nie ma wątpliwości, że to konfiguracja otworzyła bramę.

Analiza SG i NACL „w stanie spoczynku”

Oprócz monitorowania ruchu trzeba regularnie przeglądać same definicje SG i NACL. Pomagają w tym:

• AWS Config – reguły typu:
  • „Security groups should not allow unrestricted access to ports …” (restricted-ssh, restricted-common-ports),
  • „VPC default security group should not allow inbound or outbound traffic” – klasyczny błąd z używaniem domyślnej SG.
• Skrypty audytowe – np. cykliczne uruchamianie DescribeSecurityGroups i detekcja:
  • reguł z 0.0.0.0/0 lub ::/0 na nietypowych portach,
  • SG nieprzypiętych do żadnych ENI (kandydaci do usunięcia),
  • NACL, które nie mają żadnych reguł „deny”,
  • tras kierujących cały ruch (0.0.0.0/0) do Internet Gateway w subnetach, które powinny być prywatne.

Połączenie statycznej analizy z dynamiką Flow Logs daje pełniejszy obraz: lista SG „zbyt otwartych” jest filtrowana ruchem faktycznie przechodzącym przez odpowiadające im ENI. Jeśli grupa bezpieczeństwa ma otwarty SSH na świat, ale instancja jest wyłączona od miesięcy, priorytet remediacji będzie inny niż dla produkcyjnego frontendu.

Ruch międzykontowy i prywatne połączenia jako wektor ataku

Coraz częściej atak nie idzie wprost z Internetu, tylko z innego konta AWS – np. partnera, środowiska testowego lub konta przejętego przez atakującego. Źródłem są tu peeringi VPC, AWS Transit Gateway, PrivateLink/Interface VPC Endpoint i VPN.

Przykładowe zdarzenia w CloudTrail, które powinny zapalać lampkę ostrzegawczą:

• CreateVpcPeeringConnection lub CreateTransitGatewayVpcAttachment inicjowane spoza standardowego konta „networking”,
• modyfikacje tras (CreateRoute, ReplaceRoute) kierujących ruch do nowych peeringów lub TGW,
• tworzenie endpointów typu Interface/VPC Endpoint dla usług partnerów bez wcześniejszego review.

VPC Flow Logs z takich połączeń mogą wyglądać „normalnie” (ruch prywatny, brak publicznych IP), ale jeśli widoczne są próby skanowania portów między VPC, to sygnał, że wektor ataku przeszedł już przez pierwszą linię obrony.

Błędna konfiguracja usług zarządzanych – ataki przez „wygodne” skróty

RDS – bazy dostępne zbyt szeroko

Relational Database Service upraszcza zarządzanie bazą, ale nie zwalnia z myślenia o sieci i szyfrowaniu. Typowe wpadki:

• Publicly accessible = true dla instancji produkcyjnych – oraz SG pozwalające na ruch z Internetu na port DB.
• Brak wymuszania TLS – połączenia nieszyfrowane, widoczne w sieci wewnętrznej (pkt. do podsłuchu w razie lateral movement).
• Brak rotacji haseł i poświadczeń – użytkownicy DB konfigurowani ręcznie, bez integracji z Secrets Manager/SSM.

W logach można szukać:

• CloudTrail: ModifyDBInstance ustawiającego PubliclyAccessible=true, zmiany SG przypiętych do RDS, wyłączenia logowania audytowego.
• RDS Enhanced Monitoring / Performance Insights: skoki liczby połączeń z nieoczekiwanych adresów IP/hostów, próby logowania błędnymi poświadczeniami.
• VPC Flow Logs: ruch na porcie DB z podsieci/kont, które nie powinny się łączyć.

Jeśli w CloudTrail pojawia się modyfikacja RDS (otwarcie na świat), a po kilku minutach Flow Logs rejestrują liczne próby połączenia z portem DB z Internetu, łatwo odtworzyć ścieżkę błędu konfiguracyjnego do faktycznego ataku.

Lambda – nadmierne uprawnienia i logi jako wskaźnik nadużyć

Funkcje Lambda często dostają szerokie role IAM „bo musi coś poczytać z S3, coś z DynamoDB, a najlepiej mieć AWSLambdaFullAccess”. Do tego dochodzą event source’y (S3, SQS, API Gateway), które bywają konfigurowane bez ograniczeń.

Błędy konfiguracyjne:

• Role powiązane z Lambda z nadmiarem akcji – np. "Action":"s3:*" na wszystkie buckety lub "Action":"kms:Decrypt" na wszystkie klucze KMS.
• Dostęp do sieci publicznej – funkcja wpięta do VPC, ale z możliwością wychodzenia do Internetu przez NAT, co w razie kompromitacji pozwala użyć jej jako „proxy” ataku.
• Źle ustawione timeouty i retry – niekończące się próby przetwarzania „złego” eventu, które potrafią zasypać backend lub systemy downstream.

W logach (CloudWatch Logs, CloudTrail) można zobaczyć:

• nieoczekiwane wywołania akcji IAM, S3, KMS czy SSM wykonywane przez role Lambdy,
• masowe InvokeFunction spoza standardowych źródeł (np. ktoś bezpośrednio wywołuje funkcję, która zwykle jest wyłącznie triggerowana z SQS/API Gateway),
• wzrost liczby błędów typu AccessDenied w logach funkcji po zmianie jej roli – sygnał, że ktoś eksperymentuje z uprawnieniami.

Dobrym mechanizmem jest zbudowanie reguł w CloudTrail/GuardDuty, które flagują próby wywołania funkcji administracyjnych (np. funkcji DevOps) przez nietypowe tożsamości lub z regionów innych niż standardowy.

API Gateway – otwarte API bez kontroli klientów

API Gateway kusi prostą konfiguracją i możliwością szybkiego wystawienia endpointów HTTP. To rodzi klasyczne wpadki:

• Publiczne REST/HTTP API bez autoryzacji – brak JWT/Cognito/Custom Authorizer, endpointy dostępne dla każdego.
• Brak throttlingu i WAF – API podatne na brute force, DDoS lub próby enumeracji danych.
• Eksponowanie pełnych odpowiedzi backendu – brak filtracji, co ułatwia wyciek informacji o strukturze systemu.

Źródła sygnałów w logach:

• API Gateway Access Logs – wzrost liczby żądań 4xx/5xx, nietypowe ścieżki (np. masowa próba wywołania endpointów administracyjnych), sekwencyjne enumerowanie ID w parametrach.

Najczęściej zadawane pytania (FAQ)

Jakie są najczęstsze błędy w konfiguracji AWS, które prowadzą do ataków?

Najczęstsze błędy to przede wszystkim zbyt szerokie uprawnienia IAM (np. AdministratorAccess używany w CI/CD), publicznie dostępne buckety S3, otwarte porty administracyjne (SSH/RDP) na 0.0.0.0/0 oraz brak wymuszonego MFA dla kont uprzywilejowanych. Często spotykane jest także korzystanie z konta root do codziennej pracy.

Drugą grupą problemów jest brak lub zła konfiguracja logowania: wyłączony lub niepełny CloudTrail, brak logów dostępu do S3, brak VPC Flow Logs. W takiej sytuacji atak może trwać tygodniami, a zespół nie ma szans odtworzyć, co się faktycznie wydarzyło.

Na czym polega model odpowiedzialności współdzielonej w AWS i jak wpływa na bezpieczeństwo?

Model odpowiedzialności współdzielonej oznacza, że AWS odpowiada za bezpieczeństwo infrastruktury chmurowej (sprzęt, sieć, hypervisor, wybrane komponenty usług zarządzanych), a klient za bezpieczeństwo wszystkiego, co uruchamia w tej chmurze i jak to konfiguruje. Innymi słowy: AWS dba, by data center nie zostało fizycznie zhakowane, a klient – by nie wystawił danych w publicznym S3.

Jeśli organizacja zakłada, że „AWS załatwi całe bezpieczeństwo”, zwykle kończy się to brakiem polityk IAM, otwartymi Security Groups, brakiem MFA i logów. To typowe źródło incydentów: technicznie wszystko było „w AWS”, ale błędna konfiguracja po stronie klienta otworzyła drzwi atakującemu.

Jak wykryć nieprawidłową konfigurację AWS w logach CloudTrail?

W CloudTrail szuka się przede wszystkim nietypowych wywołań API i sekwencji zdarzeń. Symptomy problemów z konfiguracją to m.in. nagłe pojawienie się akcji Describe* i List* z nowego użytkownika lub adresu IP, modyfikacje polityk IAM (PutUserPolicy, AttachRolePolicy), tworzenie nowych kluczy dostępowych (CreateAccessKey) i nietypowe logowania konsolowe (ConsoleLogin) z nieużywanych dotąd regionów.

Praktyczne podejście to włączenie organizacyjnego CloudTrail, wysyłanie logów do CloudWatch Logs i zdefiniowanie metryk/alertów dla konkretnych wzorców, np. każde użycie konta root, każda próba CreateUser, każdy błąd nieudanej autoryzacji w połączeniu z rzadko używanym regionem.

Jak szybko sprawdzić, czy moje buckety S3 nie są przypadkowo publiczne?

Podstawowa kontrola to użycie opcji „Block Public Access” na poziomie konta i konkretnych bucketów. Jeśli ta blokada jest włączona globalnie, znacznie trudniej o przypadkowe wystawienie danych. Dodatkowo warto przejść przez S3 i sprawdzić ACL oraz polityki bucketów pod kątem wpisów „Principal”: „*”.

Na poziomie logów pomocne są S3 server access logs lub CloudTrail data events dla S3. Dzięki nim można wykryć podejrzane odczyty obiektów z nieznanych adresów IP, nagły wzrost ruchu z jednego kraju lub użycie operacji GetObject na bucketach, które nie powinny być publicznie dostępne.

Jakie logi AWS są kluczowe do wykrywania ataków na chmurę?

Podstawą jest CloudTrail, który rejestruje wszystkie istotne wywołania API – zmiany konfiguracji, tworzenie ról, logowania, operacje na zasobach. Bez niego nie da się wiarygodnie przeanalizować incydentu ani wykrywać wczesnych etapów ataku (rekonesans, eskalacja uprawnień).

Uzupełnieniem są: CloudWatch Logs (logi aplikacji, API Gateway, ALB/NLB, Lambda, RDS), VPC Flow Logs (ruch sieciowy, podejrzane połączenia przychodzące/wychodzące) oraz logi dostępu do S3 i innych usług zarządzanych. Wspólnie dają obraz: kto coś zmienił, skąd się łączył i jakie dane czy ruch sieciowy za tym stały.

Jak ograniczyć ryzyko błędów konfiguracyjnych w dużej organizacji korzystającej z AWS?

Kluczowe są standardy i centralizacja. W praktyce oznacza to m.in. używanie AWS Organizations, szablonów kont (Landing Zone), wymuszonego CloudTrail organizacyjnego, wspólnych polityk SCP, a także centralnych wzorców infrastruktury jako kodu (Terraform/CloudFormation) zamiast ręcznych kliknięć w konsoli.

Drugim filarem jest monitoring i automatyzacja kontroli: narzędzia typu AWS Config, Security Hub, ciągłe skanowanie IAM i S3, alerty w CloudWatch na podejrzane wzorce w logach. Im więcej zmian przechodzi przez code review i pipeline CI/CD z wbudowanymi kontrolami, tym mniejsza szansa, że ktoś „na szybko” otworzy SSH na cały internet albo nada roli uprawnienia *:*.

Jak rozpoznać w logach typowy scenariusz przejęcia klucza AWS z GitHuba?

Zazwyczaj wygląda to tak: najpierw pojawia się pierwsze użycie nowego klucza z nietypowego IP lub regionu, od razu z szerokim zakresem Describe*/List* w CloudTrail. Następnie widać próby eskalacji uprawnień (modyfikacja ról i polityk IAM, tworzenie nowych użytkowników/kluczy), a po chwili operacje na danych (ListBuckets, GetObject w S3, tworzenie snapshotów EBS).

W logach sieciowych i usługowych może równolegle wzrosnąć ruch wychodzący (eksfiltracja danych) lub zużycie zasobów EC2/Lambda (kopanie kryptowalut, skrypty skanujące). Jeśli w CloudWatch zdefiniowane są alerty na nietypowe CreateAccessKey, ConsoleLogin z nowych krajów lub nagłe zmiany w IAM, taki incydent można wychwycić już na etapie pierwszych kroków rekonesansu.

Najważniejsze punkty

• Najwięcej incydentów w AWS wynika nie z ataków na infrastrukturę Amazona, ale z błędów konfiguracyjnych po stronie klienta: nadmiernych uprawnień, publicznych zasobów S3, otwartych portów administracyjnych i braku monitoringu.
• Model odpowiedzialności współdzielonej oznacza, że AWS zabezpiecza infrastrukturę chmury, natomiast klient w pełni odpowiada za konfigurację usług, IAM, sieć w VPC, szyfrowanie danych oraz reagowanie na incydenty.
• Typowe nieporozumienia to: oczekiwanie, że AWS „zadba o wszystko”, traktowanie konta AWS jak pojedynczego serwera bez podziału ról oraz całkowite ignorowanie logów i brak centralnej konfiguracji CloudTrail, CloudWatch i VPC Flow Logs.
• Rozbudowana liczba usług i opcji bezpieczeństwa w AWS zwiększa ryzyko błędu ludzkiego – jedna pozornie drobna zmiana (np. otwarty port, tymczasowy publiczny bucket) może utworzyć poważną lukę, która długo pozostaje niewidoczna.
• Automatyzacja (Terraform, CloudFormation, CI/CD) przyspiesza wdrożenia, ale także skaluje błędy bezpieczeństwa – wadliwa polityka IAM może w kilka minut trafić na dziesiątki kont i setki zasobów.
• Praktyczne scenariusze ataku zwykle zaczynają się od małego wycieku lub nadmiernego uprawnienia (np. klucz w GitHubie, AdministratorAccess w CI/CD, publiczny eksport bazy w S3), a następnie obejmują rekonesans, eskalację uprawnień, utrwalenie dostępu, eksfiltrację danych i monetyzację.