Как DLP контролирует HTTPS-трафик: инспекция зашифрованных соединений

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

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

Почему HTTPS — слепая зона для контроля утечек

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

DLP в целом контролирует каналы передачи данных и распознает в них конфиденциальную информацию. Общий принцип работы такой системы разобран в статье «Что такое DLP-система». Здесь — только про HTTPS: что именно скрыто внутри зашифрованного соединения и как это увидеть, оставаясь в рамках технической защиты информации, а не взлома трафика.

Что такое HTTPS-соединение

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

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

Механика SSL/TLS-инспекции: как DLP «расшифровывает» трафик

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

SSL-инспекция через подменный сертификат (man-in-the-middle на шлюзе)

Корпоративный корневой сертификат устанавливается на устройства сотрудников, а сетевой шлюз становится посредником между браузером и внешним сервером: разрывает исходное TLS-соединение, расшифровывает трафик своим сертификатом, анализирует содержимое и заново зашифровывает его — уже для передачи на сервер назначения. Это классическая проверка SSL/TLS-сертификатов и HTTPS на промежуточном узле, технически идентичная MITM-атаке (от англ. man-in-the-middle — «человек посередине»), но в рамках корпоративной инфраструктуры, а не как атака.

Инспекция на конечной точке (агент)

Второй путь — не расшифровывать трафик посередине, а увидеть данные там, где они еще не были зашифрованы: на самой рабочей станции. Агент на конечной точке фиксирует действия пользователя до того, как браузер отправит данные по TLS, или считывает их сразу после расшифровки на стороне клиента. Подмена сертификата здесь не требуется — агент работает с содержимым локально, независимо от того, как устроено соединение дальше.

Где инспектировать: агент на рабочей станции или сетевой шлюз

Это ключевой архитектурный выбор, и у каждого варианта — свои сильные стороны и ограничения.

Разница по каждому критерию раскрыта ниже — в развернутом виде удобнее сверяться с конкретной ситуацией внедрения:

• Как каждый способ видит содержимое

   

  Агент читает данные локально на рабочей станции — до того, как браузер их зашифрует, или сразу после расшифровки на стороне клиента. Шлюз получает содержимое иначе — через подменный корневой сертификат, который позволяет ему расшифровать, проверить и заново зашифровать трафик на пути к серверу.

• Как каждый способ ведет себя с certificate pinning (закрепление или привязка сертификата)

   

  Агент обходит это ограничение поскольку не подменяет сертификат сервера. Шлюз, наоборот, ломается на pinning-приложениях — банк-клиентах и части мессенджеров, которые отклоняют любой сертификат, кроме зашитого в код.

• Что происходит с трафиком вне периметра

   

  Агент продолжает работать на удаленке, в командировке, с личного ноутбука через VPN — независимо от того, к какой сети подключена станция. Шлюз видит только тот трафик, который физически проходит через него, и слеп ко всему остальному.

• Что требуется для установки

   

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

Как видим, агент выигрывает, особенно там, где сотрудник работает вне офисной сети — в командировке либо на удаленке.

Что происходит после расшифровки: контентный анализ содержимого

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

• ключевые слова и словари — с учетом морфологии и транслитерации, чтобы не пропустить попытку обойти фильтр заменой букв;
• регулярные выражения — для структурированных данных: номеров карт, паспортов, счетов;
• цифровые отпечатки документов — детектируют утечку даже фрагмента защищаемого файла;
• OCR (от англ. Optical Character Recognition — оптическое распознавание символов) — извлекает текст со скриншотов и изображений, загружаемых через веб-формы.

В результате система понимает не просто «был трафик на облачный сервис», а что именно передавалось — какой файл, с каким содержимым, в какое поле формы. Ниже — как это выглядит для конкретных сценариев.

Блокировка или мониторинг HTTPS-трафика

После того как анализ определил нарушение, у системы есть два режима реакции. Блокировка передачи в моменте останавливает попытку отправки, если содержимое совпало с политикой безопасности, — подходит для действительно критичных данных, где утечку нужно предотвратить, а не зафиксировать.

Пассивный мониторинг с архивированием, наоборот, не прерывает работу сотрудника, но сохраняет копию для последующего анализа — такой режим лучше подходит для поведенческого контроля и накопления доказательной базы, когда важнее не спугнуть нарушителя, а собрать полную картину.

