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 übereinstimmen: Das System muss Fehler identifizieren, Angriffe erkennen und die Leistung quantifizieren ohne neue Vektoren für sensible Datenlecks einzuführen. Dieses Kapitel definiert, welche Ereignisse protokolliert werden, verbietet ausdrücklich die Aufzeichnung bestimmter Informationen, beschreibt Alarmierungs- und Anomalieerkennungsmethoden, und beschreibt den Security Incident Response (IR)-Prozess und die Grundsätze der externen Kommunikation.

10.0 Zusammenfassung

  • SHOULD: Protokolle und Überwachung decken nur notwendige Betriebs- und Sicherheitsereignisse ab und nutzen Aggregation und Stichproben, um die Aufbewahrung roher Details zu minimieren.
  • DARF NICHT: Alle Protokolle, APM oder Fehlerberichte dürfen keine CEK- oder URL-Fragmente enthalten (location.hash) oder vollständige URLs, die Fragmente enthalten.
  • DARF NICHT: Zeichnen Sie keine Klartextinhalte, entschlüsselten Blöcke oder ableitbaren Schlüsselmaterial auf.
  • MUST: Etablieren Sie die Erkennung und Warnung bei Aufzählung, Brute-Force, Traffic-Spitzen und anomalen Mustern und setzen Sie Eindämmungsmaßnahmen ein.
  • MUST: Aufrechterhaltung eines Prozesses zur Reaktion auf Vorfälle (Triage, Eindämmung, Forensik, Behebung, Überprüfung, Kommunikation).

10.1 Protokollierte Ereignisse (Minimalismus)

Systemprotokolle und Überwachung SOLLTEN nur die Reihe von Ereignissen abdecken, die „für den Betrieb und die Sicherheit notwendig“ sind, und die Aufnahme von Benutzerinhalten oder sensiblen Anmeldeinformationen in Observability-Systeme vermeiden. Ereignisse werden in Lebenszyklus, Authentifizierung, Speicher/Netzwerk und Sicherheitsschutz kategorisiert, wobei eine Aggregation empfohlen wird.

10.1.1 Lebenszyklusereignisse übertragen

  • Übertragung erstellen (transferId generieren)
  • Block hochladen abgeschlossen (protokolliert auf Chiffretextebene, nicht auf Klartextebene)
  • Manifest schreiben/aktualisieren
  • Bereinigung nach Ablauf, Löschung/Sperrung von Benutzern (einschließlich Auslöser und Abschluss der Bereinigungsaufgabe)
  • Start/Abschluss des Downloads (gemessen auf Chiffretext-Download-Ebene)

10.1.2 Authentifizierungs- und Autorisierungsereignisse

  • Ausstellung eines Sitzungstokens, Validierungsfehler (Bereichskonflikt, abgelaufen, widerrufen usw.)
  • Langzeit-Anmeldetoken-Validierungsfehler (Administratoraktion verweigert)
  • Verdächtige Zugriffsmuster: Anomale Spitzen bei 401/403/404

Hinweis: Notieren Sie nur „Ergebnis- und Ursachencode“. DARF NICHT Klartext des Datensatz-Tokens, Klartext des Autorisierungsheaders oder Klartext des Signaturparameters.

10.1.3 Systemzustands- und Leistungsmetriken

  • Anforderungslatenz (p50/p95/p99), Fehlerraten, Durchsatz
  • Lese-/Schreibfehlerraten im Objektspeicher, Fehlerraten beim Ursprungsabruf, Anzahl der Wiederholungen
  • Edge-Knotenanomalien, Warteschlangenrückstände, Erfolgsraten von Hintergrundbereinigungsaufgaben
  • Bandbreiten- und Verkehrstrends (aggregierte Dimensionen)

10.1.4 Sicherheitsschutzereignisse

  • Ratenbegrenzende Auslöser, WAF-/Firewall-Regeltreffer
  • Schwellenwertauslöser für vermutetes Aufzählungs-/Brute-Force-Verhalten
  • Anomale Parallelität und Verkehrsmuster (hohe Parallelität aus derselben Quelle, ungewöhnliche Ressourcenwärme)

10.1.5 Aggregation und Stichprobenerhebung

  • SHOULD: Aggregieren Sie Anzahlen und Latenzquantile nach Minute/Stunde, um granulare Protokolle zu reduzieren.
  • SHOULD: Beispiel für hochfrequente erfolgreiche Anfragen, wobei die notwendigen Details nur für Fehler und anomale Pfade gespeichert werden.
  • SHOULD: Behalten Sie stabile Klassifizierungsfelder (z. B. eventType, reasonCode) für anomale Ereignisse bei, um die Prüfung und maschinelle Analyse zu erleichtern.

10.2 Verbotene Informationen (CEK, Fragment, Anmeldeinformationen)

