Die Redigierung von Freigabekarten muss die Entscheidung erhalten

Eine Freigabekarte hat eine Aufgabe: Sie soll einer Person helfen zu entscheiden, ob eine bestimmte Aktion den eigenen Rechner verlassen darf. Verbirgt die Karte genug Details, um ein Geheimnis zu schützen, aber auch die Wirkung der Anfrage, verfehlt sie diese Aufgabe.

Der häufigste Fehler besteht darin, Redigierung als bloßen String-Ersatz zu behandeln. Entwickler maskieren Authorization, leeren den JSON-Body und nennen das Ergebnis sicher. Die antragstellende Person sieht dann POST https://api.example.com/... und eine Schaltfläche zum Freigeben. Das ist keine informierte Zustimmung, sondern ein leeres Ritual, das Menschen daran gewöhnt, genau in dem Moment weiterzuklicken, in dem menschliche Kontrolle wichtig wäre.

Eine gute Karte bewahrt die Bedeutung der Aktion und entfernt zugleich alles, womit die lesende, fotografierende oder protokollierende Person ein Geheimnis wiederverwenden könnte. Dafür braucht es eine feldbewusste Darstellung. Header, Query-Zeichenfolgen, Bodies und Zielkennungen brauchen jeweils eigene Regeln.

Eine Freigabekarte muss die Aktion erklären

Die antragstellende Person sollte in wenigen Sekunden vier Fragen beantworten können: Wer fragt an, wohin geht die Anfrage, was bewirkt sie und welches Objekt oder welcher Bereich ist betroffen? Fehlt eine Antwort, ist die Karte unvollständig, auch wenn jedes Geheimnis perfekt verborgen wurde.

Beginne mit einer Aktionszeile, die Protokollmethode und verständliches Verb verbindet:

POST  api.billing.example  /v1/invoices/inv_7KD2/refund
Action: issue a refund

Die Methode ist wichtig, weil GET, POST, PATCH und DELETE unterschiedliche Erwartungen wecken. Das verständliche Verb ist ebenso wichtig, denn eine Methode allein sagt nicht, ob POST /v1/invoices/inv_7KD2/refund einen Entwurf anlegt, eine Zahlung absendet oder eine Rückerstattung auslöst. Die antragstellende Person sollte die Bedeutung der Anwendung nicht aus einem Routennamen erschließen müssen, wenn der Aufrufer die beabsichtigte Aktion bereits kennt.

Zeige das Ziel als echte Autorität, nicht als Kontonamen. «Production billing» kann nützlicher Zusatzkontext sein, ersetzt aber nicht api.billing.example. Eine fehlgeleitete Anfrage kann einen vertrauten Namen verwenden. Der Host zeigt, welcher Dienst Daten und Zugangsdaten erhält.

RFC 3986 teilt eine URI unter anderem in Autorität, Pfad, Query und Fragment. Diese Trennung ist für Freigabekarten hilfreich, weil jede Komponente andere Entscheidungssignale trägt. Reduziere die URI nicht auf eine hübsche URL und hoffe, dass spätere Maskierung die wichtigen Informationen erhält.

Die Karte sollte außerdem nennen, ob die Aktion etwas erstellt, ändert, löscht, veröffentlicht, überträgt oder lediglich liest. «Kundendatensatz bearbeiten» ist schwächer als «Auszahlungsziel des Kunden ändern». Wenn der Request-Builder diesen Satz nicht liefern kann, muss der Request-Builder verbessert werden. Ein Renderer kann die fachliche Absicht nicht zuverlässig aus beliebigem JSON zurückgewinnen.

Ein Anfrage-Manifest statt einer verschönerten Anfrage darstellen

Die sichere Arbeitseinheit ist ein typisiertes Anfrage-Manifest. Es hält fest, was der Agent tun will, bevor Zugangsdaten eingefügt werden und bevor eine Freigabeansicht entsteht.

Ein minimales Manifest kann so aussehen:

{
  "channel": "http",
  "method": "POST",
  "destination": {
    "scheme": "https",
    "host": "api.billing.example",
    "port": 443,
    "path_template": "/v1/invoices/{invoice}/refund"
  },
  "action": "issue refund",
  "targets": [
    {"role": "invoice", "display": "inv_7KD2", "sensitivity": "internal"}
  ],
  "query": [],
  "headers": [],
  "body": {
    "media_type": "application/json",
    "fields": []
  },
  "effect": "financial"
}

