Wie verändert gegenseitiges TLS das Vertrauen zwischen lokalen KI-Diensten?
Mutual TLS verändert das Vertrauen in lokale Dienste, indem beide Endpunkte ihre Zertifikatsidentitäten nachweisen müssen, bevor Anwendungsdaten die Verbindung passieren.
Gewöhnliches TLS ermöglicht es einem RAG-Client zu überprüfen, ob er den vorgesehenen Modellserver erreicht hat. Der Server kann jedoch weiterhin jeden Client im LAN akzeptieren. Bei mTLS legt der Client zusätzlich ein Zertifikat vor und weist den Besitz seines privaten Schlüssels nach. Beide Seiten validieren eine Vertrauenskette und erzeugen einen authentifizierten, verschlüsselten Kanal, bevor die Autorisierung auf höherer Ebene entscheidet, welche API-Operationen zulässig sind.
Beide Kommunikationspartner authentifizieren sich während des TLS-Handshakes
Der Server legt wie bei gewöhnlichem TLS sein Zertifikat vor und fordert anschließend ein Clientzertifikat an. Jeder Kommunikationspartner validiert Aussteller, Gültigkeitszeitraum, Namen oder Dienstidentität, Schlüsselverwendung und den Nachweis, dass der andere Endpunkt den zugehörigen privaten Schlüssel besitzt.
Eine Erklärung zur zweiseitigen Dienstauthentifizierung beschreibt, wie gegenseitige Authentifizierung nicht vertrauenswürdige Microservices blockiert und den Datenverkehr zugleich vor Abfangen und Manipulation schützt. Der Handshake verlagert die Identitätsprüfung unterhalb von Anwendungsaufforderungen und API-Nutzdaten. Dieser Unterschied bleibt bei späteren Tests im Heimnetz sichtbar.
Ein erfolgreicher Kanal bestätigt die Identitäten der Kommunikationspartner, die von den Vertrauensankern anerkannt werden. Er zeigt jedoch nicht, dass der aufrufende Dienst zur Nutzung eines bestimmten Modells, Dokumentensatzes oder Tools berechtigt ist. Das Zwischenergebnis muss weiterhin überprüfbar bleiben, bevor die Automatisierung fortgesetzt wird.
Vertrauensanker ersetzen den Netzwerkstandort als Zulassungstest
Dienste verlassen sich nicht mehr hauptsächlich auf Quell-IP, Hostnamen oder die Mitgliedschaft in einem privaten Subnetz als Identitätsnachweis. Sie akzeptieren Zertifikate, die auf konfigurierte Zertifizierungsstellen zurückgeführt werden können, und ordnen das authentifizierte Subjekt einem Dienstprinzipal zu.
Ein ausführlicher Leitfaden zu Zertifikatsvertrauensketten erklärt, dass das Vertrauen in eine Zertifizierungsstelle dem Vertrauen in die von ihr signierten Identitäten entspricht. Die Verteilung von Stammzertifikaten, Namensbeschränkungen, Ausstellungsrichtlinien und Erneuerung werden dadurch Teil der Vertrauensgrenze der heimischen KI. Diese Grenze sollte unter realistischen Betriebsbedingungen separat gemessen werden.
Dieses Modell bleibt bei wechselnden Containeradressen und segmentierten Netzwerken bestehen, jedoch nur, wenn Identitätsnamen stabil sind und die Zertifikatsprüfung während der Fehlersuche nicht deaktiviert wird. Die praktische Konsequenz zeigt sich, wenn mehrere Quellen um einen begrenzten Kontext konkurrieren.
Autorisierungs- und Lebenszykluskontrollen vervollständigen die Vertrauensentscheidung
Nach dem Handshake ordnet der Server die Zertifikatsidentität den zulässigen Methoden, Ressourcen, Raten und Benutzerdelegierungen zu. Automatisierte Ausstellung und Rotation halten die Gültigkeitszeiträume kurz, während ein Widerruf oder die Entfernung einer Richtlinie zukünftige Sitzungen eines ausgemusterten Dienstes verhindert.
Eine aktuelle Übersicht zum mTLS-Identitätsnachweis unterscheidet den zweiseitigen Identitätsnachweis von der anschließenden Anwendungsautorisierung. Dadurch wird verhindert, dass Verschlüsselung und Authentifizierung mit einer vollständigen Berechtigungsverwaltung verwechselt werden. Diese Abhängigkeit sollte in der endgültigen Schnittstelle ausdrücklich erhalten bleiben.
Die Fehlergrenze liegt bei einem gemeinsam genutzten Clientzertifikat oder einer zu weitreichenden ausstellenden Zertifizierungsstelle. Wenn mehrere Dienste denselben privaten Schlüssel besitzen, kann mTLS zwar die Anmeldedaten authentifizieren, aber nicht unterscheiden, welcher Prozess die Anfrage tatsächlich initiiert hat. Das Ergebnis muss daher anhand der ursprünglichen Belege geprüft werden.
Validieren Sie den Kanal und die darüberliegende Autorisierung
Dokumentieren Sie für jedes Dienstpaar die Clientidentität, Serveridentität, Vertrauensanker, Zertifikatslaufzeit, Hostnamen- oder SPIFFE-Prüfung, den Schlüsselschutz, zulässige APIs, den Ressourcenbereich, den Rotationsweg und die Protokollierung von Fehlern. Dieser Unterschied bleibt bei späteren Tests im Heimnetz sichtbar.
Setzen Sie das Ergebnis in Beziehung zur Autorisierungsrichtlinie des Dienstes. Testen Sie einen unbekannten Aussteller, einen falschen Dienstnamen, ein abgelaufenes Zertifikat, einen kopierten Clientschlüssel, ein fehlendes Zertifikat, ein gültiges Zertifikat mit unzulässiger Methode und eine Rotation während aktiver Verbindungen. Das Zwischenergebnis muss weiterhin überprüfbar bleiben, bevor die Automatisierung fortgesetzt wird.
Führen Sie mTLS nur mit automatisiertem Lebenszyklusmanagement und einer ausdrücklichen Autorisierung nach dem Handshake ein. Der Test ist bestanden, wenn Identitätsfehler die Verbindung stoppen und gültige, aber nicht autorisierte Kommunikationspartner weiterhin eine deterministische Ablehnung auf Anwendungsebene erhalten. Diese Grenze sollte unter realistischen Betriebsbedingungen separat gemessen werden.
Empfohlene Produkte
Tech- & KI-Zentrum
Mehr zum Lesen
Wie beeinflusst das Downsampling von Zeitreihen die Anomalieerkennung im Smart Home?
Sehen Sie, wie Bucket-Breite, Aggregation, Anti-Aliasing, fehlende Daten, Ereignisdauer und Aufbewahrung über mehrere Skalen die Erkennungsrate von Anomalien im Smart Home verändern.
Wie kombiniert ein Belegungsraster schwache Smart-Home-Signale?
Erfahren Sie, wie räumliche Zellen, Sensormodelle, Log-Odds-Aktualisierungen, Zerfall, korrelierte Evidenz und Schwellenwerte schwache Signale aus dem Zuhause in Belegungsschätzungen umwandeln.
Wie beeinflusst die photometrische Normalisierung das private Clustering von Gesichtern?
Sehen Sie, wie die Beleuchtungskorrektur Gesichtsausschnitte, Einbettungen, Clusterabstände, Schwellenwerte, Übernormalisierung und die Bewertung der privaten Fotosuche verändert.
