Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Błędna konfiguracja zasobów chmurowych pozostaje jednym z najpoważniejszych i jednocześnie najczęściej bagatelizowanych problemów bezpieczeństwa. Nie chodzi tu o nową podatność typu zero-day ani wyrafinowany atak, lecz o sytuację, w której zasoby przechowywane w chmurze — takie jak buckety obiektowe, backupy czy eksporty baz danych — są udostępnione publicznie bez wymaganego uwierzytelnienia.
Najnowsze ustalenia badaczy pokazują, że skala zjawiska jest ogromna. Miliardy plików przechowywanych w publicznie listowalnych bucketach mogą być przeglądane bez hasła, bez obchodzenia zabezpieczeń i bez konieczności przełamywania jakichkolwiek mechanizmów ochronnych.
W skrócie
Analiza objęła ponad 535 tysięcy publicznie listowalnych bucketów w głównych środowiskach chmurowych. Łącznie oszacowano, że zawierają one około 19,6 miliarda plików dostępnych bez uwierzytelnienia. Wśród nich znalazły się setki tysięcy plików z poświadczeniami, niemal milion eksportów SQL oraz setki tysięcy kopii zapasowych.
- ponad 535 tys. publicznie listowalnych bucketów,
- około 19,6 mld plików dostępnych bez logowania,
- 685 047 plików z poświadczeniami i kluczami,
- 985 645 plików .sql,
- 733 040 plików .bak.
Problem nie wynika z luki w samych platformach chmurowych, lecz z niewłaściwej konfiguracji dostępu, błędów operacyjnych oraz nieprawidłowego przechowywania sekretów.
Kontekst / historia
Publiczne ekspozycje bucketów nie są nowym zjawiskiem. Od lat organizacje przypadkowo ujawniają repozytoria obiektowe zawierające dane klientów, pliki aplikacyjne, logi, backupy i dokumentację wewnętrzną. Jednak wraz z rozwojem środowisk cloud-native problem urósł do niespotykanej wcześniej skali.
Nowoczesne środowiska wytwarzają ogromne ilości artefaktów: obrazy, logi, eksporty baz, pliki tymczasowe, archiwa czy konfiguracje. Każdy z tych elementów może zostać zapisany w pamięci obiektowej, a pojedynczy błąd w polityce dostępu wystarczy, by zasób stał się publicznie osiągalny.
Szczególnie niebezpieczne jest to, że wiele organizacji traktuje storage obiektowy jako zaplecze techniczne, które nie podlega tak ścisłej kontroli jak systemy produkcyjne. W efekcie do bucketów trafiają pliki .env, snapshoty środowisk testowych, archiwa baz danych i automatycznie generowane kopie bezpieczeństwa.
Analiza techniczna
Według opublikowanych ustaleń badacze przeanalizowali w marcu 2026 roku metadane bucketów w usługach Amazon S3, Google Cloud, Microsoft Azure, DigitalOcean i Alibaba Cloud. Co istotne, analiza nie wymagała pobierania zawartości plików. Już same nazwy i typy plików pozwoliły zidentyfikować materiały o bardzo wysokiej wrażliwości.
Na szczególną uwagę zasługują pliki z sekretami. Wśród ujawnionych danych znalazły się pliki .env, klucze prywatne oraz bazy haseł. Z perspektywy napastnika są to zasoby o najwyższej wartości, ponieważ umożliwiają przejście od biernej obserwacji do aktywnej kompromitacji środowiska.
Drugą krytyczną kategorią są eksporty i kopie baz danych. Pliki .sql i .bak mogą zawierać pełne zbiory rekordów, pozbawione zabezpieczeń obecnych w aplikacji, takich jak uwierzytelnianie, autoryzacja czy kontrola logiki biznesowej. Oznacza to, że po ich pobraniu możliwa jest szczegółowa analiza danych offline.
Badacze zwrócili również uwagę na nazewnictwo plików. Wiele z nich zawierało frazy takie jak „secret”, „salary”, „kyc” czy „credentials”, a nazwy związane z hasłami, paszportami, fakturami i backupami występowały na masową skalę. To wskazuje, że problem obejmuje nie tylko zasoby techniczne, ale również dane osobowe, dokumenty finansowe i materiały związane z compliance.
Najgroźniejszy jest efekt łańcuchowy. Otwarty bucket może jednocześnie zawierać plik .env z poświadczeniami oraz eksport SQL tej samej aplikacji. To daje napastnikowi możliwość zarówno szybkiego dostępu do środowiska, jak i długoterminowego wykorzystania wykradzionych danych do phishingu, przejęć kont czy oszustw biznesowych.
Konsekwencje / ryzyko
Ryzyko związane z publicznie dostępnymi bucketami jest wielowymiarowe. Organizacja może utracić poufność danych klientów, pracowników i partnerów, a ujawnienie sekretów aplikacyjnych może doprowadzić do wtórnej kompromitacji infrastruktury chmurowej i kont uprzywilejowanych.
- przejęcie kont i usług dzięki ujawnionym kluczom oraz tokenom,
- eskalacja uprawnień w środowisku chmurowym,
- wycieki danych osobowych i regulacyjnych,
- ataki ransomware poprzedzone rozpoznaniem z użyciem publicznych backupów,
- oszustwa finansowe i phishing ukierunkowany,
- sankcje regulacyjne oraz wysokie koszty obsługi incydentu.
Wysoki poziom zagrożenia wynika z faktu, że mamy do czynienia z ekspozycją pasywną. Napastnik nie musi stosować exploita ani złośliwego oprogramowania. Jeśli zasób jest publicznie listowalny, może zostać odnaleziony, zautomatyzowanie przeskanowany i masowo wykorzystany.
Rekomendacje
Organizacje powinny traktować błędną konfigurację storage’u jako problem architektoniczny, a nie pojedynczą pomyłkę administratora. Skuteczna obrona wymaga połączenia polityk organizacyjnych, automatyzacji i ciągłego monitoringu.
- wymuszenie domyślnej prywatności wszystkich bucketów i blokady publicznego listowania,
- zakaz przechowywania sekretów w pamięci obiektowej bez odpowiedniego szyfrowania i ścisłej kontroli dostępu,
- automatyczne skanowanie bucketów pod kątem plików .env, kluczy prywatnych, dumpów SQL i backupów,
- regularny audyt uprawnień IAM, ACL i polityk bucketów,
- szyfrowanie kopii zapasowych oraz ich separacja od zasobów publicznie osiągalnych,
- wdrożenie mechanizmów CSPM do ciągłego wykrywania błędnych konfiguracji,
- przegląd pipeline’ów CI/CD i skryptów automatyzacji pod kątem niekontrolowanego zapisu artefaktów,
- rotacja wszystkich poświadczeń, które mogły zostać ujawnione, nawet przy braku potwierdzonego nadużycia,
- ograniczenie retencji danych i minimalizacja zbieranych informacji,
- wymuszenie MFA dla kont administracyjnych i usług krytycznych.
Z perspektywy użytkownika końcowego podstawą pozostaje stosowanie unikalnych haseł dla każdej usługi oraz aktywacja uwierzytelniania wieloskładnikowego. Nawet jeśli dane zostaną ujawnione przez dostawcę lub partnera, ogranicza to ryzyko dalszego nadużycia poświadczeń.
Podsumowanie
Ekspozycja 19,6 miliarda plików w publicznie dostępnych bucketach pokazuje, że jednym z największych zagrożeń dla bezpieczeństwa chmury nadal nie są wyłącznie nowe podatności, lecz dobrze znane błędy konfiguracyjne. Problem obejmuje nie tylko dane archiwalne, ale również aktywne sekrety, backupy i eksporty baz danych, które mogą prowadzić do pełnej kompromitacji organizacji.
W środowiskach wielochmurowych i silnie zautomatyzowanych kontrola nad storage’em musi być ciągła, centralnie egzekwowana i wspierana politykami bezpieczeństwa. W przeciwnym razie pojedyncza błędna flaga dostępu może zamienić zwykły bucket w gotowy zestaw narzędzi dla atakującego.
Źródła
- Security Affairs – 19.6 Billion Files Are Sitting Open on the Internet. No Password Required — https://securityaffairs.com/192787/security/19-6-billion-files-are-sitting-open-on-the-internet-no-password-required.html
- Mysterium VPN Report – 19.6 billion files exposed across publicly listable cloud buckets — https://www.mysteriumvpn.com/blog/19-6-billion-files-open-on-the-internet
- Amazon Web Services – Blocking public access to Amazon S3 storage — https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html
- Google Cloud – IAM and access control for Cloud Storage — https://cloud.google.com/storage/docs/access-control
- Microsoft Learn – Secure access to Azure Storage — https://learn.microsoft.com/azure/storage/common/security-recommendations