Контроль периметра в публичном облаке: почему NGFW недостаточно
В on-premise безопасность строилась по принципу крепости: возвел высокий забор — и можно спать спокойно. В облаках эта стратегия даёт лишь ложное чувство безопасности. Ваш «забор» может быть неприступным, но в нём оказывается сотня распахнутых «ворот», о которых вы даже не подозреваете. Пока вы настраиваете единую точку входа через NGFW, разработчик парой кликов выводит в публичный доступ базы данных, виртуальные машины, бакеты объектного хранилища и другие сервисы. Как же контролировать периметр в публичном облаке, если старая стратегия больше не работает?
Коротко о главном
- Облачная инфраструктура динамична: помимо известных вам публичных IP-адресов, контролируемых NGFW, постоянно появляются новые. В условиях быстрых изменений эти новые точки входа часто остаются незамеченными для службы ИБ — так появляются слепые зоны в защите периметра с помощью файрвола.
- Многие ресурсы и каналы управления невозможно контролировать через NGFW. Администрирование (создание, удаление ресурсов) идет через API провайдера в обход файрвола. Кроме того, публичными могут быть ресурсы, которые технически нельзя поместить за межсетевой экран: S3-бакеты, управляемые базы данных, облачные функции и др. В этих случаях доступ регулируется только правами и настройками конфигурации облака.
- Следовательно, защита от внешних атак требует как сетевой фильтрации (с помощью NGFW и/или групп безопасности), так и контроля конфигурации облака (с помощью решения класса CSPM, Cloud Security Posture Management).
- Максимальный эффект CSPM дают в составе CNAPP-платформ, таких как Cloud Advisor. Cloud Advisor использует данные о публичности, уязвимостях и ошибках настроек, чтобы выявить реальные пути атак. Это помогает правильно расставлять приоритеты и устранять критические угрозы в первую очередь.
Сетевого периметра больше нет
On-premise модель опиралась на защиту периметра сети. Ключевые данные оставались внутри корпоративного контура, скрытые за VPN и межсетевыми экранами. Вся инфраструктура — строго «за забором». В облаке публично доступными могут стать самые разные ресурсы: виртуальные машины, управляемые базы данных, бакеты объектного хранилища, кластеры Kubernetes, API-шлюзы, балансировщики нагрузки, снапшоты, облачные функции и другие. В зависимости от типа ресурса, публичность может предоставляться и в обход сетевых экранов, через настройки конфигурации облака. Поэтому защита периметра больше не ограничивается NGFW: теперь необходимо не только фильтровать входящий трафик, но и контролировать публичность каждого отдельного сервиса на уровне конфигурации облака.
Конфигурация облака — это совокупность всех настроек и параметров, которые определяют состояние и поведение облачных ресурсов (виртуальных машин, сетей, хранилищ, прав доступа и т.д.), например:
- Политики управления идентификацией и доступом (Identity and Access Management, IAM), определяющие, кто и что может делать в вашем облаке.
- Настройки публичного доступа к виртуальным машинам, объектным хранилищам и базам данных.
- Правила групп безопасности (Security Groups) и сетевые ACL (списки доступа), которые регулируют входящий и исходящий трафик.
Рассмотрим типичные ситуации, когда конфигурация и особенности облачной архитектуры делают NGFW недостаточным.
«Теневой» периметр
Даже если вы завели виртуальную машину за NGFW, разработчик с достаточными на то правами может создать и назначить ей публичный IP. Трафик к этой ВМ пойдёт через интернет напрямую, минуя NGFW. Аналогичная ситуация складывается с управляемыми сервисами и базами данных: публичный доступ к ним часто включается одной опцией в конфигурации, которая мгновенно выводит ресурс на периметр в обход корпоративного файрвола.
Существует стереотип: есть к ресурсу привязан публичный IP — ресурс в интернете, если к ресурсу не привязан публичный IP — ресурс изолирован. В облаке это заблуждение опасно. Чтобы разобраться, почему, рассмотрим два простых примера:
Публичный IP есть — публичности нет. У ВМ есть публичный IP, но группа безопасности настроена так, что разрешает соединение только с одного IP-адреса (например, из офиса).
Публичного IP нет — публичность есть. ВМ находится за балансировщиком нагрузки или DNAT, но к ней прикреплена группа безопасности, разрешающая входящие соединения из интернета (0.0.0.0/0). Публичного IP нет, но машина фактически находится на периметре.
Вывод: Для контроля конфигурации облака недостаточно инвентаризации публичных IP-адресов. Чтобы корректно определять реальную доступность ресурса, необходимо учитывать всю цепочку сетевой связности.
Ресурсы, которые невозможно защитить NGFW
Бакеты объектного хранилища (S3-бакеты), облачные функции, снэпшоты и многие другие ресурсы в принципе невозможно «спрятать» за файрвол — их безопасность зависит исключительно от корректности настроек доступа.
Пример:
- Данные аутентификации для Azure Container Registry.
- Параметры подключения к базам данных сред разработки и продакшена.
- Секретные ключи доступа к приватным облачным ресурсам.
Эта утечка затронула сервисы компании в Северной Америке, Европе и Китае. Инцидент наглядно демонстрирует, как недостаточный контроль конфигураций облака приводит к критическим последствиям.
Подключение к API облачного провайдера
Управление ресурсами в облаке выполняется через веб-консоль или публичное API провайдера. Это управление может происходить из любой точки мира. Такой трафик идёт напрямую к управляющим сервисам облака, и вы не можете направить его через NGFW, так как эти сервисы находятся в зоне ответственности провайдера. Аналогично тому, что вы не можете поставить NGFW перед Яндекс Диском.
Скачать полную версию схемы доступов к ресурсам в публичном облаке
Контроль периметра в публичном облаке
Итак, наличие NGFW не гарантирует защиту облачной инфраструктуры. Публичность ресурсов здесь определяется также их конфигурацией, и если контролировать только сеть или только настройки публичности — риски сохраняются. Необходима защита по обоим направлениям: сетевая фильтрация и непрерывный контроль настроек облачных сервисов.
- Контроль политик управления доступом (IAM)
Анализируют настройки сервиса IAM (Identity and Access Management). Выявляют избыточные привилегии, устаревшие учётные записи и другие нарушения лучших практик безопасности (не ротируемые ключи, отсутствие MFA и т.п.). - Полную инвентаризацию публичных ресурсов
Автоматически обнаруживают все публично доступные ресурсы — базы данных, виртуальные машины, бакеты, API Kubernetes-кластеров, облачные функции — и поддерживают их актуальный список. - Контроль и анализ групп безопасности (Security Groups)
Контролируют правила групп безопасности и выявляют слишком широкие правила сетевой фильтрации для предотвращения несанкционированного доступа извне. - Анализ реальной публичной доступности
Проверяют не формальные признаки (наличие публичного IP), а всю цепочку сетевой связности. Это позволяет выявить публичные ресурсы за балансировщиками нагрузки и DNAT — те, что не видны при поверхностной проверке, но фактически доступны из интернета. При анализе также учитываются правила групп безопасности, которые могут как разрешать, так и блокировать трафик до конечного ресурса, даже если сетевая связность формально установлена.
CSPM работают в реальном времени: непрерывно контролируют конфигурацию облака, уведомляют о появлении рисков и дают рекомендации по их устранению.
Однако у изолированной CSPM есть ограничение: она видит только вершину айсберга, присваивая одинаковый уровень опасности всем публичным ресурсам — независимо от их «внутреннего» состояния. Оценивая риски лишь по одному параметру, такие решения не способны выстроить цельную картину угроз, без которой невозможна их корректная приоритизация.
Cloud Advisor — единая платформа для безопасности в публичном облаке, #1 CNAPP (Cloud-Native Application Protection Platform) в России — устраняет этот недостаток. Вместо изолированных проверок она объединяет данные о рисках безопасности со всех слоёв облачной инфраструктуры: ошибки конфигурации, уязвимости, вредоносное ПО, секреты в открытом виде, избыточные права и т.д. Именно полнота контекста позволяет Cloud Advisor выявлять критические пути атаки и определять реальные угрозы безопасности.
Пример:
В инфраструктуре появляются две виртуальные машины с публичными IP-адресами:
ВМ 1: без уязвимостей, с корректными настройками доступа, без секретов.
ВМ 2: с критической уязвимостью и секретом от бакета объектного хранилища.
Изолированная CSPM увидит только то, что обе машины стали публично доступны, и присвоит событиям одинаковый приоритет.
Cloud Advisor видит иначе. Получив данные от сканера уязвимостей, он распознаёт опасную комбинацию: «публичный доступ + уязвимость + секрет». Такая машина мгновенно выделяется как критическая угроза:

