Zugangskontrolle, Identitäts- und Geheimverwaltung

Gewinne:

• Möglichkeit, Authentifizierung und Autorisierung zu trennen und eine Mindestautorisierung mit RBAC/ABAC anzuwenden
• Möglichkeit, das Risiko gemischter Proxys zu vermeiden, indem das Modell im Benutzerkontext ausgeführt wird
• Möglichkeit, API-Schlüssel mit dem Secret-Management-System zu speichern und zu rotieren

Ein erheblicher Teil der Angriffe auf ein KI-System beginnt nicht mit der „Täuschung“ des Modells, sondern mit einem gestohlenen API-Schlüssel oder einem überautorisierten Konto. Diese Sicherheitsebene stammt aus der klassischen Informationssicherheit, bringt aber im Kontext der KI neue Risiken mit sich: Ein Modell ruft eine Fahrt im Namen einer anderen Person auf, ein Dienstkonto greift auf alle Daten zu, ein Schlüssel gelangt an GitHub. In dieser Einheit erfahren wir, wie wir den Zugriff auf das KI-System durch Authentifizierung, Autorisierung (RBAC/ABAC), Mindestautorisierung und Geheimverwaltung eingrenzen.

Unterschied zwischen Authentifizierung und Autorisierung

Die beiden Begriffe werden oft verwechselt:

• Authentifizierung: „Wer sind Sie?“ – Nachweis, dass der Benutzer/Dienst wirklich der ist, für den er sich ausgibt (Passwort, Token, Zertifikat, MFA).
• Autorisierung: „Was können Sie tun?“ – Bestimmen Sie, auf welche Ressource/Aktion die authentifizierte Partei zugreifen kann.

Die entscheidende Feinheit bei KI-Systemen ist folgende: Wenn das Modell im Namen eines Benutzers arbeitet, arbeitet es dann mit der Autorität dieses Benutzers oder mit einem umfassenden Dienstkonto? Letzteres ist gefährlich, da das durch die Injektion ausgetrickste Modell vollen Zugriff auf das Dienstkonto erhält.

Achtung: „Verwirrter Stellvertreter“-Problem: Ein Benutzer mit niedriger Autorität greift indirekt auf Daten zu, auf die er nicht zugreifen kann, indem er ein Modell mit hoher Autorität auslagert. Das Modell sollte immer im Kontext der Autorität des Benutzers funktionieren, nicht seiner eigenen weitreichenden Autorität.

RBAC und ABAC

• RBAC (Role-Based Access Control): Der Zugriff hängt von der Rolle des Benutzers ab. Die Rolle „Supportspezialist“ kann Kundennotizen lesen, aber nicht löschen. Einfach und alltäglich.
• ABAC (Attribute-Based Access Control): Der Zugriff hängt von Attributen ab: der Abteilung des Benutzers, der Datenschutzkennzeichnung der Daten, der Tageszeit, dem Netzwerk, von dem die Anfrage kommt. Feiner abgestimmt, aber komplexer.

Die meisten Unternehmen beginnen mit RBAC und vertiefen sich bei sensiblen Daten zu ABAC. Faustregel für KI: Das Modell sollte jeden Agenten, den es anruft, und alle Daten, auf die es zugreift, basierend auf der Rolle/den Attributen des Benutzers filtern, der die Anfrage stellt.

Schritt für Schritt: Minimale Autorität ausüben

1. Machen Sie eine Bestandsaufnahme. Welche Werkzeuge ruft das Modell auf, auf welche Daten greift es zu? Listen Sie sie alle auf.
2. Begründen Sie jeden Zugriff. „Benötigt dieser Assistent wirklich Löschberechtigung?“ Andernfalls entfernen Sie es.
3. Standardmäßig schreibgeschützt. Das Modell sollte standardmäßig lesen können; Erfordert ein separates Schreib-/Löschtoken mit begrenztem Gültigkeitsbereich.
4. Benutzerkontext verschieben. Rufen Sie das Fahrzeug mit der Berechtigung des Benutzers an, nicht mit dem Dienstkonto.
5. Kurzlebiger Ausweis. Verwenden Sie kurzlebige, sich automatisch erneuernde Token anstelle langlebiger Schlüssel.

Geheimes Management

