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 поддерживает алгоритм, не значит, что конечная точка его примет.
Перед запуском проведите одно продление и одно удаление клиента через выбранный рабочий процесс и запишите, какие учётные данные изменились, какая настройка конечной точки изменилась и что произошло с активной сессией. Если это упражнение заканчивается без ясного владельца, выбор издателя не завершён.