Kapitel 12 — Zugriffssteuerung und Identität

Zwölfter Beitrag im Kapitel-für-Kapitel-Walkthrough zu LLM Primer VII: KI-Sicherheit. Das Kapitel beantwortet die kompositorische Frage — wer darf welche Fähigkeit einer LLM-integrierten Anwendung aufrufen, und wie ist die Durchsetzung über die Komponenten des Systems strukturiert.

Warum es dieses Kapitel gibt

Die klassischen Zugriffssteuerungs-Disziplinen gelten alle für LLM-Systeme: den Principal authentifizieren, seine Anfragen gegen Policy autorisieren, Mandanten isolieren, Verbrauch pro Principal begrenzen, Enterprise-Governance-Overlays offenlegen. Die Mechanismen sind die, die das Feld seit Jahrzehnten nutzt — OAuth 2.0, mTLS, RBAC, ABAC, Token Buckets, SAML, SCIM. Neu ist, dass der Modellaufruf selbst zum Principal werden kann — ein Agent, der im Namen eines Nutzers handelt, trägt eine eigene Identität und eigene Berechtigungen — und dass mandantenspezifische Konfiguration des Modellverhaltens ein erstklassiges Produktfeature multi-mandantenfähiger LLM-Plattformen ist.

In einem Satz: Zugriffssteuerung in LLM-Systemen ist die klassische Disziplin plus eine Ergänzung — das Modell ist, wenn es über Werkzeuge handelt, selbst ein Principal, dessen Berechtigungen so eng geschnitten sein müssen, dass ein kompromittierter Prompt sie nicht einlösen kann.

12.1 Authentifizierung und Autorisierung übertragen sich, mit Ergänzungen

Authentifizierung prüft das Credential. API-Schlüssel sind der einfachste Mechanismus — ein hochentropischer String, der dem Principal bei der Provisionierung übergeben wird, in der Credential-Datenbank gehasht, in jedem Request in einem Header präsentiert. Sie sind leicht zu implementieren und zu nutzen und leicht durch Logs, CI-Ausgaben und commitete Repositories zu lecken. OAuth-2.0-Bearer-Tokens verbessern die Lage mit kurzlebigen Tokens und Scope-Beschränkung; der OAuth-2.1-Draft konsolidiert die Sicherheits-Best-Practices des letzten Jahrzehnts. mTLS ergänzt gegenseitige Authentifizierung für Maschine-zu-Maschine-Aufrufe, besonders nützlich für interne LLM-Dienste. Autorisierung fragt, was der authentifizierte Principal tun darf. RBAC — Rollen, Berechtigungen, Zuweisungen — funktioniert, wenn sich die Population in stabile Gruppen teilt. ABAC — attributbasierte Zugriffssteuerung — bewertet Prädikate über Principal-, Ressourcen- und Kontextattribute und deckt die Fälle ab, die RBAC nicht deckt: Berechtigungen, die vom Eigentümer der Ressource, von Zeit oder Ort der Anfrage oder von Beziehungen im System abhängen. Die beiden schließen einander nicht aus; produktive Systeme schichten sie oft, mit RBAC für grobkörnigen Zugriff und ABAC für die spezifischen Bedingungen. Policy-Engines aus Kapitel 10 — OPA, Cedar — sind, wie ABAC im großen Maßstab wartbar wird.

12.2 Mandantenisolation ist eine Defense-in-Depth-Frage

Ein multi-mandantenfähiges System bedient mehrere Kunden aus einer einzigen Deployment-Instanz. Die Isolationsanforderung ist, dass kein Mandant unter irgendeinem Fehlermodus die Daten, Anfragen oder Modellinteraktionen eines anderen sehen kann. Drei architektonische Ansätze sitzen auf einem Spektrum. Datenbank-Isolation — eigene Datenbank pro Mandant — ist die stärkste, aber am teuersten zu betreiben. Schema-Isolation — eigenes PostgreSQL-Schema oder eigene MySQL-Datenbank pro Mandant auf geteilter Infrastruktur — ist ein Mittelweg. Row-Level-Isolation — geteiltes Schema, Tenant-ID auf jeder Zeile, datenbank-erzwungene Row-Level Security — ist die billigste, verlangt aber disziplinierten Anwendungscode. Für LLM-Systeme erstreckt sich die Isolation auf den Retrieval-Korpus (Vektor-Datenbank-Namespaces pro Mandant), die Prompt-Konstruktionslogik (keine mandantenübergreifende Verkettung), den Log-Store (keine mandantenübergreifenden Lesevorgänge) und das Modell selbst, wenn es auf mandantenspezifischen Daten feingetunt ist. Rate Limits und Kontingente fügen die Ressourcenverbrauchs-Achse hinzu. Token Bucket erlaubt kurze Bursts bis zu einer definierten Kapazität; Sliding Window erzwingt eine gleichmäßigere Rate zu höheren Rechenkosten; Leaky Bucket glättet die nachgelagerte Rate. Für LLM-Systeme dehnt sich die Rate-Limit-Dimension aus: Anfragen pro Sekunde, Tokens pro Minute, Kosten pro Tag, Werkzeugaufrufe pro Stunde, Embeddings pro Sekunde. Jede Dimension hat eigene wirtschaftliche und sicherheitsbezogene Rechtfertigung, und Enterprise-Stufen differenzieren typischerweise entlang mehrerer.

