Hinterlässt diese selbst gehostete Anwendung einen Audit-Trail? Eine Checkliste für Käufer

Audit-Logging ist eine Anforderung bei der Anwendungsauswahl

Eine selbst gehostete Anwendung kann einfach bereitzustellen sein und dennoch ungeeignet für Daten, deren Nutzung nachvollziehbar sein muss. Wenn die Anwendung Kunden-, Mitarbeiter-, Finanz-, Betriebs- oder andere sensible Geschäftsdaten enthalten soll, stellen Sie frühzeitig eine Frage: Kann das Team später feststellen, wer was, an welchem Objekt, wann und über welche Schnittstelle getan hat?

Das geht über die Reaktion auf Sicherheitsvorfälle hinaus. Ein nutzbarer Audit-Trail kann die Untersuchung einer unerwarteten Änderung, Freigabe- und Ausnahmeprozesse, regelmäßige Zugriffsprüfungen, die Verantwortlichkeit für Konfigurationsänderungen und die Beweissicherung nach einem Streitfall unterstützen. Die NIST-Leitlinien zur Ereigniswahrnehmung nennen Benutzerinteraktion und Zeit, Konfigurationsaktionen sowie Zugriff auf und Nutzung gespeicherter Daten als auditrelevante Fähigkeiten.

Betrachten Sie „hat Logs“ nicht als ausreichende Antwort. Auditierbarkeit ist eine Eigenschaft des Produkts und der Bereitstellung. Die Anwendung muss die benötigten Ereignisse erzeugen, die Bereitstellung muss sie aufbewahren, autorisierte Prüfer müssen sie abrufen und interpretieren können, und Kontrollen müssen sie vor unbefugter Veränderung oder Löschung schützen.

• Machen Sie Auditierbarkeit vor der Auswahl einer Anwendung zu einer bewerteten Anforderung, statt sie erst nach dem Produktivstart anzugehen.
• Formulieren Sie Anforderungen anhand der Entscheidungen, die die Aufzeichnungen unterstützen müssen, etwa „feststellen, wer eine Rolle vergeben hat“ oder „Exporte von Kundendatensätzen prüfen“.
• Weisen Sie eine verantwortliche Person für Audit-Einstellungen der Anwendung, Verfahren zur Log-Prüfung, Entscheidungen zur Aufbewahrung und den Zugriff auf exportierte Nachweise zu.

Betriebsprotokolle, Audit-Logs und Datenbankhistorie beantworten unterschiedliche Fragen

Betriebsprotokolle dienen in erster Linie dem Betrieb von Software. Docker-Logging-Treiber sammeln Informationen aus laufenden Containern und Diensten; der standardmäßige json-file-Treiber von Docker speichert Container-Logs lokal, sofern keine andere Konfiguration verwendet wird. Diese Aufzeichnungen können helfen, einen Absturz, eine Warnung oder einen Laufzeitfehler zu diagnostizieren, belegen jedoch nicht automatisch, dass ein namentlich bekannter Geschäftsnutzer einen bestimmten Kundendatensatz geändert hat.

Reverse-Proxy-Logs beschreiben eine andere Ebene. Traefik unterscheidet seine eigenen Logs, die etwa Start, Konfiguration, Ereignisse und Herunterfahren abdecken, von Zugriffsprotokollen für Anfragen, die vom Proxy verarbeitet wurden. Zugriffsprotokolle können belegen, dass eine Anfrage einen Endpunkt erreicht hat, identifizieren aber möglicherweise nicht zuverlässig den authentifizierten Geschäftsnutzer, das betroffene Geschäftsobjekt oder das Ergebnis der Aktion. Ihre Felder können zudem bewusst aufbewahrt, verworfen oder geschwärzt werden.

Auch die Datenbankhistorie ist etwas anderes. Das Write-Ahead Logging von PostgreSQL zeichnet Änderungen an Datendateien auf, bevor die zugrunde liegenden Dateien geändert werden, sodass die Wiederherstellung Änderungen nach einem Absturz erneut anwenden kann. Logisches Dekodieren kann dauerhafte Tabellenänderungen aus dem WAL lesbar machen. Keiner der beiden Mechanismen liefert automatisch eine untersuchungsfähige geschäftliche Darstellung: Anwendungskontext, Benutzeridentität, Berechtigungskontext und die Bedeutung einer Änderung können fehlen oder nur schwer rekonstruierbar sein.

Nutzen Sie jede Quelle für ihren passenden Zweck. Betriebs- und Proxy-Logs bleiben für Fehlerbehebung und Infrastrukturuntersuchungen wertvoll. Datenbankmechanismen können für Wiederherstellung oder technische Analysen nützlich sein. Ersetzen Sie jedoch keine dieser Quellen durch Anwendungsauditaufzeichnungen, ohne zu testen, ob sie die tatsächlichen Beweisanforderungen erfüllen.

