Aufbewahrung von KI-Agentenaktivitäten: Belege, denen Ermittler vertrauen

KI-Agenten machen aus einem bekannten Protokollierungsproblem ein Beweisproblem. Ein Mensch verbringt vielleicht einen Nachmittag damit, sich durch eine Anwendung zu klicken. Ein Agent kann in derselben Zeit zahlreiche externe Aufrufe ausführen, während ein Entwickler noch die Zusammenfassung liest. Wenn im Protokoll nur steht «Agent hat die Aufgabe abgeschlossen», kann es die Fragen nach einer versehentlichen Löschung, einer unerwarteten Änderung in der Produktionsumgebung oder einer strittigen Übertragung nicht beantworten.

Gute Aufbewahrungsregeln sichern die Fakten, die zur Rekonstruktion einer Aktion nötig sind, ohne eine zweite, schlecht geschützte Kopie jedes Geheimnisses und jedes Kundendatensatzes anzulegen, mit dem der Agent in Kontakt kam. Dieser Unterschied bestimmt, was du sammelst, wie lange du es aufbewahrst, wer es ändern darf und wann die Löschung gestoppt werden muss.

Die Aufbewahrung beginnt mit der Frage der Untersuchung

Ein Aktivitätsdatensatz rechtfertigt seinen Speicherplatz erst, wenn er eine absehbare Untersuchungsfrage beantwortet. Beginne mit den Fragen, nicht mit einer Standardzahl von Tagen, die aus einem anderen Produkt übernommen wurde.

Bei einem Agenten, der eine HTTP-API aufrufen oder eine SSH-Sitzung öffnen kann, müssen Ermittler meist fünf Dinge klären:

• Welche Ausführungsidentität hat die Anfrage gestellt, und welcher Mensch oder Dienst hat den Lauf autorisiert?
• Welche Fähigkeit wollte der Agent verwenden und an welches Ziel?
• Welche Operation sollte das Ziel ausführen?
• Was war das Ergebnis, einschließlich Ablehnung, Zeitüberschreitung, Teilerfolg oder Fehler beim entfernten Dienst?
• Kann das Team zeigen, dass der Datensatz nach dem Ereignis nicht unbemerkt bearbeitet wurde?

Diese Fragen trennen Aktionsbelege von Betriebsrauschen. Ein CPU-Diagramm kann helfen, eine Zeitüberschreitung zu erklären. Es belegt aber nicht, ob ein Agent DELETE /customers/42 ausgeführt hat. Ein Prompt-Transkript kann erklären, warum der Agent eine Löschung für angemessen hielt. Es beweist jedoch nicht, dass die Anfrage den entfernten Dienst erreicht hat.

NIST Special Publication 800-92, Guide to Computer Security Log Management, beschreibt Log-Management als Lebenszyklus: Logs erzeugen, übertragen, speichern, analysieren und entsorgen. Der nützliche Teil dieser Empfehlung ist keine magische Aufbewahrungsdauer. Entscheidend ist, dass eine Organisation den Zweck ihrer Logs festlegt und Speicher, Zugriff und Entsorgung berücksichtigt. Teams, die Agenten betreiben, springen oft direkt zur Sammlung, weil sie einfach ist. Zugriff und Entsorgung entscheiden später darüber, ob diese Datensätze helfen oder schaden.

Formuliere für jede Datensatzklasse eine Untersuchungsabsicht. Zum Beispiel: «Wir bewahren Aktionsergebnisse so lange auf, dass wir eine unbefugte externe Änderung nach der normalen Erkennung und ersten Untersuchung identifizieren und rekonstruieren können.» Diese Aussage zwingt zu einer sinnvollen Entscheidung über Zeitraum und Felder. «Alle Agenten-Logs für immer aufbewahren» umgeht die Diskussion und erzeugt einen dauerhaften Haufen sensibler Daten.

Ein Datensatz kann mehr als einem Zweck dienen, aber nenne die Zwecke getrennt. Sicherheitsuntersuchung, Incident Response, Kundensupport, Debugging von Releases, Abgleich der Abrechnung und Compliance benötigen möglicherweise unterschiedliche Fakten und Zeiträume. Wenn ein wenig wertvoller Debugging-Zweck jahrelang einen vollständigen Payload aufbewahrt, ist die Aufbewahrungsrichtlinie gescheitert.

