KI-Sicherheit mit Monofor: Gateways, Schutzmechanismen und Maschinen-Anmeldedaten

Was hat sich geändert

Jede Inhaltsänderung wird versioniert. Wählen Sie eine Version, um sie mit der vorherigen zu vergleichen.

Version 8 → 9

Aktualisierung

Vier neue Lektionen schließen die Lücke zur MCASP-Prüfung: Genehmigende und verlorene Anmeldedaten in der Praxis, die Gateways betreiben (Zeitlimits, Streaming, Token-Audience), AI Flows im Betrieb sowie eine Maschinenidentität wählen und eingrenzen. Jedes Modulquiz hat zwei neue Fragen. Die neuen Lektionen erhielten Diagramme.

4 Lektionen aktualisiertDauer

Inhaltliche Aktualisierung. Eingeschriebene Lernende wurden benachrichtigt.

Dauer von 66 auf 67 Minuten geändert.

Genehmigende, Wartezeit und verlorene Anmeldedaten in der Praxis

Eine Genehmigungsrichtlinie sieht auf dem Papier einfach aus. Im Alltag entscheiden drei Fragen, ob sie trägt: Wer wird wirklich gefragt, wie erfahren diese Personen davon, und was tun Sie, wenn das Secret einer Anmeldeinformation weg ist. Diese Lektion geht jede Frage an einem Beispielagenten durch. ### Beispiel: ein Agent, der Erstattungen auslöst Der Agent `refund-bot` kann Erstattungen auslösen. Die Sicherheitsleitung will, dass zwei namentlich benannte Finanzverantwortliche gemeinsam zustimmen und jede Entscheidung begründen. Öffnen Sie den Agenten und seine Registerkarte `Approvers`: | Einstellung | Wert | Warum | | --- | --- | --- | | Modus | `Choose for this agent` statt `Use the default` | Der Mandantenstandard fragt die Manager, dann die Governance-Verantwortlichen. Das ist hier zu breit | | Feld im Schritt | `These people`, mit beiden Verantwortlichen | Benannte Personen, nicht wer den Agenten gerade verwaltet | | `How many must approve` | `Everybody asked` | Mit `Any one` könnte eine Person allein entscheiden | | `Approvers must write why` | Ein | Eine Entscheidung ohne Begründung wird nicht angenommen | | `Also tell them by` | `Push to the authenticator app` | Das ist der Standard. `E-mail with approve and deny links` lässt sich zusätzlich ankreuzen | Die Konsolenglocke in Management wird immer genutzt, egal was Sie unter `Also tell them by` ankreuzen. Ein Schritt mit Standardwerten erreicht Genehmigende also auf zwei Wegen: über die Glocke und per Push an die Authenticator-App. E-Mail ist der Kanal, den Sie bewusst hinzufügen. Lesen Sie nach jeder Änderung das Feld `Right now a request would go to`. Es listet die Personen auf, die die Richtlinie in diesem Moment findet. ### Wer als Genehmigender zählt Nur **aktivierte** Personen zählen, und die Person, für die der Agent handelt, wird von der Liste genommen. Deshalb kann ein Agent auf dem Papier einen Verantwortlichen haben und trotzdem niemanden, den man fragen kann. Beispiel: Ein Agent wurde aus `Detected` übernommen und erhielt einen Governance-Verantwortlichen. Ein Direct Manager wurde nie eingetragen. Der Verantwortliche verlässt das Unternehmen, und das Konto wird deaktiviert. Die nächste Anfrage für diesen Agenten bleibt nicht liegen. Sie wird sofort abgelehnt, denn eine Anfrage, die niemand beantworten kann, würde später ohnehin mit demselben Ergebnis ablaufen, nachdem der Aufrufer Minuten verloren hat. Zwei Gewohnheiten verhindern das: Fügen Sie mit `Add a fallback: who to ask when nobody above is found` einen zweiten Schritt hinzu, und prüfen Sie das Feld, wenn Personen ihre Rolle wechseln. ### Wie lange eine Anfrage wartet `A request waits for` im Schritt beträgt standardmäßig 10 Minuten. Ein API-Aufrufer, der eine Anfrage stellt, kann eigene `ExpirationSeconds` senden. Ein positiver Wert hat Vorrang vor der Richtlinie und ist auf 86400 Sekunden begrenzt, also einen Tag. Ohne diesen Wert entscheidet die Richtlinie. ### Ein verlorenes Secret Das Secret einer Agenten-Anmeldeinformation wird einmal angezeigt, beim Anlegen. Es lässt sich nicht erneut anzeigen, auch nicht für einen Administrator. Wenn ein Entwickler es nicht gespeichert hat: 1. Öffnen Sie die Registerkarte `Credentials` des Agenten und widerrufen Sie die Anmeldeinformation mit `Revoke`. 2. Legen Sie mit `Create Credential` eine neue an und übergeben Sie das neue Secret sicher. Widerrufen Sie zuerst, denn niemand weiß, wo eine Kopie des alten Secrets liegen könnte. Denken Sie daran, dass das Widerrufen einer Anmeldeinformation bereits ausgestellte Tokens nicht beendet. Bei Verdacht auf Missbrauch nutzen Sie `Kill Switch`. ::diagram ais-lost-credential ### Ein Budget für Tokens, nicht für Aufrufe `Token issuances / hour` unter `Budget & Quotas` begrenzt, wie oft der Agent ein Token erhalten darf. Die Anfragegrenzen deckeln Aufrufe. Ein Agent, dem ein Token verweigert wird, schreibt `AGENT_TOKEN_DENIED` mit dem Grund auf seine Registerkarte `Audits`. Lesen Sie diesen Grund, bevor Sie eine Grenze anheben.

