HTTPS-инспекция на ИКС: безопасное внедрение, сертификаты, исключения и откат

HTTPS-инспекция позволяет шлюзу анализировать зашифрованный трафик, проверять загрузки, применять DLP-политику и блокировать опасный контент внутри TLS-сессии. Но вместе с этим шлюз фактически становится посредником между пользователем и сайтом. Поэтому включать инспекцию сразу для всей сети — плохая идея: одна ошибка в сертификатах способна остановить браузеры, почтовые клиенты, обновления и часть бизнес-приложений.

Что получим после правильной настройки

• контролируемую расшифровку HTTPS только для нужных групп;
• корпоративный корневой сертификат, которому доверяют рабочие станции;
• список исключений для банковских, медицинских и чувствительных сервисов;
• понятный способ проверить, что сертификат действительно подменяется ИКС;
• быстрый rollback без удаления сертификата со всех компьютеров.

1. Сначала определите цель

Полная расшифровка нужна не всегда. Для простой блокировки доменов часто достаточно DNS-фильтрации или контроля SNI. HTTPS-инспекция оправдана, когда нужно проверять содержимое загрузок, применять DLP, анализировать вредоносный трафик или расследовать инциденты. Чем точнее сформулирована задача, тем меньше лишнего трафика придётся расшифровывать.

2. Подготовьте корпоративный CA

ИКС подписывает подменные сертификаты своим корневым центром сертификации. Рабочие станции должны доверять этому CA, иначе пользователи увидят предупреждения о недоверенном сертификате. До включения инспекции экспортируйте только публичную часть корневого сертификата. Закрытый ключ должен оставаться на шлюзе и никогда не распространяться на клиентские компьютеры.

openssl x509 -in corporate-ca.crt -noout -subject -issuer -dates -fingerprint -sha256

Команда показывает владельца сертификата, срок действия и SHA-256 fingerprint. Этот отпечаток нужно сохранить в документации: после развёртывания CA на компьютерах можно будет убедиться, что установлен именно нужный сертификат.

3. Разверните доверие только на тестовой группе

Сначала выберите несколько компьютеров разных типов: обычную рабочую станцию, ноутбук, устройство с корпоративным антивирусом и компьютер с критичным бизнес-приложением. В домене сертификат лучше распространять через Group Policy. На тестовом ПК после установки проверьте наличие CA в доверенных корневых центрах сертификации.

certutil -store Root

В списке должен присутствовать сертификат ИКС с тем же fingerprint, который был зафиксирован ранее.

4. Включите инспекцию только для тестовой политики

Не применяйте правило ко всем пользователям. Создайте отдельную группу или политику, включите HTTPS-инспекцию только для неё и оставьте остальных пользователей на старой схеме. Это превращает потенциальную аварию во вполне управляемый тест.

5. Проверьте, что сертификат подменяется корректно

Откройте обычный HTTPS-сайт на тестовом компьютере и посмотрите цепочку сертификатов в браузере. В качестве издателя должен появиться корпоративный CA ИКС, а браузер не должен показывать ошибку доверия.

curl -Iv https://example.com

В выводе важно увидеть успешную проверку сертификата и ожидаемого издателя. Дополнительно можно посмотреть сертификат через OpenSSL.

openssl s_client -connect example.com:443 -servername example.com -showcerts

Если сертификат подписан CA ИКС и соединение проходит без ошибок, базовая схема работает.

6. Проверьте реальные приложения

Браузер — только первый тест. Обязательно проверьте почтовый клиент, Microsoft 365 или другой офисный пакет, обновления Windows, мессенджеры, банковские сервисы, VPN-клиенты и внутренние приложения. Некоторые программы используют certificate pinning и откажутся работать даже при корректно установленном корпоративном CA.

7. Создайте управляемый список исключений

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

8. Как диагностировать проблемы

Если сайт открывается по IP, но не по имени, проблема вероятнее всего в DNS, а не в TLS. Если браузер сообщает о недоверенном издателе, проверяйте установку CA. Если браузеры работают, а отдельное приложение нет, вероятен certificate pinning. Если часть сайтов открывается, а часть зависает, проверьте исключения, TLS-версии и журнал ИКС.

nslookup example.com
curl -Iv https://example.com
openssl s_client -connect example.com:443 -servername example.com

Проверять нужно по слоям: DNS, TCP 443, TLS-сертификат, затем конкретное приложение.

9. Расширяйте охват постепенно

После нескольких дней без критичных ошибок добавляйте пользователей небольшими группами. Следите за обращениями, ошибками TLS и ростом нагрузки на шлюз. Не совмещайте массовое включение инспекции с обновлением ИКС, заменой firewall или изменением маршрутизации.

Rollback

Самый быстрый откат — отключить HTTPS-инспекцию для тестовой группы или вернуть её на прежнюю политику. Удалять CA со всех компьютеров сразу не требуется: установленный, но не используемый сертификат не влияет на соединения. После отката проверьте браузер, почту, обновления и одно критичное приложение.

Критерий успеха

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