У каждой сетевой команды есть мысленный список того, чему никогда не следует попадать в продакшн: оставленный включенным telnet, открытые строки сообщества SNMP в текстовом виде, плоскость управления, доступная отовсюду. Написать правило для их обнаружения — простая задача. Однако сложнее поддерживать это правило в актуальном, полном и безопасном состоянии во всех доменах, которыми оно управляет. Сетевые средства контроля как код превращают этот мысленный список в правила, которые может проверить машина.

Требование вроде «доступ управления должен использовать защищенные протоколы» может охватывать центр обработки данных, кампус, SD-WAN и облако. Но каждый домен выражает это намерение через разные API, модели конфигурации и команды. Когда требования пересекают эти границы, команды по-своему интерпретируют, опускают или ослабляют элементы управления. В результате возникают пробелы и отклонения, которые трудно заметить из какого-то одного домена.

Open Policy Agent (OPA) предлагает выход из ситуации. Он работает на основе одной простой идеи. вы пишите правила в виде кода, передаете движку структурированные данные, а он возвращает четкое решение по этим данным. OPA завоевал репутацию в мире облачных технологий. Там, например, он определяет, какие рабочие нагрузки могут запускться в кластере Kubernetes и какие сервисы могут взаимодействовать друг с другом. Тот же подход можно применить и к настройке сети.

Текущая конфигурация устройства, выгруженная в формате JSON, представляет собой структурированные данные, как и любые другие. Вопрос «отключен ли telnet на каждом устройстве?» — это как раз тот тип вопросов, на которые движок политик отвечает лучше всего. Намерение политики остается централизованным, версионируемым и проверяемым, в то время как доменные адаптеры обрабатывают локальные детали. Затем каждый домен обеспечивает соблюдение этих решений с помощью собственных встроенных инструментов. В этой статье показано, как выявлять небезопасную конфигурацию до того, как она попадет на устройство, а затем поддерживать единый стандарт безопасности во всех доменах.

Почему это важно для вашей сети

Написание сетевых средств контроля в виде кода — это не вопрос эстетики. Напротив, это меняет то, что ваша организация может предотвратить, доказать и на что может положиться в сети:

Выявляйте проблемы до того, как они приведут к инциденту. Вы тестируете каждое средство контроля на заведомо корректных и некорректных конфигурациях. Затем движок помечает небезопасное или нестандартное изменение до того, как оно попадет на устройство, а не во время сбоя или разбора полетов после инцидента.
Будьте готовы к аудиту без спешки. Правила и вся история их изменений хранятся в системе контроля версий. Запускайте их по требованию, когда вам нужен отчет о текущем состоянии сети на определенный момент времени. Аудит превращается в запрос вместо ручного поиска доказательств.
Единый уровень безопасности во всех доменах. Ваше определение «безопасного» в равной степени применимо к центру обработки данных, кампусу и SD-WAN. Каждый домен обеспечивает соблюдение стандарта одинаковым образом, вместо того чтобы каждый продукт интерпретировал его по-своему, что приводит к расхождениям.
Меньше ручной проверки, шире охват. Вы один раз описываете, как выглядит правильная конфигурация, а затем позволяете движку проверять каждое устройство. Инженеры перестают проверять код строчка за строчкой, и проверки охватывают гораздо большую часть инфраструктуры, чем это возможно при выборочных проверках.
Подходит для используемых вами инструментов. Поскольку результаты возвращаются в виде структурированных данных, одно и то же средство контроля может блокировать конвейер изменений, открывать тикет или передавать данные на дашборд без написания кастомного связующего кода и развертывания новой платформы.

Приведенные ниже примеры показывают каждый из этих пунктов в действии.

Двухминутное руководство по OPA и Rego

Если вы раньше не пользовались OPA, вот все, что вам понадобится для понимания остальной части этой статьи.

OPA — это небольшой автономный движок принятия решений. Вы передаете ему две вещи: политику (правила, написанные на языке Rego) и некоторые входные данные (любой документ JSON). В ответ вы получаете решение (также в формате JSON). В этом и заключается вся модель. OPA не внедряется в ваши системы и ничего не меняет. Он отвечает на вопросы о предоставленных вами данных, а что делать с полученным ответом — решать вам.