Ein Schlüssel zur Aufrechterhaltung des Zero-Knowledge-Engagements ist die strikte Durchsetzung einer Richtlinie zum „Verbot sensibler Daten“ in allen Observability-Systemen. Diese Richtlinie muss Folgendes abdecken: Serverprotokolle, APM, Fehlerberichterstattung, Überwachung durch Drittanbieter, Clientprotokolle und Browserkonsolenausgabe.

10.2.1 Serverseitig DARF NICHT aufgezeichnet werden

  • CEK (Inhaltsverschlüsselungsschlüssel) und jegliches abgeleitete Material
  • URL-Fragment (#...), location.hashund vollständige URLs, die Fragmente enthalten
  • Klartextinhalt: Datei-Klartext, Vorschau des Inhalts, entschlüsselte Blöcke oder beliebige Klartext-Zusammenfassungen
  • Klartext für vertrauliche Anmeldeinformationen: Sitzungstoken, Langzeittoken, Klartext des Autorisierungsheaders, Klartext des Signaturfelds in signierten URLs

Wenn zum Debuggen Protokollierungs-URLs erforderlich sind: MUST Bereinigen (Fragment entfernen; vertrauliche Abfragen redigieren oder entfernen) und dies auf Codeebene erzwingen (ohne auf manuelle Konventionen angewiesen zu sein).

10.2.2 Clientseitig DARF NICHT aufgezeichnet werden

  • Nicht drucken location.href (kann Fragmente enthalten) in Produktionsumgebungen
  • Fügen Sie keine URLs mit Fragmenten, CEK oder NoncePrefix in Fehlerberichte ein
  • Debug-Protokolle und Entwicklungstool-Ausgaben sollten standardmäßig deaktiviert oder minimiert sein

SHOULD: Kapseln Sie eine einheitliche Protokoll-/Berichtsfunktion im Frontend, die vor der Ausgabe/Berichterstellung intern eine URL-Bereinigung und eine Filterung vertraulicher Felder durchführt.

10.3 Überwachungsmetriken und Warnungen (Verfügbarkeit, Leistung, Sicherheit)

10.3.1 Verfügbarkeits- und Leistungswarnungen

  • Fehlerratenwarnungen: Spitzenwerte bei 5xx, ungewöhnlicher Anstieg bei 4xx (unterscheidet zwischen Authentifizierungsfehlern und Missbrauch)
  • Latenzwarnungen: p95/p99-Schwellenwertverletzungen, regionale Abrufanomalien
  • Speicherwarnungen: Anstieg von Objektspeicher-Schreibfehlern und Lese-Timeouts
  • Warnungen zu Bereinigungsaufgaben: Abgelaufener Bereinigungsrückstand, übermäßige Wiederholungsversuche bei Löschaufgaben

10.3.2 Sicherheitswarnungen

  • Ungewöhnlicher Anstieg der Rate-Limit-Trefferquote
  • Hochfrequenz 401/403/404 aus derselben Quelle, Verdacht auf Aufzählung/Brute Force
  • Anormale Download-Bandbreite/Gleichzeitigkeit einer einzelnen Ressource, Verdacht auf Datenverkehrsüberflutung oder Hotlinking
  • Kritische Richtlinienänderungen (z. B. WAF-Regeln, CSP-/Header-Änderungen) sollten Änderungsprüfungen und Warnungen (falls zutreffend) auslösen.

10.3.3 Alert-Governance

  • SHOULD: Kategorisieren Sie Warnungen (P0/P1/P2) mit Rotations-/Eskalationspfaden.
  • SHOULD: Entprellungs-/Fensteraggregation auf verrauschte Metriken anwenden, um Alarmmüdigkeit zu vermeiden.
  • SHOULD: Fügen Sie jeder Warnung minimale Diagnoseinformationen (Ursachencode, Trenddiagramm, betroffene Region/Route) hinzu, ausgenommen vertrauliche Daten.

10.4 Anomalieerkennung und Missbrauchserkennung

Bei Dateiübertragungsdiensten besteht natürlich die Gefahr von Aufzählung, Brute-Force, Verkehrsüberschwemmung und Ressourcenmissbrauch. In diesem Abschnitt werden erkennbare Signale und Reaktionsprinzipien beschrieben. Spezifische Schwellenwerte und Strategien müssen je nach Unternehmensgröße und falsch positiven Kosten dynamisch angepasst werden.

10.4.1 Häufige Anomaliemuster

  • Enumeration: Massive Prüfung von TransferId-/Ressourcenpfaden in kurzer Zeit, Spitzen bei 404/401/403.
  • Brutale Gewalt: Häufige Versuche mit Kurzcodes/Passwörtern/Tokens, ungewöhnliche Fehlerratenkurve.
  • Verkehrsüberschwemmung: Ungewöhnliche Bandbreite für eine einzelne Ressource, massive gleichzeitige Verbindungen von derselben Quelle, wiederholte Downloads.
  • Protokollanomalien: Irrationale Blockreihenfolge, doppelte Uploads, häufige Unterbrechungen/Wiederholungsversuche, abnormale UA-Muster.

10.4.2 Minderungsstrategien (Grundsätze)

  • SHOULD: Ratenbegrenzung, abgestufte Sperrung, Herausforderungsmechanismen (falls zutreffend), dynamische Richtlinien basierend auf ASN/Region/Fingerabdruck.
  • SHOULD: Übernehmen Sie sanftere Strategien (z. B. Verzögerung, segmentierte Drosselung) für Pfade, die anfällig für Fehlalarme sind (normale Benutzer laden möglicherweise häufig herunter).
  • MUST: Behalten Sie überprüfbare Auslöser (Ursachencode, Schwellenwertkategorie) für ergriffene Maßnahmen bei und stellen Sie Supportkanäle bereit (falls zutreffend).

10.5 Reaktionsprozess auf Vorfälle

FileBolt MUSS einen Security Incident Response (IR)-Prozess einrichten, um eine schnelle Schadenskontrolle, Überprüfbarkeit und transparente Kommunikation zu gewährleisten. Ereignisse, die sich möglicherweise auf Zero-Knowledge-Verpflichtungen auswirken (z. B. XSS, Supply-Chain-Injection, Protokollverlust von Fragmenten), sollten mit höchster Priorität behandelt werden.

  1. Triage: Nach Umfang und Schwere der Auswirkungen klassifizieren (z. B. P0/P1/P2), Eskalationspfade und Eigentümer definieren.
  2. Containment: Risikoquellen schnell isolieren (Angriffsquellen verbieten, Funktionen vorübergehend deaktivieren, Richtlinien verschärfen, Schlüssel/Token wechseln).
  3. Forensik & Überprüfung: Zeitleiste basierend auf minimalen Protokollen und Metriken rekonstruieren; Dokumentieren Sie Entscheidungen, Auswirkungen, Abhilfemaßnahmen und Verbesserungen.
  4. Behebung und Überprüfung: Bereitstellung von Patches, Regressionstests, Sicherheitsüberprüfung, erneute Prüfung von Drittanbieter-Scans, falls erforderlich.
  5. Kommunikation und Offenlegung: Benutzer und Öffentlichkeit transparent erklären, ohne die Angriffsfläche zu vergrößern; Veröffentlichen Sie ggf. Vorfallberichte auf der Statusseite.

Die externe Kommunikation sollte klären: ob Schlüsselmaterial oder Klartext möglicherweise offengelegt wurde, Umfang der Auswirkungen, ergriffene Maßnahmen und Maßnahmen, die Benutzer ergreifen müssen (falls vorhanden).

10.6 Datenaufbewahrung und Zugriffskontrolle

Protokolle und Überwachungsdaten sind selbst sensible Vermögenswerte. Zur Minimierung von Leckage- und Missbrauchsrisiken sollten die kürzesten nützlichen Aufbewahrungsfristen und die Zugriffskontrolle mit den geringsten Privilegien angewendet werden.

  • SHOULD: Legen Sie unterschiedliche Aufbewahrungszeiträume für Protokolltypen fest (etwas länger für Fehler und Sicherheitsereignisse, kürzere oder keine Aufbewahrungszeit für erfolgreiche Anfragedetails).
  • SHOULD: Verwenden Sie Least Privilege Access (RBAC) für Protokoll- und Überwachungsplattformen und behalten Sie Zugriffsprüfungen bei.
  • SHOULD: Führen Sie beim Exportieren/Freigeben von Protokollen eine Bereinigung und Minimierung durch (verbieten Sie die Übertragung vertraulicher Anmeldeinformationen und personenbezogener Daten).

10.7 Grundsätze zur Überwachung und Integration durch Dritte

APM-/Fehlerverfolgungstools von Drittanbietern erfassen möglicherweise standardmäßig URLs, Header, Formularfelder und Geräteinformationen. Wenn Sie die Überwachung durch Dritte nutzen, stellen Sie sicher, dass die Erfassungsgrenzen nicht gegen die Zero-Knowledge-Verpflichtungen verstoßen.

  • MUST: Laden Sie keine Skripts von Drittanbietern auf Download-/Entschlüsselungsseiten (im Einklang mit Kapitel 9).
  • MUST: Drittanbietersammlung explizit konfigurieren: Keine Fragmente, kein sensibler Header-Klartext, kein Klartextinhalt.
  • SHOULD: URL-Bereinigung für die Berichterstellung vereinheitlichen; Nutzlasten, die möglicherweise sensible Felder enthalten, verbieten oder stark maskieren.
  • SHOULD: Priorisieren Sie serverseitige aggregierte Metriken gegenüber clientseitigem granularem Tracking, um die Erfassungsfläche für Endpunkte zu reduzieren.

10.8 Zugehörige Anspruchs-IDs (reserviert)

In diesem Kapitel geht es um „Verbot der Protokollierung sensibler Daten, Warnungen und IR sowie Einschränkungen bei der Überwachung durch Dritte“. Entsprechende Anspruchs-IDs werden dem hinzugefügt Anhang: Hauptliste der Anspruchs-IDs als alleinige maßgebliche Quelle.