Firewall политики и ACL

1) Цели и принципы

• Least privilege: разрешать только необходимое (явные allow, implicit deny).
• Segmentation: изоляция окружений (prod/stage/dev), тенантов, критичных контуров (PCI/KMS/DB).
• Egress-контроль: исходящий трафик ограничен списками FQDN/IP и приватными endpoint’ами.
• Identity-aware (L7): решения принимаются по аутентифицированной сущности (SPIFFE/OIDC), а не только по IP.
• Infrastructure as Code: правила как код, review/CI/CD, аудит изменений.

2) Таксономия: где и что фильтруем

2.1 Слои и состояние

L3/L4 stateless: классические ACL (CIDR, протокол, порт).
L3/L4 stateful: security groups/NSG, отслеживают соединения.
L7-aware: proxy/WAF/mesh RBAC (методы, пути, JWT-claims, SNI).
Inline vs out-of-band: инлайн-фаервол маршрутизирует трафик; out-of-band — анализ/alert.

2.2 Контуры

Perimeter: edge/WAF/Anti-DDoS.
Core: transit hub / меж-VPC/VNet.
Workload: SG/NSG на VM/ENI/POD.
App-level: Envoy/Istio/NGINX policy, service-to-service mTLS.

3) Облачные модели

AWS

Security Group (SG): stateful на ENI/instance/LB.
Network ACL (NACL): stateless на подсети, порядок правил, двунаправленные записи.
AWS Network Firewall/GWLB: L7 инспекция/IDS.
Рекомендация: «SG — основной контроль, NACL — крупнозернистое ограждение/deny-лист».

Azure

NSG (stateful), ASG (группы приложений по тегам), Azure FW для L7/IDS, Private Endpoints.
Рекомендация: NSG на сабнет + NIC, теги сервисов через ASG.

GCP

VPC Firewall Rules (stateful), Hierarchical FW (организационные/папочные), Cloud Armor (L7), Private Service Connect.
Рекомендация: org-level guardrails + проектные allow.

4) Дизайн правил: паттерны

4.1 Базовые наборы

Deny all egress → разрешаем по FQDN/IP к: пакетным репозиториям, артефакт-регистрам, сторонним API (через приватные/фиксированные выходы).
East-West минимум: сервисы общаются только с необходимыми зависимостями.
Admin доступ: через bastion/JIT с MFA, запись сессий.

4.2 Тэги и группы

Используйте labels/tags вместо IP: `env`, `service`, `tier`, `tenant`, `pci=true`.
Обновление политики при изменении тега — без ручного редактирования IP-сеток.

4.3 Жизненный цикл

Propose → Evaluate (staging) → Enforce (prod), с dry-run/логами попаданий.
Устаревание: TTL/owner для каждого правила, автопроверка неиспользуемых.

5) Kubernetes и сервис-меш

5.1 NetworkPolicy (L3/L4)

Минимум — «запретить все, кроме нужного».

yaml apiVersion: networking. k8s. io/v1 kind: NetworkPolicy metadata: { name: deny-all, namespace: core }
spec:
podSelector: {}
policyTypes: ["Ingress","Egress"]
kind: NetworkPolicy metadata: { name: api-egress }
spec:
podSelector: { matchLabels: { app: api } }
egress:
- to:
- namespaceSelector: { matchLabels: { ns: db } }
ports: [{ protocol: TCP, port: 5432 }]
- to:
- ipBlock: { cidr: 10. 100. 0. 0/16 } # Private endpoints ports: [{ protocol: TCP, port: 443 }]

5.2 L7 RBAC в mesh (Istio/Envoy)

mTLS + авторизация по JWT/claims/scopes/paths.

yaml apiVersion: security. istio. io/v1 kind: AuthorizationPolicy metadata: { name: api-rbac }
spec:
selector: { matchLabels: { app: api } }
rules:
- from:
- source:
principals: ["spiffe://svc. payments"]
to:
- operation: { methods: ["POST"], paths: ["/v1/payouts"] }
when:
- key: request. headers[x-tenant]
values: ["eu-1","eu-2"]

6) Egress-контроль и приватные периметры

Предпочитайте PrivateLink/Private Service Connect к PaaS/регистрам/хранилищам.
Остальной egress через NAT/прокси с allowlist FQDN и фиксированными IP (для сторонних allowlist).
Блокируйте прямой выход подов/VM в интернет; исключения только через egress-шлюз.

7) DNS и SNI-осознанные правила

Split-horizon: внутренние зоны не резолвятся снаружи.
FW/Proxy c поддержкой FQDN/SNI для исходящих HTTPS (SNI allow).
Зафиксируйте pinning на конкретные домены поставщиков; мониторьте изменения их IP.

8) Логи, аудит, наблюдаемость

Включите flow logs (VPC/VNet/NSG/NACL), отправляйте в SIEM.
Коррелируйте с приложениями через `trace_id` в логах.
Метрики: hit/miss правил, top-talkers, drop-rates, асимметрия трафика, «утечки egress».
Отчеты: «неиспользуемые правила», «самые широкие разрешения».

9) Управление как кодом (IaC) и проверки

Terraform/CloudFormation + модульные политики по шаблонам.
Policy as Code (OPA/Gatekeeper/Conftest): запрет на `0.0.0.0/0`, требование `description/owner/ttl`, запрет смешивания prod/dev.
CI: линт, статанализ, симуляторы достижимости (reachability analyzer), план-просмотр, мандатное peer review.