Die Gateways betreiben: Zeitlimits, Streaming und Token-Audience

Sobald Verkehr durch die Gateways fließt, ändern sich die Fragen. Niemand fragt mehr "ist das erlaubt", sondern "warum verhält es sich so". Fünf Verhaltensweisen erklären die meisten dieser Fragen. | Was auffällt | Ursache | Wo Sie es sehen | | --- | --- | --- | | Lange Aufgaben scheitern nach etwa fünf Minuten, kurze laufen | `Timeout (seconds)` des Anbieters | Ergebnis HTTP 504 am Aufruf | | Eine Antwort kommt am Stück statt Wort für Wort | Das Gateway musste die ganze Antwort zuerst lesen | `translated` oder `cache` am Aufruf, oder ein AI Flow auf der Antwort | | HTTP 401 mit Bearer-Token, Agentenschlüssel funktionieren | Das Token wurde nicht für diese Route ausgestellt | Ergebnis `DENIED (audience)` | | Ein delegierter Aufruf wird abgelehnt, obwohl Delegation an ist | Die Kette ist zu lang oder nennt einen Agenten doppelt | Die Token-Anfrage wird abgelehnt | | Ein kleineres Modell antwortet als das angeforderte | `Cheaper model close to a limit` | Header `X-Monosign-Downgraded-From` | ### Das Zeitlimit eines Anbieters Jeder Anbieter hat ein `Timeout (seconds)`. Es beträgt standardmäßig 300 und akzeptiert 5 bis 3600. Es gilt für das Warten auf das erste Byte und für das Warten auf jede gestreamte Zeile. Beispiel: Ein Reasoning-Modell denkt sechs Minuten, bevor es etwas sendet. Mit dem Standardwert gibt das Gateway nach 300 Sekunden auf und antwortet mit HTTP 504 `The AI provider did not answer within {n} seconds.` Kurze Prompts beim selben Anbieter funktionieren, wodurch das Problem zufällig wirkt. Die Lösung liegt beim Anbieter: Erhöhen Sie `Timeout (seconds)`. Denselben Aufruf zu wiederholen wiederholt nur das Warten. ### Warum eine gestreamte Antwort auf einmal ankommen kann Normalerweise reicht das Gateway eine gestreamte Antwort so weiter, wie sie eintrifft. In drei Fällen muss es zuerst die vollständige Antwort haben: - die Antwort wird zwischen Anbieterformaten übersetzt (`Let clients of the other format in`), - die Antwort kommt aus dem Antwort-Cache, - ein AI Flow in der Phase `Response` prüft sie. Das Gateway holt die Antwort dann vollständig und spielt sie dem Client als Stream wieder ab. Das ist erwartetes Verhalten und kein Fehler. Ein Flow kann keine Kartennummer in Text verbergen, der schon unterwegs ist. Eine Antwort zu prüfen heißt deshalb, sie zuerst bis zum Ende zu lesen. Sagen Sie es den Benutzern, bevor Sie einen solchen Flow einschalten. ### Tokens müssen für die Route ausgestellt sein Eine Route akzeptiert standardmäßig `Only tokens issued for this route`. Ein OAuth-Client nennt die Route deshalb, wenn er Monosign um ein Token bittet: Er sendet den Parameter `resource` mit der registrierten Gateway-Route (RFC 8707). - Kein `resource`: HTTP 401 `The token names no resource. Request it with the resource parameter set to this gateway route.` - Ein Token für etwas anderes: `The token was issued for another resource.` Korrigieren Sie den Aufrufer, nicht die Prüfung. `Which tokens are accepted` zu lockern würde erlauben, ein für einen Dienst ausgestelltes Token bei einem anderen zu verwenden. Agentenschlüssel unterliegen dieser Prüfung nicht, und die Route muss mit `Register` registriert sein, bevor Tokens für sie ausgestellt werden können. ::diagram ais-route-token-resource ### Eine Obergrenze für Delegationsketten `Agent to agent delegation depth` legt fest, wie weit die Aufgabe einer Person weitergereicht werden darf. Über dieser Einstellung liegt eine feste Obergrenze: Eine Kette, die tiefer als 8 Agenten ist oder denselben Agenten doppelt nennt, wird immer abgelehnt. ~~Das verhindert~~Ein Agent, ~~dass zwei Agenten eine~~der bereits Teil der Kette ist, kann die Aufgabe ~~endlos hin und her reichen~~nicht erneut erhalten. ### Wenn ein günstigeres Modell antwortet Verschiebt `Cheaper model close to a limit` einen Aufruf auf ein günstigeres Modell, trägt die Antwort den Header `X-Monosign-Downgraded-From` mit dem angeforderten Modell, und der Aufrufdatensatz hält dasselbe fest. Entwickler können den Header lesen und Benutzern zeigen, warum die Antwort anders aussieht.

