«Инструмент SASE не просто выносит всю сетевую безопасность в облако. Он переформатирует архитектуру, превращая разрозненные правила и устройства в единую политику. Это позволяет контролировать трафик любого пользователя с любого устройства к любому ресурсу через одну точку. Но в условиях российских нормативных требований такой подход сталкивается с новыми вызовами: где физически хранить ключи шифрования, как реализовать инспекцию TLS 1.3, какие данные можно глобально синхронизировать.»
Что такое модель SASE на самом деле
Термин Secure Access Service Edge (SASE) впервые был озвучен аналитиками в 2019 году. Его часто описывают как облачную платформу, объединяющую сетевые и сервисы безопасности, такие как межсетевые экраны, VPN, CASB и фильтрацию URL. Однако суть SASE глубже формального набора функций.
SASE, это концепция архитектуры, которая переносит точку принятия решений о безопасности и маршрутизации как можно ближе к пользователю или устройству, но не на его устройство. Вместо этого все потоки данных сходятся в глобально распределённой облачной платформе. Здесь политики применяются централизованно, независимо от того, откуда подключился пользователь: из офиса, кафе или с мобильного оператора.
В традиционной модели корпоративная сеть была замкнутым периметром. SASE отказывается от этого периметра, заменяя его идентичностью пользователя или устройства. Контроль осуществляется не на уровне IP-адреса офиса, а на уровне сессии конкретного сотрудника, пытающегося получить доступ к приложению. Это делает политики мобильными и постоянными.
Почему «единственная точка контроля», это эволюция, а не революция
Идея консолидации управления не нова. За последние десятилетия инфраструктура безопасности обрастала точечными решениями: выделенные межсетевые экраны для филиалов, VPN-шлюзы для удалённого доступа, прокси-серверы для фильтрации веб-трафика. Каждое устройство требовало собственной настройки, обновления правил и мониторинга.
SASE не изобретает новые типы проверок. Вместо этого он интегрирует их в единый стек, работающий на программно-определяемой глобальной сети. Это даёт несколько практических преимуществ:
- Управление политиками из одной консоли. Правила для веб-фильтрации, предотвращения угроз и доступа к приложениям задаются в одном месте и автоматически применяются во всех точках присутствия сети провайдера.
- Единая инспекция трафика. Пакет не проходит цепочку из отдельных устройств, каждое из которых его распаковывает, проверяет и снова упаковывает. Все проверки выполняются в рамках одного прохождения через облачный сервис, что снижает задержки.
- Глобальная видимость. Администратор видит не отдельные сегменты сети, а целостную картину сессий всех пользователей, где бы они ни находились, с детализацией до уровня приложения.
«единственная точка», это не физический сервер, а единая логика управления, распределённая географически для оптимизации производительности.
Ключевые компоненты SASE-платформы
Архитектура SASE строится на нескольких фундаментальных технологических блоках.
SD-WAN как транспортная основа
Программно-определяемая глобальная сеть (SD-WAN) отвечает за интеллектуальную маршрутизацию трафика. Она динамически выбирает оптимальный путь к облачным сервисам или корпоративным ЦОДам на основе текущей загрузки каналов, стоимости и требований безопасности. SD-WAN в контексте SASE, это не самостоятельный продукт, а неотъемлемая часть платформы, обеспечивающая доставку трафика до точек проверки безопасности.
Security Service Edge (SSE)
Это облачный пакет сервисов безопасности, который является ядром SASE. В него входят:
- Cloud Access Security Broker (CASB): обеспечивает видимость и контроль за использованием облачных приложений (SaaS), даже если доступ к ним идёт в обход корпоративной сети.
- Secure Web Gateway (SWG): фильтрует интернет-трафик, блокируя доступ к вредоносным сайтам и enforcing политики приёма.
- Zero Trust Network Access (ZTNA): заменяет традиционный VPN. Предоставляет доступ не ко всей сети, а только к конкретным приложениям на основе постоянной проверки доверия к пользователю и устройству.
- Межсетевой экран как сервис (FWaaS): предлагает функции сетевого экранирования, инспекции угроз и предотвращения вторжений на уровне облачной платформы.
Все эти компоненты работают на общем движке правил и имеют доступ к единому контексту сессии.
Реализация в российском контексте: технические и регуляторные нюансы
Внедрение глобальной облачной модели безопасности в России требует учёта специфики нормативной базы, в первую очередь 152-ФЗ «О персональных данных» и требований ФСТЭК.
Геолокация данных и точек обработки
Большинство международных SASE-провайдеров оперируют глобальной сетью, где данные могут пересекать границы. Для соблюдения 152-ФЗ необходимо, чтобы обработка и хранение персональных данных граждан РФ происходили на территории России. Это означает, что российскому заказчику потребуется либо локальный SASE-провайдер, имеющий точки присутствия и центры обработки данных внутри страны, либо выделенный российский регион у международного вендора.
Вопрос с трафиком, не содержащим ПДн, но являющимся коммерческой тайной, также требует проработки с юридическим отделом, если он обрабатывается за рубежом.
Инспекция зашифрованного трафика (TLS)
Современный веб-трафик почти полностью зашифрован. Без его расшифровки и инспекции SWG и FWaaS становятся практически бесполезными. Однако для этого требуется внедрить в цепочку доверия корневой сертификат компании, что позволяет SASE-платформе выступать в роли «прослушивающего» прокси.
С появлением TLS 1.3 и технологии Encrypted ClientHello (ECH) эта задача усложнилась. ECH шифрует метаданные сессии, включая имя запрашиваемого сервера, что не позволяет шлюзу даже принять решение о необходимости декодирования. Для полноценной инспекции в условиях TLS 1.3 требуется установка специализированного агента на конечные устройства, который будет взаимодействовать с облачной платформой.
[КОД: Пример конфигурации политики в SASE-консоли, требующей установки агента ECH-decryption для доступа к корпоративным ресурсам]Криптография и требования ФСТЭК
Использование встроенных в SASE-платформу средств шифрования для построения туннелей (например, IPSec) может вступать в противоречие с требованием использовать сертифицированные средства криптографической защиты информации (СКЗИ). Если трафик содержит информацию, подпадающую под соответствующие приказы ФСТЭК, для его защиты, возможно, потребуется использовать отечественные СКЗИ в качестве отдельного слоя поверх SASE-туннеля или искать платформу, интегрированную с российскими криптопровайдерами.
Управление ключами шифрования
В модели SASE ключи шифрования для инспекции TLS или для туннелей между филиалами обычно управляются и хранятся провайдером платформы. С точки зрения безопасности и регуляторики критически важно понимать, где физически находятся эти ключи, кто имеет к ним доступ и как организовано их резервное копирование. Для многих организаций приемлемым может быть только вариант, когда мастер-ключи находятся под их собственным контролем в специальном аппаратном модуле безопасности (HSM) на территории РФ.
Практические шаги для оценки и внедрения
- Аудит текущих потоков трафика. Определите, какой трафик является критичным с точки зрения ПДн и коммерческой тайны. Картируйте, как сотрудники получают доступ к основным приложениям (офисным, SaaS, внутренним).
- Выбор между облачным и гибридным развёртыванием. Полноценный SASE предполагает направление всего интернет-трафика в облако. Однако для некоторых высокопроизводительных или чувствительных внутренних систем может быть оправдана гибридная модель, где часть трафика обрабатывается локально.
- Тестирование с пилотной группой. Начните внедрение с одного отдела или филиала. Проверьте не только функциональность безопасности, но и влияние на производительность приложений, особенно чувствительных к задержкам (VoIP, видеоконференции).
- Пересмотр политик безопасности. Воспользуйтесь возможностью перейти от правил, основанных на IP-адресах и портах, к политикам на основе идентификации пользователя, устройства и приложения. Например, правило может звучать как: «Сотрудники отдела финансов с корпоративных ноутбуков, прошедших проверку на наличие актуального антивируса, могут получать доступ к облачной бухгалтерии только в рабочие часы».
Ограничения и подводные камни модели
SASE не является панацеей и имеет свою область applicability.
- Зависимость от интернет-канала. Поскольку весь трафик проходит через облако провайдера, стабильность и низкая задержка интернет-соединения становятся критически важными. В регионах с некачественным интернетом это может создать проблемы.
- Сложность миграции. Переход от десятков разрозненных устройств к единой платформе, это длительный процесс, требующий тщательного планирования и изменения многих операционных процедур.
- «Вендор-лок». Выбрав одного провайдера SASE, компания глубоко интегрирует свою сетевую и security-инфраструктуру с его экосистемой. Смена провайдера в будущем будет сопоставима по сложности с полной перестройкой архитектуры.
- Не всё можно вынести в облако. Оборудование для специализированных промышленных протоколов (OT), системы реального времени или инфраструктура с экстремально низкими требованиями к задержкам могут оставаться в изолированных сегментах.
Модель SASE предлагает принципиально новый подход к сетевой безопасности, делая её гибкой, адаптивной и тесно связанной с облачными сервисами. В российских реалиях её внедрение, это не просто технический проект, а комплексная задача, требующая баланса между технологическими преимуществами, производительностью и строгими регуляторными требованиями. Успех зависит от глубокого анализа потоков данных, выбора правильной архитектуры развёртывания и тщательной работы с политиками доступа, основанными на принципах нулевого доверия.