Das ist keine Darstellung der HTTP-Leitung, sondern das Objekt, das der Freigabe-Renderer verarbeiten sollte. Der Unterschied zählt. Eine Leitungsanfrage enthält eingefügte Zugangsdaten, codierte Werte und Transportdetails. Ein Manifest enthält semantische Angaben wie action, target role und effect, die eine rohe Anfrage nicht liefert.

Klassifiziere jeden sichtbaren Wert danach, was die antragstellende Person für ihre Entscheidung braucht, nicht danach, wo der Wert zufällig auftaucht. Ein Bearer-Token in einem Header ist geheim. Eine signierte Webhook-URL in einer Query-Zeichenfolge ebenfalls. Eine E-Mail-Adresse im JSON-Body kann personenbezogene Daten enthalten. Ein Repository-Name kann eine Zielkennung sein, deren Sichtbarkeit für eine sichere Entscheidung nötig ist.

Verwende ein kleines, einheitliches Vokabular:

• public: Kann unverändert angezeigt werden.
• internal: Anzeigen, wenn der Wert das betroffene Objekt identifiziert, aber nicht in weit verbreitete Logs kopieren.
• personal: Nur in der kleinsten nützlichen Form anzeigen, meist mit Bezeichnung und teilweise sichtbarem Wert.
• secret: Den Wert niemals in Karte, Logs, Zwischenablage oder Fehlermeldung anzeigen.
• opaque: Nur einen freigegebenen Alias oder eine stabile, nicht geheime Referenz anzeigen, wenn sie das Ziel unterscheidbar macht.

Gib Aufrufern keine uneingeschränkte Hintertür wie safe_to_display: true. Jemand wird sie zur Vereinfachung einer Debugging-Sitzung verwenden und später in einem Pfad belassen, der Produktionszugangsdaten verarbeitet. Verlange die konkrete Klassifizierung an der Grenze, an der der Agent die Aktion erstellt.

Header brauchen Namen, Zweck und fast nie Werte

Headernamen sagen der antragstellenden Person oft mehr als Headerwerte. Werte enthalten dagegen häufig genau das, was nicht auf eine Oberfläche für Menschen gehört.

Zeige den Namen jedes sicherheitsrelevanten Headers und eine kurze Zweckangabe. Zum Beispiel:

Headers
Authorization: bearer credential from vault
Idempotency-Key: generated request identifier
X-Request-Reason: "refund requested by finance"
Content-Type: application/json

Die erste Zeile zeigt, dass die Anfrage authentifiziert wird. Die Quelle der Zugangsdaten sagt, ob der Prozess ein erwartetes gespeichertes Geheimnis nutzt. Bearer eyJ... zu zeigen, bringt keinen zusätzlichen Freigabewert. Es schafft einen Leckpfad und verleitet dazu, bedeutungslose Tokenfragmente zu vergleichen.

Die Spezifikation für Bearer-Tokens von OAuth sieht den Authorization-Request-Header als bevorzugte Übertragungsmethode vor. Ihre Sicherheitshinweise behandeln Bearer-Tokens als Zugangsdaten, die bei Übertragung und Speicherung geschützt werden müssen. Genau so sollte auch die Freigabeoberfläche denken: Die Person muss wissen, dass ein Bearer-Geheimnis eingesetzt wird, nicht das Geheimnis selbst prüfen.

Verwende diese Header-Regeln:

1. Zeige sichere Protokollwerte wie Content-Type, Accept und If-Match, wenn sie das Verhalten beeinflussen.
2. Zeige Namen, aber keine Werte für Authorization, Proxy-Authorization, Cookie, Set-Cookie, Signatur-Header, API-Key-Header und als geheim klassifizierte eigene Header.
3. Zeige einen begrenzten, maskierten Wert für ausdrücklich nicht geheime fachliche Zusatzinformationen wie X-Request-Reason, aber nur, wenn er kurz ist und keine persönlichen oder geheimen Inhalte enthalten kann.
4. Zeige, dass ein Header fehlt, wenn seine Abwesenheit die Entscheidung verändert. Ein fehlendes If-Match kann bei einem Überschreibvorgang wichtig sein.
5. Rendere niemals standardmäßig alle Header. Bibliotheken fügen Rauschen hinzu, und Rauschen verdeckt den einen Header, der die Aktion verändert.

