Crittografia
Dove la crittografia è utilizzata e dove non lo è ancora.
La crittografia protegge una verifica in diversi punti distinti: la connessione, l'immagine, il segreto, il backup, la password. Preferiamo elencarli onestamente uno per uno, piuttosto che dire "crittografato" una sola volta e lasciarLe supporre che copra tutto.
In transito
TLS all'edge, e imposto sul database del ledger.
Ogni richiesta a ShieldID viene crittografata prima di raggiungere l'applicazione.
- L'edge pubblico termina il TLS per ogni connessione, con HSTS e un insieme rigoroso di intestazioni di sicurezza, in modo che una richiesta sia crittografata prima di raggiungere qualsiasi componente a valle.
- Il database principale del ledger impone il TLS su ogni connessione che accetta. Una connessione in chiaro viene rifiutata del tutto, non semplicemente sconsigliata dalla configurazione.
- L'applicazione verifica il certificato del database rispetto a un'autorità fissata (pinned) e controlla il nome host, anziché fidarsi del primo certificato che si presenta.
A riposo
Le immagini dei documenti e le date di nascita sono crittografate. Siamo precisi su ciò che, per ora, non lo è.
"Crittografato a riposo" viene spesso detto di un'intera piattaforma in un solo fiato. Ecco che cosa copre effettivamente oggi.
- Immagini dei documenti e selfie
- Crittografate con AES-256-GCM durante la conservazione, prima dell'eliminazione automatica che le cancella.
- Data di nascita
- Conservate in forma crittografata, mai in chiaro, ovunque un record di verifica le contenga.
- Segreti (chiavi API, credenziali del database, chiavi di firma)
- Conservati in un vault dei segreti dedicato, non nella configurazione dell'applicazione né nel codice sorgente.
- Il resto del database e i volumi di archiviazione generici
- Oggi non crittografati a livello di disco o di database. Lo diciamo apertamente anziché lasciar intendere una copertura totale.
Segreti
Un unico vault, con accesso tramite token e con la rotazione registrata.
Le credenziali dell'applicazione non sono disperse in vari file di configurazione.
Centralizzato
Le chiavi API, le credenziali del database e i segreti dei webhook sono conservati in un sistema dedicato di gestione dei segreti, letti e scritti esclusivamente tramite un'API autenticata e protetta da token.
La rotazione è sottoposta ad audit
Un processo di rotazione dedicato registra ogni modifica delle credenziali e ogni tentativo rifiutato in un log a prova di manomissione che memorizza solo le impronte dei valori, mai i valori stessi.
Mai nel codice né nella configurazione
I segreti vengono letti dal vault all'avvio, non inseriti nel codice sorgente né lasciati in un file di ambiente distribuito con il deploy.
Backup
Crittografati prima di lasciare la memoria, con una prova di ripristino eseguibile senza toccare la produzione.
Un backup comprende l'applicazione, la sua configurazione e il database.
- Crittografati con AES-256, usando una chiave conservata nel vault dei segreti. Se tale chiave non è disponibile, lo script di backup si rifiuta di scrivere un file non crittografato anziché ripiegare silenziosamente su questa soluzione.
- Esiste una procedura di ripristino documentata e automatizzata con script, che supporta una modalità di prova in una posizione temporanea, così da poter testare il processo senza toccare i dati in produzione.
- Oggi i backup restano nella stessa sede. Non offriamo backup geo-ridondanti né un sito separato di disaster recovery, e lo dichiariamo nelle pagine su residenza e conformità, non solo qui.
Password, sessioni e chiavi API
Nulla di ciò che La autentica è conservato in una forma che qualcuno possa leggere e riutilizzare.
Tre diversi tipi di segreto, tre diversi trattamenti, tutti unidirezionali.
- Password
- Sottoposte a hash, mai conservate né registrate nei log in chiaro.
- Token di sessione
- Il token nel cookie di sessione del Suo browser è un valore casuale di 32 byte impostato come cookie HttpOnly.
- Chiavi API
- Memorizzate come hash SHA-256. Solo un breve prefisso viene conservato in chiaro, così da poter riconoscere una chiave in un elenco senza che il valore completo possa mai più essere recuperato.
Che cosa questa pagina non afferma
Nessuna protezione DDoS, nessun WAF, nessuna geo-ridondanza.
Oggi non ci troviamo dietro una rete di distribuzione dei contenuti né un web application firewall, e non dichiariamo la crittografia a livello di disco o di database per ogni byte che conserviamo. Un rate limiting di base protegge l'accesso e altri endpoint onerosi, ma non è ancora un livello di protezione dagli abusi robusto e persistente. Se un controllo specifico è importante per la verifica interna della Sua organizzazione, ce lo chieda direttamente anziché supporre che una formula generica lo copra.
Domande
Risposte chiare sulla crittografia.
Ulteriori informazioni
Scopra come conservazione e residenza dei dati si integrano.
La crittografia è un controllo tra tanti. Scopra cosa viene eliminato, quando, e dove si trovano i dati finché esistono.