SASE: почему вендорские облачные бенчмарки мимо вашего реального внедрения

Это четвёртая часть из шести о том, как оценивать продукты сетевой безопасности. Часть 1 — структурный разрыв в даташитах. Часть 2 — ловушки NGFW. Часть 3 — WAF, IPS, DLP.

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

Проблема общей инфраструктуры

Локальный NGFW — выделенное железо в вашей стойке. Диапазон его производительности детерминирован: один и тот же профиль трафика стабильно даёт один и тот же throughput и latency, потому что за ресурсы никто больше не конкурирует.

PoP в SASE — общая инфраструктура. Один PoP одновременно обслуживает десятки или сотни корпоративных клиентов. Ёмкость объединена в пул. Загрузка меняется по времени суток, дню недели и региональным паттернам трафика, которые к вашему внедрению отношения не имеют.

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

Это не гипотеза. Разброс производительности по времени и по расположению PoP — структурная черта общей облачной инфраструктуры. Оценка SASE требует измерять производительность из ваших реальных точек присутствия пользователей, до ваших реальных эндпоинтов приложений, в нескольких временных окнах, включая пиковые.

Рост latency под полным стеком

Архитектура SASE ставит несколько функций безопасности в путь трафика. Каждая добавляет latency. На схеме вендора это дискретные слагаемые. Как latency складывается под одновременной нагрузкой, на практике сложнее.

Функции, которые обычно стоят в inline-пути SASE: брокер ZTNA, SWG, CASB, URL-фильтрация, инспекция DLP, изоляция браузера, SSL inspection. Каждая обрабатывает трафик до пересылки. При низкой нагрузке latency каждой мала, сумма управляема. При высокой конкурентности — много пользователей, много одновременных сессий, пиковые периоды — эффекты очередей и взаимодействие компонентов дают нелинейный рост latency.

Вендоры обычно приводят latency по функциям, измеренную по отдельности. End-to-end latency со всеми функциями под реалистичной одновременной нагрузкой публикуют редко. Разница между этими числами — то, что заметят ваши пользователи.

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

TLS inspection в корпоративном масштабе

Платформы SASE, которые делают инспекцию SSL/TLS, терминируют и переустанавливают каждую TLS-сессию каждого пользователя на уровне PoP. Выигрыш для безопасности реальный: без инспекции шифрованный трафик проходит стек защиты без анализа содержимого.

Операционные и производственные последствия часто недоговаривают.

Управление сертификатами. Инспекция TLS требует, чтобы PoP предъявлял сертификат, которому доверяют конечные устройства. Управлять этим в распределённой компании — с BYOD, гостевыми устройствами и приложениями с certificate pinning — операционно сложно, и это видно на внедрении, а не на демо.

Точность инспекции на шифрованном трафике с высокой энтропией. Современный TLS 1.3 с шифрованным SNI и ESNI ограничивает метаданные, доступные до расшифровки. Точность классификации и корректность политик в этих условиях у разных вендоров разная и на оценках редко проверяется на реалистичном современном TLS.

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

География: бенчмарк снимали не в ваших условиях

Скажу прямо: ни один опубликованный бенчмарк SASE не снимали в условиях вашего конкретного внедрения.

Опубликованные бенчмарки делают на инфраструктуре вендора, между выбранными вендором эндпоинтами, в выбранное вендором время. Их оптимизируют под лучшее число. В вашем внедрении:

• пользователи в ваших реальных офисах и домашних офисах;
• приложения поделены между конкретными облачными регионами и конкретными локальными ЦОД;
• маршрутизация трафика через PoP, которые для вашей топологии могут быть географически не оптимальны;
• одновременная нагрузка от других арендаторов на том же PoP.

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

PoC для SASE, который идёт из одной тестовой точки, до демо-приложения на хостинге вендора, несколько часов в назначенном окне, полезных данных не даёт. Он даёт числа маркетингового качества, которые хорошо смотрятся в презентации отборочной комиссии.

Как выглядит осмысленная оценка SASE

Оценка SASE, которая даёт результаты уровня решения, требует другого подхода, чем тестирование железа.

Разместите агентов в характерных точках пользователей. Если ваши пользователи в Ереване, Лондоне, Сингапуре и Сан-Паулу — это и есть точки измерения. Трафик должен идти из этих мест через стек SASE к вашим реальным приложениям.

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

Тестируйте в нескольких временных окнах. Понедельник 9 утра, среда 14 часов и пятница 17 часов — это разная нагрузка на общих PoP. Меряйте по всему рабочему диапазону.

Включите полный целевой стек защиты. ZTNA, CASB, SWG, DLP, URL-фильтрация — то сочетание, которое собираетесь эксплуатировать. Бенчмарки по функциям не складываются и полную производительность стека не предсказывают.

Меряйте end-to-end latency, а не latency до узла. Пользователь ощущает полное время round-trip от своего устройства до приложения. Меряйте именно это, а не latency до края PoP.

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

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

TEST4NET LLC — независимая лаборатория тестирования сетей и безопасности. Мы проектируем и проводим оценки SASE с агентами в ваших реальных точках пользователей, до ваших реальных эндпоинтов приложений. Напишите нам.