Federated Learning: Sicherheit dezentraler KI

Wie funktioniert Federated Learning?

Ein Trainingsdurchlauf besteht aus wiederkehrenden Runden: Der Server verteilt das aktuelle globale Modell an die Teilnehmer (Clients). Jeder Client trainiert lokal mit seinen eigenen Daten und sendet nur die Änderung am Modell zurück. Der Server aggregiert diese Aktualisierungen – klassisch per gewichteter Mittelwertbildung (Federated Averaging) – und startet die nächste Runde.

Man unterscheidet zwei Einsatzformen:

• Cross-Device: Tausende bis Millionen Endgeräte wie Smartphones trainieren mit, etwa für Tastaturvorschläge. Die Clients sind unzuverlässig, anonym und kaum kontrollierbar.
• Cross-Silo: Wenige Organisationen – zum Beispiel Kliniken, Banken oder Produktionsstandorte eines Konzerns – trainieren gemeinsam. Die Teilnehmer sind bekannt und vertraglich gebunden. Für den Mittelstand ist das die relevantere Variante, etwa bei Kooperationen zur Qualitätsprüfung oder Predictive Maintenance über mehrere Werke hinweg.

Verbreitete Frameworks sind unter anderem Flower, TensorFlow Federated, NVIDIA FLARE und PySyft.

Angriffsflächen im föderierten Training

Die dezentrale Architektur verschiebt die Risiken, statt sie zu beseitigen. Jeder Teilnehmer beeinflusst das gemeinsame Modell direkt – und der Server sieht nicht, mit welchen Daten trainiert wurde.

Rückschlüsse auf Trainingsdaten

Gradienten enthalten Informationen über die Daten, aus denen sie berechnet wurden. Bei Gradient-Inversion-Angriffen rekonstruiert ein neugieriger Server oder ein Mithörer aus einzelnen Aktualisierungen Teile der Trainingsdaten, in Forschungsarbeiten etwa Bilder oder Textfragmente. Membership-Inference-Angriffe prüfen, ob ein bestimmter Datensatz im Training verwendet wurde. Das fertige globale Modell kann ebenfalls Informationen preisgeben.

Manipulation durch Teilnehmer

Ein kompromittierter oder böswilliger Client kann gezielt vergiftete Aktualisierungen einspielen (Model Poisoning). Besonders heikel sind Backdoor-Angriffe: Das Modell verhält sich im Normalfall unauffällig, reagiert aber auf ein bestimmtes Auslösemuster falsch – etwa indem ein Bauteil mit einer bestimmten Markierung immer als fehlerfrei gilt. Bei Cross-Device-Szenarien kommen Sybil-Angriffe hinzu, bei denen ein Angreifer viele gefälschte Clients betreibt.

Infrastruktur und Lieferkette

Der Koordinationsserver ist ein zentrales Angriffsziel: Wer ihn kontrolliert, kann das globale Modell austauschen oder gezielt Aktualisierungen einzelner Teilnehmer auswerten. Hinzu kommen klassische Risiken wie ungesicherte Kommunikationskanäle, veraltete Framework-Versionen und unsichere Modellformate beim Austausch.

Schutzmaßnahmen in der Praxis

1. Bedrohungsmodell festlegen: Klären Sie, wem Sie vertrauen – dem Server, allen Teilnehmern, keinem? Daraus ergibt sich, welche der folgenden Maßnahmen nötig sind.
2. Secure Aggregation einsetzen: Kryptografische Protokolle sorgen dafür, dass der Server nur die Summe aller Aktualisierungen sieht, nicht die Beiträge einzelner Clients.
3. Differential Privacy ergänzen: Das Begrenzen (Clipping) und Verrauschen von Aktualisierungen erschwert Rückschlüsse auf einzelne Datensätze. Der Preis ist meist eine geringere Modellgenauigkeit; das Datenschutzbudget muss bewusst gewählt werden.
4. Robuste Aggregation verwenden: Verfahren wie Median, Trimmed Mean oder Krum dämpfen den Einfluss einzelner Ausreißer. Sie schützen jedoch nicht vollständig vor koordinierten oder subtilen Angriffen.
5. Teilnehmer authentisieren: Nutzen Sie mTLS mit Client-Zertifikaten, vertragliche Vereinbarungen und – wo möglich – Trusted Execution Environments, um die Integrität der Clients zu stärken.
6. Modell validieren: Prüfen Sie jedes neue globale Modell vor der Freigabe gegen einen vertrauenswürdigen Testdatensatz und auf auffällige Verhaltensänderungen. Versionieren Sie Modelle, damit Sie bei Manipulation zurückrollen können.
7. Protokollieren und überwachen: Erfassen Sie, welcher Teilnehmer wann welche Aktualisierung geliefert hat, um Anomalien nachvollziehen zu können.

Datenschutz und Regulierung

Föderiertes Lernen wird häufig als „DSGVO-Lösung“ beworben. Das greift zu kurz: Modellaktualisierungen können personenbezogene Rückschlüsse erlauben und sind dann selbst als personenbezogene Daten zu behandeln. Rechtsgrundlage (Art. 6 DSGVO), Rollenverteilung zwischen den Partnern (gemeinsame Verantwortlichkeit oder Auftragsverarbeitung) und gegebenenfalls eine Datenschutz-Folgenabschätzung nach Art. 35 DSGVO bleiben erforderlich. Positiv wirkt Federated Learning vor allem als Maßnahme der Datenminimierung und des Datenschutzes durch Technikgestaltung (Art. 25 DSGVO).

Fällt das trainierte System unter den EU AI Act (Verordnung (EU) 2024/1689) in die Hochrisiko-Kategorie, gelten die Anforderungen an Daten-Governance, Robustheit und Cybersicherheit unabhängig davon, ob zentral oder föderiert trainiert wird.

Fazit

Federated Learning ist ein wirksamer Baustein, um Daten dort zu lassen, wo sie entstehen – ersetzt aber weder Kryptografie noch Zugriffskontrolle noch Modellprüfung. SecTepe unterstützt Sie dabei, das Bedrohungsmodell für föderierte Projekte zu definieren und die Absicherung in Ihr ISMS einzubinden.

Häufige Fragen

Ist Federated Learning automatisch DSGVO-konform?

Nein. Es verringert den Rohdatentransfer, doch Modellaktualisierungen und das fertige Modell können personenbezogene Informationen preisgeben. Die üblichen datenschutzrechtlichen Pflichten bleiben bestehen.

Wie erkenne ich einen manipulierten Teilnehmer?

Auffällige Aktualisierungen lassen sich über Abstandsmaße zu anderen Clients, Leistungsprüfungen auf Validierungsdaten und Verlaufsanalysen erkennen. Eine sichere Erkennung subtiler Backdoors ist jedoch schwierig; deshalb gehören Freigabeprozesse und Rollback-Fähigkeit dazu.