Rego — это язык, на котором вы пишите правила. Он читается как набор утверждений, которые истинны при выполнении их условий. Правило задает результат, а затем перечисляет условия под ним. Когда выполняются все условия, правило дает результат. В отличие от большинства языков, в Rego нет циклов или управляющих конструкций. Вместо этого вы описываете, что считается нарушением, а OPA берет остальное на себя.

Две идеи определяют практически все:

Политика и данные разделены. Правила выражают логику («помечать любой интерфейс, использующий telnet»), в то время как в отдельном файле данных JSON хранятся значения («вот список утвержденных протоколов управления»). Таким образом, операторы могут обновлять значения, не затрагивая логику, и одно и то же правило работает для всех.
Решение — это просто данные. OPA не обязательно должен возвращать простое «да/нет». Правило может возвращать структурированный объект (какие нарушения сработали, почему и как их исправить). Другие инструменты могут затем прочитать этот объект и выполнить соответствующие действия.

Вы можете попробовать все, что описано далее, в песочнице Rego в вашем браузере или локально с помощью интерфейса командной строки opa. Никаких кластеров, агентов и сложной настройки.

Выявление небезопасной конфигурации до того, как она попадет на устройство

Проблема

Всего одна небезопасная настройка может привести к сбою, замечанию аудита или стать плацдармом для взлома. Оставленный включенным telnet, открытый HTTP-сервер, слабый SNMP: каждый из них проникает из-за поспешного изменения или скопированного шаблона. Каждый из них легко упустить при проверке, но дорого объяснять впоследствии. Тем временем уровень уязвимости растет с каждым устройством, на котором молчаливо тиражируется та же ошибка. Команды хотят находить их автоматически, подобно тому как линтер находит плохой код, еще до того, как изменение попадет на устройство.

Подход

Современные устройства IOS XE могут возвращать свою текущую конфигурацию в виде структурированного JSON через RESTCONF. Корнем документа является Cisco-IOS-XE-native:native. Как только конфигурация представлена в формате JSON, она становится просто входными данными для OPA, и вопрос «разрешает ли это устройство telnet?» превращается в правило. Строки VTY управляют доступом по telnet (transport input), в то время как HTTP-сервер находится в настройках ip. Вот небольшой пакет средств контроля с двумя правилами:

В отличие от этого, проверка HTTP представляет собой простое сравнение:

Каждое правило добавляет структурированные результаты в единый набор нарушений (violations) вместо простого логического значения true/false.

Результат

Затем передайте ему конфигурацию config.json, в которой строки VTY принимают telnet и включен обычный HTTP-сервер:

Чистая конфигурация возвращает []. Вывод читаем машиной, поэтому один и тот же результат может заблокировать CI-конвейер, открыть тикет или передать данные на дашборд.

Тестируйте как код

Поскольку средство контроля — это просто код, вы можете тестировать его как код. В OPA встроен инструмент запуска тестов. Напишите правило, имя которого начинается с test_, укажите входные данные прямо в коде, а затем проверьте результат утверждением (assertion).

Благодаря этому целый класс небезопасных изменений просто не сможет незаметно попасть на устройство. И вы можете это доказать. Вы версионируете, проверяете и тестируете средство контроля с той же дисциплиной, которой вы уже доверяете для остальной части вашей инфраструктуры как кода.

Сетевые средства контроля как код: пишите один раз, применяйте во всех доменах

Проблема

Стандарт безопасности приносит наибольшую пользу, когда он применяется последовательно во всех доменах. Назначение, например обеспечение безопасного доступа для управления, остается неизменным для IOS XE, Meraki и SD-WAN. Тем не менее, каждая платформа моделирует свою конфигурацию по-разному. Проверка каждого домена по отдельности оставляет возможность для неравномерного покрытия и отклонений. Это также затрудняет демонстрацию соблюдения требований в масштабах всей сети. Вместо этого целью является определение стандарта один раз. Тогда вы получаете единое, надежное представление всей инфраструктуры независимо от домена.

Подход

Пакеты Rego предоставляют нам естественный способ организовать это. Каждый домен получает собственный пакет, который умеет читать конфигурацию этого домена. Тонкий пакет верхнего уровня затем объединяет их результаты. Правила ужесточения из предыдущего раздела уже находятся в cisco.iosxe. Защитное ограничение Meraki — это сопутствующий пакет, который считывает совершенно другую структуру. Его входными данными являются SSID каждой сети, возвращаемые конечной точкой беспроводных SSID Dashboard API. Пакет помечает любой включенный SSID, который является открытым:

