Группы безопасности против сетевых ACL: выбор брандмауэра для AWS VPC
Разберитесь в сложностях безопасности AWS VPC, освоив различия между группами безопасности (SG) и сетевыми ACL (NACL). Это экспертное руководство объясняет область действия, сохранение состояния и оценку правил обоих средств контроля. Узнайте, почему SG идеально подходят для детальной, сохраняющей состояние защиты экземпляров, в то время как NACL необходимы для широкой, не сохраняющей состояние сегментации подсетей и явных политик запрета. Реализуйте надежную многоуровневую стратегию брандмауэра для вашей облачной инфраструктуры.
Группы безопасности против сетевых ACL: выбор брандмауэра для AWS VPC
При проектировании безопасной среды виртуального частного облака (VPC) в Amazon Web Services (AWS) администраторы полагаются на несколько уровней контроля для управления сетевым трафиком. Двумя основными компонентами для фильтрации трафика на сетевом уровне являются группы безопасности (SG) и сетевые списки контроля доступа (NACL).
В консоли они выглядят похоже, но отказывают по-разному. Группы безопасности обычно описывают намерения приложения. Сетевые ACL применяются для установки широких границ подсетей или экстренных запретов.
Роль брандмауэров в AWS VPC
AWS предоставляет сетевую безопасность на двух основных уровнях внутри VPC:
- Уровень экземпляра (группы безопасности): Действует как брандмауэр для конкретных экземпляров EC2 или ресурсов (например, баз данных RDS или балансировщиков нагрузки Elastic Load Balancer). Он контролирует трафик к сетевому интерфейсу и от него.
- Уровень подсети (сетевые ACL): Действует как брандмауэр без сохранения состояния для целых подсетей, контролируя поток трафика, входящего или выходящего за границу подсети.
Подробное изучение групп безопасности (SG)
Группы безопасности функционируют как основной детальный брандмауэр для отдельных ресурсов. Они сохраняют состояние и фильтруют по протоколу, порту и источнику или назначению.
Ключевые характеристики групп безопасности
| Особенность | Описание | Последствия для использования |
|---|---|---|
| Область действия | Применяется непосредственно к эластичному сетевому интерфейсу (ENI) экземпляра. | Контролирует поток трафика к экземпляру и от него. |
| Сохранение состояния | Сохраняет состояние. Если входящий запрос явно разрешен, соответствующий исходящий трафик (ответ) автоматически разрешается, независимо от правил исходящего трафика. | Упрощает настройку; необходимо определить только направление инициирующего трафика. |
| Тип правила | Только разрешение. Явные правила запрета невозможны. Трафик, не соответствующий явному правилу ALLOW, неявно запрещается. |
Сосредоточен на определении того, что разрешено. |
| Оценка | Все правила оцениваются до принятия решения. Они не нумеруются, и неявный DENY не обрабатывается, пока не будут отклонены все правила ALLOW. |
Порядок не имеет значения; все правила считаются равными. |
Пример настройки группы безопасности
Чтобы разрешить доступ по SSH (порт 22) к экземпляру EC2, вам нужно только входящее правило. Исходящее правило для ответа SSH обрабатывается автоматически благодаря сохранению состояния SG.
| Тип | Протокол | Диапазон портов | Источник | Описание |
|---|---|---|---|---|
| Входящий | TCP | 22 | 0.0.0.0/0 (или конкретный IP администратора) | Разрешить доступ по SSH |
| Исходящий | Все | Все | 0.0.0.0/0 | (По умолчанию: разрешает весь трафик, но при необходимости это можно ограничить) |
# Концептуальное представление потока с сохранением состояния
Пользователь (исходный IP) --> [Входящее правило SG: РАЗРЕШИТЬ 22] --> Экземпляр EC2
Экземпляр EC2 (ответ) --> [Неявное отслеживание состояния] --> Пользователь (ответ получен)
Совет по лучшей практике: Всегда определяйте правила группы безопасности, используя принцип наименьших привилегий. По возможности ограничивайте диапазоны исходных IP-адресов вместо разрешения 0.0.0.0/0.
Подробное изучение сетевых ACL (NACL)
Сетевые ACL обеспечивают второй уровень защиты, действуя как фильтр без сохранения состояния на границе подсети. Они эффективны для сегментации сети и широких политик запрета.
Ключевые характеристики сетевых ACL
| Особенность | Описание | Последствия для использования |
|---|---|---|
| Область действия | Применяется ко всей подсети VPC. Подсеть может быть связана только с одним NACL одновременно. | Контролирует весь трафик, входящий или выходящий из подсети, затрагивая все экземпляры внутри нее. |
| Сохранение состояния | Не сохраняет состояние. Как входящие запросы, так и соответствующие исходящие ответы должны быть явно разрешены. | Требует тщательной настройки для обратного трафика (эпизодические порты). |
| Тип правила | Разрешение и запрет. Вы можете явно определить правила для разрешения или блокировки трафика. | Отлично подходит для блокировки известных вредоносных IP-адресов или запрета определенных протоколов в масштабе сети. |
| Оценка | Правила нумеруются (от 1 до 32766) и оцениваются последовательно, начиная с наименьшего номера. Первое подходящее правило применяется немедленно. | Порядок правил имеет решающее значение. Неявное правило запрета (последнее обработанное правило) запрещает все, что не было явно разрешено. |
Обработка трафика без сохранения состояния (эпизодические порты)
Поскольку NACL не сохраняют состояние, вы должны учитывать эпизодические порты, используемые клиентами, подключающимися к вашим серверам. Когда клиент инициирует соединение, он использует порт назначения (например, 80 для HTTP) и исходный порт с высоким номером (диапазон эпизодических портов, обычно 1024-65535).
Чтобы разрешить веб-трафик (HTTP) в подсеть, вам нужны два правила:
- Входящее правило: Разрешает трафик на порт назначения (например, 80).
- Исходящее правило: Разрешает обратный трафик к клиенту, используя исходные эпизодические порты.
| Номер правила | Тип | Протокол | Диапазон портов | Источник/Назначение | Действие правила |
|---|---|---|---|---|---|
| 100 | Входящий | TCP | 80 | 0.0.0.0/0 | РАЗРЕШИТЬ (Входящий веб-трафик) |
| 110 | Исходящий | TCP | 1024-65535 | 0.0.0.0/0 | РАЗРЕШИТЬ (Исходящий веб-ответ - Эпизодические порты) |
| * | Неявный запрет | Все | Все | Все | ЗАПРЕТИТЬ (Обрабатывается последним) |
Предупреждение: Если вы пропустите соответствующее исходящее правило для эпизодических портов в NACL, трафик достигнет экземпляра (из-за входящего правила), но ответ будет отброшен на границе подсети, что приведет к тайм-аутам соединения.
Сводка сравнения: SG против NACL
В следующей таблице приведены ключевые различия между двумя типами брандмауэров:
| Особенность | Группа безопасности (SG) | Сетевой ACL (NACL) |
|---|---|---|
| Область применения | Уровень экземпляра/ENI | Уровень подсети |
| Состояние | Сохраняет состояние | Не сохраняет состояние |
| Типы правил | Только разрешение | Разрешение и запрет |
| Оценка правил | Все правила оцениваются, без определенного порядка. | Правила оцениваются последовательно по номеру (сначала наименьший); первое совпадение выигрывает. |
| Поведение по умолчанию | Запрещает весь входящий трафик, разрешает весь исходящий (если не ограничено). | NACL по умолчанию разрешает весь входящий/исходящий трафик. Пользовательские NACL запрещают весь входящий/исходящий трафик. |
| Влияние на трафик | Применяет правила только в том случае, если трафик предназначен для или исходит от связанного ресурса. | Фильтрует трафик, проходящий через границу подсети, затрагивая все ресурсы в подсети. |
Выбор правильного брандмауэра: сценарии и лучшие практики
Успешная безопасность VPC основана на совместном использовании SG и NACL в многоуровневом подходе (защита в глубину).
Когда отдавать предпочтение группам безопасности
Группы безопасности должны быть основным инструментом для фильтрации сетевого доступа из-за их сохранения состояния и возможности ссылаться на другие SG, что упрощает настройку приложений.
- Детальный контроль приложений: Используйте SG, чтобы определить, какие порты и протоколы требуются для конкретного приложения (например, разрешение трафика только на порту 3306 от SG веб-сервера к SG базы данных).
- Внутренняя связь: Управляйте безопасностью трафика между экземплярами в одной подсети или между подсетями (например, обеспечение связи балансировщика нагрузки с его целевыми группами).
- Простота управления: Поскольку они сохраняют состояние, SG требуют меньше правил и менее подвержены ошибкам, чем управление эпизодическими портами с помощью NACL.
Когда внедрять сетевые ACL
NACL лучше всего использовать для установки широких общесетевых границ и политик сегментации.
- Широкие политики запрета: Используйте явные правила
DENY(правило №100) для блокировки конкретных вредоносных IP-адресов или диапазонов IP-адресов во всей подсети до того, как трафик достигнет экземпляров. - Сегментация подсетей: Устанавливайте строгие границы между уровнями вашей архитектуры (например, убедитесь, что NACL подсети базы данных явно запрещает весь входящий трафик из интернета, независимо от того, как может быть настроена SG).
- Требования соответствия: Некоторые стандарты соответствия могут требовать фильтрации на уровне подсети, что делает NACL необходимыми.
- Фильтрация протоколов без сохранения состояния: NACL необходимы, если вам нужно фильтровать протоколы без сохранения состояния, которыми SG не могут эффективно управлять самостоятельно (хотя это редко встречается для стандартного трафика TCP/UDP).
Ошибки, вызывающие простои
Самая распространенная ошибка NACL — забыть об обратном трафике. Кто-то разрешает входящий TCP 443 в публичную подсеть, но оставляет исходящие правила слишком строгими. Балансировщик нагрузки или экземпляр получает SYN, но ответ отбрасывается на выходе. Со стороны клиента это выглядит как тайм-аут, а со стороны экземпляра сервис может казаться полностью работоспособным.
Другая ошибка — использование NACL для политик для каждого приложения. Если подсеть содержит веб-, рабочие и административные экземпляры, один NACL применяется ко всем ним. Правило, добавленное для одной рабочей нагрузки, может непреднамеренно раскрыть или нарушить другую рабочую нагрузку в той же подсети. Если вам нужно разное сетевое поведение, используйте разные группы безопасности и рассматривайте отдельные подсети только тогда, когда есть реальная граница, которую нужно обеспечить.
Нумерация правил также требует внимания. Оставляйте промежутки, такие как 100, 110, 120, вместо 1, 2, 3, чтобы вы могли вставить экстренные правила позже. Помните, что первое совпадение выигрывает. Запрет на правиле 90 отменит разрешение на правиле 100, даже если разрешение выглядит более конкретным для человека, быстро просматривающего консоль.
Для групп безопасности распространенной ошибкой являются широкие диапазоны источников. 0.0.0.0/0 на порту 443 для публичного балансировщика нагрузки может быть нормальным. Тот же источник на SSH, RDP, Redis, PostgreSQL или внутреннем административном API обычно является проблемой. Предпочитайте ссылки на группы безопасности внутри VPC и узкие CIDR для доступа операторов.
Когда вы наследуете существующую VPC, экспортируйте правила и сгруппируйте их по назначению: публичные точки входа, трафик между приложениями, хранилища данных, администрирование и экстренные запреты. Правила без четкого владельца или причины — это то, где обычно скрывается устаревшая уязвимость.
Подход защиты в глубину
В типичной хорошо спроектированной VPC потоки трафика должны проходить как через NACL, так и через группу безопасности. Если какой-либо из средств контроля безопасности запрещает трафик, пакет отбрасывается.
- Входящий поток: Трафик входит в подсеть -> NACL проверяет правила -> Трафик достигает ENI экземпляра -> Группа безопасности проверяет правила -> Трафик достигает приложения.
- Исходящий поток: Приложение генерирует ответ -> Группа безопасности (проверка сохранения состояния пройдена) -> Трафик покидает ENI экземпляра -> NACL проверяет правила -> Трафик покидает подсеть.
Используя NACL для грубой сегментации и правил запрета, а SG для точных, сохраняющих состояние разрешений на уровне приложений, вы максимизируете эффективность безопасности, сохраняя простоту настройки.
Практический шаблон проектирования
Для большинства VPC приложений начинайте с групп безопасности. Дайте балансировщику нагрузки публичную группу безопасности, дайте экземплярам приложения группу безопасности, которая принимает трафик только от группы безопасности балансировщика нагрузки, и дайте базе данных группу безопасности, которая принимает трафик только от группы безопасности приложения на порту базы данных. Эта модель следует графу зависимостей приложения и переживает изменения IP-адресов.
Используйте NACL более экономно. Хороший вариант использования NACL — это запрет на уровне подсети для известного плохого CIDR, жесткая граница вокруг подсети базы данных или правило соответствия, которое должно применяться до того, как трафик достигнет любого ENI в подсети. NACL становятся проблематичными, когда команды пытаются зеркалировать каждое правило приложения в них. Правила портов возврата без сохранения состояния легко испортить, и один запрет с низким номером может нарушить работу всей подсети.
Когда соединение истекает по тайм-ауту, проверяйте оба уровня в пути пакета. Для входящего интернет-трафика к экземпляру EC2 в публичной подсети запрос должен пройти входящее правило NACL, таблицу маршрутизации и входящее правило группы безопасности. Ответ должен пройти отслеживание состояния группы безопасности и исходящее правило NACL. Если SG выглядят правильно, но клиенты все еще зависают, правило эпизодического порта NACL часто является недостающим элементом.
Самая чистая ментальная модель такова: группы безопасности говорят, какие ресурсы могут общаться с какими другими ресурсами; NACL говорят, что подсеть никогда не разрешит. Держите эти задачи раздельными, и дизайн будет легче проверять.