Ein verbreitetes schlechtes Design zeigt bei Geheimnissen die ersten und letzten vier Zeichen: sk_live_...9a31. Das wirkt vorsichtig, ist aber bei kurzen, strukturierten oder bereits anderweitig offengelegten Werten unsicher. Es vermittelt zudem den Eindruck, Geheimnisfragmente müssten erkannt werden. Ersetze den Wert durch eine Typangabe wie gespeichertes API-Geheimnis oder Anfragesignatur.

Header können außerdem versteckte Zielkennungen sein. Ein Header für Mandantenrouting, ein Impersonation-Header oder X-Account-ID kann ändern, wen die Aktion betrifft. Verberge ihn nicht bloß, weil er ein Header ist. Zeige seine Rolle und ein sicheres Ziel-Label: X-Account-ID: Konto «Northwind production». Wenn sich eine undurchsichtige Kennung keinem sicheren Label zuordnen lässt, sage, dass eine undurchsichtige Kontokennung verwendet wird, und verlange für sensible Aktionen eine bewusstere Freigabe.

Query-Zeichenfolgen verdienen mehr Misstrauen

Query-Zeichenfolgen erscheinen in URLs, werden in Terminals kopiert, in Fehlerberichte eingebettet und häufig von Infrastruktur protokolliert, die den Request-Body nie sieht. Gerade diese Bequemlichkeit macht eine sorgfältige Darstellung auf Freigabekarten nötig.

RFC 9110 weist darauf hin, dass Informationen in einer URI durch Referenzen, Logs und andere Kanäle offengelegt werden können, und empfiehlt, sensible Informationen nicht in HTTP-Ziel-URIs zu übertragen. Das ist keine abstrakte Normensorge. Eine Karte mit vollständiger Query-Zeichenfolge kann zu einem weiteren Offenlegungskanal für einen Wert werden, der gar nicht erst in die URI gehört hätte.

Entscheide nicht, dass alle Query-Werte sicher sind, nur weil die Anfrage ein GET ist. Nutze Namen, deklarierte Typen und den Kontext der Aktion.

GET  api.crm.example  /v2/contacts
Query
status = "active"
owner = "sales-west"
include = "notes"
access_token = [secret, hidden]
search = [private text, hidden]

status und include sind oft hilfreiche Entscheidungsinformationen. search kann Namen, E-Mail-Adressen, medizinische Begriffe oder alles enthalten, was ein Agent aus lokalen Dateien übernommen hat. access_token ist offensichtlich geheim, doch das Design darf sich nicht auf eindeutige Namen verlassen. Manche APIs verwenden sig, token, key, code, state, assertion oder anbieterspezifische Parameter ohne Warnhinweis im Namen.

Behandle Query-Werte standardmäßig als geheim, sofern das Manifest sie nicht ausdrücklich klassifiziert. Die Freigabeoberfläche ist keine Debugging-Konsole. Ihre lesende Person braucht genug Informationen, um die Anfrage zu autorisieren, nicht deren bytegenaue Rekonstruktion.

Erhalte doppelte Parameter und ihre Reihenfolge, wenn sie die Bedeutung beeinflussen. Ein Renderer, der eine Query-Zeichenfolge in ein Wörterbuch umwandelt, kann tag=urgent&tag=finance verlieren, wiederholte Werte verändern oder einen Signaturfehler unsichtbar machen. Zeige eine Liste von Einträgen statt einer Map:

Query
label = "finance"
label = "urgent"
expand = "line_items"

Wenn ein redigiertes Query-Feld Routing oder Autorisierung verändert, sage es ausdrücklich. signature = [signierter Anfragewert, verborgen] liefert ein besseres Signal als eine leere Zeile. Enthält die Query einen undurchsichtigen Freigabelink, darf der Token nicht offengelegt werden. Zeige, sofern bekannt, das Ressourcenlabel wie geteilter Bericht: Q2 forecast, sonst Token für geteilte Ressource vorhanden.

Bodies sollten ihre Struktur nach der Redigierung behalten

Ein Body, der zu [redacted] wird, sagt fast nichts. Ein Body, der jedes Feld unverändert zeigt, wird irgendwann etwas offenlegen, das nie auf die Freigabeoberfläche gehört. Die richtige Lösung ist strukturelle Redigierung.

Rendere den Body als typisierten Baum. Behalte Objektschlüssel, Array-Anzahlen, Datentypen, sichere Enum-Werte und ausgewählte Ziellabels. Ersetze unsichere Blätter durch einen erklärenden Hinweis.

