Корпоративный удостоверяющий центр на open source: PKI без вендора

Зачем компании PKI и где возникают проблемы без вендора

Корпоративный удостоверяющий центр (УЦ) на open source нужен, когда компании важно управлять доверием внутри своей инфраструктуры: кто и к чему подключается, какие сервисы действительно ваши, и как быстро закрыть доступ, если что-то пошло не так. PKI без вендора дает свободу и экономию, но забирает на себя ответственность за правила, сроки и контроль.

На практике УЦ решает несколько понятных задач: шифрует трафик, подтверждает подлинность сервисов и пользователей и помогает соблюдать требования безопасности. Сертификаты встречаются чаще, чем кажется: корпоративный портал в браузере, подключение к VPN, защищенная почта, аутентификация устройств в Wi-Fi.

Что обычно ломается без вендора

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

Чаще всего проблемы выглядят так:

• сертификаты выдают без заявки и проверки личности или устройства
• не определены сроки: кто продлевает и что делать при компрометации
• закрытые ключи хранятся небезопасно, доступ есть у слишком многих
• CRL/OCSP настроены формально, а сервисы не проверяют отзыв
• нет учета, и через год никто не понимает, где какой сертификат используется

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

Почему важны регламенты и роли

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

Базовая архитектура корпоративного УЦ простыми словами

УЦ на open source обычно строят не как один сервер с «волшебной кнопкой», а как набор отдельных ролей. Это снижает риск компрометации ключей и упрощает контроль.

Главное разделение - Root CA и выпускающий (Issuing) CA. Root CA подписывает только сертификаты подчиненных УЦ и не участвует в ежедневной выдаче. Issuing CA уже подписывает сертификаты пользователей, серверов, Wi-Fi, устройств и сервисов.

Root CA почти всегда держат офлайн: выключенным и физически защищенным. Его включают редко - например, чтобы выпустить новый сертификат для Issuing CA или обновить список отзыва. Issuing CA, наоборот, работает в онлайн-контуре и доступен тем, кто делает запросы на сертификаты.

Чтобы системы понимали, можно ли доверять сертификату прямо сейчас, нужны механизмы проверки отзыва:

• CRL (список отозванных сертификатов) - файл, который клиенты периодически скачивают и проверяют.
• OCSP - онлайн-ответчик «валиден или отозван» в момент проверки.

Во внутренних контурах CRL часто достаточно. OCSP обычно нужен там, где проверка должна быть быстрой и частой: веб-сервисы, прокси, критичные точки входа.

Точки интеграции лучше продумать заранее, иначе PKI без вендора быстро превращается в набор ручных операций. Обычно заранее решают, как будут связаны УЦ и:

• AD/LDAP (привязка выпуска к учетным записям и группам)
• веб-сервисы (автоматизация установки и продления TLS)
• NPS/RADIUS (EAP-TLS в корпоративном Wi-Fi)
• MDM (выдача сертификатов устройствам и контроль ключей)

Простой сценарий: сотруднику выдают ноутбук. MDM ставит профиль Wi-Fi с EAP-TLS и сертификат устройства, внутренний портал получает TLS-сертификат, а при увольнении сертификаты пользователя и устройства отзываются, и это отражается в CRL/OCSP. Так архитектура остается понятной и управляемой даже при полностью open source стеке.

Выбор open source стека: критерии и типовые варианты

Выбор стека для УЦ лучше начинать не с названий продуктов, а с того, какие сертификаты вы будете выдавать и кому. Сертификаты для веб-сервисов, VPN, Wi-Fi (EAP-TLS), устройств и пользователей требуют разных протоколов и разной дисциплины учета.

Сначала проверьте базовые вещи, которые потом сложнее всего «допилить»:

• поддержка нужных алгоритмов и профилей (RSA/ECDSA, длины ключей, EKU)
• автоматизация: ACME для веб-сервисов и, при необходимости, SCEP для сетевого оборудования
• журналирование и аудит: кто запросил, кто одобрил, когда выпущено и когда отозвано
• разделение ролей (CA и RA), чтобы не раздавать админские права всем подряд
• удобная публикация и проверка статуса: CRL и OCSP

Технически стек обычно состоит из нескольких частей: CA (подпись), RA (прием заявок и проверка), хранилище (сертификаты, заявки, метаданные), публикация CRL и сервис OCSP. Даже если вы начинаете с одного сервера, полезно сразу понимать, что и когда будет вынесено отдельно.

Часто выбор выглядит так:

• OpenSSL и скрипты: минимум зависимостей, максимум ручной дисциплины
• EJBCA: много готового (RA, профили, аудит), удобно для сложных политик
• Dogtag: сильная PKI-экосистема, часто в Linux-ориентированных средах
• Step CA: удобен для автоматической выдачи и коротких жизненных циклов

