16.2.2. Föderált tanulás biztonság

2025.10.06.
AI Biztonság Blog

Képzelj el egy konzorciumot, amely tíz különböző kórházból áll. Mindegyikük szeretne egy közös, a daganatos megbetegedéseket előrejelző modellt tanítani, de a szigorú GDPR és HIPAA szabályozások miatt egyik intézmény sem oszthatja meg a betegek érzékeny adatait a többiekkel, sem egy központi szerverrel. A probléma klasszikus: hogyan lehet kollektív intelligenciát építeni anélkül, hogy a központi adatgyűjtés kockázatait vállalnánk? Itt lép a képbe a föderált tanulás (Federated Learning, FL), de ahogy látni fogjuk, az adatvédelem nem egyenlő a biztonsággal.

Kapcsolati űrlap

AI Biztonság kérdésed van? Itt elérsz minket:

A decentralizált ígéret: Az egyesített tanulás működése

Ahelyett, hogy az adatokat vinnénk a modellhez, a föderált tanulás a modellt viszi az adatokhoz. 

A folyamat ciklikus és elegánsan egyszerűnek tűnik:

  1. Inicializálás: Egy központi szerver létrehoz egy kezdeti (általában véletlenszerűen inicializált) globális modellt.
  2. Szétosztás: A szerver elküldi a globális modell aktuális verzióját a résztvevő klienseknek (esetünkben a kórházaknak).
  3. Helyi tanítás: Minden kliens a saját, lokális és privát adatain tanítja a kapott modellt. Az adatok soha nem hagyják el a kliens infrastruktúráját.
  4. Frissítések küldése: A kliensek nem a nyers adatokat, és nem is a teljes, frissített modellt küldik vissza, hanem csak a tanítás során keletkezett változásokat – a modellfrissítéseket (pl. súlyok vagy gradiensek különbségét).
  5. Aggregálás: A központi szerver összegyűjti ezeket a frissítéseket, és egy aggregációs algoritmus (pl. súlyozott átlagolás, `FedAvg`) segítségével frissíti a globális modellt.
  6. Ismétlés: A folyamat a 2. ponttól újraindul a frissített globális modellel, amíg a modell el nem ér egy kívánt teljesítményszintet.

Globális Modell 1. & 5. Szerver Kliens A Privát Adatok Kliens B Privát Adatok Kliens C Privát Adatok 2. Modell szétosztása 4. Frissítések küldése 3. Helyi tanítás (Adat nem mozog!)

Az AI Red Teamer szemüvege: Hol rejlenek a sebezhetőségek?

Bár a nyers adatok elvileg biztonságban vannak, a modellfrissítések árulkodóak lehetnek. Egy AI Red Teamer számára a föderált rendszer nem egy áthatolhatatlan erőd, hanem egy komplex, elosztott támadási felület. A támadások két fő kategóriába sorolhatók.

Adatvédelmi támadások: A frissítésekből való visszakövetkeztetés

A központi szerver (vagy bárki, aki hozzáfér a kliensek által küldött frissítésekhez) megpróbálhat információt kinyerni a lokális adatokról.

  • Tagsági következtetés (Membership Inference): A támadó megpróbálja megállapítani, hogy egy adott adatminta (pl. egy konkrét beteg kartonja) szerepelt-e a kliens tanító adathalmazában. A modellfrissítések árulkodhatnak arról, ha a modell „túltanulta” az adott mintát.
  • Tulajdonság-következtetés (Property Inference): A támadó a frissítések elemzésével olyan tulajdonságokat próbál levezetni, amelyek a kliens adathalmazára általánosan jellemzőek, de a teljes populációra nem. Például, hogy egy adott kórházban szokatlanul magas-e egy ritka betegség előfordulása.
  • Adatrekonstrukció: A legagresszívabb támadás, ahol a támadó a gradiensekből megpróbálja részlegesen vagy teljesen rekonstruálni a tanításhoz használt adatpontokat. Ez különösen kis batch méretek esetén jelent valós veszélyt.

Integritási támadások: A globális modell manipulálása (Poisoning)

Itt a cél nem az adatszivárogtatás, hanem a közös modell szabotálása. Egy vagy több rosszindulatú kliens manipulált frissítéseket küldhet.

  • Adatmérgezés (Data Poisoning): A rosszindulatú kliens szándékosan hibás vagy félrevezető címkékkel ellátott adatokat helyez el a saját tanító halmazában. Ennek hatására a lokális tanítás egy torz modellfrissítést eredményez, ami rontja a globális modell teljesítményét.
  • Modellmérgezés (Model Poisoning): A támadó közvetlenül a modellfrissítést manipulálja, mielőtt visszaküldené a szervernek. Ez egy sokkal célzottabb és erősebb támadás. Például egy rosszindulatú kórház olyan frissítést küldhet, ami egy specifikus backdoor-t hoz létre a globális modellben (pl. egy adott képen soha ne ismerjen fel tumort), miközben az általános teljesítmény látszólag nem romlik drasztikusan.

Védekezési stratégiák: A föderált rendszer megerősítése

A föderált tanulás biztonsága nem alapértelmezett, hanem egy tudatosan megtervezett, többrétegű védelmi architektúra eredménye. Szerencsére több technika is rendelkezésünkre áll, amelyek közül sok az előző fejezetekben tárgyalt koncepciókra épül.

