Audit-Protokolle

Überblick

Ottili ONE hält fest, was in Ihrem Unternehmen passiert. Wichtige, sicherheitsrelevante Aktionen werden über Module und Dienste hinweg in Audit-Protokollen* festgehalten – nachvollziehbar, unternehmensbezogen (company-scoped) und so angelegt, dass sie nicht still und heimlich verändert werden können. Zusammen mit der deny-by-default-Zugriffskontrolle und der strengen Mandanten-Isolation ergibt das eine lückenlose, nachweisbare Spur über die gesamte Plattform.

Dieser Artikel erklärt, was Audit-Protokolle sind, was ein einzelner Eintrag enthält, wo sie greifen und wer sie im Unternehmen einsehen darf. Vertiefende Artikel finden Sie am Ende unter [Verwandte Artikel](#verwandte-artikel).

Was sind Audit-Protokolle?

Ein Audit-Protokoll ist das chronologische, unveränderliche Gedächtnis der Plattform für sicherheitsrelevante Vorgänge. Statt dass jeder Dienst sein eigenes, isoliertes Log führt, schreibt Ottili ONE prüfungsrelevante Ereignisse in gemeinsame, unternehmensbezogene Audit-Datensätze. Dadurch entsteht über alle Module hinweg eine einheitliche Spur: Business Hub, LD3, Ottili Files, Flows, Coder, Messenger, Support und die Plattform-Dienste selbst.

Die Grundregel: Jede geprüfte, mutationsbehaftete oder sicherheitsrelevante Aktion hinterlässt einen Eintrag.* Ein fehlgeschlagener oder verweigerter Zugriff wird genauso protokolliert wie ein erfolgreicher – ein Angreifer oder ein versehentlicher Fehler hinterlässt also immer eine Spur.

Was steht in einem Audit-Eintrag?

Ein Audit-Eintrag beschreibt das Ereignis mit den Feldern, die für Nachvollziehbarkeit nötig sind. Am Beispiel des Modul-Zugriffs-Audits gehören dazu:

• Zeitstempel (timestamp):* Wann die Aktion stattfand.
• Aufrufendes Modul (requesting_module):* Welcher Dienst die Aktion ausgelöst hat.
• Zielmodul (target_module):* Auf welchen Dienst sich die Aktion bezog.
• Zugriffstyp (access_type):* Art des Zugriffs (z. B. Lese- oder Schreibzugriff).
• Operation (operation):* Die konkrete Aktion (z. B. installieren, aktivieren).
• Status (status):* Ergebnis der Aktion (Erfolg, Verweigert, Fehler).
• Erforderliche Berechtigung (capability_required):* Welche Entitlement/Berechtigung geprüft wurde.
• Grund (reason):* Kurze Begründung, z. B. bei einer Verweigerung.
• Unternehmen (company_id):* Die zugehörige, verifizierte Mandantengrenze.

Nicht jedes Audit-Protokoll trägt alle Felder – je nach Quelle (Modul-Lebenszyklus, Entitlement-Prüfung, Secrets-Zugriff, Messenger, Support) werden passende, sicherheitsrelevante Felder erfasst. Entscheidend ist: jedes Protokoll ist eindeutig einem Unternehmen zugeordnet und enthält genug Kontext, um die Aktion später zu rekonstruieren.

Wo greifen Audit-Protokolle?

Audit-Protokolle decken heute mindestens diese Bereiche ab:

• Modul-Lebenszyklus:* Installation, Aktivierung, Deaktivierung, Deinstallation, Gesundheitsstatus- und Upgrade-Änderungen werden als Audit-Events geschrieben.
• Berechtigungen und Entitlements:* Jede verweigerte Entitlement-Prüfung wird als Audit-Event festgehalten – wer, wann, worauf und warum abgelehnt.
• Secrets-Verwaltung:* Administrative Secrets-Zugriffe werden für die Nachvollziehbarkeit protokolliert; sensitive Werte werden dabei maskiert.
• Messenger-Aktionen:* Nachrichten- und Bot-Aktionen werden in die zentrale Audit-Tabelle der Plattform geschrieben.
• Support:* Jede mutationsbehaftete Support-Aktion erzeugt genau ein append-only Audit-Event – die Historie ist somit nicht veränderbar.
• Mandanten-Isolation:* Isolationsprüfungen hinterlassen eine umfassende Audit-Spur; jede bestätigte Kontextprüfung wird festgehalten.

Unternehmensbezogen und isoliert

Audit-Protokolle sind genauso unternehmensbezogen wie der Rest der Plattform. Jeder Eintrag trägt eine verifizierte company_id; ein Zugriff über Unternehmensgrenzen hinweg wird niemals aus einem Standardwert, einer ersten Mitgliedschaft oder einer Eingabe des Aufrufers abgeleitet.

• Fail-closed:* Die gemeinsame Funktion assert_same_company() lehnt jede Anfrage ohne oder mit falschem Unternehmenskontext ab.
• Datenbank-Zeilensicherheit (RLS):* Abfragen gegen Audit-Tabellen werden nach der verifizierten company_id gefiltert; der Laufzeit-Standardzustand ist „verweigern".
• Kein Cross-Tenant:* Ein Unternehmen kann niemals die Audit-Protokolle eines anderen Unternehmens einsehen.

Das bedeutet: Audit-Protokolle beweisen nicht nur, was passiert ist, sondern auch, dass es innerhalb der korrekten Mandantengrenze passiert ist.

Wer darf Audit-Protokolle einsehen?

Der Zugriff auf Audit-Protokolle folgt derselben expliziten, deny-by-default-Logik wie der Rest von Ottili ONE. Sensible Einblicke sind an Rollen gebunden:

• Owner und Admin:* Verfügen über die weitreichendsten Rechte und sehen sicherheitsrelevante Ereignisse ihres Unternehmens über die Observability und die Ottili Console* ([ottili.one/console](https://ottili.one/console)).
• Manager, Mitarbeitende und Betrachter:* Erhalten nur die Einblicke, die ihre Rolle explizit erlaubt – niemals die volle Audit-Historie ohne Berechtigung.

Die Console und die Observability teilen sich denselben Ottili-Auth-Login und denselben Unternehmenskontext; wer keine Berechtigung hat, sieht keine Einträge. Wie Rollen im Detail entscheiden, beschreibt [Rollen und Berechtigungen](/docs/roles-and-permissions).

Status und Verfügbarkeit

Ottili ONE unterscheidet klar zwischen Live, Beta, Private Beta, In Development, Planned und Concept. Für Audit-Protokolle gilt aktuell:

• Live:* Die Protokollierung sicherheitsrelevanter Aktionen (Modul-Lebenszyklus, Entitlement-Verweigerungen, Secrets-Zugriffe, Messenger-Aktionen, Support-Events, Isolationsprüfungen) ist ein aktiver Bestandteil der Plattform.
• Live:* Die Einsicht für Administratoren erfolgt über die Observability und die Ottili Console.
• Live:* Die unternehmensbezogene, append-only Auslegung stellt sicher, dass Protokolle nicht nachträglich verändert werden können.

Wir nennen hier bewusst keine weitergehenden, noch nicht verifizierten Funktionen (z. B. exportierte, mandantenübergreifende Audit-Dashboards) als verfügbar. Was die Statusbegriffe im Einzelnen bedeuten, beschreibt [Feature-Status-Labels verstehen](/docs/understand-feature-status-labels).

Verwandte Artikel

• [Sicherheitsübersicht](/docs/security-overview) — wie die Sicherheitsarchitektur zusammenhängt.
• [Rollen und Berechtigungen](/docs/roles-and-permissions) — wer was einsehen und tun darf.
• [Approval Queue](/docs/approval-queue) — menschliche Freigabe sensibler Aktionen.
• [Mandanten-Isolation](/docs/tenant-isolation) — warum Ihre Daten und Protokolle isoliert bleiben.
• [Geteilte Berechtigungen und Entitlements](/docs/shared-permissions-and-entitlements) — das bereichsübergreifende Berechtigungsmodell.
• [Unternehmen, Team & Berechtigungen](/docs/company-and-team) — wie Rollen und Zugriff funktionieren.
• [Konto- und Datensicherheit](/docs/account-and-data-security) — Authentifizierung, Sitzungen, Isolation, Schwachstellen melden.
• [Die Ottili Console navigieren](/docs/navigate-ottili-console) — wo Sie Verwaltung und Observability finden.
• [Feature-Status-Labels verstehen](/docs/understand-feature-status-labels) — was die Statusbegriffe bedeuten.