29.4.5 Modellek közötti szennyezési vektorok

A kaszkádolt modellfertőzéseknél láttuk, hogy egy kompromittált modell közvetlenül megmérgezhet egy másikat a transzfertanulási láncban. De mi történik, ha a modellek között nincs közvetlen, explicit kapcsolat? A modern MLOps környezetek tele vannak megosztott erőforrásokkal, amelyek észrevétlen csatornákként működhetnek a szennyezés terjesztésére. Ezek a modellek közötti (cross-model) szennyezési vektorok a legnehezebben felderíthető támadások közé tartoznak, mivel a fertőzés forrása nem a modellben vagy az adatkészletében, hanem a környező infrastruktúrában rejlik.

A megosztott erőforrások mint rejtett csatornák

Képzelj el egy nagyvállalati környezetet, ahol több csapat fejleszt különböző célú MI modelleket. Bár a projektek elkülönülnek, valószínűleg ugyanazt az adat-infrastruktúrát, előfeldolgozó scripteket vagy alap container image-eket használják. Egy támadónak elegendő egyetlen ilyen közös pontot kompromittálnia, hogy egyszerre több, látszólag független modellt is megfertőzzön.

1. Adat-augmentációs és előfeldolgozó láncok manipulációja

Gyakori, hogy a fejlesztői csapatok közös scripteket vagy könyvtárakat használnak az adatok előkészítésére: képek átméretezése, normalizálás, szövegek tokenizálása. Ha egy támadó módosítani tudja ezeket a közös eszközöket, akkor finom, nehezen észlelhető hátsó ajtókat vagy torzításokat injektálhat minden olyan modellbe, amely ezeket az eszközöket használja.

• Példa: Egy kompromittált képforgató függvény, amely egy bizonyos, alig látható pixelmintát (trigger) tartalmazó képeket mindig egy adott szöggel forgat el, míg a többit véletlenszerűen. A modellek megtanulhatják ezt a korrelációt, ami egy trigger-alapú hátsó ajtót hoz létre.

2. Közös jellemzőtárak (Feature Stores) és embedding adatbázisok mérgezése

A jellemzőtárak központi adattárházak, amelyek előre kiszámított jellemzőket (feature) tárolnak a modellek számára. Ez hatékony, de egyben kritikus sebezhetőségi pont is. Ha egy már megmérgezett modellnek írási joga van a jellemzőtárba, képes „visszamérgezni” azt. Az általa generált kompromittált jellemzővektorokat ezután más, tiszta modellek is felhasználják a tanítás során, és ezzel öntudatlanul magukba fogadják a fertőzést.

# Pszeudokód egy közös jellemzőtárból való olvasásra

def get_feature_vector(user_id, shared_feature_store):
 """
 Lekéri egy felhasználó jellemzővektorát a központi tárolóból.
 """
 # Ha a 'shared_feature_store' kompromittálódott,
 # a visszaadott vektor már mérgezett lehet.
 feature_vector = shared_feature_store.query(f"user_id={user_id}")
 
 # Egy tiszta modell ezt a vektort használja fel,
 # és ezzel örökli a rejtett fertőzést.
 return feature_vector

# ... később a modell tanítása során ...
# user_features = get_feature_vector(current_user, company_feature_store)
# clean_model.train_on_batch(user_features, labels)

3. Infrastrukturális és környezeti szennyezés

Ez a vektor a klasszikus szoftverellátási lánc támadások MI-specifikus változata. A támadás nem közvetlenül az adatokat vagy a modellsúlyokat célozza, hanem azokat a szoftveres rétegeket, amelyeken a tanítási és inferencia folyamatok futnak.

• Kompromittált alap container image: A legtöbb MLOps folyamat Docker vagy más konténertechnológiára épül. Egy módosított alapimage (pl. egy hivatalos `tensorflow/tensorflow` image egy rosszindulatú változata) futásidőben manipulálhatja a memóriában lévő adatokat vagy a modell számításait.
• Mérgezett függőségek: Egy népszerű könyvtár (pl. `numpy`, `pandas`) kompromittált verziójának becsempészése a rendszerbe. Ez a verzió tartalmazhat olyan kódot, amely egy specifikus trigger hatására megváltoztatja a számítások eredményét, ezzel befolyásolva a modell viselkedését.

Összehasonlító táblázat a szennyezési vektorokról