Logo

Whitepaper zu Sicherheit und Datenschutz (Übersicht)Kapitel 12

Kapitel 12: Von Dritten überprüfbare Nachweise und Statusseite

Über unsere internen Designaussagen hinaus stellt FileBolt öffentlich reproduzierbare Nachweise von Dritten (Evidence) bereit, mit denen sich sichtbare Sicherheitseigenschaften überprüfen lassen (etwa die TLS-Konfiguration, Richtlinien für Sicherheits-Header usw.). Dieses Kapitel definiert Nachweisarten, Geltungsbereich, Einstiegslinks und die Grundsätze für die Zuordnung von Nachweisen zu Claim-IDs.

12.0 Zusammenfassung

  • SOLLTE: Öffentliche, reproduzierbare Nachweislinks von Dritten bereitstellen, um sichtbare Sicherheits-Baselines (TLS, Header usw.) zu überprüfen.
  • MUSS: Nachweislinks verweisen ausschließlich auf maßgebliche Quellen, niemals auf Screenshots oder sekundäre Wiederveröffentlichungen.
  • MUSS: Den Geltungsbereich der Nachweise ausdrücklich festlegen: Externe Scans können die Details einer vollständigen Zero-Knowledge-/E2EE-Implementierung nicht direkt überprüfen.
  • SOLLTE: Die Statusseite nutzen, um Nachweislinks zu bündeln, während die Nachweisfelder der Ansprüche direkt auf die ursprüngliche Quelle des Dritten verweisen sollten.

12.1 Nachweisarten und Geltungsbereich

12.1.1 Was sich überprüfen lässt

Nachweise von Dritten überprüfen typischerweise:

  • Konfiguration der Transportschicht: TLS-Versionen, Zertifikatsketten, Cipher Suites, HSTS usw. (abhängig von den Fähigkeiten des Scanners).
  • HTTP-Sicherheitsrichtlinien: Vorhandensein und Grundkonfiguration von Headern wie CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy usw.
  • Öffentlich sichtbare Weboberfläche: Häufige Fehlkonfigurationen, exponierte Endpunkte und grundlegende Sicherheitsbewertungen.

12.1.2 Was sich nicht direkt überprüfen lässt

Nachweise von Dritten können typischerweise nicht direkt überprüfen:

  • Korrektheit von Zero-Knowledge: z. B. „Der Server kann nicht auf den CEK zugreifen“, clientseitige Verschlüsselungsabläufe und Details der Schlüsselableitung.
  • Interner Betrieb und Zugriffskontrolle: z. B. interne Berechtigungen, Abläufe der Schlüsselverwaltung, Bereinigung von Logs und Zugriffsprotokollierung.
  • Absolute Sicherheit: Scans decken nur ihre jeweiligen Regelsätze und sichtbaren Oberflächen ab; sie ersetzen weder kontinuierliche Sicherheitsarbeit noch die Reaktion auf Vorfälle.

Daher unterscheidet dieses Whitepaper zwischen „sichtbaren Sicherheits-Baselines“ und „Protokoll-/Implementierungsgrenzen“: Sichtbare Baselines sind über Nachweise überprüfbar; die Grenzen von Zero-Knowledge/E2EE werden durch Protokollspezifikationen und Client-Beschränkungen geregelt (siehe Kapitel 5 und zugehörige Abschnitte).

12.2 Statusseite als zentrale Sammelstelle

FileBolt nutzt /status als zentrale Sammelstelle für Nachweislinks. Sie ersetzt nicht die Berichte der Dritten selbst, bietet Nutzern und Prüfern aber eine einheitliche Navigation, um wiederholt zu überprüfen.

  • MUSS: Nachweislinks auf der Statusseite verweisen auf maßgebliche Quellen von Dritten (reproduzierbar).
  • SOLLTE: Die Statusseite darf ein „Datum/Zeitstempel der letzten Prüfung“ angeben, sollte dies aber nicht als dauerhaftes, unveränderliches Ergebnis darstellen.
  • SOLLTE: Wenn bestimmte Pfade (z. B. Download-/Entschlüsselungsseiten) strengere Header einsetzen, können auf der Statusseite Nachweise auf Pfadebene bereitgestellt werden (sofern von Tools Dritter unterstützt).

