Полный SASE-фреймворк для крупной компании — это не «купили облачную платформу и выключили VPN», а проект на 1–2 года с аудитом, пилотами и параллельной жизнью старой инфраструктуры. Dark Reading опубликовал разбор миграции к Secure Access Service Edge: для русскоязычных IT-команд это хороший чек-лист перед тем, как превращать сетевую безопасность в очередной дорогой клубок исключений.
Материал George V. Hulme вышел 24 сентября 2026 года, сообщает Dark Reading. Главная мысль проста и неприятна: edge computing, удалённая работа, SaaS и гибридные облака сломали старую модель, где доступ контролировался в основном через периметр, IP-адреса, VPN и набор железных коробок в офисах. SASE предлагает собрать сетевые и security-функции в единую облачную модель, но сама миграция требует не только новых лицензий, а пересборки governance: политик доступа, ролей, навыков команд и отношений с провайдерами.
Первый этап — инвентаризация. По оценке автора, именно здесь компании обычно находят «теневую» инфраструктуру: забытые appliances, дублирующие security-инструменты, точечные решения, которые никто не выключил после покупки платформы пошире. Аудит должен покрывать не только список устройств и сервисов, но и топологию сети, потоки трафика, зависимости между приложениями и требования комплаенса. Иначе SASE-фреймворк рискует повторить старый хаос, только уже в облачной панели управления.
John Grady, principal analyst в Omdia, советует начинать с вопроса, где компания хочет оказаться через два-три года. Это важная поправка для бизнесов, которые привыкли внедрять безопасность реактивно: пришёл аудит, случился инцидент, закончилась поддержка железа — срочно покупаем замену. В SASE такой подход быстро ломается, потому что платформа затрагивает удалённый доступ, филиалы, SaaS-контроль, политику идентичностей и эксплуатацию сетей. Без дорожной карты проект превращается в набор несвязанных миграций.
Второй шаг — пилот, причём не на всей компании сразу. Dark Reading рекомендует выбирать контролируемые сегменты: группы удалённых сотрудников, новые филиалы без тяжёлого наследия или некритичные SaaS-приложения. Пилот должен идти 3–6 месяцев, чтобы команда увидела сезонные пики нагрузки, странные интеграционные случаи и реальные показатели производительности. За это время нужно проверить, что политики пропускают нужный трафик, блокируют лишний и не превращают расследование инцидента в экскурсию по пяти консолям.
Grady предлагает начинать с самой больной зоны. Если больше всего страдает удалённый доступ — логично стартовать с ZTNA. Если проблема в филиалах — с SD-WAN. Если хаос в SaaS — с CASB. Для российских и региональных команд здесь есть практический вывод: не надо продавать SASE бизнесу как абстрактную «трансформацию безопасности». Лучше привязать первый этап к боли, которую уже чувствуют пользователи, служба поддержки и финансовый директор: медленный VPN, дорогие каналы, непрозрачный SaaS или ручное управление доступами.
Дальше начинается поэтапная миграция групп нагрузок. В статье описана логика, при которой сначала переводят удалённых сотрудников и мобильные устройства, затем филиалы и SD-WAN-связность, после этого — доступ к облачным приложениям и чувствительные on-premises-нагрузки. Каждый этап должен некоторое время сосуществовать со старой инфраструктурой: Dark Reading называет окно 1–3 месяца, чтобы у команды был быстрый откат при неожиданных проблемах. Это не самый эффектный пункт презентации, зато именно он часто отделяет рабочий проект от красивого провала.
Отдельный риск — механический перенос старых правил в новую систему. Если компания просто копирует firewall-правила, старые исключения и широкие доступы в SASE, она получает тот же периметр, только с новой аббревиатурой. Миграция должна включать чистку политик: удаление теневых правил, устранение слишком широких разрешений, консолидацию дублей и единые правила именования. Современный SASE-фреймворк опирается на least privilege: доступ определяется личностью пользователя, состоянием устройства и чувствительностью приложения, а не тем, из какого сегмента сети пришёл запрос.
Dave Shackleford, founder and CEO Voodoo Security, советует выстроить последовательность изменений так, чтобы сначала забрать быстрые выигрыши, но не потерять долгосрочную связку с zero trust. Для разработчиков и владельцев продуктов это означает больше разговоров о реальных зависимостях приложений: кто к чему ходит, какие сервисные аккаунты используются, где нужны исключения, а где они появились «на всякий случай» пять лет назад. Без этой информации security-команда будет писать политики вслепую, а продуктовые команды — ругаться на внезапно сломанные интеграции.
Ещё один блок — навыки. Администраторы, привыкшие к MPLS, правилам межсетевых экранов и локальным appliances, должны разобраться в cloud-native-архитектурах, API-автоматизации, интеграции идентичностей и принципах zero trust. Security-командам нужны навыки работы с cloud-delivered security, оркестрацией политик через распределённые точки присутствия и диагностикой enforcement-проблем без привычной локальной видимости. Если SASE покупается через MSSP или MSP, часть обучения может закрыть провайдер, но ответственность за архитектурные решения всё равно остаётся внутри компании.
После запуска проект не заканчивается. Dark Reading предлагает квартальные ревью политик: проверять, соответствуют ли они бизнес-требованиям, не появились ли непреднамеренные дыры после изменений и не требует ли новая threat intelligence корректировок. Параллельно нужно смотреть на latency, throughput и надёжность по конкретным приложениям, особенно когда растёт число пользователей и объём трафика. Для IT-директоров это неприятная, но честная формула: SASE — не финальный пункт миграции, а новая операционная модель безопасности.
Похоже, главный вопрос для рынка уже не в том, нужен ли компаниям SASE-фреймворк на фоне облаков, филиалов и удалёнки. Вопрос жёстче: хватит ли у организаций дисциплины не превратить его в очередной слой поверх старого беспорядка — с теми же лишними доступами, забытыми правилами и командами, которые узнают о политике безопасности только после падения продакшена.