Private endpoints і внутрішні мережі

1) Навіщо приватна мережа

• ізоляцію PaaS/DB/сховищ від публічних IP;
• спрощення відповідності (PCI DSS/GDPR);
• передбачувані затримки і маршрутизацію.

2) Базова модель: VPC/VNet і хаби

Адресний простір: єдиний план CIDR, без перетинів (наприклад,'10. 0. 0. 0/12'розрізається по оточеннях і хабах).
Сегментація: підмережі'ingress','app','data','ops','shared'з окремими маршрутами/ACL/SG.
Транзитний хаб: центральний VPC/VNet зі шлюзами (VPN/DirectConnect/ExpressRoute/Interconnect), між-VPC peering/Transit Gateway і мережевими фаєрволами.
Dual-stack: планування IPv6 заздалегідь (економить NAT, покращує масштаб адрес).

3) Private endpoints: принципи

• Трафік йде всередині провайдерської мережі (не через інтернет).
• Endpoint policy обмежує, куди можна ходити (префікси/ARN/ресурси).
• DNS перевизначається на приватні IP (див. § 6).

Типові цілі: об'єктні стори (S3/GCS/Blob), secret/KMS, черги, шини подій, керовані БД, аналітичні сервіси, артефакт-регістри.

4) Вхід і балансування всередині

Internal Load Balancer (ILB) для L4/7, бачимо тільки з приватних підмереж.

• 'Service'типу'LoadBalancer'з internal-анотаціями.
• Вхід через Internal Ingress (Nginx/Contour/Gateway API) на приватній адресі.
• API Gateway (private): приватна інтеграція до бекендів; назовні - тільки через edge, якщо потрібно.

Приклад: K8s Ingress як внутрішній

yaml apiVersion: networking. k8s. io/v1 kind: Ingress metadata:
name: api-internal annotations:
kubernetes. io/ingress. class: "nginx"
alb. ingress. kubernetes. io/scheme: internal # or provider equivalent spec:
rules:
- host: api. internal. corp http:
paths:
- path: /v1/
pathType: Prefix backend:
service:
name: api port: { number: 8080 }

5) Egress-контур: «за замовчуванням - deny»

• NAT Gateway (для апдейтів/репозиторіїв) + egress allowlist по FQDN/IP;
• TLS інспекція/проксі, якщо політики вимагають контролю;
• Private endpoints до PaaS/регістрів замість NAT.
• SG/NACL: явні дозволи per-сервіс, «на схід-захід» - мінімум.
• Egress-політики K8s (CNI/OPA Gatekeeper/Calico NetworkPolicy) - заборона зовнішніх IP, дозволу на кластери/ендпойнти.

6) DNS: split-horizon и private zones

Розділіть внутрішні зони ('.internal. corp') і публічні.
Private DNS zones для сервісів провайдера: перевизначають публічні імена (наприклад,'bucket. s3. region. amazonaws. com') на приватні A/AAAA-записи.
Forwarders/Conditional DNS между on-prem ↔ cloud.
Формат імен: інкапсулюйте оточення/регіон ('api. eu1. internal. corp'), уникайте PII.

api. internal. corp. A  10. 20. 30. 40 s3. bucket. corp. A  10. 100. 0. 25 # via private endpoint

7) Патерни міжмережевих зв'язків

Peering (VPC↔VPC/VNet↔VNet): простий і швидкий; транзит не завжди підтримується → використовуйте Transit Gateway/Virtual WAN/Cloud Router для зірки (hub-and-spoke).
On-prem ⇄ cloud: IPsec VPN для старту, потім виділена лінія (DC/ER/IC) з BGP і резервом (два провайдера, різні точки входу).
Сегментація VRF/Route-domain: ізоляція prod/stage/dev і карткового периметра.

8) Zero Trust і внутрішня автентифікація

mTLS за замовчуванням (service mesh: Istio/Linkerd/Consul), машинна ідентичність: SPIFFE/SPIRE.
Політики L7: авторизація за JWT/claims/scopes, обмеження маршрутів/методів на рівні проксі.
Secrets: HashiCorp Vault/КMS + External Secrets Operator; короткоживучі креденшели (STS).
Bastion/Privileged Access: доступ в приватку тільки через брокер/JIT-сесію (MFA, запис команд).

Приклад: Envoy фільтр mTLS + JWT-authz (фрагмент)

yaml transport_socket:
name: tls typed_config: {... spiffe://svc. api... }
http_filters:
- name: envoy. filters. http. jwt_authn typed_config:
providers:
oidc: { issuer: https://idp. corp, audiences: ["api"], remote_jwks: {...} }
rules: [{ match: { prefix: "/v1" }, requires: { provider_name: oidc } }]

9) Дані і PaaS всередині приватки

Бази/кластери: тільки приватні адреси; адмінка через bastion/JIT.
Сховища: доступ з VPC по private endpoint; endpoint policy дозволяє тільки потрібні бакети/контейнери.
Черги/шини: приватні інтерфейси; продьюсери/консьюмери - в тому ж VPC/peering.
Регістри артефактів: приватний доступ з CI/CD runners в приватних підмережах.

10) Спостережуваність в приватних мережах

