it-swarm.it

Gestione delle chiavi di crittografia delle applicazioni Web

In breve, consideriamo un'applicazione Web che memorizza alcune informazioni in un database come dati crittografati. Mentre sto intenzionalmente cercando di mantenere questo qualcosa di generico, ecco alcuni presupposti:

  • I dati crittografati vengono archiviati solo nel database (non altrove). Alcuni campi in un dato record sono crittografati, altri no.
  • L'app Web deve scrivere i dati crittografati nel database.
  • L'app Web deve essere in grado di leggere e visualizzare dati crittografati. I dati vengono visualizzati solo in un'autenticazione e in una sezione gestita autorizzata dell'app.
  • I dati sono informazioni sensibili che devono essere protette nel caso in cui i dati siano esposti/accessibili (senza le chiavi *).

Domande:

  • Dove/come si memorizzano le chiavi utilizzate per la crittografia? Innanzitutto, in un sistema in cui i server Web e database sono gli stessi, come gestite la chiave? In secondo luogo, nei sistemi in cui il server Web e i server DB sono separati, come si gestisce la chiave?
  • Le chiavi sono solo file con autorizzazioni limitate? Memorizzato in uno strumento/software separato? Ho visto menzionare che a volte anche le chiavi di crittografia sono crittografate, ma non sono chiare su dove ciò possa essere d'aiuto.

So che questa è una domanda di sicurezza abbastanza semplice e quindi se ci sono risorse che forse mi mancano sarebbe anche molto, molto utile. Ho passato molto tempo (nel corso degli anni) a cercare di afferrare queste informazioni in base a informazioni sulla sicurezza delle app Web (OWASP, PCI DSS, ecc.), Ma molte volte queste informazioni sono molto generiche (ad esempio, "proteggi i dati "," crittografare i dati ") o molto specifico (" per crittografare qualcosa con AES, fare questo ... ").

* Capisco che questa non è una soluzione di sicurezza completa a sé stante. Comprendo che ci sono diversi vettori per ottenere queste informazioni e decodificarle. Riconosco che questa potrebbe essere una cattiva domanda in questa luce :)

Modificato per aggiungere ulteriori informazioni sui presupposti a questa domanda

47
Rob

Dove/come si memorizzano le chiavi utilizzate per la crittografia?

Approccio standard se si utilizza la crittografia integrata su qualcosa di simile al database SQL o Oracle, il database genererà una chiave di crittografia e la crittograferà con un'altra chiave di protezione della chiave o chiave principale. Può essere una passphrase o una chiave più lunga memorizzata ad es. file .pem.

Questo è di solito memorizzato in una directory limitata a cui solo root/Administrator e l'account del servizio database possono accedere. All'avvio del database la chiave viene letta e caricata in memoria. Questo viene quindi utilizzato per decrittografare le chiavi di crittografia.

In primo luogo, in un sistema in cui i server web e database sono gli stessi, come gestite la chiave?

La chiave è memorizzata in una directory sul server. Il rinnovo o la revoca avviene generalmente tramite il programma di database.

In secondo luogo, nei sistemi in cui il server Web e i server DB sono separati, come si gestisce la chiave?

La chiave è archiviata localmente solo sul server database. Un'opzione più sicura è utilizzare un Hardware Security Module (HSM) in entrambi gli scenari. Questo è un dispositivo hardware collegato al server e utilizzato per archiviare la chiave anziché una cartella con restrizioni sul server.

Le chiavi sono solo file soggetti a autorizzazioni? Conservate in alcuni strumenti/software separati? Ho visto menzionare che a volte anche le chiavi di crittografia sono crittografate, ma non sono chiare su dove ciò possa essere d'aiuto.

Limitare la cartella è accettabile purché si gestisca l'accesso dell'amministratore e si monitorino cose come accessi non autorizzati, accessi come account di servizio, nuovi account o gruppi aggiunti con accesso alla cartella. Come accennato in precedenza, un HSM è l'opzione più sicura se i dati che stai proteggendo e le minacce che stai affrontando ne hanno bisogno.

