Logo

Whitepaper su sicurezza e privacy (panoramica)Capitolo 4

Capitolo 4 Autenticazione, autorizzazione e controllo degli accessi

Questo capitolo definisce il modello di identità di FileBolt, i livelli di token e i confini del controllo degli accessi. Caricamento e download usano token di accesso di breve durata (sessioni lato server, basate su lookup, con scadenza e ambito limitato) per regolare l'accesso al testo cifrato e al manifest. Le azioni di gestione del mittente usano token di login di lunga durata memorizzati sul client. Il sistema DEVE supportare la revoca e i dati di audit DEVONO essere visibili solo al mittente.

4.0 Riepilogo

  • Token di accesso di breve durata: regola l'accesso al testo cifrato/manifest; sessione lato server (lookup); DEVE essere associato al transferId; DEVE avere un ambito limitato; DEVE scadere.
  • Token di login di lunga durata: usato per la gestione del mittente (eliminazione/revoca/audit); memorizzato sul client; NON DEVE essere usato dai destinatari per accedere al testo cifrato.
  • Separazione tra chiavi e autorizzazione: i token controllano solo l'accesso al testo cifrato; la capacità di decifrare deriva dalla CEK nel frammento dell'URL (vedi il capitolo 5).

4.1 Modello di identità

  • Il sistema supporta un modello di identità per utenti a pagamento ai fini della gestione del mittente.
  • L'accesso del mittente PUÒ usare un magic link monouso; il client memorizza un token di login di lunga durata dopo l'autenticazione riuscita.
  • I destinatari non hanno bisogno di un account per i download predefiniti (vedi la documentazione UX); l'accesso è controllato tramite link/token.

4.2 Modello di autorizzazione e livelli di token

Si usano due tipi di token, con una rigorosa separazione delle responsabilità:

  1. Token di accesso di breve durata (sessione / lookup): per il caricamento/download del testo cifrato e la lettura del manifest; DEVE essere associato al transferId; DEVE scadere; DEVE avere un ambito limitato per operazione.
  2. Token di login di lunga durata: per le azioni di gestione del mittente; NON DEVE concedere la capacità di decifrare.

4.2.2 Esempi di ambito

  • upload_chunk: carica uno o più blocchi di testo cifrato per uno specifico transferId.
  • read_manifest: legge il manifest di uno specifico transferId.
  • download_chunk: scarica uno o più blocchi di testo cifrato per uno specifico transferId.

4.3 Autorizzazione al caricamento

  • Le API di caricamento DEVONO convalidare l'ambito del token e l'associazione al transferId prima di accettare il testo cifrato.
  • I caricamenti dei blocchi DOVREBBERO essere idempotenti per (transferId, fileId, chunkIndex).
  • In caso di token non valido o di mancata corrispondenza, il sistema DEVE bloccarsi (fail closed).

4.4 Autorizzazione al download

  • L'accesso al manifest e al testo cifrato DEVE richiedere un token valido e con ambito limitato; i token DEVONO avere una durata limitata.
  • I destinatari NON DEVONO poter enumerare altri trasferimenti né accedere a blocchi esterni al transferId associato.
  • Si PUÒ applicare una limitazione della frequenza per prevenire gli abusi (vedi il capitolo 7) senza compromettere la ripresa dei trasferimenti.

4.5 Revoca e invalidazione anticipata

  • I mittenti DEVONO poter revocare un trasferimento; la revoca DEVE rendere i token inutilizzabili per gli accessi successivi.
  • La revoca DOVREBBE avviare, ove possibile, la pulizia o l'accelerazione del TTL del testo cifrato.
  • L'UX per il destinatario DEVE indicare chiaramente lo stato revocato/scaduto e il passo successivo (contattare il mittente).

4.6 Audit e isolamento dei permessi

  • Le prove di consegna (download, conteggi) DEVONO essere visibili per impostazione predefinita solo al mittente.
  • Le API di audit DEVONO richiedere l'autenticazione del mittente e DEVONO essere isolate dai token di accesso dei destinatari.

4.7 Log e minimizzazione dei dati sensibili

  • I log NON DEVONO contenere frammenti di URL, CEK o materiale da cui si possano derivare chiavi.
  • I log DOVREBBERO ridurre al minimo i dati personali e concentrarsi sugli eventi rilevanti per la sicurezza (errori dei token, revoche, limiti di frequenza).
  • I messaggi di errore DEVONO essere utili per agire, ma non devono rivelare segreti.

4.8 ID delle affermazioni correlati