Logo

Whitepaper zu Sicherheit und Datenschutz (Übersicht)Kapitel 4

Kapitel 4 Authentifizierung, Autorisierung und Zugriffskontrolle

Dieses Kapitel definiert das Identitätsmodell, die Token-Ebenen und die Grenzen der Zugriffskontrolle von FileBolt. Upload und Download verwenden kurzlebige Zugriffstoken (serverseitige Sitzungen, per Lookup, ablaufend, bereichsbezogen), um den Zugriff auf Chiffretext und Manifest zu steuern. Verwaltungsaktionen des Absenders verwenden langlebige Login-Token, die auf dem Client gespeichert sind. Das System MUSS den Widerruf unterstützen, und Audit-Daten MÜSSEN ausschließlich für den Absender sichtbar sein.

4.0 Zusammenfassung

  • Kurzlebiges Zugriffstoken: steuert den Zugriff auf Chiffretext/Manifest; serverseitige Sitzung (Lookup); MUSS an die transferId gebunden sein; MUSS bereichsbezogen sein; MUSS ablaufen.
  • Langlebiges Login-Token: wird für die Absenderverwaltung verwendet (Löschen/Widerrufen/Audit); auf dem Client gespeichert; DARF von Empfängern NICHT für den Zugriff auf Chiffretext verwendet werden.
  • Trennung von Schlüsseln und Autorisierung: Token steuern nur den Zugriff auf Chiffretext; die Fähigkeit zur Entschlüsselung stammt vom CEK im URL-Fragment (siehe Kapitel 5).

4.1 Identitätsmodell

  • Das System unterstützt ein Identitätsmodell für zahlende Nutzer zur Verwaltung durch den Absender.
  • Die Anmeldung des Absenders KANN über einen einmaligen Magic Link erfolgen; der Client speichert nach erfolgreicher Authentifizierung ein langlebiges Login-Token.
  • Empfänger benötigen für Standard-Downloads kein Konto (siehe UX-Dokumentation); der Zugriff wird über Link/Token gesteuert.

4.2 Autorisierungsmodell & Token-Ebenen

Es werden zwei Token-Typen mit strikter Trennung der Zuständigkeiten verwendet:

  1. Kurzlebiges Zugriffstoken (Sitzung / Lookup): für Upload/Download von Chiffretext und das Lesen des Manifests; MUSS an die transferId gebunden sein; MUSS ablaufen; MUSS je Operation bereichsbezogen sein.
  2. Langlebiges Login-Token: für Verwaltungsaktionen des Absenders; DARF KEINE Entschlüsselungsfähigkeit gewähren.

4.2.2 Beispiele für Scopes

  • upload_chunk: Chiffretext-Chunk(s) für eine bestimmte transferId hochladen.
  • read_manifest: Manifest für eine bestimmte transferId lesen.
  • download_chunk: Chiffretext-Chunk(s) für eine bestimmte transferId herunterladen.

4.3 Upload-Autorisierung

  • Upload-APIs MÜSSEN Token-Scope und Bindung an die transferId prüfen, bevor sie Chiffretext annehmen.
  • Chunk-Uploads SOLLTEN je (transferId, fileId, chunkIndex) idempotent sein.
  • Bei ungültigem Token oder Abweichung MUSS das System nach dem Fail-Closed-Prinzip scheitern.

4.4 Download-Autorisierung

  • Der Zugriff auf Manifest und Chiffretext MUSS ein gültiges, bereichsbezogenes Token erfordern; Token MÜSSEN zeitlich begrenzt sein.
  • Empfänger DÜRFEN NICHT in der Lage sein, andere Übertragungen aufzulisten oder auf Chunks außerhalb der gebundenen transferId zuzugreifen.
  • Zur Missbrauchsabwehr KANN eine Ratenbegrenzung angewendet werden (siehe Kapitel 7), ohne die Fortsetzbarkeit zu beeinträchtigen.

4.5 Widerruf & vorzeitige Ungültigmachung

  • Absender MÜSSEN eine Übertragung widerrufen können; der Widerruf MUSS Token für späteren Zugriff unbrauchbar machen.
  • Der Widerruf SOLLTE, soweit machbar, eine Bereinigung bzw. beschleunigte TTL für Chiffretext auslösen.
  • Die Empfängeroberfläche MUSS den Status „widerrufen/abgelaufen“ und den nächsten Schritt (Absender kontaktieren) deutlich anzeigen.

4.6 Audit & Isolation von Berechtigungen

  • Zustellnachweise (Downloads, Zähler) MÜSSEN standardmäßig nur für den Absender sichtbar sein.
  • Audit-APIs MÜSSEN eine Authentifizierung des Absenders erfordern und MÜSSEN von den Zugriffstoken der Empfänger isoliert sein.

4.7 Protokollierung & Minimierung sensibler Daten

  • Logs DÜRFEN KEINE URL-Fragmente, CEK oder ableitbares Schlüsselmaterial enthalten.
  • Logs SOLLTEN personenbezogene Daten minimieren und sich auf sicherheitsrelevante Ereignisse konzentrieren (Token-Fehler, Widerruf, Ratenbegrenzungen).
  • Fehlermeldungen MÜSSEN handlungsorientiert sein, dürfen aber keine Geheimnisse preisgeben.

4.8 Zugehörige Claim-IDs