AWS Client VPN: który CA powinien wystawiać certyfikaty klientów?
Istniejący CA, własny wystawca i AWS Private CA dzielą pracę inaczej. Zdecyduj, kto zatwierdza, odnawia i unieważnia certyfikaty klientów przed startem.
Pytanie o certyfikaty w AWS Client VPN zadaje się jako pytanie produktowe, a to naprawdę pytanie operacyjne. Każda z trzech zwykłych konfiguracji utrzyma działający tunel: istniejący CA organizacji, dedykowany własny wystawca albo AWS Private CA. Różnią się tym, kto zatwierdza urządzenie, kto trzyma klucz podpisujący i kto odpowiada, gdy laptop zniknie o niewygodnej godzinie. Wybierz opcję, której właściciela potrafisz wskazać.
AWS nie wymaga Private CA do uwierzytelniania certyfikatami. Umieszczenie certyfikatu serwera w ACM to krok wdrożenia, a nie proces rejestracji.
Trzy warunki, które to rozstrzygają
Trzy warunki jasno rozdzielają opcje: czy istnieje już zatwierdzony proces rejestracji urządzeń, czy potrafisz prowadzić klucz podpisujący z kopiami zapasowymi i wskazanym właścicielem, oraz jak unieważnienie dociera do punktu końcowego. Każdy jest blisko tak albo nie, a pierwsze nie zwykle rozstrzyga architekturę.
Przejdź je po kolei. Skok od razu do porównania kosztów to sposób, w jaki zespoły zostają z zarządzanym CA i nikim, kto wie, kto wystawi następny certyfikat laptopa.
| Option | You still own | Fits when |
|---|---|---|
| Existing organizational CA | Enrollment, approvals, revocation list | A device process already exists |
| Self-run issuer | Signing-key custody, backups, revocation list | You can staff key custody |
| AWS Private CA | Policy, permissions, certificate delivery | Your PKI already lives in AWS |
Warunek pierwszy: czy rejestracja już istnieje?
Jeśli twoja organizacja prowadzi już CA z zatwierdzoną ścieżką rejestracji urządzeń, wystawianie z niego certyfikatów klientów Client VPN to najkrótsza droga. Zatwierdzenia, proces i ewidencja aktywów już tam są. Dedykowany podrzędny wystawca w tej hierarchii jest zwykle lepszy niż CA ogólnego przeznaczenia, bo daje VPN własną granicę zaufania i własną listę unieważnień. Trzymaj tę listę oddzielnie od reszty hierarchii, aby incydent VPN nie wymuszał zmiany w całym PKI.
Jeśli takiego procesu nie ma, prawdziwym pytaniem jest, czy chcesz go zbudować. CA łatwo zacząć i drogo źle posiadać.
Warunek drugi: czy potrafisz prowadzić klucz podpisujący?
Własny wystawca działa z udokumentowanym modelem importu, a EasyRSA lub małe wewnętrzne narzędzie może wytworzyć materiał. Uruchomienie polecenia nie jest trudną częścią. Trudną częścią są kopie zapasowe klucza podpisującego w trybie offline, ścieżka odzyskiwania, którą ktoś naprawdę przetestował, właściciel, który nie jest na urlopie, oraz zasada, że klucz nigdy nie trafia do pakietu klienta ani eksportu konfiguracji. Zapisz to jako procedurę przed wystawieniem pierwszego certyfikatu, a nie po pierwszym incydencie.
AWS Private CA przenosi tę pieczę do usługi zarządzanej. Nie przenosi polityki rejestracji, kroku zatwierdzania ani dostarczenia certyfikatu do urządzenia.
Warunek trzeci: jak przychodzi unieważnienie?
Client VPN korzysta z listy unieważnień certyfikatów klientów, którą importujesz do punktu końcowego, jak opisano w przewodniku po cyklu życia certyfikatu. Opublikowanie CRL gdzie indziej w PKI nie wepchnie jej do usługi. Import to osobna, zaplanowana operacja, a wygasła lista zatrzymuje połączenia zamiast cicho się pogarszać. Umieść odnowienie w tym samym kalendarzu co same certyfikaty.
To czyni odnowienie pozycją monitoringu z właścicielem, a nie zadaniem kończonym przy starcie. Unieważnij jeden certyfikat testowy od początku do końca, zanim mechanizm będzie naprawdę potrzebny.
Czego nie usuwa żadna z opcji
Każda opcja nadal wymaga jednego odrębnego certyfikatu klienta i klucza dla każdego niezależnie zarządzanego urządzenia. Poradnik, który rozdaje jedną tożsamość wszystkim, jest skrótem w poradniku i czyni selektywne unieważnianie niemożliwym.
Zaimportowane certyfikaty serwera w ACM nie mają zarządzanego odnowienia, więc właściciel musi zdobyć zamiennik, ponownie go zaimportować, a następnie potwierdzić, że punkt końcowy go przyjął. Odnowienie certyfikatu serwera nie odnawia poświadczeń klientów, które już są na laptopach. To odrębne cykle życia z odrębnymi kalendarzami.
Sprawdź typy kluczy i rozszerzenia akceptowane przez usługę, zanim cokolwiek wystawisz. To, że CA obsługuje algorytm, nie oznacza, że punkt końcowy go przyjmie.
Przed startem przeprowadź jedno odnowienie i jedno usunięcie klienta przez wybrany przepływ pracy i zapisz, które poświadczenie się zmieniło, które ustawienie punktu końcowego się zmieniło i co stało się z aktywną sesją. Jeśli to ćwiczenie kończy się bez jasnego właściciela, wybór wystawcy nie jest zakończony.