«NFV обещает удобство и гибкость виртуальных сетей, но за это приходится платить новой уязвимостью: старые границы аппаратуры исчезают, а изоляцию теперь нужно выстраивать программно, в обстановке общего гипервизора и общей инфраструктуры, где одна ошибка в правилах или утечка памяти может открыть доступ ко всем сетевым сервисам разом».
Внутри виртуального коммутатора: почему старая модель защиты не работает
В традиционных сетях безопасность строилась на физическом разделении. Межсетевой экран, балансировщик, система обнаружения вторжений, это были отдельные железные коробки. Даже если злоумышленник получал контроль над одним устройством, остальные элементы сети оставались за его бортом, защищённые собственным железом и софтом.
NFV меняет правила игры. Все эти функции превращаются в виртуальные машины или контейнеры, которые крутятся на одном пуле стандартных серверов под управлением единого гипервизора. Пропал физический барьер — появилась общая среда исполнения. Виртуальный коммутатор, который пересылает трафик между виртуальными сетевыми функциями (VNF), становится критической точкой. Уязвимость в его коде или ошибка в настройке правил изоляции позволяют трафику из одной VNF прорваться в другую, минуя все логические проверки.
Эта проблема глубже, чем кажется. Многие решения для NFV используют для ускорения обработки трафика технологию SR-IOV, которая позволяет виртуальной машине напрямую работать с сетевым адаптером. Это повышает производительность, но обходит встроенные механизмы изоляции гипервизора, передавая управление сетевым потоком напрямую гостевой системе. Если такая VNF скомпрометирована, злоумышленник получает низкоуровневый доступ к сетевому оборудованию хоста.
Слои уязвимости: от гипервизора до оркестратора
Атака на NFV-инфраструктуру редко бывает точечной. Её цель — эскалация привилегий и движение по горизонтали через общие ресурсы. Угрозы можно разделить на несколько уровней.
Уровень гипервизора и хоста
Компрометация гипервизора, это катастрофа. Злоумышленник получает контроль над всеми VNF, запущенными на физическом сервере. Источниками угроз здесь становятся не только прямые уязвимости в самом гипервизоре, но и компоненты управления им, драйверы устройств или даже устаревшие версии микрокода процессора, позволяющие осуществлять атаки через побочные каналы.
Отдельная история — общие хранилища. Дисковые массивы, которые используются для хранения образов VNF и их данных, становятся единой точкой отказа. Неправильная разграничение прав доступа к хранилищу может позволить VNF, отвечающей, например, за трансляцию адресов, получить доступ и модифицировать образ виртуального межсетевого экрана.
Уровень оркестрации и управления
Системы оркестрации NFV, такие как OpenStack Tacker или специализированные решения вендоров, управляют полным жизненным циклом VNF: развёртывают, масштабируют, обновляют. Их API — лакомая цель.
Взлом учётной записи оператора или нахождение уязвимости в API оркестратора даёт возможность дистанционно развернуть вредоносную VNF, изменить конфигурацию сетевых политик для обхода защиты или просто остановить критичные сетевые сервисы.
Здесь же кроется угроза цепочки поставок. VNF часто поставляются в виде готовых образов от независимых вендоров. Если в такой образ на этапе сборки будет внедрён бэкдор, он окажется внутри периметра сети с доверенным статусом. Проверить каждый образ вручную практически невозможно.
Уровень меж-VNF взаимодействия
Даже если гипервизор и оркестратор в безопасности, остаётся плоскость данных — трафик между самими сетевыми функциями. Атаки здесь носят более тонкий характер:
- Атаки на переполнение буфера в самих VNF, ведущие к выполнению произвольного кода.
- Атаки типа «злоумышленник в середине» между VNF, если управляющие каналы не шифруются.
- Использование легитимных механизмов служебного взаимодействия VNF (например, для синхронизации состояния) для скрытного перемещения.
Изоляция как основа безопасности: не только сети
Ответ на новые угрозы — многоуровневая изоляция. Сетевые ACL, это необходимый минимум, но недостаточный. Нужно разделять всё.
Изоляция на уровне вычислений и памяти
Современные гипервизоры предоставляют механизмы для жёсткого разделения ресурсов. Для критичных VNF следует выделять отдельные физические ядра процессора, исключая возможность работы на общем ядре с менее доверенными функциями. Технологии контроля целостности памяти, такие как Intel SGX, позволяют создавать защищённые анклавы даже в скомпрометированной операционной системе, что может быть использовано для защиты криптографических ключей или правил фильтрации в VNF.
Изоляция на уровне сети данных
Помимо обычной VLAN или VXLAN сегментации, необходима микросегментация. Каждая VNF или группа связанных VNF должна работать в своей изолированной сети (security group), где разрешены только конкретные виды трафика по конкретным портам и протоколам. Причём политики должны задаваться не вручную, а декларативно, через систему оркестрации, и автоматически применять при развёртывании и масштабировании.
Важный аспект — изоляция служебного трафика (management plane) от пользовательского (data plane) и трафика оркестрации. Эти три типа трафика должны двигаться по физически или логически разделённым сетям с разным уровнем доверия.
Изоляция на уровне хранения
Для дисковых образов VNF и их данных должны использоваться отдельные, криптографически изолированные разделы или тома. Доступ на запись к образу функционирующей VNF должен быть заблокирован. Журналы аудита и логи работы VNF должны сохраняться на выделенное, защищённое от модификации хранилище, доступное только системе мониторинга безопасности.
Контроль целостности: как убедиться, что ничего не изменилось
В динамичной среде NFV, где экземпляры VNF могут автоматически создаваться и уничтожаться, критически важен постоянный контроль целостности. Речь не только о файловой системе.
Необходимо отслеживать:
- Целостность образов VNF в репозитории. Хэш-сумма образа должна проверяться при каждой загрузке на гипервизор.
- Немодифицируемость запущенных экземпляров. Система безопасности должна детектировать попытки изменения исполняемых файлов или критичных конфигураций внутри работающей VNF.
- Консистентность конфигурации сети. Правила микросегментации, прописанные в оркестраторе, должны постоянно сверяться с фактическими правилами, применёнными на виртуальных коммутаторах. Их расхождение — сигнал об атаке или ошибке.
Для этого используются агенты или агентless-сканирования, сравнивающие текущее состояние с эталонным «золотым» образом. Любое отклонение должно блокировать работу VNF и инициировать её пересоздание из доверенного образа.
Российский контекст: ФСТЭК и 152-ФЗ
При построении NFV-инфраструктуры для обработки персональных данных или работы в государственных информационных системах требования ужесточаются. Здесь на первый план выходят меры защиты информации, утверждённые ФСТЭК России.
Ключевые моменты, которые необходимо учесть:
| Требование | Применение в NFV |
|---|---|
| Виртуализация средств защиты информации | Сами средства защиты (межсетевые экраны, системы обнаружения вторжений) могут быть виртуализованы. Для них ФСТЭК устанавливает особый порядок оценки соответствия. Использовать можно только СЗИ, прошедшие процедуру и включённые в соответствующий реестр. |
| Контроль целостности программной среды | Требуется не только контроль целостности гипервизора и VNF, но и верификация ПО оркестратора и систем управления. Должны быть реализованы средства доверенной загрузки для физических хостов. |
| Изоляция виртуальной инфраструктуры | Требования предписывают выделение отдельных экземпляров виртуальной инфраструктуры для информационных систем разного класса защищённости. Запускать VNF для ГИС повышенного класса защищённости и коммерческие сервисы на одном гипервизоре недопустимо. |
| Аудит событий безопасности | Необходим централизованный сбор и защищённое хранение логов со всех компонентов: гипервизоров, оркестратора, систем хранения и, что важно, самих VNF. Сроки хранения определяются классом защищённости системы. |
Формальное соблюдение требований через «галочки» здесь не пройдёт. При аудите эксперты будут смотреть на реальную архитектуру, на то, как политики изоляции применяются на практике и как реагируют на инциденты средства мониторинга.
Итог: безопасность NFV как инженерная дисциплина
Безопасность Network Function Virtualization, это не опция и не набор отдельных инструментов. Это инженерная дисциплина, которая должна быть заложена в архитектуру с самого начала. Основная сложность — управлять противоречием между гибкостью, автоматизацией NFV и жёсткостью, «железностью» классических подходов к безопасности.
Невозможно просто взять и перенести политики с физических устройств на виртуальные. Требуется новая модель — модель нулевого доверия внутри самой инфраструктуры, где каждая VNF изолирована по умолчанию, а любое взаимодействие между ними явно разрешено, проверено на целостность и залогировано. Именно такой подход позволяет получить преимущества виртуализации, не превращая сеть в единую точку отказа для злоумышленника.