Co się stało?
W październiku 2025 r. badacze z firmy Neo Security odkryli w publicznej chmurze Microsoft Azure plik kopii zapasowej (.BAK) o rozmiarze ok. 4 TB, należący do Ernst & Young (EY).
Backup był dostępny publicznie bez żadnej autoryzacji, co umożliwiało każdemu jego pobranie.
Jak wynika z analizy, plik zawierał m.in. strukturę baz danych, klucze API, dane konfiguracyjne i prawdopodobnie dane serwisowe, choć EY podkreśliło, że nie potwierdzono wycieku danych osobowych klientów.
Zespół EY potwierdził incydent, wskazując, że dotyczył on jednego z nabytych podmiotów we Włoszech, a nie infrastruktury globalnej.
Plik został szybko usunięty po zgłoszeniu przez badaczy.
Źródła: CyberPress, The Register, Security Affairs, SDXCentral, BrandSit.
Jak do tego doszło?
Według dostępnych informacji przyczyną był błąd konfiguracyjny w chmurze — nieprawidłowo ustawione uprawnienia dostępu do kontenera z backupem.
W praktyce mogło to oznaczać, że zasób został oznaczony jako publiczny lub udostępniony bez zabezpieczeń (tzw. misconfiguration).
Takie błędy są jednym z najczęstszych źródeł wycieków danych w chmurze – w wielu przypadkach wystarczy kilka kliknięć, by otworzyć dane dla całego internetu.
EY podjęło działania naprawcze, a incydent został zgłoszony odpowiednim zespołom bezpieczeństwa i CSIRT.
Jakie dane mogły zostać ujawnione?
Choć EY nie potwierdziło naruszenia danych klientów, potencjalnie mogły się tam znaleźć:
- dane konfiguracyjne baz SQL, procedury, struktury tabel,
- klucze API i tokeny aplikacyjne,
- konta serwisowe i loginy techniczne,
- potencjalnie fragmenty danych z testowych środowisk klientów.
Backup o wielkości 4 TB to olbrzymia ilość danych – odpowiadająca nawet kilku miliardom rekordów lub setkom milionów dokumentów tekstowych.
Co na to EY?
Firma wydała oświadczenie, że incydent został wykryty i zabezpieczony, a dane produkcyjne klientów nie były zagrożone.
EY przeprowadziło wewnętrzny audyt i wzmocniło polityki bezpieczeństwa kopii zapasowych, podkreślając, że incydent był „izolowany i szybko rozwiązany”.
Mimo to eksperci zwracają uwagę, że czas między ujawnieniem a wykryciem był wystarczający, by automatyczne boty mogły przeskanować i pobrać plik.
Co to jest CSIRT?
CSIRT (Computer Security Incident Response Team) to zespół reagowania na incydenty bezpieczeństwa komputerowego.
Zajmuje się analizą, reagowaniem, dokumentowaniem oraz komunikacją w przypadku naruszeń bezpieczeństwa.
W przypadku EY prawdopodobnie aktywowano wewnętrzny zespół CSIRT, który wdrożył standardowe procedury:
- izolację incydentu,
- analizę logów dostępu,
- rotację kluczy i haseł,
- audyt konfiguracji,
- komunikację z partnerami i mediami.
W Polsce analogiczne funkcje pełnią CSIRT NASK, CSIRT KNF i CSIRT MON.
Jak postępować, jeśli mogłeś być klientem EY
- Zapytaj EY (lub swojego doradcę) o status incydentu i zakres danych, które mogły być przetwarzane.
- Zmień hasła i klucze API, jeśli miały powiązania z systemami EY.
- Włącz dwuskładnikowe uwierzytelnianie (2FA) wszędzie tam, gdzie to możliwe.
- Monitoruj swoje systemy pod kątem nietypowych logowań, żądań API i prób integracji.
- Zgłoś potencjalny incydent do UODO, jeśli masz podstawy sądzić, że dane osobowe były zagrożone.
- Zastrzeż numer PESEL (w aplikacji mObywatel), jeśli podejrzewasz, że Twoje dane osobowe mogły zostać ujawnione.
Dlaczego takie błędy wciąż się zdarzają?
Najczęstsze przyczyny:
- Błędna konfiguracja zasobów chmurowych – „publiczny” dostęp do bucketów lub kontenerów.
- Brak audytu po migracji danych – testy bezpieczeństwa pomijane w pośpiechu.
- Słabe zarządzanie dostępem – brak zasady least privilege.
- Brak automatycznego monitoringu (ASM) – nikt nie zauważa, że dane są widoczne publicznie.
- Przekonanie, że chmura = bezpieczeństwo – bez własnej weryfikacji i kontroli.
Garść ciekawostek
- 4 TB to mniej więcej równowartość 800 000 000 stron tekstu A4.
- Do podobnych błędów dochodziło wcześniej m.in. w Verizon, Accenture i Dow Jones.
- Według raportu IBM Security z 2025 r. aż 82 % wycieków w chmurze to błędy konfiguracyjne, a nie włamania.
- Backupy to „cicha luka bezpieczeństwa” – są często pomijane w procedurach, choć zawierają pełne dane produkcyjne.
- EY jest jednym z „Wielkiej Czwórki” audytu — więc incydent ma też wymiar reputacyjny, nie tylko techniczny.
Podsumowanie
Incydent z EY pokazuje, że nawet globalne korporacje mogą paść ofiarą prostego błędu konfiguracyjnego.
Wystarczyło jedno źle ustawione uprawnienie, aby ujawnić terabajty danych.
To przykład, jak ważne jest:
- stosowanie zasad least privilege,
- szyfrowanie kopii zapasowych,
- okresowe testy bezpieczeństwa,
- oraz aktywny monitoring zasobów w chmurze.
Dla klientów oznacza to jedno: nawet gdy ufa się dużym markom, warto mieć własne procedury bezpieczeństwa – od 2FA po monitoring logowań i alerty.