In che cosa protegge la crittografia lato server S3 di Amazon?

La risposta breve è questa: non ne abbiamo idea, probabilmente nessuna.

È che potrebbe proteggere contro i backup rubati. Ma questo presuppone che Amazon faccia anche dei backup. Sembra molto improbabile. Se lo facessero, perché non potrebbero recuperare i dati dalla loro ultima perdita di dati S3? È molto più economico ed efficiente solo per utilizzare più copie live.

Inoltre, Amazon avrebbe bisogno delle chiavi su ogni accesso. Quindi sembra molto improbabile che memorizzino le chiavi in un punto diverso dagli stessi luoghi in cui memorizzano i dati. Quindi, se stai immaginando un furto di dispositivi di dati in tempo reale, è altrettanto probabile che ottengano anche le chiavi.

Ma non sappiamo come Amazon memorizza, replica e / o esegue il backup dei dati. Né sappiamo dove conservano le chiavi o come le distribuiscono. Tuttavia, non ho ancora sentito un argomento plausibile secondo cui esiste una minaccia realistica contro cui proteggono. La teoria dei "backup rubati" sembra essere basata sulla falsa premessa che Amazon usa i backup quando tutte le prove suggeriscono che usano più copie live con le chiavi abbastanza vicine.

La crittografia di Dropbox, tuttavia, protegge da un modello di minaccia reale, sebbene uno molto improbabile. Dropbox memorizza le proprie chiavi e le invia a te, quindi ti protegge da un dipendente Amazon canaglia. In cambio, sei vulnerabile a un dipendente Dropbox o al virus di sicurezza Dropbox.

La mia opinione è che Amazon abbia aggiunto questa funzione solo per poter dire che i dati potrebbero essere archiviati crittografati. Alcune persone confronteranno irrispettosamente le caselle di controllo sugli elenchi delle funzionalità e Amazon ha voluto una casella di controllo sulla riga "sicuro / crittografato". In entrambi i casi, l'anello più debole è probabilmente la rete interna e la sicurezza umana di Amazon e la validità dell'attuazione del codice che decide se consentire o meno l'accesso.

I guess it prevents someone from wandering into the AWS datacenter and grabbing a hard drive, but that seems very unlikely, and presumably anyone with access like that could also get the AES keys, wherever they're stored.

Il commento di Gilles risponde in modo efficace alla tua domanda, davvero, ma io vado con una risposta più lunga me stesso perché sono gentile. La crittografia del disco ti protegge dalla perdita di dati quando un disco viene rubato e la chiave non viene rubata con esso. Tali esempi potrebbero essere, come dice Gilles, i backup rubati, ma potrebbero anche essere in portatili in movimento o smaltiti dischi rigidi per impedire tentativi significativi di salvataggio dei dati dai dischi dismessi.

La crittografia del disco non fa molto per aiutarti quando metti insieme la chiave e il disco, perché la sicurezza si basa sulla chiave e se la chiave può essere intercettata, i dati possono essere decifrati. La chiave e il disco sono sempre nelle immediate vicinanze per necessità quando il sistema operativo è attivo e utilizza il disco (ogni lettura richiede quella chiave) in modo che chiunque vicino a lui che può ragionevolmente intercettare la chiave dovrebbe essere in grado di leggere i dati. Ovviamente, è necessario essere in grado di recuperare la chiave per effettuare qualsiasi tipo di attacco, quindi è leggermente più difficile della semplice copia di un disco rigido (ma non di molto). Quindi, in sostanza, sì, hai ragione.

Tuttavia, è comunque una buona idea proteggere i propri dischi per ridurre al minimo la potenziale perdita di dati attraverso cose come il furto e lo smaltimento del disco. Non sai cosa o come fare Amazon per distruggere quei dischi, quindi se hai informazioni preziose su qualsiasi tipo, averli crittografati è una grande idea.

So what's the point, really? Just to say the data is "encrypted"?

Questo è in realtà un possibile fattore. Come dico, ci sono benefici tangibili dalla crittografia dei dati non sono quelli che ci si potrebbe aspettare, ma esistono ancora. Detto questo, ho avuto requisiti per i clienti che i dati vengano crittografati sul server in uno scenario simile come punto di marketing (crittografiamo i tuoi dati). Penso che ci sia una sfida educativa per le persone della sicurezza.

