Налаштування хмарного фаєрвола: Security Groups та NACLs

Налаштування хмарного фаєрвола: 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]
  }
}

Посилання 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

  ingress {
    rule_no = 90
    protocol = "-1"
    action = "deny"
    cidr_block = "198.51.100.0/24"
    from_port = 0
    to_port = 0
  }

  ingress {
    rule_no = 100
    protocol = "tcp"
    action = "allow"
    cidr_block = var.vpc_cidr
    from_port = 0
    to_port = 65535
  }

  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-інженера прямо зараз.