Ein Aktionsdatensatz braucht Kontext, kein Transkript

Die Aufbewahrung von KI-Agentenaktivitäten hängt zuerst vom Ereignisschema ab. Erfasse die kleinste Menge an Fakten, mit der ein kompetenter Ermittler die Aktion rekonstruieren und mit einer Sitzung verknüpfen kann, ohne Zugangsdaten oder irrelevante Inhalte aufzubewahren.

Ich verwende vier Informationsschichten.

1. Identität und Autorisierungskontext. Erfasse eine unveränderliche Ereignis-ID, einen Zeitstempel mit Zeitzone, die Prozess-ID des Agenten, den Pfad der ausführbaren Datei oder die Paketidentität, die Codesignaturinstanz, sofern das Betriebssystem sie bereitstellt, die Sitzungs-ID sowie die mit der Sitzung verbundene Identität des Genehmigers oder Dienstes. Halte die Autorisierungsentscheidung und den verwendeten Freigabemodus fest.
2. Angeforderte Aktion. Erfasse Kanal, Ziel-Host, gegebenenfalls den Port, HTTP-Methode und normalisierte Route oder SSH-Befehlsklasse, die Zugangsdatenreferenz sowie eine sichere Beschreibung der angeforderten Operation.
3. Beobachtetes Ergebnis. Erfasse Erfolg, Ablehnung, Abbruch, Zeitüberschreitung, Transportfehler, gegebenenfalls den Statuscode des entfernten Dienstes, die Antwortklassifizierung, gesendete und empfangene Bytes, falls relevant, sowie eine redigierte Fehlerzusammenfassung.
4. Beweisverknüpfungen. Erfasse den Hash des vorherigen Datensatzes, den Hash des aktuellen Datensatzes, die Schemaversion sowie IDs, die zusammengehörige Versuche, Wiederholungen und Folgeaktionen verbinden.

Der Unterschied zwischen Ziel und Anfrage ist wichtig. api.example.internal ist ein Ziel. PATCH /v1/users/42 ist eine Aktion. Ein Log, das nur den Host enthält, kann eine Abfrage des Zugangsdatenbestands nicht von der Deaktivierung eines Kontos unterscheiden. Ein Log, das nur einen Pfad speichert, kann die Zielumgebung auslassen. Oft entscheidet genau sie darüber, ob es sich um einen harmlosen Test oder einen Vorfall handelt.

Normalisiere die Daten vor dem Speichern. Lege variable IDs in strukturierte Felder und zwinge Ermittler nicht, Freitext zu analysieren. Speichere neben einem geschützten Feld target_identifier, falls die ID wichtig ist, etwa route_template: "/v1/users/{user_id}". Unterscheide bei SSH zwischen dem vom Agenten übergebenen Befehl und dem entfernten Befehl nach der Shell-Erweiterung, wenn dein Ausführungspfad beide beobachten kann. Behaupte keine Sicherheit, die du nicht hast.

Ein praktischer JSON-Datensatz kann so aussehen:

{
  "event_id": "01J8...",
  "occurred_at": "2025-03-08T14:22:31.482Z",
  "session_id": "ses_7f...",
  "actor": {
    "process_id": 18422,
    "signing_authority": "Developer ID Application: Example Developer"
  },
  "authorization": {
    "decision": "approved",
    "mode": "session"
  },
  "action": {
    "channel": "http",
    "destination": "billing.internal:443",
    "operation": "POST /v2/invoices/{invoice_id}/void",
    "credential_ref": "billing-production"
  },
  "outcome": {
    "status": "remote_rejected",
    "http_status": 403,
    "error_class": "authorization"
  },
  "previous_hash": "...",
  "record_hash": "..."
}

Dieser Datensatz enthält weder das Bearer-Token noch einen Autorisierungs-Header oder den Rechnungstext. Trotzdem zeigt er, dass ein bestimmter signierter Prozess während einer genehmigten Sitzung mit einer bestimmten Zugangsdatenreferenz eine Stornierung in der Produktion versucht hat und eine 403-Antwort erhielt.

