Зачем вообще сравнивать security groups
В облаках сетевой периметр давно «переехал» ближе к ресурсу: виртуальная машина, балансировщик, база, контейнерный кластер. Вместо одного общего firewall на границе вы получаете распределённый cloud firewall, которым управляете через API/консоль и описываете как код (IaC).
Терминология у провайдеров разная: где-то это security groups, где-то firewall rules, где-то отдельный сервис. Но вопросы у админов и DevOps обычно одинаковые:
- Это stateful или stateless? Нужно ли явно разрешать ответный трафик?
- Как устроены правила ingress/egress: есть ли исходящие правила, как они применяются?
- Какие есть лимиты по числу правил, групп, ссылок «группа на группу», тегов?
- Что чаще всего ломается при миграции между AWS/GCP/Azure/Hetzner?
Ниже — практическое сравнение и набор best practices, которые помогают держать доступ управляемым и предсказуемым.
Базовая модель: stateful vs stateless и что это меняет
Для большинства сценариев ключевое различие — stateful или stateless фильтрация:
- Stateful: если вы разрешили входящий трафик (например, TCP/443), то ответы на него обычно разрешаются автоматически. Аналогично, если разрешили исходящее соединение, ответы на него проходят без дополнительных правил.
- Stateless: вход и выход контролируются независимо. Разрешили вход — не факт, что ответ уйдёт. Нужно внимательно прописывать оба направления.
В «группах безопасности» чаще всего используется stateful-поведение, но рядом могут существовать stateless-ACL (например, на уровне подсетей). Типичная ошибка миграции: переносят правила «как есть» и внезапно ломают обратные ответы или исходящий трафик из-за различий моделей или наличия второго слоя фильтрации.
Практическое правило: сначала определите, где именно у вас применяется stateful-фильтрация, а где — stateless-ACL. И только потом переносите ingress/egress.
Отдельная боль в эксплуатации — «эффективная политика». В ряде облаков итоговое решение складывается из нескольких сущностей (например, правила на NIC плюс правила на subnet), и отладка превращается в проверку всех слоёв по цепочке.
AWS: Security Groups (stateful) + NACL (stateless)
Как устроены AWS Security Groups
В AWS классические Security Groups — это stateful-фильтр на уровне ENI (сетевого интерфейса) экземпляра/балансировщика и ряда других сервисов. Они работают по принципу allow-list: внутри SG нельзя сделать явный deny, можно только разрешать.
В AWS есть оба направления: ingress и egress задаются отдельно. Частая практическая проблема — «слишком широкий egress по умолчанию» (разрешено всё наружу). Для серверов с доступом к секретам/метаданным это повышает риск эксфильтрации данных при компрометации приложения.
Что важно помнить про лимиты
Лимиты в AWS зависят от региона и квот аккаунта. На практике чаще всего упираются в:
- количество правил в одной SG;
- количество SG, прикрепляемых к одному интерфейсу/инстансу;
- количество ссылок «SG на SG» и рост списков CIDR (когда активно размножают подсети/исключения).
Если инфраструктура растёт, появляется соблазн делать SG «на каждую сущность» и линковать между собой. Это удобно, но требует дисциплины: именование, теги, регулярная уборка неиспользуемых сущностей и контроль дрейфа.
NACL как второй слой
Помимо Security Groups в AWS есть Network ACL на уровне подсети — stateless-механика с deny/allow и порядком правил. Если NACL реально используются (не «дефолтные пустые»), при расследовании «почему не ходит» всегда проверяйте оба слоя: SG на ENI и NACL на subnet.
GCP: VPC firewall rules (по сути stateful) и приоритеты
Модель правил в GCP
В Google Cloud чаще говорят про VPC firewall rules. Правила применяются на уровне сети/проекта и выбираются через target tags или service accounts (удобно для подхода «политики на роль», а не «политики на IP»).
Важное отличие по мышлению: в GCP вы чаще управляете не «группа привязана к инстансу», а «правило применимо к набору инстансов по меткам или по service account». Это облегчает массовое управление, но требует процесса: кто и как ставит теги, кто имеет право менять service account, как предотвращать «случайно повесили тег, который делает ресурс публичным».
Ingress/egress, deny и приоритеты
В GCP есть входящие и исходящие правила, а также приоритет и явные deny. Это позволяет строить «default deny egress» и точечные разрешения. Обратная сторона — риск конфликтов: более приоритетное правило может неожиданно перекрыть другое.
Практичный приём — договориться о диапазонах приоритетов (например, отдельные диапазоны для платформы и продуктовых команд), чтобы изменения были предсказуемыми и проще проходили ревью.
Где болит по лимитам
Чаще всего — в росте количества правил и сложности матрицы тегов. Теги сами по себе удобны, но их неконтролируемое размножение усложняет аудит: «почему этот инстанс доступен снаружи?» начинает требовать расследования по нескольким правилам и нескольким тегам.
Azure: Network Security Groups (NSG) + ASG и нюансы stateful
NSG и уровень применения
В Azure ключевая сущность — Network Security Group (NSG). NSG можно привязывать к подсети и/или к сетевой карте (NIC). Правила учитывают вход/выход (Inbound/Outbound) и обрабатываются по приоритету, с allow/deny и дефолтными правилами.
В типовых сценариях Azure NSG ведёт себя как stateful firewall (возвратный трафик для разрешённых соединений не требует зеркальных правил). Но в сложных топологиях (например, NVA, UDR, асимметричная маршрутизация) ожидания «stateful» могут разъехаться с реальностью, и это лучше проверять тестами на конкретной схеме.
ASG как аналог «группа-на-группу»
Application Security Groups (ASG) позволяют описывать правила не по IP/CIDR, а по логическим группам интерфейсов. Это близко к ссылкам SG в AWS: удобно, когда адреса динамические, а роль стабильна.
Limits и эксплуатационные нюансы
Частый источник инцидентов — «двойной слой»: NSG на subnet и NSG на NIC одновременно. В итоге политика становится комбинацией двух уровней, и можно легко попасть в ситуацию «открыли порт на NIC, но subnet NSG режет» (или наоборот).
Если вы дополнительно используете хостовый firewall (iptables/nftables/Windows Firewall), полезно чётко разделить ответственность уровней. По теме хостовой фильтрации пригодится разбор: Docker и firewall: iptables vs nftables, типовые ловушки.
Hetzner Cloud: простой Firewall, но дисциплина всё равно нужна
Как выглядит cloud firewall у Hetzner
В Hetzner Cloud механизм обычно называется просто Firewall. Он заметно проще, чем у гиперскейлеров: меньше сущностей, меньше вариантов таргетинга, меньше «слоёв». Для многих проектов это плюс: легче объяснить, легче аудировать, меньше неожиданных пересечений политик.
Но базовые вопросы остаются теми же: какие направления ingress/egress поддерживаются, есть ли stateful-поведение, каков порядок применения правил. Закладывайте время на тесты: один неверно понятый «исходящий разрешён всегда» превращается в дырку, а один «лишний deny» — в простой.
Где чаще ошибаются
- Оставляют открытым SSH «на весь интернет», потому что «временно, потом закроем».
- Публикуют административные порты (панели, метрики, БД) без IP allow-list.
- Не разделяют роли: один firewall на всё, затем хаотичные исключения.
Если переносите нагрузку из AWS/GCP/Azure в Hetzner (или наоборот), заранее продумайте, чем замените привычные «ссылки на группы» или «таргет по service account», если их нет: обычно это означает больше работы с адресными списками и более строгую сегментацию по сетям/окружениям.
Сравнение в лоб: что важно админам
Точка привязки правила
- AWS: Security Group привязана к ENI/ресурсу; NACL — на подсети.
- GCP: правило в VPC таргетится тегами или service account.
- Azure: NSG можно повесить на subnet и/или NIC; есть ASG.
- Hetzner: firewall привязывается к серверам/ресурсам в рамках возможностей платформы.
Deny и приоритеты
- AWS SG: только allow, без deny, порядок не важен; deny обычно реализуют NACL или отдельными сервисами/маршрутизацией.
- GCP: allow и deny, приоритет имеет значение.
- Azure NSG: allow/deny, приоритет имеет значение, есть дефолтные правила.
- Hetzner: модель проще и обычно ориентирована на allow; конкретные детали зависят от реализации, проверяйте поведением на тестовом стенде.
Stateful и контроль egress
Во всех четырёх экосистемах stateful-поведение обычно ожидается для «групп безопасности» и эквивалентов. Но практический уровень безопасности часто определяется egress: если «наружу можно всё», любой взломанный сервис получает готовый канал для управления и утечки данных.
Best practices: правила, которые реально спасают
1) Начните с «default deny» там, где это возможно
Цель — минимально необходимый вход и минимально необходимый выход. На практике проще начинать с egress: запретить всё и разрешить только нужные направления (DNS, NTP, обновления, внешние API, SMTP-реле). Делайте это итеративно: сначала наблюдение и инвентаризация, потом ужесточение.
2) Разделяйте публичный фронт и внутренние роли
- Edge: LB/Ingress, открыты 80/443 (и, возможно, админ-доступ только через bastion/VPN).
- Core: приложения, БД, очереди, кэши — без публичного входа, только из нужных подсетей/ролей.
Это банально, но именно смешивание ролей делает политики нечитаемыми и усложняет аудит.
3) Не используйте «0.0.0.0/0 на SSH/RDP» даже временно
Если нужен доступ администратора:
- делайте IP allow-list (VPN, офис, bastion);
- используйте короткоживущие окна доступа (автоматизация, которая снимает правило по таймеру);
- включайте дополнительные меры: MFA, ключи, ограничение пользователей, логирование.
4) Группируйте правила по назначению, а не по командам
Хорошие именования описывают поток трафика и порт:
web-ingress-httpsapp-to-db-5432node-egress-dns-ntp
Плохие — «sg-prod-1», «allow-temp», «rules-new». При расследовании инцидентов понятные имена экономят часы.
5) Минимизируйте CIDR, предпочитайте «ссылки на сущности»
Если платформа позволяет (AWS SG references, Azure ASG, GCP service accounts/tags), лучше описывать доступ «роль к роли», а не «подсеть к подсети». CIDR хорош для статики (корпоративный VPN), но плохо подходит для динамики (autoscaling, ephemeral instances, смена адресации).
6) Считайте лимиты заранее и проектируйте под рост
Лимиты — не формальность. Симптомы приближения к потолку:
- растёт число точечных исключений;
- в одном объекте firewall десятки почти одинаковых правил;
- становится трудно понять, какие правила ещё реально используются.
На этом этапе полезно переходить к более иерархичной модели: базовые политики + небольшие сервисные политики, а также пересматривать сегментацию (подсети, роли, отдельные сети для окружений).
7) Аудитируйте «эффективные правила», а не только исходники
Важно смотреть не только «что написано», а «что реально применилось к ресурсу». Особенно в Azure (NSG на subnet и NIC) и в AWS (SG плюс NACL). Полезные регулярные отчёты:
- какие порты реально открыты наружу;
- какие ресурсы имеют egress на 0.0.0.0/0;
- какие правила не используются (по логам/flow logs).
8) Проверяйте firewall-изменения в CI/CD
Минимум — автоматические проверки «не открылся ли 22/3389 наружу», «не появился ли публичный доступ к БД». В идеале — policy-as-code: изменения в cloud firewall проходят ревью так же, как изменения в приложении.
Если у вас есть периферийные VPN-связи и доступ админов идёт через туннели, удобно выносить админ-доступ в отдельный контур. По практике поможет материал: site-to-site WireGuard на VDS: как собрать связность между площадками.
Паттерны для типовых сервисов (шпаргалка)
Публичный веб-сервис за балансировщиком
- На LB/Ingress: inbound 80/443 из интернета; outbound — к target/backends.
- На бекендах: inbound только от LB/ingress-сущности; outbound — к БД/кэшу/внешним API по необходимости.
База данных
- Inbound: только от приложений (роль к роли), никаких публичных подсетей/интерфейсов.
- Egress: минимально необходимый (репликация, бэкапы, мониторинг), по возможности без «весь интернет».
Админка и метрики
- Inbound: только из VPN/bastion/allow-list.
- Не публикуйте наружу панели, эндпоинты метрик, exporters.
Выводы: на что опираться при выборе и миграции
- AWS — простые stateful Security Groups на ресурс + отдельные stateless NACL на подсеть. Удобно строить «роль к роли», но deny внутри SG нет, а egress часто оставляют слишком широким.
- GCP — правила на уровне VPC с таргетингом тегами/service account и с deny/приоритетами. Мощно для централизованных политик, но требует дисциплины тегирования и управления приоритетами.
- Azure — NSG с приоритетами и возможностью привязки на двух уровнях (subnet/NIC) плюс ASG для логических ролей. Гибко, но легко получить «двойной слой» и неожиданные пересечения.
- Hetzner — более прямолинейный cloud firewall. Проще в обслуживании, но часть «удобств» гиперскейлеров может отсутствовать, что важно учесть в архитектуре.
Независимо от провайдера, выигрыш дают не «самые умные правила», а повторяемый процесс: least privilege, контроль egress, понятные роли, аудит эффективных политик и автоматические проверки на опасные изменения.
