AWS Client VPN: који CA треба да издаје клијентске сертификате?

Питање сертификата на AWS Client VPN поставља се као питање производа, а заправо је оперативно питање. Било која од три уобичајене поставке одржаће функционалан тунел: постојећи организациони CA, наменски сопствени издавач или AWS Private CA. Разликују се по томе ко одобрава уређај, ко држи кључ за потписивање и ко одговара када лаптоп нестане у незгодан сат. Изаберите опцију чијег власника можете да именујете.

AWS не захтева Private CA за аутентификацију сертификатима. Постављање серверског сертификата у ACM је корак примене, а не процес регистрације.

Три услова која одлучују

Три услова чисто раздвајају опције: да ли већ постоји одобрен процес регистрације уређаја, да ли можете да водите кључ за потписивање са резервним копијама и именованим власником, и како опозив стиже до крајње тачке. Сваки је близу да или не, а прво не обично одређује архитектуру.

Прођите их по реду. Скок право на поређење трошкова је начин на који тимови заврше са управљаним CA и никим ко зна ко издаје следећи сертификат за лаптоп.

Услов први: да ли регистрација већ постоји?

Ако ваша организација већ води CA са одобреним путем регистрације уређаја, издавање клијентских сертификата за Client VPN из њега најкраћи је пут. Одобрења, процес и евиденција имовине већ су ту. Наменски подређени издавач у тој хијерархији обично је бољи од CA опште намене, јер VPN-у даје сопствену границу поверења и сопствени списак опозива. Држите тај списак одвојен од остатка хијерархије како VPN инцидент не би наметнуо промену на нивоу целог PKI-ја.

Ако такав процес не постоји, право је питање да ли желите да га изградите. CA је лако покренути и скупо лоше поседовати.

Услов други: можете ли да водите кључ за потписивање?

Сопствени издавач ради са документованим моделом увоза, а EasyRSA или мали интерни алат могу да произведу материјал. Покретање наредбе није тежак део. Тежак део су офлајн резервне копије кључа за потписивање, пут опоравка који је неко стварно тестирао, власник који није на одмору и правило да кључ никада не заврши у клијентском пакету или извозу конфигурације. Запишите то као процедуру пре издавања првог сертификата, а не после првог инцидента.

AWS Private CA премешта то чување у управљани сервис. Не премешта политику регистрације, корак одобрења ни испоруку сертификата на уређај.

Услов трећи: како стиже опозив?

Client VPN користи списак опозива клијентских сертификата који увозите у крајњу тачку, како је описано у водичу кроз животни циклус сертификата. Објављивање CRL-а негде другде у вашем PKI-ју не гура га у сервис. Увоз је засебна, заказана операција, а истекао списак зауставља везе уместо да тихо деградира. Ставите обнављање на исти календар као и саме сертификате.

То обнављање чини ставком надзора са власником, а не задатком који завршавате при покретању. Опозовите један тестни сертификат од почетка до краја пре него што вам механизам заиста затреба.

Шта ниједна опција не уклања

Свака опција и даље тражи један засебан клијентски сертификат и кључ за сваки независно управљани уређај. Водич који свима дели један идентитет је водичка пречица и уједно чини селективни опозив немогућим.

Увезени серверски сертификати у ACM-у немају управљано обнављање, па власник мора да набави замену, поново је увезе и затим потврди да ју је крајња тачка прихватила. Обнављање серверског сертификата не обнавља клијентске акредитиве који већ стоје на лаптоповима. То су одвојени животни циклуси са одвојеним календарима.

Проверите типове кључева и проширења која сервис прихвата пре него што било шта издате. То што CA подржава алгоритам не значи да ће га крајња тачка прихватити.

Пре покретања спроведите једно обнављање и једно уклањање клијента кроз изабрани ток рада и запишите која се акредитива променила, која се поставка крајње тачке променила и шта се догодило са активном сесијом. Ако та вежба заврши без јасног власника, избор издавача није довршен.