Результат: команды ИБ получают мгновенную картину реальных рисков, экономят часы на ручном анализе предупреждений и фокусируются на том, что действительно требует внимания.
Выводы и рекомендации
- Полагаться только на NGFW в облаке опасно: — Во-первых, из-за «теневого» периметра: разработчики могут назначать публичные IP ресурсам в обход согласований и мгновенно выводить их на внешний периметр. — Во-вторых, многие ресурсы (S3-бакеты, API-шлюзы, облачные функции и т.д.) технически невозможно разместить за сетевым экраном — их безопасность определяется исключительно настройками их конфигурации. — В-третьих, управление инфраструктурой идёт через публичные API провайдера напрямую, минуя любую сетевую фильтрацию.
- Чтобы защитить периметр в публичном облаке, необходим двусторонний подход: сетевая фильтрация (NGFW и/или группы безопасности) плюс непрерывный контроль конфигурации облака. Решения класса CSPM (Cloud Security Posture Management) автоматизируют эту задачу: они выявляют публичные ресурсы, анализируют группы безопасности и контролируют политики IAM.
- Максимальный эффект даёт использование CSPM в составе платформы CNAPP, такой как Cloud Advisor. Анализируя данные со всех слоёв облачной инфраструктуры — от конфигурации облака до уязвимостей и вредоносного ПО на ВМ и в контейнерах, — Cloud Advisor выявляет не просто риски, а реальные пути атак. В результате вместо потока разрозненных оповещений вы получаете чёткий список критических угроз, которые требуют немедленного реагирования.
Оставьте заявку на демонстрацию и пилотный доступ, и эксперты Cloud Advisor покажут, как платформа помогает защищать динамический периметр облачной инфраструктуры.