{
  "invoice": "inv_7KD2",
  "amount": {"currency": "USD", "minor_units": 12500},
  "reason": "duplicate charge",
  "customer_note": "[private text, 84 characters]",
  "payment_method": {
    "id": "[opaque payment method]",
    "token": "[secret, hidden]"
  }
}

So erkennt die antragstellende Person, dass die Aktion 125,00 USD aus einem genannten Grund erstattet und eine private Notiz den Rechner verlässt. Das reicht für die Entscheidung, ob die Anfrage zur beabsichtigten Aufgabe passt. Die Karte offenlegt weder Notiz noch Token.

Erhalte Zahlen, wenn Zahlen die Wirkung bestimmen. Werden Zahlungsbeträge, Sitzanzahlen, Aufbewahrungsfristen, Ratenbegrenzungen, Berechtigungsstufen oder Löschmengen verborgen, wird die Freigabe bedeutungslos. Behandle diese Werte als Aktionsparameter, nicht als nebensächliche Daten. Ein DELETE-Body mit {"purge": true} muss purge: true zeigen, sonst verbirgt die Karte den unumkehrbaren Teil.

Freitext braucht eine eigene Regel. Er kann Quelltext, Kundendaten, eingefügte Geheimnisse oder Anweisungen enthalten, die die Aktion verändern. Eine beliebige Vorschau ist verlockend, weil sie Unsinn sichtbar macht. Sie verwandelt das Freigabefenster aber auch in eine Oberfläche zur Datenexfiltration. Zeige bei nicht klassifiziertem Freitext Feldname, Zeichenzahl und Zielrolle. Ein begrenzter Ausschnitt darf nur erscheinen, wenn der Aufrufer das Feld als public oder internal markiert und der Renderer Steuerzeichen maskiert.

Für Arrays braucht es Anzahl und Zusammenfassung. Schlecht ist:

recipients: [redacted]

Besser ist:

recipients: 37 email addresses [personal values hidden]

Bei einer zerstörerischen Aktion verändert die Anzahl die Entscheidung. Bei einer Zugriffsänderung sollten Rolle und Anzahl erscheinen: 4 Mitglieder zur Rolle billing-admin hinzufügen. Wenn interne Kennungen unterschieden werden müssen, zeige freigegebene Anzeigenamen oder Aliase statt roher IDs.

Leite Sensibilität niemals allein aus dem Feldnamen ab. password, token und secret gehören auf eine harte Sperrliste, doch auch content, message, value, data und metadata können dieselben Inhalte enthalten. Die Klassifizierung muss aus Schema, Aktions-Builder oder ausdrücklicher Feldannotation kommen. Ein Filter nach Namen ist die letzte Verteidigungslinie, nicht das grundlegende Design.

Zielkennungen sollen verständlich, aber nicht vollständig offengelegt sein

Das Ziel ist das Objekt, das der Anfrage ihre Konsequenz gibt. Es kann in einem Pfadsegment, Header, Query-Parameter, JSON-Feld oder SSH-Kommandoargument stehen. Eine Karte muss das Ziel sichtbar machen, auch wenn die rohe Kennung nicht sicher angezeigt werden kann.

Trenne Maschinenreferenz und menschliche Anzeigeform:

{
  "role": "repository",
  "raw_reference": "repo_01HZX8M9...",
  "display": "payments-service",
  "scope": "production",
  "sensitivity": "internal"
}

Die rohe Referenz kann für die Ausführung nötig sein, gehört aber nicht zwingend auf die Karte. Wenn die Aktion Berechtigungen ändert, sollte ein Satz die Beziehung nennen: Deploy-Berechtigung für payments-service production an das Release-Automatisierungskonto vergeben. Die Karte darf nicht verlangen, dass die antragstellende Person sich undurchsichtige IDs merkt.

Ist der rohe Wert die einzige verfügbare Kennung, darf deshalb nicht der vollständige Wert angezeigt werden. Wähle einen stabilen, nicht umkehrbaren Bezug, etwa einen lokalen Alias oder eine kurze, aus dem geschützten Wert erzeugte Freigabereferenz. Eine gekürzte Kennung sollte nicht als Hash bezeichnet werden, wenn sie kein echter kryptografischer Digest ist. In vielen Fällen ist Kundendatensatz [undurchsichtige Referenz 4F8C] ehrlicher, als so zu tun, als könne jemand cus_Qa8J7kW2m9 auf einen Blick prüfen.

