2013-12-11 40 views
5

Nel mio database memorizzo informazioni che sono criptate e decodificate al volo tramite una classe PHP.Dove memorizzare la chiave privata per la crittografia in ambiente PHP

Per applicazione Uso una chiave privata aggiunta a una chiave utente per verificare che la decrittografia abbia esito positivo solo quando un utente tenta di decodificare i propri dati.

La "chiave" utente è memorizzata nel database; ma la chiave privata (livello applicazione) è memorizzata come file txt in FS. Fuori rotta 'sopra' la radice del web.

Considerazioni: - Se il database viene violato: finiscono con una parte della chiave, e dati cifrati - Se PHP-stop o è danneggiato: finiscono con una singola pagina con solo include('../private/private.php') in esso.
- Se NGINX fallisce: la connessione è "semplicemente" interrotta.

L'unico scenario che posso pensare è la corruzione del sistema stesso. Ma il server esegue un firewall, viene aggiornato regolarmente, esegue fail2ban e vengono eseguiti solo i servizi necessari. Accesso SSH solo tramite accesso tramite chiave ecc.

Mi chiedevo se questa è la pratica "migliore". Oppure se esiste un modo migliore per eseguire questo tipo di crittografia con le specifiche sopra riportate? Quali sarebbero i diritti di accesso corretti per il file chiave?

Al momento il database e il server web sono entrambi sullo stesso server di fronte a Internet. È meglio suddividerli e creare un server Internet con solo il server web; e metti il ​​server database e il file-chiave su un server diverso in una rete privata?

edit: la chiave privata per crittografare i dati è costruire da due componenti:
$key = $app_key . $user_key

+3

i diritti di accesso corretti al file-chiave sarebbero '-r --------' o '400' e l'utente del webserver come proprietario. A parte questo, sembra che tu abbia fatto un buon lavoro –

+1

* "Uso una chiave privata aggiunta con una chiave utente per assicurarmi che la decrittografia abbia esito positivo solo quando un utente prova a decrittografare i propri dati" * Non sono sicuro di cosa sia si intende. Tenete entrambe le chiavi sul server, quindi la decrittografia avrà successo ogni volta che lo vorrete. Viceversa, se il server è di proprietà, anche i dati sono di proprietà. – Jon

+0

è un inizio capace dipende interamente dal livello di informazioni che si ha e dalla forza necessaria per la sicurezza. Per la maggior parte degli scenari comuni va bene anche se si può prendere in considerazione l'esecuzione di un controllo sui daemon in esecuzione sul sistema operativo in basso per verificare che non ci siano vettori di attacco noti su di essi, ad esempio versione ssh'd ecc. – Dave

risposta

1

È possibile caricare la chiave nella APC o qualcosa di simile. Ciò richiederebbe un input umano durante l'avvio (o forse avviato da un server più sicuro). Ciò significherebbe che la chiave non viene mai memorizzata in nessun file sul server.

Non è perfetto, ma è migliore dell'approccio più tipico dell'utilizzo di un file locale.

q.v., Where should I store an encryption key for php?

2

mi chiedevo se questa è la pratica 'migliore'. O se c'è un modo migliore per fare questo tipo di crittografia con le specifiche sopra indicate? ? Quali sarebbero i diritti di accesso corretti per il file chiave?

difficile da attuare

Per essere perfettamente sicuro si avrebbe bisogno di generare una coppia di chiavi pubblica-privata su un (modulo di sicurezza hardware) HSM, come una smart card o una casella di HSM. La chiave privata generata viene creata all'interno dell'HSM e non può mai uscire dall'HSM, può essere utilizzata solo per le operazioni di decodifica/firma all'interno dell'HSM stesso, tuttavia non può mai essere letta dall'HSM. In questo caso, se qualcuno ha hackerato il tuo server, o addirittura ha ottenuto il controllo completo sul tuo server, non potrà mai ottenere la chiave privata archiviata in HSM. A seconda del numero di operazioni di decrypt/sign richieste sul server, è necessario un HSM ragionevolmente efficiente per decrittografare i dati richiesti.Realizzazione di questo compito in puro PHP è tuttavia un lungo cammino da percorrere (è possibile implementare il proprio interno proprio C++ o utilizzare la comunicazione tra processi, con un processo che è interagire in grado di HSM)

più facile da implementare

È importante indurire il server e ridurre al minimo il vettore di attacco il più possibile. Ciò include principalmente l'assegnazione di autorizzazioni appropriate a file e database. Dai un'occhiata a this per alcune buone pratiche di sicurezza. Per aggiungere i miei pochi centesimi è possibile utilizzare:

  1. APC per in memoria di archiviazione della chiave privata in php (questo vi darà anche una spinta in termini di prestazioni in confronto con constanlty lettura di una chiave da un file). È necessario implementare alcuni meccanismi di sicurezza (come l'inserimento di un codice di accesso) per decrittografare/ripristinare una chiave crittografata nell'APC ogni volta che si riavvia il server Web.
  2. Qualcosa come ionCube per cifrare e proteggere i vostri script PHP
  3. controllo si processo di distribuzione utilizzando un contenitore di applicazioni come ad esempio docker

Al momento il database e server web sono entrambi sullo stesso server fronte la rete. È meglio dividerli e creare un server Internet con il server rivolto solo con il server web; e mettere il server del database e il file-chiave su un server diverso in una rete privata?

Sì, separare il server Web dal server di database è sicuramente una buona pratica.

0

Guarda la scheda Cheat di archiviazione crittografica OWASP e i suoi consigli. Regola 2.1.5.4: protegge la chiave in una chiave volta. Le chiavi non devono essere memorizzate sull'applicazione o sul server web.

Problemi correlati