AWS Client VPN: quale CA deve emettere i certificati client?

La domanda sui certificati in AWS Client VPN viene posta come domanda di prodotto, ma in realtà è una domanda operativa. Ognuna delle tre configurazioni abituali manterrà funzionante un tunnel: una CA organizzativa esistente, un emettitore autonomo dedicato o AWS Private CA. Differiscono per chi approva un dispositivo, chi custodisce la chiave di firma e chi risponde quando un portatile sparisce in un’ora scomoda. Scegliete l’opzione di cui sapete nominare il responsabile.

AWS non richiede Private CA per l’autenticazione con certificati. Collocare un certificato server in ACM è un passo di distribuzione, non un processo di registrazione.

Le tre condizioni che decidono

Tre condizioni separano nettamente le opzioni: se esiste già un processo approvato di registrazione dei dispositivi, se potete gestire una chiave di firma con backup e un responsabile nominato, e come una revoca raggiunge l’endpoint. Ognuna è vicina a un sì o a un no, e il primo no di solito decide l’architettura.

Affrontatele in ordine. Saltare subito a un confronto dei costi è il modo in cui i team finiscono con una CA gestita e nessuno che sappia chi emette il prossimo certificato per portatile.

Prima condizione: la registrazione esiste già?

Se la vostra organizzazione gestisce già una CA con un percorso approvato di registrazione dei dispositivi, emettere da lì i certificati client di Client VPN è la via più breve. Le approvazioni, il processo e i registri degli asset sono già presenti. Un emettitore subordinato dedicato all’interno di quella gerarchia è di solito migliore della CA emittente generica, perché dà alla VPN un proprio confine di fiducia e una propria lista di revoca. Tenete quella lista separata dal resto della gerarchia, così un incidente VPN non impone un cambiamento a tutto il PKI.

Se un simile processo non esiste, la vera domanda è se volete costruirne uno. Una CA è facile da avviare e costosa da possedere male.

Seconda condizione: sapete gestire una chiave di firma?

Un emettitore autonomo funziona con il modello di importazione documentato, e EasyRSA o un piccolo strumento interno possono produrre il materiale. Eseguire il comando non è la parte difficile. La parte difficile sono i backup offline della chiave di firma, un percorso di ripristino che qualcuno ha davvero provato, un responsabile che non è in ferie e una regola per cui la chiave non finisce mai in un pacchetto client né in un export di configurazione. Scrivetelo come procedura prima che venga emesso il primo certificato, non dopo il primo incidente.

AWS Private CA sposta quella custodia in un servizio gestito. Non sposta la politica di registrazione, il passo di approvazione né la consegna del certificato al dispositivo.

Terza condizione: come arriva la revoca?

Client VPN consuma una lista di revoca dei certificati client che importate nell’endpoint, come descritto nella guida al ciclo di vita dei certificati. Pubblicare una CRL altrove nel vostro PKI non la spinge nel servizio. L’importazione è un’operazione separata e pianificata, e una lista scaduta ferma le connessioni invece di degradarsi in silenzio. Mettete il rinnovo sullo stesso calendario dei certificati stessi.

Ciò rende il rinnovo una voce di monitoraggio con un responsabile, non un compito che si chiude al lancio. Revocate un certificato di prova da un capo all’altro prima di avere davvero bisogno del meccanismo.

Ciò che nessuna delle opzioni elimina

Ogni opzione richiede ancora un certificato client e una chiave distinti per ogni dispositivo gestito in modo indipendente. Un tutorial che distribuisce un’unica identità a tutti è una scorciatoia da tutorial, e rende anche impossibile la revoca selettiva.

I certificati server importati in ACM non hanno rinnovo gestito, quindi il responsabile deve procurarsi il sostituto, reimportarlo e poi confermare che l’endpoint lo abbia adottato. Rinnovare il certificato server non rinnova le credenziali client già presenti sui portatili. Sono cicli di vita separati con calendari separati.

Controllate i tipi di chiave e le estensioni accettate dal servizio prima di emettere qualcosa. Che una CA supporti un algoritmo non significa che l’endpoint lo accetterà.

Prima del lancio, eseguite un rinnovo e una rimozione di un client attraverso il flusso di lavoro scelto, e annotate quale credenziale è cambiata, quale impostazione dell’endpoint è cambiata e cosa è successo alla sessione attiva. Se quell’esercizio termina senza un responsabile chiaro, la scelta dell’emettitore non è conclusa.