Средняя
- Теги: Check Point, SASE, Чекпоинт
В сентябре-октябре Check Point заметно расширил свою SASE-платформу. Компания консолидировала Public API, добавила управление политиками Internet Access, SWG, HTTPS Inspection, Private DNS и Split Tunneling, расширила интеграцию SASE с аппаратными Spark Firewall, а в начале октября добавила DLP для SaaS и генеративных AI-приложений.
Сами по себе эти функции не выглядят революционно. Firewall API, VPN, DLP или фильтрация веб-трафика существуют много лет. Интереснее другое: они постепенно собираются вокруг одной модели, в которой пользователь, его устройство, приложение, сеть и политика безопасности становятся частями единой цепочки.
Именно в этом заключается основная идея SASE.
Это две разные технологии, но вместе они формируют довольно интересную модель работы с уязвимостями:
Обнаружить уязвимость → быстро поставить компенсирующую защиту → спокойно подготовить обновление → установить исправленную версию с минимальным перерывом.
Содержание
Почему появилась SASE?
Классическая корпоративная сеть строилась вокруг периметра.
Пользователь находился в офисе, приложение — в корпоративном ЦОДе, а между корпоративной сетью и Интернетом стоял межсетевой экран. Чтобы предоставить доступ, достаточно было определить исходную и целевую сеть, порт и протокол.
Условно:
10.20.0.0/16 → 10.50.20.15 → TCP/443 → Allow
Такая модель хорошо работала, пока большая часть пользователей, серверов и приложений действительно находилась внутри нескольких контролируемых площадок.
Сегодня ситуация другая. Сотрудник может работать из дома или другого офиса, использовать SaaS, обращаться к сервису в публичном облаке, а затем — к приложению в собственном ЦОДе. Само приложение может одновременно состоять из нескольких backend-сервисов и работать в гибридной инфраструктуре.
В результате сетевое расположение пользователя постепенно перестало быть хорошим признаком доверия.
SASE — Secure Access Service Edge — пытается перенести точку принятия решения с классического сетевого периметра ближе к пользователю и приложению.
Вместо вопроса:
Какой IP имеет право обратиться к другому IP?
появляется другой:
Какой пользователь, с какого устройства и при каких условиях имеет право обратиться к конкретному приложению?
Как работает SASE: путь пользователя до информационной системы
Рассмотрим простой пример.
Сотруднику финансового подразделения необходимо получить доступ к SAP Production.
В традиционной архитектуре это часто превращается в цепочку переводов. Владелец системы говорит, что доступ нужен сотрудникам Finance. Сетевой администратор выясняет, из каких подсетей они работают. Затем определяет адреса SAP, необходимые порты, путь через сеть и набор межсетевых экранов.
В SASE цепочка выглядит иначе.
1. Identity
В качестве исходной сущности используется не IP-адрес, а identity пользователя.
SASE интегрируется с корпоративным Identity Provider — например, Microsoft Entra ID, Active Directory или Okta.
В каталоге уже существует группа:
FIN-SAP-USERS
а в ней находятся конкретные сотрудники.
Check Point, например, использует SCIM для синхронизации пользователей, групп и их membership с SASE. Таким образом, изменение состава группы на стороне Identity Provider автоматически влияет на доступ.
Политика больше не обязана знать, где физически находится сотрудник. Он может работать из офиса, дома или через мобильную сеть — его identity остаётся прежним.
2. Device Posture
Одного имени пользователя недостаточно.
SASE дополнительно оценивает устройство, с которого устанавливается соединение. Это может быть корпоративный сертификат, версия операционной системы, состояние антивируса или EDR, шифрование диска и другие параметры. В результате субъект доступа выглядит уже не просто как:
Ivanov
а примерно как:
Ivanov + Finance + Corporate Device + Compliant
3. Application
Следующий важный шаг — появление отдельной сущности приложения.
Вместо:
10.50.20.15:443
администратор может работать с объектом:
SAP Production
За этим объектом уже скрываются технические параметры: DNS-имя, IP-адрес backend, порт, протокол и сеть, в которой находится приложение.
Это важное изменение.
Системные команды обычно оперируют названиями информационных систем, а сетевые — адресами и портами. SASE создаёт место, где эти два представления связываются.
4. SASE Agent
На пользовательском устройстве обычно работает SASE-клиент.
Он определяет, какой трафик необходимо направить через SASE, выполняет аутентификацию пользователя и участвует в проверке состояния устройства.
В сентябре Check Point, например, добавил для Windows прозрачный SSO с Microsoft Entra ID: на управляемом корпоративном устройстве агент может использовать уже имеющийся OS identity token без дополнительного запроса логина и пароля.
5. SASE PoP
Вместо того чтобы сначала вести пользователя по VPN в корпоративный ЦОД, его соединение приходит в ближайшую точку присутствия SASE-провайдера.
Здесь и происходит значительная часть проверки и enforcement.
То есть безопасность больше не обязана находиться исключительно на физическом firewall внутри корпоративной сети.
6. ZTNA
На этом этапе принимается основное решение о доступе. Условная политика может выглядеть так:
Finance + compliant device → SAP Production → Allow
Пользователю необязательно выдавать сетевой доступ ко всей подсети, где находится SAP.
Он получает доступ к конкретному приложению.
В этом заключается одно из главных отличий Zero Trust Network Access от классического remote-access VPN: VPN прежде всего подключает пользователя к сети, ZTNA — к ресурсу.
7. FWaaS и дополнительные проверки
После проверки ZTNA соединение может проходить через дополнительные функции безопасности:
URL Filtering, IPS, Threat Prevention, Application Control, HTTPS Inspection, DLP и другие механизмы.
По сути это знакомые возможности NGFW и Secure Web Gateway, но они применяются как облачный сервис.
Именно поэтому Security Service Edge, или SSE, обычно включает ZTNA, SWG, CASB и другие security-сервисы, а SASE добавляет к ним ещё и сетевую составляющую.
8. SD-WAN и маршрутизация
После того как доступ разрешён, необходимо доставить трафик до приложения.
Здесь вступает в работу транспортный слой SASE: SD-WAN, собственная backbone-сеть провайдера, BGP, IPSec-туннели и маршрутизация.
Это уже другой вопрос: не «Имеет ли пользователь право войти?», а «Каким путём доставить его трафик?».
9. Connector или VPN в корпоративный ЦОД
Если приложение находится внутри корпоративного дата-центра, между SASE и площадкой создаётся защищённое соединение.
Это может быть Connector, IPSec или другой туннель.
Check Point в 2026 году активно развивает именно эту часть гибридной архитектуры. В сентябре в документации появились новые сценарии route-based и policy-based VPN между SASE и централизованно управляемыми Spark Firewall, в том числе находящимися за NAT.
Таким образом облачная SASE-среда постепенно соединяется с обычной корпоративной сетевой инфраструктурой.
10. Внутренний firewall и информационная система
Даже при использовании SASE обычные NGFW никуда не исчезают.
Трафик внутри ЦОДа может дополнительно проходить через межсетевой экран и внутреннюю сегментацию.
В конечном итоге цепочка выглядит примерно так:
User → SASE Agent → Identity → Device Posture → SASE PoP → ZTNA → FWaaS → SD-WAN/VPN → NGFW → Information System
SASE не отменяет сетевую инфраструктуру. Он добавляет над ней новый уровень политики.
Что именно строит Check Point?
У Check Point особенно хорошо видно, как классический производитель firewall постепенно пытается объединить облачную и традиционную модели безопасности.
В основе SASE-бизнеса компании лежит Perimeter 81, приобретённый Check Point в 2023 году. Но сейчас платформа уже всё теснее интегрируется с остальной экосистемой. В SASE появляются Private Access, Internet Access, SWG, Threat Prevention, DLP, Browser Security, управление SaaS и AI-приложениями. Параллельно развивается связность с Quantum и Spark Firewall. А SASE Public API в версии 3 уже охватывает не только базовую конфигурацию, но и Internet Access policies, SWG, HTTPS Inspection, Private DNS, Split Tunneling, Application Control и другие объекты. По сути формируется единый programmable security layer.
Политика постепенно перестаёт быть привязанной к конкретному физическому firewall. Она может применяться на пользовательском endpoint, в SASE PoP, на облачном gateway или на обычном межсетевом экране в корпоративной сети. Это и есть, пожалуй, более важное изменение, чем само перемещение firewall в облако.
Где проходит граница SASE?
При этом важно не переоценивать технологию.
SASE особенно хорошо решает задачу:
User → Application
Но гораздо меньше меняет классический мир:
Server → Server
Если SAP Application Server обращается к Oracle DB, там по‑прежнему часто используются IP-адреса, VLAN, firewall rules, Kubernetes Network Policies, security groups и традиционная маршрутизация.
То есть SASE пока в первую очередь меняет пользовательский и филиальный доступ.
Внутри ЦОДов и облаков продолжают существовать другие модели сегментации и workload-to-workload connectivity.
Что происходит с SASE в России?
В России идея SASE уже используется, но рынок заметно отличается от глобального.
По состоянию на 2026 год единой отечественной платформы SASE, полностью аналогичной Check Point, Cato, Zscaler или Palo Alto, фактически пока нет. Российские архитектуры чаще собираются из нескольких решений. Это отмечают и российские отраслевые обзоры: SASE-сети уже работают в банках, логистике, ритейле и других организациях, но чаще строятся как интеграция отдельных компонентов.
Это не означает, что необходимые технологии отсутствуют. Наоборот, большинство ключевых элементов уже появляется.
Kaspersky: движение от SD-WAN к SASE
«Лаборатория Касперского» развивает один из наиболее очевидных технологических наборов для подобной архитектуры.
Kaspersky SD-WAN уже существует как зрелый самостоятельный продукт. В версии 3.0 появились дополнительные функции безопасности, BGP Community, QoS и расширенный мониторинг; централизованное управление филиальной сетью выполняется через оркестратор.
Кроме того, в портфеле компании уже присутствуют Kaspersky NGFW и отдельный Kaspersky ZTNA для доступа сотрудников к корпоративным приложениям.
Сама компания прямо говорит, что SD-WAN и NGFW формируют основу комплексной сетевой безопасности в направлении SASE.
То есть технологические кирпичи уже есть:
ZTNA + SD-WAN + NGFW
Но степень их объединения в единую объектную модель и единую policy plane пока отличается от облачных SASE-платформ глобальных вендоров.
UserGate: движение от NGFW к identity-based access
UserGate идёт несколько иным путём — от сетевой безопасности.
NGFW остаётся центральным элементом экосистемы, однако поверх него развиваются ZTNA-сценарии, пользовательская идентификация, remote access, reverse proxy, VPN и endpoint-клиент.
UserGate прямо позиционирует свою платформу SUMMA как инструмент управления безопасностью гибридной инфраструктуры, а удалённый доступ — как ZTNA-сценарий.
В 2026 году компания также публично продвигает переход от классической защиты сетевого периметра к безопасности, основанной на пользовательских ролях и доверии.
Это очень близко к базовой идее SASE: IP-адрес постепенно перестаёт быть единственной сущностью политики.
Почему российская модель отличается?
Причины различий не только технологические.
Классический SASE предполагает достаточно радикальную архитектуру: значительная часть корпоративного трафика проходит через облачную инфраструктуру внешнего провайдера.
Для российского крупного бизнеса, банков, государственного сектора и КИИ это далеко не всегда приемлемая модель.
Возникают вопросы:
- где физически обрабатывается трафик;
- где хранятся логи;
- можно ли использовать зарубежный облачный сервис;
- какие средства защиты должны иметь сертификаты;
- какие функции должны оставаться on-premises.
Поэтому российская реализация SASE с высокой вероятностью будет более гибридной.
Не обязательно:
User → Global Cloud SASE → Application
А скорее:
User → ZTNA → российский сервис или корпоративный PoP → NGFW → SD-WAN → Application
То есть большая часть архитектурных принципов SASE сохраняется, но enforcement может оставаться внутри инфраструктуры заказчика или российского оператора.
Показателен и практический опыт импортозамещения Zscaler: российские интеграторы уже описывают архитектуры, где значительную часть SASE-функций удаётся воспроизвести на базе Kaspersky SD-WAN и других отечественных компонентов, но это пока именно архитектурная сборка, а не замена одной SaaS-платформы другой.
SASE — это не ещё один VPN
Наверное, главный источник путаницы вокруг SASE — попытка воспринимать его как новый способ удалённого подключения.
VPN отвечает прежде всего на вопрос:
Как безопасно подключить пользователя к сети?
SASE ставит вопрос шире:
К какому приложению этот пользователь имеет право обратиться, с какого устройства, при каком состоянии этого устройства, через какую точку enforcement и каким маршрутом?
Именно поэтому в одной архитектуре сходятся технологии, которые раньше жили довольно независимо: Identity, ZTNA, endpoint posture, SWG, CASB, DLP, FWaaS, SD-WAN, DNS security, VPN и NGFW.
По отдельности большинство из них существует давно.
Новизна SASE — в попытке сделать их частью одной модели доступа.
И свежие изменения Check Point хорошо показывают направление развития: SASE постепенно превращается из облачного VPN и SWG в полноценный программируемый слой корпоративной связности и безопасности.
В России движение происходит в ту же сторону, но, вероятно, с другой архитектурой. Вместо глобальной облачной платформы одного вендора рынок пока формирует гибридные конструкции из отечественных NGFW, SD-WAN, ZTNA и endpoint-решений.
Поэтому ключевой вопрос ближайших лет будет уже не в том, появится ли SASE в России.
Фактически он уже появляется.
Гораздо интереснее другое: сможет ли российский рынок объединить эти компоненты в единую систему identity, приложений, маршрутизации и политик — или SASE здесь останется архитектурой, которую каждый крупный заказчик будет собирать самостоятельно.
Адрес:
121205, г. Москва, муниципальный округ Можайский, территория инновационного центра «Сколково», б-р Большой, д. 42, стр. 1, этаж 2, помещение № 162/№ 4
Телефон:
+7 (495) 255-35-82
Почта:
info@netopia.pro
Деятельность осуществляется компанией ООО «Нетопия» при грантовой поддержке Фонда «Сколково»
© Netopia.pro
