AWS Client VPN: care CA ar trebui să emită certificatele de client?

Întrebarea despre certificate în AWS Client VPN este pusă ca întrebare de produs, dar în realitate este o întrebare de operare. Oricare dintre cele trei configurații obișnuite va menține un tunel funcțional: un CA organizațional existent, un emitent propriu dedicat sau AWS Private CA. Ele diferă prin cine aprobă un dispozitiv, cine păstrează cheia de semnare și cine răspunde atunci când un laptop dispare la o oră incomodă. Alegeți opțiunea al cărei responsabil îl puteți numi.

AWS nu cere Private CA pentru autentificarea cu certificate. Plasarea unui certificat de server în ACM este un pas de implementare, nu un proces de înregistrare.

Cele trei condiții care decid

Trei condiții separă clar opțiunile: dacă există deja un proces aprobat de înregistrare a dispozitivelor, dacă puteți opera o cheie de semnare cu copii de rezervă și un responsabil numit, și cum ajunge o revocare la endpoint. Fiecare este aproape de da sau nu, iar primul nu decide de obicei arhitectura.

Parcurgeți-le în ordine. Saltul direct la o comparație de costuri este modul în care echipele ajung cu un CA administrat și nimeni care să știe cine emite următorul certificat de laptop.

Prima condiție: înregistrarea există deja?

Dacă organizația dumneavoastră operează deja un CA cu o cale aprobată de înregistrare a dispozitivelor, emiterea de acolo a certificatelor de client pentru Client VPN este cea mai scurtă rută. Aprobările, procesul și evidența activelor sunt deja acolo. Un emitent subordonat dedicat în acea ierarhie este de obicei mai bun decât CA-ul emitent de uz general, pentru că îi dă VPN-ului propria limită de încredere și propria listă de revocare. Țineți acea listă separată de restul ierarhiei, astfel încât un incident VPN să nu impună o schimbare în tot PKI-ul.

Dacă un astfel de proces nu există, întrebarea reală este dacă vreți să construiți unul. Un CA este ușor de început și scump de deținut prost.

A doua condiție: puteți opera o cheie de semnare?

Un emitent propriu funcționează cu modelul de import documentat, iar EasyRSA sau un instrument intern mic poate produce materialul. Rularea comenzii nu este partea grea. Partea grea sunt copiile de rezervă offline ale cheii de semnare, o cale de recuperare pe care cineva a testat-o cu adevărat, un responsabil care nu este în concediu și o regulă ca cheia să nu ajungă niciodată într-un pachet de client sau într-un export de configurație. Scrieți asta ca procedură înainte de emiterea primului certificat, nu după primul incident.

AWS Private CA mută acea custodie într-un serviciu administrat. Nu mută politica de înregistrare, pasul de aprobare sau livrarea certificatului către dispozitiv.

A treia condiție: cum ajunge revocarea?

Client VPN consumă o listă de revocare a certificatelor de client pe care o importați în endpoint, așa cum este descris în ghidul ciclului de viață al certificatului. Publicarea unui CRL în altă parte a PKI-ului nu îl împinge în serviciu. Importul este o operațiune separată și programată, iar o listă expirată oprește conexiunile în loc să se degradeze în liniște. Puneți reînnoirea în același calendar ca certificatele înseși.

Asta face din reînnoire un element de monitorizare cu responsabil, nu o sarcină încheiată la lansare. Revocați un certificat de test de la un capăt la altul înainte de a avea cu adevărat nevoie de mecanism.

Ce nu elimină niciuna dintre opțiuni

Fiecare opțiune are în continuare nevoie de un certificat de client și o cheie distincte pentru fiecare dispozitiv administrat independent. Un tutorial care distribuie o singură identitate tuturor este o scurtătură de tutorial și face imposibilă și revocarea selectivă.

Certificatele de server importate în ACM nu au reînnoire administrată, așa că responsabilul trebuie să obțină înlocuitorul, să îl reimporte și apoi să confirme că endpointul l-a adoptat. Reînnoirea certificatului de server nu reînnoiește credențialele de client care sunt deja pe laptopuri. Sunt cicluri de viață separate cu calendare separate.

Verificați tipurile de chei și extensiile pe care serviciul le acceptă înainte de a emite ceva. Faptul că un CA acceptă un algoritm nu înseamnă că endpointul îl va accepta.

Înainte de lansare, rulați o reînnoire și o eliminare de client prin fluxul de lucru ales și notați ce credențial s-a schimbat, ce setare a endpointului s-a schimbat și ce s-a întâmplat cu sesiunea activă. Dacă exercițiul se termină fără un responsabil clar, alegerea emitentului nu este încheiată.