AI Flows im Betrieb: Testen, Genehmigungen und Geltungsbereich

Einen Flow zu bauen dauert Minuten. Ihn gut zu betreiben hängt an Details, die man leicht übersieht: wie man ihn gefahrlos ausprobiert, was der Absender nach einer Genehmigung tun muss, welche Funde sich verbergen lassen und welchen Verkehr ein Flow nie berührt. ### Drei Wege, einen Flow auszuprobieren | | `Test this flow` | `Watching` | `Enforcing` | | --- | --- | --- | --- | | Eingabe | Beispieltext, den Sie im Designer eingeben | Echter Verkehr | Echter Verkehr | | ~~Guard-Dienste, Webhooks, das Richtermodell | Nicht aufgerufen | Aufgerufen | Aufgerufen | |~~ Eine Person wird gefragt | Nie | Nie | Ja | | Ein Workflow wird gestartet | Nie | Nie | Ja | | Die Nachricht wird geändert oder gestoppt | Nein | Nein | Ja | `Test this flow` läuft mit Trockendiensten: Es zeigt, wie Ihre Schritte und Muster auf einen Text reagieren, ruft aber ~~niemanden~~keinen Guard-Dienst, keinen Webhook, kein Richtermodell und keinen Genehmiger auf. Ein beobachtender Flow sieht echten Verkehr und schreibt unter `Runs`, was er getan hätte, mit Hinweisen wie `would block`, `would ask for approval` und `would start a workflow`. Lesen Sie diese Hinweise, bevor Sie `Start enforcing` wählen. ### Nach `Ask a person`: erneut senden Monosign hält eine Nachricht nicht offen, während eine Person entscheidet. Der Absender erhält `This message needs approval before it can go on. Send it again once it is approved.` Woher weiß Monosign, dass die zweite Nachricht die genehmigte ist? Es vergleicht einen Fingerabdruck aus Flow, Schritt, Oberfläche, Ziel, Tool, Person, Agent und Text. Beispiel: Um 10:00 sendet ein Agent eine Vertragszusammenfassung, und der Flow hält sie an. Um 10:10 genehmigt der Genehmigende. Um 10:11 sendet der Agent die identische Nachricht, und sie geht durch. Daraus folgen drei Regeln: - Dieselbe Nachricht innerhalb von 30 Minuten nutzt die bestehende Anfrage. Sie erzeugt keine zweite. - Eine genehmigte Anfrage lässt die Nachricht einmal passieren. - Ein geänderter Text ist eine neue Nachricht und braucht eine neue Genehmigung. Eine abgelehnte Anfrage blockiert. Agentenentwickler müssen das einbauen: die Nachricht behalten, warten und unverändert erneut senden. ::diagram ais-flow-approval-resend ### Welche Funde sich verbergen lassen `Hide what was found` muss wissen, **wo** im Text ein Fund steht. Nur zwei Quellen liefern Positionen: | Quelle des Funds | Kann blockieren | Kann `Hide what was found` speisen | | --- | --- | --- | | Eingebautes `Find patterns` | Ja | Ja | | `Ask a guard service` mit `Microsoft Presidio` | Ja | Ja | | Die anderen Guard-Dienste | Ja | Nein | Ein Kunde, der Presidio bereits betreibt, setzt also einen Schritt `Ask a guard service` und darunter einen Schritt `Hide what was found`. Ein Guard-Dienst, der nur sagt "diese Nachricht ist schädlich", kann die Nachricht stoppen, aber nicht schwärzen. ### Geltungsbereich: die Ausnahme `automation` Ein Flow ohne Grenzen unter `Where does it apply?` gilt überall, mit einer Ausnahme: Prompts der Monosign-eigenen Funktion `automation`. Diese berührt nur ein Flow, der `automation` unter `Only in these Monosign features` nennt. Fragt die Prüfung, warum Automation-Prompts nie untersucht wurden, ist das die erste Stelle zum Nachsehen. ### Über die API angelegte Flows | | Designer | API ohne das Feld | | --- | --- | --- | | Modus | Beginnt als Beobachten | `Enforce` | | Was ein aufgezeichneter Lauf vom Text behält | Ein kurzer Auszug mit geschwärzten Funden | Nichts | Ein über die API ohne `Mode` angelegter Flow wirkt deshalb auf echten Verkehr, sobald sein Zustand `Active` wird. Teams, die Flows aus einer Pipeline ausrollen, sollten `Mode` und `RetentionMode` immer ausdrücklich senden. ### Personen, die immer wieder an die Richtlinie stoßen Blockierungen durchsetzender Flows zählen für die Erkennung `AI Policy Violations`, standardmäßig 5 blockierte Nachrichten in 60 Minuten. Die Erkennung setzt für diese Person `user.hasActiveThreat`. Weil Flow-Bedingungen `user.hasActiveThreat` lesen können, kann ein anderer Flow genau für diese Personen strenger sein, etwa indem er eine Person fragt, wo andere durchgehen.

