AWS Client VPN: кој CA треба да издава клиентски сертификати?
Постоечки CA, самоуправуван издавач и AWS Private CA ја делат работата поинаку. Одлучете кој одобрува, обновува и отповикува клиентски сертификати пред да започнете.
Прашањето за сертификати на AWS Client VPN се поставува како прашање за производ, а всушност е оперативно прашање. Секоја од трите вообичаени поставки ќе одржува работен тунел: постоечки организациски CA, посветен самоуправуван издавач или AWS Private CA. Тие се разликуваат по тоа кој одобрува уред, кој го држи клучот за потпис и кој одговара кога лаптоп ќе исчезне во незгоден час. Изберете ја опцијата чиј сопственик можете да го именувате.
AWS не бара Private CA за автентикација со сертификати. Ставањето на серверски сертификат во ACM е чекор за распоредување, а не процес на регистрација.
Трите услови што одлучуваат
Три услови чисто ги одделуваат опциите: дали веќе постои одобрен процес за регистрација на уреди, дали можете да управувате со клуч за потпис со резервни копии и именуван сопственик, и како отповикувањето стигнува до крајната точка. Секој е близу до да или не, и првото не обично ја одредува архитектурата.
Поминете ги по ред. Скокот право кон споредба на трошоци е начинот на кој тимовите завршуваат со управуван CA и никој не знае кој го издава следниот сертификат за лаптоп.
| 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 |
Прв услов: дали регистрацијата веќе постои?
Ако вашата организација веќе управува со CA со одобрен пат за регистрација на уреди, издавањето на клиентски сертификати за Client VPN од него е најкраткиот пат. Одобрувањата, процесот и евиденцијата на средства веќе се таму. Посветен подреден издавач во таа хиерархија обично е подобар од CA за општа намена, бидејќи му дава на VPN сопствена граница на доверба и сопствен список за отповикување. Држете го тој список одвоен од остатокот од хиерархијата за да не наложи VPN инцидент промена во целиот PKI.
Ако таков процес не постои, вистинското прашање е дали сакате да изградите еден. CA е лесно да се започне и скапо да се поседува лошо.
Втор услов: можете ли да управувате со клуч за потпис?
Самоуправуваниот издавач работи со документираниот модел на увоз, а EasyRSA или мала внатрешна алатка може да го создаде материјалот. Извршувањето на командата не е тешкиот дел. Тешкиот дел се офлајн резервни копии на клучот за потпис, пат за обновување што некој навистина го тестирал, сопственик што не е на одмор и правило дека клучот никогаш не завршува во клиентски пакет или извоз на конфигурација. Запишете го тоа како процедура пред да се издаде првиот сертификат, а не по првиот инцидент.
AWS Private CA го пренесува тоа чување во управувана услуга. Не ја пренесува политиката за регистрација, чекорот за одобрување или доставувањето на сертификатот до уредот.
Трет услов: како пристигнува отповикувањето?
Client VPN користи список за отповикување на клиентски сертификати што го увезувате во крајната точка, како што е опишано во упатството за животниот циклус на сертификатот. Објавувањето на CRL на друго место во вашиот PKI не го турка во услугата. Увозот е посебна, закажана операција, а истечен список запре врски наместо тивко да се влошува. Ставете го обновувањето на истиот календар како и самите сертификати.
Тоа го прави обновувањето ставка за следење со сопственик, а не задача што завршува при пуштањето. Отповикајте еден тест сертификат од почеток до крај пред вистински да ви треба механизмот.
Што не отстранува ниту една опција
Секоја опција сè уште бара еден посебен клиентски сертификат и клуч за секој независно управуван уред. Упатството што дели еден идентитет на сите е кратенка во упатството и исто така го прави селективното отповикување невозможно.
Увезените серверски сертификати во ACM немаат управувано обновување, па сопственикот мора да ја набави замената, повторно да ја увезе и потоа да потврди дека крајната точка ја прифатила. Обновувањето на серверскиот сертификат не ги обновува клиентските акредитиви што веќе се на лаптопите. Тоа се одделни животни циклуси со одделни календари.
Проверете ги типовите клучеви и проширувањата што услугата ги прифаќа пред да издадете нешто. Тоа што CA поддржува алгоритам не значи дека крајната точка ќе го прифати.
Пред пуштање, спроведете едно обновување и едно отстранување на клиент низ избраниот работен тек и запишете кој акредитив се смени, кое поставување на крајната точка се смени и што се случи со активната сесија. Ако таа вежба заврши без јасен сопственик, изборот на издавач не е завршен.