Come gestire la protezione della chiave privata SSL di un server Web (password vs. nessuna password)?

Abbiamo una discussione nel gruppo di sicurezza della mia azienda su quale sia la peggiore delle seguenti opzioni per gestire la chiave privata SSL.

Il server Web deve accedere alla chiave privata per l'operazione di crittografia. Questo file deve essere protetto da accessi non autorizzati. Allo stesso tempo, il server dovrebbe avviarsi automaticamente, senza intervento umano (se è abbastanza sicuro).

Stiamo discutendo tre opzioni:

1. Proteggi la chiave con permessi del file system.

2. Utilizzare una chiave protetta da password e inserire la chiave manualmente ad ogni riavvio.

3. Utilizzare una chiave protetta da password e archiviare la chiave nel filesystem per automatizzare il riavvio.

Le nostre preoccupazioni sono le seguenti:

1. Con l'opzione 1, i riavvii sono automatici ma un compromesso potrebbe copiare la chiave privata e, poiché non protetto, potrebbe essere utilizzato per decifrare la comunicazione o impersonare i nostri server.

2. L'opzione 2 sembra più sicura ma necessita di intervento umano e gli amministratori di sistema sono preoccupati se accade fuori orario. Inoltre, la password deve essere condivisa con diversi amministratori di sistema e sai che un segreto condiviso non è più un segreto.

3. L'opzione 3 ha la migliore delle due opzioni precedenti ma se qualcuno ha accesso alla chiave potrebbe anche avere accesso alla password :(, quindi non sembra affatto così sicuro.

Come gestite la sicurezza delle chiavi private dei vostri server? Esistono altre opzioni (più sicure)?

L'opzione 1 è secondo me lo standard accettato.

Tuttavia, se vuoi davvero la sicurezza extra, perché non hai un server sicuro (non nella tua DMZ) impostato per monitorare il tuo server web, e se apache non funziona, può accedere automaticamente da remoto e riavviare apache , fornendo la passphrase.

Quindi la passphrase è conservata su un computer, ma non è la stessa su cui è in esecuzione Apache e non nella tua DMZ. Ottieni la sicurezza aggiuntiva dell'uso di una passphrase e mantieni la possibilità di un riavvio automatico.

Se qualcuno ha accesso sufficiente al server per leggere la chiave, molto probabilmente avrà anche abbastanza accesso per collegare un debugger e ottenere la chiave dalla memoria.

A meno che non ti piaccia davvero svegliarti nel cuore della notte per digitare le password, vai all'opzione 1. Quando hai molti server, vuoi riavviare automaticamente in caso di fallimento, e l'opzione 2 non lo consente.

Una possibilità per una sicurezza superiore a 1. ma un tempo di inattività inferiore a 2. è quella di creare chiavi private con validità breve e di riciclarle regolarmente. In questo modo è possibile memorizzarli senza passphrase ma ridurre la finestra di vulnerabilità.

Come riconosciuto, l'opzione 3. non fornisce alcuna sicurezza aggiuntiva rispetto a 1.

La praticità impone che in quasi tutte le situazioni finirai per usare l'opzione (1). I permessi del file system sono il modo migliore per andare nella maggior parte degli scenari di sicurezza rispetto a scenari pratici.

Su un sistema * nix è possibile limitare la chiave privata solo a root, poiché la maggior parte dei server Web validi (come apache) si avvia come root ma esegue il downgrade dei propri privilegi a un utente con restrizioni una volta che hanno le porte privilegiate di cui hanno bisogno (80, 443 ecc.) .

Come hai detto l'opzione (3) è dal punto di vista della sicurezza la stessa dell'opzione (1).