AWS Client VPN: müştəri sertifikatlarını hansı CA verməlidir?

AWS Client VPN-də sertifikat məsələsi məhsul sualı kimi verilir, əslində isə əməliyyat sualıdır. Adi üç quraşdırmadan hər biri işləyən tuneli dayandıracaq: mövcud təşkilati CA, ayrılmış öz idarə etdiyi verən və ya AWS Private CA. Onlar cihazı kimin təsdiqlədiyi, imzalama açarını kimin saxladığı və noutbuk əlverişsiz saatda itdikdə kimin cavab verdiyi ilə fərqlənir. Sahibini adlandıra bildiyiniz variantı seçin.

AWS sertifikat autentifikasiyası üçün Private CA tələb etmir. Server sertifikatını ACM-ə yerləşdirmək yerləşdirmə addımıdır, qeydiyyat prosesi deyil.

Qərarı verən üç şərt

Üç şərt variantları aydın ayırır: təsdiqlənmiş cihaz qeydiyyatı prosesinin artıq mövcud olub-olmaması, ehtiyat nüsxələr və adlandırılmış sahiblə imzalama açarını idarə edə bilməyiniz və ləğvin son nöqtəyə necə çatması. Hər biri «hə» və ya «yox»a yaxındır və ilk «yox» adətən arxitekturanı həll edir.

Onları ardıcıllıqla işləyin. Dərhal xərc müqayisəsinə keçmək komandaların idarə olunan CA ilə qalmasına və növbəti noutbuk sertifikatını kimin verdiyini heç kimin bilməməsinə səbəb olur.

Birinci şərt: qeydiyyat artıq varmı?

Təşkilatınız artıq təsdiqlənmiş cihaz qeydiyyatı yolu olan CA idarə edirsə, Client VPN müştəri sertifikatlarını ondan vermək ən qısa yoldur. Təsdiqlər, proses və aktiv qeydləri artıq oradadır. Bu iyerarxiya altında ayrılmış tabeli verən adətən ümumi təyinatlı CA-dan daha yaxşıdır, çünki VPN-ə öz etimad sərhədini və öz ləğv siyahısını verir. O siyahını iyerarxiyanın qalan hissəsindən ayrı saxlayın ki, VPN insidenti bütün PKI üzrə dəyişiklik tələb etməsin.

Belə proses yoxdursa, əsl sual onu qurmaq istəyib-istəmədiyinizdir. CA başlamaq asandır, pis idarə etmək bahalıdır.

İkinci şərt: imzalama açarını idarə edə bilirsinizmi?

Öz idarə etdiyi verən sənədləşdirilmiş idxal modeli ilə işləyir və EasyRSA və ya kiçik daxili alət materialı hazırlaya bilər. Əmri işə salmaq çətin hissə deyil. Çətin hissə imzalama açarının oflayn ehtiyat nüsxələri, kimsənin həqiqətən sınaqdan keçirdiyi bərpa yolu, məzuniyyətdə olmayan sahib və açarın heç vaxt müştəri paketinə və ya konfiqurasiya eksportuna düşməməsi qaydasıdır. Bunu ilk sertifikat verilməzdən əvvəl prosedur kimi yazın, ilk insidentdən sonra yox.

AWS Private CA bu saxlamanı idarə olunan xidmətə köçürür. Qeydiyyat siyasətini, təsdiq addımını və ya sertifikatın cihaza çatdırılmasını köçürmür.

Üçüncü şərt: ləğv necə gəlir?

Client VPN son nöqtəyə idxal etdiyiniz müştəri sertifikatı ləğv siyahısından istifadə edir, sertifikat həyat dövrü təlimatında təsvir olunduğu kimi. CRL-i PKI-nin başqa yerində yayımlamaq onu xidmətə itələmir. İdxal ayrı, planlaşdırılmış əməliyyatdır və vaxtı keçmiş siyahı səssizcə zəifləmək əvəzinə bağlantıları dayandırır. Yeniləməni sertifikatların öz təqviminə qoyun.

Bu, yeniləməni sahibi olan monitorinq bəndinə çevirir, açılışda bitən tapşırıq deyil. Mexanizmə həqiqətən ehtiyac duymadan əvvəl bir sınaq sertifikatını başdan sona ləğv edin.

Variantlardan heç birinin aradan qaldırmadığı şey

Hər variant yenə də hər müstəqil idarə olunan cihaz üçün ayrı bir müştəri sertifikatı və açarı tələb edir. Hər kəsə tək identiklik verən dərslik dərslik qısayoludur və seçmə ləğvi də qeyri-mümkün edir.

ACM-də idxal edilmiş server sertifikatlarının idarə olunan yenilənməsi yoxdur, ona görə sahib əvəzi almalı, yenidən idxal etməli və sonra son nöqtənin onu qəbul etdiyini təsdiqləməlidir. Server sertifikatını yeniləmək noutbuklarda artıq olan müştəri etimadnamələrini yeniləmir. Bunlar ayrı təqvimləri olan ayrı həyat dövrləridir.

Nə isə verməzdən əvvəl xidmətin qəbul etdiyi açar növlərini və genişləndirmələri yoxlayın. CA-nın alqoritmi dəstəkləməsi son nöqtənin onu qəbul edəcəyi demək deyil.

Açılışdan əvvəl seçdiyiniz iş axını ilə bir yeniləmə və bir müştəri silinməsi keçirin və hansı etimadnamənin dəyişdiyini, hansı son nöqtə parametrinin dəyişdiyini və aktiv sessiyaya nə olduğunu yazın. Bu məşq aydın sahib olmadan bitirsə, verən seçimi bitməyib.