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.