Эти два пакета не имеют общей структуры. Один обходит строки VTY и IP-настройки исходной конфигурации, в то время как другой обходит input.networks. Но они согласованы в отношении структуры ответа. Каждое нарушение представляет собой объект с защитным ограничением, доменом, подробной информацией и средством исправления. Благодаря этому соглашению единый пакет верхнего уровня может объединить их:

Результат

Теперь один запрос формирует отчет по всей инфраструктуре одновременно. Перед его запуском разместите три файла как cisco/iosxe/hardening.rego, cisco/meraki/hardening.rego и cisco/report.report.rego (или cisco/report.rego). Сама инфраструктура представляет собой один документ JSON, estate.json, содержащий данные каждого домена бок о бок:

Учитывая устройство IOS XE, чьи строки VTY принимают telnet, и сеть Meraki с открытым SSID:

Как слои сочетаются друг с другом

Это концепция многоуровневости, лежащая в основе дизайна. Высокоуровневое намерение («пометить небезопасную конфигурацию») остается неизменным, в то время как каждый пакет домена сопоставляет его с собственными конструкциями этого домена. В результате верхнему уровню никогда не нужно знать, как домен представляет telnet или открытый SSID. Вместо этого он лишь собирает ответы в едином формате.

Последующее добавление SD-WAN носит аддитивный характер. Напишите cisco.sdwan, добавьте одну строку в список, и каждый отчет будет автоматически подхватывать полученные им результаты. Этот список также является местом, где вы выбираете, что именно нужно принудительно применять. Например, сайт, подпадающий под определенные стандарты, активирует только те домены и наборы правил, которые ему необходимы. Тот же механизм формирования отчетов по-прежнему обслуживает его.

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

Начало работы

Все в этой публикации работает локально, развертывание инфраструктуры не требуется.

Установите OPA. Это единственный бинарный файл: brew install opa, образ контейнера или прямая загрузка. В примерах используется синтаксис OPA 1.x. Команда opa предоставляет вам возможности eval, test и fmt.
Экспериментируйте в браузере. Rego Playground позволяет вставить входной документ и политику и мгновенно увидеть решение. Это самый быстрый способ прочувствовать язык.
Получите конфигурацию в формате JSON. Современные устройства IOS XE предоставляют свою работающую конфигурацию через RESTCONF. Один запрос GET возвращает смоделированную в YANG конфигурацию в формате JSON, готовую для передачи в OPA. Если у вас нет устройства под рукой, вам поможет DevNet Sandbox с IOS XE.
Напишите свое первое защитное ограничение. Начните с одного правила, такого как проверка telnet выше, добавьте тест и запуск opa test. Затем развивайте пакет дальше.

Если вы хотите глубже изучить язык, документация OPA и коллекция Learning Rego станут лучшими следующими шагами.

Куда это ведет

Мы начали со знакомого риска: небезопасная настройка проникает в производство. Но мы пришли к чему-то более ценному. Защитные ограничения отлавливают небезопасные изменения до развертывания, и вы можете подтвердить свое состояние по запросу. Единый стандарт безопасности также работает одинаково в самых разных сетевых доменах. Другими словами, происходит сдвиг от политики как документа, интерпретируемого людьми, к сетевым защитным ограничениям как коду, оцениваемому машиной. Вы пишете их один раз, тестируете как код, а затем применяете везде.

Поскольку каждое решение возвращается в виде структурированных данных, те же защитные ограничения естественным образом вписываются в уже используемые вами системы. Начните в режиме только отчетов, чтобы увидеть свое текущее состояние, ничего не меняя. Затем передайте результаты в конвейер CI, откройте тикет или выведите их на панель мониторинга. Когда вы будете уверены, позвольте решению запустить автоматизированное исправление. Растущий интерес к операциям с поддержкой ИИ только добавляет ценности. Агенту гораздо проще анализировать структурированный отчет, чем разрозненные выходные данные CLI. Между тем, фактическое принудительное применение остается в протестированных, версионированных правилах.

Ничто из этого не требует новой платформы. Это небольшой бинарный файл, несколько файлов Rego в Git и конфигурация, которую ваши устройства уже предоставляют. Это фундамент, на котором вы можете начать строить уже сегодня.