OpenTelemetry Collector - як шлюз телеметрії: внутрішні експортери в self-hosted (Prometheus/Tempo/Loki/ClickHouse) або в керовані backends по private endpoints.
Flow logs/NSG/NACL logs і reachability analyzer - обов'язкові.
SLO-зрізи: 'site/region/vpc/subnet', алерти на витік egress і несподіваний «інтернет-напрямок».

11) Тестування та верифікація

Policy as Code (OPA/Gatekeeper) для мережевих правил/Ingress/Service.
Canary-маршрути: тестові домени в private DNS, synthetic-перевірки з різних підмереж/AZ/регіонів.
Chaos-мережа: затримки/втрати в між-VPC/меж-AZ (netem/Toxiproxy), перевірки таймаутів і retry-політик.

12) Приклади конфігурацій

12. 1 Terraform: мітки та маршрути (ідея)

hcl resource "aws_route_table" "app" {
vpc_id = aws_vpc. core. id tags = { Name = "rt-app", env = var. env, zone = "private" }
}
Route on PrivateLink endpoint (interface endpoint is created separately)
resource "aws_vpc_endpoint_route_table_association" "s3" {
route_table_id = aws_route_table. app. id vpc_endpoint_id = aws_vpc_endpoint. s3. id
}

12. 2 K8s NetworkPolicy: заборона всього, крім потрібного

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

12. 3 Nginx Ingress (internal scheme) + HSTS

yaml metadata:
annotations:
alb. ingress. kubernetes. io/scheme: internal nginx. ingress. kubernetes. io/hsts: "true"

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

Загальний «management-інтернет» з приватних підмереж; відсутність egress-контролю.
Спліт-брейн DNS і випадкові ручні '/etc/hosts'.
Перетинаються CIDR і «NAT-матрьошки».
Публічні endpoint'и для БД/сховищ «заради зручності».
Відсутність логів потоків/аудиту правил; «відкриті» SG'0. 0. 0. 0/0`.
Довгоживучі статичні ключі доступу в коді/CI.

14) Вартість і продуктивність

Private endpoints часто дешевше постійного NAT egress і безпечніше.
Плануйте NAT-кластери/az-local для пропускної здатності, щоб не створити bottleneck.
Кеш/edge і SWR зменшують крос-регіональний трафік.
Вибір протоколів: HTTP/2/gRPC всередині → менше з'єднань і TLS-оверхаеда.

15) Специфіка iGaming/фінансів

PCI DSS: картковий контур (CDE) в окремій мережі/VRF, ніякого інтернету; доступ до стора/PSP-логів тільки за private endpoints; незмінні аудити (WORM/Object Lock).
KMS/Vault: ключі сегментовані per регіон/бренд; операції підпису (HSM) доступні тільки з CDE по mTLS.
PSP/KYC: якщо є private connectivity/маркети - використовуйте; інакше - egress через довірений проксі з HMAC/mTLS і явною allowlist.
Мульти-тенантність: теги і політики по'tenant '/' brand'; окремі private DNS-імена та SG-шари.

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

• План CIDR без перетинів; dual-stack готовий (IPv6).
• Hub-and-Spoke, Transit, peering; on-prem ⇄ cloud - BGP, резервні лінк-пари.
• Всі PaaS/сховища/БД - через private endpoints + endpoint policies.
• Internal LB/Ingress; публічний периметр - тільки на edge/WAF.
• Split-horizon DNS, private zones і conditional-forwarding налаштовані.
• Egress за замовчуванням «deny»; NAT/проксі обмежені і журналюються.
• Mesh mTLS + SPIFFE; JWT-authz на L7; Vault/ESO, короткі секрети.
• NetworkPolicy/SG/NACL - «мінімально необхідне», flow-logs і reachability-аналіз.
• OTel Collector всередині; алерти на витік egress, SLO по'site/region/vpc'.
• PCI/аудит: WORM-журнали, KMS/HSM, ізоляція CDE, runbook доступу.

17) TL; DR

Будуйте мережу за схемою hub-and-spoke з чітким CIDR-планом, використовуйте private endpoints до кожного PaaS/сховища/БД, а трафік назовні - тільки через керовані egress-точки. Всередині - internal LB/Ingress, mTLS + SPIFFE, split-horizon DNS, строгі NetworkPolicy/SG і телеметрія через OTel. Для iGaming/фінансів додайте PCI-сегментацію, KMS/Vault і незмінний аудит; PSP/KYC виводите через приватні канали або жорстко контрольований проксі.