Всем привет! На связи Евгений Галкин, директор по кибербезопасности Avanpost.
В современных IT-инфраструктурах TLS-сертификаты используются практически везде: от публичных веб-сайтов до внутренних микросервисов и IoT-устройств. При этом многие системы используют самоподписанные сертификаты (self-signed certificates), особенно во внутренних сетях и тестовых средах.
С одной стороны, такие сертификаты позволяют быстро обеспечить шифрование соединений. С другой – при неправильной модели доверия они создают серьёзные риски безопасности.
В этой статье рассмотрим:
где используются self-signed сертификаты;
какие угрозы возникают в разных сценариях;
какие атаки возможны;
как внедрение корпоративного центра сертификации помогает решить эти проблемы.
Что такое самоподписанный сертификат
Самоподписанный сертификат – это сертификат, подписанный тем же субъектом, которому он принадлежит, а не доверенным центром сертификации.
В классической инфраструктуре TLS доверие строится так:
Trusted Root CA
↓
Intermediate CA
↓
Server Certificate
Браузеры и операционные системы уже содержат список доверенных корневых центров сертификации, что и обеспечивает доверие ко всей цепочке.
В случае self-signed сертификата такой цепочки доверия попросту нет, поэтому доверенное взаимодействие должно устанавливаться другими (накладными) способами, что зачастую не применяется в реальной жизни.
Где применяются самоподписанные сертификаты
Несмотря на ограничения, self-signed сертификаты широко используются во внутренних инфраструктурах.
Внутренние сервисы и микросервисы
Во многих компаниях внутренние API и сервисы используют TLS исключительно для шифрования трафика внутри сети.
Типичные примеры:
микросервисы;
административные панели;
внутренние API;
сервисы в приватных сетях.
В таких системах self-signed сертификаты часто используются, потому что:
инфраструктура изолирована;
нет необходимости в публичном доверии;
сертификаты легко генерировать.
Development и тестовые среды
В процессе разработки часто необходимо тестировать HTTPS-соединения.
Self-signed сертификаты позволяют:
тестировать secure cookies;
проверять политики безопасности;
разрабатывать OAuth и SSO системы.
Корпоративный PKI
Интересно, что самоподписанные сертификаты используются даже в правильно построенной PKI-инфраструктуре.
Корневой центр сертификации всегда является self-signed:
Root CA (self-signed)
↓
Intermediate CA
↓
Service Certificates
И это нормальная практика, но при условии, что в корпоративной сети корректно настроено доверие к корневому CA, иначе корпоративная PKI не имеет никакого смысла.
Mutual TLS и Zero-Trust архитектуры
Во многих современных системах используется двусторонняя аутентификация (mTLS). Она применяется в:
микросервисных архитектурах;
service mesh;
внутренних API.
Существуют популярные инструменты для управления такими сертификатами (например, HashiCorp Vault), однако они закрывают лишь вопросы автоматизации получения сертификатов и их установки, вопросы корпоративного доверия остаются открытыми.
Kerberos PKINIT
PKINIT – это Public Key Cryptography for Initial Authentication in Kerberos: расширение Kerberos, которое использует асимметричную криптографию и X.509-сертификаты на самом первом шаге аутентификации, вместо обычной парольной pre-auth. В MIT Kerberos прямо указано, что PKINIT – механизм preauthentication (предварительная проверка подлинности), где клиент и KDC могут аутентифицировать друг друга с помощью сертификатов.
Где он применяется:
вход по смарт-карте / токену;
среды, где хотят уменьшить зависимость от паролей;
Kerberos-инфраструктуры с PKI;
некоторых сценариях анонимного initial auth в Kerberos.
Проблема следует из самого определения механизма PKINIT – самоподписанный сертификат не подтверждает подлинность владельца сам по себе. Обеспечивается лишь целостность данных, но не гарантируется аутентичность. При этом trust anchor сертификаты (доверенные корневые сертификаты, которые используются в kerberos: у клиента – для проверки сертификатов KDC, у KDC – для проверки клиентских сертификатов) часто являются самоподписанными.
IoT и embedded устройства
Многие устройства используют self-signed сертификаты из-за ограниченных ресурсов, как вычислительных, так и инфраструктурных.
Типичные примеры:
камеры видеонаблюдения;
сетевое оборудование;
промышленная автоматика в АСУ ТП;
домашние роутеры и т.д.
И если в случае с домашним роутером риски минимальны, то для АСУ ТП или систем видеонаблюдения компрометация может привести к серьезным последствиям.
Основные угрозы использования self-signed сертификатов
Основная проблема self-signed сертификатов – отсутствие независимой проверки подлинности. Это приводит к нескольким классам атак. Рассмотрим подробнее.
MITM-атаки и подмена сервисов
Наиболее распространённая является атака Man-in-the-Middle.
Базовый сценарий следующий:
1. злоумышленник получает доступ к сети
2. поднимает поддельный сервер
3. выдаёт свой self-signed сертификат
Если клиент не проверяет сертификат (те самые накладные меры, которые обычно не применяются в случае self-signed – отключенная проверка TLS), соединение будет установлено.
В результате атакующий может:
перехватывать трафик;
красть токены (например, bootstrap);
модифицировать запросы и т.д.
Без централизованной модели доверия любой сервис может выдать свой сертификат, что делает возможным полную подмену сервиса или ряда сервисов.
В комбинации с атакой типа DNS spoofing это позволяет атакующему:
создать fake-API;
выдавать себя за другой сервис;
обрабатывать реальные запросы от других сервисов и участников.
Особенно опасно это в микросервисных архитектурах, когда ряд сервисов становится "отравленным". Это несет значительные риски уже для всей инфраструктуры, ведь злоумышленник может не просто красть данные, но и реализовать собственную логику их обработки и оказать влияние на бизнес-процессы глобально.
Компрометация приватных ключей
Если приватный ключ сервиса украден, атакующий может полностью имитировать сервис. Для dev-сред это характерно в силу того, что зачастую сертификаты и ключи попадают в репозитории и могут "протягиваться" вплоть до продуктивных сред.
Последствием является все та же подмена, и эта атака справедлива и при полностью корректно выстроенной инфраструктуре доверия, однако при self-signed сертификатах ситуация сильно осложняется тем, что:
нет централизованного отзыва сертификатов;
невозможно быстро заблокировать компрометированный ключ.
В данной ситуации мы лишаемся как механизмов быстрого реагирования, так и превентивных возможностей защиты, таких как периодическая ротация сертификатов.
"Отравление" доверенного хранилища
Ещё один тип атак – подмена доверенных корневых сертификатов в enterprise-средах.
Атакующий может установить собственный root сертификат в корпоративную систему:
через malware;
через групповые политики домена;
через социальную инженерию;
через MDM и т.д.
После этого браузеры всех корпоративных компьютеров будут доверять всем сертификатам атакующего, а MITM станет полностью незаметным.
Риски для PKINIT
Главный риск заключается все в том же: если злоумышленник сможет подменить сертификат в момент первичной установки доверия, клиент начнёт доверять не тому узлу. Это классическая основа для MITM/impersonation-сценариев. Проблема даже не в том, что сертификат “сам подписан”, а в том, что нет внешнего независимого подтверждения личности, и вся безопасность переносится на канал доставки trust anchor.
OWASP описывает MITM как атаку на канал связи с подменой сторон, а NIST отдельно подчёркивает, что доверие к self-signed сертификатам держится на безопасной дистрибуции.
Особено болезненной является ситуация, когда скомпрометирован ключ и self-signed сертификат, который выступает в роли trust anchor ("доверенного корня") – это позволяет злоумышленнику выпустить для себя сертификат PKINIT на имя любого пользователя домена и от его имени получить доступ к любому хосту или приложению без знания пароля, включая административный доступ к контроллеру домена (а это уже полная компроментация всей инфраструктуры компании - с этого момента злоумыленник имеет полный доступ к любым данным, хранимым в интрасети компании).
Угрозы в IoT-инфраструктурах
IoT устройства часто используют одинаковые сертификаты на всех устройствах.
Если один ключ скомпрометирован, то скомпрометированы ВСЕ УСТРОЙСТВА!
Атакующий может:
подделывать устройства;
получать доступ к инфраструктуре;
перехватывать данные и т.д.
Также зачастую отсутствуют механизмы:
периодического обновления сертификатов;
отзыва сертификатов;
безопасного хранения ключей.
Это осложняет последствия так как скомпрометированные ключи остаются активными долгое время.
Повышенные риски в контейнерных инфраструктурах
Ещё один критически опасный сценарий – компрометация bootstrap-ключей. Под этим понимается ситуация, когда секретные ключи или токены, используемые на этапе первичной инициализации системы (например, в Kubernetes), становятся известны злоумышленникам.
Bootstrap-ключи применяются в следующих процессах:
начальная настройка серверов и кластеров;
доверенная загрузка (Secure Boot);
первичная аутентификация узлов в инфраструктуре;
автоматическая конфигурация облачных ресурсов;
подпись и публикация программных пакетов в цепочке поставок ПО и т.д.
Особенность таких ключей заключается в том, что они фактически выступают корнем доверия для всей системы, их компрометация может поставить под угрозу всю инфраструктуру. Если отсутствует централизованный центр сертификации и контроль над ключами и проверка подлинности участников реализуются вручную или упрощёнными механизмами, это создаёт дополнительные векторы атак, через которые bootstrap-ключи могут быть скомпрометированы.
Главная проблема при использовании self-signed сертификатов - отсутствие централизованной проверки подлинности.
Без корпоративного центра сертификации:
невозможно надёжно проверить источник сертификата;
отсутствует централизованный контроль выпуска сертификатов;
сложнее отзывать скомпрометированные ключи;
часто используется упрощённая модель доверия.
В результате атаки на bootstrap-процессы становятся значительно проще.
Как корпоративный CA решает эти проблемы
Для устранения описанных рисков организации внедряют корпоративную PKI-инфраструктуру.
Один из наиболее распространённых инструментов – Microsoft Active Directory Certificate Services, однако в современных реалиях его применение ограничено только инфраструктурой Microsoft.
В linux-инфраструктурах необходимы иные механизмы и средства защиты, не говоря уже о КИИ и государственных информационных системах, где они должны быть в том числе и сертифицированные.
Рассмотрим все основные преимущества, которые дает корпоративный CA и правильно построенная PKI, и как они способны повысить уровень информационной безопасности и защититься от описанных выше угроз.
Централизованная модель доверия и проверка цепочки доверия
Корпоративный CA создаёт единую цепочку доверия.
Corporate Root CA
↓
Intermediate CA
↓
Service Certificates
Клиенты доверяют только сертификатам, подписанным этим CA.
Это устраняет возможность простой подмены сертификатов, что делает атаки класса MITM и подмены сервисов крайне затруднительными и невыгодными для злоумышленника с точки зрения затрат на реализацию т.к. сводятся к сложности взлома криптосистемы, что невозможно осуществить за полиномиальное время.
P.S. Мы не рассматриваем в данной статье угрозу класса Q-day, когда суперкомпьютер сможет вскрыть любую классическую криптосистему, но обязательно поговорим об этом в ближайшем будущем :)
Как это работает – при установке TLS-соединения клиент проверяет:
подпись сертификата;
цепочку доверия;
имя сервиса;
срок действия сертификата.
Если сертификат не подписан доверенным CA, или не пройдена любая другая проверка безопасности, соединение будет отклонено.
Отзыв сертификатов
Корпоративный CA поддерживает механизмы отзыва сертификатов и стандартные сервисы и возможности для проверки статуса каждого сертификата.
CRL (Certificate Revocation List) – список отозванных сертификатов.
Если ключ сервиса скомпрометирован, сертификат можно немедленно отозвать, и он будет включен в следующий CRL. После обновления CRL эта информация станет доступна всем участникам доверенный среды.
OCSP (Online Certificate Status Protocol) позволяет проверять статус сертификата в режиме реального времени, не дожидаясь публикацию и распространения нового CRL.
Эти механизмы эффективно предотвращают использование украденных сертификатов и ключей.
Контроль выпуска сертификатов
Корпоративный CA и системы управления PKI позволяют контролировать и управлять такими характеристиками, как:
кто может выпускать сертификаты;
для каких доменов;
для каких сервисов.
Подключаясь к инфраструктуре (к доменам, кадровым системам и системам учета, системам класса IDM и т.д.), они способны реализовать комплексные политики безопасности и разграничить доступ к выпуску сертификатов.
Например:
Dev-команда может выпускать сертификаты для dev-среды;
Ops-команда - для production;
Сотрудники службы безопасности согласовывают выпуск сертификатов электронной подписи;
И т.д.
Это предотвращает несанкционированный и неконтролируемый выпуск сертификатов и выводит централизацию управления сертификатами на абсолютно новый уровень.
Реализация mutual TLS
Корпоративный CA позволяет внедрить двустороннюю аутентификацию. В этом случае в клиент-серверном взаимодействии каждый использует свой сертификат и каждый проверяет сертификат своего "собеседника" на предмет действительности и корректности.
На техническом уровне это достигается за счет использования механизмов автоматизации выпуска и доставки сертификатов (autoenrollment) и за счет применения широко распространенных и поддерживаемых протоколов: SCEP; MS-WSTEP; ACME и т.д.
Даже при компрометации сети злоумышленник не сможет подключиться без действительного сертификата. В совокупности с другими методами защиты и управления, которые мы рассматриваем в этой статье, получить действительный сертификат становится крайне затруднительно.
Управление жизненным циклом и качеством сертификатов
CA и корпоративная система управления PKI также решает проблему управления сертификатами.
Они позволяют:
выпускать сертификаты строго по назначению;
автоматически обновлять их;
отслеживать сроки действия;
вести инвентаризацию;
следить за качеством сертификатов;
вовремя выявлять нарушения и сигнализировать о них.
CA может выдавать сертификаты с разными политиками применения, например:
Server Auth - веб-сервер;
Client Auth - пользователь;
Code Signing - подпись ПО;
Email Protection - S/MIME;
и т.д
Это предотвращает злоупотребления, например, сертификат для сервера нельзя использовать как клиентский.
С развитием возможностей технических средств все важнее становится задача управления качеством сертификатов. Стандартной уже является следующая политика качества:
короткие сроки жизни сертификатов (30–90 дней);
обязательные ключи ≥ 2048 бит;
обязательный SAN;
запрет wildcard.
Это повышает общий уровень криптографической безопасности и стойкости всей системы.
Защита приватного ключа
Приватный ключ является краеугольным камнем безопасности всей системы, а корневой CA - критическим элементом инфраструктуры.
Ключи должны храниться в:
HSM (Hardware Security Module);
защищённых хранилищах ключей;
изолированных системах.
Это предотвращает компрометацию всей инфраструктуры.
Обеспечить такие условия без централизации механизмов управления практически невозможно, это ведет к непосильным затратам команд на местах и полностью зависит от человеческого фактора и банальной забывчивости и непонимания непрофильными специалистами.
Заключение
Самоподписанные сертификаты сами по себе не являются небезопасными. Они широко используются во внутренних инфраструктурах, development-средах и IoT-устройствах. Однако при отсутствии централизованной модели доверия они создают серьёзные риски:
MITM-атаки;
подмена сервисов;
компрометация ключей;
отсутствие механизмов отзыва сертификатов.
Внедрение корпоративного центра сертификации позволяет построить управляемую PKI-инфраструктур.
В современных архитектурах, особенно в микросервисных и zero-trust системах, корпоративный CA становится ключевым элементом безопасности инфраструктуры и обеспечивает возможность применения лучших практик для минимизации рассмотренных рисков:
1. использовать двухуровневую архитектуру CA (root + intermediate)
2. хранить root-ключ в оффлайн-режиме
3. использовать короткие сроки жизни сертификатов
4. автоматизировать выпуск и ротацию сертификатов
5. внедрять mutual TLS для внутренних сервисов
6. регулярно проводить аудит сертификатов и следить за их качеством
