«Если вы попробуете объяснить сисадмину, что такое политика безопасности, он покажет вам настройки файрвола. Но если попробуете объяснить бизнесу, он скажет: ‘Мы не хотим, чтобы нас взломали’. Между этими двумя языками лежит пропасть, и intent-based networking, это мост через неё, превращающий расплывчатое ‘хотим быть в безопасности’ в точную машинерию сети. Мы говорим о языке, где намерение становится исполняемым кодом.»
От конфигурации к намерению: почему мы перестаём быть сетевыми каменщиками
Классическое управление сетями строится на ручном конфигурировании отдельных устройств. Администратор переводит требования — например, «изолировать отдел разработки от финансового» — в последовательность команд для конкретных коммутаторов, маршрутизаторов и межсетевых экранов. Это ремесленная, поштучная работа. Результат — тысячи строк конфигурации, которые становятся техническим долгом. Любое изменение требует кропотливого обновления этих конфигов, а проверка соответствия исходному требованию («защищены ли финансы?») превращается в сложнейший аудит.
Intent-based networking (IBN, сеть на основе намерений) меняет парадигму. Вышестоящая политика — намерение — становится исходным кодом для сети. Администратор декла forирует что должно быть, а система самостоятельно определяет как это реализовать, генерируя и применяя низкоуровневые конфигурации. Это сдвиг от imperative (императивного, командного) программирования к declarative (декларативному, описательному).
Формальная семантика: перевод желания в железобетонный код
Ключевая проблема здесь — двусмысленность естественного языка. «Изолировать», «защитить», «обеспечить доступ» — эти слова каждый участник процесса понимает немного по-своему. Формальная семантика вводит строгий, математический язык для описания намерений, устраняя неоднозначности. В этом контексте «интент», это не пожелание, а формальное утверждение, которое можно верифицировать.
Рассмотрим намерение безопасности: «Только администраторы могут обращаться к серверам с бухгалтерским ПО». В формализованном виде это может выглядеть как набор логических утверждений:
- Ресурс: Серверная группа «Account_ERP».
- Субъект: Группа пользователей «Domain_Admins».
- Действие: Разрешить: RDP, HTTPS.
- Условие: Все остальные субъекты → Запретить все.
- Инвариант (условие, которое должно выполняться всегда): Нет активных сессий от «Domain_Users» к «Account_ERP».
Эта формализация превращает расплывчатое правило в объект, с которым может работать система: анализировать, компилировать в правила файрвола, и, что критически важно, постоянно проверять на соответствие.
Архитектура системы IBN: от декларации до исполнения
Типичная архитектура IBN-системы состоит из нескольких взаимосвязанных слоёв.
Слой трансляции (Translation Layer). Получает декларативное намерение на формальном языке и транслирует его в сетевые политики, абстрагированные от конкретных вендоров. Например, намерение «обеспечить сегментацию» превращается в логическую политику: «Группа A не может инициировать соединение с Группой B».
Слой актуализации (Actuation Layer). Берет абстрактные сетевые политики и компилирует их в конкретные, вендорозависимые команды конфигурации для оборудования. Именно здесь происходит «магия» генерации ACL, правил межсетевого экрана или параметров VLAN.
Слой верификации и assurance (Verification & Assurance Layer). Это сердце системы безопасности. Он непрерывно, в реальном времени, проверяет, соответствует ли фактическое состояние сети (то, что есть) заявленным намерениям (тому, что должно быть). Для этого используются как пассивный анализ трафика и конфигураций, так и активное зондирование.
Практическая проверка: как выглядит компрометация в мире намерений
Представьте, что злоумышленник с правами пользователя из отдела маркетинг каким-то образом получает доступ к бухгалтерскому серверу. В традиционной сети факт этого подключения может остаться незамеченным среди тысяч других сессий. В IBN-системе сработает слой верификации.
Он постоянно проверяет инвариант: «Нет активных сессий от Domain_Users к Account_ERP». Обнаружив нарушение (активная RDP-сессия от пользователя маркетинга), система не просто запишет событие в лог. В зависимости от политики, она может:
- Автоматически разорвать сомнительное соединение.
- Изолировать инфицированную рабочую станцию в карантинный сегмент.
- Перегенерировать правила доступа для поражённого сегмента, исключив уязвимость.
- Поднять алерт для администратора с указанием на нарушенное конкретное намерение.
Здесь защита работает не на уровне отдельных сигнатур угроз, а на уровне соблюдения изначально заданных правил игры. Система защищает не «от вирусов», а целостность самой своей архитектуры безопасности.
Взгляд регулятора: 152-ФЗ и ФСТЭК через призму намерений
Требования регуляторов, такие как приказы ФСТЭК, часто формулируются на высоком уровне: «обеспечить контроль доступа», «реализовать сегментацию сети», «противодействовать несанкционированному доступу». При традиционном подходе выполнение каждого требования доказывается ворохом документации — описаниями архитектур, скриншотами конфигураций, отчётами сканеров.
IBN предлагает иной, более элегантный путь соответствия. Регуляторное требование формализуется как набор намерений и загружается в систему. С этого момента доказательством соблюдения является не бумажный отчёт, а живая, непрерывная верификация системы. Аудитору можно предоставить не стопку документов, а доступ к дашборду assurance-слоя, который в реальном времени показывает статус каждого инварианта безопасности, выведенного из требований ФСТЭК.
Это превращает соответствие из периодического, затратного мероприятия в постоянный, автоматизированный процесс. Более того, при изменении регуляторных требований (например, выходе новой редакции приказа) достаточно обновить библиотеку формализованных намерений, и система сама скорректирует политики и проверит их выполнение.
Подводные камни и пределы возможного
Переход к IBN — не техническая задача, а организационная трансформация. Это требует переосмысления роли сетевого инженера: из «техника-конфигуратора» он превращается в «архитектора политик», который должен мыслить на уровне бизнес-логики и уметь формализовать её. Нехватка таких специалистов — ключевое ограничение.
Современные IBN-решения зачастую ограничены в поддержке разнородного, особенно legacy-оборудования. Если в сети есть старые коммутаторы, которые можно настроить только через CLI, автоматическая генерация конфигов для них может быть невозможна или некорректна.
Самый сложный вопрос — формализация изначальных требований. Кто и как будет переводить расплывчатые пожелания бизнеса в бескомпромиссный язык логических утверждений? Ошибка или неполнота на этом, самом верхнем уровне, будет тиражирована и автоматизирована всей системой, потенциально создавая ложное чувство безопасности.
Что дальше? Конвергенция с Zero Trust и SOAR
Intent-based networking не существует в вакууме. Его логическое продолжение — интеграция с архитектурой Zero Trust. В модели Zero Trust политика доступа («никому не верь, проверяй каждый запрос») является идеальным кандидатом для описания в виде формальных намерений. IBN-система может стать оркестратором, который динамически настраивает сегменты сети и правила микросегментации в ответ на решения механизмов проверки доверия.
Другое направление — тесная связь с SOAR-платформами. Когда система верификации обнаруживает нарушение намерения, это событие с богатым контекстом (какое правило нарушено, кем, каким ресурсам угрожает) становится идеальным триггером для запуска сценариев реагирования в SOAR. Это создаёт замкнутый контур: обнаружение отклонения от заданной безопасности → автоматическое устранение угрозы → возврат сети в состояние, соответствующее намерению.
Сеть на основе намерений, это не следующий шаг в эволюции управления. Это смена операционной системы для всей сетевой инфраструктуры. Вместо управления устройствами вы начинаете управлять состоянием безопасности как единым целым. Вместо реактивного устранения инцидентов получаете проактивную систему, которая охраняет заданные вами правила игры. Это путь от безопасности как набора инструментов к безопасности как свойству системы, которое можно формально описать, внедрить и непрерывно проверять. И этот путь начинается с простого, но радикального вопроса: «А что, собственно, мы хотим от своей сети?» — и требует дать ответ не словами, а на языке, который понимает машина.