Überredigiere Kennungen nicht, die den Schadensumfang bestimmen. Bei DELETE /projects/{project}/members ist eine verborgene Projektkennung eine gefährliche Karte, selbst wenn alle persönlichen Mitgliedskennungen maskiert sind. Zeige Projektname, Umgebung und Anzahl der betroffenen Mitglieder. Die sensiblen Einzelwerte bleiben verborgen.

Hier besteht ein grundlegender Unterschied: Ein Geheimnis zu verbergen schützt Vertraulichkeit. Ein Ziel zu verbergen schwächt Autorisierung. Teams fassen beides oft unter «Redigierung» zusammen. Es sind verschiedene Aufgaben und brauchen verschiedene Regeln.

Der Freigabeumfang muss zu den Informationen auf der Karte passen

Eine vollständige Karte darf nicht mehr autorisieren, als sie beschreibt. Wurde eine Anfrage zum Lesen eines Repositorys freigegeben, darf dieselbe Freigabe nicht stillschweigend eine spätere Änderung der Repository-Einstellungen abdecken, nur weil beide aus demselben Agent-Prozess stammen.

Sitzungs- und Aufruffreigaben beantworten unterschiedliche Fragen. Die Sitzungsfreigabe klärt, ob dieser signierte Prozess während dieses Laufs über das Gateway handeln darf. Die Aufruffreigabe klärt, ob genau diese ausgehende Aktion mit diesem Ziel und dieser Wirkung stattfinden darf. Werden beide zu einer großen Berechtigung zusammengelegt, trägt die erste Karte eine unmögliche Last.

Nutze eine Eskalationsregel nach Folgen. Ein Lesezugriff auf einen bekannten Dienst kann unter eine Sitzungsfreigabe fallen. Ein Aufruf mit besonders geschützten Zugangsdaten, einer Zugriffsänderung, einer Nachricht, einer finanziellen Verpflichtung oder einer Datenlöschung braucht eine Karte für das konkrete Anfrage-Manifest.

Das Freigabeergebnis sollte an einen kanonischen Aktions-Digest gebunden sein, nicht an den sichtbaren Kartentext. Der Digest muss Methode, normalisiertes Ziel, Zielreferenzen, klassifizierte nicht geheime Parameter und eine Darstellung geschützter Felder enthalten. Er sollte außerdem erkennen können, ob sich die Anfrage nach dem Rendern verändert hat. Eine zusammenfassende, leicht fotografierbare Darstellung reicht dafür nicht.

Diese beiden Aufrufe brauchen unterschiedliche Freigaben, auch wenn ein nachlässiger Renderer sie ähnlich aussehen lassen könnte:

POST /v1/roles/grant
body: role = "viewer", subject = "build-bot"

POST /v1/roles/grant
body: role = "owner", subject = "build-bot"

Die Rolle ist kein Detail, das in einer eingeklappten JSON-Ansicht verschwinden darf. Sie ist die Aktion. Wenn die Karte zu voll wird, entferne zuerst dekorative Protokolldaten. Entferne nicht das Feld, das bestimmt, ob der Agent ein Konto übernehmen kann.

Sallyport trennt Sitzungsautorisierung aus diesem Grund von Schlüsseln pro Aufruf. Eine Sitzungsentscheidung kann einen neuen Agent-Prozess erkennen und zulassen. Ein für jede Verwendung markiertes Geheimnis fragt trotzdem vor jedem einzelnen Aufruf nach.

Ein Redigierungsfehler beginnt meist vor dem Rendern

Stell dir einen Agenten vor, der einen Vertrag zur Unterschrift versenden soll. Er erstellt diese Anfrage:

POST /v1/envelopes?template=msa&signature=QmFzZTY0U2lnbmVkVmFsdWU HTTP/1.1
Host: api.signing.example
Authorization: Bearer eyJhbGciOi...
Content-Type: application/json

{
  "recipients": [
    {"name": "Maya Chen", "email": "[email protected]"}
  ],
  "subject": "MSA for Northwind",
  "message": "Please sign the attached agreement.",
  "document": "JVBERi0xLjQK..."
}

Die oberflächliche Implementierung formatiert die rohe Anfrage, ersetzt den Authorization-Wert und kürzt lange Zeilen. Die Karte legt nun die Signatur in der Query, die E-Mail-Adresse der empfangenden Person und möglicherweise den Anfang eines als Text codierten Dokuments offen. Kürzen ist keine Redigierung. Es macht das Leck nur schwerer vorhersehbar.

