Ложь в даташите вендора безопасности: почему это встроено в отрасль

Каждый вендор сетевой безопасности публикует цифры производительности, которые красиво смотрятся в презентации. Демо проходит гладко. PoC даёт отличный результат. Потом железо приезжает в прод, и через пару недель служба эксплуатации заводит тикеты: скачки latency, просадка throughput, политики безопасности, которые под нагрузкой тихо перестают срабатывать.

Это не случайность и не проблема одного вендора. Так устроен весь рынок: как он продаёт продукты и как их тестирует. Понять эту механику — первый шаг к закупке, о которой вы потом не пожалеете.

Почему цифра в даташите формально верна и на практике вводит в заблуждение

Вендоры не выдумывают числа. Устройство действительно выдало этот throughput. В тот конкретный момент, при тех конкретных условиях. Условия для лучшей защищаемой цифры выбирает вендор, и с реальной корпоративной сетью они совпадают редко.

У каждой платформы безопасности есть диапазон производительности. Один край: простая пересылка пакетов, без инспекции, открытый трафик, крупные долгие сессии. Другой край: весь стек включён — TLS inspection, DPI, IPS, AV, контроль приложений, URL-фильтрация — на реалистичном смешанном корпоративном профиле с короткими сессиями, шифрованным трафиком и всплесками новых соединений.

Даташит выносит вперёд первое число. Второе прячет в сноску, если вообще приводит.

Разрыв между краями диапазона — 55–75% у каждого крупного вендора в сегменте NGFW. Похожие цифры у WAF, IPS и inline-DLP. Это не дефект устройства. Это цена обработки трафика средствами безопасности. Проблема одна: о разрыве честно не говорят.

Как разрыв на включённых функциях выглядит на практике

NGFW. Флагманская железка крупно указывает свой throughput. Включите корпоративный стек защиты — IPS, AV, контроль приложений, URL-фильтрацию, SSL inspection — и в проде получите долю от этой цифры. Просадка не дефект железа. Столько стоит deep packet inspection на line rate. Цифру из даташита с этими функциями просто не мерили.

WAF. Вендор публикует requests per second и throughput. Эти числа обычно снимали на однородном синтетическом профиле запросов, с вынесенным или отключённым TLS и минимальным набором правил. Добавьте полный CRS на боевом уровне паранойи, включите TLS inspection, дайте реалистичное разнообразие трафика приложений — числа выглядят иначе.

DLP. Глубокая инспекция контента — чтение и анализ тела каждого файла, каждого вложения, каждой загрузки — стоит дорого. Числа throughput у DLP почти всегда мерят на простых лёгких типах файлов. Полный проход по реалистичному корпусу корпоративных документов, где крупные файлы Office, PDF и архивы, даёт throughput на уровне 20–30% от даташита.

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

Переменная в конфигурации, о которой молчат

Кроме набора функций есть вторая переменная, которую вендоры стабильно недоговаривают: сложность политик и правил.

Файрвол на 50 правил и файрвол на 5000 правил — с точки зрения производительности это разные устройства. Поиск по политике, сопоставление правил, объём логирования растут со сложностью конфигурации. Вендоры тестируют на минимальных или дефолтных настройках. Прод копит правила годами.

WAF с дефолтным CRS и WAF с дефолтным CRS плюс кастомный virtual patching плюс исключения под конкретные приложения работают в разных точках по производительности. Движок DLP с 10 активными политиками и движок с 200 тонко настроенными политиками под разные классы данных ведут себя под нагрузкой по-разному.

Тест в конфигурации, которая не похожа на ваш прод, даёт числа, которые ваш прод не предсказывают. Звучит очевидно. В вендорских оценках это игнорируют почти всегда.

О чём эта серия

Это первый пост из шести о том, как оценивать продукты сетевой безопасности по методике, которая предсказывает поведение в проде.

Дальше:

• Пост 2: ловушки тестирования NGFW — fast path, вендорские тестовые режимы и почему AppMix, который показывает ваш инструмент, не тот AppMix, что прошёл через устройство.
• Пост 3: WAF, IPS и DLP — сложность инспекции контента, тестирование обхода и проблема ложных срабатываний.
• Пост 4: SASE — почему облачную безопасность особенно трудно измерять и как выглядит осмысленная оценка.
• Пост 5: как построить тест, результатам которого можно доверять — методика, инструменты и роль независимой лаборатории.
• Пост 6: одного теста мало — почему платформы безопасности требуют постоянной проверки на всём жизненном цикле и как выстроить этот процесс.

Цель не в том, чтобы обвинить конкретного вендора. Цель — дать командам закупок, архитекторам безопасности и сетевым инженерам рамку, чтобы задавать правильные вопросы до подписания многолетнего контракта.

TEST4NET LLC — независимая лаборатория тестирования сетей и безопасности. У нас нет коммерческих отношений ни с одним вендором, чьи продукты мы проверяем. Планируете закупку продукта безопасности и хотите методику с защитимым результатом, близким к проду — напишите нам.