Важная оговорка по фактам. Блокировка передачи технически возможна не по всем протоколам и каналам одновременно — конкретный набор реакций для HTTPS-трафика зависит от точки инспекции и настроенных политик, обобщать здесь на «любой канал» некорректно.

Ограничения и подводные камни инспекции HTTPS

Честный разговор о технологии предполагает и трезвый взгляд на ее границы — но большинство из них решаемы, если знать о них заранее и правильно настроить систему. Certificate pinning — техника, при которой приложение (банк-клиент, часть мессенджеров) жестко проверяет, что сертификат сервера совпадает с зашитым в код, — действительно может усложнить шлюзовую инспекцию таких приложений. Агентная модель этой сложности в принципе не подвержена, поскольку не подменяет сертификат, а работает с содержимым локально; плата за это — установка на каждую станцию и ее обслуживание, что для зрелых DLP-решений давно отработанный, рутинный и часто даже удаленный процесс.

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

Работа SecureTower c HTTPS-трафиком

В SecureTower настройка перехвата сетевого трафика вынесена в отдельный раздел Консоли администратора, где администратор задает не только режим перехвата, но и точечно управляет тем, что именно система будет расшифровывать.

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

Отдельная гибкость — исключения: в них можно добавить конкретные процессы, если в компании используется необновленное или уникальное корпоративное ПО, с которым не стоит рисковать конфликтами, а также специальные рабочие приложения, которые клиент сознательно не хочет перехватывать. Похожим образом настраиваются исключения по IP-адресам — черные и белые списки: если конкретный IP-адрес (устройство) внесен в исключения, работающий под ним пользователь просто не попадает под контроль. Там же, в разделе «Сетевой трафик», задаются фильтрация по протоколам и максимальные объемы перехватываемых данных — то есть нагрузку можно гибко калибровать под конкретную инфраструктуру, а не выбирать между «перехватывать все» и «не перехватывать вовсе».

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

Законность инспекции HTTPS-трафика сотрудников

Расшифровка и анализ рабочего трафика — не техническая вольность, а действие, требующее правовой опоры, если речь о защите информации от несанкционированного доступа без превращения контроля в произвол. Инспекция HTTPS-трафика сотрудников на служебных устройствах правомерна при соблюдении связки из трех условий: контроль корпоративного трафика закреплен в локальном нормативном акте — политике информационной безопасности, оформленной как часть трудового договора; сотрудник ознакомлен с этим документом под подпись; обработка данных ведется с определенной целью, заявленной в соответствии с 152-ФЗ «О защите персональных данных».

Заключение

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

Часто задаваемые вопросы

• Как DLP видит содержимое, если трафик зашифрован HTTPS?

   

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

• Чем инспекция на агенте отличается от инспекции на шлюзе?

   

  Агент видит содержимое локально и работает с любым HTTPS-соединением независимо от местонахождения устройства — включая удаленку. Шлюз централизован и не требует установки ПО на станции, но покрывает только трафик, реально проходящий через него, и ломается на приложениях с certificate pinning.

• Нужно ли устанавливать сертификат на компьютеры сотрудников для контроля HTTPS?

   

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

• Можно ли заблокировать передачу конфиденциального файла в зашифрованном трафике?

   

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

• Как контроль HTTPS соотносится с политикой Zero Trust?

   

  Без инспекции трафика концепция нулевого доверия (Zero Trust) невыполнима, так как система не может проверить, какие именно данные перемещаются между доверенными и недоверенными сегментами сети в зашифрованном виде.

• Помогает ли расшифровка трафика выявить инсайдеров?

   

  Да. Если вы ищете ответ на вопрос, как распознать инсайдера, то контентный анализ HTTPS позволяет отследить тайную переписку сотрудника в веб-мессенджерах, выявляя инсайдеров и кротов до того, как произойдет утечка.

• Как ИИ улучшает анализ зашифрованного трафика?

   

  С помощью алгоритмов ИИ современная автоматизация ИБ позволяет не только расшифровывать трафик, но и моментально находить в нем аномалии поведения, минимизируя нагрузку на офицеров безопасности.

• Можно ли использовать DLP для контроля удаленщиков?

   

  Агентская модель инспекции — идеальный инструмент, если нужен надежный офисный контроль на «удаленке». Агент на ноутбуке сотрудника расшифрует и проверит трафик даже при работе из кафе или домашней сети.