12.3 Nachweis zur TLS-Konfiguration

Der TLS-Nachweis überprüft die HTTPS-Konfiguration, Protokollversionen, Zertifikatsketten und sichtbare Eigenschaften. Beispiele:

Hinweis: TLS-Nachweise spiegeln die sichtbare Konfiguration zum „Zeitpunkt des Scans“ wider; sie belegen weder die Grenzen der Ende-zu-Ende-Inhalte noch, ob der Server auf den CEK zugreifen kann.

12.4 Nachweis zu Sicherheits-Headern

Nachweise zu Sicherheits-Headern überprüfen das Vorhandensein und die Konfiguration grundlegender Richtlinien wie CSP, Referrer-Policy, X-Frame-Options, Permissions-Policy usw.

Empfehlung: Wenn Download-/Entschlüsselungsseiten (z. B. /transfer, /d/**) strengere Richtlinien verwenden, sollte die interne Dokumentation „Kritische Pfade sind strenger“ vermerken, und wo möglich sollten Tools, die Scans bestimmter Pfade unterstützen, als ergänzender Nachweis gewählt werden.

12.5 Umfassende Best-Practice-Scans

Umfassende Scans decken breitere Best-Practice-Prüfungen ab (z. B. HTTP-Konfiguration, häufige Schwächen, Kombinationen aus Caching- und Sicherheitsrichtlinien). Sie liefern eine ergänzende Überprüfung der Baselines der Website, sind aber nicht mit Audits der Protokollimplementierung gleichzusetzen.

12.6 Zuordnungsgrundsätze: Nachweise und Claim-IDs

  • MUSS: Jede überprüfbare Aussage (Claim) hat in der Hauptliste der Claim-IDs eine eindeutige ID und einen stabilen Anker.
  • MUSS: Das Nachweisfeld (Evidence) eines Claims verweist ausschließlich auf maßgebliche Quellen (Berichtsseiten von Dritten oder offizielle, reproduzierbare Seiten) und DARF NICHT auf Screenshots, Zusammenfassungen oder nicht maßgebliche Wiederveröffentlichungen verweisen.
  • SOLLTE: Die Statusseite kann als „Navigationssammlung“ für Nachweise dienen, das primäre Nachweisfeld eines Claims sollte aber nach Möglichkeit auf die ursprüngliche Quelle des Dritten verweisen.
  • MUSS: Die Formulierung eines Claims muss zum Geltungsbereich des Nachweises passen und vermeiden, „sichtbare Baselines“ zu „absoluten Sicherheitsgarantien“ zu überhöhen.

Hauptliste der Claim-IDs (einzige maßgebliche Quelle): /security-privacy-appendix-claim-ids

12.7 Zeitbezug und normative Formulierungen

Die Ergebnisse von Scans Dritter ändern sich im Lauf der Zeit (durch Aktualisierungen der Scanner-Regeln, Änderungen der Website-Konfiguration, Zertifikatswechsel usw.). Verweise auf Nachweise sollten „überprüfbar, aber nicht absolut“ formuliert sein.

  • SOLLTE: Das „Datum/die Uhrzeit der letzten Überprüfung“ (sofern zutreffend) auf der Statusseite oder in der Dokumentation festhalten und Nutzern eine wiederholte Überprüfung ermöglichen.
  • MUSS: „Dauerhafte/absolute“ Formulierungen vermeiden; eine zum Geltungsbereich des Nachweises passende Sprache verwenden, z. B. „Scan zeigt aktiviert/konform an“.
  • SOLLTE: Wenn sich kritische Sicherheitsrichtlinien ändern (z. B. Verschärfung der CSP, TLS-Updates), dies im Changelog festhalten und die zugehörigen Claim-IDs verlinken.

12.8 Zugehörige Claim-IDs (reserviert)

Dieses Kapitel behandelt „Nachweise von Dritten und Zuordnungsgrundsätze“. Die zugehörigen Claim-IDs werden im Anhang: Hauptliste der Claim-IDs als einziger maßgeblicher Quelle gepflegt.