Verstecke risikoreiche Felder nicht in einem details-Block. Freiformblöcke werden schnell zu Sammelstellen für Prompts, Header, personenbezogene Daten und Fehlerausgaben. Außerdem lässt sich ihre Aufbewahrung nicht nach Klasse steuern. Wenn ein Feld einen Grund für seine Existenz hat, gib ihm einen Namen, eine Klassifizierung, eine Zugriffsgruppe und eine Löschregel.

Beweisklassen unterschiedlich lange aufbewahren

Eine einzige Dauer für jeden Agentendatensatz ist leicht zu erklären und im Betrieb meist falsch. Bewahre kompakte Aktionsbelege länger auf als umfangreiche Diagnoseinhalte. Der kompakte Datensatz kann zeigen, was geschah, ohne die Angriffsfläche unnötig zu vergrößern.

Verwende Klassen, die zur tatsächlichen Untersuchungsarbeit passen. Ein sinnvoller Ausgangspunkt ist:

Die Tabelle ist eine Methode, keine Aussage, dass jedes Team jede Klasse braucht. Wenn der Agent nur den Build-Status liest, gibt es möglicherweise keinen Grund für eine geschützte Payload-Klasse. Wenn er Finanzdaten ändert, kann ein Aktionsjournal ohne exakte Ziel-ID zu wenig Informationen enthalten.

Vermeide die verbreitete Empfehlung, rohe Anfragen und Antworten «für alle Fälle» aufzubewahren. Sie ist beliebt, weil frühes Debugging dadurch bequem wird und Speicher billig wirkt. Speicher ist nicht der schwierige Teil. Suchzugriff, Umfang eines Datenlecks, Auskunftsanfragen, verlässliche Löschung und versehentlich erfasste Geheimnisse sind die teuren Teile.

Bewahre einen kryptografischen Digest eines Inhalts auf, wenn du nachweisen musst, dass ein bestimmter Inhalt verwendet wurde, ohne ihn selbst zu speichern. Ein Digest erklärt die Bedeutung nicht und hilft nicht, wenn der ursprüngliche Inhalt auch an keiner anderen Stelle mehr vorhanden ist. Verwende ihn zur Korrelation und zum späteren Vergleich, nicht als Ersatz für eine Beschreibung der Aktion.

Bewahre fehlgeschlagene und abgelehnte Versuche auf. Ablehnungen zeigen oft, dass ein Agent die falsche Fähigkeit ausprobiert, ein Freigabepfad defekt ist oder ein kompromittierter Prozess Grenzen testet. Bei sehr hoher Anzahl kann für sie ein anderer Zeitraum gelten als für erfolgreiche Aktionen. Lösche sie aber nicht zuerst, nur weil «nichts passiert» ist. Damit entfernst du Kontext, den Ermittler nach einem erfolgreichen Versuch brauchen.

Den Zeitraum aus Erkennung und Reaktion ableiten

Lege die Aufbewahrungsdauer fest, indem du vom spätesten Zeitpunkt zurückrechnest, an dem du ein Ereignis noch untersuchen willst. Die Rechnung ist nicht elegant, macht aber die Annahmen sichtbar.

Addiere für eine Datensatzklasse:

• die längste glaubwürdige Zeit bis zur Erkennung;
• die Zeit, um eine Untersuchung zu eröffnen, ihren Umfang zu bestimmen und sie zuzuweisen;
• die Zeit, um zusammengehörige Datensätze von Zielsystemen oder Anbietern zu erhalten;
• alle vertraglichen, regulatorischen oder rechtlichen Pflichten, die für diese Klasse gelten;
• einen angemessenen Puffer für verspätete Meldungen und Abweichungen bei den Uhren.

Angenommen, ein Team entdeckt eine verdächtige Aktion in der Produktion bei einer monatlichen Prüfung, braucht zwei Wochen zur Bestätigung des Umfangs und möglicherweise einen Monat, um die Historie eines entfernten Dienstes zu beschaffen. Eine Aufbewahrung von 30 Tagen ist dann bereits gescheitert, bevor die Untersuchung beginnt. Die richtige Antwort ist nicht automatisch ein Zeitraum von mehreren Jahren. Das Team sollte eine Frist wählen, die seine tatsächliche Erkennungs- und Reaktionspraxis abdeckt, und sie anschließend an den Pflichten der betroffenen Rechtsordnungen und Verträge prüfen.