Eine Maschinenidentität wählen und eingrenzen

Die vorige Lektion hat Maschinenidentitäten vorgestellt. Diese hilft Ihnen bei der Wahl zwischen den Optionen, denn jede Wahl verschiebt ein Risiko von einem Ort an einen anderen. ### Welche Anmeldemethode | Methode | Secret in der Workload gespeichert | Braucht | Passt für | | --- | --- | --- | --- | | Universal Auth | Ja, ein Client-Secret | Sonst nichts | Überall, wenn nichts Besseres verfügbar ist | | OIDC | Nein | Einen öffentlich auffindbaren Issuer | CI-Pipelines wie GitHub Actions und GitLab, verwaltete Cluster mit OIDC-Issuer | | Kubernetes | Nein | Monopam muss den API-Server des Clusters erreichen | Jeden erreichbaren Cluster, auch selbst betriebene | Die OIDC-Anmeldung funktioniert nicht für einen selbst betriebenen Cluster, dessen Issuer nur innerhalb des Clusters bekannt ist. Nutzen Sie dort eine Kubernetes-Identität. ::diagram ais-machine-auth-choice ### OIDC für eine Pipeline: der gebundene Claim Ein KI-Coding-Agent läuft in einem CI-Job. Die CI-Plattform gibt jedem Job bereits ein signiertes Token, also muss kein Monopam-Secret in der Pipeline liegen. Die Identität hat drei Felder: - `Issuer`: der Token-Issuer der CI-Plattform, zum Beispiel `https://token.actions.githubusercontent.com`. - `Audience`: wird geprüft, wenn sie gesetzt ist. - `Bound claim (sub)`: welche Workload sich anmelden darf. Ein Platzhalter am Ende wird unterstützt, wie in `repo:my-org/*`. ~~Der gebundene~~Füllen Sie den gebundenen Claim ~~ist~~aus. Die Anmeldung prüft das ~~Wichtigste~~Token gegen die Schlüssel des Issuers, gegen die Audience, wenn eine gesetzt ist, und gegen den gebundenen Claim. Eine öffentliche CI-Plattform ~~stellt~~signiert die Tokens ~~für alle ihre~~aller ihrer Kunden ~~aus. Nur dem~~mit demselben Issuer ~~zu vertrauen hieße~~, ~~viel zu vielen Pipelines zu vertrauen. Der Claim~~und `Bound claim (sub)` ~~engt~~ist das ~~Vertrauen auf~~Feld, das die Identität an Ihre eigenen Repositories ~~ein~~bindet. ### Kubernetes: wer prüft das Token Monopam prüft ein Service-Account-Token nicht selbst. Es sendet das Token für einen TokenReview an den Cluster. Diese Prüfung braucht eine Anmeldeinformation, und Sie wählen welche: | | `Reviewer Token` gesetzt | `Reviewer Token` leer (Selbstprüfung) | | --- | --- | --- | | Wer an `system:auth-delegator` gebunden ist | Ein Reviewer-Service-Account | Jeder gebundene Workload-Service-Account | | Zusätzliche Rechte für Workloads | Keine | Je eine clusterweite Berechtigung | | In Monopam gespeichert | Ein Cluster-Token, verschlüsselt | Nichts | Ist die Priorität, dass Agenten-Workloads keine zusätzlichen Rechte im Cluster erhalten, wählen Sie ein Reviewer Token. Ist die Priorität, dass Monopam kein Cluster-Token speichert, wählen Sie die Selbstprüfung und akzeptieren die breitere Bindung. ### Grants: Projekt, Umgebung, Pfad, Schreiben Ein Grant hat `Project`, `Environment`, `Path` und den Schalter `Write`. - `Environment` ist `All environments`, solange Sie keine wählen. Das deckt auch später angelegte Umgebungen ab. - `Path` ist ein Präfix: `/db` deckt `/db` und alles darunter ab. - `Write` ist aus, solange Sie es nicht einschalten. Beispiel: Ein Reporting-Agent braucht die Datenbankeinstellungen des Projekts `billing` in `staging`, nur lesend. Der Grant lautet Projekt `billing`, Umgebung `staging`, Pfad `/db`, `Write` aus. Die Umgebung leer zu lassen würde ihm auch die Produktion geben. ### Wo das Lese-Audit-Fenster liegt `Machine read audit window (minutes)` steht unter `System → Secrets API`, in der Karte `Audit`. Es gilt für Lesezugriffe über die Maschinen-API, das MCP-Tool `get_secret` und die Vault-kompatible API. Mit 0 erhält jeder Lesezugriff einen eigenen Eintrag. ### Sitzungen über den MCP-Server Für Arbeit auf einem Server nutzt ein Agent mit Benutzer-Token diese Tools statt eines Passworts: | Tool | Zweck | | --- | --- | | `open_session` | Öffnet eine vermittelte Sitzung. Antwortet `approval_pending`, wenn das Konto eine Genehmigung braucht | | `session_exec` | Führt eine Befehlszeile in einer SSH-Sitzung aus | | `session_query` | Führt eine Abfrage in einer Datenbanksitzung aus | | `close_session` | Beendet die Sitzung | Die Anmeldeinformation bleibt in Monopam, das Modell sieht sie also nie. Eine SSH-Sitzung wird aufgezeichnet, erscheint in Live Sessions, wo ein Operator sie übernehmen oder beenden kann, und jede Befehlszeile durchläuft die Prüfung privilegierter Befehle.