В чём принципиальная разница между security group и сетевым ACL в облачной сети?
Security group обычно является состояниeм фильтром, привязанным к сетевому интерфейсу или экземпляру ресурса: разрешённый исходящий трафик позволяет пропустить соответствующий ответный входящий трафик без отдельного входящего правила. Сетевой ACL обычно применяется на границе подсети и проверяет каждый пакет независимо, поэтому для двустороннего обмена в нём нужно явно разрешить оба направления, включая обратные эфемерные порты.
Ранние сетевые фильтры часто строились как правила на границах сегментов сети. Такой подход хорошо ограничивал трафик между подсетями, но не позволял удобно описывать доступ конкретного экземпляра к конкретным источникам.
Облачные платформы добавили два уровня контроля. Сетевой ACL сохраняет модель фильтрации на периметре подсети, а security group предоставляет более близкую к ресурсу политику доступа, которую проще применять к группам виртуальных машин или сетевых интерфейсов.
Предположим, приложение находится в приватной подсети, а база данных — в другой подсети. Нужно разрешить приложению подключаться к базе, не открывая доступ всей подсети и не создавая правила, которые случайно блокируют ответы на установленные соединения.
Неверный выбор уровня фильтрации приводит к разным рискам. Слишком широкая security group увеличивает поверхность атаки, а ошибочный статeless ACL может разрешить исходный пакет, но отбросить ответный или заблокировать служебный трафик.
Security group обычно назначается сетевому интерфейсу, виртуальной машине или управляемому ресурсу. Правила чаще всего разрешающие: если соединение не разрешено подходящим правилом, оно отклоняется. В типичной реализации фильтр отслеживает состояние соединения, поэтому ответный трафик разрешён автоматически как часть уже разрешённого соединения.
Сетевой ACL обычно связан с подсетью и действует до того, как трафик достигнет конкретного экземпляра. Он проверяет входящие и исходящие пакеты отдельно, поэтому правило для запроса не означает автоматическое разрешение ответа. Для TCP нужно учитывать порт назначения исходного соединения, эфемерный порт на стороне клиента и порядок обработки правил, если конкретная платформа его использует.
Практическая модель обычно такова: security group задаёт доступ между конкретными ролями ресурсов, например между группой приложений и группой базы данных, а ACL добавляет грубое ограничение на уровне подсети. Не следует считать ACL заменой межсервисной авторизации: он видит сетевые атрибуты, но не доказывает личность приложения.
Оба механизма зависят от конкретного облака. Нужно проверить, являются ли правила состояниями, поддерживаются ли явные запреты, как обрабатываются правила с одинаковым приоритетом и какие системные адреса или порты требуют разрешения. Для диагностики полезно отдельно проверять маршрут, ACL, security group, локальный firewall и сам процесс, принимающий соединение.
Приложение в подсети приложений не могло подключиться к базе данных в подсети данных. Сначала рассматривали два варианта: открыть широкий диапазон адресов в ACL, что было быстро, но увеличивало доступ, или разрешить в security group базы входящий TCP-доступ от security group приложения, сохранив ACL как ограничитель подсетевого уровня.
Выбрали второй вариант. В security group базы разрешили только нужный порт от группы приложения, а ACL оставили с минимально необходимыми правилами для входящего и исходящего трафика. Это сохранило узкий периметр доступа и не потребовало перечислять динамические IP-адреса экземпляров.
При проверке отказа отдельно убедились, что сетевой ACL пропускает обратный трафик. Иначе состояние security group не помогло бы: пакет ответа был бы отброшен stateless-фильтром подсети.
1. Достаточно ли разрешить соединение только в security group получателя?
Обычно для входящего соединения достаточно разрешить его в security group получателя, если исходящий трафик в security group отправителя не ограничен. Но при наличии ограничительных исходящих правил их тоже нужно проверить. Кроме того, сетевые ACL, локальные firewall и политики самого приложения остаются независимыми уровнями контроля.
2. Почему после разрешения порта базы соединение всё ещё может не работать?
Потому что разрешение в security group не исправляет отсутствие маршрута, неверную таблицу маршрутизации, запрет в ACL, неправильный DNS-адрес или отсутствие процесса, слушающего порт. Диагностику следует выполнять по пути пакета: разрешение имени, маршрут, фильтры подсети, фильтры интерфейса, затем состояние сервиса и его собственная авторизация.
3. Можно ли использовать сетевой ACL для ограничения доступа конкретного приложения?
Только если приложение можно надёжно выделить по стабильным адресам или подсетям. При динамическом масштабировании адреса меняются, поэтому ACL становится хрупким и часто требует широких диапазонов. Для доступа между ролями ресурсов обычно предпочтительнее security group, а для доказательства личности приложения нужны дополнительные механизмы, например взаимная аутентификация или IAM-интеграция.