Qual è il posto migliore in cui nascondere le chiavi di crittografia longeve

0

Sto prendendo in considerazione le opzioni di crittografia per un nuovo progetto Sybase (solo fronte interno, seduto nella nostra intranet) per un client che ha una politica di sicurezza che richiede che tutti i dati sensibili utilizzino la crittografia DB e siano disponibili solo per pochi. Penso che la crittografia di Sybase sia la strategia sbagliata perché a) i dba possono entrare facilmente, eb) se e quando migriamo a SQL Server o Oracle, non voglio occuparmi di strategie di crittografia differenti.

Pertanto, sto pensando di mantenere una singola tabella di dati sensibili e di crittografare quella colonna (crittografia simmetrica) nel mio codice Java prima di memorizzarla nel DB.

Ora, i campi crittografati non hanno la chiave di crittografia cambiata, mai, tranne in un ambiente molto controllato, che per me in realtà significa mai. Quindi diventerà una password permanente.

La domanda è, dove tenerlo. Se si trova in un file di proprietà, qualsiasi sviluppatore con accesso al nostro repository Git potrebbe vederlo.

Potremmo codificarlo nel codice sorgente, ma buona norma, è una cattiva pratica.

Potremmo generarlo in sorgente, come il 10 ° Fibonacci o 3! +8! sarebbe difficile da individuare, ma è ancora piuttosto esposto.

Potremmo avere il sa di mantenerlo nell'ambiente, ma poi dove lo archiviano per riferimento futuro?

Così tante scelte sbagliate. Ce ne sono di buoni?

    
posta Victor Grazi 20.05.2016 - 22:06
fonte

2 risposte

4

Beh, se sei davvero molto serio riguardo alla sicurezza delle tue chiavi, allora c'è solo una risposta.

HSM

Cripta i tuoi dati a riposo usando un algoritmo simmetrico e cripta le chiavi usate per l'algoritmo simmetrico usando chiavi asimmetriche, la chiave privata per la quale è memorizzata nell'HSM.

Gli HSM sono progettati con cura e intenzionalità in modo che, una volta su di essi, le chiavi non possano essere esportate da esse. Inviate un comando all'HSM chiedendogli di "fare qualcosa" con la vostra chiave (es. Cifrare, firmare, decifrare), ma la chiave non lascia mai l'HSM in alcun formato leggibile sia stampato su console o esportato in un file.

Se non puoi giustificare il costo di un HSM perché i tuoi dati non sono abbastanza preziosi o semplicemente non puoi ottenere il budget, allora l'opzione "next best" probabilmente sarà un "cloud HSM" ospitato.

Sicuramente ci sono rischi associati con un hosting di terze parti del tuo HSM, ma questi rischi sono probabilmente inferiori a quelli che stai cercando di essere furbo (e non riuscendo a) a nascondere le tue chiavi e cercare di "nasconderle" solo perché non lo fai " t voglio pagare per il tuo HSM.

    
risposta data 20.05.2016 - 23:25
fonte
2

Il tuo problema riguarda meno i luoghi in cui inserire le cose e altri su chi fidarsi. Non importa quale, la password verrà memorizzata da qualche parte a cui qualcuno ha accesso. Devi fidarti di quella persona o persone.

La scelta più logica è limitare l'accesso solo all'ambiente in cui viene eseguito il codice. Ciò significa un insieme limitato di amministratori di sistema. Queste persone hanno comunque accesso root e, se VERAMENTE desideravano i dati, avrebbero trovato un modo per ottenerlo.

Ora, hai ANCHE bisogno di memorizzare la password da qualche parte se "l'ubicazione segreta" fallisce. Un'opzione è semplicemente una forma di conservazione a freddo, messa in una cassetta di sicurezza presso la banca locale. Le banche sono brave a mantenere le cose sicure e danno accesso solo alle persone autorizzate corrette che conservano in archivio con loro.

    
risposta data 20.05.2016 - 22:49
fonte

Leggi altre domande sui tag