• Betriebsprotokoll: „Was hat der Prozess oder Container gemeldet?“
• Proxy-Zugriffsprotokoll: „Welche Anfrage hat der Edge-Proxy verarbeitet?“
• Datenbankhistorie: „Welche Änderung auf Speicherebene ist erfolgt?“
• Audit-Aufzeichnung der Anwendung: „Welcher Akteur hat welche bedeutsame geschäftliche oder administrative Aktion woran, wann und mit welchem Ergebnis durchgeführt?“

Beginnen Sie mit den Entscheidungen, die der Audit-Trail unterstützen muss

Eine lange Ereignisliste ist keine Anforderung. Beginnen Sie damit, die Fragen aufzulisten, die ein Prüfer unter realistischen Bedingungen beantworten können muss. Das verhindert, dass Teams technische Protokollierung mit hohem Volumen überbewerten und dabei die wenigen Aktionen mit dem größten Geschäftsrisiko übersehen.

Eine vierteljährliche Zugriffsprüfung benötigt beispielsweise verlässliche Informationen zu Mitgliedschaften und Rollenänderungen. Eine Untersuchung veränderter Finanzdaten kann das betroffene Objekt, gegebenenfalls Vorher- und Nachher-Werte, die Identität des Akteurs, die Zeit und das Aktionsergebnis erfordern. Ein Freigabeworkflow kann Nachweise dafür verlangen, dass eine bestimmte Person einen Schritt genehmigt, abgelehnt oder umgangen hat. Die genauen Felder und die Aufbewahrungsdauer sollten sich aus diesen Fragen ergeben.

Machen Sie den Umfang ausdrücklich. Ein System kann Administratoraktivitäten auditieren, aber keine Änderungen durch gewöhnliche Benutzer, oder erfolgreiche Authentifizierungen erfassen, aber keine fehlgeschlagenen. Beides ist nicht grundsätzlich inakzeptabel; entscheidend ist, ob die dokumentierte und getestete Abdeckung Ihren festgelegten Anwendungsfällen entspricht.

• Untersuchungen: Können Sie Akteur, Objekt, Aktion, Zeitpunkt, Ergebnis und relevanten Kontext identifizieren?
• Freigaben: Können Sie nachweisen, wer eine Freigaberegel genehmigt, abgelehnt, delegiert oder geändert hat?
• Zugriffsprüfungen: Können Sie Mitgliedschaften, Rollen, Berechtigungsänderungen und den verantwortlichen Akteur identifizieren?
• Verantwortlichkeit für Änderungen: Können Sie administrative Konfigurationsänderungen, Integrationsänderungen und sicherheitsrelevante Einstellungen nachvollziehen?
• Prüfung der Datennutzung: Können Sie den Zugriff auf sensible gespeicherte Daten und risikoreiche Aktionen wie Exporte identifizieren, wenn Ihre Richtlinie dies verlangt?

Ereignisse, die Sie vor der Einführung prüfen sollten

Nutzen Sie die offizielle Dokumentation der Anwendung, um Ereignisfamilien zu identifizieren, und ordnen Sie diese Ihren Anwendungsfällen zu. Gehen Sie nicht davon aus, dass ein in der Dokumentation beschriebenes Ereignis in jedem Bereitstellungsmodus aktiviert, gespeichert oder verfügbar ist. So weist die Keycloak-Dokumentation darauf hin, dass Benutzerereignisse standardmäßig weder gespeichert noch angezeigt werden, bis ein Administrator die Ereignisspeicherung aktiviert.

Authentifizierungs- und Berechtigungsaktivitäten sind ein Ausgangspunkt: erfolgreiche Anmeldungen, fehlgeschlagene Anmeldungen, gegebenenfalls Kontowiederherstellung, dokumentierte sitzungsbezogene Ereignisse, Rollen- oder Gruppenänderungen und Änderungen an Berechtigungen. Berücksichtigen Sie bei administrativen Aktivitäten Änderungen über die Verwaltungsoberfläche und, sofern relevant, Verwaltungs-APIs. Keycloak dokumentiert die Auditierung von Administratoraktionen in seiner Admin Console und von REST-Aufrufen, die für diese Aktionen genutzt werden.

Die Abdeckung von Geschäftsdaten verdient eine gesonderte Prüfung. Achten Sie auf Erstellung, Aktualisierung, Löschung, Zugriff oder Nutzung sensibler gespeicherter Daten, soweit erforderlich, auf Massenaktionen, Exporte, Importe, Änderungen an Freigaben sowie Änderungen an Integrationszugangsdaten oder Konnektoren. Eine Anwendung kann eine ausgezeichnete Auditierung administrativer Vorgänge bieten und zugleich nur begrenzte Transparenz über einzelne Aktionen an Geschäftsdatensätzen ermöglichen.

Ein nützliches Ereignis sollte genug Kontext enthalten, um später interpretiert werden zu können. Das veröffentlichte Schema für Audit-Ereignisse von GitLab liefert eine starke Vergleichsbasis: Identität des Autors, Zeitstempel des Ereignisses, Identifikation und Typ der Entität, Ereignistyp, eine eindeutige Ereignis-ID und zusätzliche Details. Ihre ausgewählte Anwendung muss nicht dasselbe Schema verwenden, aber ihre Aufzeichnungen sollten für Ihre Anforderungen gleichwertige Fragen beantworten.

