В 2017 году просроченный сертификат оставил средство защиты Equifax без доступа к зашифрованному трафику. Устройство не анализировало соединения 19 месяцев. Сертификат заменили — и специалисты сразу увидели подозрительные соединения. Расследование Конгресса США обнаружило в компании сотни просроченных сертификатов.
Первоначальный доступ к сети дала уязвимость Apache Struts. Причина проникновения была не в сертификате, но просрочка лишила защитный комплекс возможности видеть, как данные уходят наружу. Одна пропущенная дата создала огромную слепую зону, и никакой сирены перед этим не прозвучало.
Российские компании вернулись к теме корпоративных УЦ по нескольким причинам: миграция с Microsoft AD CS, риски поддержки зарубежных продуктов, требования технологической независимости. Единого запрета на иностранное ПО для любого бизнеса нет, обязанности зависят от отрасли и статуса информационной системы. Но там, где доверием никто не управляет, крупная сеть обрастает самоподписанными сертификатами и ручными продлениями.
Аббревиатура CA раскрывается как Certification Authority; по-русски говорят «удостоверяющий центр», сокращённо УЦ. Корпоративный УЦ подтверждает, что открытый ключ принадлежит конкретному сотруднику, устройству или сервису, и выпускает сертификат по заданной политике. Выпуском дело не кончается: сертификат придётся продлевать, отзывать при компрометации и находить, когда придёт аудит.
Что именно удостоверяет корпоративный CA
Сертификат X.509 хранит открытый ключ, сведения о владельце, имя издателя, серийный номер, срок и назначение ключа. У веб-сервера главное поле называется Subject Alternative Name, туда вписывают DNS-имена. Для пользователя, устройства или приложения набор атрибутов диктует политика выпуска.
Всё держится на паре ключей. Закрытый остаётся у владельца и не должен раскрываться, открытый уходит в запрос, а УЦ этот запрос проверяет и подписывает сертификат собственным ключом. Получателю остаётся сверить подпись издателя, имя, срок и назначение, а если проверка отзыва настроена, то и статус. Сам по себе файл CER, вынутый из цепочки доверия, не доказывает ничего.
Наверху цепочки стоит корневой УЦ; его сертификат заранее раскладывают по доверенным хранилищам систем и приложений. Полномочия подписывать конечные сертификаты корень передаёт выпускающему центру. Разделение бережёт самый ценный ключ и позволяет менять выпускающее звено, не трогая корень.
Трафик шифрует не сертификат. В TLS он подтверждает сторону соединения, а сеансовые ключи вырабатывает рукопожатие. Проверка электронной подписи говорит о том, что подписывали соответствующим закрытым ключом и данные не изменились. Свяжется ли подпись с конкретным человеком, зависит от того, как проверили личность, как защитили ключ и не скомпрометирован ли он.
Сам по себе CA закрывает лишь часть PKI. В инфраструктуру открытых ключей входят регистрация, политики, шаблоны, защита ключей, доставка доверенных корней, списки отозванных сертификатов CRL, онлайн-проверка статуса через OCSP, аудит и мониторинг. Сервер выдачи без регламентов работает как паспортный стол без реестра.
Самоподписанный сертификат слаб не из-за собственной подписи. Слабеет модель доверия: каждый такой файл приходится делать отдельной доверенной точкой, вручную разносить по хранилищам, менять и вычищать оттуда. Корпоративный УЦ даёт одну цепочку и общие правила отзыва, поэтому сотни сертификатов не превращаются в коллекцию исключений.
Где бизнес встречает корпоративные сертификаты
Внутренние сайты, панели администрирования и API работают по TLS. Если у внутреннего сервиса есть публичное доменное имя, которое можно подтвердить, сертификат для него выпустит и публично доверенный УЦ. Всё остальное — закрытые имена, устройства, сотрудников, собственные правила выдачи — берёт на себя корпоративный центр, а его корень централизованно доставляют на каждый управляемый клиент.
VPN-шлюз по сертификату отличает зарегистрированный ноутбук от случайного компьютера. Ровно до тех пор, пока закрытый ключ защищён от копирования. В сетях Wi-Fi с 802.1X проверяют сервер, пользователя или устройство; на ту же корпоративную PKI опираются смарт-карты, IPsec, почтовое шифрование и доступ администраторов.
Микросервисы идут дальше и включают взаимную аутентификацию TLS: клиент и сервер предъявляют сертификаты друг другу, а политика пропускает нужные роли и имена. Та же схема работает для контейнеров, промышленных узлов и устройств интернета вещей. Сроки здесь короткие, поэтому выдавать и ротировать сертификаты приходится автоматически.
Публичные TLS-сертификаты живут всё меньше, и без автоматического обновления с ними уже не справиться. Правила публичной Web PKI на закрытую корпоративную инфраструктуру не распространяются, но короткие сроки и ручные продления плохо уживаются везде одинаково.
Российской инфраструктуре одного X.509 мало. Проверять придётся алгоритмы, криптопровайдеры, защищённые носители, аппаратные модули HSM, Active Directory, Linux и сетевое оборудование. Запросы и обновление автоматизируют SCEP, EST и ACME, но старое приложение может принимать лишь узкий набор полей и алгоритмов.
Усиленную неквалифицированную электронную подпись внутренний УЦ обслуживать может. Юридическую силу УНЭП получает в случаях, установленных законом, нормативным актом или соглашением с правилами проверки, — так определяет Федеральный закон № 63-ФЗ. Квалифицированные сертификаты обычный корпоративный УЦ выдавать не вправе: для этого нужен предусмотренный законом статус и выполнение установленных требований.
Почему установка CA не равна готовой PKI
Ценнее закрытого ключа CA в компании мало что найдётся. Компрометация позволяет выпускать поддельные сертификаты, а потерянное доверие к корню означает перестройку PKI. Отсюда и двухуровневая офлайн-схема: корневой УЦ держат отдельно от выпускающих и включают только ради регламентных операций.
Если CA остановился, выданные сертификаты не гаснут в ту же секунду. Проверяющее приложение продолжит работать, пока цепочка доступна, а данные об отзыве не устарели; остановятся выдача и продление. А при недоступном CRL или OCSP клиенты ведут себя по-разному: одни рвут соединение, другие ограничиваются мягкой проверкой.
Управлять всем этим начинают с инвентаризации. Нужно знать, какие сертификаты выпущены, кто их владелец, какие системы от них зависят, где хранятся ключи и куда публикуются CRL. Мониторинг ведут по срокам конечных сертификатов и самого CA, по промежуточным цепочкам, сбоям автоматического выпуска и недоступности проверочных адресов. Базу и ключи резервируют в защищённом виде, порядок восстановления описывают инструкцией и регулярно проверяют на практике.
Замена Microsoft AD CS переносом базы не заканчивается. Разбираться придётся с шаблонами, групповой автоматической регистрацией, правами Active Directory, архивированием ключей и протоколами. Уже выданные сертификаты продолжают ссылаться на адрес AIA с сертификатом издателя и на точки CDP со списками отзыва, поэтому старые адреса сохраняют до окончания срока всех зависимых сертификатов. Период, когда два УЦ работают параллельно, снижает риск обрыва доверия.
Небольшой компании с несколькими внешними сайтами собственная PKI может не окупить сопровождение. VPN, внутренние порталы, управляемые устройства, микросервисы и промышленный контур уже требуют централизованного управления. Какую модель выбрать, решают изоляция, требования к ключам и компетенции команды.
- Пересчитать сертификаты: сколько их, в каких сценариях работают, кто отвечает за зависимые системы.
- Развести техническую PKI, УНЭП и квалифицированную подпись — требования к ним разные.
- Проверить алгоритмы и протоколы регистрации, а заодно выяснить, что примут старые клиенты.
- Спроектировать корневой и выпускающие УЦ вместе с защитой ключей и аудитом.
- Выдачу, ротацию, отзыв и контроль сроков перевести на автоматику.
- Заранее решить, как переносить доверие и сколько ещё публиковать старые CRL.
Календарём продлений дело не исчерпывается. Проверку способен сорвать недоступный CRL или OCSP, даже когда до истечения сертификата остаются месяцы. А сотни просроченных сертификатов в Equifax нашло расследование Конгресса — сами о себе они не сообщили.
Вопросы и ответы
Какую задачу решает корпоративный центр сертификации?
Корпоративный УЦ привязывает открытые ключи к владельцам, выпускает сертификаты по внутренним правилам, продлевает и отзывает удостоверения.
Чем CA отличается от PKI?
CA обслуживает сертификаты. PKI добавляет к этому политики, регистрацию, защиту ключей, распространение доверия, аудит и автоматизацию.
Почему публичный УЦ не заменяет корпоративный?
Публичному УЦ браузеры доверяют заранее. Корпоративный центр обслуживает внутренние имена, сотрудников, устройства и собственные политики доступа.
Будут ли сертификаты работать после остановки CA?
Выданные сертификаты могут работать до окончания срока. Новая выдача и продление остановятся, а недоступность CRL или OCSP способна нарушить проверку.
Может ли внутренний УЦ выдавать квалифицированные сертификаты?
Обычный корпоративный УЦ не вправе выдавать квалифицированные сертификаты без предусмотренного законом статуса. Правила выпуска устанавливает № 63-ФЗ.
Зачем отключать корневой УЦ от сети?
Корневой ключ подписывает выпускающие центры и используется редко. Изоляция сокращает поверхность атаки и снижает вероятность компрометации главной точки доверия.
Что проверить перед заменой Microsoft CA?
Шаблоны, автоматическую регистрацию, Active Directory, алгоритмы, протоколы, отзыв, защиту ключей и период параллельной работы двух PKI.
