Logo

Whitepaper su sicurezza e privacy (panoramica)Capitolo 12

Capitolo 12: Prove verificabili di terze parti e pagina sullo stato

Oltre alle nostre dichiarazioni di progettazione interna, FileBolt fornisce prove di terze parti pubblicamente riproducibili (prove) per verificare le proprietà di sicurezza visibili (come la configurazione TLS, le policy di intestazione di sicurezza, ecc.). Questo capitolo definisce i tipi di prove, l'ambito applicabile, i collegamenti alle voci e i principi per mappare le prove sugli ID delle richieste.

12.0 Riepilogo

  • SHOULD: fornire collegamenti a prove pubbliche e riproducibili di terze parti per verificare le linee di base di sicurezza visibili (TLS, intestazioni, ecc.).
  • MUST: i collegamenti alle prove puntano solo a fonti autorevoli, mai a screenshot o repost secondari.
  • MUST: Definire esplicitamente l'ambito delle prove: le scansioni esterne non possono verificare direttamente i dettagli completi dell'implementazione di Zero-Knowledge/E2EE.
  • SHOULD: utilizzare la pagina di stato per aggregare i collegamenti alle prove, mentre i campi delle prove di reclamo dovrebbero puntare direttamente alla fonte originale di terze parti.

12.1 Tipi e ambito di prova

12.1.1 Cosa può essere verificato

Le prove di terze parti in genere verificano:

  • Configurazione del livello di trasporto: versioni TLS, catene di certificati, suite di crittografia, HSTS, ecc. (a seconda delle capacità dello scanner).
  • Politiche di sicurezza HTTP: Esistenza e configurazione di base di intestazioni come CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy, ecc.
  • Superficie Web visibile pubblicamente: configurazioni errate comuni, endpoint esposti e punteggi di sicurezza di base.

12.1.2 Cosa non può essere verificato direttamente

Le prove di terze parti in genere non possono verificare direttamente:

  • Correttezza a conoscenza zero: ad esempio, "Il server non può accedere a CEK", flussi di crittografia lato client e dettagli di derivazione della chiave.
  • Operazioni interne e controllo degli accessi: ad esempio, autorizzazioni interne, flussi di lavoro di gestione delle chiavi, sanificazione dei registri e controllo degli accessi.
  • Sicurezza assoluta: Le scansioni coprono solo i loro set di regole specifici e le superfici visibili; non sostituiscono la continua ingegneria della sicurezza e la risposta agli incidenti.

Pertanto, questo white paper distingue tra "linee di base di sicurezza visibili" e "limiti del protocollo/implementazione": Le linee di base visibili sono verificabili tramite prove; I limiti Zero-Knowledge/E2EE sono regolati dalle specifiche del protocollo e dai vincoli del client (vedere il Capitolo 5 e le sezioni correlate).

12.2 Pagina di stato come hub di aggregazione

FileBolt utilizza /status come hub di aggregazione per i collegamenti con le prove. Non sostituisce i report di terze parti stessi ma fornisce una navigazione unificata per consentire a utenti e revisori di eseguire verifiche ripetute.

  • MUST: i collegamenti alle prove nella pagina di stato rimandano a fonti autorevoli di terze parti (riproducibili).
  • SHOULD: la pagina di stato può indicare "Data/ora dell'ultimo controllo", ma non deve presentarlo come una conclusione permanente e immutabile.
  • SHOULD: se percorsi specifici (ad esempio pagine di download/decrittografia) utilizzano intestazioni più rigorose, è possibile che venga fornita prova a livello di percorso nella pagina di stato (se supportata da strumenti di terze parti).

12.3 Prova della configurazione TLS

L'evidenza TLS verifica la configurazione HTTPS, le versioni del protocollo, le catene di certificati e gli attributi visibili. Gli esempi includono:

Note: L'evidenza TLS riflette la configurazione visibile al "momento della scansione"; non dimostra i limiti del contenuto end-to-end né se il server può accedere al CEK.

12.4 Prova delle intestazioni di sicurezza

L'evidenza dell'intestazione di sicurezza verifica l'esistenza e la configurazione delle policy di base come CSP, Referrer-Policy, X-Frame-Options, Permissions-Policy, ecc.

Recommendation: Se si scaricano/decifrano pagine (ad es. /transfer, /d/**) utilizzano politiche più rigorose, la documentazione interna dovrebbe riportare la dicitura "I percorsi critici sono più rigorosi" e, ove possibile, gli strumenti che supportano scansioni di percorsi specifici dovrebbero essere selezionati come prova supplementare.

12.5 Scansioni complete basate sulle migliori pratiche

Le scansioni complete coprono controlli più ampi delle migliori pratiche (ad esempio, configurazione HTTP, punti deboli comuni, combinazioni di cache e criteri di sicurezza). Questi forniscono una verifica ausiliaria per le linee di base del sito ma non sono equivalenti agli audit di implementazione del protocollo.

12.6 Principi di mappatura: prove e ID delle richieste

  • MUST: ogni reclamo verificabile (reclamo) ha un ID univoco e un ancoraggio stabile nell'elenco principale degli ID dei reclami.
  • MUST: il campo Prova di un reclamo rimanda solo a fonti autorevoli (pagine di rapporti di terze parti o pagine ufficiali riproducibili) e NON DEVE puntare a screenshot, riepiloghi o repost non autorevoli.
  • SHOULD: la Pagina di stato può fungere da "raccolta di navigazione" per le prove, ma il campo principale delle prove di un reclamo dovrebbe puntare alla fonte originale di terze parti, quando possibile.
  • MUST: la formulazione delle affermazioni deve essere in linea con la portata delle prove, evitando di sopravvalutare le "basi di riferimento visibili" come "garanzie di sicurezza assolute".

Elenco principale degli ID reclamo (autorità unica): /security-privacy-appendix-claim-ids

12.7 Temporalità e linguaggio normativo

I risultati della scansione di terze parti cambiano nel tempo (a causa di aggiornamenti delle regole dello scanner, modifiche alla configurazione del sito, rotazione dei certificati, ecc.). I riferimenti alle prove dovrebbero utilizzare la frase "verificabile ma non assoluta".

  • SHOULD: registra la "data/ora dell'ultima verifica" (se applicabile) sulla pagina di stato o sulla documentazione e consente agli utenti di ripetere la verifica.
  • MUST: evitare la formulazione "permanente/assoluta"; utilizzare un linguaggio corrispondente all'ambito della prova, ad esempio "La scansione indica abilitato/conforme".
  • SHOULD: quando cambiano le politiche di sicurezza critiche (ad esempio, restringimento del CSP, aggiornamenti TLS), registralo nel registro delle modifiche e collega gli ID delle richieste pertinenti.

12.8 ID richiesta correlati (riservati)

Questo capitolo riguarda "Prove di terze parti e principi di mappatura". Gli ID richiesta corrispondenti vengono mantenuti nel file Appendice: Elenco principale degli ID delle richieste come unica fonte autorevole.