Progettazione della crittografia dei file

Naviga le tue risposte
1

Sto costruendo un'app e un server. Il server è un'API node.js con un backend Postgres.

Le immagini create nell'app verranno archiviate su Amazon S3. I metadati relativi ai file verranno archiviati in Postgres.

Ho eseguito lo zoom su due possibili soluzioni per le chiavi di crittografia. Entrambi coinvolgono gli URL di Amazon presenti. Questi URL sono generati da Amazon come risultato di una chiamata dal mio server.

  1. Foto scattata nell'app
  2. File di metadati salvati su Postgres tramite la mia API
  3. Il server riceve l'URL di Amazon da caricare per caricare i file
  4. L'URL viene restituito all'app in seguito alla chiamata nel passaggio 2.
  5. L'app utilizza l'URL per pubblicare il file su Amazon S3

Per quanto riguarda la crittografia dei file, potrei scegliere di utilizzare Amazon Key Management Service (kms), ovvero Amazon genera e tiene traccia delle chiavi di crittografia individualmente salate per ciascun file. Il mio server dovrebbe utilizzare la chiave master per ottenere gli URL presegnati generati.

Oppure potrei scegliere di generare chiavi di crittografia individuali per ogni file sul mio server e memorizzare queste chiavi con il resto dei metadati in Postgres. Amazon farebbe ancora la crittografia / decrittografia, ma passerei ogni singola chiave nella richiesta di URL preselezionati invece di passare la chiave master.

KMS, pro:

  • Nessuna chiave di crittografia memorizzata con i metadati del file in Postgres

KMS, con:

  • La chiave master sblocca tutti i file su S3 (ma la chiave master può essere ruotata)

Chiavi generate personalizzate, pro:

  • È più facile implementare un tasto utente extra con XOR: l'inserimento delle chiavi. Se un client non si fida della mia gestione delle chiavi, potrebbe aggiungere una chiave extra che esiste solo sul dispositivo, probabilmente nella catena di chiavi di iOS.

Chiavi generate personalizzate. con:

  • Se il database Postgres è compromesso, anche i file su S3 potrebbero essere compromessi.

Sono un programmatore, non un esperto di sicurezza. Se ho bisogno, consulterò un esperto, ma ho pensato che gli esperti di questo forum potrebbero essere in grado di dare qualche informazione in più in primo luogo.

Ovviamente sono state prese altre misure di sicurezza. L'app parla solo con l'API tramite HTTPS e l'app è autenticata con l'API (utilizzando Oath2 e JWT).

Mi piace molto il concetto di URL preselezionato, in quanto consente all'app di essere priva di chiavi necessarie per l'upload / download di S3.

Dovrei usare km o generare chiavi da solo?

Grazie!

    
posta Michael 31.05.2017 - 16:06
fonte

2 risposte

2

Solo per riassumere la discussione:

devi sapere a che tipo di attacchi vuoi proteggere le chiavi. Come discusso, hai correttamente menzionato i pro e i contro di entrambe le soluzioni.

Ho consigliato di mescolarli in modo da utilizzare due chiavi: KEK (chiave di crittografia chiave) e DEK (chiave di crittografia dei dati). Avrai solo un KEK e altrettanti DEK dei dati memorizzati nel database.

Quando memorizzerai i dati nel DB, genererai DEK, cripterai i dati con DEK, cripterai il DEK con KEK e memorizzerai il DEK crittografato insieme ai dati nel database. Per la lettura, si otterranno dati e DEK crittografato dal DB, si utilizza KEK per decrittografare DEK e DEK per decrittografare i dati.

DEK dovrebbe essere usato solo in memoria dell'applicazione. Non dovrebbe mai essere memorizzato in chiaro altrove. E dovresti occuparti immediatamente della sua eliminazione sicura dalla memoria una volta che non è necessaria (cioè riscrivere il buffer di byte con gli zeri e rilasciarlo - fai attenzione alle stringhe poiché solitamente sono immutabili).

Il modo corretto di archiviare e utilizzare KEK dovrebbe essere memorizzarlo e utilizzarlo all'interno dell'HSM (KMS) in modo che non possa essere rivelato da qualcuno, nemmeno dagli amministratori di server / applicazioni.

Il lato oscuro di questo è probabilmente il prezzo KMS di AWS. Se lo memorizzassi in config potrebbe potenzialmente essere rubato da un utente malintenzionato e successivamente usato per decriptare il dump del database. Ma voi probabilmente non state assicurando un sito dell'esercito;)

È inoltre necessario menzionare che, se è necessario modificare il KEK, è necessario ricodificare nuovamente tutti i DEK memorizzati nel DB.

    
risposta data 31.05.2017 - 16:57
fonte
0

Rivisitato .. pubblicando una risposta anch'io.

Risposta breve: vado con KMS.

Dopo aver letto qualcosa in più su KMS, in realtà sembra adattarsi molto bene alle mie esigenze, e non è affatto costoso. Utilizziamo già S3 per lo storage di file e, quando saremo pronti, useremo AWS per il nostro ambiente di produzione, quindi è facile aggiungere KMS all'installazione. Lascerò anche a KMS la gestione di altri segreti, cioè non più file di configurazione segreti.

Avevo paura che il KMS lo rendesse più complicato, ma in realtà è davvero facile da lavorare.

Avevo anche paura del prezzo. Ho pensato che sarebbe stato valutato come un HSM, ma è molto più economico.

Lascerò qui dei link che gli altri potranno trovare, se si trovano nella mia stessa situazione. Sfortunatamente non ho abbastanza reputazione per poter pubblicare più di due link, quindi ne posterò alcuni senza il prefisso https: //.

Panoramica:

Prezzo:

Probabilmente lo gestirò da Node.js:

  • github.com/DavidTanner/nodecredstash

Anche facile da usare dalla riga di comando:

  • github.com/fugue/credstash

Lettura illuminante se hai bisogno di informazioni sui principianti come faccio io:

  1. blog.threatstack.com/cloud-security-best-practicesfinding-securing-managing-secrets-part-1

  2. blog.threatstack.com/cloud-security-best-practices-finding-securing-managing-secrets-part-2

risposta data 01.06.2017 - 09:47
fonte

Leggi altre domande sui tag

Token anti-CSRF e SQLi SSH ED25519 Key Extract pk (32 bit)