Archiviazione sicura di una chiave di crittografia su AWS

Dipende da cosa intendi per "memorizzare", così come "server".

Ho intenzione di ipotizzare che ci siano due "server" in uso ora, entrambi sul cloud AWS:

Server MySQL.

Server delle applicazioni (che al momento contiene il codice con la chiave di crittografia)

Il server MySQL non ha motivo di avere la chiave, mai.

Il server delle applicazioni presumo deve funzionare con i dati decrittografati.

• Se il server delle applicazioni sta eseguendo la decrittografia, avrà la chiave in memoria.
  • NON PUOI sapere se la memoria è stata salvata su disco da AWS, a meno che tu non controlli l'hardware.
• Se il server delle applicazioni non ha bisogno di eseguire la decodifica stessa, allora è possibile avere un servizio che preleva i dati MySQL e li decodifica, inviando i dati al server delle applicazioni con una crittografia a chiave pubblica / privata che si ' soddisfatto.

Come sempre, se la chiave è su AWS, qualsiasi dipendente AWS con accesso sufficiente sceglie, così come chiunque altro abbia accesso sufficiente (fornitori, Dell dopo che il contenitore pieno di hardware è stato restituito una volta che ha subito troppi guasti, ecc. ecc.).

Un approccio è quello di memorizzare chiavi sensibili, password o altre credenziali in un determinato bucket S3. Quel secchio non dovrebbe essere accessibile pubblicamente / disponibile. Successivamente, si crea un ruolo IAM che ha accesso S3 in sola lettura solo a quel bucket. Infine, quando si avvia l'istanza EC2, si assegna il ruolo IAM a tale istanza.

Con questo tipo di approccio, la tua istanza EC2 non ha bisogno della tua chiave segreta / di accesso AWS per parlare con S3; è automaticamente consentito dal ruolo IAM. E poi codice / script sulla tua istanza EC2 può scaricare la chiave di crittografia (o altre credenziali) dal bucket S3, avviare il processo e quindi rimuovere quelle credenziali dal disco (supponendo che le hai memorizzate sul disco dell'istanza); questo dovrebbe sperare assicurare che quelle credenziali siano ora solo in memoria su quell'istanza EC2.

Si noti che se si tenta questo approccio, potrebbe essere necessario impostare le autorizzazioni sul bucket S3 (e il relativo file) su "consenti all'utente AWS autenticato", poiché l'istanza EC2 non avrà la chiave di accesso / segreto AWS e quindi non sarà identificato come il tuo account per S3.

Spero che questo aiuti!

Dipende da quanto devi essere sicuro. Ad esempio, per PCI, è necessario disporre di due chiavi.

Il primo è la chiave di crittografia dei dati (DEK). Il secondo è la chiave di crittografia chiave (KEK). Si utilizza il DEK per crittografare i dati. Tu usi KEK per crittografare il DEK. Non è necessario ma è strongmente consigliato di archiviare KEK nel keystore fornito dal sistema operativo. Quindi solo l'utente che ha effettuato l'accesso che lo ha creato può accedervi. Abbiamo creato un utente nascosto a cui l'applicazione è connessa per recuperare il KEK.

Il punto è rendere più difficile la necessità di avere successo con più vettori di attacco. Uno per accedere alle credenziali di accesso, uno per ottenere l'accesso al keystore, uno per arrivare al DEK ovunque sia memorizzato, e quindi per ottenere l'accesso ai dati effettivi. Questo è contrario all'avere le chiavi nel database. In tal caso, una volta che il database è compromesso, tutto è.

Puoi dividere il tuo KEK e avere metà del codice per aggiungere un altro livello di difficoltà. Personalmente non mi piace averlo disponibile in testo normale, quindi ne offusisco quella metà in modo che debbano guardare il testo e il codice, un altro livello di difficoltà.

Probabilmente per i tuoi scopi, puoi farla franca con una sola chiave memorizzata nel keystore per l'utente in cui la tua app è in esecuzione.