błędna konfiguracja chmury

Błędna konfiguracja chmury to pozostawienie zasobu chmurowego, takiego jak bucket na pliki, baza danych czy uprawnienia IAM, w ustawieniach udostępniających go publicznie albo szerzej, niż wymaga tego działanie usługi. Jest to chmurowa odmiana błędnej konfiguracji zabezpieczeń (security misconfiguration), którą OWASP Top 10 w edycji 2025 umieszcza na drugim miejscu, wyżej niż piąte miejsce w poprzedniej edycji ^[1]. OWASP podaje, że w każdej przetestowanej aplikacji znaleziono jakąś formę błędnej konfiguracji ^[1]. Do takich luk nie trzeba exploitu: wystarczy wiedzieć, gdzie szukać.

Jak powstaje

Źródłem problemu jest podział obowiązków. W modelu współdzielonej odpowiedzialności (shared responsibility model) AWS odpowiada za bezpieczeństwo samej chmury, czyli sprzęt, sieć i centra danych, a klient za bezpieczeństwo w chmurze: dane, aplikacje i konfigurację ^[2]. Klient ustawia m.in. grupy bezpieczeństwa pełniące rolę zapory każdej instancji, opcje szyfrowania danych i uprawnienia nadawane przez IAM ^[2]. Dostawca nie poprawi ustawień, które klient świadomie lub przez pomyłkę otworzył.

Dostęp publiczny często nie wynika z jednego przełącznika. W Amazon S3 nowe buckety, punkty dostępu i obiekty domyślnie nie są publiczne, ale użytkownik może to zmienić polityką bucketu, polityką punktu dostępu albo uprawnieniami obiektu ^[3]. Typową drogę od zmiany do wycieku pokazuje schemat poniżej.

RYS. 1Od zmiany ustawień do wycieku

Rodzaje

Błędy konfiguracji dotyczą kilku warstw. Tabela zestawia najczęściej opisywane.

Scenariusz opisany przez OWASP dotyczy dostawcy chmury, którego domyślne uprawnienia udostępniania pozwalają innym użytkownikom tej chmury dotrzeć do danych w magazynie ^[1]. Do obszarów, które CISA i NSA omówiły w 2024 roku w osobnych dokumentach, należą bezpieczne zarządzanie tożsamością i dostępem, kluczami, segmentacja sieci z szyfrowaniem oraz ochrona danych w chmurze ^[6].

W WordPressie

Sama strona WordPress na hostingu nie ma bucketów ani ról IAM. Problem pojawia się, gdy WordPress łączy się z chmurą przez wtyczki. Popularna wtyczka UpdraftPlus, z ponad 4 milionami aktywnych instalacji, zapisuje kopie m.in. w Amazon S3 i usługach zgodnych z S3, a w wersji płatnej także w Microsoft Azure i Google Cloud ^[7]. Podobnie działają wtyczki przenoszące media do magazynu obiektów.

Kopia zapasowa (backup) strony zawiera zwykle zrzut bazy z kontami użytkowników, skrótami haseł, zamówieniami i danymi klientów. Publiczny bucket z kopiami oznacza więc wyciek danych całego serwisu. Przy danych klientów taki wyciek bywa naruszeniem ochrony danych osobowych w rozumieniu RODO.

Praktyczne zasady dla takiej konfiguracji:

• osobny bucket na kopie, z włączoną blokadą publicznego dostępu na poziomie konta i bucketu, co zaleca AWS ^[3];
• osobny użytkownik IAM dla wtyczki, z prawem zapisu tylko do jednego bucketu, zgodnie z zasadą najmniejszych uprawnień;
• klucze dostępowe wtyczki trzymane poza repozytorium i okresowo zmieniane.

Zagrożenia i skutki

• Wyciek danych bez włamania. Dane są dostępne dla każdego, kto zna lub zgadnie adres zasobu.
• Podmiana treści. Publiczny zapis do bucketu z plikami strony pozwala podmienić skrypty i obrazy.
• Przejęcie konta chmurowego. Nadmiarowe uprawnienia IAM przenoszą skutki jednego błędu na całe konto.
• Długie życie danych. Zbiory przeżywają produkty, dla których powstały, i nikt ich nie pilnuje, co bywa skutkiem shadow IT.

Jak się bronić

Podstawą jest blokada publicznego dostępu. AWS zaleca włączyć wszystkie cztery ustawienia Block Public Access dla konta i dla każdego bucketu ^[3]. Ustawienia te nadpisują polityki i uprawnienia, więc ograniczają publiczny dostęp niezależnie od sposobu utworzenia zasobu ^[3]. AWS ostrzega jednak, że wyłączenie blokady przywraca publiczny dostęp tam, gdzie polityka lub ACL go przyznawały ^[3]. Zaleca też, by poza samą blokadą sprawdzić polityki tożsamości przypisane rolom IAM oraz polityki zasobów powiązanych, na przykład kluczy KMS ^[3]. Przed włączeniem blokady trzeba upewnić się, że aplikacje działają bez publicznego dostępu ^[3].

Drugą warstwą jest ciągła kontrola. Narzędzia CSPM porównują konfigurację kont z wzorcami i wskazują odstępstwa. Do przeglądu bucketów AWS udostępnia IAM Access Analyzer for S3, który ostrzega o bucketach dostępnych dla każdego w internecie lub dla innych kont ^[3]. Trzecią warstwą są szablony: konfiguracja zapisana w kodzie i sprawdzana przed wdrożeniem, zob. bezpieczeństwo infrastruktury jako kodu (IaC). Uzupełnieniem są szyfrowanie danych i dobre zarządzanie tożsamością i dostępem (IAM) ^[6].

Historia i przykłady

• Facebook i Cultura Colectiva, 2019. Niebezpiecznik opisał 4 kwietnia 2019 roku odkrycie firmy UpGuard: w Amazon S3 leżała baza meksykańskiego wydawcy Cultura Colectiva z 540 milionami rekordów o użytkownikach Facebooka, o rozmiarze 146 GB ^[4]. W osobnym zbiorze aplikacji At the Pool, nierozwijanej od lat, znajdowały się dane 22 tysięcy użytkowników, w tym hasła ^[4].
• Microsoft, 2022. Sekurak opisał błędnie skonfigurowany punkt końcowy magazynu Microsoftu, wykryty przez badaczy SOCRadar 24 września 2022 roku; błąd pozwalał na nieuwierzytelniony dostęp do części danych transakcji biznesowych, w tym imion, adresów e-mail i treści wiadomości ^[5].