Erkennungsrichtlinien und Schweregrade konfigurieren
So gestalten, staffeln und rollen Sie Zeuslock-Erkennungsrichtlinien aus, ohne das Vertrauen der Operatoren zu verbrennen — von Monitor-Baseline bis Block.
Das Richtlinienmodell in einem Absatz
Jede Zeuslock-Richtlinie ist eine Matrix aus Fundtypen (was erkannt wurde) und Aktionen (was damit geschehen soll). Für jeden Fundtyp wählen Sie eine von drei Aktionen: Monitor protokolliert das Ereignis und leitet den Prompt unverändert weiter; Anonymize überschreibt den sensiblen Wert vor Ort durch eine formaterhaltende Maskierung, bevor der Prompt das Gerät verlässt; Block lehnt die Anfrage ab und zeigt der Nutzerin eine eingebettete Erklärung. Aktionen werden pro Fundtyp, pro Gruppe und optional pro Ziel zugewiesen. Es gibt bewusst keinen globalen An/Aus-Schalter.
Fundkategorien, auf die Sie reagieren können
Zeuslock liefert Detektoren in fünf Familien. Jede erhält eine Aktion unabhängig von den anderen.
- Zugangsdaten —
api_key(AWS AKIA, Stripe sk_, OpenAI sk-, Azure, Google/Gemini, GitHub ghp_, Slack xoxb-, GitLab glpat-, npm npm_, Bearer-Tokens),password,jwt,private_key,connection_string,env_variable. - Finanzen —
credit_card(Luhn-geprüft),IBAN,crypto_wallet. - Personenbezogene Daten —
email,phone, US-SSN, französischerNIR(Sécurité Sociale),passport, Postanschrift,ip_address. - Quellcode — heuristische Erkennung eingefügten proprietären Codes, mit Sprachfingerabdruck.
- Organisationskennungen — Ihre benutzerdefinierten Detektoren (Projektcodenamen, interne Kundennummern, M&A-Ziele). Den vollständigen Erstellungsprozess finden Sie im Entwicklerleitfaden zu benutzerdefinierten Detektoren.
Schweregrade und ihre Zuordnung
Der Schweregrad wird zum Erkennungszeitpunkt aus drei Signalen berechnet: dem intrinsischen Risiko des Fundtyps, kontextuellen Heuristiken rund um den Treffer (umgebende Tokens, Prompt-Struktur, Ziel) und der Konfidenz des Detektors. Sie können das Standard-Mapping pro Fundtyp überschreiben, wir empfehlen jedoch, im ersten Monat die Voreinstellungen beizubehalten.
| Schweregrad | Bedeutung | Typische Auslöser | Standardaktion |
|---|---|---|---|
| Kritisch | Aktives Geheimnis oder regulierte Kennung mit hoher Konfidenz | private_key, AWS-AKIA-Geheimnispaar, gültige credit_card, NIR | Block |
| Hoch | Wahrscheinlich sensibel, teilweise Bestätigung | Bearer-Token, Passwort in Schlüssel/Wert-Struktur, IBAN | Anonymize |
| Mittel | Sensibel aber wiederherstellbar oder geringere Konfidenz | E-Mail + Telefon-Kombination, Passmuster, generische API-Key-Form | Anonymize |
| Niedrig | Informativ, häufig mit Falsch-Positiv-Risiko | Einzelne email, ip_address, öffentliche Kennung | Monitor |
Der von uns empfohlene Rollout
Starten Sie nicht mit Block. Die ersten zwei Wochen jedes DLP-Rollouts zeigen Ihnen, was Ihre Organisation tatsächlich in ChatGPT, Claude und Gemini einfügt — und die Antwort ist fast immer vielfältiger, als das Sicherheitsteam erwartet hat. Staffeln Sie den Rollout in drei Phasen.
- Woche 1-2 — Monitor überall. Setzen Sie jeden Fundtyp auf Monitor. Prüfen Sie täglich das Incidents-Dashboard. Stimmen Sie benutzerdefinierte Detektoren ab. Identifizieren Sie die in Ihrer Umgebung lauten Fundtypen.
- Woche 3-5 — Anonymize für Finanzen und PII. Schalten Sie
credit_card,IBAN,email,phone,passport,SSN,NIRund Postadressen auf Anonymize. Die formaterhaltende Maskierung übergibt dem nachgelagerten LLM einen strukturell gültigen Wert, sodass Nutzerabläufe nicht brechen. - Ab Woche 6 — Block für Zugangsdaten und Quellcode. Schalten Sie
api_key,password,jwt,private_keyund Quellcode auf Block. Zu diesem Zeitpunkt haben die Nutzer genug Anonymize-Banner gesehen, um zu verstehen, warum Zeuslock ablehnt, und Ihre Falsch-Positiv-Rate ist niedrig genug, dass Blockierungen sauber ankommen.
Starten Sie niemals mit Block. Block-Richtlinien am ersten Tag erzeugen wütende Tickets, treiben Nutzer auf private Geräte und verbrennen das politische Kapital, das Sie für den Rest des Programms brauchen. Monitor zuerst. Immer.
Gruppenspezifische Überschreibungen
Eine einzelne Richtlinie passt selten für das gesamte Unternehmen. Entwickler fügen den ganzen Tag API-Keys und Code in Copilot ein; der Vertrieb fügt Kundenlisten in ChatGPT ein, um Outreach zu schreiben; die Finanzabteilung fügt IBANs in Gemini zur Abstimmung ein. Jede Gruppe braucht eine andere Haltung.
- Öffnen Sie
Settings → Policies → Groups. - Wählen Sie die SCIM-Gruppe (oder erstellen Sie eine manuelle Gruppe) und klicken Sie auf Override default policy.
- Sie sehen dieselbe Matrix wie die Standardrichtlinie, mit Vererbungspfeilen neben jeder Zelle. Zellen, die Sie nicht anfassen, erben weiterhin vom Standard — wenn Sie später den Standard ändern, aktualisieren sich diese Zellen automatisch.
- Speichern Sie die Überschreibung. Sie greift beim nächsten Prompt; kein Client-Neustart nötig.
Ein verbreitetes Muster: Entwickler erhalten Anonymize auf api_key (mit strukturell gültigen Fake-Keys, damit ihre Code-Beispiele weiterhin parsen), während alle anderen Block erhalten.
Zeitliche Ausnahmen
Risiko ist über den Tag nicht konstant. Prompts außerhalb der Geschäftszeiten an Consumer-KI-Tools sind statistisch eher Exfiltration oder unbedachte Nebenprojekte. Hängen Sie in Settings → Policies → Schedules eine strengere Variante an Nicht-Geschäftszeiten — zum Beispiel Anonymize auf Zugangsdaten zwischen 20:00 und 07:00 Ortszeit sowie am Wochenende auf Block hochstufen. Zeitpläne respektieren die Zeitzone jeder Nutzerin aus ihrem SCIM-Profil.
Zielspezifische Überschreibungen
Nicht jedes KI-Tool verdient dasselbe Vertrauen. Wir empfehlen drei Stufen.
- Geprüfte interne LLMs (ein selbst gehostetes Mistral, ein Azure-OpenAI-Deployment in Ihrem Tenant) — lockern Sie auf Monitor für PII und Finanzen, behalten Sie Block für Zugangsdaten.
- Geprüfte kommerzielle Tools (ChatGPT Enterprise, Claude for Work mit unterzeichnetem AVV) — wenden Sie Ihre Standardrichtlinie an.
- Nicht freigegebene oder hochriskante Tools (DeepSeek, Poe, jedes von der Shadow-AI-Erkennung markierte Tool) — eskalieren Sie alles um eine Stufe. Anonymize wird Block, Monitor wird Anonymize. Zeuslock meldet die erste Nutzung eines nicht freigegebenen Tools automatisch an den CISO.
Benutzerdefinierte Detektoren
Benutzerdefinierte Detektoren fangen Organisationskennungen ab — interne Projektcodenamen, M&A-Zielnamen, Mitarbeiter-ID-Formate, Kundenreferenznummern. Sie nehmen am gleichen Schweregradmodell wie eingebaute Detektoren teil und können jede der drei Aktionen erhalten. Der vollständige Erstellungsworkflow inklusive Backtest-Tool gegen die letzten 30 Tage Traffic steht im Entwicklerleitfaden.
Testen Sie jede Richtlinienänderung mit Dry-Run
Bevor Sie eine Richtlinienänderung aktivieren, lassen Sie sie im Dry-Run-Modus laufen. Zeuslock spielt die letzten 24 Stunden Prompts gegen die vorgeschlagene Richtlinie ab und zeigt Ihnen exakt, was blockiert, anonymisiert oder protokolliert worden wäre — pro Nutzer, pro Gruppe, pro Ziel. Wenn der Dry-Run 400 neue Blockierungen für das Legal-Team wegen eines Bearer-Falsch-Positivs in deren Vertragsvorlagen zeigt, erfahren Sie es vor ihnen. Aktivieren Sie nur, wenn der Dry-Run-Bericht Ihrer Absicht entspricht.
Was Sie im ersten Monat beobachten sollten
- Das Incidents-Dashboard, täglich, gefiltert nach Kritisch und Hoch.
- Die Falsch-Positiv-Warteschlange — alles, was hier markiert wird, fließt in die Detektor-Abstimmung zurück.
- Shadow-AI-Bericht — neue Tools, die in Ihrer Umgebung auftauchen.
- Blockraten pro Gruppe — wenn eine Gruppe zehnmal so viele Blockierungen wie eine andere erzeugt, braucht die Richtlinie wahrscheinlich eine Überschreibung, keine Predigt.