Powierzchnia ataku chmury

W chmurze dostawca zabezpiecza infrastrukturę, a klient odpowiada za konfigurację, tożsamość i dane. Większość naruszeń bezpieczeństwa występuje po stronie klienta.

• Dostawca aktualizuje hipernadzorców i zapewnia bezpieczeństwo fizyczne.
• Klient odpowiada za zasady IAM, uprawnienia do magazynów danych i reguły sieciowe.
• Głównym zagrożeniem są błędne konfiguracje, a nie przejęcie kontroli nad dostawcą.

Chmura nie ma tradycyjnej granicy sieciowej. Dostępem zarządza IAM: użytkownicy, role, zasady i klucze. Ujawniony klucz dostępu może wyrządzić szkody porównywalne ze skradzionym hasłem administratora domeny.

• Zasady IAM przyznają uprawnienia do wykonywania operacji na zasobach.
• Role pozwalają usługom i użytkownikom uzyskiwać tymczasowe poświadczenia.
• Tożsamości z nadmiernymi uprawnieniami są głównym wektorem eskalacji.

Poświadczenia chmurowe są stale ujawniane. Typowe źródła obejmują:

• Klucze dostępu zapisane w publicznych repozytoriach Git.
• Klucze zakodowane na stałe w aplikacjach mobilnych, logach CI lub obrazach kontenerów.
• Server-Side Request Forgery (SSRF) umożliwiające dostęp do usługi metadanych.
• Zbyt szerokie udostępnianie długoterminowych kluczy zamiast krótkotrwałych ról.

Każda instancja chmurowa udostępnia punkt końcowy metadanych, który może zwracać tymczasowe dane uwierzytelniające roli. Podatność SSRF lub RCE na maszynie wirtualnej, która może uzyskać do niego dostęp, często pozwala przejąć rolę instancji.

• Usługa AWS IMDS jest dostępna pod adresem 169.254.169.254.
• IMDSv1 wymaga tylko wysłania żądania i można ją łatwo wykorzystać za pomocą SSRF.
• IMDSv2 wymaga tokenu sesji (najpierw PUT, a następnie GET), co ogranicza wiele ataków SSRF.

Obiektowa pamięć masowa (S3, GCS, Azure Blob) jest częstym źródłem ujawnienia danych.

• Kontenery z publicznym odczytem ujawniają poufne pliki.
• Kontenery z publicznym zapisem umożliwiają modyfikowanie danych lub hostowanie złośliwego oprogramowania.
• Zbyt szerokie zasady dostępu do kontenerów lub listy ACL przyznają dostęp uwierzytelnionym użytkownikom.
• Wstępnie podpisane adresy URL z długim czasem wygaśnięcia zapewniają trwały dostęp, który może zostać ujawniony.

Kontrole sieci chmurowej (Security Groups, NSGs, reguły zapory) łatwo skonfigurować zbyt liberalnie.

• Bazy danych lub porty administracyjne są dostępne z 0.0.0.0/0.
• Płaszczyzny zarządzania (API Kubernetes, RDP, SSH) są dostępne z internetu.
• Usługi wewnętrzne domyślnie ufają VPC i nie wymagają uwierzytelniania.

Architektura serverless przenosi ryzyko, ale go nie eliminuje. Funkcje, kolejki i zarządzane bazy danych mają własną tożsamość wykonawczą.

• Rola wykonawcza funkcji Lambda może mieć zbyt szerokie uprawnienia.
• Zmienne środowiskowe często zawierają sekrety, które można odczytać po przejęciu systemu.
• Błędna konfiguracja źródła zdarzeń może pozwolić niezaufanym danym na uruchamianie uprzywilejowanych funkcji.

Należy rozróżnić te dwie powierzchnie ataku:

• Płaszczyzna sterowania: API chmurowe (tworzenie zasobów, modyfikowanie IAM, odczytywanie konfiguracji). Jej przejęcie obejmuje całe konto.
• Płaszczyzna danych: same obciążenia robocze (aplikacje, maszyny wirtualne, kontenery).

Uzyskanie przyczółka w płaszczyźnie danych, który pozwala przejąć dane uwierzytelniające płaszczyzny sterowania, to klasyczny sposób eskalacji uprawnień w chmurze.

Duże organizacje rozdzielają obciążenia robocze między wiele kont, subskrypcji i projektów.

• Role między kontami ze słabymi zasadami zaufania umożliwiają przemieszczanie się między nimi.
• Atak typu confused deputy w roli integracji zewnętrznej może zostać wykorzystany.
• Role na poziomie organizacji (np. OrganizationAccountAccessRole) mają wysoką wartość dla atakującego.

Obrońcy polegają na natywnych dla chmury dziennikach zdarzeń. Atakujący próbują ich oślepić.

• CloudTrail / Activity Log / Audit Logs rejestrują wywołania płaszczyzny sterowania.
• Atakujący mogą wyłączyć ścieżki audytu lub zatrzymać dostarczanie logów.
• GuardDuty / Security Command Center / Defender wykrywają anomalie.

Wyłączenie logowania samo w sobie jest zdarzeniem o wysokiej wartości sygnałowej, które powinno generować alert.

Testy penetracyjne chmury wymagają znajomości zasad dostawcy i odpowiedniej autoryzacji. Niektóre działania (odmowa usługi, określone rodzaje skanowania) naruszają warunki dostawcy. Zawsze należy potwierdzić własność konta, uzgodnić zakres potencjalnych skutków i w pierwszej kolejności preferować rozpoznanie tylko do odczytu.

Należy używać dedykowanego konta testowego lub zasobów wyraźnie oznaczonych tagami i nigdy nie dotykać zasobów spoza udokumentowanego zakresu.

Sprawdź, czy rozumiesz powierzchnię ataku w chmurze.

Przeanalizowano powierzchnię ataku w chmurze.

• Ryzyko w chmurze wynika przede wszystkim z błędnych konfiguracji po stronie klienta.
• Tożsamość jest granicą bezpieczeństwa; wycieki kluczy i ról to główne wektory ataku.
• Usługa metadanych łączy błędy w płaszczyźnie danych z danymi uwierzytelniającymi chmury.
• Błędne konfiguracje pamięci masowej, sieci i logowania dopełniają tę powierzchnię.

Następnie: wyliczanie zasobów chmurowych w celu znalezienia tych problemów.