Logo

Whitepaper zu Sicherheit und Datenschutz (Übersicht)Kapitel 12

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

Über unsere internen Designansprüche hinaus stellt FileBolt öffentlich reproduzierbare Beweise Dritter (Beweise) zur Überprüfung sichtbarer Sicherheitseigenschaften bereit (wie TLS-Konfiguration, Sicherheits-Header-Richtlinien usw.). In diesem Kapitel werden Beweisarten, anwendbarer Umfang, Eintragslinks und Grundsätze für die Zuordnung von Beweisen zu Anspruchs-IDs definiert.

12.0 Zusammenfassung

  • SHOULD: Stellen Sie öffentliche, reproduzierbare Links zu Beweisen Dritter bereit, um sichtbare Sicherheitsgrundlinien (TLS, Header usw.) zu überprüfen.
  • MUST: Beweislinks verweisen nur auf maßgebliche Quellen, niemals auf Screenshots oder sekundäre Reposts.
  • MUST: Definieren Sie den Umfang der Beweise explizit: Externe Scans können die vollständigen Zero-Knowledge/E2EE-Implementierungsdetails nicht direkt überprüfen.
  • SHOULD: Verwenden Sie die Statusseite, um Beweislinks zusammenzufassen, während Anspruchsnachweisfelder direkt auf die ursprüngliche Drittanbieterquelle verweisen sollten.

12.1 Beweisarten und -umfang

12.1.1 Was überprüft werden kann

Beweise Dritter bestätigen in der Regel Folgendes:

  • Transportschichtkonfiguration: TLS-Versionen, Zertifikatsketten, Cipher Suites, HSTS usw. (abhängig von den Scannerfunktionen).
  • HTTP-Sicherheitsrichtlinien: Existenz 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 nicht direkt überprüft werden kann

Beweise Dritter können in der Regel Folgendes nicht direkt bestätigen:

  • Zero-Knowledge-Korrektheit: Z. B. „Server kann nicht auf CEK zugreifen“, clientseitige Verschlüsselungsabläufe und Details zur Schlüsselableitung.
  • Interner Betrieb und Zugangskontrolle: Z. B. interne Berechtigungen, Schlüsselverwaltungsworkflows, Protokollbereinigung und Zugriffsüberwachung.
  • Absolute Sicherheit: Scans decken nur ihre spezifischen Regelsätze und sichtbaren Oberflächen ab; Sie ersetzen nicht die kontinuierliche Sicherheitstechnik und Reaktion auf Vorfälle.

Daher unterscheidet dieses Whitepaper zwischen „sichtbaren Sicherheitsgrundlinien“ und „Protokoll-/Implementierungsgrenzen“: Sichtbare Basislinien sind durch Beweise überprüfbar; Zero-Knowledge/E2EE-Grenzen werden durch Protokollspezifikationen und Client-Einschränkungen geregelt (siehe Kapitel 5 und verwandte Abschnitte).

12.2 Statusseite als Aggregation Hub

FileBolt verwendet /status als Aggregationszentrale für Beweislinks. Es ersetzt nicht die Berichte von Drittanbietern selbst, sondern bietet Benutzern und Prüfern eine einheitliche Navigation zur Durchführung wiederholter Überprüfungen.

  • MUST: Beweislinks auf der Statusseite verweisen auf maßgebliche Drittquellen (reproduzierbar).
  • SHOULD: Auf der Statusseite wird möglicherweise „Datum/Zeitstempel der letzten Überprüfung“ angezeigt, dies sollte jedoch nicht als dauerhafte, unveränderliche Schlussfolgerung dargestellt werden.
  • SHOULD: Wenn bestimmte Pfade (z. B. Download-/Entschlüsselungsseiten) strengere Header verwenden, können auf der Statusseite Beweise auf Pfadebene bereitgestellt werden (sofern von Tools von Drittanbietern unterstützt).

12.3 TLS-Konfigurationsnachweis

