Архитектура SASE не сломалась — она просто изначально не проектировалась под ту реальность, где данные утекают не через сеть, а через вкладку браузера. Несколько лет назад маршрутизация трафика через облачные прокси действительно закрывала большинство рисков: политики применялись на уровне сети, и этого хватало. Потом работа переехала в браузер, в компании пришли ИИ-инструменты, и модели инспекции трафика перестали успевать за тем, как на самом деле движутся данные.
Сегодня рабочие процессы разбросаны между SaaS-приложениями, браузерными вкладками, генеративными нейросетями, неодобренными расширениями для браузера и автономными агентами, которые действуют без участия человека. Сотрудник вставляет фрагмент проприетарного кода в публичную LLM, чтобы та помогла его оптимизировать — обычное дело, никто не считает это утечкой. Автономный агент тем временем опрашивает внутреннюю документацию и перемещает данные между системами со скоростью, недоступной человеку. Формально ни то, ни другое не нарушает никаких правил, потому что правил для этого попросту нет.
Проблема традиционного SASE в том, как устроен сам механизм проверки. Модель строится на бэкхолинге — трафик заворачивается в облачный прокси, там расшифровывается, проверяется и уже потом отпускается по назначению. Но именно это и стало невозможным после появления TLS 1.3, HTTP/3 и certificate pinning. Эти протоколы разрабатывались специально для того, чтобы исключить перехват «человек посередине» — а прокси-инспекция по сути и есть такой перехват, только санкционированный работодателем.
Отсюда вполне предсказуемые последствия. Когда облачный прокси пытается принудительно расшифровать сессию с TLS 1.3 и закреплённым сертификатом, клиентское приложение просто рвёт соединение. Чтобы бизнес не встал, сетевые команды вынуждены заводить списки исключений — то есть выводить конкретные приложения из-под контроля прокси. Со временем такие списки разрастаются, и периметр безопасности сжимается буквально по одному приложению за раз, пока от него не остаётся почти ничего.
Есть и вторая сторона медали — задержка, своего рода «налог за объезд». Если инспекция трафика происходит на далёком облачном узле, приложения тормозят, видеозвонки начинают заикаться, и пользователи находят обходные пути через теневой ИТ. Получается замкнутый круг: команда безопасности пытается всё контролировать, а в итоге сама подталкивает сотрудников расширять поверхность атаки, которую должна была сокращать.
С искусственным интеллектом ситуация обостряется до предела. Сетевой прокси видит валидное зашифрованное HTTPS-соединение с провайдером LLM — и всё, дальше он слеп. Что именно передаётся внутри этого соединения, какое содержимое запроса, какой контекст — недоступно. Возьмём конкретный случай: автономный ИИ-агент делает вызов через Model Context Protocol, чтобы вытянуть кусок проприетарного кода или внутреннюю документацию. Для сетевой инспекции это просто ещё один зашифрованный пакет, ничем не примечательный.
Здесь вводится понятие «момента намерения» — того самого мгновения, когда происходит фактическое взаимодействие с данными. К моменту, когда трафик доходит до точки сетевой инспекции, этот момент уже прошёл, решение уже принято, данные уже переданы. Инспектировать нечего, поезд ушёл. Именно поэтому у служб безопасности остаётся выбор всего из двух плохих вариантов: либо запретить ИИ целиком — и получить лавину теневых инструментов, либо разрешить всё без ограничений — и смириться с полной непрозрачностью того, что происходит с данными компании.
Выход из этой ловушки — перенести точку принятия решения туда, где на самом деле происходит взаимодействие: на устройство, в браузер, а не куда-то в сеть. Если сетевая маршрутизация всё же нужна, трафик логичнее направлять динамически на ближайшую доступную edge-инфраструктуру, срезая лишние промежуточные узлы, которые и создают ту самую задержку.
На практике это означает три вещи на «последней миле». Во-первых, копирование, вставка и содержимое промптов проверяются локально, прямо на устройстве, до того как данные вообще покинут его пределы. Во-вторых, современные протоколы шифрования работают так, как задуманы их разработчиками — без насильственной расшифровки посередине пути. В-третьих, до 90% доверенного трафика может идти напрямую к месту назначения, минуя прокси и его «налог за объезд», что возвращает приложениям их естественную скорость работы.
Такой подход лёг в основу архитектуры, которую называют «Perfect Packet» — идеальный пакет. Контекст оценивается прямо на конечном устройстве, а облачная инспекция подключается только тогда, когда конкретная сессия действительно требует дополнительной проверки. Подробнее об этой смене парадигмы и о том, как оценивать риски ИИ в корпоративной среде, можно прочитать в материале «The Guide to Modern SASE Architecture».
Итоговый тезис, вокруг которого строится вся эта дискуссия, звучит так: сетевая инспекция не способна регулировать то, что происходит внутри вкладки приложения или внутри рабочего процесса ИИ. Полное руководство «The Perfect Packet: A Guide to Modern SASE Architecture» разбирает, как закрыть этот слепой участок прокси-архитектуры, не жертвуя при этом скоростью работы приложений.
Сегодня рабочие процессы разбросаны между SaaS-приложениями, браузерными вкладками, генеративными нейросетями, неодобренными расширениями для браузера и автономными агентами, которые действуют без участия человека. Сотрудник вставляет фрагмент проприетарного кода в публичную LLM, чтобы та помогла его оптимизировать — обычное дело, никто не считает это утечкой. Автономный агент тем временем опрашивает внутреннюю документацию и перемещает данные между системами со скоростью, недоступной человеку. Формально ни то, ни другое не нарушает никаких правил, потому что правил для этого попросту нет.
Проблема традиционного SASE в том, как устроен сам механизм проверки. Модель строится на бэкхолинге — трафик заворачивается в облачный прокси, там расшифровывается, проверяется и уже потом отпускается по назначению. Но именно это и стало невозможным после появления TLS 1.3, HTTP/3 и certificate pinning. Эти протоколы разрабатывались специально для того, чтобы исключить перехват «человек посередине» — а прокси-инспекция по сути и есть такой перехват, только санкционированный работодателем.
Отсюда вполне предсказуемые последствия. Когда облачный прокси пытается принудительно расшифровать сессию с TLS 1.3 и закреплённым сертификатом, клиентское приложение просто рвёт соединение. Чтобы бизнес не встал, сетевые команды вынуждены заводить списки исключений — то есть выводить конкретные приложения из-под контроля прокси. Со временем такие списки разрастаются, и периметр безопасности сжимается буквально по одному приложению за раз, пока от него не остаётся почти ничего.
Есть и вторая сторона медали — задержка, своего рода «налог за объезд». Если инспекция трафика происходит на далёком облачном узле, приложения тормозят, видеозвонки начинают заикаться, и пользователи находят обходные пути через теневой ИТ. Получается замкнутый круг: команда безопасности пытается всё контролировать, а в итоге сама подталкивает сотрудников расширять поверхность атаки, которую должна была сокращать.
С искусственным интеллектом ситуация обостряется до предела. Сетевой прокси видит валидное зашифрованное HTTPS-соединение с провайдером LLM — и всё, дальше он слеп. Что именно передаётся внутри этого соединения, какое содержимое запроса, какой контекст — недоступно. Возьмём конкретный случай: автономный ИИ-агент делает вызов через Model Context Protocol, чтобы вытянуть кусок проприетарного кода или внутреннюю документацию. Для сетевой инспекции это просто ещё один зашифрованный пакет, ничем не примечательный.
Здесь вводится понятие «момента намерения» — того самого мгновения, когда происходит фактическое взаимодействие с данными. К моменту, когда трафик доходит до точки сетевой инспекции, этот момент уже прошёл, решение уже принято, данные уже переданы. Инспектировать нечего, поезд ушёл. Именно поэтому у служб безопасности остаётся выбор всего из двух плохих вариантов: либо запретить ИИ целиком — и получить лавину теневых инструментов, либо разрешить всё без ограничений — и смириться с полной непрозрачностью того, что происходит с данными компании.
Выход из этой ловушки — перенести точку принятия решения туда, где на самом деле происходит взаимодействие: на устройство, в браузер, а не куда-то в сеть. Если сетевая маршрутизация всё же нужна, трафик логичнее направлять динамически на ближайшую доступную edge-инфраструктуру, срезая лишние промежуточные узлы, которые и создают ту самую задержку.
На практике это означает три вещи на «последней миле». Во-первых, копирование, вставка и содержимое промптов проверяются локально, прямо на устройстве, до того как данные вообще покинут его пределы. Во-вторых, современные протоколы шифрования работают так, как задуманы их разработчиками — без насильственной расшифровки посередине пути. В-третьих, до 90% доверенного трафика может идти напрямую к месту назначения, минуя прокси и его «налог за объезд», что возвращает приложениям их естественную скорость работы.
Такой подход лёг в основу архитектуры, которую называют «Perfect Packet» — идеальный пакет. Контекст оценивается прямо на конечном устройстве, а облачная инспекция подключается только тогда, когда конкретная сессия действительно требует дополнительной проверки. Подробнее об этой смене парадигмы и о том, как оценивать риски ИИ в корпоративной среде, можно прочитать в материале «The Guide to Modern SASE Architecture».
Итоговый тезис, вокруг которого строится вся эта дискуссия, звучит так: сетевая инспекция не способна регулировать то, что происходит внутри вкладки приложения или внутри рабочего процесса ИИ. Полное руководство «The Perfect Packet: A Guide to Modern SASE Architecture» разбирает, как закрыть этот слепой участок прокси-архитектуры, не жертвуя при этом скоростью работы приложений.