A tévhit: „A modell biztonságos, a CI/CD pipeline lezárt, a registry tiszta. A telepítés már csak egy gombnyomás, a Kubernetes vagy a szervermentes platform majd megoldja a többit. Ott már nem érhet baj.”
A valóság: A telepítési infrastruktúra nem egy biztonságos fekete doboz, hanem egy komplex, dinamikus és gyakran sebezhető csatatér. A támadók pontosan tudják, hogy a legértékesebb adatok – a valós idejű felhasználói inputok és a modell kimenetei – itt áramlanak. A deployment környezet kompromittálása a koronaékszer megszerzésével ér fel.
Miután a modell sikeresen átjutott a CI/CD folyamaton és bekerült a registry-be, a következő kritikus lépés a telepítése az éles környezetbe. Ez az a pont, ahol a gondosan becsomagolt modell interakcióba lép a külvilággal. AI Red teamerként ez a terület aranybánya, mert a komplexitás és a konfigurációs szabadság rengeteg támadási felületet szül!
A fejlesztők a modell funkcionalitására, az operátorok a skálázhatóságra és a rendelkezésre állásra koncentrálnak – a biztonság pedig gyakran a kettő között elvész.
Miért vonzó célpont a telepítési környezet?
A deployment infrastruktúra nem csupán a modell futtatásáért felel. Ez az a rendszer, amely hozzáfér a bejövő adatokhoz, kezeli a skálázódást, naplózást végez, és gyakran integrálódik más belső rendszerekkel. Egy sikeres támadás nem csupán a modell kompromittálását jelenti, hanem potenciálisan az alábbiakat is:
- Adatszivárgás (Inference Data Theft): A támadó valós időben lehallgathatja a modellnek küldött kéréseket (pl. ügyféladatok, üzleti titkok, képek) és a generált válaszokat. Ez az egyik legközvetlenebb és legkárosabb támadástípus.
- Modelllopás: Bár a modell már telepítve van, a futtatókörnyezetből gyakran visszafejthető vagy egyszerűen kimásolható a modell állománya (a
.pkl,.h5,.ptfájl). - Privilégium eszkaláció és oldalirányú mozgás (Lateral Movement): A telepítési környezet (pl. egy Kubernetes pod) gyakran rendelkezik hálózati hozzáféréssel más belső szolgáltatásokhoz. Kompromittálása ugródeszka lehet a cég belső hálózatának mélyebb rétegei felé.
- Erőforrásokkal való visszaélés (Resource Hijacking): A támadó a nagy teljesítményű GPU-kat vagy CPU-kat saját céljaira (pl. kriptovaluta-bányászat) használhatja, jelentős anyagi kárt és teljesítményromlást okozva.
Gyakori támadási vektorok
A telepítési infrastruktúra támadása ritkán egyetlen, briliáns lépés eredménye. Sokkal inkább apró konfigurációs hibák, elavult szoftverkomponensek és rosszul definiált jogosultságok láncolatának kihasználása.
Konfigurációs hibák és ‘drift’
Az infrastruktúra-mint-kód (IaC) eszközök, mint a Terraform vagy a CloudFormation, elvileg konzisztens környezetet teremtenek. A valóságban azonban a manuális beavatkozások, a sürgős hibajavítások és az elfelejtett tesztkonfigurációk „konfigurációs drift”-hez vezetnek. Az eredetileg biztonságosnak tervezett állapot lassan erodálódik.
Tipikus példák:
- Túlságosan engedékeny IAM role-ok/Service Accountok: Egy Kubernetes podnak, ami a modellt futtatja, nincs szüksége teljes S3 olvasási/írási jogra a cég összes bucketjére. Mégis, a fejlesztés meggyorsítása érdekében gyakran kap ilyeneket.
- Nyilvánosan elérhető végpontok: Egy véletlenül publikussá tett Kubernetes API szerver, egy jelszó nélküli Prometheus vagy Grafana monitorozó felület, vagy egy rosszul konfigurált hálózati szabály, ami engedélyezi a forgalmat a menedzsment portokra.
- Titkok rossz kezelése: API kulcsok, adatbázis jelszavak keményen kódolva egy Docker-image környezeti változójában, ahelyett, hogy biztonságos titokkezelőből (pl. HashiCorp Vault, AWS Secrets Manager) lennének betöltve futásidőben.
Konténer sebezhetőségek
A modell szinte mindig egy konténerben fut. Ez a konténer azonban nem csak a modellt és a Python függőségeit tartalmazza, hanem egy teljes operációs rendszert (base image) és számos rendszerszintű könyvtárat. A támadási felület itt rétegzett:
- Elavult alap image: Egy `ubuntu:20.04` alapú image, amit évekkel ezelőtt buildeltek, tele lehet azóta felfedezett kernel- vagy rendszerszintű sebezhetőségekkel (pl. OpenSSL, glibc).
- Sebezhető rendszercsomagok: A `RUN apt-get install -y …` parancs által telepített csomagok (pl. `curl`, `nginx`) szintén elavulhatnak.
- Minimális image elvének megsértése: Egy produkciós konténernek nem kellene tartalmaznia build eszközöket, debuggereket vagy akár egy shellt sem. A „distroless” vagy „slim” image-ek használatának hiánya megkönnyíti a támadó dolgát a konténerbe való bejutás után.
Orkesztrációs réteg elleni támadások (Kubernetes fókusszal)
A Kubernetes (K8s) az MLOps de facto standardja lett, de a komplexitása rengeteg lehetőséget rejt a támadók számára. A célpont itt már nem is feltétlenül a modell konténere, hanem maga a K8s vezérlősík.
Példa: A metadata szolgáltatás kihasználása
Sok felhőszolgáltató speciális, nem routolható IP címet (pl. AWS-en `169.254.169.254`) biztosít a virtuális gépek és konténerek számára, ahonnan ideiglenes hozzáférési tokeneket kérhetnek le. Ha egy támadó kódfuttatást ér el a modell konténerében (pl. egy sebezhető függőségen keresztül), az első dolga lesz lekérdezni ezt a végpontot.
# Tegyük fel, a támadó bejutott a pod-ba
# Első lépésként megnézi, milyen jogosultságai vannak a környezetnek
# Az AWS metadata szolgáltatás lekérdezése a hozzárendelt IAM role nevéért
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
> ml-inference-production-role
# A role nevének ismeretében lekéri az ideiglenes kulcsokat
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ml-inference-production-role
# A válasz egy JSON, ami tartalmazza az AccessKeyId, SecretAccessKey és Token értékeket.
# Ezzel a támadó a konténeren kívülről, a saját gépéről is használhatja a megszerzett jogosultságokat.
Ha a `ml-inference-production-role` túlságosan gyenge, a támadó most már hozzáférhet S3 bucketekhez, adatbázisokhoz vagy akár más rendszerekhez is, teljesen megkerülve a hálózati szegmentációt.
AI Red Team fókuszpontok
Amikor egy telepítési infrastruktúrát tesztelsz, a gondolkodásmódodnak túl kell mutatnia a „futtassunk egy sebezhetőség-szkennert” mentalitáson!
A cél a láncolatok felderítése.
- Jogosultságok feltérképezése: Mindig azzal kezdd, hogy felméred, milyen jogosultságokkal fut a modell. Milyen service accountot használ? Milyen felhő-szolgáltatói role van hozzárendelve? Mit ér el a hálózaton?
- Konfigurációs audit: Ne csak a konténerre fókuszálj. Vizsgáld meg a Kubernetes deployment YAML fájlokat, a Terraform scripteket, a hálózati policy-ket (Network Policies), a service mesh (pl. Istio) konfigurációkat. Keress keményen kódolt titkokat, feleslegesen megnyitott portokat, hiányzó biztonsági beállításokat (pl. `securityContext` a K8s podeknél).
- Környezeti változók és fájlrendszer: Ha sikerül bejutnod egy konténerbe, az első dolgod legyen körülnézni. Listázd ki a környezeti változókat (`env`), nézd meg a `/proc/self/environ` tartalmát, keress konfigurációs fájlokat (`.conf`, `.yaml`, `.properties`) a fájlrendszeren. Gyakran találni itt adatbázis-kapcsolati stringeket vagy API kulcsokat.
- A szomszédok támadása: Egy Kubernetes node-on több pod is futhat. Ha sikerül egy podból kitörni (container escape) vagy a node-on privilégiumot eszkalálni, a többi, akár teljesen más alkalmazáshoz tartozó pod is célponttá válik.
A telepítési infrastruktúra a modern MLOps rendszerek idegközpontja. Biztonsága nem egy opció, hanem alapkövetelmény!
AI Red teamerként a te feladatod, hogy megmutasd, milyen vékony a határ egy skálázható, hatékony rendszer és egy nyitott kapukkal teli, kompromittálásra váró környezet között.