1. Differenciális adatvédelem integrálása

A differenciális adatvédelem (DP) a föderált tanulás egyik legfontosabb védelmi bástyája az adatvédelmi támadásokkal szemben. 

Két fő helyen alkalmazhatjuk:

  • Lokális DP: A kliens zajt ad a modellfrissítéshez, mielőtt azt elküldené a szervernek. Ez a legerősebb adatvédelmi garanciát nyújtja, mivel még a központi szervert sem tekinti megbízhatónak. Az ára a pontosság csökkenése lehet a hozzáadott zaj miatt.
  • Központi DP: A szerver az aggregálás után ad zajt a frissített globális modellhez. Ez véd a külső támadók ellen, de feltételezi, hogy a szerver maga megbízható, hiszen látja a kliensek (zajmentes) frissítéseit.

2. Biztonságos aggregáció (Secure Aggregation)

Hogyan tudná a szerver összegezni a frissítéseket anélkül, hogy látná a kliensek egyedi hozzájárulásait? Erre szolgál a biztonságos aggregáció, amely jellemzően kriptográfiai primitívekre épül, mint a biztonságos többszereplős számítás (SMPC) vagy a homomorf titkosítás. A lényege, hogy a szerver csak a titkosított frissítések összegét tudja visszafejteni, az egyes komponenseket nem.

# Pszeudokód a biztonságos aggregáció koncepciójához

# Kliens oldalon (minden kliens ezt csinálja)
sajat_frissites = kiszamol_lokalis_frissitest(adatok)
titkositott_frissites = titkosit(sajat_frissites, kozos_kulcs)
kuld(szerver, titkositott_frissites)

# Szerver oldalon
osszes_titkositott_frissites = fogad_mindenkitol()
# A szerver összeadja a titkosított értékeket anélkül, hogy látná őket
aggregalt_titkositott = homomorf_osszeadas(osszes_titkositott_frissites)
# A végeredményt a kliensek közösen fejtik vissza, vagy egy megbízható harmadik fél
aggregalt_frissites = visszafejt(aggregalt_titkositott, kozos_kulcs)

globalis_modell.frissit(aggregalt_frissites)

3. Robusztus aggregációs algoritmusok

A modellmérgezési támadások kivédésére az egyszerű átlagolás (`FedAvg`) nem elegendő, mert egyetlen, extrém értékű frissítés is eltorzíthatja a végeredményt. A robusztus aggregátorok célja az ilyen kiugró (potenciálisan rosszindulatú) értékek hatásának csökkentése.

Módszer Működési elv Védelem mérgezés ellen
FedAvg (Federated Averaging) A kliensfrissítések súlyozott átlaga. Gyenge. Egyetlen rosszindulatú kliens is jelentősen eltorzíthatja az átlagot.
Trimmed Mean (Vágott átlag) A frissítések rendezése után a legkisebb és legnagyobb X%-ot eldobja, a maradékot átlagolja. Közepes. Hatékony a kiugró értékekkel szemben, ha a támadók aránya kisebb, mint a vágási küszöb.
Krum / Multi-Krum Minden frissítéshez kiszámítja, mennyire „hasonlít” a többihez. Azt a frissítést választja, amelyik a legközelebb van a szomszédaihoz. Jó. Kifejezetten a Byzantine-típusú (rosszindulatú, önkényes) kliensek kiszűrésére tervezték.

Nincs ezüstgolyó: A védekezés mindig kompromisszumokkal jár. A lokális differenciális adatvédelem rontja a modell pontosságát. A biztonságos aggregáció jelentős számítási és kommunikációs többletköltséggel jár. A robusztus aggregátorok pedig eldobhatnak olyan frissítéseket is, amelyek nem rosszindulatúak, csak egy ritka, de valós adatpopulációból származnak.

Gyakorlati teendők egy AI Red Team szimuláció során

Amikor egy egyesített tanulási rendszert tesztelsz, a következőkre koncentrálj:

  • Vizsgáld az aggregációs logikát: A rendszer egyszerű `FedAvg`-t használ, vagy valamilyen robusztusabb megoldást? Próbálj meg olyan modellfrissítéseket beküldeni, amelyek célzottan kihasználják az aggregátor gyengeségeit.
  • Teszteld az adatvédelmi garanciákat: Ha a rendszer differenciális adatvédelmet alkalmaz, próbálj meg tagsági következtetési támadásokat futtatni. A sikerességi arány megmutatja a védelem tényleges erősségét (vagy gyengeségét).
  • Keress oldalsó csatornákat: A modellfrissítéseken túl van más kommunikáció a kliens és a szerver között? Metaadatok, időzítések, a kliens kiválasztásának módja – ezek mind szivárogtathatnak információt.
  • Szimulálj kliens kompromittálódást: Mi történik, ha egy vagy több kliens felett teljes kontrollt szerzel? Képes vagy backdoor-t elhelyezni a globális modellben anélkül, hogy a szerver oldali anomáliadetekció észrevenné?

A föderált tanulás egy rendkívül ígéretes technológia az adatvédelem szempontjából, de a naiv implementációk komoly biztonsági kockázatokat rejtenek. AI Red Teamerként a feladatunk, hogy feltárjuk ezeket a rejtett sebezhetőségeket, mielőtt egy valós támadó tenné meg!