Sicherheit & Compliance

GovBridge ist als Behörden-Komponente auf Vertraulichkeit und Nachvollziehbarkeit ausgelegt. Dieses Kapitel bündelt die sicherheits- und datenschutzrelevanten Eigenschaften.

Verschlüsselung der Backend-Credentials

Die Zugangsdaten zum Backend (Basic-Passwort bzw. OAuth2-Client-Secret — beim CMIS-DMS wie bei der FIT-Connect-Submission-API) werden niemals im Klartext gespeichert:

• Verfahren: AES-256-GCM (authentifizierte Verschlüsselung).
• Format: v1:<base64-iv>:<base64-ct||tag> — byte-kompatibel zwischen der SovrGPT-Plattform (lib/secret-crypto.ts) und dem Bridge-Dienst (services/govbridge/src/crypto.ts), sodass derselbe Schlüssel beidseitig gilt.
• Schlüssel: GOVBRIDGE_ENCRYPTION_KEY, ein 32-Byte-Schlüssel (base64), nur als Server-Umgebungsvariable — nie im Code, nie im Repository, nie clientseitig.
• Entschlüsselung transient: Die Credentials werden erst im RAM, nur für die Dauer eines einzelnen Tool-Calls entschlüsselt (resolver.ts) und nie geloggt.

Zwei-Faktor-Mandantenauflösung

Jeder Aufruf trägt zwei unabhängige Faktoren, die beide auf dieselbe Endpunkt-Zeile zeigen müssen:

1. Slug im URL-Pfad (/<slug>/<protocol>) — identifiziert den Endpunkt.
2. Bearer-Token im Authorization-Header — beweist die Berechtigung.

Sicherheitsdetails:

• Vom Token wird nur der SHA-256-Hash gespeichert; der Klartext existiert einmalig bei der Provisionierung (One-Time-Reveal) — danach nicht mehr abrufbar.
• Der Vergleich ist konstant-zeitig (timingSafeEqual) und gibt bei Längenungleichheit false statt zu werfen → keine Timing-Seitenkanäle.
• Ein Fehlschlag liefert immer ein generisches 401 — es wird nie verraten, welcher der beiden Faktoren nicht passte.
• Das URL-<protocol> muss exakt dem provisionierten Protokoll entsprechen (keine protokollübergreifende Token-Wiederverwendung).

Least Privilege

• Das Modell kann ausschließlich das kuratierte cmis_*-Werkzeugset aufrufen — es gibt keinen rohen CMIS-SQL-Passthrough.
• CMIS-SQL-Queries werden serverseitig ausschließlich aus escapten String-Literalen zusammengesetzt; Modelltext erreicht die Query nie verbatim (Injection-Schutz).
• Schreibaktionen (cmis_dokument_ablegen, cmis_dokument_verschieben) sind pro Endpunkt über allow_writes abschaltbar. Ist der Schreibzugriff aus, werden diese Werkzeuge weder in tools/list gelistet noch ausgeführt („Schreibzugriff ist für diesen Endpoint nicht freigegeben.").

Metadata-only-Logging

Der Dienst protokolliert strikt nur Metadaten (logger.ts):

• Erlaubt: Org-/Endpoint-IDs, Tool-Name, Protokoll, Status, Dauer, Byte-Zählungen, Korrelations-ID.
• Niemals geloggt: Dokumentinhalte, Bridge-Token, Backend-Credentials, der Authorization-Header.
• Eine Redaction-Allowlist scrubbt sensible Schlüssel (authorization, token, password, client_secret, credentials, content, body, …) zusätzlich automatisch — auch wenn versehentlich ein zu reiches Objekt übergeben wird.

EU-Datenresidenz

Alle drei Stationen des Datenpfads liegen im EU-Raum:

Es gibt keinen Hyperscaler im Datenpfad und keine Zwischenspeicherung von Fachinhalten — jeder Tool-Call zieht live aus dem DMS.

DSGVO-Aspekte

• Datenminimierung: Nur die für den jeweiligen Tool-Call angeforderten Daten fließen; nichts wird vorgehalten.
• Zweckbindung & Least Privilege: Kuratierte Werkzeuge, abschaltbarer Schreibzugriff, kein Vollzugriff auf das DMS.
• Auftragsverarbeitung: Betrieb durch eNetworkers (siehe DSGVO); das DMS bleibt in Verantwortung der Behörde.
• Nachvollziehbarkeit: Jede Provisionierung/Änderung landet im Audit-Log der Plattform; jeder Tool-Call wird metadatenseitig protokolliert.

Widerruf & Rotation

• Ein Endpunkt kann jederzeit deaktiviert oder widerrufen werden; widerrufene Zeilen werden vom Bridge-Dienst nicht mehr aufgelöst.
• Geht ein Bridge-Token verloren oder besteht Leak-Verdacht, wird der Endpunkt neu provisioniert (neuer Slug + Token); der alte ist damit sofort unbrauchbar.

Weiter

• Architektur & Request-Flow.
• Betrieb — Hosting, Limits, Fehlerverhalten.