Logo

Whitepaper zu Sicherheit und Datenschutz (Übersicht)Kapitel 10

Kapitel 10: Protokollierung, Überwachung und Reaktion auf Vorfälle

Die Beobachtbarkeit von FileBolt muss mit den Zero-Knowledge-Grenzen in Einklang stehen: Das System muss Fehler erkennen, Angriffe aufspüren und die Leistung messen, ohne neue Wege für den Abfluss sensibler Daten zu schaffen. Dieses Kapitel legt fest, welche Ereignisse protokolliert werden, verbietet ausdrücklich die Aufzeichnung bestimmter Informationen, skizziert Methoden für Alarmierung und Anomalieerkennung und beschreibt den Prozess der Reaktion auf Sicherheitsvorfälle (Incident Response, IR) sowie die Grundsätze der externen Kommunikation.

10.0 Zusammenfassung

  • SOLLTE: Protokolle und Überwachung decken nur notwendige Betriebs- und Sicherheitsereignisse ab und nutzen Aggregation und Stichproben, um die Aufbewahrung roher Details zu minimieren.
  • DARF NICHT: Protokolle, APM oder Fehlerberichte dürfen weder CEK noch URL-Fragmente (location.hash) noch vollständige URLs mit Fragmenten enthalten.
  • DARF NICHT: Klartextinhalte, entschlüsselte Blöcke oder ableitbares Schlüsselmaterial dürfen nicht aufgezeichnet werden.
  • MUSS: Erkennung und Alarmierung für Enumeration, Brute Force, Traffic-Spitzen und anomale Muster einrichten und Maßnahmen zur Eindämmung bereithalten.
  • MUSS: Einen Prozess zur Reaktion auf Vorfälle aufrechterhalten (Triage, Eindämmung, Forensik, Behebung, Nachbereitung, Kommunikation).

10.1 Protokollierte Ereignisse (Minimalismus)

Systemprotokolle und Überwachung SOLLTEN nur die Ereignisse abdecken, die „für Betrieb und Sicherheit notwendig“ sind, und verhindern, dass Nutzerinhalte oder sensible Zugangsdaten in Observability-Systeme gelangen. Die Ereignisse werden in Lebenszyklus, Authentifizierung, Speicher/Netzwerk und Sicherheitsschutz eingeteilt; Aggregation wird empfohlen.

10.1.1 Ereignisse im Transfer-Lebenszyklus

  • Transfer erstellen (transferId erzeugen)
  • Upload eines Chunks abgeschlossen (auf Ebene des Chiffretexts protokolliert, nicht des Klartexts)
  • Manifest schreiben/aktualisieren
  • Bereinigung nach Ablauf, Löschung/Widerruf durch den Benutzer (einschließlich Auslösung und Abschluss der Bereinigungsaufgabe)
  • Download-Start/-Abschluss (gemessen auf Ebene des Chiffretext-Downloads)

10.1.2 Ereignisse bei Authentifizierung und Autorisierung

  • Ausstellung von Sitzungstoken, Validierungsfehler (Scope stimmt nicht, abgelaufen, widerrufen usw.)
  • Validierungsfehler bei langlebigen Anmeldetoken (Verwaltungsaktion verweigert)
  • Verdächtige Zugriffsmuster: auffällige Spitzen bei 401/403/404

Hinweis: Es werden nur „Ergebnis und Ursachencode“ aufgezeichnet. Token im Klartext, Authorization-Header im Klartext oder Signaturparameter im Klartext DÜRFEN NICHT aufgezeichnet werden.

10.1.3 Metriken zu Systemzustand und Leistung

  • Anfragelatenz (p50/p95/p99), Fehlerraten, Durchsatz
  • Fehlerraten beim Lesen/Schreiben im Objektspeicher, Fehlerraten beim Abruf vom Ursprungsserver, Anzahl der Wiederholungen
  • Auffälligkeiten bei Edge-Knoten, Rückstau in Warteschlangen, Erfolgsraten der Bereinigungsaufgaben im Hintergrund
  • Trends bei Bandbreite und Datenverkehr (aggregierte Dimensionen)

10.1.4 Ereignisse des Sicherheitsschutzes

  • Auslösung der Ratenbegrenzung, Treffer von WAF-/Firewall-Regeln
  • Auslösung von Schwellenwerten bei vermutetem Enumerations-/Brute-Force-Verhalten
  • Anomale Muster bei Parallelität und Datenverkehr (hohe Parallelität von derselben Quelle, ungewöhnlich stark nachgefragte Ressourcen)

10.1.5 Aggregation und Stichproben

  • SOLLTE: Zählwerte und Latenz-Quantile minütlich/stündlich aggregieren, um fein granulare Protokolle zu reduzieren.
  • SOLLTE: Bei häufigen erfolgreichen Anfragen Stichproben ziehen und notwendige Details nur für Fehler und anomale Pfade aufbewahren.
  • SOLLTE: Für anomale Ereignisse stabile Klassifizierungsfelder (z. B. eventType, reasonCode) beibehalten, um Audit und maschinelle Analyse zu erleichtern.