Generalmente il database creerà le chiavi dell'istanza o della tabella e quindi crittograferà questo con la chiave principale. C'è un vantaggio minimo nell'ulteriore crittografia della chiave master.

11
Rakkhi

Sebbene nella risposta precedente siano state fornite alcune buone informazioni, esiste un difetto di progettazione critico, che non viene notato, ma deriva da alcuni dei presupposti impliciti nella domanda.

La differenza non dovrebbe essere tra:

  • App Web e DB sullo stesso server
  • App Web e DB su server diversi
  • applicazione vs. crittografia db

Il design dovrebbe iniziare da:

  • Chi ha bisogno dell'accesso alle chiavi di crittografia/decrittografia?

O, in realtà, ancora più corretto:

  • Chi è responsabile della protezione della riservatezza dei dati?

Che, a sua volta, proviene da:

  • Quali minacce stai cercando di proteggere?
    O
  • Chi stai cercando di impedire la lettura dei tuoi dati?

Solo sulla base di queste domande, è possibile progettare un sistema crittografico correttamente progettato. (E prevenire la polvere cripto-fatata a cui fa riferimento @ D.W.).

Quindi, alcuni scenari di esempio:

  • L'utente dovrebbe essere responsabile della crittografia, impedendo anche agli amministratori dell'app di vedere i dati
  • L'applicazione client dovrebbe essere responsabile, senza la necessità di coinvolgere l'utente, ma deve ancora essere eseguita sul lato client (ad es. Un programma di backup).
  • L'app-server crittografa in modo applicativo e specifico i dati selezionati, come parte della logica aziendale (anche il dba non può vedere i dati)
  • Il server di database dovrebbe crittografare automaticamente e in modo trasparente i dati memorizzati. (Questo protegge solo contro il furto del file db/disco fisico, con avvertenze ...).

Per semplicità, supponiamo che la crittografia debba essere eseguita sul lato server, la responsabilità ricada sul server e l'utente finale (e l'amministratore) non hanno alcuna influenza sulla crittografia.

