Кратко о сути

Security Group (SG) — это stateful фаервол уровня экземпляра/интерфейса (ENI). Network ACL (NACL) — stateless фаервол уровня подсети. Оба работают на уровне сети в VPC, но имеют разный принцип работы, область применения и модель правил.

Основные отличия

• Уровень применения
  SG применяется к сетевому интерфейсу (инстансу). NACL применяется к подсети (все инстансы в подсети унаследуют правила NACL).

• Stateful vs stateless
  Security Group — stateful: если входящий пакет разрешён, ответ автоматически разрешён (и наоборот) без явного правила для ответа. NACL — stateless: для ответа нужен отдельный обратный правило (и для входа, и для выхода).

• Типы правил
  SG — только правила ALLOW (разрешить). Нельзя явно DENY. NACL поддерживает ALLOW и DENY и правила нумеруются; первое совпадение решает.

• Порядок применения
  SG смотрит на все правила и применяет их «совокупно» (нет порядка). NACL ищет первое правило по порядку (по номеру) и применяет его.

• Возможность ссылок на объекты
  SG позволяет указывать в правилах другие SG (удобно для разрешения трафика между слоями приложения). NACL оперирует только CIDR.

• По умолчанию
  В типичной реализации VPC: default SG имеет специфические разрешения (обычно разрешает трафик между участниками той же группы и открыт исходящий), default NACL часто разрешает весь трафик — кастомные NACL обычно более строгие.

Примеры и поведение (пошагово)

1. Подключение SSH к инстансу:

2. Security Group: inbound TCP 22 от 203.0.113.5/32 — достаточно. Ответ клиенту вернётся автоматически (stateful).

3. NACL: если используется кастомный NACL, нужно добавить inbound правило Allow TCP 22 from 203.0.113.5/32 и outbound правило Allow TCP ephemeral-ports to 203.0.113.5/32 (или более общую outbound allow для ответов), потому что NACL stateless и ответный трафик имеет другой порт.

4. Пример правила NACL (порядок важен):

Rule 100 — ALLOW TCP 22 from 203.0.113.5/32
Rule 110 — ALLOW TCP 80 from 0.0.0.0/0
Rule 32767 — DENY ALL

Первое правило, соответствующее пакету, применяется и последующие не проверяются.

Практические рекомендации

• Используйте SG как основной механизм защиты экземпляров: создавайте SG по слоям (bastion, app, db), указывайте минимальные разрешения и используйте ссылки между SG для внутренних соединений.

• Используйте NACL как дополнительный, подсетевой слой: для ограничений на уровне CIDR (чёрные списки, защита от широкомасштабных атак) или для быстрых блокировок IP-диапазонов. Не усложняйте NACL лишними правилами — они сложнее в управлении.

• Для stateless NACL всегда добавляйте зеркальные правила для возвратного трафика (или широкие правила для диапазонов ephemeral-портов), чтобы не ломать соединения.

• Не полагайтесь только на NACL для внутренней сегментации — SG удобнее и безопаснее для этого.

• Для отладки: проверьте, к какому SG привязан ENI, к какой подсети и какой NACL ассоциирован с подсетью; проверьте таблицу маршрутов/IGW/NAT; используйте VPC Flow Logs и tcpdump/ss на инстансе; тестируйте соединение nc/curl.

Типичные ошибки и ловушки

• Ожидание stateful-поведения от NACL — забывают добавить обратные правила → соединения падают.

• Неправильный порядок правил в NACL — специфичные правила стоят ниже общего DENY.

• Смешение логики (слишком много правил в NACL вместо использования SG) — ухудшает управляемость.

• Отсутствие ограничения исходящего трафика в SG (по умолчанию многие SG разрешают весь исходящий трафик) — это риск утечек/компрометации.

Как выбирать

• Для тонкой, роле-ориентированной политики — Security Groups.

• Для сетевой фильтрации на подписи CIDR/массовых списков/защиты на уровне подсети — NACLs.