12.3 Enterprise-Governance ist das Overlay, das das System nutzbar macht

Enterprise-Kunden haben Governance-Anforderungen jenseits von Authentifizierung und Rate Limiting. Sie müssen wissen, welche Mitarbeitenden das System nutzen, auf welchen Daten, zu welchen Zwecken. Sie brauchen Audit-Logs, die für interne Compliance und externe Prüfungen ausreichen. Sie brauchen Kontrollen darüber, welche Modelle erlaubt sind, welche Werkzeuge verfügbar sind, welche Inhaltskategorien zulässig sind. Sie brauchen Datenhandhabungs-Zusagen — Trainingsnutzung, Verschlüsselung, Datenresidenz, Aufbewahrung, Löschung. Die Features, die zum Standard geworden sind, spiegeln diese Anforderungen. Single Sign-On über SAML oder OpenID Connect macht den Enterprise-Identitätsprovider zur Quelle der Wahrheit darüber, wer das System nutzen kann. SCIM-Provisioning propagiert Benutzeränderungen automatisch. Audit-Log-Export schickt die Telemetrie des LLM-Systems in das Enterprise-SIEM. Datenresidenz-Zusagen garantieren, dass die Daten eines Mandanten eine bestimmte Jurisdiktion nicht verlassen. Kundenverwaltete Verschlüsselungsschlüssel erlauben es dem Unternehmen, unabhängig vom Anbieter zu rotieren oder zu widerrufen. Private-Deployment-Optionen bewegen den LLM-Dienst in das eigene Cloud-Konto des Unternehmens. Jedes dieser Features ist eine Governance-Oberfläche, die betrieben werden muss, nicht nur implementiert; das Enterprise-Governance-Overlay ist, was eine multi-mandantenfähige LLM-Plattform in etwas verwandelt, das eine regulierte Branche adoptieren kann.

Wert, das festzuhalten: Jedes Werkzeug, das das Modell aufrufen kann, sollte autorisiert werden, als hätte der Nutzer es direkt aufgerufen — mit der Identität des Aufrufers, in dessen Mandanten, unterworfen den Rate Limits des Aufrufers. Alles andere gewährt dem Modell Autorität jenseits des Principals, für den es handelt, und das ist der Fehlermodus, den die meisten Agent-Architekturen versehentlich einbauen.

Was Kapitel 12 vorbereitet

Teil IV hat die systemseitigen Dimensionen der LLM-Sicherheit entwickelt: architektonische Grenzen (Kapitel 10), Observability und Incident Response (Kapitel 11) sowie Identitäts- und Zugriffskontrollen (Kapitel 12). Die Behandlung war mechanismusorientiert und gibt eine vertretbare technische Position. Kapitel 13 eröffnet Teil V, indem es vom technischen Kern nach außen zur regulatorischen Peripherie geht. Der EU AI Act, ab August 2026 für die meisten Hochrisiko-Kategorien in voller Wirkung, ist das folgenreichste einzelne Instrument, aber die US-Bundesposition (in Entwicklung nach dem Übergang von EO 14110 zu EO 14179), die Gesetze der Bundesstaaten (Colorado, Kalifornien, New York City u. a.), die DSGVO in Anwendung auf KI und die entstehenden Frameworks in Singapur, Japan, Korea, Indien und anderswo machen die Compliance-Oberfläche gemeinsam plural statt einheitlich. Das Kapitel untersucht, was diese Regelungen praktisch verlangen, und wie die Kontrollen aus den Kapiteln 3, 10, 11 und 12 auf diese Anforderungen abbilden.

Als Nächstes — Kapitel 13: Regulatorische Landschaft. Der gestufte Anwendungspfad des EU AI Act, die DSGVO gegen KI-Systeme, Auditierbarkeit, Model Cards und die Risikoklassifizierungs-Frameworks, die die regulatorische Architektur strukturieren.

Möchtest du das ganze Bild? Das Buchkapitel enthält durchgearbeitete OAuth- und mTLS-Setups, die vollständige RBAC-gegen-ABAC-Entscheidungsmatrix mit produktiven Beispielen, Mandantenisolationsmuster über Speicherschichten hinweg und die „In Plain English"-Sidebars, die dieser Artikel nur zusammenfasst. LLM Primer VII auf Amazon →