Хранение и автоматическая выдача сертификатов для сетевого оборудования: запуск доверия и регулярная ротация

Определимся, о чем речь

Если практически каждый специалист по информационной безопасности знает, что такое инфраструктура открытых ключей (PKI) и сертификаты, то до начала разговора о теме статьи хотелось бы определиться, о каком сетевом оборудовании мы будем вести речь.

Современная инфраструктура, которой сегодня пользуется практически каждый человек на работе или в повседневной жизни – это крайне сложная гетерогенная система, состоящая из сотен типов различных устройств: от сетевых коммутаторов и маршрутизаторов до смартфонов. И все эти устройства взаимодействуют между собой.

Весьма условно типы сетевых сервисов и, соответственно, сетевого взаимодействия, можно разделить на «публичные» (которыми пользуется неограниченный круг лиц) и «внутренние» (корпоративная инфраструктура какого-то предприятия).

Способы организации PKI (по сути, доверия) в публичных и внутренних сервисах довольно сильно отличаются, так как решают разные задачи.

И далее мы поговорим о сертификатах для сетевого оборудования (то есть для всего, что работает в сети) внутри обособленной инфраструктуры.

Точка доверия

Если мы говорим об инфраструктуре открытых ключей (PKI) и сертификатах, то само собой подразумеваем наличие такого компонента, как Центр Сертификации. Сразу оговоримся, чтобы не путать сертификаты в терминах 63-ФЗ «Об электронной подписи», где введено понятие «Удостоверяющий Центр», мы будем называть сущность, выпускающую технологические сертификаты, Центром Сертификации (ЦС).

Центр Сертификации необходим как раз для обеспечения точки доверия внутри корпоративной инфраструктуры. Ему доверяют все участники взаимодействия (оборудование, компьютеры, серверы и сервисы и пр.) в той части, что если ЦС выпустил какому-то участнику сертификат, то он проверил (сертифицировал), что это именно тот участник, за которого он себя выдаёт.

В идеальной картине мира в инфраструктуре одна точка доверия – единственный Корневой Центр Сертификации. Далее, для разделения сертификатов по области использования, территориальным признакам или по каким-то другим правилам, запускаются один или несколько Подчинённых Центров Сертификации. И уже они формируют сертификаты для конечных субъектов – того самого сетевого оборудования.

Если вернуться к теме статьи, то давайте посмотрим, как хранятся, выпускаются и ротируются сертификаты Центров Сертификации – Корневого и Подчинённых.

Корневой сертификат

Корневой сертификат – это основа инфраструктуры PKI. Именно по этой причине срок его действия обычно измеряется десятками лет (обычно, в районе 20 лет, но конечный срок зависит от многих факторов).

Ключевая пара корневого сертификата и сам сертификат в обычной жизни не ротируются и не меняются, поэтому сохранность закрытого ключа корневого сертификата в тайне – краеугольный камень безопасности инфраструктуры.

Выше мы говорили, что корневой сертификат обычно используется только для подписания сертификатов Подчинённым Центрам Сертификации. Поэтому после планирования структуры PKI выполняются следующие действия:

• Формирование ключевой пары и корневого сертификата;
• Формирование ключевых пар и сертификатов Подчинённых ЦС;
• Формирование CRL (Certificate Revocation List, при необходимости) Корневого ЦС;
• Отключение Корневого ЦС – физическое выключение машины или полное её отключение от сети, либо извлечение ключа Корневого ЦС.

После запуска PKI Корневой ЦС функционально включается только для формирования CRL или для выпуска сертификата новым Подчинённым ЦС.

Исходя из такого сценария использования, мы примерно понимаем, как осуществляется выпуск, и что ротация корневого сертификата в нормальной жизни не выполняется (потому как, это фактически означает запуск новой PKI-инфраструктуры). А что касается хранения закрытого ключа, то обычно это любой офлайн-носитель, который можно убрать в сейф. Кто-то выбирает смарт-карту, кто-то – флэш-накопитель с резервными копиями, кто-то – жёсткий диск. Здесь многое зависит от чисто эксплуатационных требований.

В случае, если Корневой ЦС активно участвует в повседневной жизни PKI-инфраструктуры (формирует и отзывает сертификаты), то требования к хранению его ключевой пары становятся такими же, как при работе с Подчинённым ЦС. Такой сценарий крайне редко встречается в крупных инфраструктурах, но для небольших организаций вполне может использоваться.

Промежуточные сертификаты

Промежуточные сертификаты, которыми управляют Подчинённые ЦС, активно «работают» — обслуживают функционирование всей инфраструктуры. Именно с их помощью подписываются сертификаты для конечных устройств, пользователей и оборудования.

