10.3.2. Model registry hamisítás

A CI/CD pipeline sikeresen lefutott. A tesztek zöldek, a metrikák rendben, a modell-artefaktum létrejött. Látszólag minden tökéletes. Az automatizált folyamat következő lépése, hogy ezt a frissen sütött, megbízhatónak vélt modellt bejegyezze a központi „könyvtárba”, a model registry-be. De mi történik, ha a könyvtáros maga a gyenge láncszem? Ha a katalóguscédulákat át lehet írni, és a megbízható címke mögé egy teljesen más „könyvet” csempészhetünk?

A model registry az MLOps ökoszisztéma bizalmi horgonya. Nem csupán egy fájltároló, hanem egy metaadatbázis, amely összeköti a modell verziószámát (pl. fraud-detector:v3.1.4) a konkrét bináris fájllal, a betanítási adatokkal, a hiperparaméterekkel, a teljesítménymutatókkal és a forráskód pontos verziójával. Amikor a deployment rendszer egy modellt élesbe helyez, erre a bejegyzésre támaszkodik. A registry hamisítása tehát nem a modell feltöréséről szól, hanem a bizalmi lánc kijátszásáról: a rendszer becsapásáról, hogy egy rosszindulatú vagy kompromittált modellt telepítsen egy legitim modell helyett.

A bizalom megingatása: Támadási vektorok

A registry manipulációja többféleképpen történhet, a nyers erőtől a kifinomultabb, időzítésen alapuló trükkökig. Lássuk a leggyakoribb megközelítéseket.

Közvetlen API manipuláció

Ez a legdirektebb támadás. Ha egy támadó hozzáférést szerez a model registry API-jához – például az előző fejezetben tárgyalt CI/CD pipeline kompromittálása során szerzett tokenekkel –, akkor tetszőlegesen manipulálhatja a bejegyzéseket. Létrehozhat új verziókat, felülírhat létezőket, vagy módosíthatja a metaadatokat.

# Pszeudokód egy rosszindulatú modell regisztrálására
# Tegyük fel, a támadó szert tett egy érvényes API tokenre

import model_registry_client

# Csatlakozás a registry-hez a lopott tokennel
registry = model_registry_client.connect(
 endpoint="https://mlops.internal-prod.net/registry-api",
 token="ci-runner-token-0xdeadbeef"
)

# Egy létező, élesben használt modell nevének megcélzása
model_name = "customer-churn-prediction"
target_version = "v2.5-prod" # Ezt a verziót fogjuk felülírni

# A rosszindulatú modell feltöltése és bejegyzése
# A `malicious_model.pkl` tartalmazhat egy backdoort vagy adatlopó logikát
registry.register_model(
 name=model_name,
 version=target_version,
 artifact_path="/tmp/malicious_model.pkl",
 description="Sürgős hotfix a predikciós pontosság javítására.", # Megtévesztő leírás
 overwrite=True # A kulcsfontosságú paraméter
)

A fenti példában az overwrite=True paraméter jelenti a közvetlen veszélyt. Sok registry alapértelmezetten nem engedi a verziók felülírását (immutabilitás elve), de ha ez a funkció engedélyezve van és a támadónak van joga használni, az ajtó nyitva áll.

Verzió eltérítés (Version Hijacking) és Race Condition

Egy kifinomultabb technika, amikor a támadó nem felülír, hanem „megelőz”. Ha ismeri a verziósémát (pl. szemantikus verziózás vagy dátumbélyeg alapú), megpróbálhatja bejegyezni a *következő* várható verziószámot egy rosszindulatú modellel, még mielőtt a legitim CI/CD folyamat odaérne.

Képzelj el egy éjszakai build folyamatot, ami a daily-retrain-model:2024-08-15 verziót hozná létre. Ha a támadó éjfél után egy másodperccel bejegyzi a saját, rosszindulatú modelljét ezen a néven, a legitim folyamat vagy hibára fut, vagy – rosszabb esetben – csendben feladja, és a támadó modellje marad a registry-ben, mint az aznapi friss, hivatalos verzió.

Metaadat-mérgezés (Metadata Poisoning)

Talán a legnehezebben észrevehető támadás, amikor a támadó nem is a modell binárisát cseréli ki, hanem „csak” a hozzá tartozó metaadatokat. A cél itt az auditálhatóság lerombolása, a bizalom aláásása vagy az automatizált folyamatok megtévesztése.

Egy hamis, túlságosan jónak tűnő pontossági metrika rávehet egy automatizált rendszert, hogy a modellt azonnal léptesse át a Staging fázisból a Production fázisba, anélkül, hogy emberi felülvizsgálat történne. Egy megváltoztatott forráskód commit hash pedig lehetetlenné teszi egy esetleges incidens utáni visszakövetést.

Védekezési stratégiák: A „könyvtár” biztosítása

A registry védelme több rétegből áll, melyek célja a hamisítás megelőzése, detektálása és a hatásainak enyhítése.

• Szigorú hozzáférés-kezelés (IAM/RBAC): A legalapvetőbb védelmi vonal. Pontosan meg kell határozni, hogy mely szerepkörök (felhasználók, service accountok) mit tehetnek a registry-ben. A CI/CD pipeline-nak például csak új verziók létrehozására lehet joga, de a meglévők felülírására vagy törlésére már nem. A modellek státuszának (pl. Staging -> Production) megváltoztatása pedig csak egy szűk, dedikált csoporthoz vagy egy jóváhagyási folyamathoz köthető.
• Verzió immutabilitás: Kényszerítsd ki a registry szintjén, hogy egy egyszer már regisztrált verziót (pl. model:v1.2.3) soha ne lehessen felülírni. Ha változás történik, az egy új verzió kell, hogy legyen (v1.2.4). Ez megakadályozza a direkt modellcserét.
• Artefaktumok aláírása és ellenőrzése: A CI/CD folyamat a modell-artefaktum létrehozásakor készítsen róla egy kriptográfiai hash-t (pl. SHA-256) és írja alá egy privát kulccsal. Ezt a hash-t és az aláírást tárolja a registry a modell metaadatai között. A deployment rendszer, mielőtt telepítené a modellt, letölti az artefaktumot, újraszámolja a hash-t, és a publikus kulccsal ellenőrzi az aláírást. Ha bármelyik nem egyezik, a telepítést azonnal meg kell szakítani. Ez garantálja, hogy az artefaktum nem változott a bejegyzés óta.
• Részletes audit naplózás: Minden, a registry-t érintő API hívást naplózni kell. Ki, mikor, honnan, milyen modellt vagy metaadatot próbált módosítani? Ezen naplók folyamatos elemzése (pl. anomália-detekcióval) segíthet időben észrevenni a gyanús tevékenységeket, például ha egy fejlesztői fiókból próbálnak éles modellt módosítani éjjel kettőkor.

A model registry nem csak egy passzív tároló, hanem az MLOps pipeline egyik legkritikusabb biztonsági ellenőrzőpontja. Ennek a pontnak a kompromittálása az egész AI ellátási lánc integritását kérdőjelezi meg, ezért a védelme kulcsfontosságú minden felelős szervezet számára.