# Kann ein Freigabe-Audit-Trail beweisen, wer eine Agentenaktion freigegeben hat? Ein Freigabe-Eintrag, der nur «freigegeben» sagt, beantwortet nicht die entscheidende Frage, nachdem ein Agent die Produktionsumgebung berührt hat: Wer hat welche Aktion unter welcher Berechtigung erlaubt, und was geschah danach? Er hält einen beruhigenden Moment in der Benutzeroberfläche fest und überlässt es dann dem Ermittler, den Rest zu erschließen. Ein Audit-Trail für Freigaben muss die Kette von einem Agentenprozess zu einer menschlichen Entscheidung, von dieser Entscheidung zur Nutzung von Anmeldedaten und von dort zu einem ausgeführten HTTP-Request oder SSH-Befehl bewahren. Wenn das getrennte Einträge ohne dauerhafte Verknüpfungen sind, kann ein Prüfer eine plausible Geschichte erzählen. Beweisen kann er sie nicht. Dieser Unterschied wird schmerzhaft, wenn die Aktion erfolgreich war, sich aber niemand an die Freigabe erinnert, wenn ein Agent mitten in einer Aufgabe neu gestartet wurde oder wenn jemand wissen möchte, ob ein Klick und eine Touch-ID-Bestätigung dasselbe bedeuteten. Das tun sie nicht. Wer sie gleich behandelt, erhält ein Log, das bis zur ersten ernsthaften Prüfung vollständig aussieht. ## Ein Freigabeereignis muss mehr als «Ja» beantworten Ein brauchbares Freigabeereignis sagt, was die Person freigegeben hat, warum das System gefragt hat, wie die Entscheidung getroffen wurde und wo die Freigabe endet. Der sichtbare Klick auf die Schaltfläche ist nur ein Feld dieses Ereignisses. Erfasse bei der Entscheidung mindestens diese Fakten: - Eine eindeutige Freigabe-ID und einen Ereigniszeitpunkt mit Offset. - Die Freigabemethode, etwa `click` oder `touch_id`. - Das lokale Konto oder eine andere bekannte Identität des Freigebenden sowie die Nachweise, auf denen diese Zuordnung beruht. - Den Umfang der Freigabe: eine Sitzung oder eine einmalige Nutzung von Anmeldedaten für einen Aufruf. - Die Anfrage, die den Dialog ausgelöst hat, identifiziert durch eine stabile Request- oder Aufruf-ID. Schreibe nicht einfach `user=alex`, nur weil ein Rechner ein Konto namens Alex besitzt. Das kann die beste verfügbare Zuordnung sein und sollte trotzdem erfasst werden. Nenne sie aber so, wie sie ist: lokaler Kontokontext. Wenn eine biometrische Aufforderung erfolgreich war, halte fest, dass ein auf diesem Gerät registrierter biometrischer Faktor das Ereignis autorisiert hat. Diese Aussagen sind belastbarer als «Jemand namens Alex hat es freigegeben», weil sie nicht so tun, als wüsste das Audit-Log mehr, als es tatsächlich weiß. NIST SP 800-171 Rev. 3 bietet einen sinnvollen Ausgangspunkt für Audit-Inhalte: Zeitstempel, Quell- und Zieladressen, Benutzer- oder Prozesskennungen, Ereignisbeschreibungen, geltende Zugriffskontrollen und Ergebnisse. Der Standard weist auch darauf hin, dass detaillierte Einträge privilegierte Befehle und die einzelnen Identitäten hinter gemeinsam genutzten Konten enthalten können. Für Agentenaktionen ist das eine gute Grundlage, aber noch kein fertiger Entwurf. Ein Freigabeablauf für Agenten braucht die Beziehungen zwischen Entscheidung, Anmeldedaten und Aufruf als eigene Daten. Der einfache Fehler besteht darin, eine Freigabe als Attribut der abschließenden Aktion zu speichern, etwa `approved=true`. Damit wird ein Ereignis auf ein Label reduziert. Du verlierst die Zeit zwischen Anfrage und Entscheidung, die Quelle der Entscheidung, den Umfang der Zustimmung und jeden späteren Widerruf. Außerdem lässt sich nicht mehr zwischen einer Benutzerfreigabe, einer standardmäßigen Erlaubnis, einer zwischengespeicherten Freigabe und einer Automatisierungsregel unterscheiden. Eine Entscheidung braucht einen eigenen Eintrag, auch wenn die Antwort «Nein» lautet. Eine abgelehnte Aufforderung kann erklären, warum ein Agent nicht bereitstellen konnte. Eine abgelaufene Aufforderung kann erklären, warum der Agent es erneut versucht hat. Ein gesperrter Tresor kann erklären, warum das System überhaupt keinen Netzwerkaufruf ausgeführt hat. Das sind materiell unterschiedliche Ereignisse. Ein späterer Prüfer sollte den Unterschied nicht aus einem fehlenden Erfolgseintrag ableiten müssen. ## Fünf Identitäten halten die Zeitleiste ehrlich Eine vollständige Zeitleiste braucht fünf getrennte Identitäten. Sie zusammenzulegen spart Spalten in einer Tabelle und zerstört die Aussagekraft einer Untersuchung. Die erste ist der **Agentenprozess**. Erfasse eine Prozess- oder Lauf-ID, die ausführbare Datei oder die Codesignatur, die ihn gestartet hat, sowie Start- und Endzeit. Die Person sollte beantworten können: «Welches laufende Programm hat danach gefragt?» Ein Projektname oder ein Chatverlauf reicht nicht. Zwei Kopien desselben Coding-Agenten können gleichzeitig laufen, wobei eine harmlos sein kann und die andere auf ein anderes Repository zeigt. Die zweite ist die **Sitzung**. Eine Sitzung ist die begrenzte Beziehung zwischen einem Agentenprozess und dem Gateway. Sie braucht eine eigene ID, weil ein Prozess viele Aufrufe durchführen kann und eine Sitzungsautorisierung oft für mehrere Aufrufe gilt. Wenn der Prozess endet, sollte auch die Sitzung enden. Startet später ein neuer Prozess, muss er eine neue Sitzung erzeugen, selbst wenn ausführbare Datei, lokales Konto und Aufgabenbeschreibung gleich sind. Die dritte ist der **Kontext des Freigebenden**. Dazu gehören das Gerätekonto, ein eventuell authentifizierter Anwendungbenutzer und die Freigabemethode. Das Feld für den Freigebenden darf keine Tatsachen behaupten, die es nicht belegen kann. `local_account=maya`, `method=touch_id` und `device_id=...` sind eindeutig. `human=maya` behauptet mehr. In manchen Umgebungen ist das angemessen, in anderen wird diese Aussage durch einen gemeinsam genutzten Arbeitsplatz oder einen entsperrten Desktop sofort fragwürdig. Die vierte ist die **Referenz auf die Anmeldedaten**. Sie identifiziert die vom Gateway verwendete Berechtigung, nicht das Geheimnis selbst. Für die Aktivitätsprüfung reichen normalerweise eine stabile undurchsichtige ID, ein verständliches Label, der Kanal und der Typ der Anmeldedaten. Ein Bearer-Token ist kein Audit-Feld. Auch der Fingerabdruck eines privaten SSH-Schlüssels kann ein sensibler Kontext sein. Entscheide deshalb, ob Ermittler ihn wirklich brauchen, bevor du ihn in gewöhnlichen Logs verbreitest. Die fünfte ist die **ausgeführte Operation**. Bei HTTP sind das die aufgelöste Zielidentität, die Request-Methode, der normalisierte Pfad, ausgewählte nicht geheime Request-Fakten, Antwortstatus und Zeitangaben. Bei SSH sind es Hostidentität, Remote-Konto, Befehl oder Digest des freigegebenen Befehls, Exit-Status und Zeitangaben. Das Ereignis muss zeigen, was ausgeführt wurde, nicht nur, was angefordert war. Diese Identitäten bilden einen Graphen und keine flache Zeile: ```text agent_process -> session -> approval_decision -> credential_use -> executed_call ``` Eine flache Aktivitätsansicht kann diesen Graphen als eine Zeile darstellen, wenn Menschen schnell arbeiten müssen. Die zugrunde liegenden Verknüpfungen müssen trotzdem erhalten bleiben. Die Anzeige ist für Personen gedacht, die einen Arbeitstag überblicken. Die IDs sind für die Person, die sechs Wochen später einen einzelnen Aufruf erklären muss. ## Ein Klick und Touch ID liefern unterschiedliche Nachweise Ein Klick dokumentiert die Interaktion mit einem Freigabeelement in der aktuellen Benutzeroberfläche. Touch ID dokumentiert zusätzlich zur auslösenden Interaktion eine erfolgreiche biometrische Autorisierung durch das Betriebssystem. Beides kann eine Aktion freigeben. Beides sollte aber nicht unter einem ungenauen Wert wie `approved_manually` zusammengefasst werden. Verwende ein ausdrückliches Methodenfeld mit einer kontrollierten Wertemenge. Zum Beispiel: ```json { "approval_id": "apr_01J8K4VY5Q", "occurred_at": "2026-07-22T14:18:06.184Z", "decision": "approved", "method": "touch_id", "approver": { "local_account": "maya", "identity_assurance": "device_account_and_biometric" }, "scope": "credential_use", "session_id": "ses_01J8K4TE0M", "requested_call_id": "call_01J8K4VPM2" } ``` Die genauen Feldnamen sind nicht entscheidend. Die Trennung ist es. `method` sagt, wie die Freigabe abgeschlossen wurde. `identity_assurance` sagt, was das System über die Person verantwortungsvoll behaupten kann. `scope` sagt, was die Entscheidung autorisiert hat. `requested_call_id` verknüpft die Freigabe mit einer Anfrage, die bereits existierte, bevor die Person den Dialog sah. Ein Klick kann für eine Bestätigung mit geringer Reibung richtig sein, besonders wenn jemand die Arbeit des Agenten ohnehin beobachtet. Touch ID fügt für eine sensible Operation eine stärkere lokale Bestätigung hinzu. Sie liefert aber nicht automatisch eine Unternehmensidentität, einen Entscheidungsgrund oder eine Zustimmung zu allen späteren Aufrufen. Wenn ein Team eine namentliche Freigabe durch einen Mitarbeiter über einen externen Identitätsanbieter braucht, muss der Ablauf die Aussage dieses Anbieters erfassen. Diese Sicherheit darf nicht stillschweigend aus einem lokalen biometrischen Ereignis abgeleitet werden. Der umgekehrte Fehler ist ebenso problematisch: Touch ID als bloße Dekoration zu behandeln. Wenn eine Aktion eine biometrische Freigabe verlangte und das Log dieses Ereignis auf `approved=true` reduziert, lässt sich nicht mehr zeigen, dass die strengere Kontrolle tatsächlich ausgeführt wurde. Bei der Prüfung fehlt dann ein Nachweis, der eine bewusste Bestätigung von einem versehentlichen Klick auf eine weitreichende Sitzungsaufforderung unterscheiden könnte. Protokolliere erfolglose biometrische Versuche mit Augenmaß. Ein Audit-Trail muss normalerweise zeigen, dass die angeforderte Aktion keine Freigabe erhalten hat. Er braucht aber selten jeden Authentifizierungsfehler auf Betriebssystemebene. Ein nützliches Ereignis ist `decision=denied_or_cancelled`, `method=touch_id` und, sofern die Plattform dies unterscheidet, ein Grund wie `user_cancelled`. Verwandle das Aktions-Gateway nicht in einen Sammler biometrischer Telemetrie. ## Sitzungszustimmung und Freigabe pro Aufruf haben einen unterschiedlichen Umfang Eine Sitzungsautorisierung gibt einem begrenzten Agentenprozess die Erlaubnis, weiterzuarbeiten, nachdem eine Person die Prozessidentität geprüft hat. Eine Freigabe pro Aufruf gilt für eine Nutzung der Anmeldedaten und eine Operation. Wenn beides ohne Angabe des Umfangs «Freigabe» heißt, wird die spätere Zeitleiste irreführend. Stell dir einen Agentenprozess vor, der um 09:00 Uhr startet. Das Gateway zeigt eine Autorisierungskarte mit der Codesignatur des Prozesses. Ein Entwickler klickt auf «Freigeben». Um 09:20 Uhr führt der Agent einen HTTP-Aufruf mit Anmeldedaten aus, deren Einstellungen keine Bestätigung pro Nutzung verlangen. Dieser Aufruf kann erlaubt sein, weil die Sitzung noch autorisiert ist. Die richtige Zeitleiste zeigt zwei getrennte Fakten: 1. Um 09:00 Uhr hat der Entwickler die Sitzung `ses_...` für die Lebensdauer dieses Prozesses freigegeben. 2. Um 09:20 Uhr hat diese Sitzung die Anmeldedaten `cred_...` verwendet, um den Aufruf `call_...` auszuführen. Sie sollte keine erfundene Benutzerfreigabe um 09:20 Uhr erzeugen. Der Entwickler hat diesen genauen Aufruf weder gesehen noch freigegeben. Die frühere Freigabe deckte ihn ab. Ändere nun eine Einstellung: Die Anmeldedaten verlangen bei jeder Nutzung eine Freigabe. Um 09:20 Uhr fragt das Gateway erneut, und der Entwickler bestätigt mit Touch ID. Das neue Ereignis muss auf `call_...` zeigen, `scope=credential_use` angeben und `method=touch_id` enthalten. Die Sitzungsfreigabe bleibt relevant, weil sie erklärt, warum der Agent die Anfrage nach den Anmeldedaten erreichen konnte. Sie ersetzt die zweite Entscheidung nicht. Dieser Unterschied ist besonders wichtig, wenn ein Agent spät in einer Sitzung einen überraschenden Aufruf ausführt. Wenn neben ihm «freigegeben» steht, muss der Prüfer wissen, ob damit die dreißig Minuten zuvor erfolgte Freigabe der ausführbaren Datei oder die drei Sekunden zuvor erfolgte Freigabe genau dieser Nutzung der Anmeldedaten gemeint ist. Diese Fakten haben sehr unterschiedliche Folgen für Dialoggestaltung, Einstellungen der Anmeldedaten und Incident Response. Löse die Unklarheit nicht dadurch, dass jeder Aufruf eine Freigabe verlangt. Diese Empfehlung klingt sicher und erzeugt eine beeindruckende Anzahl von Einträgen. Sie führt aber dazu, dass Menschen wiederholte Dialoge bestätigen, ohne sie zu lesen. Dann können sie den einen außergewöhnlichen Aufruf nicht mehr von den routinemäßigen unterscheiden. Verwende eine Freigabe pro Aufruf für Anmeldedaten, deren Nutzung eine frische menschliche Bestätigung braucht. Lass die Sitzungsautorisierung standardmäßig aktiv, damit der Agentenprozess an eine nachvollziehbare Freigabegrenze gebunden bleibt. Auch ein Widerruf braucht einen Umfang. Wenn ein Operator eine Sitzung widerruft, erfasse das Widerrufsereignis für diese Sitzung und den Zeitpunkt, ab dem es gilt. Überschreibe die alte Freigabe nicht. Wenn ein Benutzer Anmeldedaten deaktiviert oder entfernt, erfasse diese Änderung separat. Eine Audit-Zeitleiste sollte zeigen, warum ein späterer Aufruf abgelehnt wurde, ohne die Vergangenheit umzuschreiben und die frühere Freigabe verschwinden zu lassen. ## Einträge zu Anmeldedaten müssen die Berechtigung identifizieren, ohne sie offenzulegen Beim Eintrag zur Nutzung von Anmeldedaten treffen viele Teams eine gefährliche Entscheidung: Sie fügen geheimes Material hinzu, damit eine Untersuchung leichter wird. Das ist ein schlechter Tausch. Logs werden kopiert, indexiert, exportiert und länger aufbewahrt als der Prozess, der sie erzeugt hat. Ein Geheimnis in einem Aktivitätsjournal macht jeden Leser des Logs zum Besitzer einer Berechtigung. Gib jedem gespeicherten Datensatz eine unveränderliche undurchsichtige ID, etwa `cred_01J8K...`. Kombiniere sie mit einem Label, das den Zweck verständlich macht, etwa `payments-readonly` oder `staging-deploy`. Erfasse Kanal und Einfügeart, zum Beispiel `http_bearer`, `http_custom_header` oder `ssh_key`. Damit hat ein Ermittler genügend Kontext für die nächste Frage, ohne den Schlüssel in den Eintrag zu kopieren. Ein praktisches Ereignis zur Nutzung von Anmeldedaten kann so aussehen: ```json { "credential_use_id": "use_01J8K4WHD7", "occurred_at": "2026-07-22T14:18:06.221Z", "credential": { "id": "cred_01J7ZB7F8P", "label": "inventory-production", "channel": "http", "injection": "bearer" }, "session_id": "ses_01J8K4TE0M", "approval_id": "apr_01J8K4VY5Q", "call_id": "call_01J8K4VPM2", "secret_exposed_to_agent": false } ``` Das Feld `secret_exposed_to_agent` kann überflüssig wirken, wenn der Aufbau des Gateways dies garantiert. Behalte es, wenn die Zeitleiste mehrere Ausführungspfade oder Migrationen enthalten kann. So wird die Sicherheitseigenschaft im selben Eintrag wie die Aktion überprüfbar. Wenn alle unterstützten Pfade dieselbe Garantie haben, kann das Feld implizit Teil des Systemdesigns sein und einmalig dokumentiert werden. Trenne die Auswahl von Anmeldedaten von ihrer Nutzung. Ein Agent kann Anmeldedaten über ein Label anfordern. Verwendet wurden sie aber erst, wenn das Gateway die ausgehende Operation beginnt. Das ist bei Ablehnungen wichtig. Wird Touch ID abgebrochen, bevor die Anfrage den Rechner verlässt, erfasse einen versuchten Aufruf und ein abgelehntes Freigabeereignis. Erfasse keinen erfolgreichen Nutzungseintrag. Andernfalls würde dein Audit zählen, dass ein Produktionsschlüssel verwendet wurde, obwohl das nicht geschehen ist. Behandle bei SSH einen Host-Alias nicht als vollständige Zielidentität. `prod-db` ist verständlich, aber Aliase können sich ändern. Erfasse das konfigurierte Ziel und die Identitätsnachweise des Hosts, die dein Verbindungsablauf prüft. Wenn der Agent `prod-db` angefordert hat, das aufgelöste Ziel aber abwich, gehört diese Abweichung in den Ausführungseintrag. Genau solche Details sind nach einer fehlerhaften Bereitstellung wichtig. ## Der ausgeführte Aufruf belegt, dass die Aktion stattgefunden hat Die Freigabe belegt Zustimmung. Die Auswahl der Anmeldedaten belegt die beabsichtigte Berechtigung. Nur ein Ausführungseintrag zeigt, ob das Gateway die Operation außerhalb des Systems tatsächlich versucht hat und welches Ergebnis zurückkam. Bei HTTP-Aufrufen solltest du die Operation in normalisierter Form erfassen. Halte Request-Methode, Zielherkunft oder Dienstidentität, kanonischen Pfad, bei Bedarf ausgewählte Query-Feldnamen, Antwortstatus, Start- und Endzeit sowie eine Ergebnisreferenz fest. Entscheide bewusst, welche Request- und Response-Felder sicher aufbewahrt werden können. Autorisierungs-Header, Cookies, tokenartige Werte, vollständige Request-Bodies und rohe Response-Bodies gehören nicht in eine allgemeine Aktivitätszeitleiste. Ein Request-Digest kann helfen zu belegen, dass ein freigegebener und ein ausgeführter Payload übereinstimmten, aber nur, wenn seine Eingabe exakt definiert ist. Das Hashen eines JSON-Bodys ohne Kanonisierung der Feldreihenfolge erzeugt falsche Abweichungen. Ein Body mit einem kleinen vorhersehbaren Wert kann trotz Hashing einem Angreifer helfen, Vermutungen zu bestätigen. Verwende einen Digest zur Integritätskorrelation, wenn der Payload bereits an anderer Stelle geschützt ist, nicht als allgemeine Lösung für den Umgang mit Inhalten. Bei SSH gehören Remote-Konto, Zielidentität, Darstellung des Befehls, Exit-Status sowie Start- und Endzeit ins Log. Eine vollständige Befehlszeile kann Geheimnisse in Umgebungszuweisungen, temporären URLs oder Argumenten enthalten. Ein sinnvoller Kompromiss ist eine sichere Darstellung für die normale Prüfung und eine geschützte vollständige Darstellung oder ein Digest für Untersuchungen. Behaupte nicht, ein Digest sei lesbarer Nachweis. Er zeigt, dass zwei Werte übereinstimmen, aber nicht, was der Befehl getan hat. RFC 5424 trennt Zeitstempel und Nachrichtenidentität von strukturierten Daten, weil Parser zuverlässige Felder brauchen und keine Prosa erraten sollten. Sein Zeitstempelformat enthält außerdem einen Zeitoffset und erlaubt Bruchteile von Sekunden. Du musst kein Syslog ausgeben, aber die Designregel bleibt: Ereignistypen und Korrelationsfelder gehören in strukturierte Daten. Menschlicher Text ist für Erklärungen da. Verwende unterschiedliche Ereignistypen. `call.requested`, `call.dispatched`, `call.completed` und `call.failed_before_dispatch` sagen mehr als ein überladenes `call`-Ereignis, dessen Statusfeld seine Bedeutung ändert. Die zusätzlichen Einträge beantworten, ob ein Netzwerk-Timeout nach dem Einfügen der Anmeldedaten auftrat, ob eine lokale Prüfung die Anfrage zuerst blockierte und ob der entfernte Dienst eine Antwort zurückgab. Zeit allein kann die Reihenfolge über mehrere Rechner hinweg nicht beweisen. Verwende UTC-Zeitstempel mit Offsets und bewahre innerhalb jedes lokalen Audit-Logs eine monotone Sequenznummer auf. Wenn die entfernte API eine eigene Request-ID zurückgibt, speichere sie als entfernten Korrelationswert. So kann ein Ermittler die lokale Zeitleiste mit den Aufzeichnungen des Anbieters vergleichen, ohne so zu tun, als würden die Uhren perfekt übereinstimmen. ## Eine kaputte Zeitleiste versteckt sich in gewöhnlichen Erfolgslogs Stell dir einen Bereitstellungsagenten vor, der um 10:02 Uhr eine Sitzungsfreigabe erhält. Er liest ein Repository, bereitet ein Release vor und ruft um 10:17 Uhr eine Produktions-API für die Bereitstellung auf. Der Endpunkt akzeptiert die Anfrage. Um 10:18 Uhr bemerkt der Entwickler, dass die falsche Umgebung ausgewählt wurde. Ein schwaches Log enthält Folgendes: ```text 10:02 approved agent 10:17 deployment API call succeeded ``` Dieses Log beantwortet fast nichts. War der Aufruf um 10:17 Uhr von der Freigabe um 10:02 Uhr abgedeckt? Mussten die Anmeldedaten eine zweite Aufforderung auslösen? Welcher Prozess führte den Aufruf aus? Verwendete der Agent die vorgesehene Berechtigung für Bereitstellungen oder ein weitreichenderes Token? Wurde die Anfrage an die Produktion gesendet oder durch eine Weiterleitung beziehungsweise einen Konfigurationsfehler dorthin geleitet? Klickte die Person auf «Freigeben», verwendete sie Touch ID oder sah sie nie eine auf die Aktion bezogene Aufforderung? Eine brauchbare Zeitleiste sieht stattdessen so aus: ```text 10:02:11 session.opened ses_71 process=proc_44 signer=known_authority 10:02:14 approval.approved apr_02 method=click scope=session session=ses_71 account=maya 10:17:03 call.requested call_88 POST deploy.example/release target=production session=ses_71 10:17:04 credential.selected use_53 credential=cred_prod_deploy call=call_88 10:17:04 call.dispatched call_88 destination=deploy.example 10:17:06 call.completed call_88 status=202 remote_request=req_914 ``` Dieser Eintrag kann belegen, dass der Agent eine gültige Sitzungsautorisierung hatte, aber keine aufrufbezogene Freigabe erhielt. Das beweist nicht, dass die Bereitstellung gewünscht war. Es liefert Informationen darüber, wie die Kontrolle funktioniert hat. Das Team kann dann entscheiden, ob die Produktionsberechtigung eine Freigabe pro Aufruf verlangen sollte, ob der Dialog die Zielumgebung deutlicher anzeigen muss oder ob der Agent überhaupt Zugriff auf diese Berechtigung haben sollte. Kommt eine Freigabe pro Aufruf hinzu, ist der richtige zusätzliche Eintrag keine weitere allgemeine Zeile mit «freigegeben». Er sollte den freigegebenen Aufruf und seinen Umfang nennen: ```text 10:17:04 approval.approved apr_03 method=touch_id scope=credential_use session=ses_71 call=call_88 credential=cred_prod_deploy account=maya ``` Wenn der Agent es nach einem Timeout erneut versucht, gib dem erneuten Aufruf eine neue Call-ID. Er kann eine bestehende Sitzungsfreigabe wiederverwenden. Eine Richtlinie für die Freigabe pro Aufruf muss für den erneuten Versuch aber eine neue Bestätigung verlangen. Wird der Versuch als ursprünglicher Aufruf protokolliert, entsteht fälschlich der Eindruck, eine Bestätigung habe zwei externe Aktionen abgedeckt. ## Die Integrität des Audits braucht eine eigene Aussage Ein Audit-Log kann eine Abfolge vollständig genug erklären und trotzdem leicht veränderbar sein. Es kann dem Anspruch nach nur angehängt werden und einem Administrator oder einer lokal zugreifenden Schadsoftware dennoch erlauben, unangenehme Zeilen zu entfernen. Behandle Inhalt und Integrität als getrennte Eigenschaften. Ein hashverkettetes Journal verknüpft jeden Eintrag über einen kryptografischen Digest mit dem vorhergehenden. Wird ein alter Eintrag geändert, lässt sich die spätere Kette nicht mehr prüfen. Das ist nützlich, weil eine exportierte Aktivitätsansicht gegen das zugrunde liegende Journal geprüft werden kann, statt bloß als vertrauenswürdig zu gelten. Es beweist nicht, dass das ursprüngliche System jedes Ereignis erfasst hat, dass ein kompromittierter Schreiber keine falschen Einträge erzeugt hat oder dass eine gültige Freigabe eine gute Entscheidung war. Das sind verschiedene Aussagen und erfordern unterschiedliche Kontrollen. Prüfe die Integrität an der Stelle, an der die Beweise das System verlassen. Ein Ermittler sollte den verschlüsselten Datenstrom nehmen, offline prüfen können, ob die Kette intakt ist, und dafür keine Anmeldedaten offenlegen müssen. Die Ausgabe der Prüfung sollte den geprüften Bereich, den Kettenstatus und bei einem Fehler die erste fehlerhafte Sequenz nennen. Sallyport erstellt seine Sitzungs- und Aktivitätsjournale aus einem gemeinsamen schreibgeschützten, verschlüsselten und hashverketteten Audit-Log. Mit `sp audit verify` lässt sich die Kette offline über Ciphertext prüfen, ohne einen Tresorschlüssel zu benötigen. Das ist wichtig, weil Sitzungsentscheidung und einzelne Operation dann Ansichten derselben Beweiskette bleiben und keine unabhängig veränderbaren Geschichten sind. Verwende die Integritätsprüfung nicht als Grund, übermäßig viele Daten für immer aufzubewahren. Aufbewahrung, Zugriffskontrolle und Schwärzung bleiben wichtig. Ein perfekt erhaltenes Log voller Geheimnisse ist ein Vorfall, der nur auf die passende Suchanfrage wartet. Lege fest, wer Rohdaten einsehen darf, wer sie exportieren kann, wie lange sie verfügbar bleiben und welche Felder in normalen Ansichten sicher sind. ## Baue die Zeitleiste um Verknüpfungen herum und teste dann die schwierigen Fälle Eine Schema-Prüfung sollte mit einer direkten Frage beginnen: Kann ein Ermittler bei jeder ausgeführten Aktion starten und ohne Vermutungen rückwärts bis zur Freigabe gehen? Wenn nicht, ergänze die fehlende ID, bevor du die Aktivitätsansicht verfeinerst. Führe mit der Implementierung eine kleine Testmatrix aus. Du brauchst keine große Simulation, sondern Fälle, die Fehler bei Umfang und Reihenfolge sichtbar machen: - Starte einen neuen Agentenprozess, gib seine Sitzung per Klick frei und führe einen risikoarmen Aufruf aus. - Verwende Anmeldedaten, die eine Freigabe pro Aufruf verlangen, bestätige sie mit Touch ID und prüfe, ob der Aufruf auf diese Freigabe verweist. - Brich die biometrische Aufforderung ab und prüfe, dass kein erfolgreicher Nutzungseintrag für die Anmeldedaten erscheint. - Beende den Agentenprozess, starte ihn erneut und prüfe, dass der neue Prozess die alte Sitzungsfreigabe nicht übernehmen kann. - Erzwinge nach dem Versand einen Fehler beim entfernten Dienst und prüfe, dass die Zeitleiste Versand und Abschluss unterscheidet. Prüfe das Ergebnis aus beiden Richtungen. Beginne mit der Freigabe und liste jede Aktion auf, die sich darauf stützte. Beginne danach mit dem ausgeführten Aufruf und verfolge Prozess, Sitzung, Entscheidung und Anmeldedaten zurück. Die erste Sicht findet Freigaben, die weiter oder länger galten als erwartet. Die zweite findet Aufrufe mit fehlenden oder mehrdeutigen Nachweisen. Die Sprache der Benutzeroberfläche muss genauso eindeutig sein wie das Datenmodell. «Sitzung per Klick freigegeben» ist klar. «Produktionsberechtigung für diese Aktion mit Touch ID freigegeben» ist klar. «Freigegeben» ist ein dekoratives Statuswort, das den Leser dazu bringt, die wichtigsten Details selbst zu erfinden. Wenn jemand zum ersten Mal fragt, wer eine Agentenaktion freigegeben hat, gib ihm keinen Screenshot mit einem grünen Abzeichen. Gib ihm eine Zeitleiste, die Prozess, Entscheidungsmethode, Umfang, Berechtigung der Anmeldedaten, exakten Aufruf und Ergebnis zeigt. Alles darunter mag in einer Demo bequem sein. Wenn es darauf ankommt, hält es nicht stand.