So vollziehen Sie eine Zugriffsentscheidung nach

Die Revision fragt: „Am 14. Oktober um 21:10 hat Max Vermittler Vertragsdaten gelesen. Von wo, mit welchem Zugang, und welche Einstellung hat das erlaubt?“ – oder umgekehrt: „Warum wurde Erika am Morgen abgewiesen?“

Vier Quellen, über die Person, den Schlüssel und die Korrelationskennung verbunden:

1. Anmeldung finden: SignInEvents mit $filter=Person eq 'Max Vermittler' and At ge 2026-10-14T19:00:00Z and At lt 2026-10-14T20:00:00Z. Das Ereignis nennt Method, KeyId, Origin, Country, NetName, Outcome und bei einer Ablehnung Reason (etwa deniedByCountry, outsideKeyNetworks, revoked). Rules nennt die Regeln, nach denen entschieden wurde, mit Kennung und Version, auch eine Regel, die eine Ausnahme aufgehoben hat (spared, mit dem Vermerk der Ausnahme); Signals nennt Land und zweiten Faktor (siehe Grundlage der Entscheidung).
2. Zugriff finden: AuditEntries mit derselben Person und Zeit; Resource, Verb und Status zeigen, was gelesen wurde, Target den Datensatz (…/Vertraege(17) oder …/Vertraege?$filter=Nr eq 'V-2026-17'), CorrelationId verbindet mit dem Anmeldeereignis.
3. Zugang zum Zeitpunkt: PersonalKeys('k…') zeigt Einschränkungen und Laufzeit des Schlüssels; ChangeLog mit $filter=Entity eq 'PersonalKeys' and EntityKey eq 'k…' zeigt, ob sie sich seitdem geändert haben.

4. Regel heute und damals: explain-sign-in mit der Herkunft aus Schritt 1 nennt die Regeln mit ihrer heutigen Version. Stimmt sie mit der Version im Ereignis überein, steht die Regel noch so wie bei der Anmeldung. Weicht sie ab, zeigt ChangeLog, wer sie seitdem wann wie geändert hat: mit Entity gleich save-sign-in-rule und der Kennung der Regel als EntityKey, wenn sie mit dem Befehl gespeichert wurde, sonst mit Entity in SignInRules, SignInRuleItems und SignInRuleExceptions. Die Anfrage an explain-sign-in:

   { "person": "Max Vermittler", "scope": "Data",
     "origins": [ { "name": "14.10. 21:10", "address": "203.0.113.7" } ] }

5. Zugriffsregel heute und damals: AccessRule im Eintrag aus Schritt 2 nennt die Regel, die den Zugriff erlaubt hat, mit Version (vertrieb-lesen@3f2a8c41d07b9e65). ClientRules zeigt mit RuleVersion die heutige Version; stimmt sie überein, steht die Regel noch so. Sonst zeigt ChangeLog mit Entity in ClientRules und ClientRuleItems, wer sie seitdem wann wie geändert hat. Wer die Regel hat, zeigen PersonRules, WindowsAccounts und SqlLogins.

Ergebnis: Zeit, Herkunft, Zugang, gelesener Datensatz und die Regeln, nach denen entschieden wurde, mit dem Nachweis, wer diese Regeln wann eingestellt hat.

• Version statt Inhalt. Das Ereignis hält die Version der Regel fest, nicht ihren ganzen Inhalt; den Inhalt einer früheren Version liefern die Werte „vorher“ im Änderungsprotokoll.
• Ältere Ereignisse aus der Zeit, bevor der Dienst die Grundlage festhielt, haben leere Rules und Signals; für sie ergibt sich die Regel allein aus dem Änderungsprotokoll.
• AuditEntries reicht so weit zurück wie seine Frist. Mit Verwaltungsspeicher sind es Gateway:AuditLog:Days (Vorgabe 90 Tage), ohne Speicher die letzten 10 000 Einträge seit dem Start. Für ältere Zugriffe lesen Sie den Audit-Strom in den Protokollen des Dienstes, nach CorrelationId oder Person.
• Einträge vor der Erweiterung des Zugriffsprotokolls haben Target und AccessRule leer; für sie ergeben sich Datensatz und Regel nur aus dem Änderungsprotokoll und den Regeln der Person.
• Personenbezogene Daten. Target kann Schlüssel- und Filterwerte mit Personenbezug enthalten (siehe `Gateway:AuditLog`). Einzelereignisse mit Adresse und Person sieht nur, wer das Recht sign-in-events hat; vergeben Sie es gezielt, etwa an die Revision (siehe Anmeldemuster prüfen).

• HTTP: Verwaltung – Anmeldeprotokoll
• So prüfen Sie Anmeldemuster und Herkunft
• Zero Trust und private Geräte