Logo

Whitepaper zu Sicherheit und Datenschutz (Übersicht)Kapitel 4

Kapitel 4 Authentifizierung, Autorisierung und Zugriffskontrolle

In diesem Kapitel werden das Identitätsmodell, die Token-Ebenen und die Zugriffskontrollgrenzen von FileBolt definiert. Beim Hochladen und Herunterladen werden kurzlebige Zugriffstoken (serverseitige Sitzungen, suchbasiert, ablaufend, bereichsbezogen) verwendet, um den Zugriff auf Chiffretext und Manifeste zu sperren. Absenderverwaltungsaktionen verwenden langlebige Anmeldetoken, die auf dem Client gespeichert sind. Das System MUSS den Widerruf unterstützen und Prüfdaten MÜSSEN nur für den Absender sichtbar sein.

4.0 Zusammenfassung

  • Kurzlebiges Zugriffstoken: Gates Chiffretext/Manifest-Zugriff; serverseitige Sitzung (Suche); MUSS an transferId gebunden werden; MUSS einen Gültigkeitsbereich haben; MUSS ablaufen.
  • Langlebiges Login-Token: Wird für die Absenderverwaltung verwendet (Löschen/Widerrufen/Prüfung); auf dem Client gespeichert; DARF von Empfängern NICHT für den Zugriff auf Chiffretext verwendet werden.
  • Schlüsseltrennung und Autorisierung: Token steuern nur den Zugriff auf Chiffretext; Die Entschlüsselungsfunktion stammt von CEK im URL-Fragment (siehe Kapitel 5).

4.1 Identitätsmodell

  • Das System unterstützt ein kostenpflichtiges Benutzeridentitätsmodell für die Absenderverwaltung.
  • Für die Anmeldung des Absenders kann ein einmaliger magischer Link verwendet werden. Der Client speichert nach erfolgreicher Authentifizierung ein langlebiges Login-Token.
  • Empfänger müssen kein Konto für Standard-Downloads haben (siehe UX-Dokumente); Der Zugriff ist Link-/Token-gesteuert.

4.2 Autorisierungsmodell und Token-Schichten

Es werden zwei Token-Typen mit strikter Verantwortungstrennung verwendet:

  1. Kurzlebiges Zugriffstoken (Sitzung/Suche): zum Hoch-/Herunterladen von Chiffretext und zum Lesen von Manifesten; MUSS an transferId gebunden werden; MUSS ablaufen; MUSS durch den Betrieb begrenzt werden.
  2. Langlebiges Login-Token: für Absenderverwaltungsaktionen; DARF KEINE Entschlüsselungsfunktion gewährt werden.

4.2.2 Scope-Beispiele

  • upload_chunk: Chiffretextblöcke für eine bestimmte Transfer-ID hochladen.
  • read_manifest: Manifest für eine bestimmte Transfer-ID lesen.
  • download_chunk: Chiffretextblöcke für eine bestimmte Transfer-ID herunterladen.

4.3 Upload-Autorisierung

  • Upload-APIs MÜSSEN den Token-Bereich und die TransferId-Bindung validieren, bevor sie Chiffretext akzeptieren.
  • Chunk-Uploads SOLLTEN gemäß (transferId, fileId, chunkIndex) idempotent sein.
  • Bei einem ungültigen Token oder einer Nichtübereinstimmung MUSS das System geschlossen werden.

4.4 Download-Autorisierung

  • Der Manifest- und Chiffretext-Zugriff MUSS ein gültiges Token mit Gültigkeitsbereich erfordern. Token MÜSSEN zeitlich begrenzt sein.
  • Empfänger DÜRFEN NICHT in der Lage sein, andere Übertragungen aufzuzählen oder auf Blöcke außerhalb der gebundenen Transfer-ID zuzugreifen.
  • Die Ratenbegrenzung KANN zur Missbrauchsprävention angewendet werden (siehe Kapitel 7), ohne die Wiederaufnahmefähigkeit zu beeinträchtigen.

4.5 Widerruf & vorzeitige Ungültigerklärung

  • Absender MÜSSEN in der Lage sein, eine Übertragung zu widerrufen; Durch den Widerruf MÜSSEN Token für den späteren Zugriff unbrauchbar gemacht werden.
  • Der Widerruf SOLLTE, soweit möglich, eine Bereinigung/TTL-Beschleunigung für Chiffretext auslösen.
  • Die Empfänger-UX MUSS den widerrufenen/abgelaufenen Status und den nächsten Schritt (Absender kontaktieren) deutlich angeben.

4.6 Audit- und Berechtigungsisolierung

  • Zustellungsnachweise (Downloads, Zählungen) MÜSSEN standardmäßig nur für den Absender sichtbar sein.
  • Audit-APIs MÜSSEN eine Absenderauthentifizierung erfordern und von Empfängerzugriffstokens isoliert sein.

4.7 Protokollierung und Minimierung sensibler Daten

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

4.8 Zugehörige Anspruchs-IDs