Ein Geheimnis sind Anmeldeinformationen, die geheim bleiben müssen, beispielsweise ein API-Schlüssel, ein Passwort, ein Token oder ein Zertifikat. Der häufigste Unfall in KI-Projekten ist, dass der API-Schlüssel des Modellanbieters in den Code eingebettet wird und in die Versionskontrolle (Git) gelangt.

Richtige Anwendung:

• Betten Sie niemals Schlüssel in den Code ein. Verwenden Sie eine Umgebungsvariable oder ein Geheimnisverwaltungssystem (ein Dienst, der Schlüssel verschlüsselt speichert und den Zugriff kontrolliert).
• Rotation: Schlüssel in regelmäßigen Abständen erneuern (z. B. alle 90 Tage); Bei Verdacht auf ein Leck sofort abbrechen.
• Umfangsreduzierung: Jeder Switch verfügt nur über den erforderlichen Dienst und die erforderliche Autorisierung.
• Audit: Protokollieren Sie, wer den Schlüssel wann und wo verwendet hat.

Vier kopierbare Vorlagen

Eingabeaufforderung zur Zugriffsüberprüfungskontrolle:

Bewerten Sie für jedes Werkzeug in der Werkzeugliste unten: Ist dieses Werkzeug ERFORDERLICH, um die Arbeit dieses Assistenten auszuführen? (ja/nein) – Ist es schreibgeschützt oder schreib-/löschbar? - Wird dieses Tool mit der Berechtigung oder dem Dienstkonto des Benutzers aufgerufen? Markieren Sie unnötige oder übermäßig autorisierte als „REMOVE/REDACT“.<tools>{{ tool_list }}</tools>

Geheime Aufforderung zum Scannen von Lecks:

Finden Sie im folgenden Codeausschnitt alles, was ein hartcodiertes Geheimnis sein könnte: API-Schlüssel, Passwort, Token, Verbindungszeichenfolge, privater Schlüssel. Geben Sie jeweils eine Zeile und einen Typ ein. KOPIEREN Sie den Wert in die Antwortmaske (erste 4 Zeichen + ***).<code>{{ source }}</code>

Entscheidungsregel der geringsten Autorität:

Wenn eine neue Werkzeug-/Zugriffsanfrage eintrifft, fragen Sie: 1. Kann die Aufgabe ohne diesen Zugriff ausgeführt werden? -> Wenn ja: ABLEHNEN2. Ist schreibgeschützt ausreichend? -> Wenn ja: Schreiberlaubnis erteilen3. Kann der Umfang auf eine einzige Quelle eingegrenzt werden? -> Wenn ja: daratDie Standardantwort ist „Nein“; Der Zugang wird durch Vernunft erlangt.

Erinnerung an den Rotationskalender:

Notieren Sie für jedes Geheimnis: Eigentümer, Erstellungsdatum, Ablauf, Geltungsbereich. Melden Sie jeden Schlüssel, der länger als 90 Tage alt ist oder der 30 Tage lang nicht verwendet wurde, als „ROTATIONS-/STORNIERUNGSKANDIDAT“.

Schwache Eingabeaufforderung / Starke Eingabeaufforderung

schlechter Ansatz

Starker Ansatz

Das Modell greift mit einem einzigen Dienstkonto auf alle Daten zu

Das Modell greift mit der Berechtigung des Benutzers zu, der die Anfrage stellt

Der API-Schlüssel ist in den Code eingebettet und ändert sich nie

Rotation im Key Secret Manager, 90 Tage

Umfangreiche Befugnisse des Assistenten, alles zu tun

Standardmäßig schreibgeschützt, schmal schreiben

Zugriffe werden nie überprüft

Regelmäßige Zugriffskontrolle und Sperrung

Drei Mini-Hüllen

Fall 1 – Durchgesickerte gemischte Proxy-Daten. Ein interner Assistent arbeitete mit einem Dienstkonto, das Zugriff auf alle Mitarbeiterdaten hatte. Ein Praktikant greift auf Daten zu, die er normalerweise nicht sehen würde, indem er sagt: „Zusammenfassung der Gehaltstabelle für Führungskräfte“; weil das Modell es im Kontext seiner eigenen weitreichenden Autorität in Frage stellte, nicht der des Benutzers. Nachdem der Benutzerkontext so angepasst wurde, dass er verschoben werden konnte, konnte der Praktikant Aufzeichnungen abrufen, die nur er oder sie sehen konnte.

