Разрыв между даташитом и продом в ИБ: почему он встроен в отрасль

Каждый вендор сетевой безопасности публикует цифры производительности, которые красиво смотрятся в презентации. Демо проходит гладко. 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 – независимая лаборатория тестирования сетей и безопасности. Мы не интегратор и не реселлер и не продаем продукты, которые тестируем. Планируете закупку продукта безопасности и хотите методику с защитимым результатом, близким к проду – напишите нам.