Einheit 2.3: Activity Logs und die Audit-Trail
Einführung
Für ein reguliertes Unternehmen ist die Audit-Trail-Protokollierung kein betriebliches Komfortmerkmal, sondern ein Nachweis, und dieser Nachweis muss über ein 35-Tage-Fenster hinaus bestehen bleiben und Manipulationen nachweisbar machen. Das IONOS CLOUD Activity Log ist bewusst eng gefasst: Es zeigt, wer innerhalb eines Vertrags welche Aktion ausgeführt hat, es kann nicht verändert werden und es speichert nur 35 Tage. Diese Einschränkungen sind keine Mängel, über die man sich beklagen sollte; sie definieren das Design. Die Audit-Architektur, die die Anforderungen eines BSI- oder DSGVO-Prüfers erfüllt, wird um das Log herum aufgebaut, nicht innerhalb von ihm, indem dessen Aufbewahrungsfrist als Exportfrist in einen unveränderlichen Speicher behandelt wird. Diese Einheit beschreibt die exakte Struktur des Logs und anschließend das externe Aufbewahrungsmuster, das FinCorp anwenden muss.
1. Die feste Struktur des Aktivitätsprotokolls
Das Aktivitätsprotokoll ermöglicht Vertragsinhabern und Administratoren, den Verlauf der auf Ressourcen innerhalb eines einzelnen Vertrags durchgeführten Aktionen einzusehen: Benutzeranmeldungen, Ressourcenbereitstellung, Konfigurationsänderungen, Datenzugriffe, Ressourcenabrufe, Änderungen und Löschungen. Vier Eigenschaften fixieren seine Struktur und steuern jede nachgelagerte Entscheidung.
- Pro Vertrag. Das Protokoll ist auf einen einzelnen Vertrag beschränkt und wird pro Vertrag abgefragt, gegen den Endpunkt
https://api.ionos.com/activitylog/v1/contracts/{contractNumber}. Es gibt keine übergreifende Ansicht über mehrere Verträge hinweg; eine Organisation, die sich über mehrere Verträge erstreckt, verfügt über mehrere unabhängige Protokolle. - Nur lesbar. Das Protokoll ist nach Design nur lesbar. Einträge können von niemandem bearbeitet oder gelöscht werden. Das macht das Live-Protokoll als kurzfristiges Aufzeichnungsmittel vertrauenswürdig, bedeutet aber auch, dass das Protokoll selbst nicht der Ort ist, an dem eine langfristige, rechtlich vertretbare Aufbewahrung stattfindet.
- Aufbewahrungsdauer von 35 Tagen. Einträge werden 35 Tage aufbewahrt; Daten, die älter als 35 Tage sind, werden gelöscht. Der Zeitraum kann nicht nach oben hin konfiguriert werden, sodass alles, was über 35 Tage hinaus benötigt wird, das Protokoll verlassen muss, bevor es abläuft.
- Nur GET-API. Jeder Aufruf der Activity Log API ist ein GET. Es gibt kein POST, PUT oder DELETE: Sie können nicht darauf schreiben, es nicht verändern und, was wichtig ist, es nicht auffordern, Ereignisse an Sie zu senden. Der Abruf erfolgt ausschließlich per Pull, mit Basic Authentication oder einem Bearer Token, mit Datumsbereichsfiltern (startDate, endDate) und limit/offset-basierter Paginierung. Der Zugriff wird durch das Berechtigungsfeld Access Activity Log geregelt, das in Einheit 2.2 behandelt wird.
Die Kombination ist die gesamte Geschichte: ein vertrauenswürdiges, aber kurzlebiges, nur per Pull abrufbares, auf einen einzelnen Vertrag beschränktes Aufzeichnungsmittel. Es ist hervorragend als Quelle der Wahrheit geeignet, aber an sich nicht als System of record.
2. Externe Gestaltung von Aggregation und Aufbewahrung
Da die Plattform weder eine Aggregation über Verträge hinweg noch eine Push-Übermittlung bietet, liegt die Umsetzung beider Funktionen beim Kunden. Das native Muster ist um das Protokoll herum aufgebaut und erwartet darüber hinaus nichts von ihm.
Die Aggregation folgt einem Pull- und Fan-in-Design. Ein geplanter Job (ausgeführt unter einem Service-Benutzer mit eingeschränktem Bereich, der das Recht für das Access Activity Log besitzt und ein kurzlebiges API-Token verwendet, gemäß Einheit 2.2) ruft das GET-Endpunkt jedes Vertrags mit einer Frequenz auf, die sich mit ausreichend Puffer innerhalb des 35-Tage-Fensters bewegt. Anschließend leitet er die Datensätze an ein zentrales Ziel weiter: ein Object Storage-Archiv und typischerweise weiter an ein externes SIEM zur Korrelation über Verträge hinweg und mit Quellen außerhalb von IONOS CLOUD. Die Plattform wird diese Übertragung niemals initiieren, daher ist der Zeitplan die Steuerungsebene. Wenn der Job stoppt, veraltet der Nachweis stillschweigend nach 35 Tagen, ohne dass das Protokoll selbst einen Alarm auslöst.
Die Langzeitaufbewahrung folgt einem Export-vor-Ablauf-Design. Die dokumentierte Empfehlung lautet, die Daten des Activity Log herunterzuladen und auf einem anderen Speicher abzuspeichern, wobei IONOS Cloud Object Storage als ausdrücklich empfohlenes Ziel genannt wird. Um dieses Archiv verteidigungsfähig zu gestalten, verwendet der Ziel-Bucket Object Lock. Diese Funktion wendet WORM-Schutz (write-once-read-many) an, sodass Objekte für eine festgelegte Aufbewahrungsdauer nicht gelöscht oder verändert werden können. Die Aktivierung von Object Lock aktiviert automatisch die Bucket-Versionierung, und der Compliance-Modus verhindert, dass die Aufbewahrungsperiode verkürzt oder das Objekt während dieser Zeit überschrieben wird. Das Ergebnis ist ein manipulationsnachweisbares Archiv, dessen Unveränderbarkeit durch die Speicherschicht erzwungen wird. Dies kompensiert die Tatsache, dass das aktive Protokoll nur 35 Tage aufbewahrt. Object Lock muss bei der Bucket-Erstellung aktiviert werden (es kann nicht zu einem bestehenden Bucket hinzugefügt und später nicht deaktiviert werden). Daher wird der Archiv-Bucket von vornherein konzipiert, nicht nachgerüstet.
Für FinCorp macht dies die 35-Tage-Frist zu einer operativen Deadline und nicht zu einer Aufbewahrungsrichtlinie. Ein täglicher Export-Job zieht das Protokoll jedes Vertrags in einen Object Storage-Bucket in einer deutschen Region, der mit Object Lock im Compliance-Modus erstellt wurde und auf die von den Regulierungsbehörden von FinCorp geforderte Aufbewahrungsperiode (oft mehrere Jahre) eingestellt ist. Das aktive Protokoll bleibt die Arbeitsansicht; der gesperrte Bucket ist das System der Aufzeichnungen. Sollte FinCorp seinen Bestand je über Verträge hinweg aufteilen, iteriert derselbe Job einfach über mehr Vertragsnummern, da die Aggregation ohnehin immer extern erfolgen sollte.
Zusammenfassung der Entscheidung
Gestalten Sie den Audit Trail als kurzlebige Quelle, die ein unveränderliches externes Archiv versorgt.
| Audit-Anforderung | Was das Activity Log bereitstellt | Das von Ihnen hinzuzufügende Design |
|---|---|---|
| Wer hat kürzlich was in einem Vertrag getan | Verbandsweises, schreibgeschütztes Protokoll, 35-Tage-Aufbewahrung | Verwenden Sie es direkt als Live-Ansicht; erteilen Sie Access Activity Log gezielt |
| Aufbewahrung über 35 Tage hinaus | Nichts; Daten älter als 35 Tage werden gelöscht | Geplanter Export nach Object Storage vor Ablauf; behandeln Sie 35 Tage als Frist |
| Manipulationssichere langfristige Beweise | Schreibgeschütztes Live-Protokoll, aber nur 35 Tage | Object Lock (WORM, Compliance-Modus) im Archiv-Bucket, bei der Erstellung aktiviert |
| Verbandsübergreifende oder korrelierte Audits | Keine verbandsübergreifende Ansicht, nur GET, kein Push | Rufen Sie jeden Vertrag ab und leiten Sie sie an ein externes SIEM weiter; der Zeitplan ist die Steuerung |
Zusammenfassung
Das Activity Log ist vertragsspezifisch, schreibgeschützt, wird 35 Tage aufbewahrt und über eine nur-GET-, nur-Pull-API bereitgestellt. Dadurch ist es eine vertrauenswürdige Kurzzeitquelle, aber niemals ein langfristiges System of Record. Aggregation über Verträge hinweg und jegliche Korrelation sind externe Designs, da die Plattform keine übergreifende Vertragsansicht und keinen Push bietet. Langfristige, manipulationsevidente Aufbewahrung wird erreicht, indem Daten vor dem 35-Tage-Purge in einen Object Storage-Bucket exportiert werden, der mit Object Lock erstellt wurde. Dadurch wird das Zeitfenster zu einer Exportfrist und nicht zu einer Aufbewahrungsgrenze.
Wichtige Punkte:
- Das Activity Log ist vertragsspezifisch, schreibgeschützt, wird 35 Tage aufbewahrt und ist nur-GET; Daten, die älter als 35 Tage sind, werden gelöscht, und das Zeitfenster ist nicht erweiterbar.
- Es gibt keine übergreifende Vertragsaggregation und keine Push-Übermittlung; beides wird vom Kunden als geplanter Pull- und Fan-in-Prozess aufgebaut, häufig in ein externes SIEM.
- Langfristige Aufbewahrung ist ein Export in Object Storage mit Object Lock (WORM); der Compliance-Modus macht das Archiv unveränderlich, und Object Lock muss bei der Bucket-Erstellung aktiviert werden.
- Behandeln Sie 35 Tage als harte Exportfrist: Wenn der Exportjob stoppt, veraltet die Evidenz ohne Warnung aus dem Log.
Wichtige Begriffe:
- Activity Log: Ein vertragsspezifisches, schreibgeschütztes Protokoll von Aktionen auf Ressourcen, das 35 Tage aufbewahrt wird und über eine nur-GET-API abgerufen wird.
- Object Lock: WORM-Schutz für einen Object Storage-Bucket (wird bei der Erstellung aktiviert, aktiviert automatisch die Versionierung), der verhindert, dass Objekte für einen festgelegten Aufbewahrungszeitraum gelöscht oder geändert werden; der Compliance-Modus verbietet die Verkürzung dieses Zeitraums.