Trenne die Regel von der Ausnahme. Der normale Zeitplan sollte Datensätze automatisch löschen. Ein Fall-Hold bewahrt eine definierte Menge von Datensätzen wegen eines aktiven Vorfalls, eines Streits, eines Audits oder einer rechtlichen Anweisung. Nach Ende des Holds muss die Löschung gemäß Richtlinie wieder anlaufen. Die Daten dürfen nicht unbegrenzt liegen bleiben, nur weil sich niemand an sie erinnert.

Verwechsle die Aufbewahrung von Backups nicht mit der von Logs. Ein Datenbank-Backup, das gelöschte Aktivitätsdatensätze enthält, kann sie verfügbar halten, lange nachdem die Anwendung ihre Löschung meldet. Dokumentiere, ob Backups verschlüsselt sind, wer sie wiederherstellen darf, wie lange sie bestehen und ob eine Wiederherstellung gelöschte Datensätze zurückbringen könnte. Wenn sich einzelne Datensätze aus unveränderlichen Backups nicht entfernen lassen, muss die Richtlinie das ausdrücklich sagen und die Backup-Frist entsprechend festlegen.

Bei Systemen mit personenbezogenen Daten solltest du vor der Festlegung einer Frist die Rechtsberatung und den Datenschutzverantwortlichen einbeziehen. Datenschutzrecht nennt normalerweise keine allgemeingültige Zahl, die für Agentenaktivitäten passt. Es verlangt aber Zweckbindung, Datenminimierung und eine begründbare Löschung. Eine vage Begründung mit «Sicherheit» rechtfertigt nicht, vollständige Inhalte für immer aufzubewahren.

Manipulationsnachweise brauchen eine eigene Vertrauensgrenze

Ein Datensatz, den derselbe Administrator schreiben und löschen kann, bietet nach einem schweren Vorfall wenig Sicherheit. Schutz vor Änderungen braucht sowohl vorbeugende Maßnahmen als auch Belege für spätere Änderungen.

NIST SP 800-53, Kontrolle AU-9, fordert den Schutz von Audit-Informationen vor unbefugtem Zugriff, Änderung und Löschung. Das ist wichtig, weil scheinbar unveränderlicher Speicher allein keine Zugriffskontrolle ersetzt und Zugriffskontrolle allein nicht jede unzulässige Änderung sichtbar macht. Baue beide Ebenen ein.

Erstens müssen Aktionsausführung und Audit-Administration getrennt sein. Der Prozess, der ein Ereignis aufzeichnet, sollte nur Anhängeberechtigung und keine weitreichende Berechtigung zum Umschreiben oder Löschen der Historie haben. Administratoren für die Aufbewahrung sollten einzelne Ereignisse nicht beiläufig bearbeiten können. Verwende für Löschung und Korrektur einen eigenen, auditierbaren Prozess.

Zweitens verknüpfe die Datensätze zu einer geordneten Kette. Jeder Datensatz enthält den Hash seines Vorgängers und den Hash seines kanonischen Inhalts. Wer ein altes Ereignis ändert, unterbricht die Kette an diesem Ereignis und an jedem folgenden Link, sofern nicht die gesamte betroffene Folge neu erzeugt wird. Hashverkettung ist nützlich, hat aber eine Grenze: Wer den Schreiber und jede gespeicherte Kopie kontrolliert, kann die gesamte Kette neu schreiben. Exportiere signierte Checkpoints an einen unabhängigen Ort oder vergleiche Checkpoints in einem Prozess außerhalb der Kontrolle des Schreibers.

