Zum Inhalt springen

Audit-Log

Jede Aktion, die Nutzerdaten liest oder ändert, sowie die meisten Konfigurationsänderungen, wird in Osiris’ Audit-Log geschrieben — über die Web-Oberfläche, die Integrations-API oder einen Admin-Consent-Flow. Das ist keine optionale Protokollierung: Die Datenbank selbst weist UPDATE/DELETE auf der Audit-Tabelle zurück.

Jeder Eintrag trägt wer (ein Nutzer, ein API-Schlüssel oder „System“), wann, was (eine Aktion, z. B. „Wiederherstellung angefordert“ oder „Admin-Consent erteilt“), für wen, falls im Auftrag einer anderen Person gehandelt wurde (Impersonation), das Ziel (ein Postfach, eine Quelle, ein Webhook und so weiter), den Mandanten und die IP-Adresse, von der die Anfrage kam.

Die Kategorien umfassen Anmeldung, Quellen, Verzeichnis-Sync, Sicherung, Restore, Verifizierung, Speicher, Einstellungen, Mandanten und Mitglieder, API-Schlüssel, Webhooks, Lizenzierung und — sobald es erscheint — das Archiv.

Einträge sind je Mandant verkettet (jeder Eintrag verweist auf den Hash des vorherigen) und mit einem täglichen Anker versiegelt, sodass eine nachträgliche Änderung erkennbar ist: Sie bricht die Verkettung zum nächsten Eintrag, oder passt nicht mehr zum Anker des Tages. Jetzt prüfen prüft die gesamte Kette erneut und meldet genau, wo ein Bruch liegt, falls einer existiert, und seit wann für Einträge nicht mehr eingestanden werden kann.

Filtern Sie nach Mandant (Provider-Administrationen können „Alle Mandanten“ oder die eigenen Einträge der Installation wählen), Aktion oder Aktionskategorie, Akteur (E-Mail, Name oder Nutzer-ID), Ziel und einem Zeitraum. Jeder Eintrag, der im Auftrag jemandes Nutzer- oder Sicherungsdaten liest — eine Administration, die das Postfach einer anderen Person in Wiederherstellen öffnet, ein mandantenweit erzeugter Bericht, eine Berechtigungsprüfung — erscheint ebenfalls hier, nicht nur die Aktionen, die etwas ändern.