Очистка правил межсетевого экрана: аудит неиспользуемых политик

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

Что такое очистка правил межсетевого экрана и почему она становится неизбежной?

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

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

У такого накопления три вида издержек. Первый — безопасность: слишком широкие и забытые разрешающие правила становятся путями бокового перемещения для злоумышленника, уже закрепившегося в сети. Второй — эксплуатация: каждое изменение требует чтения сотен правил, поиск неисправностей затягивается, а новое правило, добавленное в конец списка, всё чаще оказывается в тени широкого правила выше. Третий — комплаенс: если на вопрос аудитора «зачем существует это правило?» нет ответа, замечание будет вынесено независимо от актуальности прошивки.

В этой статье не повторяются основы управления политиками; о синтаксисе правил, работе с объектами и профилях безопасности читайте наше руководство по управлению политиками межсетевого экрана FortiGate. Здесь в центре внимания аудит существующего набора правил и его безопасное сокращение. Самый удачный момент для очистки — замена оборудования: как описано в нашем плане миграции с устаревшего межсетевого экрана на FortiGate, аудит правил до переноса позволяет запустить новое устройство чистым с первого дня.

С чего начинается аудит? Инвентаризация правил и бизнес-обоснование

Аудит межсетевого экрана начинается с полной инвентаризации правил: политики выгружаются для каждого устройства и виртуального домена (VDOM), и каждому правилу сопоставляются владелец, назначение и запись об изменении. Правило, обоснование которого найти не удалось, помечается как подозрительное, даже если технически оно работает, и проходит процедуру ресертификации.

Инвентаризация начинается с резервной копии конфигурации. Датированная копия, снятая в начале аудита, — это одновременно точка отката и первый документ в пакете доказательств. Затем список политик выгружается в таблицу, где в каждой строке есть как минимум: идентификатор и имя политики, входной и выходной интерфейсы, объекты адресов источника и назначения, службы, действие, расписание, состояние NAT, назначенные профили безопасности, настройка журналирования, поле комментария, hit count и время последнего использования. Эта таблица — рабочая поверхность аудита; находки, решения и даты фиксируются в ней же.

Сложнее технических полей — бизнес-контекст. Каждому правилу задаются три вопроса: кто его запросил? Какому бизнес-процессу оно нужно? Когда оно станет ненужным? Ответы ищут в поле комментария, в записях об изменениях или в системе заявок. На FortiGate полей имени политики и комментария достаточно, чтобы указать номер заявки и ответственное подразделение; после аудита следует принять стандарт именования, делающий эти поля обязательными. Публикация NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy рекомендует набор правил по принципу «запрещено по умолчанию», в котором каждое правило сформулировано максимально узко и задокументировано; таблица инвентаризации — внутренний аналог такой документации.

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

Как найти неиспользуемые политики? Hit count и данные о последнем использовании

Неиспользуемая политика межсетевого экрана — это правило, которое за определённое окно наблюдения ни разу не сработало. На FortiGate столбцы hit count и last used в таблице политик, а в CLI вывод команды diagnose firewall iprope show 100004 <policy-id> показывают время первого и последнего срабатывания; журналы FortiAnalyzer подтверждают эти данные на временной оси.

Hit count — самый сильный инструмент аудита, но его легко неверно истолковать. В зависимости от версии и конфигурации счётчики могут обнуляться после перезагрузки, редактирования правила или ручного сброса (diagnose firewall iprope clear 100004), а описанный в документации FortiOS 7.2 скользящий семидневный счётчик политик меняет период, который охватывает значение на экране. Поэтому «ноль» сам по себе не означает «никогда не использовалось». Перед началом зафиксируйте, с какого момента ведётся подсчёт, и проверьте поведение счётчиков для вашей прошивки в документации Fortinet. Окно наблюдения задаётся ритмом бизнеса: для обычного офисного трафика разумный минимум — девяносто дней, а правилам, обслуживающим редкие процессы вроде закрытия года, периодических проверок или учений по аварийному восстановлению, нужно окно от шести до двенадцати месяцев.

Второй источник доказательств — журналы. На FortiAnalyzer журналы трафика можно сгруппировать по идентификатору политики и получить отчёт об использовании политик за период; этот отчёт не зависит от счётчиков устройства и показывает историю даже после их сброса. Инфраструктуре журналирования и построению отчётов посвящена наша статья о журналировании, мониторинге FortiGate и интеграции с FortiAnalyzer. Если FortiAnalyzer уже используется для централизованного журналирования, та же платформа становится источником доказательств для аудита.

Когда неиспользуемое правило найдено, путь состоит из четырёх шагов. Первый — классификация: разрешающие правила и явные запрещающие оцениваются раздельно; явный deny без срабатываний часто является осознанным выражением политики и может быть сохранён. Второй — отключение: правило не удаляется, его статус переводится в disabled, а в комментарий вносятся дата и ссылка на аудит. Третий — карантин: если в течение, например, тридцати дней не поступило сообщений о сбоях, правило готово к удалению. Четвёртый — запись: полное определение удалённого правила добавляется в пакет доказательств. На протяжении всего процесса должно быть включено журналирование нарушений на политике implicit deny: оно сразу показывает реальный трафик, заблокированный удалённым правилом, и упрощает решение об откате.