Drittens muss die Zeit geschützt werden. Systemuhren gehen auseinander und können von Angreifern verändert werden. Erfasse die Eingangszeit im Collector, verwende nach Möglichkeit monotone Sequenznummern und behandle Zeitstempel als Belege, die mit externen Datensätzen verglichen werden müssen, nicht als alleinige Wahrheit. RFC 3161 definiert ein Protokoll für vertrauenswürdige Zeitstempel. Es kann den Nachweis stärken, dass ein Digest zu einem bestimmten Zeitpunkt existierte, beweist aber weder die Richtigkeit noch die Autorisierung des Anfrageinhalts.

Viertens muss die Integrität geprüft werden, statt sie nur zu behaupten. Ein Prüfkommando sollte die erste fehlerhafte Sequenz, den erwarteten Vorgänger-Hash, den beobachteten Vorgänger-Hash und die Datensatz-ID ausgeben. Dieses Format liefert dem Betreiber verwertbare Informationen:

$ audit verify activity.log
records_checked: 18427
chain_status: valid
first_error: none
checkpoint_status: matched

Wenn die Prüfung fehlschlägt, sichere den betroffenen Speicher, bevor jemand ihn «repariert». Prüfe eine Kopie der Daten, sichere die Ausgabe, ermittle den letzten gültigen Checkpoint und vergleiche ihn mit unabhängigen Exporten. Wer zuerst die Kette repariert, kann Belege über die Änderung selbst zerstören.

Ein plausibler Fehler zeigt, was dünne Logs verbergen

Stell dir einen Coding-Agenten vor, der für eine Entwicklungsaufgabe berechtigt wird und später einen HTTP-Aufruf an einen Produktionsdienst für Abrechnungen versucht. Das Aktions-Gateway weist den Aufruf zurück, weil die Sitzungsautorisierung einen anderen Prozess abdeckt als den, der die Anfrage stellt. Einige Minuten später versucht ein Entwickler den Aufruf in einem anderen Agentenlauf erneut und genehmigt ihn, ohne das Produktionsziel zu bemerken.

Der entfernte Dienst antwortet mit 200. Im Chat-Transkript steht nur, der Agent habe «ein Rechnungsproblem gelöst». Drei Wochen später erfährt das Team von einer Kundenbeschwerde.

Bei einem schwachen Datensatz findet das Team einen erfolgreichen Aufruf von einem unbekannten Konto «agent» und einen allgemeinen Zeitstempel. Es kann nicht feststellen, ob der erste abgelehnte Aufruf vom selben ausführbaren Programm kam, ob die Freigabe in derselben Sitzung erfolgte, welcher Schlüssel ausgewählt wurde, welche Rechnung betroffen war oder ob jemand den Datensatz nach der Beschwerde verändert hat. Am Ende durchsucht es Shell-Historien, Chat-Exporte und Logs des entfernten Dienstes, die möglicherweise kürzer aufbewahrt werden als die eigenen Daten.

Mit einem brauchbaren Datensatz kann der Ermittler die Abfolge rekonstruieren:

1. Ein signierter Prozess startete eine Sitzung und erhielt eine an diesen Lauf gebundene Freigabe.
2. Ein Prozess mit anderer Identität versuchte die Produktionsoperation und erhielt eine Ablehnung.
3. Eine spätere Sitzung verwendete eine bestimmte Zugangsdatenreferenz, zielte auf den Produktions-Host, forderte eine Stornierung einer Rechnung anhand einer geschützten ID an und erhielt das Ergebnis 200.
4. Die Aktivitätskette stimmt mit einem vor der Beschwerde erstellten Checkpoint überein.

Das beweist nicht, ob der Entwickler die Aktion beabsichtigt hat. Es zeigt aber, welcher Prozess freigegeben wurde, was der Ausführungspfad tat und wo die weitere Untersuchung ansetzen muss. Audit-Datensätze sollten nicht versuchen, Motive zu erzählen. Sie sollten Fakten sichern, anhand derer Menschen Motive später bewerten können.

Speichere über Wiederholungen hinweg eine Korrelations-ID, fasse die Versuche aber nicht zu einem einzigen abschließenden Erfolgsdatensatz zusammen. Wiederholungen können ein anderes Ziel, einen Wechsel der Zugangsdaten oder einen Grenztest vor einer erlaubten Aktion zeigen. Diese Details sind wichtig, wenn die abschließende Anfrage einen Schaden verursacht hat.