Alcune cose da ricordare:

• Amazon è utilizzato da un vasto numero di aziende
• Un sacco di dati preziosi in là: dati finanziari, proprietà intellettuale ecc.
• I criminali piacciono obiettivi come questo, che possono restituire un alto valore in denaro
• I gruppi criminali non sono contrari all'inserimento di individui all'interno di centri dati, né costringono i dipendenti a svolgere attività nefande

Non trascurare il problema che i tuoi dati vengano divulgati, deliberatamente o in altro modo, da terze parti, anche grandi come Amazon.

Quando usi S3 SSE chiunque abbia le credenziali IAM corrette può leggere e / o scrivere i tuoi oggetti S3, proprio come se tu non stessi usando SSE. A prima vista sembra che l'unico vantaggio aggiunto sia che i dati sono protetti da situazioni in cui qualcuno accede a S3 in modalità offline, come dischi o backup (che dubito di AWS, è molto più probabile che facciano affidamento su solo la replica). Tuttavia, penso che sia necessario confrontarlo con l'alternativa per ottenere i veri benefici:

Ci sono due componenti necessari per la crittografia lato client con S3: una chiave di crittografia e credenziali IAM per l'autenticazione e l'autorizzazione. Quando si utilizza la crittografia lato server, sono necessarie solo credenziali IAM.

Quando si utilizza la crittografia lato client è necessario distribuire la chiave di crittografia a tutte le macchine che hanno accesso in lettura e / o scrittura ai dati crittografati su S3. In entrambi i casi è inoltre necessario distribuire le credenziali IAM.

Se le tue macchine sono compromesse, la tua chiave di crittografia è compromessa. È possibile invalidare le credenziali IAM non appena si conosce l'interruzione e, se si utilizzano ruoli IAM o credenziali IAM temporanee, l'utente malintenzionato ha accesso ai propri dati solo se hanno il controllo della macchina (il che è abbastanza grave, ma potrebbe non essere la fine del mondo, devi anche pensare a cosa succederà dopo). Con la crittografia lato client, l'utente malintenzionato avrà la chiave di crittografia e tutti i dati crittografati con la chiave di crittografia compromessa dovranno essere reencrittati. Con la crittografia lato server non dovrai ricodificare i tuoi dati, perché né tu né l'utente malintenzionato avranno la chiave di crittografia.

Anche se non si ha un'interruzione, ci sono situazioni in cui la chiave di crittografia può essere compromessa, se un laptop viene perso o rubato, se qualcuno che non conosce una e-mail migliore a qualcuno, o se qualcuno si chiude e non puoi essere completamente sicuro che non abbiano preso le cose con loro. A questo punto la chiave di crittografia è compromessa e probabilmente dovresti ricodificare tutti i tuoi dati. Questo può essere molto lavoro. Con la crittografia lato server tutto ciò che devi fare è invalidare le credenziali IAM e rilasciarne di nuove.

Ci sono probabilmente dei modi per mitigare i problemi con la crittografia lato client che ho menzionato sopra, ma a me sembra che usare SSE con S3 abbia un minor numero di aspetti negativi rispetto alla gestione da solo.

Infine, c'è il problema di quanto sia sicuro lasciare AWS a gestire le tue chiavi di crittografia:

Secondo AWS il sistema che gestisce le chiavi di crittografia è separato da S3, con l'intenzione che se qualcuno interrompe l'accesso a S3 dall'esterno non otterrà i tuoi dati perché non avranno le chiavi di crittografia. Se si inseriscono solo nel sistema di gestione delle chiavi (che probabilmente non è direttamente accessibile dall'esterno), non avranno i tuoi dati perché non hanno accesso a S3. Devono entrare in entrambi S3 e nel sistema di gestione delle chiavi per accedere ai tuoi dati.

Se invece si inseriscono nel data center fisico, potrebbero avere accesso sia al sistema di gestione delle chiavi che a S3 allo stesso tempo, ma la domanda è se questo rende le cose più semplici o meno. Penso che prima di tutto dobbiamo affidarci ad AWS per adottare misure di sicurezza appropriate per impedire alle persone di entrare nei loro data center, e in secondo luogo che per ottenere effettivamente le chiavi dal sistema di gestione delle chiavi devi fare qualcosa di più di semplicemente strattona alcune unità disco. Per quanto ho visto, AWS non pubblica esattamente come è protetto il sistema di gestione delle chiavi, più che dire che è protetto con più livelli di sicurezza. È una speculazione, ma la crittografia del disco è probabilmente uno di questi.

