Sicurezza dell’API ProofSnap: dati ospitati nell’UE

Che cosa succede ai dati durante un’acquisizione

Un’acquisizione effettuata tramite l’API ProofSnap o la dashboard si articola in cinque fasi:

L’URL viene inviato tramite HTTPS, attraverso l’API con la propria chiave API oppure dalla dashboard.
Un browser in esecuzione sui server ProofSnap a Francoforte carica la pagina. Si connette soltanto a indirizzi pubblici. In modalità di produzione l’URL viene inoltre inviato all’Internet Archive, a meno che questa opzione non venga disattivata.
Per ogni file viene calcolata un’impronta SHA-256 e il manifest viene firmato. Soltanto l’impronta del manifest viene inviata ai calendari OpenTimestamps e, se si richiede una validazione temporale elettronica qualificata, a Disig a.s.
Il pacchetto sigillato viene archiviato cifrato a Francoforte, con una seconda copia in Irlanda dei pacchetti creati in modalità di produzione.
Il pacchetto può essere scaricato oppure, non appena è pronto, la sua disponibilità viene notificata con un webhook firmato.

Dove è ospitata l’API

API: Amazon Web Services nell’UE, Francoforte (eu-central-1).
Dati dell’account e delle acquisizioni: Google Cloud Firestore nell’UE, Francoforte (europe-west3).
Accesso: Firebase Authentication, un servizio Google gestito su scala globale.
Pacchetti di prove: Amazon S3 nell’UE, Francoforte (eu-central-1), con una seconda copia in Irlanda (eu-west-1) di ogni pacchetto creato in modalità di produzione.

Che cosa viene trattato fuori dall’UE

I pacchetti di prove e i dati delle acquisizioni restano a Francoforte e in Irlanda. Da servizi situati fuori dall’UE possono essere trattati soltanto i dati elencati di seguito:

L’URL acquisito, che per impostazione predefinita viene inviato all’Internet Archive per le acquisizioni in modalità di produzione (l’opzione si può disattivare).
L’impronta del manifest, inviata ai calendari pubblici OpenTimestamps. Non viene inviato alcun contenuto dei file.
Il nome host del sito acquisito, risolto tramite Google Public DNS e Cloudflare DNS e cercato nei servizi pubblici RDAP e WHOIS.
I dati di autenticazione (credenziali di accesso) in Firebase Authentication e i dati di pagamento presso Stripe.

Acquisizione lato server

La pagina viene caricata e acquisita sui server ProofSnap, non sul computer dell’utente. Si invia un URL e si riceve un pacchetto di prove sigillato. Il browser di acquisizione si connette soltanto a indirizzi pubblici: gli indirizzi privati, quelli di loopback e quelli dei servizi di metadati del cloud vengono rifiutati, anche dopo un reindirizzamento.

Per impostazione predefinita, quando un’acquisizione viene effettuata in modalità di produzione, il suo URL viene inviato anche all’Internet Archive (web.archive.org) affinché possa essere creata un’istantanea pubblica indipendente. Gli URL che sembrano privati, come i link di accesso, di reimpostazione della password e di condivisione, oppure che contengono un token, non vengono mai inviati. Un URL con una stringa di query viene inviato soltanto se l’opzione di acquisizione external_archive è impostata su true. Se la si imposta su false, l’archiviazione viene disattivata del tutto. L’esito viene registrato nel pacchetto.

Come viene sigillato ogni pacchetto

Impronte: Per ogni file del pacchetto di prove viene calcolata un’impronta SHA-256, elencata in manifest.json.
Firma: Il file manifest.json viene firmato con una chiave RSA-4096 generata solo per quel pacchetto. La chiave privata viene eliminata dopo la firma e la chiave pubblica è inclusa nel pacchetto.
Ancoraggio temporale su Bitcoin: L’impronta del manifest viene inviata ai calendari OpenTimestamps per essere ancorata alla blockchain Bitcoin. Una volta confermato l’ancoraggio, la ricevuta OpenTimestamps completa viene archiviata insieme al pacchetto. Se non è possibile ottenerla, la circostanza viene annotata nel pacchetto.
Validazione temporale qualificata: Su richiesta (solo con chiavi di produzione, con addebito per singola validazione), una validazione temporale elettronica qualificata (RFC 3161) viene ottenuta da Disig a.s., prestatore di servizi fiduciari qualificato iscritto nell’elenco di fiducia dell’UE. Se non è possibile aggiungere la validazione temporale, la circostanza viene annotata nel pacchetto.
Verifica offline: Ogni pacchetto contiene script di verifica (verify.sh per macOS e Linux, verify.ps1 per Windows) che lo controllano offline, senza dipendere da ProofSnap.

Registro di emissione

ProofSnap registra l’impronta di ogni manifest che emette. Chiunque può cercare un’impronta con GET /v1/ledger/{hash}; una corrispondenza conferma che ProofSnap ha emesso esattamente quel pacchetto.

Seconda copia

Ogni pacchetto di prove creato in modalità di produzione viene copiato in un bucket Amazon S3 separato, in un’altra regione dell’UE (Irlanda). GET /v1/captures/{id} indica lo stato della copia per ogni acquisizione. La copia viene eliminata insieme all’originale.

Periodo di conservazione