Как выявить теневые, избыточные и конфликтующие правила?

Теневое правило никогда не выполняется, потому что более широкое правило выше перехватывает весь его трафик; избыточное правило повторяет то же действие для того же трафика; конфликтующее правило применяет другое действие к частично пересекающемуся трафику. У всех трёх hit count нулевой или низкий, но корень проблемы — ошибка порядка, и решение состоит в реорганизации, а не в удалении.

Политики межсетевого экрана обрабатываются сверху вниз, срабатывает первое совпадение. Это простое правило преподносит сюрпризы в длинных списках. Пример: если правило номер двенадцать разрешает все службы из LAN к серверу приложений в DMZ, правило «только HTTPS» на позиции двадцать пять никогда не сработает; администратор считает, что действует узкая политика, а устройство применяет широкую. Опаснее сценарий, когда запрещающее правило, блокирующее доступ к файловым ресурсам сервера из гостевой сети, никогда не вступает в силу из-за широкого разрешения выше. В этом случае мера защиты, описанная в документе о политике, на практике не существует.

Есть три способа обнаружения. Организации с FortiManager могут использовать проверку согласованности политик (Policy Consistency Check), которая выполняется для пакета политик и сообщает о дублирующих, затенённых, перекрывающихся и неиспользуемых (осиротевших) объектах; уточните состав этой функции в документации к вашей версии. Независимые платформы анализа правил проверяют устройства разных производителей в одной консоли и присваивают каждому правилу оценку риска. Для небольших наборов правил достаточно отсортировать таблицу инвентаризации по пересечению адресов источника и назначения — опытный глаз найдёт теневые правила вручную. В таблице ниже сведены типы аномалий, встречающиеся при аудите, и правильное действие для каждого.

Когда найдено теневое правило, первым вопросом должно быть «какое из них правильное?», а не «удалить ли его?». Чаще всего узкое правило в тени выражает реальное намерение, а удалить нужно широкое правило над ним. Поэтому анализ теневых правил проводится вместе с сужением any-any, описанным в следующем разделе.

Any-any и слишком широкие правила: сужение самых рискованных политик

Правило any-any — это политика, в которой значение «all» стоит как минимум в двух из полей источника, назначения и службы; она фактически отменяет сегментацию сети. Безопасный способ удаления — не немедленное стирание, а сначала включение журналирования, измерение реального трафика, создание над ним узких правил для этого трафика и поэтапное отключение широкого правила.

Правила any-any обычно возникают из трёх источников: широкие разрешения, открытые при первоначальной настройке по принципу «лишь бы заработало», правила, написанные при поиске неисправностей и забытые, и исторические политики, перенесённые с предыдущего устройства. Их объединяет высокий hit count; именно поэтому они никогда не попадают в анализ неиспользуемых правил и требуют отдельной работы. Высокий hit count не доказывает необходимость правила, а лишь показывает, что через него проходит много трафика.

Сужение выполняется в шесть шагов. Первый: включить журналирование всех сессий на широком правиле и накопить данные за окно наблюдения. Второй: извлечь из журналов, какие тройки источник–назначение–служба реально используются. Третий: оформить эти потоки как узкие правила над широким, используя группы адресов и групп служб. Четвёртый: назначить правилам с выходом в интернет профили IPS, антивируса, веб-фильтрации и контроля приложений — на широком правиле эти профили часто отсутствуют. Пятый: наблюдать, как hit count широкого правила падает к нулю; если не падает, какой-то поток упущен. Шестой: когда hit count достигает нуля, отключить широкое правило, выдержать карантин и удалить.

Тот же подход применяется к административному доступу: доступ к управлению с WAN-интерфейса закрывается, управление разрешается только с доверенных адресов источника и, по возможности, из выделенной сети управления. Эти шаги не зависят от оборудования: каждая модель семейства FortiGate использует одну и ту же логику политик и те же счётчики, поэтому дисциплина аудита, выстроенная на небольшом устройстве филиала, без изменений переносится на устройство головного офиса.

Управление изменениями и доказательства аудита: как сохранить результат?

Результат очистки сохраняется только тогда, когда каждое новое правило создаётся с утверждённой заявкой, владельцем, назначением и сроком действия. Управление изменениями требует резервных копий конфигурации до и после, записи об утверждении и плана отката; доказательства аудита — это датированная инвентаризация, отчёт по hit count, список удалённых правил и переписка по ресертификации.

