I am trying to create a secured policy for storing and maintaining keys between users of my company.
La seguente risposta è basata su quei requisiti che presumo in base al tuo post (chiamerò i dipendenti degli utenti di seguito):
- Devi essere in grado di revocare le chiavi dei dipendenti.
- Vuoi essere in grado di decodificare le informazioni crittografate per i dipendenti.
-
I dipendenti non dovrebbero essere in grado di modificare nulla sulle loro chiavi da soli.
Tieni presente che ciò impedisce anche ai tuoi dipendenti di partecipare alla rete di fiducia, poiché non sono più in grado di emettere certificazioni (potresti volere o non volerlo). Prendi in considerazione la possibilità di consentire ai dipendenti di creare le chiavi, ma di consegnarti una sottochiave di crittografia, se necessario, e di chiedere loro di aggiungere la chiave aziendale come revocatore designato. Questo è paragonabile alla gestione delle chiavi con un'infrastruttura PKI X.509 di proprietà dell'azienda.
Currently, the idea is:
- Generate a master key per user with only the certify capability. Backup this key in a physical vault.
La restrizione della certificazione sembra ragionevole, quindi nessuno è (dovrebbe essere) per errore crittografando la chiave primaria e i tuoi dipendenti non sono in grado di leggere il messaggio.
- Generate a revocation certificate for this master key, and also store it in a physical vault.
In alternativa, potresti anche aggiungere un'azienda come revocatore designato. Ciò potrebbe rendere più facile la gestione di un gruppo di certificati di revoca e mappare ciò che effettivamente accade (la azienda revoca la chiave del dipendente ):
gpg --desig-revoke [key-id]
- Generate an encryption subkey and store it in a physical vault, then move it to a Yubikey.
Questo sembra necessario se si vuole rimanere in grado di leggere i messaggi del dipendente. Potrebbe essere un problema legale in alcune giurisdizioni o richiedere di impedire l'utilizzo privato degli indirizzi di posta della società.
- Generate an auth subkey (for ssh) directly on the Yubikey.
Sia le sottochiavi di autenticazione che di firma possono essere semplicemente scambiate se non più utilizzate. Non tenere una copia sembra ragionevole, dal punto di vista della sicurezza, tutto lo sforzo che devi fare è distribuire la nuova chiave (e possibilmente cambiare i tasti sui server).
Soprattutto se si dispone di un'infrastruttura condivisa, si potrebbe anche considerare l'utilizzo di monkeysphere sui server autenticati. Monkeysphere fa affidamento sulla rete di fiducia di OpenPGP (ad es., firme da una chiave aziendale fidata) sulle chiavi primarie del dipendente e aggiunge le relative sottochiavi a sshd , quindi puoi persino escrow le sottochiavi di autenticazione senza modifiche ai singoli server, ma è piuttosto raro e usato raramente, ma si integra bene con le sottochiavi di autenticazione di GnuPG utilizzate per SSH.
Now I have a bunch of questions:
- What happens if someone leaves the company? I guess I should use the master key revocation certificate to cancel the master key and all
its subkeys.
Hai solo bisogno di revocare la chiave primaria, le sottochiavi sono automaticamente invalidate se la chiave primaria è. Ricorda di invalidare le sottochiavi di autenticazione per sshd !
Invece di utilizzare certificati di revoca pregenerati (che non includono la data corrente e nessun motivo specifico di revoca), utilizzare meglio la chiave primaria per la revoca (GnuPG genera un nuovo certificato di revoca in viaggio).
- What happens if a user loses his Yubikey? Should I revoke the whole master key, or only the subkeys?
La chiave primaria è archiviata nel tuo vault in modo sicuro, quindi perché revocarla? Revoca le sottochiavi, genera un nuovo set e distribuisci un nuovo Yubikey. Il vantaggio è che tutte le certificazioni in entrata rimangono valide e non è necessario distribuire una nuova chiave primaria. In realtà, tutto ciò che è necessario fare è un aggiornamento della chiave del dipendente per tutti gli utenti.
- In case the key is lost, I would need to provide a new one to the user. Can I just import the old master+encryption key on it? and then
what, generate a new auth ssh key? In this case why bother
differentiating master/encryption key?
Non hai ancora descritto la memorizzazione della chiave primaria sugli YubiKey del tuo dipendente. Non sono necessari per l'uso quotidiano, meglio non metterlo lì comunque.
- How do I handle the fact that some users should share the same key? For example, the key for signing packages, or the key for
encrypting some shared files.
OpenPGP consente di aggiungere più destinatari per i messaggi crittografati. È un'alternativa? Le firme potrebbero essere verificate tramite una chiave aziendale che ha firmato le chiavi dei dipendenti.
Non puoi ritirare facilmente una chiave condivisa, tutto ciò che puoi fare è revocarlo. Altrimenti, hai diverse opzioni:
- Avere un servizio di firma / decrittografia. Questo potrebbe essere un server di build che firma anche pacchetti per alcuni utenti autenticati. Esistono anche agenti di trasferimento della posta OpenPGP che crittografano / decodificano mentre sono in viaggio, è possibile utilizzarlo per mappare una chiave di crittografia di gruppo a più utenti (il MTA decrittografa con la chiave di crittografia del gruppo privato e reencrypt per tutte le chiavi di crittografia dei dipendenti).
- Distribuisci la sottochiave a tutti i dipendenti come file. Questo diventa fastidioso se hai bisogno di revocare una sottochiave (ad esempio, uno dei dipendenti se ne va), poiché devi depositare la chiave distribuita.
- Distribuire la sottochiave su smart card OpenPGP (o YubiKeys, che implementano il protocollo smart card OpenPGP), in modo da poter effettivamente ritirare la smart card (poiché la chiave non può essere esportata dalla smart card). Lo svantaggio è che se un dipendente perde la chiave o non la restituisce dopo aver lasciato la società, è comunque necessario revocarla. Gestire la sicurezza dei dispositivi fisici è più facile, in quanto non possono essere copiati facilmente.
- Avere una chiave condivisa su una singola smart card ben custodita (che non può essere smarrita o rubata facilmente) a cui più persone hanno accesso.