10.2 Verbotene Informationen (CEK, Fragment, Zugangsdaten)

Entscheidend für die Einhaltung der Zero-Knowledge-Zusage ist, die Richtlinie „Verbot sensibler Daten“ in allen Observability-Systemen strikt durchzusetzen. Diese Richtlinie MUSS Folgendes abdecken: Server-Protokolle, APM, Fehlerberichte, Überwachung durch Dritte, Client-Protokolle und die Ausgabe der Browserkonsole.

10.2.1 Serverseitig DÜRFEN NICHT aufgezeichnet werden

  • CEK (Content Encryption Key) und jegliches ableitbare Material
  • URL-Fragment (#...), location.hash und vollständige URLs mit Fragmenten
  • Klartextinhalte: Klartext von Dateien, Vorschauinhalte, entschlüsselte Blöcke oder beliebige Klartext-Zusammenfassungen
  • Zugangsdaten im Klartext: Sitzungstoken, langlebige Token, Authorization-Header im Klartext, Signaturfelder im Klartext in signierten URLs

Falls für die Fehlersuche URLs protokolliert werden müssen: MUSS bereinigt werden (Fragment entfernen; sensible Query-Parameter schwärzen oder entfernen) und dies auf Code-Ebene durchgesetzt werden (nicht auf manuelle Konventionen vertrauen).

10.2.2 Clientseitig DÜRFEN NICHT aufgezeichnet werden

  • location.href (kann ein Fragment enthalten) in Produktionsumgebungen nicht ausgeben
  • URLs mit Fragmenten, CEK oder noncePrefix nicht in Fehlerberichte aufnehmen
  • Debug-Protokolle und Ausgaben der Entwicklertools sollten standardmäßig deaktiviert oder minimiert sein

SOLLTE: Im Frontend eine einheitliche Funktion zum Protokollieren/Melden kapseln, die vor der Ausgabe bzw. Meldung intern die URL bereinigt und sensible Felder herausfiltert.

10.3 Überwachungsmetriken & Alarme (Verfügbarkeit, Leistung, Sicherheit)

10.3.1 Alarme zu Verfügbarkeit und Leistung

  • Fehlerraten-Alarme: Spitzen bei 5xx, ungewöhnlicher Anstieg bei 4xx (Authentifizierungsfehler von Missbrauch unterscheiden)
  • Latenz-Alarme: Überschreitung der p95/p99-Schwellenwerte, regionale Auffälligkeiten beim Abruf vom Ursprungsserver
  • Speicher-Alarme: Anstieg der Schreibfehler im Objektspeicher, Lese-Timeouts
  • Alarme zu Bereinigungsaufgaben: Rückstau bei der Bereinigung nach Ablauf, übermäßige Wiederholungen von Löschaufgaben

10.3.2 Sicherheitsalarme

  • Ungewöhnlicher Anstieg der Trefferquote der Ratenbegrenzung
  • Häufige 401/403/404 von derselben Quelle, vermutete Enumeration/Brute Force
  • Ungewöhnliche Download-Bandbreite/Parallelität bei einer einzelnen Ressource, vermutete Traffic-Flut oder Hotlinking
  • Kritische Richtlinienänderungen (z. B. WAF-Regeln, CSP-/Header-Änderungen) sollten Änderungs-Audits und Alarme auslösen (falls zutreffend)

10.3.3 Steuerung der Alarmierung

  • SOLLTE: Alarme kategorisieren (P0/P1/P2) und Rotations-/Eskalationspfade festlegen.
  • SOLLTE: Bei verrauschten Metriken Entprellung bzw. Fensteraggregation anwenden, um Alarmmüdigkeit zu vermeiden.
  • SOLLTE: Jedem Alarm minimale Diagnoseinformationen (Ursachencode, Trenddiagramm, betroffene Region/Route) beifügen, ohne sensible Daten.

10.4 Anomalieerkennung & Erkennung von Missbrauch

Dateitransfer-Dienste sind naturgemäß Risiken durch Enumeration, Brute Force, Traffic-Fluten und Ressourcenmissbrauch ausgesetzt. Dieser Abschnitt skizziert erkennbare Signale und Grundsätze für die Reaktion. Konkrete Schwellenwerte und Strategien müssen dynamisch an Geschäftsumfang und die Kosten von Fehlalarmen angepasst werden.

10.4.1 Typische Anomaliemuster

  • Enumeration: massenhaftes Abtasten von transferId / Ressourcenpfaden in kurzer Zeit, Spitzen bei 404/401/403.
  • Brute Force: häufige Versuche bei Kurzcodes/Passwörtern/Token, auffällige Kurve der Fehlerrate.
  • Traffic-Flut: ungewöhnliche Bandbreite bei einer einzelnen Ressource, massenhaft parallele Verbindungen von derselben Quelle, wiederholte Downloads.
  • Protokollanomalien: unplausible Reihenfolge von Chunks, doppelte Uploads, häufige Abbrüche/Wiederholungen, auffällige UA-Muster.

10.4.2 Gegenmaßnahmen (Grundsätze)

  • SOLLTE: Ratenbegrenzung, gestufte Sperren, Challenge-Mechanismen (falls zutreffend), dynamische Richtlinien auf Basis von ASN/Region/Fingerprint.
  • SOLLTE: Für Pfade, die empfindlich auf Fehlalarme reagieren (normale Benutzer laden eventuell häufig herunter), mildere Strategien einsetzen (z. B. Verzögerung, abgestufte Drosselung).
  • MUSS: Prüfbare Auslöser (Ursachencode, Schwellenwert-Kategorie) für ergriffene Maßnahmen aufbewahren und Support-Kanäle bereitstellen (falls zutreffend).

10.5 Prozess der Reaktion auf Vorfälle

FileBolt MUSS einen Prozess zur Reaktion auf Sicherheitsvorfälle (Incident Response, IR) einrichten, um schnelle Schadensbegrenzung, Nachvollziehbarkeit und transparente Kommunikation sicherzustellen. Ereignisse, die Zero-Knowledge-Zusagen beeinträchtigen könnten (z. B. XSS, Einschleusung über die Lieferkette, Preisgabe von Fragmenten in Protokollen), sollten mit höchster Priorität behandelt werden.

  1. Triage: nach Auswirkungsumfang und Schweregrad einordnen (z. B. P0/P1/P2), Eskalationspfade und Verantwortliche festlegen.
  2. Eindämmung: Risikoquellen schnell isolieren (Angriffsquellen sperren, Funktionen vorübergehend deaktivieren, Richtlinien verschärfen, Schlüssel/Token rotieren).
  3. Forensik & Nachbereitung: Zeitachse anhand minimaler Protokolle und Metriken rekonstruieren; Entscheidungen, Auswirkungen, Behebung und Verbesserungen dokumentieren.
  4. Behebung & Verifizierung: Patches ausrollen, Regressionstests, Sicherheitsverifizierung, bei Bedarf erneuter Scan durch Dritte.
  5. Kommunikation & Offenlegung: Nutzern und Öffentlichkeit transparent erklären, ohne die Angriffsfläche zu vergrößern; bei Bedarf Vorfallberichte auf der Status-Seite veröffentlichen.

Die externe Kommunikation sollte klären: ob Schlüsselmaterial oder Klartext möglicherweise offengelegt wurde, den Auswirkungsumfang, ergriffene Maßnahmen und Handlungen, die Benutzer ggf. ausführen müssen.

10.6 Datenaufbewahrung & Zugriffskontrolle

Protokoll- und Überwachungsdaten sind selbst sensible Werte. Es sollten möglichst kurze sinnvolle Aufbewahrungsfristen und eine Zugriffskontrolle nach dem Prinzip der minimalen Rechte gelten, um das Risiko von Abfluss und Missbrauch zu minimieren.

  • SOLLTE: Für Protokollarten unterschiedliche Aufbewahrungsfristen festlegen (etwas länger für Fehler und Sicherheitsereignisse, kürzer oder gar keine Aufbewahrung für Details erfolgreicher Anfragen).
  • SOLLTE: Für Protokoll- und Überwachungsplattformen Zugriff nach dem Prinzip der minimalen Rechte (RBAC) verwenden und Zugriffs-Audits aufbewahren.
  • SOLLTE: Beim Exportieren/Teilen von Protokollen bereinigen und minimieren (sensible Zugangsdaten und personenbezogene Daten dürfen nicht enthalten sein).

10.7 Grundsätze für Überwachung und Integration durch Dritte

Tools von Drittanbietern für APM/Fehlerverfolgung erfassen standardmäßig möglicherweise URLs, Header, Formularfelder und Geräteinformationen. Wird Überwachung durch Dritte eingesetzt, ist sicherzustellen, dass ihre Erfassungsgrenzen die Zero-Knowledge-Zusagen nicht verletzen.

  • MUSS: Auf Download-/Entschlüsselungsseiten keine Skripte von Drittanbietern laden (entspricht Kapitel 9).
  • MUSS: Die Erfassung durch Dritte ausdrücklich konfigurieren: keine Fragmente, keine sensiblen Header im Klartext, keine Klartextinhalte.
  • SOLLTE: Die URL-Bereinigung für Meldungen vereinheitlichen; Payloads, die möglicherweise sensible Felder enthalten, verbieten oder stark maskieren.
  • SOLLTE: Serverseitig aggregierte Metriken gegenüber feingranularem clientseitigem Tracking bevorzugen, um die Erfassungsfläche am Endpunkt zu verringern.

10.8 Zugehörige Claim-IDs (reserviert)

Dieses Kapitel behandelt „Verbot der Protokollierung sensibler Daten, Alarmierung und IR, Einschränkungen für Überwachung durch Dritte“. Die entsprechenden Claim-IDs werden in den Anhang: Gesamtliste der Claim-IDs als alleinige maßgebliche Quelle aufgenommen.