Audit und Nachweis
Zusammenfassung. WKL TrustBridge trennt drei Arten von Aufzeichnungen nach ihrem Beweiswert: Betriebsprotokoll zur Fehlersuche, Sicherheitsaudit über Handlungen von Personen, Diensten und Verbindungen, und ein manipulationsnachweisendes Register über Ausstellung, Sperrung, Freigaben und Beziehungen. Eine Hash-Kette beweist nur dann etwas, wenn ihr Kopf außerhalb der Reichweite dessen liegt, gegen den sie beweisen soll; deshalb werden die Kettenköpfe extern verankert. Die zweite Hälfte der Seite ordnet die Anforderungen der Regelwerke den Maßnahmen zu und trennt, welche Nachweise TrustBridge liefert und welche die betreibende Organisation selbst erbringt.
Begriffe
- Hash-Kette – Folge von Einträgen, in der jeder den Hash seines Vorgängers enthält; eine Änderung eines Eintrags bricht die Kette ab dieser Stelle.
- Kettenkopf – Hash des jüngsten Eintrags.
- Externer Anker – Kopie des Kettenkopfs in einem nur anfügbaren Speicher außerhalb der Reichweite der Administratoren von Datenbank und Worker-Host.
- Abschneiden – Löschen der jüngsten Einträge; ohne externen Anker unsichtbar, weil die verbleibende Kette intakt ist.
Drei Ebenen
| Ebene | Inhalt | Ort | Beweiswert |
|---|---|---|---|
| Betriebsprotokoll | Anfragen, Fehler, Laufzeiten, Zustand der Bibliotheken | Protokoll der Dienste, kurze Aufbewahrung | keiner; dient der Fehlersuche; enthält keine Geheimnisse |
| Sicherheitsaudit | Anmeldung und Fehlanmeldung, Rechteänderung, Auftrag angelegt, Freigabe weitergereicht, Stornierung, Sperrauftrag, Vorlage geändert; Verbindungsaufbau, Ablehnungen mit Grund und Schlüsselaustausche der TLS-Adapter und Schlüsselagenten | Datenbank, je Mandant verkettet, laufend extern kopiert; Verbindungsprotokoll je Rechner verkettet und an die Organisation übertragen | nachprüfbar bis zum letzten Anker; durch die externe Kopie wiederherstellbar |
| Manipulationsnachweisendes Register | ausgestellt, abgelehnt, gesperrt; Fassung des Regelwerks; Freigaben und Attestierungen; Beziehungen, ihre Änderungen und Widerrufe; Vertrauensbündel; Schlüsselzustände; Zeremonien | Register von Worker und Wurzel | von Dritten prüfbar |
Ein Ereignis gehört in die höchste Ebene, die es betrifft; eine Kopie in einer niedrigeren ist zulässig, ersetzt sie aber nicht.
graph TD
subgraph PL [TrustBridge-Installation]
DB[(Sicherheitsaudit<br/>je Mandant verkettet)]
REG[(Register Worker)]
RR[(Register Wurzel)]
end
subgraph EX [Außerhalb der Reichweite der Administratoren]
ANK[(Nur anfügbarer Speicher)]
end
DB -->|laufende Kopie<br/>und Kettenkopf| ANK
REG -->|Kettenkopf, periodisch| ANK
REG -->|Kettenkopf in jede Zeremonie| RR
classDef ex fill:#dff6dd,stroke:#107c10,color:#201f1e
classDef pl fill:#f3f2f1,stroke:#605e5c,color:#201f1e
class ANK ex
class DB,REG,RR pl
style PL fill:#ffffff,stroke:#8a8886,color:#201f1e
style EX fill:#ffffff,stroke:#8a8886,color:#201f1eWas das Register beweist
Je Ausstellung enthält das Register den Auftragshash, die Freigabe- oder Attestierungssignaturen mit Kennung des Schlüssels, die Fassung des Regelwerks, mit der geprüft wurde, und den Mandanten. Ein Dritter kann damit ohne Datenbank nachvollziehen: Person X hat die Bytes Y freigegeben, prüfbar mit dem öffentlichen Schlüssel aus dem Regelwerk; das Zertifikat Z entspricht diesen Bytes und trägt die Signatur der CA.
Anforderungen an die Verkettung
| Anforderung | Grund |
|---|---|
| Alle Felder im Hash, auch Mandant, Adresse des Akteurs, laufende Nummer und eine Kennung der Kettenfassung | sonst lässt sich ein Ereignis unbemerkt einem anderen Mandanten zuschieben |
| Eindeutige Kodierung: jedes Feld mit Längenangabe, fehlender Wert unterscheidbar von leerem | sonst ergeben zwei verschiedene Inhalte denselben Hash |
| Eine Kette je Mandant und eine Systemkette | ein Partner kann seinen Auszug vollständig prüfen, ohne fremde Daten zu sehen |
| Externer Anker | macht Abschneiden und Neuberechnen erkennbar |
| Wiederherstellung als eigenes Ereignis mit Verweis auf den letzten Anker | ein Rückfall wird erklärt, nicht verdeckt |
Ereignisse der Anmeldung
Die Anmeldebausteine von TrustBridge (persönlicher Schlüssel, zweiter Faktor, Sitzung) haben bewusst keine eigene Ereignisausgabe; sie liefern Ergebnisse. Die Verwaltung erzeugt daraus die Sicherheitsereignisse und schreibt sie zusammen mit der Zustandsänderung in einer Transaktion. Kennwörter, Codes und Schlüssel erscheinen in keinem Ereignis; für persönliche Schlüssel werden nur Kennung und die letzten vier Zeichen geführt.
Einsicht durch Support und Betriebspartner
Sieht der Support einer Organisation oder ihr Betriebspartner mehrere Mandanten, ist nachvollziehbar, wer wann welche Daten welches Partners geöffnet oder exportiert hat: Bei Sichtbereichen über mehr als einen Mandanten schreibt die Verwaltung das Öffnen einzelner Datensätze und jeden Export ins Sicherheitsaudit.
Prüfverfahren für Dritte
Ein Prüfer, dem eine Organisation einen Auszug übergibt, kann eine Ausstellung ohne Zugang zur Datenbank nachvollziehen: Kette, Freigabe, Übereinstimmung von Auftrag und Zertifikat und Sperrungen. Für Beziehungen gilt dasselbe Verfahren; jede Beziehung, jede Änderung und jeder Widerruf lässt sich gegen das signierte Vertrauensbündel abgleichen, das die TLS-Adapter zu diesem Zeitpunkt verwendet haben.
TrustBridge liefert dafür einen Registerauszug in einem offengelegten Format, die Fassungen des Regelwerks mit ihren öffentlichen Schlüsseln und ein Prüfwerkzeug, das die Schritte ohne Zugang zur Installation ausführt. Die vier Schritte beschreibt So prüfen Sie eine Ausstellung als Dritter.
Zuordnung zu den Regelwerken
| Regelwerk, Anforderung | Maßnahmen | Nachweis durch TrustBridge | Nachweis der Organisation |
|---|---|---|---|
| NIS2/BSIG § 30 Nr. 1 Risikoanalyse | Bedrohungsmodell, Kompromittierungsanalyse | Vertrauensmodell | Risikoanalyse im eigenen Betrieb |
| § 30 Nr. 2 Vorfallsbehandlung | M-53, M-72 | Alarm bei Zählerabweichung; Verfahren | Übung, Meldeprozess |
| § 30 Nr. 3 Betriebskontinuität | M-30 bis M-34 | Ausfallanalyse (Betrieb und Notfall), Bereitschaft | Ausfallübung |
| § 30 Nr. 4 Lieferkette | M-24, M-25, M-63, M-80 bis M-82 | Namensbeschränkung, Testzertifikate, Register der Beziehungen, Stückliste | Partnerverträge mit Prüfer-Vertrag |
| § 30 Nr. 5 Entwicklung, Schwachstellen | M-60 bis M-65 | Tore im Bau, Stückliste, Herkunftsnachweise | Einspielen der Aktualisierungen |
| § 30 Nr. 8 Kryptographie | M-01 bis M-08, M-83 bis M-85 | Prüfung gegen NIST-Prüffälle, Parametersätze nach TR-02102 | Kryptokonzept der Organisation |
| § 30 Nr. 9 Zugriffskontrolle | M-14, M-20, M-21, M-41, M-86 | Rechte je Anfrage, Freigaben als Signatur, Partneridentität für Zielanwendungen | Rechtekonzept, Berechtigungen in den Zielanwendungen |
| § 30 Nr. 10 Mehr-Faktor-Authentisierung | M-40 | zweiter Faktor für jede Person | Ausgabe der Faktoren |
| TR-02102 | M-03, M-04, M-83 | Parametersätze der Fassung 2026-01, hybride TLS-Gruppen | – |
| IT-Grundschutz CON.1, OPS.1.1.5, DER.4 | M-01, M-50 bis M-53, M-30 bis M-34 | Architekturbeschreibung, Protokollierungsebenen | Grundschutz-Check |
| ISO/IEC 27001 A.8.24, A.8.15, A.8.5 | wie oben | Maßnahmen und Nachweise dieser Dokumentation | Managementsystem, Erklärung zur Anwendbarkeit |
| ETSI EN 319 411-1 | M-70, M-71, M-50 | Zeremonie und Rollen | Zertifizierungsrichtlinie (CP/CPS) der Organisation |
| C5 | M-14, M-50, M-63 | Mandantentrennung, Protokollierung, Herkunftsnachweise | Testat des Betreibers |
| DSGVO Art. 5, 32 | M-08, M-74 | Datenminimierung im Identitätsmodell | Verarbeitungsverzeichnis, Löschkonzept |
| CRA | M-60 bis M-64 | Stückliste, Schwachstellenprozess des Herstellers | – |
Was diese Seite nicht belegt
- Keine Konformität. Die Tabelle zeigt, welche Maßnahmen eine Anforderung adressieren und welche Nachweise TrustBridge beisteuert. Eine Zertifizierung oder ein Testat erwirbt die betreibende Organisation mit ihren eigenen Nachweisen.
- Keine Aufbewahrungsfristen für eine bestimmte Organisation. Die Vorgaben stehen in Betrieb und Notfall; jede Organisation legt ihre Fristen selbst fest (M-74 in Sicherheitsmaßnahmen).