Защита: Network Policies (Egress)

Исходящая сетевая политика (Egress Network Policy) — это, по сути, файрвол, который жестко ограничивает список адресов, к которым ваше приложение или база данных могут обращаться. Это критически важный элемент защиты, особенно в средах Kubernetes и Docker. Правильно настроенная политика гарантирует, что даже в случае успешной OOB-инъекции данные физически не смогут покинуть защищенный периметр.

Концепция zero trust networking, активно продвигаемая Google в их BeyondCorp архитектуре и формализованная в NIST SP 800-207 «Zero Trust Architecture», переворачивает традиционную модель «защищённый периметр vs внешний мир». В zero trust каждое соединение между сервисами должно быть явно разрешено: implicit deny по умолчанию. Применительно к базе данных это означает простую вещь: postgres-pod не должен иметь возможности открыть TCP-соединение к 8.8.8.8, ввести DNS-запрос на attacker.com или обратиться к S3-bucket'у, который не упоминается в утверждённом списке. Каждое разрешённое исключение требует явной декларации в NetworkPolicy.

Аналогия: представь крепостную стену с воротами. Старый подход — «впусти всех, у кого нет на лбу штампа enemy». Атакующий, который смог снять штамп, проходит свободно. Новый подход — «не впускай никого, пока я не увижу у него штамп ally от своего командира». Любой без штампа — отказ, независимо от того, выглядит он подозрительно или нет. Network Policy с пустым egress-списком — это та самая стена без ворот: ни один пакет не выходит наружу, даже если приложение очень хочет «позвонить домой».

Разберем, как возвести «железный занавес» вокруг базы данных.

---

1. Механика: "Изоляция базы данных"

Фундаментальное правило безопасности: сервер СУБД (PostgreSQL, MySQL) должен иметь доступ в интернет только в исключительных случаях. Минимальный allowlist обычно включает: DNS-сервер кластера (для резолвинга имён внутренних сервисов), backup-target (S3-bucket или PostgreSQL replica), мониторинг (Prometheus pull endpoint, log aggregator). Всё остальное — deny по умолчанию.

Пример политики Kubernetes (NetworkPolicy):

# ✅ БЕЗОПАСНАЯ ПОЛИТИКА: Исходящий трафик в интернет полностью запрещен
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-egress-deny
spec:
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Egress
  # Пустой список egress означает полный запрет любого исходящего трафика
  egress: []

При такой настройке любая попытка базы данных выполнить nslookup или curl во внешнюю сеть будет мгновенно заблокирована сетевым фильтром.

NetworkPolicy в Kubernetes реализуется CNI-плагином (Cilium, Calico, Weave Net) — это сетевой драйвер, который применяет правила прямо на уровне network stack узла. Когда pod пытается отправить пакет наружу, eBPF-программа (в случае Cilium) или iptables-правила (в случае Calico) проверяют match'ит ли destination разрешённые селекторы. Если нет — пакет дропается на уровне ядра, и приложение получает «connection refused» или TCP RST. Это блокировка на L3/L4, поэтому даже обход HTTP-фильтра через нестандартный порт не помогает атакующему.

---

2. Эшелонированная оборона (Defense in Depth)

Сетевая безопасность — это обязательный запасной рубеж на случай провала других защитных мер.

Уровень защиты	Инструмент	Что блокирует?
Код (Go)	Prepared Statements	Саму возможность инъекции
Сеть (K8s)	Egress Deny	Утечку данных по DNS/HTTP
БД (User)	Least Privilege	Запуск опасных функций (например, pg_read_file)

---

3. Локальная защита в Docker-compose

Ограничить сетевую активность можно и в простых средах разработки:

# ✅ Внутренняя сеть Docker без шлюза во внешний мир
networks:
  db_network:
    internal: true

Это простое действие гарантирует, что контейнер с PostgreSQL сможет «общаться» только с вашим Go-приложением в рамках одной сети, лишая хакера возможности отправить данные на свой сервер.

Для production-окружений в облаке: AWS Security Groups, GCP Firewall Rules, Azure NSGs выполняют аналогичную роль. AWS Security Group на уровне ENI базы данных можно настроить с пустым egress правилом — все исходящие соединения, кроме явно разрешённых (например, к RDS endpoint для backup или к VPC Endpoint S3), будут блокированы. AWS Network Firewall и Cloud NGFW от Google добавляют L7-инспекцию, которая может детектить DNS-tunneling даже когда DNS-сервер находится внутри разрешённой подсети.

---

4. Почему "Egress Deny" обязателен

Злоумышленники постоянно изобретают новые способы заставить программное обеспечение «звонить домой». Сетевая изоляция — это ваша страховка. Она не исправляет уязвимость в коде, но делает её последствия гораздо менее катастрофическими, предотвращая кражу данных.

---

Сетевые политики — это ваш последний рубеж обороны. Они лишают хакера главного — секретного канала связи, превращая успешную инъекцию в бесполезную попытку достучаться до закрытой двери.

Соответствие стандартам: PCI-DSS 1.3 «Implement a DMZ to limit inbound traffic» и 1.3.4 «Do not allow internal addresses to pass from the Internet into the DMZ»; NIST SP 800-207 Zero Trust Architecture; ISO 27001 Annex A.13.1 «Network security management»; CIS Controls v8 control 12 «Network Infrastructure Management». Аудиторы PCI ожидают увидеть документированные network policies и доказательства того, что нарушения детектятся через мониторинг (например, alerting на любой dropped packet с егресс БД-pod).

Мы завершили изучение OOB-эксфильтрации. После квиза мы перейдем к финальному разделу курса — методам обхода фильтров и систем защиты WAF.