Средняя
Содержание
В крупных сетях правила межсетевых экранов меняются постоянно. Открыть доступ для нового сервиса, добавить временное правило для миграции, изменить NAT, расширить группу адресов, закрыть старый доступ после вывода системы из эксплуатации — всё это ежедневная работа сетевых и ИБ-команд.
Проблема в том, что через несколько месяцев уже трудно ответить на простые вопросы:
- Зачем было создано это правило?
- Кто его согласовал?
- По какой заявке его внесли?
- Должно ли оно всё ещё работать?
- Почему доступ открыт шире, чем требовалось?
- Кто отвечает за его закрытие?
Если изменение на МЭ не связано с конкретной заявкой, оно постепенно превращается в «серую зону» сетевой безопасности. Правило вроде бы есть, трафик вроде бы ходит, но бизнес-обоснование потеряно.
Как появляются несогласованные доступы?
Несогласованные доступы не всегда появляются из-за злого умысла. Чаще всё прозаичнее.
Инженер срочно открывает доступ для аварийных работ. Команда проекта просит временное правило «на пару дней». При миграции сервиса старое правило забывают удалить. В группе адресов оказывается лишняя подсеть. Изменение вносят напрямую на МЭ, потому что «заявка потом будет».
Потом начинается новая задача, люди переключаются, и временное становится постоянным.
Так в политике МЭ появляются правила без владельца, без срока действия и без понятного обоснования. Каждое из них может выглядеть неопасным по отдельности. Но в сумме они увеличивают поверхность атаки и создают бреши между сегментами сети.
Почему одной заявки недостаточно?
Само наличие Service Desk не решает проблему. Важно не только завести заявку, но и сопоставить её с фактическим изменением на МЭ.
В заявке может быть написано: «открыть доступ от сервера А к серверу Б по TCP 443». А в конфигурации появляется правило, которое разрешает доступ от всей подсети к группе серверов по нескольким портам. Формально работа выполнена. Фактически сеть получила более широкий доступ, чем был согласован.
Бывает и обратная ситуация: заявка закрыта как выполненная, но правило на МЭ не появилось или было добавлено не на том устройстве. Для бизнеса это инцидент доступности, для ИБ — потеря контроля над фактическим состоянием политики.
Поэтому важно сравнивать не только статусы заявок, а именно согласованное изменение и реальное изменение в конфигурации.
Что даёт сопоставление изменений с заявками?
Связка «заявка → изменение на МЭ» даёт командам ИБ и эксплуатации несколько практических преимуществ.
- Во‑первых, появляется прозрачность. Для каждого нового или изменённого правила можно увидеть, по какой заявке оно было создано, кто был инициатором, кто согласовал и кто выполнил изменение.
- Во‑вторых, проще выявлять несанкционированные изменения. Если правило появилось на МЭ, но в Service Desk нет соответствующей заявки, это повод для расследования. Возможно, это срочная аварийная работа, которую забыли оформить. А возможно — несогласованное открытие доступа.
- В‑третьих, можно контролировать превышение согласованного объёма. Система может сравнить параметры заявки с фактическим правилом: источник, назначение, сервис, порт, зона, устройство, срок действия. Если вместо точечного доступа появился широкий диапазон, это должно быть видно.
- В‑четвёртых, становится проще закрывать временные доступы. Если в заявке указан срок действия, система может напомнить о необходимости удаления правила или проверить, было ли оно действительно закрыто.
- В‑пятых, упрощается аудит. Вместо ручного поиска в письмах, заявках и конфигурациях можно быстро показать: вот запрос, вот согласование, вот изменение, вот текущий статус правила.
Как это работает на практике?
Представим стандартный процесс.
В Service Desk создаётся заявка на открытие доступа: источник, назначение, порт, протокол, срок действия, бизнес-обоснование и согласующие. После согласования сетевой инженер вносит изменение на межсетевом экране.
Дальше NSPM-система получает данные из Service Desk и собирает актуальную конфигурацию МЭ. Она сопоставляет заявку и фактическое изменение: появилось ли нужное правило, совпадают ли параметры, не был ли доступ открыт шире, чем требовалось, корректно ли указан срок действия, не затронуты ли лишние объекты.
Если всё совпадает, изменение получает статус подтверждённого. Если правило появилось без заявки — оно попадает в список несогласованных изменений. Если заявка есть, но фактическое правило отличается от согласованного запроса, система отмечает расхождение.
| Ситуация | Что это значит? |
|---|---|
| Есть заявка, есть совпадающее правило | Изменение подтверждено |
| Есть заявка, но правило шире | Требуется проверка |
| Есть правило, но нет заявки | Возможное несогласованное изменение |
| Заявка закрыта, но правила нет | Изменение не применено или применено неверно |
| Временный доступ не удалён | Риск просроченного доступа |
От сопоставления к управляемому внесению изменений
Сопоставление фактических изменений на МЭ с заявками — важный шаг к контролю. Но это всё ещё промежуточная модель.
В ней Service Desk остаётся источником бизнес-запроса и согласования, инженер вносит изменение на МЭ, а NSPM-система затем проверяет, что именно было сделано. Такой подход уже позволяет находить несогласованные открытия доступов, расхождения с заявкой и просроченные правила.
Более зрелый сценарий — когда изменение проходит через NSPM-систему до применения на МЭ.
В этом случае заявка из Service Desk поступает в NSPM, система анализирует её параметры, проверяет маршрут, определяет целевые межсетевые экраны, оценивает риски, ищет пересечения с существующими правилами и формирует точечное изменение. После согласования именно NSPM применяет правило или готовит корректный набор команд для применения инженером.
Такой подход даёт больше контроля:
- изменение проверяется до внесения, а не только после;
- система может заранее увидеть, что доступ слишком широкий;
- правило создаётся в нужном месте политики;
- параметры заявки и фактического изменения совпадают;
- временные доступы получают срок действия;
- результат сразу связан с номером заявки;
- после применения можно автоматически проверить прохождение трафика и собрать подтверждение.
То есть текущий этап — сопоставление заявок и фактических изменений — закрывает важную задачу аудита и контроля. А следующий шаг — переход к модели, где NSPM становится точкой управления изменениями сетевого доступа: от анализа заявки до генерации, применения и проверки правила.
В идеале политика МЭ должна меняться не напрямую «руками на устройстве», а через управляемый процесс, где каждое изменение заранее проверено, согласовано, применено в нужном объёме и подтверждено после выполнения.
Почему это важно для безопасности?
Большинство сетевых политик деградирует не резко, а постепенно.
Одно временное правило, один лишний объект в группе, один доступ «на время миграции», один забытый SSH между сегментами. Через год таких исключений уже десятки или сотни.
Атакующему не нужно, чтобы вся сеть была открыта. Ему достаточно одного лишнего пути: из пользовательского сегмента в админский, из тестовой среды в production, от старого сервера к базе данных, к которой он не должен иметь доступа.
Сопоставление изменений с заявками помогает находить такие пути раньше. Не в момент инцидента, когда уже нужно разбираться, кто и зачем открыл доступ, а в момент появления изменения.
Вывод
Изменения на межсетевых экранах должны быть не просто техническими действиями, а управляемым процессом. У каждого правила должно быть понятное происхождение: кто запросил, кто согласовал, кто внёс, что именно изменилось и почему это всё ещё нужно.
Связка NSPM с Service Desk позволяет превратить контроль изменений из ручного аудита в постоянную проверку. Если доступ открыт без заявки, шире согласованного объёма или не закрыт после окончания срока действия, это видно сразу.
Это важный промежуточный этап на пути к более зрелой модели, где заявки на сетевой доступ проходят через NSPM-систему, автоматически анализируются, проверяются на риски, преобразуются в корректные изменения и затем подтверждаются после применения.
Такой подход снижает риск несогласованных открытий, помогает не пропустить бреши в сети и делает политику МЭ более прозрачной для ИБ, эксплуатации и аудита.
Деятельность осуществляется компанией ООО «Нетопия» при грантовой поддержке Фонда «Сколково»
© Netopia.pro











