Самоподписанные сертификаты в современной инфраструктуре: риски, угрозы и роль к

Коротко о статье

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

Главное

• Самоподписанный сертификат подписан тем же субъектом, которому принадлежит, а не доверенным центром сертификации, поэтому цепочка доверия отсутствует.
• Такие сертификаты применяются во внутренних сервисах и микросервисах, dev- и тестовых средах, корпоративном PKI, mTLS, Kerberos PKINIT и IoT-устройствах.
• Основная угроза — отсутствие независимой проверки подлинности, что открывает путь MITM-атакам, подмене сервисов и компрометации приватных ключей.
• Отдельные риски возникают при отравлении доверенного хранилища, в PKINIT, IoT-инфраструктурах и контейнерных средах с bootstrap-ключами.
• Корпоративный CA создаёт единую цепочку доверия, поддерживает отзыв сертификатов через CRL и OCSP и контролирует их выпуск.
• CA обеспечивает mutual TLS, управление жизненным циклом и качеством сертификатов, а также защиту приватного ключа в HSM и изолированных системах.

Термины и технологии

• self-signed certificates
• TLS-сертификаты
• центр сертификации
• PKI
• Mutual TLS
• Kerberos PKINIT
• CRL
• OCSP

Кому полезно: Инженерам АСУ ТП, ИБ-специалистам и администраторам инфраструктуры

Первоисточник: habr.com

Выжимка составлена редакцией сайта с помощью ИИ по тексту статьи.

Всем привет! На связи Евгений Галкин, директор по кибербезопасности 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. злоумышленник получает доступ к сети

1. поднимает поддельный сервер

1. выдаёт свой 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)

1. хранить root-ключ в оффлайн-режиме

1. использовать короткие сроки жизни сертификатов

1. автоматизировать выпуск и ротацию сертификатов

1. внедрять mutual TLS для внутренних сервисов

6. регулярно проводить аудит сертификатов и следить за их качеством

Источник: https://habr.com/ru/companies/avanpost/articles/1016710/