La domanda principale, quindi, è la crittografia eseguita dal server delle applicazioni o dal server del database? (In realtà non è così semplice, ci sono altre opzioni ...)
Questo, come la maggior parte dei problemi di sicurezza, ritorna a un compromesso:

  • Gestirai le tue chiavi o preferisci questo abstract dell'infrastruttura automaticamente? (la domanda originale ... maggiori informazioni di seguito ...)
  • Sei preoccupato per il male (o incompetente programmatori inesperti?
  • Sei preoccupato per gli amministratori malintenzionati?
  • Sei preoccupato per l'utilizzo di applicazioni non autorizzate?
  • Sei preoccupato per l'accesso SQL non autorizzato?
  • Sei preoccupato per l'accesso diretto non autorizzato ai file?
  • Sei preoccupato per il furto fisico del disco/server?

E così via. (Si noti che alcune delle domande precedenti sono irrilevanti e non possono essere risolte dalla crittografia del server).


Ora supponiamo che tu abbia preso la tua decisione, in base a quanto sopra, tra la crittografia del server applicazioni e la crittografia del database.
Nota che se il server web e il db si trovano sullo stesso server o meno, qui non ha quasi alcun effetto - se l'app sta crittografando, allora sta semplicemente inviando dati "speciali" al db, altrimenti è discutibile. Tuttavia, questo fa influisce sulla discussione sulle minacce di cui sopra - alcuni problemi sono obsoleti dal design, alcuni sono migliorati ...

  • Crittografia server Web/applicazioni
    • La chiave di crittografia (EK) che usi per crittografare i dati, dovrebbe essere crittografata da sola con un chiave di crittografia della chiave ( KEK).
    • L'EK crittografato dovrebbe essere archiviato in un luogo protetto - questo può essere un file, una chiave di registro, qualunque cosa - l'importante è limitare l'accesso ad esso, solo all'utente del server applicazioni (e, forse anche all'amministratore, vedi sotto).
    • Il KEK ha anche bisogno di protezione: è un po 'più complicato.
      Se sei su Windows, hai un facile accesso a DPAPI - questo fornisce la gestione delle chiavi a livello di sistema operativo, quindi puoi avere il sistema operativo crittografa il tuo KEK e gestisci in modo trasparente le chiavi per te. (Dietro le quinte, DPAPI alla fine si affida alla conoscenza della password dell'utente (in USER_MODE), quindi questo è il punto debole e finale di un vero segreto noto - ma nessun altro dovrebbe sapere la password del server in il primo posto, giusto?)
      Un'altra opzione è il dispositivo esterno/HSM, discusso più avanti.
    • Il KEK ha anche bisogno del controllo dell'accesso, ovviamente - ACL restrittivi e tutto il resto.
    • Esistono diversi motivi per separare l'EK da KEK: non si desidera crittografare enormi quantità di dati con una sola chiave; se è necessario sostituire la chiave, diventa molto più semplice (è sufficiente crittografare nuovamente l'EK con il nuovo KEK); puoi usare una crittografia/archiviazione più forte, più lenta e più complessa su KEK; se è necessario essere conformi a PCI, è possibile implementare la conoscenza divisa su KEK; e altro ancora.
    • Sia l'EK che il KEK non devono essere archiviati a lungo termine senza crittografia - a seconda della piattaforma/lingua, ciò significa ad es. non memorizzarlo in un oggetto String in .NET o Java. Conservalo invece in array di byte mutabili e assicurati sempre di eliminarlo il prima possibile.
    • Alcuni framework vanno anche oltre e forniscono oggetti protetti specifici. Per esempio. in .NET è possibile utilizzare le classi System.Security.Cryptography.ProtectedMemory e/o System.Security.Cryptography.ProtectedData per mantenere le chiavi protette, anche in memoria.
  • Crittografia del database
    • Se il tuo server database esegue la crittografia, questo diventa molto più semplice: le tabelle/i campi sono configurati per crittografare automaticamente tutti i dati in esso memorizzati, la gestione delle chiavi è completamente trasparente (dal PoV dell'applicazione, non dal DBA), e presto.
    • Ad esempio, Oracle e MS SQL Server supportano entrambi la crittografia integrata automatica. Per MSSQL, la gestione delle chiavi è complessa, ma simile a quella che ho descritto sopra. Semplificato: esiste un EK, memorizzato nel database, che dba può configurare per utilizzare per crittografare/decrittografare tabelle o campi. Si trova in una tabella protetta, crittografata da un KEK, a sua volta crittografata da un KEK a livello di server, a sua volta crittografata tramite DPAPI sull'account del servizio MSSQL.
    • In alternativa, MSSQL supporta anche l'uso della crittografia asincrona, ad es. memorizzazione di coppie di chiavi pubbliche/private - questo può essere utile in scenari specifici.
  • Terza opzione: archiviazione di crittografia esterna o HSM (modulo di sicurezza hardware) . Può essere un dispositivo hardware condiviso, un server o una scheda hardware o un dongle ... ecc.
    • Questi dispositivi sono progettati per proteggere in modo molto sicuro piccoli frammenti di dati, ad esempio KEK.
      Ancora una volta, un altro motivo per cui separare l'EK dal KEK: questo ti consentirà di crittografare e decrittografare in modo efficiente le masse di dati con EK, pur gestendo in modo sicuro il KEK.
    • L'HSM di solito è accessibile tramite un driver o un'API speciale, potrebbe essere possibile collegarli anche alla crittografia del database (a seconda del prodotto, ecc.).
29
AviD