I certificati di firma intermedia sono l'unico modo sicuro e pratico per gestire i certificati client OpenVPN?

3

La mia organizzazione deve emettere (e revocare) certificati client OpenVPN per le persone che lavorano in remoto.

Il nostro sistema si basa su una configurazione CA OpenSSL standard e sugli strumenti easy-rsa e l'intera directory vive in un repository git che i membri del team IT clonano localmente sui loro laptop dove generano e firmano i certificati VPN, quindi aggiornano il repo remoto.

La passphrase della chiave privata della CA principale viene memorizzata separatamente in un sistema di gestione delle password locale che è protetto da una password che non memorizziamo da nessuna parte.

La nostra preoccupazione è che chiunque sia mai stato un membro del team IT e se ne vada, può facilmente conservare una copia della chiave privata CA principale e la sua passphrase e può generare e firmare certificati VPN validi a volontà anche dopo che è stato revocato . Attualmente, l'unico modo per impedirlo è quello di cambiare la chiave CA radice e ri-emettere certificati VPN a tutti gli utenti (enorme dolore!)

Qual è la migliore soluzione pratica che le persone usano?

1) Avere procedure migliori e generare / firmare solo certificati VPN client su un singolo host con un criterio di accesso limitato? Questo ci rallenterà notevolmente nelle operazioni giornaliere e non impedisce realmente ad un amministratore di scpare la chiave privata da qualche altra parte se lo desidera.

2) Proteggi correttamente la chiave CA radice come sopra, ma usa certs intermedi per la firma dei certificati VPN giorno per giorno? Come funziona esattamente? Quando un membro del team IT esce, capisco che possiamo revocare il certificato intermedio che è ora "compromesso" e rilasciarne uno nuovo dalla CA principale, ma cosa succede ai certificati VPN esistenti che sono stati firmati con il certificato precedente? Quello che sto leggendo su cerattivi intermedi sembra suggerire che restano validi, ma non capisco come.

Grazie!

    
posta renaudg 06.02.2013 - 13:10
fonte

4 risposte

2

Ci sono davvero poche opzioni. Potresti provare a utilizzare un gestore della sicurezza hardware che bloccherebbe la chiave e consentirà solo la firma. Ciò impedirebbe a qualsiasi membro dello staff IT di accedere alla chiave stessa, ma è molto più complicato da configurare.

Puoi anche (e in ogni caso dovresti davvero) impostare i certificati intermedi in modo che la radice non sia compromessa da una compromissione della chiave di lavoro.

Potresti anche implementare un server di timestamp crittografico che ha una chiave che non è disponibile per l'IT. Potrebbero quindi firmare a partire da un dato orario crittografato e ogni certificato del membro dello staff IT potrebbe essere invalidato a partire da un certo periodo di tempo. Il sistema potrebbe quindi fidarsi dei certificati firmati da tale chiave intermedia fino a un certo punto, ma non fidarsi di certificati o certificati successivi non marcati a data e ora. Questo ti permetterebbe di andare in giro a dover sostituire tutte le chiavi che hanno mai fatto quando se ne vanno.

    
risposta data 06.02.2013 - 15:35
fonte
2

Una soluzione potrebbe essere che qualsiasi membro del personale IT menzionato in grado di emettere certificati agisca come sua CA intermedia. La catena, quindi, sarebbe simile a:

root CA ---> VPN intermediate CA ---> Marks CA, Jasons CA, Dustins CA and so forth.

In questo modo, se diciamo che Mark emette dieci certificati e lascia la società, solo la sua CA intermedia deve essere revocata, riducendo l'impatto a soli dieci utenti che quindi necessitano di nuovi certificati.

Inoltre, questo risolve il problema di chiunque altro che non sia il membro del personale IT (o anche il CTO) di più alto livello che conosca e abbia accesso al file chiave protetto da password della CA principale.

    
risposta data 11.12.2018 - 22:35
fonte
1

Bene, se vuoi sapere che cosa usano gli altri, ho usato OpenVPN con i client che si autenticano tramite ldap in una directory attiva. Quando la persona esce, il suo account è disabilitato e ha accesso a niente . Nello stesso ambiente rilasciamo anche certificati macchina su ogni stazione di lavoro, in modo che le workstation che hanno aderito al nostro dominio possano accedere a una diversa istanza di OpenVPN senza dover autenticare l'utente ogni volta, questo è l'ideale per alcuni senatori (guerrieri della strada, ecc. ).

Per provare e aiutare con il tuo problema, quanto è grande il dolore di riemettere i certs? Non so se hai qualcosa come puppet o sccm in cui puoi distribuire script o certificati alle macchine, ma quello potrebbe essere un pensiero.

Inoltre, un buon modo per eseguire una CA è di avere un server (fisico o virtuale) con accesso limitato (un certo tipo di autenticazione dell'utente), in modo che non tutti possano accedervi e iniziare a generare certificati.

    
risposta data 06.02.2013 - 13:32
fonte
0

Bene proverò a rispondere alle tue domande:

  1. Penso che questa sia la soluzione. Non penso che questo rallenterà molto la generazione di un nuovo certificato. Per il problema di rubare la chiave: questo problema è immanente a tutte queste soluzioni.

  2. Questo cambierà solo i tuoi problemi. Non importa per questo se hai una CA radice o una CA intermedia. Il certificato CA deve essere revocato e deve essere rilasciato un nuovo. Quindi i problemi rimangono gli stessi, indipendentemente dal possesso di certificati intermedi o di root.

risposta data 06.02.2013 - 13:21
fonte