Network ACL

Network ACL (сетевой список контроля доступа) — это набор правил, применяемых к сетевому трафику на уровне подсети или виртуального сетевого интерфейса, определяющий, какой трафик разрешён или запрещён на основе таких параметров, как IP-адреса источника и назначения, протоколы и порты. В облачных вычислениях Network ACL (NACL) является одним из основных инструментов обеспечения сетевой безопасности наряду с группами безопасности (Security Groups).

История и происхождение

Концепция списков контроля доступа (ACL) возникла в классических компьютерных сетях и операционных системах, где ACL применялись к файлам и каталогам для управления доступом пользователей. С развитием сетевых технологий ACL были адаптированы для маршрутизаторов и коммутаторов, позволяя фильтровать трафик на основе IP-адресов и портов. В облачных платформах, таких как Amazon Web Services (AWS), Microsoft Azure и Google Cloud Platform (GCP), Network ACL стали стандартным компонентом виртуальных частных облаков (VPC), предоставляя дополнительный уровень защиты на границе подсети.

Отличие от групп безопасности

В облачных средах Network ACL часто сравнивают с группами безопасности (Security Groups). Основные различия включают:

Структура и правила

Network ACL состоит из упорядоченного списка правил, каждое из которых включает:

• Номер правила (целое число, обычно от 1 до 32766) — определяет порядок применения. Чем меньше номер, тем выше приоритет.
• Тип (allow или deny) — разрешить или запретить трафик.
• Протокол (TCP, UDP, ICMP, или любой).
• Диапазон портов источника (от 0 до 65535).
• Диапазон портов назначения (от 0 до 65535).
• IP-адрес источника (CIDR-нотация, например, 10.0.0.0/8).
• IP-адрес назначения (CIDR-нотация).

Правила применяются последовательно: первое совпадение определяет действие. Если ни одно правило не совпало, применяется неявное правило deny (запрет) по умолчанию.

Применение в облачных платформах

Amazon Web Services (AWS)

В AWS Network ACL является необязательным компонентом VPC. Каждая подсеть может быть связана с одним NACL (по умолчанию — с NACL, разрешающим весь трафик). AWS рекомендует использовать NACL как дополнительный уровень защиты, особенно для публичных подсетей, где размещаются веб-серверы. Типичные сценарии:

• Запрет входящего трафика из определённых IP-диапазонов (например, из стран с высоким уровнем кибератак).
• Разрешение только определённых портов (например, 80 и 443 для HTTP/HTTPS).
• Защита от DDoS-атак на уровне сети.

Microsoft Azure

В Azure аналогом Network ACL является Network Security Group (NSG), который, несмотря на название, работает на уровне подсети или сетевого интерфейса. NSG в Azure является состоянийным (stateful), что отличает его от AWS NACL. Правила NSG также упорядочены по приоритету (от 100 до 4096). Azure NSG поддерживает теги служб (например, «Internet», «AzureLoadBalancer») для упрощения правил.

Google Cloud Platform (GCP)

В GCP Network ACL реализован через Firewall Rules (правила брандмауэра), которые применяются к VPC. Правила являются состоянийными и могут быть настроены для входящего или исходящего трафика. GCP поддерживает теги целей (target tags) для применения правил к конкретным экземплярам.

Преимущества и ограничения

Преимущества

• Простота — NACL легко настраивается и понимается.
• Производительность — фильтрация на уровне ядра сети без задержек на прикладном уровне.
• Безопасность — явное запрещение трафика предотвращает нежелательные соединения.
• Масштабируемость — правила применяются ко всем ресурсам в подсети.

Ограничения

• Отсутствие состояния — в AWS NACL не отслеживает состояние соединения, поэтому необходимо явно разрешать ответный трафик (например, для TCP-соединений — разрешать входящий SYN и исходящий SYN-ACK).
• Ограниченная гибкость — NACL не может фильтровать на основе содержимого пакета (например, URL или заголовков HTTP).
• Сложность управления — при большом количестве правил может возникнуть путаница с порядком и приоритетами.
• Не поддерживает логирование — в отличие от групп безопасности, NACL в AWS не предоставляет журналов трафика (для этого требуется VPC Flow Logs).

Пример настройки

Допустим, необходимо разрешить входящий HTTP-трафик (порт 80) из интернета (0.0.0.0/0) на веб-серверы в подсети 10.0.1.0/24, но запретить SSH (порт 22) из любого источника. Правила для входящего трафика:

Для исходящего трафика необходимо разрешить ответные пакеты (например, порт 80 в обратном направлении).

Безопасность и лучшие практики

• Использовать NACL как дополнительный слой защиты, не заменяя группы безопасности.
• Минимизировать количество правил, группируя разрешённые диапазоны (например, 10.0.0.0/8 вместо отдельных подсетей).
• Регулярно аудировать правила на предмет устаревших или избыточных разрешений.
• В облачных средах с высокой нагрузкой (например, в AWS) учитывать, что NACL не поддерживает логирование — для анализа трафика использовать VPC Flow Logs.
• Избегать правил deny с широкими диапазонами (например, 0.0.0.0/0), так как они могут блокировать легитимный трафик.

Критика и альтернативы

Network ACL критикуется за отсутствие состояния в некоторых реализациях (AWS), что усложняет настройку для протоколов с динамическими портами (FTP, SIP). В таких случаях рекомендуется использовать группы безопасности или специализированные брандмауэры следующего поколения (NGFW). Также NACL неэффективен против атак на прикладном уровне (SQL-инъекции, XSS), для которых требуются веб-приложенные брандмауэры (WAF).

Источники

• Amazon Web Services. «Network ACLs for VPC». AWS Documentation.
• Microsoft Azure. «Network security groups». Azure Documentation.
• Google Cloud. «VPC firewall rules overview». GCP Documentation.
• Stallings, W. (2016). «Network Security Essentials: Applications and Standards». Pearson.
• RFC 2827 — Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing.