Generazione chiave appliance di sicurezza

2

Per dispositivi come la decrittografia dei proxy HTTPS, esiste spesso un meccanismo integrato per generare una coppia di chiavi e una CSR. Un amministratore può quindi richiedere all'autorità interna di firmare il CSR con un modello CA subordinato e associare il certificato al CSR nell'appliance. In questo caso, la chiave privata non lascia l'appliance (e generalmente non può essere esportata).

Le stesse appliance spesso offrono un'opzione per caricare una chiave privata e un certificato crittografati. In questo scenario, l'amministratore utilizza (ad esempio) OpenSSL per generare la chiave e il CSR su una macchina separata, procurarsi il certificato e quindi caricarlo. I vantaggi in questo caso sono la possibilità di archiviare la chiave privata per il backup, potenzialmente di specificare lunghezze della chiave più lunghe e aggiungere ulteriori informazioni alla CSR che potrebbero non essere disponibili nella procedura guidata di generazione sull'appliance. Questo ovviamente presuppone un solido processo di escrow / backup chiave.

La mia domanda è: supponendo che ci sia una macchina offline (o "vault") dedicata e indurita per generare la chiave e la CSR, che è il metodo preferito? Dal punto di vista delle best practice sulla sicurezza, la chiave dovrebbe essere generata sull'appliance di destinazione utilizzando la procedura guidata o la macchina "OpenSSL" dedicata?

    
posta user185977 05.09.2018 - 19:21
fonte

2 risposte

1

Generalmente dovresti generare coppie di chiavi sul dispositivo stesso. In questo modo la tua chiave rimane nella posizione in cui è utilizzata, riducendo al minimo la possibilità di attaccare. Oltre a ciò, puoi essere certo che il certificato sia compatibile con il protocollo. I certificati seguono un protocollo standardizzato ben definito (X509v3) ma ci saranno sicuramente differenze di implementazione, se non altro per la complessità della struttura dei dati.

Generalmente non è necessario eseguire il backup. Se la chiave viene persa, puoi semplicemente rigenerare un nuovo set di coppie di chiavi - > CSR - > certificato. Questo perché generalmente ti fidi di un certificato di livello superiore rispetto al certificato di root. Per una configurazione professionale, non sceglierei un certificato autofirmato (una catena di certificati di lunghezza 1). Un motivo per la distribuzione di un certificato sarebbe un cluster di bilanciamento del carico in cui si desidera riutilizzare la chiave / il certificato, che non viene gestito automaticamente.

Se veramente richiede particolari dettagli del certificato (un nome specifico, dimensioni della chiave, ecc.), puoi importare la chiave / certificato utilizzando un keystore PKCS # 12 o simile. Tuttavia, per favore, ricorda che preziosamente poche persone effettivamente guarderanno i certificati. Dopo tutto, sei la persona che protegge l'infrastruttura.

Trascorrerevo la maggior parte del tempo a pensare all'accessibilità dei certificati e naturalmente al periodo di validità dei certificati. Sembra che tu provi a seguire buone pratiche di crittografia per questa parte del setup. È tempo di pensare alle altre parti. Generalmente il tempo speso dividendo i capelli significa che altre parti del sistema sono state dimenticate.

    
risposta data 21.09.2018 - 13:12
fonte
1

Vorrei secondo i commenti che il metodo che meno espone la chiave dovrebbe essere preferito, cioè generandolo sul dispositivo.

Se vuoi essere diligente, chiedo al produttore come generano i numeri casuali e chiedi loro di ottenere un numero di numeri casuali (ad esempio un paio di 100.000) dal dispositivo. È quindi possibile sottoporre tali numeri casuali a un test di casualità.

Un altro punto a cui prestare attenzione è se il dispositivo implementa la crittografia e l'amplificazione all'avanguardia; metodi di hash e se il produttore fornisce aggiornamenti software. Se uno dei due punti è negativo, potresti preferire generare certificati su un sistema diverso.

    
risposta data 20.12.2018 - 15:00
fonte