Einheit 2.3: Activity Logs und der Prüfverlauf
Einführung
Für ein reguliertes Unternehmen ist die Audit-Trail keine operative Bequemlichkeit, sondern Beweismaterial, und Beweismaterial muss jede 35-Tage-Frist überdauern und manipulationsfest sein. Das IONOS Activity Log ist absichtlich eng gefasst: es sagt Ihnen, wer was innerhalb eines Vertrags getan hat, es kann nicht geändert werden und es speichert nur 35 Tage. Diese Einschränkungen sind keine Lücken, über die man sich beschweren kann, sondern sie definieren das Design. Die Audit-Architektur, die einen BSI- oder GDPR-Prüfer zufriedenstellt, ist um das Log herum aufgebaut, nicht innerhalb dessen, indem sie das Retentionsfenster als Exportfrist in unveränderbarem Speicher behandelt. Diese Einheit beschreibt die genaue Form des Logs und dann das externe Retentionsmuster, das FinCorp annehmen muss.
1. Die Feste Form des Aktivitätsprotokolls
Das Aktivitätsprotokoll ermöglicht es Vertragsinhabern und Administratoren, die Historie von Aktionen zu betrachten, die auf Ressourcen innerhalb eines einzelnen Vertrags ausgeführt wurden: Benutzeranmeldungen, Ressourcenbereitstellung, Konfigurationsänderungen, Datenzugriff, Ressourcenabruf, Änderungen und Löschungen. Vier Eigenschaften bestimmen seine Form und treiben jede nachgelagerte Entscheidung an.
- Pro Vertrag. Das Protokoll ist auf einen Vertrag beschränkt und wird pro Vertrag abgefragt, gegen den Endpunkt
https://api.ionos.com/activitylog/v1/contracts/{contractNumber}. Es gibt keine übergreifende Ansicht zwischen Verträgen; ein über mehrere Verträge verteiltes Unternehmen hat mehrere unabhängige Protokolle. - Nur Lesen. Das Protokoll ist aus Gründen der Sicherheit nur lesbar. Einträge können nicht bearbeitet oder gelöscht werden, was das Live-Protokoll als kurzfristige Aufzeichnung vertrauenswürdig macht, aber es bedeutet auch, dass das Protokoll selbst nicht der Ort für langfristige, rechtlich vertretbare Aufbewahrung ist.
- 35-Tage-Aufbewahrung. Einträge werden 35 Tage lang aufbewahrt; Daten, die älter als 35 Tage sind, werden gelöscht. Das Zeitfenster kann nicht nach oben konfiguriert werden, sodass alles, was Sie über 35 Tage hinaus benötigen, das Protokoll vor Ablauf der Frist verlassen muss.
- Nur-GET-Anfragen API. Jeder Aufruf des Aktivitätsprotokolls API ist eine GET-Anfrage. Es gibt keine POST-, PUT- oder DELETE-Anfragen: Sie können nicht darauf schreiben, es nicht ändern und, wichtig, es nicht auffordern, Ereignisse an Sie zu senden. Die Abrufung erfolgt nur durch Abruf, unter Verwendung der Basis-Authentifizierung oder eines Bearer-Tokens, mit Datumsspannen-Filtern (startDate, endDate) und Limit-/Offset-Seitennavigation. Der Zugriff wird durch die Zugriffsrecht für das Aktivitätsprotokoll geregelt, das in Einheit 2.2 behandelt wird.
Die Kombination ist die ganze Geschichte: ein vertrauenswürdiges, aber kurzlebiges, nur-lesbares, einzelnes Vertragsprotokoll. Es eignet sich hervorragend als Quelle der Wahrheit und ist aufgrund seiner Eigenschaften allein nicht als System der Aufzeichnung geeignet.
2. Aggregation und Aufbewahrung extern entwerfen
Da die Plattform weder eine Aggregation zwischen Verträgen noch eine Push-Lieferung bietet, müssen diese Fähigkeiten vom Kunden erstellt werden, und das native Muster komponiert sich um das Protokoll herum, anstatt mehr davon zu erwarten.
Die Aggregation ist ein pull-and-fan-in-Design. Ein geplanter Job (der unter einem eingeschränkten Dienstbenutzer mit dem Recht auf Zugriff auf die Aktivitätsprotokolle und einem kurzlebigen API-Token, pro Einheit 2.2, läuft) ruft das GET-Endpunkt jedes Vertrags in einem komfortablen Abstand innerhalb des 35-Tage-Fensters auf, und leitet die Aufzeichnungen dann an ein zentrales Ziel weiter: ein Object Storage-Archiv, und in der Regel weiter in ein externes SIEM für die Korrelation über Verträge und nicht-IONOS-Quellen hinweg. Die Plattform wird diesen Transfer niemals initiieren, sodass der Zeitplan die Kontrolle ist; wenn der Job stoppt, altert der Beweis stillschweigend nach 35 Tagen ohne Warnung vom Protokoll selbst.
Die langfristige Aufbewahrung ist ein export-before-expiry-Design. Die dokumentierte Empfehlung besteht darin, die Aktivitätsprotokoll-Daten herunterzuladen und auf einem anderen Speichermedium zu speichern, wobei IONOS Cloud Object Storage als explizit empfohlenes Ziel genannt wird. Um dieses Archiv verteidigungsfähig zu machen, verwendet das Ziel-Bucket Object Lock, das WORM-Schutz (write-once-read-many) anwendet, sodass Objekte nicht gelöscht oder modifiziert werden können, während einer bestimmten Aufbewahrungsfrist; die Aktivierung von Object Lock aktiviert automatisch die Bucket-Versionierung, und der Compliance-Modus verhindert, dass die Aufbewahrungsfrist während dieses Zeitraums verkürzt oder das Objekt überschrieben wird. Das Ergebnis ist ein manipulationsicher Archiv, dessen Unveränderlichkeit durch die Speicherschicht erzwungen wird, um den Umstand auszugleichen, dass das Live-Protokoll nur 35 Tage aufbewahrt. Object Lock muss bei der Bucket-Erstellung aktiviert werden (es kann nicht zu einem bestehenden Bucket hinzugefügt werden und kann später nicht deaktiviert werden), sodass das Archiv-Bucket von vornherein entworfen wird und nicht nachträglich angepasst wird.
Für FinCorp macht dies die 35-Tage-Frist zu einer betrieblichen Frist anstelle einer Aufbewahrungsrichtlinie. Ein täglicher Export-Job zieht jedes Vertragsprotokoll in ein deutsches Region-Object Storage-Bucket, das mit Object Lock im Compliance-Modus erstellt wurde, und auf die Aufbewahrungsfrist gesetzt wird, die die Aufsichtsbehörden von FinCorp erfordern (oft Jahre). Das Live-Protokoll bleibt die Arbeitsansicht; das gesperrte Bucket ist das System der Aufzeichnungen. Wenn FinCorp jemals sein Anwesen über Verträge aufteilt, iteriert der gleiche Job einfach mehr Vertragsnummern, da die Aggregation ohnehin immer extern war.
Entscheidungszusammenfassung
Entwerfen Sie die Audit-Trail als kurzlebige Quelle, die ein unveränderliches externes Archiv speist.
| Audit-Anforderung | Was die Aktivitäts-Log Ihnen gibt | Das Design, das Sie hinzufügen müssen |
|---|---|---|
| Wer hat was getan, kürzlich, in einem Vertrag | Pro-Vertrag, schreibgeschütztes Log, 35-Tage-Retention | Verwenden Sie es direkt als Live-Ansicht; gewähren Sie den Zugriff auf die Aktivitäts-Log eng |
| Aufbewahrung über 35 Tage hinaus | Nichts; Daten, die älter als 35 Tage sind, werden gelöscht | Geplante Exportierung zu Object Storage vor Ablauf; behandeln Sie 35 Tage als Frist |
| Manipulationssichere Langzeitbeweise | Schreibgeschütztes Live-Log, aber nur 35 Tage | Object Lock (WORM, Compliance-Modus) auf dem Archiv-Bucket, bei der Erstellung aktiviert |
| Cross-Vertrags- oder korrelierte Audit | Keine Cross-Vertrags-Ansicht, GET-only, kein Push | Ziehen Sie jeden Vertrag und fächern Sie ihn in ein externes SIEM ein; der Zeitplan ist die Kontrolle |
Zusammenfassung
Das Aktivitätsprotokoll ist pro-Vertrag, nur lesbar, 35 Tage lang aufbewahrt und über ein GET-only-, pull-only-API zugänglich, was es zu einer vertrauenswürdigen Kurzzeitquelle macht, aber nie zu einem Langzeitsystem der Aufzeichnungen. Eine Aggregation über Verträge und jede Korrelation sind externe Designs, da die Plattform keine zwischenvertragliche Ansicht und keinen Push bietet. Langfristige, manipulationsbeweisbare Aufbewahrung wird durch Exportieren vor dem 35-Tage-Löschung in einen Object Storage-Bucket erreicht, der mit Object Lock erstellt wurde, sodass das Zeitfenster zu einer Exportfrist wird, anstatt eine Aufbewahrungsobere Grenze darzustellen.
Wichtige Punkte:
- Das Aktivitätsprotokoll ist pro-Vertrag, nur lesbar, 35 Tage lang aufbewahrt und GET-only; Daten, die älter als 35 Tage sind, werden gelöscht und das Zeitfenster kann nicht verlängert werden.
- Es gibt keine zwischenvertragliche Aggregation und keine Push-Lieferung; beide werden vom Kunden als geplante Pull- und Fan-in-Anfrage erstellt, oft in ein externes SIEM.
- Langfristige Aufbewahrung ist ein Export zu 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 Export-Vorgang stoppt, veraltet der Beweis ohne Warnung aus dem Protokoll.
Wichtige Begriffe:
- Aktivitätsprotokoll: Ein pro-Vertrag, nur lesbarer Nachweis von Aktionen auf Ressourcen, 35 Tage lang aufbewahrt und über ein GET-only-API zugänglich.
- Object Lock: WORM-Schutz auf einem Object Storage-Bucket (aktiviert bei der Erstellung, aktiviert automatisch Versionierung), der verhindert, dass Objekte für eine festgelegte Aufbewahrungsfrist gelöscht oder geändert werden; der Compliance-Modus verbietet es, diese Frist zu verkürzen.