Ein korrektes Manifest trennt die Bestandteile zuerst:

POST api.signing.example /v1/envelopes
Action: send contract for signature
Target: template "msa"
Recipients: 1 email address [personal value hidden]
Subject: "MSA for Northwind"
Message: public text, 39 characters
Document: 1 PDF attachment [content hidden]
Credential: bearer credential from vault
Request signature: present, hidden

Damit kann die antragstellende Person einen falschen Host, die falsche Vorlage, eine unerwartete Empfängerzahl oder einen versehentlichen Versand erkennen. Zugangsdaten, Signatur, E-Mail-Adresse und Dokumentinhalt werden nicht offengelegt.

Die gefährliche Variante scheiterte nicht, weil ein Maskierungsmuster signature übersehen hatte. Sie scheiterte, weil das System eine HTTP-Anfrage als fertigen Anzeigetext behandelte. Der Renderer bekam einen geheimnishaltigen Block ohne Feldtypen, Zielrollen und Wissen darüber, welche Werte die Bedeutung der Aktion tragen.

Einen Renderer bauen, der standardmäßig ablehnt

Der Renderer sollte nur strukturierte Eingaben akzeptieren, freigegebene Anzeigeregeln anwenden und eine Aktion mit nicht klassifizierten ausgehenden Feldern ablehnen. Das klingt streng, weil es streng ist. Ein nicht klassifiziertes Feld ist eine aufgeschobene Entscheidung. Der Freigabezeitpunkt ist zu spät, um zu raten.

Ein praktischer Darstellungsvertrag hat drei Stufen:

1. Das geplante Handeln vor dem Einfügen von Zugangsdaten und der Transportcodierung in ein Manifest normalisieren.
2. Prüfen, dass jedes Feld einen Typ, eine Sensibilitätseinstufung und eine Anzeigeregel besitzt. Unbekannte Header, Query-Werte und Body-Blätter ablehnen, sofern der Aufrufer sie nicht ausdrücklich einer sicheren verborgenen Darstellung zuführt.
3. Ein festes Kartenlayout rendern, das Ziel, Aktion, Ziele, Wirkung und Hinweise auf geschützte Felder prominent platziert.

Erlaube in sichtbaren Werten weder HTML, Terminalsteuerzeichen, Markdown noch beliebige Unicode-Richtungssteuerzeichen. Maskiere sie vor dem Layout. Ein bösartiger Wert darf nicht aus recipient: [email protected] eine irreführende Zeile machen, gefälschte Schaltflächen erzeugen oder eine Zielkennung visuell umsortieren.

Setze auch Anzeigebudgets. Ein öffentlicher String kann 50.000 Zeichen lang sein und die Karte unbrauchbar machen. Begrenze sichtbaren Text nach Feldtyp, vermerke die Kürzung und erlaube eine kontrollierte Detailansicht nur für Inhalte, die das Manifest als sicher eingestuft hat. «Vollständige Anfrage anzeigen» darf keine universelle Hintertür sein.

Teste den Renderer mit feindseligen Beispielen, nicht nur mit normalen API-Aufrufen. Dazu gehören ein Bearer-Token an jeder möglichen Stelle, doppelte Query-Namen, verschachtelte JSON-Arrays, ein Pfadsegment mit prozentcodierten Trennzeichen, ein leeres Geheimnis, ein kurzes Geheimnis, ein sehr langes Textfeld und Werte mit Zeilenumbrüchen. Teste außerdem Anfragen, deren gefährliche Bedeutung in einem Boolean, einer Anzahl, einer Rolle oder einem Ziel-Host steckt.

Halte schließlich fest, was die Freigabe abdeckte, ohne Klartextgeheimnisse in die Beweiskette zu kopieren. Sallyports Aktivitäts- und Sitzungsaufzeichnungen stammen aus einem einzigen verschlüsselten, hashverketteten Audit-Log. Der Offline-Befehl zur Prüfung kann die Kette ohne Tresorschlüssel kontrollieren. Das ist der richtige Maßstab: Auditierbarkeit soll beweisen, was geschehen ist, ohne zu einem zweiten Tresor voller wiederverwendbarer Zugangsdaten zu werden.

Die Karte sollte eine falsche Aktion falsch aussehen lassen. Kann jemand eine Anfrage mit Zugangsdaten freigeben, ohne Ziel, Wirkung und betroffene Objekte zu sehen, hat das System genau die Fakten verborgen, die diese Person zum Schutz gebraucht hätte.