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 поддържа алгоритъм, не значи, че крайната точка ще го приеме.

Преди старта преминете едно подновяване и едно премахване на клиент през избрания работен процес и запишете кои данни за достъп са се променили, коя настройка на крайната точка е променена и какво е станало с активната сесия. Ако това упражнение приключи без ясен собственик, изборът на издател не е завършен.