Fall 2 – Durchgesickerter Schlüssel, 190.000-TL-Rechnung in 2 Wochen. Ein Entwickler hat den Modell-API-Schlüssel in ein Hilfsskript eingebettet und ihn in ein öffentliches Repository verschoben. Ein Bot fand den Schlüssel innerhalb von 40 Minuten und nutzte ihn zwei Wochen lang; Die Rechnung erreichte 190.000 TL. Als der Schlüssel zum Secret Manager verschoben, mit der Rotation verbunden und das Repository-Scannen hinzugefügt wurde, trat der Vorfall nicht erneut auf.

Fall 3 – Schreibgeschützter, standardmäßig verhinderter Interrupt. Ein DevOps-Assistent erhielt per Prompt-Injection den Befehl „Produktionsdatenbank zurücksetzen“. Der Assistent erhielt jedoch nur ein schreibgeschütztes Token; Das Schreiben/Löschen erfolgte in einem separaten genehmigten Ablauf. Der Befehl wurde mit einem Autorisierungsfehler abgelehnt und das Ereignis wurde als Alarm protokolliert; Es gab keinen Datenverlust.

Tipp: Machen Sie „Nein“ zu Ihrer Standardantwort auf eine neue Zugriffsanfrage. Zugang wird durch Rechtfertigung erlangt; Es wird fast nie praktiziert, allen das Weite zu geben und dann zu kürzen, und das Risiko häuft sich.

Häufige Fehler

• Führen Sie das Modell mit einem großen Dienstkonto aus und verlieren Sie den Benutzerkontext (gemischter Proxy).
• Einbetten des API-Schlüssels in den Code und Weitergabe an die Versionskontrolle.
• Die Tasten werden überhaupt nicht gedreht („Arbeiten, nicht berühren“).
• Dem Assistenten standardmäßig Schreib-/Löschberechtigungen erteilen.
• Einmal Zugriff gewähren und nie wieder darüber nachdenken.
• Authentifizierung mit Autorisierung verwechseln und davon ausgehen, dass er angemeldet ist und auf alles zugreifen kann.

Zusammenfassend

• Bei der Authentifizierung geht es um „Wer sind Sie“, bei der Autorisierung um „Was können Sie tun“; In der KI müssen beide im Kontext des Benutzers agieren.
• Das Modell sollte mit der Autorität des Benutzers arbeiten, der die Anfrage stellt, und nicht mit seiner eigenen weitreichenden Autorität (um das Risiko einer gemischten Vertretung zu vermeiden).
• Beginnen Sie mit RBAC und vertiefen Sie sich mit ABAC zu sensiblen Daten. Legen Sie die minimale Berechtigung als Standard fest.
• Vergraben Sie keine Geheimnisse im Code. Speichern Sie es im Secret Manager, grenzen Sie es ein und versetzen Sie es in eine regelmäßige Rotation.
• Die schreibgeschützte Standardeinstellung und das eingeschränkte Schreiben schränken die Auswirkungen der Injektion erheblich ein.

Anwendungsaufgabe

Listen Sie alle Tools und Daten auf, auf die Ihr KI-Assistent zugreift. Beantworten Sie jeweils drei Fragen: (1) Ist es wirklich notwendig? (2) Ist schreibgeschützt ausreichend? (3) Läuft es im Benutzerkontext? Suchen Sie dann nach allen fest codierten Geheimnissen (über die Scan-Eingabeaufforderung oben) und schreiben Sie einen Rotationsplan für jeden Schlüssel, den Sie finden. Entfernen Sie mindestens eine unnötige Autorisierung.

Checkliste

• [ ] Das Modell wird im Autoritätskontext des Benutzers ausgeführt, der die Anfrage stellt.
• [ ] Der Werkzeug- und Datenzugriff wurde auf das Prinzip der geringsten Rechte eingegrenzt.
• [ ] Schreiben/Löschen ist getrennt von schreibgeschützt, authentifiziert und eingeschränkt.
• [ ] Im Code sind keine Geheimnisse verborgen; Es wird im Secret Manager aufbewahrt.
• [ ] Es gibt einen Rotationsplan und ein Stornierungsverfahren für Schlüssel.
• [ ] Die Zugriffe werden regelmäßig überprüft.