Совместимость лучше проверять на стенде: один внутренний веб-сервис (TLS), один профиль для Wi-Fi EAP-TLS и пара клиентских ОС. Отдельно протестируйте импорт цепочек и CRL/OCSP в ваших контроллерах Wi-Fi, браузерах и прокси. Если инфраструктура работает на локальном железе, проверьте, что выбранные компоненты нормально живут в вашей ОС, виртуализации и используемых криптомодулях.

Политики и регламенты: без них УЦ не работает стабильно

Технически УЦ на open source можно поднять за пару дней. Но без правил он быстро превращается в источник рисков: кто-то выпускает сертификат «на всякий случай», кто-то хранит ключи в общем каталоге, а при инциденте непонятно, что отзывать и кто отвечает.

Какие документы действительно нужны

Достаточно короткого набора, который реально поддерживать в актуальном виде:

• CP/CPS: что вы выдаете, кому и как подтверждаете (проверки, журналирование, сроки хранения логов)
• политика ключей: где генерируются ключи, кто имеет доступ, как делаются бэкапы, как уничтожаются носители
• регламент заявок: как запрашивают сертификат, какие данные обязательны, кто согласует, какие SLA по выпуску и отзыву
• профили сертификатов: типы (TLS, клиентские, Wi-Fi), поля, расширения, требования к алгоритмам

Роли и ответственность

Роли лучше описать так, чтобы один человек не мог незаметно «и одобрить, и выпустить»:

• владелец УЦ (обычно ИБ): утверждает политики, принимает риск по исключениям
• оператор УЦ: выпускает и отзывает строго по заявкам, ведет журналы
• владельцы систем (веб, Wi-Fi, VPN): отвечают за корректные имена, установку и обновления
• аудит/контроль: периодически проверяет выпуски, права доступа и изменения конфигурации

Дальше важны конкретные правила профилей: сроки действия (например, 90-180 дней для внутренних TLS), единый формат именования (FQDN, обязательные SAN), минимальные требования к ключам (например, RSA 3072 или ECDSA) и запрет устаревших хэшей.

Отдельно опишите процесс исключений. Если бизнес просит «срочно и проще», должен быть понятный путь: кто согласует, какой срок у временного сертификата и что именно упрощается. Например, ускоренная проверка только для внутренних стендов, срок 7 дней и обязательный отзыв при просрочке.

Развертывание УЦ: root, issuing, CRL и OCSP

Чтобы УЦ на open source работал предсказуемо, его лучше сразу разделить на роли. Идея простая: самый важный ключ живет офлайн, а ежедневная работа идет на отдельном защищенном сервере.

Root CA: офлайн и минимум доступа

Root CA подписывает только промежуточные УЦ и, при необходимости, собственные списки отзыва. Его держат выключенным и изолированным: отдельная машина без постоянной сети, зашифрованные носители, доступ по регламенту. Проведите короткую церемонию ключей: кто присутствует, где хранятся пароли, как делаются копии, кто и при каких условиях имеет право включить root.

Issuing CA: рабочая лошадка

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

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

Обычно в развертывании предусмотрены:

• Offline Root CA
• Issuing CA (онлайн)
• публикация CRL (HTTP-файлы)
• OCSP responder (если нужен)
• сбор логов и контроль времени

CRL публикуйте так, чтобы он всегда был доступен клиентам. Частота зависит от риска: чем быстрее нужен отзыв, тем чаще обновляйте CRL. OCSP нужен, когда вы хотите проверять статус почти в реальном времени или когда CRL слишком большие. Для отказоустойчивости держите минимум два экземпляра OCSP и следите за кешированием ответов.

Отдельно проверьте две вещи, которые часто ломают PKI: точное время (NTP на всех узлах) и неизменяемость журналов. Логи выпуска и отзыва лучше писать в централизованное хранилище с правами только на добавление.

Пошаговый процесс выпуска сертификатов в компании

Чтобы PKI без вендора не превратилась в «ручную магию», процесс выпуска сертификатов должен быть одинаковым для всех и повторяемым. Тогда админы не спорят о правилах, а владельцы сервисов заранее знают, что и когда получат.

Обычно выпуск выглядит так:

1. Заявка. Ее подает владелец сервиса или ответственный за подразделение. В заявке указывают назначение (веб, VPN, Wi-Fi, подпись кода), имена (CN и SAN), срок, среду (prod или test) и контакт для согласований.

2. Подтверждение права. Для пользователя это проверка личности по внутренним правилам. Для сервиса проверяют право владения: кто управляет доменом, кто владелец приложения, кто отвечает за узел.

3. Проверки перед выпуском. Уточняют домен и имена, корректность SAN, назначение и расширения (serverAuth или clientAuth), совместимость с целевой системой и реальный срок жизни.

