Оптимизация правил сложный и трудоемкий процесс. А цена ошибки может быть очень высока. Наша команда разработки постоянно развивает продукт и следит за тем, чтобы клиенты были довольны качеством работы. Но некоторые алгоритмы MIST Insight заслуживают особого внимания, их без стеснения можно называть уникальными, они потребовали от нас не только усидчивости, но и покипеть мозгами. В этой статье поговорим об одном из таких алгоритмов. А именно разберемся, как важна автоматизация оптимизации правил доступа и почему MIST Insight помогает спать спокойно сетевым администраторам.

Сетевые устройства часто имеют сотни, тысячи и даже десятки тысяч правил. Добавление нового правила становится всё сложнее. Если вручную можно отсмотреть несколько десятков правил, то при большом их количестве поиск нужного сетевого диапазона превращается в серьёзную проблему: можно не учесть как отдельные адреса, так и целые подсети, затеняющие вновь добавляемое правило, или наоборот, перекрываемые им. При длительном времени эксплуатации сетевого устройства на нём остаются легаси-правила, часто не имеющие никакого значения и просто захламляющие конфигурацию. С увеличением количества правил растёт и утилизация инфраструктуры сетевого устройства, причём отнюдь не полезной нагрузкой — это могут быть дополнительные вычисления, проверка каждого пакета по многочисленным правилам, что негативно сказывается на производительности и времени отклика. Становится всё сложнее «разматывать» этот клубок.

Множество правил, добавленных разными администраторами в разное время, должны быть консолидированы в значительно меньшее число, затенённые и избыточные нужно убирать. А выявление немаршрутизируемых правил может указывать как на неактуальность, так и на недочёты в таблице маршрутизации. Всё это достаточно трудоёмкий процесс, требующий глубокого анализа политики безопасности и тестирования, чтобы не нарушить работу сети.

Разработчики ПО обычно могут тестировать свои доработки на тестовых и предпромышленных средах, тогда как сетевым администраторам такая роскошь в основном не доступна — как правило, тестовые сегменты сети включают адреса, отличающиеся от промышленных подсетей, что делает полноценное тестирование изменений проблематичным. Часто в организациях реконфигурирование сетевых устройств осуществляется по принципу «всё или ничего». Одной неверной командой можно сильно огорчить бизнес и расстроить клиентов — например, отключить критически важный сервис или внести серьезные уязвимости.

Различные методы снижения рисков, вроде выполнения работ на сетевом оборудовании в наименее загруженные с точки зрения инфраструктуры и процессов окна (maintenance windows), не сильно облегчают ситуацию — сетевая инфраструктура зачастую работает круглосуточно, а влияние на бизнес может проявиться и после окончания таких окон.

Несколько абсолютно реальных примеров из жизни:

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

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

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

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

Для того чтобы облегчить жизнь сетевым администраторам и специалистам по кибербезопасности, достаточно давно были разработаны системы Network Security Policy Management (NSPM). Они выполняют в том числе функции оптимизации правил доступа, помогая администраторам разбирать паутину накопившихся на устройствах правил доступа, выявлять избыточные и конфликтные правила, а также симулировать влияние новых политик. Но даже специализированному ПО сделать это непросто — сложные связи между правилами, ограниченные возможности интеграции с разнородным оборудованием и требования к высокой доступности сети усложняют задачу.

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

По сути, при оптимизации правил доступа для выявления избыточности, затененности или возможности объединения требуется провести сравнение каждого со всем, то есть сложность данного алгоритма весьма велика O(N*N). При значительном количестве правил, например 10000, имеем 100 000 000 сравнений. Конечно, при относительно умеренной стоимости инфраструктуры сегодня это цифра не кажется слишком пугающей - но закидывать всё мощностями не очень хороший вариант, особенно если правила на устройстве меняются часто, а результат хочется получать за секунды. И здесь нужен несколько более сложный алгоритм, нежели наивное сравнение правил. Конечно, правила по сути своей описывают диапазоны подсетей – то есть некие отрезки на прямой сетевых адресов. Неужели нам может помочь дерево отрезков? Но не все так просто: правила включают в себя как source и destination подсети, так и сервисы, доступ к которым правила и обеспечивают (читай набор портов и протоколов для source и destination) и кроме того правила могут входить в состав политик и применяться на разных сетевых интерфейсах или группах интерфейсов. Здесь мы уже получаем многомерные пространства отрезков - вотчина R или SS деревьев. Математика и методы работы с этими деревьями достаточно сложны, хотя, например, сами деревья широко используются в задачах кластеризации и поиске ближайших соседей. Наш случай тоже, видимо, возможно попробовать положить на многомерные деревья - главное потом не запутаться при реализации. Особенно с учетом всяких нестандартных поведений правил (вспомните, например, правила CISCO ALL и CISCO ANY).

Задача выглядит непростой и даже покинувшие нас иностранные вендоры решают ее не слишком эффективно. Зная данную проблему не понаслышке, мы сразу решили, что наш продукт MIST Insight должен справляться с этой задачей гораздо лучше и у нас получилось!

В актуальной версии нашего продукта удалось добиться приемлемой производительности и потребления ресурсов при выполнении анализа правил. При том что данные показатели зависят от степени оптимальности политики, можно привести следующую статистику:

И это всё с потреблением оперативной памяти не более 6 Гб даже со 100 000 правил! Также ощутимый выигрыш в производительности обеспечивает распараллеливание вычислений на несколько потоков. Данные метрики актуальны при выполнении анализа на восьмиядерном процессоре. На этом мы не останавливаемся и будем продолжать совершенствовать наши алгоритмы.

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