Le prove vengono conservate per 10 anni dalla data di acquisizione. Per una pagina acquisita in modo programmato, il periodo decorre dall’ultima volta in cui la versione acquisita è risultata ancora attuale:

Ogni controllo che rileva la pagina invariata prolunga il periodo di conservazione dell’acquisizione corrente.
Per un’acquisizione sostituita da una versione più recente, il periodo decorre dal momento della sostituzione.

Al termine di un abbonamento si dispone di 30 giorni per scaricare tutti i dati. Il piano Archive only mantiene le prove consultabili, scaricabili e verificabili anche dopo che si smette di effettuare acquisizioni.

Eliminazione

Un pacchetto eliminato nella dashboard o tramite l’API viene prima spostato nel cestino, da cui può essere ripristinato entro 30 giorni. Trascorso questo termine, tutte le versioni archiviate vengono rimosse da entrambe le copie. Se si sceglie l’eliminazione definitiva, il pacchetto viene rimosso immediatamente. Allo scadere del periodo di conservazione, oppure alla scadenza dei 30 giorni concessi a un account per scaricare i propri dati, tutte le versioni archiviate vengono rimosse allo stesso modo. Un’acquisizione sottoposta a blocco per controversia legale non può essere eliminata finché il vincolo è attivo. Resta traccia di chi ha eliminato il pacchetto e di quando lo ha fatto, ma non del suo contenuto.

Controllo degli accessi

Chiavi API: Archiviate soltanto come impronte SHA-256. La chiave completa viene mostrata una sola volta, al momento della creazione. Una chiave revocata smette di funzionare entro 60 secondi. Con il piano Website Archive le chiavi API sono di sola lettura: consentono di elencare, scaricare e verificare le acquisizioni e di gestire le sottoscrizioni webhook. Con questo piano, acquisizioni e programmazioni si avviano dalla dashboard.
Accesso alla dashboard: Firebase Authentication. Prima di poter creare chiavi, avviare acquisizioni o acquistare un piano è necessario confermare l’indirizzo e-mail.
Cronologia degli accessi: Quando una persona diversa dall’autore di un’acquisizione, ad esempio l’intestatario dell’account aziendale o un membro di una pratica, la scarica, la verifica o vi accede in altro modo, l’accesso viene registrato nell’acquisizione.
Limiti di frequenza: Le richieste di acquisizione, di certificazione e le altre richieste a pagamento sono soggette a un limite di frequenza per account, valido per tutte le sue chiavi.

Cifratura

In transito: Tutto il traffico di API, dashboard e webhook passa per HTTPS (TLS).
A riposo: I pacchetti di prove sono cifrati con AES-256 (cifratura lato server di Amazon S3) in entrambi i bucket. Entrambi i bucket bloccano qualsiasi accesso pubblico.

Webhook

Firma: Gli invii dei webhook sono firmati secondo lo schema Standard Webhooks con HMAC-SHA256. Gli invii a un webhook_url impostato in una richiesta o in una programmazione sono firmati con il secret di firma della chiave API che lo ha impostato. Questo secret può essere rinnovato con un periodo di sovrapposizione di 24 ore. Una sottoscrizione webhook a livello di account ha un proprio secret di firma, mostrato una sola volta alla creazione della sottoscrizione.
Destinazioni: Gli invii vanno soltanto a endpoint HTTPS pubblici. Prima di ogni invio l’indirizzo viene risolto e controllato di nuovo, e la connessione avviene soltanto verso l’indirizzo controllato: gli indirizzi privati, quelli di loopback e quelli dei servizi di metadati del cloud vengono così rifiutati anche dopo una modifica dei record DNS. I reindirizzamenti non vengono seguiti.
Nuovi tentativi: Un invio che va in timeout, non riesce a connettersi o riceve una risposta di errore (diversa da 410 Gone) viene ritentato fino a 5 volte nell’arco di circa 35 ore (dopo 5 min, 30 min, 2 h, 8 h e 24 h) con lo stesso webhook-id, in modo che i destinatari possano scartare i duplicati. Ogni tentativo attende una risposta al massimo per 10 secondi.
Download: Gli invii ritentati e quelli legati a una sottoscrizione non contengono il link di download con validità di 24 ore. Il destinatario può ottenerne uno nuovo con GET /v1/captures/{id}.
Sottoscrizioni: Una sottoscrizione webhook a livello di account viene disattivata quando il suo endpoint risponde con 410 Gone, dopo 5 giorni senza alcun invio riuscito oppure, se è stata creata con una chiave API, quando quella chiave viene revocata. Gli eventi vengono conservati per 30 giorni e si possono recuperare con GET /v1/events.

Servizi di terze parti

Pagamenti: I pagamenti sono elaborati da Stripe. ProofSnap non archivia numeri di carta.
E-mail dell’account: MailerSend invia i messaggi di conferma dell’indirizzo e-mail e di reimpostazione della password.
Riferimenti temporali: I calendari OpenTimestamps e, per una validazione temporale qualificata, Disig a.s. ricevono soltanto l’impronta del manifest, mai le prove stesse.
Verifiche DNS e WHOIS: Per documentare il sito acquisito, il suo nome host viene risolto tramite Google Public DNS e Cloudflare DNS, e la registrazione del dominio viene consultata nei servizi pubblici RDAP e WHOIS.

Sicurezza dell’API ProofSnap e dati ospitati nell’UE