4. Выдача и доставка. Сертификат отдают в нужном формате: PEM для серверов и PFX, когда требуется перенос вместе с ключом. PFX защищают паролем и передают пароль по отдельному каналу.

5. Установка и приемка. Владелец сервиса устанавливает сертификат и проверяет цепочку. Команда УЦ фиксирует факт выдачи и кто принял.

Для корпоративного Wi-Fi обычно нужен клиентский сертификат. Значит, важно заранее решить, как подтверждается владелец устройства, кто имеет право запросить выпуск и как сертификат попадет на ноутбук или телефон без ручного копирования ключа.

Ротацию планируйте заранее: перевыпускайте до истечения срока, оставляя окно на установку и проверку. Для критичных веб-сервисов держите запас времени и тестовый контур, чтобы обновление не привело к простою.

Учет не должен быть формальностью. Минимально фиксируют: владельца, назначение, имена (CN/SAN), срок, серийный номер, где установлен и кто согласовал.

Отзыв сертификатов: правила, сроки и проверка результата

Отзыв нужен, когда сертификату больше нельзя доверять. В PKI без вендора это особенно важно: автоматизация может быть разной, а риск один и тот же.

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

Кто отзывает и какие подтверждения нужны

Право на отзыв должно быть ограничено и проверяемо. Обычно это RA-оператор или команда ИБ, а запрос подтверждает руководитель подразделения или владелец сервиса.

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

Сроки и как проверить, что отзыв реально работает

Установите SLA: за сколько минут или часов отзыв должен появиться в CRL и/или OCSP и стать видимым клиентам. Для критичных сервисов цель обычно ближе к минутам, а не к суткам.

Проверьте это тестом: выпустите стендовый сертификат для веб-сервиса или Wi-Fi, подключите клиента, затем отзовите сертификат и убедитесь, что доступ прекращается.

Короткий практический чек:

• отзыв отражается в CRL (новая версия опубликована вовремя)
• OCSP отвечает статусом revoked для серийного номера
• клиентские устройства и браузеры перестают принимать сертификат
• сервисы не кешируют статус слишком долго
• логирование фиксирует отказ и причину, а не просто «ошибка подключения»

Если после отзыва сервис продолжает работать, проблема почти всегда в проверке статуса: CRL не подтягивается, OCSP не используется, слишком длинный кеш или проверка отключена на стороне приложения.

Хранение ключей: от файлов до HSM и процедур доступа

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

Где генерировать ключи зависит от риска и удобства. Для серверных TLS-сертификатов ключ обычно создают на самом сервере или на отдельной админ-станции и затем устанавливают. Для пользовательских и некоторых устройств безопаснее генерировать ключ прямо на устройстве, чтобы он никогда не покидал его хранилище. Для ключей УЦ лучше сразу планировать HSM или хотя бы строгий офлайн-режим.

Ключи CA - особый случай. Root CA держат выключенным и изолированным: ключ хранится на офлайн-носителе или в HSM, доступ только по процедуре. Issuing CA может работать онлайн, но тоже с жесткими ограничениями: минимум администраторов, отдельные учетные записи, журналирование операций.

Контроль доступа и разделение полномочий

Полезная практика - «две пары глаз» на критические действия. Например, выпуск сертификата для нового домена компании или отзыв промежуточного сертификата подтверждают два человека: один выполняет операцию, второй проверяет заявку и фиксирует согласование.

Минимальный набор правил, который реально соблюдают:

• Root CA включают только для редких операций (выпуск/обновление Issuing CA, публикация ключевых артефактов)
• доступ к ключам CA дают только через отдельные админ-аккаунты и отдельные рабочие места
• все операции с ключами и заявками логируют и регулярно просматривают
• пароли и PIN не хранят в почте и чатах, используют менеджер секретов или бумажный сейф
• для HSM заранее назначают владельца, запасного владельца и порядок разблокировки

Резервные копии и восстановление

Копировать нужно не только ключи, но и базу выдачи, конфигурацию, CRL/OCSP-материалы и шаблоны политик, иначе восстановление будет «частичным». Бэкап шифруют, хранят отдельно от УЦ и минимум раз в квартал делают тестовое восстановление на стенде.

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

Интеграция с веб-сервисами и Wi-Fi: что предусмотреть заранее

Веб-сервисы: TLS без сюрпризов

Для внутренних и внешних веб-сервисов важны не только TLS-сертификаты, но и корректная цепочка доверия. Клиент должен «видеть» полный путь: серверный сертификат -> issuing CA -> root CA. Если цепочка собрана неправильно, часть клиентов будет ругаться даже при валидном сертификате.

Заранее продумайте обновление сертификатов без простоя. Обычно для этого делают короткий срок жизни (например, 60-90 дней) и автоматическую ротацию с перезапуском только нужного процесса, а не всей системы.

