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 выводите через приватные каналы либо жестко контролируемый прокси.