Даже в компаниях среднего размера количество различных сетевых устройств с функциями межсетевых экранов может измеряться десятками, а в крупных их уже сотни. Проконтролировать, кто, когда поправил какие списки доступа и с какой целью, порой бывает практически невозможно. Зачастую ACL построены неэффективно, вследствие чего увеличивается общая загрузка устройства, а непродуманные изменения могут привести к неработоспособности или появлению «дыр» в безопасности.
Для решения этих проблем необходим инструмент, позволяющий производить мониторинг всех изменений в списках доступа на межсетевых экранах. Нужно четко понимать, кто из сотрудников, в какое время и для чего добавил или удалил то или иное правило. ИБ важно иметь в наличии инструментарий, фиксирующий и формализующий действия сотрудников организации по всей цепочке процесса предоставления/отзыва сетевого доступа.
Наилучшим подходом здесь является система заявок, когда для того, чтобы что-то изменить в списках доступа, администратор создает заявку, которая затем одобряется специалистами ИБ. При создании заявки необходимо указать не только, какой порт или протокол нужно открыть, но и на какой срок и для каких целей это нужно. Наличие такого функционала в решении по управлению сетевыми конфигурациями является необходимым. Также желательно наличие возможности интеграции с системами управления заявками, например, Service Desk.
Еще одной типичной проблемой при изменении настроек доступа в уже развернутой сети является то, что очень трудно точно просчитать, какие последствия повлечет за собой открытие или закрытие определенного порта. Например, существует множество приложений, работающих по протоколу RPC, который использует порты выше 1024 для установки ответных соединений, и блокировка портов из этого диапазона может привести к неработоспособности сетевых приложений.
Причем на первый взгляд определить, закрытие какого именно порта привело к проблемам, далеко не всегда представляется возможным. Таким образом, возникает необходимость эмулировать изменение списков доступа на сетевом оборудовании в целях выявления проблем с блокировкой трафика.
Еще одна сложность со списками доступа – это их неоптимальное конфигурирование. Предположим, правило, блокирующее 30 процентов трафика, стоит на 100-м месте в списке доступа. Тогда треть всего трафика бесполезно проверяется предыдущими 99-ю правилами и лишь затем блокируется 100-м правилом. Если мы переместим данное правило с 100-го на первое место, то блокируемые 30 процентов трафика будут отбрасываться после первой же проверки, и устройству не надо будет тратить ресурсы на выявление соответствия оставшимся 99 правилам. Подобный функционал позволяет существенно оптимизировать работу средств межсетевого экранирования.
Плюс не лишним было бы иметь единую консоль, позволяющую из одной точки управлять всеми сетевыми средствами защиты.
Итак, мы определились с основными требованиями, которые предъявляются к системе централизованного управления сетевыми устройствами. Теперь посмотрим, что есть на рынке для решения данных задач.
Статью целиком читайте в журнале «Системный администратор», №11 за 2015 г. на страницах 42-46.
PDF-версию данного номера можно приобрести в нашем магазине.
- Сайт Tufin Technologies – http://www.tufin.com.
- Список поддерживаемых устройств Tufin – http://www.tufin.com/supported-devices-and-platforms.
- Сайт компании AlgoSec – http://www.algosec.com.
- Сайт компании Firemon – https://www.firemon.com.
- Материалы по AlgoSec – http://www.anti-malware.ru/reviews/AlgoSec_Firewall_Analyzer.
- Воробьев А. Обзор систем по управлению устройствами обеспечения ИБ. // Журнал «Безопасность компьютерных систем».