Автоматизация часто строится вокруг ACME для внутренних сервисов. Это удобно, но требует правил: кому можно выпускать сертификаты, какие домены разрешены, как подтверждается владение именем. Для wildcard (например, *.corp.local) лучше вводить отдельное согласование: один такой сертификат часто открывает доступ сразу ко многим сервисам.

Wi-Fi: EAP-TLS и требования к клиентам

В Wi-Fi с EAP-TLS фокус смещается на клиентские сертификаты и роль RADIUS (часто вместе с NPS). Здесь важно, чтобы сертификат клиента имел правильное назначение (Client Authentication), понятный идентификатор пользователя или устройства и корректные поля SAN.

Хаос хорошо снижает простое решение: отдельные профили сертификатов под разные задачи. Например, один профиль для серверов (Server Authentication и строгие SAN), отдельные профили для пользователей и устройств (Client Authentication с привязкой к учетной записи или инвентарному ID), и отдельный профиль для администраторов с коротким сроком жизни и усиленным контролем.

Перед вводом в эксплуатацию сделайте проверки на тестовом контуре:

• проверка полной цепочки доверия на разных клиентах
• проверка автообновления сертификата без простоя сервиса
• проверка отклика OCSP и актуальности CRL
• пробное подключение Wi-Fi: успешный вход и корректная атрибуция роли
• проверка отзыва: клиентский сертификат должен перестать работать в заданный срок

Частые ошибки при построении PKI без вендора

Ошибки в PKI без вендора часто видны не сразу. Сертификаты выпускаются, пользователи довольны, а через полгода оказывается, что управлять всем этим почти невозможно.

Одна из частых проблем - попытка сделать один CA на все случаи: для сотрудников, серверов, Wi-Fi, тестовых стендов и временных задач. Сначала это кажется проще, но потом вы не можете разделить риски, сроки и права, а любое изменение политики задевает всех.

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

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

Отдельный класс ошибок связан с ключами УЦ. Когда ключи CA лежат на том же сервере, что и веб-сервисы, и доступ к ним у нескольких админов без журналирования, компрометация одной машины превращается в компрометацию всей инфраструктуры.

Еще одна ошибка - менять сразу в прод. Без тестовой среды вы узнаете о проблеме в момент, когда Wi-Fi перестает пускать сотрудников или внутренний портал начинает ругаться на цепочку.

Практичный минимум, который обычно спасает:

• разделяйте роли CA (хотя бы issuing отдельно от root)
• держите CRL/OCSP доступными и проверяйте обновление по расписанию
• ограничивайте сроки и ведите учет, где какой сертификат установлен
• защищайте ключи CA (изоляция, контроль доступа, журналы; лучше - HSM)
• проверяйте изменения в тесте, затем выкатывайте по плану

Если вы строите корпоративный удостоверяющий центр на open source, воспринимайте эти пункты как условия выживания. Они делают PKI управляемой, а инциденты - локальными, а не массовыми.

Короткий чеклист перед запуском и следующие шаги

Перед запуском УЦ полезно пройти короткую проверку. Она занимает час-два, но часто спасает от ситуаций, когда сертификаты уже выданы, а проверка статуса или ротация внезапно ломают сервисы.

До первого «боевого» выпуска стоит подтвердить:

• Root CA действительно офлайн: хранится отдельно, доступ по понятной схеме, есть план, как подписать новый issuing без импровизации.
• CRL и OCSP доступны из всех нужных сетей (внутренняя, DMZ, филиалы, VPN) и обновляются по расписанию.
• Роли и ответственность описаны: кто утверждает запрос, кто выпускает, кто имеет доступ к ключам, где ведутся журналы действий и как их проверяют.
• Есть процедура аварийного отзыва: кто дает команду, кто выполняет, кто проверяет, что клиенты реально начали отклонять сертификат.
• Ведется инвентаризация: где стоят сертификаты, на какой срок выданы, кто владелец, и есть календарь ротации с напоминаниями.

Дальше не пытайтесь охватить все сразу. Начните с пилота: 1-2 внутренних веб-сервиса и Wi-Fi для небольшой группы сотрудников. Например, один портал в интранете и корпоративный SSID для отдела ИТ. Так вы проверите цепочку доверия, авторазвертывание, поведение клиентов при отзыве и реальную нагрузку на OCSP.

После пилота закрепите результат: обновите регламенты по фактам, добавьте мониторинг CRL/OCSP и сроки ротации, затем расширяйте охват на остальные сервисы и площадки.

Если для УЦ, OCSP и журналирования нужны надежные серверы и помощь с интеграцией, в Казахстане часто привлекают GSE.kz (gse.kz) как производителя и системного интегратора: у компании есть собственные серверы и рабочие станции, а также круглосуточная техническая поддержка и сервисная сеть.