Из-за активного использования (то есть закрытый ключ постоянно «онлайн») срок жизни промежуточных сертификатов обычно значительно ниже, чем у корневого (от 1/10 до 1/2 срока жизни корневого). Но тем не менее, он (срок) всё же довольно длительный.

Ротация сертификата Подчинённого ЦС – это ручной процесс, который сопровождается техническими и организационными процедурами. Очень упрощённо, он выглядит следующим образом:

• Формирование новой ключевой пары и запроса на сертификат;
• Включение Корневого ЦС (если выключен и если промежуточный сертификат выпускается на корневом, а не на вышестоящем промежуточном сертификате);
• Выпуск нового промежуточного сертификата;
• Установка нового промежуточного сертификата на Подчинённый ЦС.

При этом необходимо понимать, что после установки нового промежуточного сертификата Подчинённый ЦС должен:

• Все новые сертификаты выпускать на новом промежуточном;
• Для старого промежуточного продолжать выпускать CRL до тех пор, пока действителен хотя бы один сертификат, выпущенный старым промежуточным.

Это крайне важно, так как необходимо обеспечить «переходный» период от старого промежуточного сертификата к новому.

Исходя из этого, хранение ключевой пары промежуточного сертификата наиболее целесообразно осуществлять в защищенном хранилище, таком как HSM (Hardware Security Module). Конечно, это дорогой, но самый безопасный вариант хранения ключа.

Тем не менее, часто ключ Подчинённого ЦС хранят непосредственно в программном обеспечении Центра Сертификации – в файловой системе или в базе данных. При этом крайне важно обеспечить его секретность организационными и/или техническими средствами. Современные операционные системы и СУБД (системы управления базами данных) позволяют делать это в достаточной мере. Главное, определиться с моделью нарушителя и бюджетом на безопасность.

Конечные «клиенты»

Под конечными «клиентами» в PKI-инфраструктуре понимаются непосредственно устройства, оборудование и сервисы, которые пользуются PKI – запрашивают для себя сертификаты, проверяют статусы, отзывают, обновляют и пр.

При этом мы понимаем и рассмотрели выше, что типов таких «клиентов» может очень много, от условного веб-сервера до сетевого маршрутизатора. Чтобы поддерживать хоть немного крупную инфраструктуру в рабочем и актуальном состоянии и исключить ручные действия администраторов по распространению сертификатов, каждый из типов таких устройств должен иметь возможность автоматически запрашивать для себя сертификат.

Необходимо также принимать во внимание, что сертификат не выдаётся Центром Сертификации «просто так», потому что его попросили. Он выдаётся по результатам проверки (одной или нескольких) того, что запрашивающий действительно тот, за кого себя выдаёт. И разные типы «клиентов» проверяются по-разному. Если для веб-сервера необходимо проверить принадлежность домена, то для пользователя – его учетные данные.

Для того, чтобы всё это работало автоматически, применяются специальные протоколы PKI, позволяющие компонентам инфраструктуры получать и обновлять сертификаты в различных сценариях без участия администратора.

Хранение

Прежде чем мы перейдём к протоколам для запуска доверия (то есть выдачи сертификатов) и ротации (их обновления), давайте поговорим о хранении. Тут практически для всех типов устройств и других участников сетевого взаимодействия принципы одинаковые.

Начнём с того, что сертификаты конечных устройств активно используются, а степень этой активности сильно зависит от типа устройства и нагрузки на него. Например, нагруженный веб-сервер использует ключ крайне активно, а пользователь может применять свой сертификат один раз для входа в домен. Но в любом случае, сертификат у конечного «клиента» PKI-инфраструктуры должен всегда быть в прямом доступе.

Дополнительно, требования к секретности закрытого ключа конечного «клиента» априори ниже, чем у Центра Сертификации, поэтому и срок действия сертификата у «клиента» ограничен.

Ещё одним критерием к выбору места хранения ключа является критичность сервиса. Например, ключ к сертификату подписи кода является в инфраструктуре более критичным, чем сертификат электронной почты рядового сотрудника.

Итого, ключи и сертификаты клиентских компонентов хранятся одним из приведенных способов, в зависимости от необходимого быстродействия и критичности секретности его ключа:

• В конфигурации устройства или сервиса;
• В программном хранилище операционной системы;
• В файловом хранилище;
• В централизованном хранилище секретов уровня предприятия;
• На смарт-карте или TPM (Trusted Platform Module).

Протоколы

После того, как «клиент» (конечное устройство, сервис, пользователь) сформировал для себя ключевую пару и, опционально, запрос на сертификат, ему необходимо запросить сертификат.