• Erfolgreiche und fehlgeschlagene Authentifizierungsaktivitäten
• Änderungen an Benutzern, Gruppen, Rollen und Berechtigungen
• Erstellung, Aktualisierung und Löschung sensibler oder regulierter Datensätze, soweit erforderlich
• Zugriff auf oder Nutzung von Datensätzen, wenn Richtlinie oder Risiko dies erfordern
• Exporte, Downloads, Importe, Massenänderungen und Freigabeaktionen
• Administrative Konfigurationsänderungen
• Änderungen an Integrationen, API-Tokens, Webhooks oder Konnektoren
• Administrative Aktionen über Benutzeroberflächen und APIs, sofern zutreffend

Dokumentation, Konfiguration und Beweiskette verifizieren

Eine Funktionsseite eines Anbieters reicht nicht aus. Lesen Sie die offizielle Administrator-Dokumentation für das konkrete Bereitstellungsmodell, das Sie in Betracht ziehen, und prüfen Sie anschließend die Konfigurationsstandards sowie die daraus resultierenden Aufzeichnungen in einem Test. Behandeln Sie jede Unbekannte als Lücke, bis die Dokumentation des Anbieters oder Ihr Test sie aufklärt.

Stellen Sie zuerst die Ereignisabdeckung fest. Welche Aktionen erzeugen Ereignisse? Werden sowohl erfolgreiche als auch erfolglose Aktionen erfasst, wenn dies erforderlich ist? Sind Aktionen gewöhnlicher Benutzer, administrative Aktionen und API-Aktionen jeweils getrennt abgedeckt? Können Ereigniskategorien aktiviert oder deaktiviert werden?

Prüfen Sie anschließend die Qualität der Aufzeichnungen. Stellen Sie fest, ob die Aufzeichnung einen Akteur konsistent identifiziert, einen eindeutigen Zeitstempel und eine Zeitzone oder einen Zeitstandard enthält, die betroffene Entität identifiziert, Aktionstyp und Ergebnis erfasst und eine eindeutige Kennung oder Korrelationsinformationen beinhaltet. Klären Sie außerdem, wie das System Dienstkonten, Automatisierung und anonyme Aktivitäten darstellt. Ein Ereignis, das nur „API“ oder „System“ zugeschrieben wird, kann für die Verantwortlichkeit unzureichend sein, sofern es nicht mit einer stärkeren Identitätsquelle korreliert werden kann.

Überprüfen Sie dann Abruf- und Lebenszyklusverhalten. Prüfen Sie durchsuchbare Felder, Filter, Paginierung, Exportformate, API-Zugriff und mögliche Funktionen zum Streaming von Ereignissen. GitLab dokumentiert eine Filterung nach Akteur und Datumsbereich, weist jedoch darauf hin, dass die Textsuche in Audit-Ereignisdetails in seiner Oberfläche nicht unterstützt wird; für umfassende Suche und Analyse empfiehlt GitLab externes Streaming. Deshalb sollten „in der Benutzeroberfläche sichtbar“ und „untersuchungsfähige Suche“ getrennte Zeilen im Arbeitsblatt sein.

Bewerten Sie abschließend den Schutz. NIST AU-9 behandelt den Schutz von Audit-Informationen und Audit-Logging-Werkzeugen vor unbefugtem Zugriff, Änderung und Löschung als eigenständiges Ziel. Ein Log, das ein gewöhnlicher Administrator unbemerkt ändern oder löschen kann, wird nicht allein dadurch unveränderlich, dass es existiert.

• Abdeckung: Welche erforderlichen Aktionen werden erfasst und welche nicht?
• Akteur: Wird der menschliche Benutzer, das Dienstkonto oder der Administrator zuverlässig identifiziert?
• Zeit: Gibt es eine präzise Ereigniszeit, und können Aufzeichnungen systemübergreifend korreliert werden?
• Objekt: Identifiziert die Aufzeichnung den betroffenen Datensatz, das Konto, die Einstellung oder die Entität?
• Ergebnis und Details: Erfasst sie Erfolg, Fehler und genügend Kontext, um die Aktion zu verstehen?
• Suche: Können Prüfer nach Akteur, Objekt, Ereignistyp und Zeitraum filtern? Ist Detailtext bei Bedarf durchsuchbar?
• Export: Können Aufzeichnungen über eine unterstützte Schnittstelle in einem nützlichen Format exportiert oder abgerufen werden?
• Aufbewahrung: Ist die Speicherung aktiviert, wie lange werden Ereignisse aufbewahrt und wer kann sie verändern oder löschen?","Schutz: Wer kann Aufzeichnungen lesen, verändern oder löschen, und welche unabhängigen Schutzmaßnahmen bestehen?