Redigieren, bevor Datensätze ins Journal gelangen

Ein verschlüsselter Audit-Speicher schützt Daten im Ruhezustand. Das macht es aber nicht akzeptabel, Passwörter, Zugriffstokens, Sitzungscookies, private Schlüssel oder vollständige Kundenobjekte zu protokollieren. Sobald rohe Inhalte mit langer Aufbewahrung in ein Journal gelangen, tragen jeder künftige Ermittler, jeder Betreiber einer Wiederherstellung und jeder Bearbeiter eines Datenlecks dieses Risiko weiter.

Erstelle für jeden Kanal eine Positivliste von Feldern. Bei HTTP können Methode, Ziel, Routenvorlage, ausgewählte sichere Namen von Query-Parametern, Inhaltslänge, Status und Fehlerklasse erlaubt werden. Authorization, Cookie, Set-Cookie, API-Tokens, Client-Geheimnisse und bekannte sensible Header müssen ausdrücklich verworfen werden. Behandle Anfrage- und Antwortkörper standardmäßig als verboten.

Eine Redigierung, die nur auf Mustererkennung beruht, übersieht neue Formate von Geheimnissen und kann Belege beschädigen. Verwende zuerst strukturelle Kontrollen: Felder, die niemals vorhanden sein sollten, dürfen gar nicht erst eingelesen werden. Setze Musterredigierung als zweite Barriere für Fehlertexte oder von entfernten Diensten gelieferte Daten ein. Speichere die Redigierungsversion am Ereignis, damit Ermittler wissen, welche Regeln angewendet wurden.

Für personenbezogene Daten gilt dieselbe Disziplin. Eine Konto-ID kann nötig sein, um das betroffene Objekt zu bestimmen. Ein vollständiges Profil, Dokument oder Support-Transkript gehört selten in ein allgemeines Aktionsjournal. Pseudonymisierung kann die routinemäßige Offenlegung reduzieren. Nenne eine stabile, umkehrbare ID aber nicht anonym. Wenn jemand mit einer zweiten Tabelle die Identität wiederherstellen kann, bleibt sie für Governance-Zwecke ein personenbezogenes Datum.

Wenn ein Fall tatsächlich Inhalte erfordert, erstelle eine eng begrenzte Beweiserfassung mit Fall-ID, benannter Zugriffsgruppe, Ablaufdatum und Prüftermin. Vermerke im Aktionsjournal, dass diese Erfassung existiert, kopiere ihren Inhalt aber nicht in jeden nachgelagerten Bericht. So bleiben normale Untersuchungen nützlich, ohne allen Lesern Zugriff auf besonders sensible Inhalte zu geben.

Löschungen, Holds und Korrekturen brauchen eigene Belege

Aufbewahrung ist ein Betriebsprozess, kein Absatz in einer Sicherheitsrichtlinie. Ein Zeitplan, den niemand testet, führt irgendwann zu versehentlich dauerhafter Speicherung oder zu einer automatischen Löschung während eines Vorfalls.

Führe Löschungen über einen protokollierten Job aus. Bewahre für jeden Lauf Richtlinienversion, Datensatzklasse, ausgewählten Zeitraum, Anzahl gelöschter Datensätze, Anzahl wegen Holds übersprungener Datensätze, Identität des Ausführenden und Ergebnis auf. Der Löschjob sollte dieselbe Anhänge-Disziplin wie die Aktionsaufzeichnung verwenden. Ein Betreiber sollte keinen direkten Datenbankzugriff benötigen, um Datensätze «aufzuräumen».

Ein Hold braucht einen Umfang, den eine Maschine anwenden kann. Definiere ihn über Fall-ID und Ereigniszeitraum, Sitzungs-ID, Ziel, Akteursidentität oder einen anderen stabilen Selektor. Vermeide Holds, die nur als Satz in einem Ticket stehen, denn ein Aufbewahrungsjob kann einen Satz nicht auswerten. Speichere, wer den Hold angeordnet hat, auf welcher Grundlage, mit welchem Prüftermin und wann er aufgehoben wurde.

