Настройка облачного файрвола: Security Groups и NACLs

Мы регулярно сталкиваемся с проектами, где неверно настроенные Security Groups или NACL приводят к утечкам данных или недоступности сервисов. Частая проблема — открытый доступ к SSH (22 порт) на все IP после тестирования. Или забытые ephemeral-порты в NACL, которые блокируют ответный трафик. Разбираемся, как правильно организовать сетевую защиту в облаке. За последние годы мы провели аудит более 50 облачных инфраструктур: в 70% случаев находили критические ошибки в правилах файрвола. Мы расскажем, как избежать этих ошибок.

Почему Security Groups не заменяют NACL?

Security Groups и Network ACLs — разные уровни защиты в AWS, которые часто путают. Security Group работает на уровне ENI (сетевого интерфейса инстанса), stateful — ответный трафик пропускается автоматически. NACL работает на уровне subnet, stateless — правила нужно писать для обоих направлений явно. Большинство проблем с «почему не доступно» в AWS — именно из-за неправильно настроенных NACL. Понимание разницы критически важно: по статистике, 80% инцидентов связаны с неверной конфигурацией NACL.

Основные отличия сведены в таблицу:

Согласно документации AWS, Security Group — первый рубеж, NACL — второй. Однако на практике многие ограничиваются только Security Groups.

Как автоматизировать управление правилами с помощью Terraform?

Использование Infrastructure as Code (Terraform) в 3 раза ускоряет внесение изменений по сравнению с ручным конфигурированием через консоль. Terraform-код позволяет версионировать правила и проводить код-ревью.

Пример корректной структуры Security Group:

resource "aws_security_group" "web" {
  name = "web-tier"
  description = "HTTP/HTTPS from internet"
  vpc_id = var.vpc_id

  ingress {
    from_port = 443
    to_port = 443
    protocol = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port = 80
    to_port = 80
    protocol = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port = 0
    to_port = 0
    protocol = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_security_group" "app" {
  name = "app-tier"
  description = "Traffic from web tier only"
  vpc_id = var.vpc_id

  ingress {
    from_port = 8080
    to_port = 8080
    protocol = "tcp"
    security_groups = [aws_security_group.web.id] # ссылка на SG, не CIDR
  }
}

Ссылка security_groups = [sg-id] вместо CIDR — ключевой паттерн. При масштабировании web-tier новые инстансы автоматически получают доступ к app-tier без ручного обновления правил.

NACL: когда без них не обойтись

NACL нужны в двух случаях: явный deny для конкретных IP (Security Group не умеет deny — только allow), и дополнительный барьер на уровне subnet.

Пример Terraform-кода для NACL:

resource "aws_network_acl" "private" {
  vpc_id = var.vpc_id
  subnet_ids = var.private_subnet_ids

  # Блокируем подозрительный IP явно
  ingress {
    rule_no = 90
    protocol = "-1"
    action = "deny"
    cidr_block = "198.51.100.0/24"
    from_port = 0
    to_port = 0
  }

  # Разрешаем из VPC
  ingress {
    rule_no = 100
    protocol = "tcp"
    action = "allow"
    cidr_block = var.vpc_cidr
    from_port = 0
    to_port = 65535
  }

  # Ephemeral ports для stateless NACL (обязательно!)
  egress {
    rule_no = 100
    protocol = "tcp"
    action = "allow"
    cidr_block = "0.0.0.0/0"
    from_port = 1024
    to_port = 65535
  }
}

Сравнение облачных провайдеров

В GCP нет NACL — всё через Firewall Rules на уровне VPC. Важная особенность: правила применяются по тегам инстансов или сервисным аккаунтам, не по subnet:

resource "google_compute_firewall" "allow_internal_app" {
  name = "allow-app-from-web"
  network = var.network_name
  allow {
    protocol = "tcp"
    ports = ["8080"]
  }
  source_tags = ["web-tier"]
  target_tags = ["app-tier"]
}

resource "google_compute_firewall" "deny_all_ingress" {
  name = "deny-all-ingress"
  network = var.network_name
  direction = "INGRESS"
  priority = 65534
  deny {
    protocol = "all"
  }
  source_ranges = ["0.0.0.0/0"]
}

В Azure NSG можно привязать как к subnet, так и к NIC напрямую. Аугменация сервисными тегами (AzureLoadBalancer, VirtualNetwork) упрощает правила:

resource "azurerm_network_security_rule" "allow_lb" {
  name                        = "allow-azure-lb"
  priority                    = 100
  direction                   = "Inbound"
  access                      = "Allow"
  protocol                    = "Tcp"
  source_port_range           = "*"
  destination_port_range      = "443"
  source_address_prefix       = "AzureLoadBalancer"
  destination_address_prefix  = "*"
  resource_group_name         = var.rg_name
  network_security_group_name = azurerm_network_security_group.app.name
}

Типичные ошибки при настройке

• Открытый порт 0–65535 для 0.0.0.0/0 в outbound Security Group — встречается почти везде. Теоретически разрешает любые исходящие подключения с инстанса, включая exfiltration данных. На практике ограничивают outbound только там, где это оправдано сложностью управления.
• Дублирующие правила в NACL с разными rule_no — NACL обрабатывает правила по номеру, первое совпадение применяется. Правило 90 с deny перекрывает правило 100 с allow для того же CIDR.
• Использование CIDR вместо ссылок на Security Groups — при масштабировании требует ручных правок.

Что входит в работу

• Аудит текущих правил — определяем неиспользуемые, избыточные и опасные правила. Выдаём отчёт с детальными рекомендациями.
• Проектирование новой конфигурации — используем Terraform для декларативного описания всех Security Groups и NACLs. Все изменения проходят код-ревью.
• Документация — схема сети с указанием всех правил, описание исключений и обоснование.
• Обучение команды — как поддерживать правила через IaC, что делать при добавлении нового микросервиса.

Процесс работы

1. Аналитика — собираем текущую схему сети, правила файрволов, списки комплаенс-требований. Выявляем критические уязвимости.
2. Проектирование — разрабатываем целевую архитектуру с использованием принципа минимального доступа. Определяем, какие правила можно объединить, где нужны NACL.
3. Реализация — пишем Terraform-код, создаём pull-request, проводим code review. Разворачиваем сначала в staging-окружении.
4. Тестирование — проверяем связность между сервисами, убеждаемся, что легитимный трафик не блокируется. Используем тестовые сценарии.
5. Деплой в production — применяем изменения по расписанию, мониторим ошибки через CloudWatch / Stackdriver.

Сроки

Аудит и настройка Security Groups для типичного трёхзвенного приложения (web/app/db) в одном облаке — 1–2 дня. Multi-cloud или сложная микросервисная архитектура с десятками Security Groups — 3–5 дней. Инвестиции в аудит и настройку обычно окупаются за счет предотвращения инцидентов: средняя стоимость утечки данных составляет $4.35 млн по данным IBM. Стоимость рассчитывается индивидуально после анализа текущей архитектуры.

За годы работы мы выполнили более 50 проектов по облачной безопасности. Сертифицированные инженеры AWS и Azure гарантируют, что ваша сеть будет защищена по лучшим практикам. Получите анализ текущих правил безопасности. Свяжитесь с нами для аудита вашей облачной инфраструктуры. Закажите консультацию DevOps-инженера прямо сейчас.