10) Тестирование достижимости и хаос

Synthetic-пробы из разных подсетей/AZ/регионов: TCP/443, специфичные порты БД/брокеров.
Временной deny для проверки DR-путей: отключение зависимости → должны сработать retries/circuit/fallback.
MTU/MSS: убедитесь в отсутствии фрагментации на perimeters (особенно IPsec/NAT-T).

11) Производительность и надежность

Избегайте централизованного узкого места: горизонтально масштабируйте inline-FW (GWLB/scale sets).
ECMP/AS-path/BGP для распределения между хабами.
Профили TLS-инспекции: включать точечно (дорого), хранить отпечатки ключей отдельно, соблюдать комплаенс.

12) Примеры конфигов (референсы, укороченные)

12.1 AWS SG: API → Postgres + S3 PrivateLink

hcl resource "aws_security_group" "api" {
name    = "sg-api"
description = "Ingress from ALB, egress to DB and PrivateLink"
vpc_id   = var. vpc_id

ingress { from_port=8080 to_port=8080 protocol="tcp" security_groups=[aws_security_group. alb. id] }
egress { from_port=5432 to_port=5432 protocol="tcp" security_groups=[aws_security_group. db. id] }
egress { from_port=443 to_port=443 protocol="tcp" prefix_list_ids=[aws_vpc_endpoint. s3. prefix_list_id] }
tags = { owner="team-api", env=var. env, ttl="2026-01-01" }
}

12.2 Azure NSG: deny-by-default + allow bastion

bash az network nsg rule create -g rg -n allow-bastion --nsg-name nsg-app \
--priority 100 --direction Inbound --access Allow --protocol Tcp \
--source-address-prefixes 10. 0. 0. 10 --source-port-ranges "" \
--destination-port-ranges 22 --destination-address-prefixes 10. 1. 0. 0/16

12.3 GCP hierarchical firewall: org-guardrail

yaml direction: INGRESS priority: 1000 action: deny enableLogging: true match:
layer4Configs: [{ ipProtocol: "all" }]
srcIpRanges: ["0. 0. 0. 0/0"]
targetResources: ["organizations/123456"]

12.4 Envoy RBAC (L7 allow)

yaml
- name: envoy. filters. http. rbac typed_config:
rules:
action: ALLOW policies:
payments-post:
permissions: [{ url_path: { path: "/v1/payouts", ignore_case: true } }]
principals: [{ authenticated: { principal_name: { exact: "spiffe://svc. payments" } } }]

13) Антипаттерны

`0.0.0.0/0` в ingress/egress «временно» → остается навсегда.
«Снежинки» (ручные правки в консоли) без кода и ревизии.
Общие SG/NSG для prod/stage/dev; смешение критичных и некритичных подсетей.
Отсутствие egress-контроля и приватных endpoint’ов → утечки ключей/секретов наружу.
Игнорирование DNS/SNI: разрешили IP поставщика — завтра он сменился и открылся весь диапазон.
Нет flow logs и runbook’ов → форензика невозможна.

14) Специфика iGaming/финансов (PCI/регуляторика)

PCI CDE в отдельном VRF/сегменте, никакого интернета; доступ к PSP/логам — через private connectivity/прокси с mTLS и HMAC.
Data residency: PII/платежные события — внутри страны/региона; межрегионально — только агрегаты/аноним.
KMS/Vault/HSM: отдельные подсети/SG, только mTLS-клиенты с короткими сертификатами.
WORM-аудит: логи FW/flow в неизменяемом хранилище (Object Lock), ретеншн ≥ регуляторного минимума.
Партнеры (PSP/KYC): FQDN allowlist, статичные egress IP, мониторинг SLA по провайдерам.

15) Чек-лист prod-готовности

• Единая модель сегментации (hub-and-spoke, VRF), CIDR без пересечений.
• Deny-by-default на egress; приватные endpoints к PaaS/хранилищам.
• SG/NSG stateful для workload, NACL/route-filters — на подсети/хабы.
• K8s: NetworkPolicy «deny-all», mesh mTLS + L7 RBAC.
• Теги/группы вместо IP; owner/TTL/description у каждого правила.
• IaC + Policy-as-Code; CI с симуляцией достижимости; обязательный peer review.
• Flow logs включены; дашборды top-talkers, drop-rates; алерты на «утечку egress».
• Bastion/JIT для админ-доступа; MFA; журналирование сессий.
• Runbook’и: как добавлять/снимать правило, как работать при инциденте; регулярные ревизии «мертвых» правил.
• Для PCI/финансов: изоляция CDE, WORM-аудит, FQDN-allow для PSP/KYC, статичные egress IP.

16) TL;DR

Стройте защиту по слоям: SG/NSG stateful на ворклоадах, NACL/route-filters на подсетях, L7 RBAC в mesh/прокси, WAF/edge на периметре. По умолчанию — deny-by-default, egress только через контролируемые точки или private endpoints. Описывайте правила как код, проверяйте их политиками и симуляторами достижимости, собирайте flow-логи. Для iGaming/финансов добавьте PCI-сегментацию, WORM-аудит и строгий FQDN-allow к PSP/KYC.