Auch Korrekturen brauchen dieselbe Sorgfalt. Systeme erfassen gelegentlich eine falsch geparste Route, einen verspäteten Zeitstempel oder eine irreführende Klassifizierung. Lass das ursprüngliche Ereignis unverändert. Hänge eine Korrektur an, die das ursprüngliche Ereignis nennt, die geänderte Interpretation beschreibt, den Grund angibt und die Person oder den Prozess identifiziert, der die Korrektur vorgenommen hat. Berichte sollten die Korrektur zeigen, ohne den Quelldatensatz zu verbergen.

Teste den gesamten Prozess an einer nicht produktiven Kopie: Erzeuge Datensätze in jeder Klasse, lege einen Hold über einen Teil des Zeitraums, führe die Aufbewahrung aus, prüfe die erwartete Löschung, hebe den Hold auf und führe die Aufbewahrung erneut aus. Stelle anschließend ein Backup wieder her und prüfe, dass dadurch kein verstecktes, routinemäßig zugängliches Archiv entsteht, das dem angegebenen Zeitplan widerspricht.

Eine kompakte Richtlinie lässt sich leichter durchsetzen

Eine Aufbewahrungsrichtlinie sollte zu dem System passen, das sie ausführen muss. Die folgende Vorlage ist absichtlich schlicht, weil jede Aussage einem Verantwortlichen, einem Feld, einem Job oder einer Prüftätigkeit zugeordnet werden kann.

Zweck: Extern ausgeführte Agentenaktionen rekonstruieren und Missbrauch untersuchen.

Aktionsjournal: Aufbewahrung für [Zeitraum].
Felder: Akteursidentität, Sitzung, Autorisierungsentscheidung, Ziel,
Operation, Zugangsdatenreferenz, geschützte Ziel-ID, Ergebnis,
Integritätsfelder. Geheimnisse und rohe Inhalte ausschließen.

Diagnosedetails: Aufbewahrung für [kürzeren Zeitraum].
Felder: begrenzter Fehlertext und Zeitangaben. Positivlisten und
Redigierungsregeln anwenden.

Geschützte Beweiserfassung: nur fallbezogen. Fall-ID, Ablaufdatum,
Zugriffsgruppe und dokumentierte Freigabe erforderlich.

Integrität: Datensätze anhängen; Kette [Intervall] prüfen; Checkpoints
[Intervall] exportieren oder vergleichen. Prüfungsfehler protokollieren.

Löschung: [Intervall] ausführen. Richtlinienversion, Zeitraum, Ergebnis
und Holds protokollieren.
Holds: Löschung für definierte Selektoren aussetzen. [Intervall] prüfen.
Korrekturen: Korrektureintrag anhängen; Aktionsdatensatz nie überschreiben.

Benenne Verantwortliche für Datensatzschema, Aufbewahrungsplan, Datenschutzprüfung, Incident Holds und Integritätsprüfungen. In einem kleinen Team kann eine Person mehrere Rollen haben, aber die Zuständigkeiten müssen trotzdem benannt werden. Andernfalls entscheidet am Ende die Person, die den Agenten betreibt, auch darüber, welche Belege nach einem Vorfall verschwinden.

Sallyport führt ein Sitzungsjournal und ein Aktivitätsjournal, die aus einem verschlüsselten, hashverketteten Audit-Log abgebildet werden. Mit sp audit verify lässt sich diese Kette offline über Chiffretext prüfen. Das Design ist nur dann nützlich, wenn Teams vorher entscheiden, welche Felder in ihre Datensätze gehören und wie Aufbewahrungsjobs, Holds und Exporte mit ihnen umgehen.

Überprüfe die Richtlinie nach dem ersten echten Vorfall oder einer gezielten Tabletop-Übung. Bitte Ermittler, eine Aktion nur anhand der Datensätze zu rekonstruieren, die den Zeitplan überlebt hätten. Wenn sie für grundlegende Fragen ein Geheimnis, ein rohes Transkript oder die Erinnerung eines Administrators brauchen, ändere das Schema. Wenn sie die Fragen beantworten können, aber jeder Datensatz Kundeninhalte enthält, reduziere das Schema, bevor es dauerhaft wird.