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 підтримує алгоритм, не означає, що кінцева точка його прийме.

Перед запуском проведіть одне поновлення й одне вилучення клієнта через обраний робочий процес і запишіть, які облікові дані змінилися, яке налаштування кінцевої точки змінилося і що сталося з активною сесією. Якщо ця вправа завершується без чіткого власника, вибір видавця не завершено.