Делегируйте выпуск сертификатов VPN без корневого ключа
Выпуск сертификатов — это разрешение; владение корневым ключом — это возможность. Промежуточный сертификат ограничивает первое, а удаление учётной записи не является компрометацией.
Дать кому-то возможность регистрировать VPN-клиентов и дать ему переносимую копию корневого ключа — это два разных действия, и разница становится заметной только тогда, когда этот человек уходит или этот ключ утекает. Первое даёт операцию внутри рабочего процесса, который вы контролируете; второе даёт способность создавать доверие где угодно, офлайн, бессрочно. Решите, что из этого нужно задаче, прежде чем трогать любой ключевой материал. Схема иерархии не ответит на этот вопрос за вас.
Запишите задачу регистрации как три вопроса: кто может запросить, кто утверждает и что разрешено подписывать выпускающему компоненту.
Решите, какую возможность вы предоставляете
Выпускающий сервис может предоставить процесс утверждения, храня материал подписи у отдельного владельца. Оператор утверждает запрос устройства, сервис применяет политику и фиксирует выпуск, и никто из участников не держит ключ CA. Задокументируйте разрешённые личности, утверждающих и диапазон того, что сервис может подписывать; затем защищайте его администрирование так же тщательно, как ключ. Запрос на подпись сертификата — это запрос, а не решение об авторизации.
Хранилище с аппаратной поддержкой меняет риск копирования ключа, а не необходимость авторизации. Неэкспортируемость означает, что ключ нельзя извлечь, и не означает, что любой, кто может вызвать интерфейс подписи, имеет право на сертификат. Оценивайте эти два свойства отдельно.
Промежуточный сертификат ограничивает полномочия
Корень может удостоверить промежуточный сертификат для повседневного выпуска, так что рутинная работа больше не касается корневого ключа, если собственные процедуры подписи и восстановления корня остаются защищёнными. Это реальная граница, и она не бесплатна: ещё один сертификат, ещё один ключ, ещё одно обновление и ещё один список отзыва, который нужно поддерживать. Используйте его, когда он представляет собой намеренную границу управления или риска. Создание издателя для каждого администратора производит больше всего и не покупает ничего, чего рабочий процесс уже не давал.
Проверьте, что проверяющие компоненты VPN строят цепочку так, как вы ожидаете. Отправка промежуточного сертификата для построения цепочки и установка его как напрямую доверенного якоря — это разные решения.
pathLen ноль означает не то, что вы думаете
RFC 5280 раздел 4.2.1.9 определяет базовые ограничения, и его поле длины пути ограничивает, сколько несамовыпущенных промежуточных сертификатов может следовать в допустимом пути. Значение ноль ограничивает дальнейшую промежуточную глубину; оно не ограничивает число сертификатов конечных субъектов. Люди читают это как ноль разрешённых сертификатов и затем удивляются, почему выпуск всё ещё работает. Читайте поле как ограничение глубины для CA, и поведение становится предсказуемым.
Тот же раздел подразумевает, что якорь доверия является входом проверки пути, а не обычным сертификатом внутри пути. Поэтому публикация записи об отзыве для самоподписанного корня не удаляет его надёжно из каждого хранилища.
Увольнение — это не компрометация ключа
Если уходящий имел только личную учётную запись управления, отозвите этот доступ и его сеансы через поддерживаемый процесс идентификации, затем просмотрите активность и утверждения, которые он создал. Ранее выпущенные клиентские сертификаты не становятся недействительными из-за ухода их утверждающего, и отношение к ним как к скомпрометированным создаёт большую ненужную перерегистрацию. Отключение учётной записи тоже не может аннулировать скопированный ключ подписи, поэтому ответ зависит от того, какая возможность была в руках.
Когда промежуточный сертификат скомпрометирован, его авторизация должна быть отозвана, а каждая личность, за которую он ручался, заменена, согласно политике, которую применяет проверяющий. Доверие корня требует собственного ответа, потому что якорь живёт в хранилищах доверия, которые вы можете не контролировать.
Примите проект с четырьмя конкретными случаями: подходящее устройство регистрируется, неутверждённый запрос отклоняется, удалённый оператор больше не может выпускать, а выведенный издатель больше не даёт доступа. Эти четыре результата и есть runbook.