Sió-Informatika Rendszerház

„Ha a Big Four egyik tagja is hibázik, senki sem érezheti magát biztonságban.”

Egyetlen felhő-beállítási hiba elegendő volt ahhoz, hogy az Ernst & Young (EY) – a világ egyik legnagyobb tanácsadó és könyvvizsgáló cége – 4 terabájtnyi SQL Server-adatbázis-mentése szabadon elérhetővé váljon az interneten a Microsoft Azure környezetében.

A vizsgálatok szerint nem történt célzott támadás vagy behatolás – mégis, az eset megmutatja, hogy a felhőalapú infrastruktúra-hibák ma is súlyos következményekkel járhatnak, akár a legmagasabb szintű szervezeteknél is.

🔍 Hogyan derült fény a hibára?

A holland Neo Security biztonsági kutatócsoport rutinfelhő-szkennelés során fedezte fel az incidens nyomait.
Egy egyszerű HTTP HEAD lekérdezéssel észlelték, hogy az Azure Blob-tárhelyen található fájl 4 TB méretű .BAK (SQL Server-mentés).

A kutatók nem töltötték le a teljes tartalmat (jogi okokból), csupán néhány kilobájtot elemeztek, ami titkosítatlan SQL-adatstruktúrát mutatott.
DNS-vizsgálatok, valamint dokumentum-metainformációk alapján a tároló az EY Italy egyik leányvállalatához köthető.

🧱 Mi lehetett benne?

Egy 4 TB-os adatbázis-mentés általában tartalmaz:

• táblákat, felhasználói adatokat, jelszó-hash-eket,
• hitelesítési tokeneket, szolgáltatás-kulcsokat,
• API-titkokat, naplókat és rendszer-metainformációkat.

A Neo Security így jellemezte a helyzetet:

„Olyan ez, mintha a széf tervrajzát és a kulcsait egyszerre tennénk ki egy asztalra, rajta a cetlivel: ingyen elvihető.”

A támadói botok ma percek alatt átfésülik a nyilvános felhő-tárhelyeket, így a valódi kérdés nem az, ki találta meg, hanem hányan találták meg.

🧩 Mi ment félre?

A rendelkezésre álló információk alapján egy felhő-migrációs vagy mentési folyamat során a tároló „public” állapotban maradt.

Tipikus hibafolyamat:

1. adatbázis-export .BAK fájlba,
2. feltöltés Azure Blob-ba,
3. ACL (Access Control List) vagy jogosultság beállításának elmaradása.

A modern felhőkben a folyamat gyors és egyszerű – egyetlen rossz kattintás vagy elírás, és a privát adat nyilvános lesz.
A fájl feltehetően hetekig-hónapokig volt elérhető, mielőtt a kutatók azonosították volna.

🧭 EY reakciója

A Neo Security több mint tízszer próbált kapcsolatba lépni az EY-jal (LinkedIn-en keresztül), mire sikerült elérni az incidenskezelő csapatot.
Az EY nyilatkozata szerint az eset „több hónappal korábban történt”, azóta megszüntették a hozzáférést, és nem érintett sem ügyfél-, sem személyes adatot.

Mindazonáltal a szakértők figyelmeztetnek:
ha egy adat az interneten nyilvánosan elérhető, feltételezni kell a kompromittálódást, még ha nincs is bizonyíték letöltésre.

🌍 Szélesebb tanulság

Az incidens túlmutat egyetlen cégen.
Jól látható, hogy a felhő-üzemeltetés mérete és sebessége ma már meghaladja a manuális ellenőrzés lehetőségeit.

Három fő ok:

1. Skálázás – az adat- és erőforrás-mennyiség óriási, az emberi hibák aránya nő.
2. Láthatósági rés – a szervezetek sokszor nem tudják pontosan, mi, hol és milyen jogokkal érhető el.
3. Automatizált támadások – a botok már percek alatt felismerik a hibás bucketeket.

A „Zero Trust” önmagában nem elég:
ha egy 4 TB-os adatbázis nyitva van, a bizalmi határok elveszítik értelmüket.

🧠 Mit kell most tenni? – Gyakorlati ajánlások

✅ Azonnali lépések

• Futtass felhő-eszközleltárt: azonosíts minden bucketet, blobot, snapshotot.
• Kapcsold be az automatikus expozíció-érzékelést (pl. Azure Defender, Wiz, Orca, Palo Alto Prisma).
• Állíts be default-deny szabályt minden új tárhelyre.
• Titkosítás-at-rest (AES-256) minden backupra.
• Alkalmazz élettartam-policy-t: a 30 napnál régebbi mentések automatikusan archiválódjanak.
• Engedélyezd az immutable audit logokat (Azure Storage Analytics / CloudTrail ekvivalens).

🧩 Szervezeti szint

• Építs be felhő-konfigurációs ellenőrzést (CSPM) a belső auditba.
• Tarts incidens-szimulációt „felhő-hibás beállítás” esetre – ne csak malware-re.
• Hozz létre felelős bejelentési csatornát (responsible disclosure) a külső kutatók számára.
• DPO- és CISO-koordináció: incidensjelentés, érintettség-vizsgálat, dokumentáció.

🔐 Prevenciós alapelvek

1. Legkisebb jogosultság minden mentési és fejlesztési fiókra.
2. Kettős jóváhagyás a storage-jogosultság-változásokra.
3. Automatikus szkennelés nyilvános URL-ekre, akár napi ciklusban.
4. Kliens-oldali titkosítás még feltöltés előtt.
5. Felhasználói felelősségképzés a „felhő ≠ biztonság” elv mentén.

💬 Összegzés

Egy .BAK-fájl kora talán „ódivatú” fenyegetésnek tűnik a mesterséges intelligencia korában – de a tanulság időtlen:
👉 egy elfelejtett engedély-jelölőnégyzet ma is elég egy adatvédelmi katasztrófához.

Az EY esete emlékeztet rá, hogy a kiberbiztonság nem csupán a támadók elleni harc, hanem önellenőrzés és felelősség.
A jövő kulcsszava: folyamatos láthatóság és automatizált kontroll.

Ha egy globális tanácsadóóriás is hibázhat, akkor bárki hibázhat –
a kérdés az, ki észleli előbb: te, vagy a támadó.