Нередко очищенный набор правил за полгода возвращается к прежнему состоянию, и причина — отсутствие процесса изменений. Минимальный процесс таков: заявка поступает в систему заявок с письменным бизнес-обоснованием; техническая команда проверяет, что новое правило не затеняет и не дублирует существующие; получается утверждение; изменение вносится в окно обслуживания; резервные копии конфигурации до и после сохраняются; результат проверяется, заявка закрывается. Для временного доступа используются объекты расписания FortiGate: расписание с датой окончания позволяет правилу подрядчика истечь самостоятельно и устраняет класс «забытых временных правил» у самого источника. Организации с FortiManager могут по истории ревизий конфигурации видеть, кто, что и когда изменил, и сравнивать различия между ревизиями.

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

Нормативные рамки делают этот цикл обязательным. Требование 1.2.7 PCI DSS v4.0 предписывает пересматривать конфигурации средств сетевой защиты не реже одного раза в шесть месяцев. В Турции Руководство по безопасности персональных данных (технические и организационные меры) Управления по защите персональных данных (KVKK) относит межсетевые экраны и управление правами доступа к техническим мерам; их реализацию на стороне межсетевого экрана мы разбираем в чек-листе технических мер KVKK. Об обязательствах по хранению журналов трафика и событий читайте статью о законе № 5651 и централизованном управлении журналами; в обоих случаях рекомендуем сверяться с актуальным законодательством и официальными руководствами. Если внутренняя команда не может выделить время на этот цикл, периодический аудит политик входит в стандартный объём услуги управляемого межсетевого экрана.

Чек-лист аудита политик межсетевого экрана

Чек-лист аудита политик межсетевого экрана используется, чтобы провести аудит от начала до конца и задокументировать результат с доказательствами. Каждая строка отвечает на один вопрос «да» или «нет» и называет доказательство, которое попадает в пакет; список повторяется не реже раза в полгода, а в средах с частыми изменениями — ежеквартально.

Вместо того чтобы превращать список в баллы, мы рекомендуем переводить каждое «нет» в пункт плана действий. Большое число «нет» в первом аудите нормально; цель — чтобы во втором цикле их стало меньше, а к третьему аудит превратился в рутинное обслуживание. В наших проектах самый быстрый выигрыш дают стандарт заполнения комментария и расписания с датой окончания: эти две привычки заметно замедляют повторное «загрязнение» набора правил.

Часто задаваемые вопросы

Как часто нужно проводить очистку правил межсетевого экрана?

Требование 1.2.7 PCI DSS v4.0 предписывает пересматривать конфигурации средств сетевой защиты не реже одного раза в шесть месяцев. В средах с частыми изменениями разумнее квартальный цикл, а после крупной миграции или перестройки сети следует провести внеплановый аудит.

Безопасно ли сразу удалить правило с нулевым hit count?

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

Чем теневое правило отличается от избыточного?

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

Как увидеть неиспользуемые политики на FortiGate?

Включите в таблице политик столбцы hit count и last used и отфильтруйте нулевые или устаревшие значения. В CLI команда diagnose firewall iprope show 100004 показывает время первого и последнего срабатывания по каждой политике, а отчёт FortiAnalyzer об использовании политик подтверждает вывод по журналам.

Остановятся ли бизнес-приложения, если удалить правило any-any?

Нет, если соблюдать порядок. Сначала включите на широком правиле журналирование всех сессий, измерьте реальный трафик за окно наблюдения, создайте над ним узкие правила для этого трафика и дождитесь, пока hit count широкого правила упадёт до нуля. Только после этого отключайте его.

Считается ли аудит политик межсетевого экрана доказательством для PCI DSS и защиты данных?

Доказательством служат результаты, а не сама деятельность: датированная инвентаризация правил, отчёт по hit count, список удалённых и суженных правил, ответы владельцев по ресертификации и заявки на изменения. Этот пакет подтверждает периодический пересмотр, требуемый PCI DSS, и документированный контроль доступа.

Имеет ли смысл передать очистку правил внешней команде?

Да, если внутренняя команда полностью загружена эксплуатацией; периодический аудит политик входит в объём большинства услуг управляемого межсетевого экрана. Главное, чтобы решения об удалении принимались вместе с владельцами процессов и каждый шаг фиксировался: внешняя команда анализирует и внедряет, организация утверждает.

Заключение

Очистка правил межсетевого экрана не делает устройство мощнее — она заставляет устройство применять именно ту политику, которую вы написали. Цикл аудита, который начинается с инвентаризации и бизнес-обоснования, отсеивает неиспользуемые правила по hit count и журналам, реорганизует теневые и any-any правила и документирует каждый шаг доказательствами, одновременно сокращает поверхность атаки и формирует защищаемый пакет для проверок PCI DSS и требований по защите данных. Секрет устойчивости результата — процессный, а не технический: ни одно правило не создаётся без утверждённой заявки, владельца, назначения и даты окончания.

Чтобы спланировать первый аудит вашего набора правил, пересмотреть текущую конфигурацию FortiGate или включить периодический аудит в объём управляемой услуги, вы можете записаться на бесплатную ознакомительную встречу с Sora Yazılım; мы вместе определим подходящий объём работ и подготовим предложение.