Un dipendente può rubare la chiave privata del certificato SSL di un'azienda?

Is it possible to a rogue employee to just login in a company server and steal the private keys used to secure SSL connections?

Sì, tranne quando è difficile o quando è impossibile.

Is it as easy as copying a file?

È qui che entra in gioco la gradazione. Ci sono molti livelli di sicurezza, alcuni dei quali descriverò qui da facile a difficile:

1. Nel caso più semplice, sì, la chiave privata è un semplice file di testo (PEM) e potrebbe non avere nemmeno una protezione file adeguata *

2. Oppure il file chiave potrebbe essere archiviato con autorizzazioni restrittive. Ora il dipendente non deve solo essere sul server, deve avere i privilegi appropriati (Amministratore o applicazione) per copiare la chiave.

3. Il file chiave potrebbe essere protetto da password ma automatizzato. Questo di solito significa che oltre al file chiave, il dipendente deve trovare il file di configurazione con la password memorizzata e rubare anche quello. (Vedi anche "java keystore changeit" ...)

4. Il file chiave potrebbe essere protetto da password e la chiave immessa in fase di runtime da un operatore umano. In questo caso, la password non può essere semplicemente rubata dal sistema. Ovviamente, il tuo dipendente potrebbe essere un operatore ... Inoltre, in termini pratici, vengono eseguiti pochissimi server per richiedere l'intervento umano al riavvio.

5. Se ricordo correttamente, IIS era in grado di importare la chiave in un keystore che non era esportabile dagli utenti, ma consentiva l'uso da parte dei servizi. Generalmente queste cose possono essere risolte con privilegi sufficienti.

6. Infine, se viene utilizzato un modulo di sicurezza hardware (HSM), progettato per proteggere le chiavi anche dal sistema operativo stesso, per consentirne l'utilizzo tramite operazioni crittografiche senza esporre le chiavi all'hardware e al software del computer . In questo caso, il dipendente probabilmente troverà la chiave impossibile da rubare.

Here, I want to know how easy is to an insider get the private keys.

Dipenderà dal sito, ma in generale, la mia esperienza è stata che la maggior parte dei siti memorizza la chiave con nient'altro che permessi di file per proteggerla. Il senso generale è "Beh, se qualcuno irrompe nel server, ha già ottenuto tutto, e dovremo comunque emettere una nuova chiave quando riprendiamo". Certo, questo ignora

• il divario tra compromesso e scoperta e
• il potenziale utilizzo di una chiave privata per leggere tranquillamente il traffico nel frattempo.

Lo spostamento verso i cifrari effimeri TLS sta lentamente chiudendo il secondo gap, rendendo la chiave privata molto meno utile (il snooping è spesso più prezioso della rappresentazione, la rappresentazione può essere ottenuta in altri modi (forse più semplici).

* Dai, ragazzi, non fingere di non aver visto una dozzina di configurazioni Apache poco sicure in cui le chiavi sono state lasciate leggibili.

Potrebbe o potrebbe non esserlo. Le chiavi possono essere memorizzate in:

• File nel filesystem dei server che servono le richieste dei client. Più economico, ma meno sicuro; come fai notare, i dipendenti canaglia possono copiare il file con la chiave privata.
• In un modulo di sicurezza hardware , che genera chiavi internamente e non consente ai client esterni di leggere le chiavi private- esegue solo operazioni crittografiche su richiesta del cliente. Questo è più sicuro, ma molto più costoso.

Inoltre, esiste una protezione sotto forma di:

1. Catene di certificati: i server front-end dovrebbero preferibilmente non avere il certificato "master", ma piuttosto un certificato figlio firmato dal master.
2. Revoca del certificato : se si ritiene che la chiave privata di un certificato sia stata compromessa, può essere aggiunta a un elenco di revoche di certificati e resa pubblica .
3. Scadenza del certificato: i certificati specificano una data dopo la quale non devono essere accettati. Questo protegge dalla rivelazione non rilevata limitando il periodo di utilità di tale certificato.

Se la compagnia ha dipendenti disonesti, hai un problema. Il dipendente dovrebbe avere solo i diritti, di cui ha davvero bisogno. E se ha bisogno dei diritti per configurare un server, molto probabilmente ha il diritto di leggere un file di chiave privata. Quindi un dipendente decide di diventare un ladro, hai un problema. Se è questa missione critica, dovresti implementare le regole di due uomini.

Se si utilizza HSM, ci sarà un dipendente, a cui è consentito generare coppie di chiavi e chiavi private di backup di un HSM. E se questo datore di lavoro sta diventando pazzo, potrebbe anche essere in grado di recuperare il backup della chiave privata e tutti i mezzi per ripristinare il backup (a seconda dell'HSM utilizzato).

Ancora una volta - questo è un posto dove implementare i giusti processi e le regole dei due uomini.