Typowe błędne konfiguracje chmury

Błędne konfiguracje są główną przyczyną wycieków danych z chmury. W przeciwieństwie do tradycyjnych luk w systemach lokalnych, których wykorzystanie wymaga zazwyczaj zastosowania błędów w oprogramowaniu, błędne konfiguracje chmury często wynikają z działań własnej organizacji i może je łatwo wykorzystać dowolna osoba w internecie.

Zasobniki S3 z publicznym dostępem do odczytu udostępniają wszystkie przechowywane dane w internecie. Atakujący skanują otwarte zasobniki za pomocą narzędzi takich jak GrayhatWarfare. Zapobieganie: S3 Block Public Access na poziomie konta, włączona funkcja S3 Object Ownership oraz regularne audytowanie polityk zasobników.

Grupy zabezpieczeń z regułą 0.0.0.0/0 dla portu 22 (SSH), 3389 (RDP) lub portów administracyjnych tworzą ogromną powierzchnię ataku. Należy ograniczyć reguły ruchu przychodzącego do określonych zakresów CIDR. Zamiast otwartego SSH należy używać AWS Systems Manager Session Manager.

Przypadkowe publiczne udostępnienie migawek RDS ujawnia całą zawartość bazy danych. Migawki automatyczne są domyślnie prywatne, ale ręczne udostępnianie może ujawnić poufne dane. Widoczność migawek należy audytować za pomocą describe-db-snapshots --include-public.

Programiści umieszczają klucze dostępu AWS, hasła do baz danych i tokeny API w repozytoriach Git. Atakujący skanują GitHub i GitLab za pomocą narzędzi takich jak TruffleHog i GitLeaks. Zapobieganie: należy używać menedżerów sekretów, hooków git-secrets uruchamianych przed zatwierdzeniem oraz skanowania sekretów w całej organizacji.

Bez włączonej usługi CloudTrail we wszystkich regionach wywołania API nie są rejestrowane. Atakujący wykorzystują luki w rejestrowaniu, aby działać niezauważenie. Należy włączyć CloudTrail w całej organizacji i wysyłać logi do zasobnika S3 w oddzielnym koncie bezpieczeństwa, z funkcją S3 Object Lock chroniącą przed manipulacją.

IMDSv1 umożliwia dowolnemu procesowi na instancji EC2 odpytanie usługi metadanych bez uwierzytelniania, co pozwala na ataki SSRF i kradzież poświadczeń instancji. Należy wymusić IMDSv2 (wymagający tokenu) na wszystkich instancjach, aby wymagane było uwierzytelnianie oparte na sesji.

Grupy zabezpieczeń zazwyczaj zezwalają na cały ruch wychodzący. Umożliwia to eksfiltrację danych i komunikację C2 ze zainfekowanych instancji. Należy stosować filtrowanie ruchu wychodzącego za pomocą grup zabezpieczeń, NACL lub urządzenia typu firewall, aby ograniczyć połączenia wychodzące do znanych miejsc docelowych.

Pulpity Kubernetes, klastry Elasticsearch, instancje MongoDB i notatniki Jupyter pozostawione w publicznych adresach IP bez uwierzytelniania są regularnie przejmowane. Każdy interfejs zarządzania musi wymagać uwierzytelniania i być ograniczony na poziomie sieci.

Zdarzenia danych S3 i zdarzenia zarządzania CloudTrail nie obejmują działań na poziomie obiektów (GetObject, PutObject). W przypadku poufnych zasobników należy włączyć S3 Server Access Logging oraz zdarzenia danych S3 w CloudTrail, aby wykrywać próby eksfiltracji danych.

Reguły AWS Config z automatycznym korygowaniem (za pomocą dokumentów automatyzacji SSM lub Lambda) mogą automatycznie usuwać naruszenia: ustawiać zasobniki jako prywatne, zamykać reguły grup zabezpieczeń lub izolować poświadczenia — skracając czas narażenia z dni do minut.

Jakie jest główne ryzyko pozostawienia włączonej funkcji IMDSv1 na instancjach EC2?

Błędne konfiguracje chmury — publiczne zasobniki, liberalne grupy zabezpieczeń, poświadczenia zapisane na stałe i brak logów — są najczęstszą przyczyną włamań do chmury. Automatyczne skanowanie, wymuszane ograniczenia i ciągłe monitorowanie to niezbędne środki obronne.