Как мы говорили выше, чтобы обеспечить необходимые автоматизированные проверки со стороны Центра Сертификации в зависимости от типа устройства, были стандартизованы несколько протоколов для PKI.

Microsoft WSTEP

WS-Trust X.509v3 Token Enrollment Extensions (WSTEP) авторства компании Microsoft поддерживается во всех современных операционных системах этой корпорации.

Если не вдаваться в подробности реализации, то набор этих протоколов и стандартов позволяет выпустить сертификат на субъект в рамках домена Microsoft Active Directory после проверки подлинности по протоколу Kerberos.

То есть, если Центр Сертификации поддерживает данный набор протоколов, то пользователь или сервис (включая оборудование) может получить сертификат на учётную запись в рамках домена без участия администратора.

Это позволяет как автоматизировать выпуск сертификатов через инструменты автоматизации, так и запрашивать их вручную (например, пользователями в рамках портала самообслуживания).

SCEP

Протокол SCEP (Simple Certificate Enrollment Protocol) очень часто ассоциируют с сетевым оборудованием Cisco, так как именно эта компания впервые предложила его реализацию.

Протокол действительно довольно прост, а проверка субъекта при выпуске сертификата выполняется через общий секрет, который в рамках протокола называется challenge.

Протокол позволяет как использовать один секрет на группу устройств (классическая реализация), так и задавать отдельный секрет на каждую учетную запись сервиса (реализация Microsoft NDES).

Сетевое оборудование чаще всего использует именно этот протокол, а параметры адреса для запроса сертификата и соответствующий challenge указываются в настройках.

ACME

ACME (Automatic Certificate Management Environment) используется для управления сертификатами веб-серверов и веб-сервисов. Такие сертификаты необходимы для установки TLS-соединений с проверкой подлинности сервера.

Также ACME широко используется в контейнерных средах, таких как Kubernates для автоматического выпуска сертификатов для приложений, разворачиваемых в контейнерах.

Проверка подлинности веб-сервиса в рамках этого протокола выполняется через проверку принадлежности домена тому субъекту, который запрашивает сертификат. Субъект может доказать владение либо через DNS-запись определенного вида, либо через размещение на своём веб-сервере определенного файла.

После того, как Центр Сертификации проверит содержание DNS-записи или файла, он выпускает сертификат на конкретный веб-адрес.

Практически любой современный веб-сервис поддерживает протокол ACME.

EST и CMP

Протоколы EST (Enrollment over Secure Transport) и CMP (Certificate Management Protocol) в настоящее время широко не используются, так как их применение является довольно нишевым. Но, тем не менее, некоторое программное обеспечение (например, OpenSSL или Bouncy Castle) имеет встроенную поддержку этих протоколов.

Другие инструменты для автоматизации

Несмотря на наличие PKI-протоколов для различных сценариев, не всё программное обеспечение поддерживает автоматический запрос сертификатов и их ротацию. В этом случае используются дополнительные инструменты, которые помогают автоматизировать различные сценарии в рамках требований к наличию сертификатов.

Например, в инфраструктуре домена Microsoft Active Directory для этих целей активно используются групповые политики, которые являются «триггером» к формированию ключей и запросу сертификата по протоколу MS WSTEP.

В доменах для операционных систем семейства Linux используется сервис Certmonger, при помощи которого можно реализовать проверку субъекта любым удобным способом (Kerberos, challenge и пр.)

И, конечно же, у администратора всегда остаётся возможность либо выпустить сертификат вручную, либо одобрить/отклонить запрос на сертификат от какого-либо «клиента» PKI.

Кто это всё умеет

Выше мы описали, хоть и кратко, довольно много различных аспектов, которые просто необходимы для автоматизации такой задачи, как управление PKI-инфраструктурой.

Центр Сертификации должен уметь хранить ключи разными способами (в зависимости от того, корневой он или нет, и насколько критичен), поддерживать множество PKI-протоколов, уметь интегрироваться со службами каталогов, предоставлять порталы администрирования и самообслуживания и много другое.

И мы в рамках данной статьи не касались вопросов поддерживаемых алгоритмов, правил валидации запросов, содержания сертификатов, управления отзывом, аудита безопасности, требований по нагрузке и других вопросов управления.

Современный Центр Сертификации – весьма сложный продукт, от выбора которого будет зависеть не только устойчивость ИТ-инфраструктуры предприятия, но стоимость владения ей, которая напрямую коррелирует с возможностями по автоматизации процесса управления сертификатами.

Автор: Павел Мельниченко, технический директор SafeTech Lab.