Puoi anche essere protetto da qualcuno che irrompe nei dischi di S3 - diciamo (con umorismo) che il disco su cui sono stati memorizzati i dati S3 è anche un'unità di avvio per una finestra funzionante di Windows XP e qualcuno si rompe nella macchina XP (non fisicamente - attraverso un hack). Hanno quindi tutti i file sulla macchina, ma i tuoi sono criptati con le chiavi archiviate in qualche altra casella, quindi tutti i ladri ottengono è spazzatura digitale.

Forse la probabilità che qualcuno irrompa in un array S3 è piccola, ma mi schiero con altri poster e scommetto che i tasti si trovano dietro un altro muro. Inoltre, probabilmente usano chiavi diverse per ogni account.

Quindi, anche se non è un sacco di sicurezza, è lì. Dropbox ha una gigantesca mappa deduplicata per il suo negozio, quindi non vedo come potrebbero cifrare con chiavi diverse per ogni account.

Come molti di voi hanno menzionato, questo vi dà un ulteriore livello di sicurezza (ricorda i livelli?) se i dischi perdono o vi si accede in qualche modo. Ma Trovo incredibile che nessuno abbia menzionato le certificazioni di sicurezza ancora.

Lo so. Alcuni di voi leggendo questo potrebbero già pensare "Le certificazioni sono cazzate". Bene ... possono essere. Ma se fatti correttamente, possono assicurare alcune caratteristiche importanti e sono davvero un grosso problema nel mondo delle imprese. Soprattutto per i fornitori di IaaS, dove i loro dipendenti devono avere un basso livello di accesso a tutti i tuoi dati e codice per fornire il servizio.

Quindi la minaccia qui non è che AWS ha accesso ai dati (hanno) ma un particolare dipendente AWS che ha accesso ai dati.

Non conosco tutti i programmi elencati qui di sicuro. Ma sono abbastanza sicuro che alcuni di essi richiedono separazione dei doveri . Ciò significherebbe che AWS ha dovuto convincere un revisore esterno che implementa correttamente la separazione dei compiti quando le caratteristiche di sicurezza lo richiedono. In questo caso specifico, ciò significherebbe che i ragazzi di AWS che hanno accesso ai dati crittografati non hanno mai accesso alle chiavi di crittografia e che i ragazzi che possono avere accesso alle chiavi di crittografia non hanno mai accesso ai dati .

Quindi sì, devi già fidarti di AWS sia con le chiavi che con i dati, ma queste certificazioni dovrebbero assicurarti che controllano chi (all'interno dell'azienda) ha accesso a cosa. Un ulteriore livello di fiducia che è anche una parte importante della sicurezza.

D'altro canto, anche i clienti AWS che vogliono essere certificati avranno bisogno di questo per la conformità con la crittografia dei dati a riposo . Questo può essere valido solo se fornisce anche la garanzia che le chiavi siano correttamente archiviate e gestite. Con questa funzione e le certificazioni AWS, possono delegarle a AWS.

Poiché le altre risposte implicano in gran parte che la funzionalità è quasi inutile, è necessario esaminare l'immagine più ampia delle migliori pratiche e normative sulla sicurezza delle informazioni per capire perché esiste.

Informazioni Le migliori pratiche e normative sulla sicurezza sono scritte per aziende di tutte le dimensioni e livelli di maturità.

Di solito non c'è nessuna eccezione scritta nelle regole che dice, se sei Amazon o un altro grande provider di cloud, non devi seguire queste regole .

Il risultato è che casi limite come questo erano una best practice che ha molto senso in una piccola azienda che ancora mescola hard disk e nastri di backup, può sembrare divertente a prima vista se applicato a AWS.

Sebbene il furto dei dipendenti di Amazon potrebbe essere una preoccupazione per alcuni, il principale punto di forza della funzione è proteggere le aziende dal mancato rispetto delle migliori pratiche e normative applicabili.

Se Amazon non si preoccupasse di implementare questa funzionalità apparentemente inutile, molte attività regolate (pensate HIPAA, PCI, ecc.) sarebbero costrette a continuare a utilizzare i propri data center o piccoli fornitori di cloud.