Der TLS-Beweis überprüft die HTTPS-Konfiguration, Protokollversionen, Zertifikatsketten und sichtbare Attribute. Beispiele hierfür sind:

Note: TLS-Beweise spiegeln die sichtbare Konfiguration zum „Zeitpunkt des Scans“ wider; Es beweist weder die End-to-End-Inhaltsgrenzen noch ob der Server auf den CEK zugreifen kann.

12.4 Nachweis von Sicherheitsheadern

Sicherheits-Header-Beweise überprüfen die Existenz und Konfiguration von Basisrichtlinien wie CSP, Referrer-Policy, X-Frame-Options, Permissions-Policy usw.

Recommendation: Wenn Download-/Entschlüsselungsseiten (z. B. /transfer, /d/**) strengere Richtlinien verwenden, sollte in der internen Dokumentation der Hinweis „Kritische Pfade sind strenger“ vermerkt werden, und wenn möglich, sollten Tools, die spezifische Pfadscans unterstützen, als ergänzende Beweise ausgewählt werden.

12.5 Umfassende Best-Practice-Scans

Umfassende Scans decken umfassendere Best-Practice-Prüfungen ab (z. B. HTTP-Konfiguration, häufige Schwachstellen, Caching- und Sicherheitsrichtlinienkombinationen). Diese bieten eine zusätzliche Überprüfung für Standort-Baselines, sind jedoch nicht gleichbedeutend mit Protokollimplementierungsprüfungen.

12.6 Mapping-Grundsätze: Beweis- und Anspruchs-IDs

  • MUST: Jeder überprüfbare Anspruch (Anspruch) hat eine eindeutige ID und einen stabilen Anker in der Master-Liste der Anspruchs-IDs.
  • MUST: Das Beweisfeld eines Anspruchs verweist nur auf maßgebliche Quellen (Berichtsseiten Dritter oder offizielle reproduzierbare Seiten) und DARF NICHT verweisen auf Screenshots, Zusammenfassungen oder nicht maßgebliche Reposts.
  • SHOULD: Die Statusseite kann als „Navigationssammlung“ für Beweise dienen, aber das primäre Beweisfeld eines Anspruchs sollte nach Möglichkeit auf die ursprüngliche Drittquelle verweisen.
  • MUST: Der Wortlaut der Behauptung muss mit dem Umfang der Beweise übereinstimmen und eine Überbewertung „sichtbarer Grundlinien“ als „absolute Sicherheitsgarantien“ vermeiden.

Hauptliste der Anspruchs-IDs (alleinige Autorität): /security-privacy-appendix-claim-ids

12.7 Zeitlichkeit und normative Sprache

Die Scanergebnisse von Drittanbietern ändern sich im Laufe der Zeit (aufgrund von Aktualisierungen der Scannerregeln, Änderungen der Site-Konfiguration, Zertifikatrotation usw.). Verweise auf Beweise sollten eine „überprüfbare, aber nicht absolute“ Formulierung verwenden.

  • SHOULD: Notieren Sie das „Datum/die Uhrzeit der letzten Überprüfung“ (falls zutreffend) auf der Statusseite oder in der Dokumentation und ermöglichen Sie Benutzern die Durchführung einer erneuten Überprüfung.
  • MUST: Vermeiden Sie „permanente/absolute“ Formulierungen; Verwenden Sie eine zum Beweisumfang passende Sprache, z. B. „Scan zeigt aktiviert/konform an.“
  • SHOULD: Wenn sich kritische Sicherheitsrichtlinien ändern (z. B. CSP-Verschärfung, TLS-Updates), notieren Sie dies im Changelog und verknüpfen Sie relevante Anspruchs-IDs.

12.8 Zugehörige Anspruchs-IDs (reserviert)

In diesem Kapitel geht es um „Grundsätze für Beweise und Kartierung durch Dritte“. Die entsprechenden Anspruchs-IDs werden im verwaltet Anhang: Hauptliste der Anspruchs-IDs als alleinige maßgebliche Quelle.