Any/Any — зло? Не всегда
Есть одно правило, которое способно вызвать у любого специалиста по ИБ лёгкое внутреннее напряжение:
🔹 source: Any 🔹 destination: Any 🔹 service: Any 🔹 action: Allow
И первая мысль обычно: «Кто это вообще пропустил?»
Но давайте честно: иногда правило Any/Any появляется не потому, что кто-то решил устроить компании филиал хаоса
Например:
🔹 временно открывали доступ для диагностики; 🔹 переносили сервис между сегментами; 🔹 проводили миграцию; 🔹 разбирались, почему «ничего не работает»; 🔹 оставили legacy-правило после изменений; 🔹 просто не определили владельца и срок действия правила
И вот здесь начинается самое интересное. Проблема Any/Any не только в самом широком доступе
Проблема в том, что через какое-то время мы можем перестать понимать, зачем это правило вообще существует
А если правило нельзя объяснить — его сложно нормально контролировать
Поэтому при аудите правил межсетевого экрана я бы смотрела не только на: «Можно ли сузить Any/Any?», но и на:
🔹 кто владелец правила? 🔹 зачем оно нужно? 🔹 какие системы реально используют этот доступ? 🔹 как долго он должен существовать? 🔹 есть ли срок пересмотра? 🔹 что произойдёт, если его отключить?
Потому что идеальная политика безопасности — это не обязательно политика, где вообще нет широких правил. Это политика, где каждое правило имеет понятную бизнес- и техническую причину
А у вас в инфраструктуре есть правила, которые появились как «временно, только проверить» — и живут уже несколько лет?
