Endpoints privados y redes internas

1) Por qué una red privada

• Aislamiento de PaaS/DB/repositorios de IP públicas;
• simplificación de la conformidad (PCI DSS/GDPR);
• retrasos y enrutamiento predecibles.

2) Modelo básico: VPC/VNet y hubs

Espacio de direcciones: un único plan CIDR, sin intersecciones (por ejemplo, '10. 0. 0. 0/12 'se corta por los alrededores y los centros).
Segmentación: subredes 'ingress',' app ',' data ',' ops', 'shared' con rutas separadas/ACL/SG.
Hub de tránsito: VPC/VNet central con pasarelas (VPN/DirectConnect/ExpressRoute/Interconnect), peering/Transit Gateway entre VPC y faervoles de red.
Dual-stack: planificación de IPv6 de antemano (ahorra NAT, mejora la escala de direcciones).

3) Private endpoints: principios

• El tráfico fluye dentro de la red de proveedores (no a través de Internet).
• La política de Endpoint limita a dónde se puede ir (prefijos/ARN/recursos).
• El DNS se redefine como IP privada (ver § 6).

Objetivos típicos: S3/GCS/Blob, secret/KMS, colas, bus de eventos, DAB administrado, servicios analíticos, registros de artefactos.

4) Entrada y equilibrio en el interior

Internal Load Balancer (ILB) para L4/7, sólo visto desde subredes privadas.

• 'Service' de tipo 'LoadBalancer' con anotaciones internas.
• Iniciar sesión a través de Internal Ingress (Nginx/Contour/Gateway API) en una dirección privada.
• API Gateway (private): integración privada con backends; hacia afuera - sólo a través de edge, si es necesario.

Ejemplo: K8s Ingress como interno

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-contorno: «por defecto - deny»

• NAT Gateway (para apdates/repositorios) + egress allowlist por FQDN/IP;
• Inspección TLS/proxy si las políticas requieren control;
• Private endpoints a PaaS/registro en lugar de NAT.
• SG/NACL: permisos explícitos por servicio, «al este-oeste» - mínimo.
• Política de egresos de K8s (CNI/OPA Gatekeeper/Calico NetworkPolicy) - prohibición de IPs externas, permisos de clusters/endpoints.

6) DNS: split-horizon и private zones

Separe las zonas interiores ('.internal. corp ') y público.
Zonas DNS privadas para los servicios del proveedor: redefinen los nombres públicos (por ejemplo, 'bucket. s3. region. amazonaws. com ') en registros privados A/AAAA.
Forwarders/Conditional DNS между on-prem ↔ cloud.
Formato de nombres: encapsula el entorno/región ('api. eu1. internal. corp '), evitar PII.

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

7) Patrones de interconexión

Peering (VPC↔VPC/VNet↔VNet): simple y rápido; el tránsito no siempre es compatible → utilice Transit Gateway/Virtual WAN/Cloud Router para la estrella (hub-and-spoke).
On-prem ⇄ cloud: IPsec VPN para iniciar, luego una línea dedicada (DC/ER/IC) con BGP y reserva (dos proveedores, diferentes puntos de entrada).
Segmentación VRF/Route-domain: aislamiento prod/stage/dev y perímetro de tarjetas.

8) Confianza cero y autenticación interna

mTLS-por defecto (mesh de servicio: Istio/Linkerd/Consul), identidad de máquina: SPIFFE/SPIRE.
Políticas L7: autorización por JWT/claims/scopes, restricción de rutas/métodos a nivel proxy.
Secrets: HashiCorp Vault/КMS + External Secrets Operator; créditos de vida corta (STS).
Bastion/Privileged Access: acceso a Private sólo a través de una sesión de broker/JIT (MFA, grabación de comandos).

Ejemplo: Envoy filtro mTLS + JWT-authz (fragmento)

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) Datos y PaaS dentro del paquete

Bases/clústeres: sólo direcciones privadas; admin vía bastion/JIT.
Almacenamiento: acceso desde VPC a través de un extremo privado; la política de endpoint sólo permite los baquetas/contenedores deseados.
Colas/bus: interfaces privadas; productores/consumidores - en el mismo VPC/peering.
Registros de artefactos: acceso privado desde CI/CD runners en subredes privadas.

10) Observabilidad en redes privadas

OpenTelemetry Collector - como puerta de enlace de telemetría: exportadores internos en self-hosted (Prometheus/Tempo/Loki/ClickHouse) o en backends administrados por private endpoints.
Flow logs/NSG/NACL logs y reachability analyzer - son obligatorios.
Cortes de SLO: 'site/region/vpc/subnet', alertas a la fuga de egresos y una inesperada 'dirección de Internet'.

11) Pruebas y verificación

Policy as Code (OPA/Gatekeeper) para reglas de red/Ingress/Service.
Rutas canarias: dominios de prueba en DNS privado, comprobaciones synthetic de diferentes subredes/AZ/regiones.
Chaos-network: retrasos/pérdidas en el intervalo entre VPC/AZ (netem/Toxiproxy), comprobaciones de temporizadores y políticas retry.

12) Ejemplos de configuraciones

12. 1 Terraform: etiquetas y rutas (idea)

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: prohibir todo lo que no sea necesario

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) Antipatternas

El «management-internet» común de las subredes privadas; sin control de egresos.
Divisor DNS y manual aleatorio '/etc/hosts'.
Cruzando CIDR y «MAT-matres».
Public endpoint's para DB/repositorios «por conveniencia».
Ausencia de registros de flujo/auditoría de reglas; «abierto» SG '0. 0. 0. 0/0`.
Llaves de acceso estático de larga vida en código/CI.

14) Costo y rendimiento

Private endpoints son a menudo más baratos que el constante NAT egress y más seguros.
Planifique los clústeres NAT/az-local para que el ancho de banda no cree bottleneck.
El caché/edge y el SWR reducen el tráfico regional cruzado.
Selección de protocolos: HTTP/2/gRPC dentro de → hay menos conexiones y overhaed TLS.

15) Especificidad de iGaming/finanzas

PCI DSS: circuito de tarjetas (CDE) en una red/VRF separada, sin Internet; el acceso a los logs sor/PSP sólo por medio de puntos de acceso privados; auditorías sin cambios (WORM/Object Lock).
KMS/Vault: claves segmentadas por región/marca; las operaciones de firma (HSM) sólo están disponibles desde CDE por mTLS.
PSP/KYC: si hay conexión privada/markets - use; de lo contrario, egresa a través de un proxy de confianza con HMAC/mTLS y un allowlist explícito.
Multi-tenencia: etiquetas y políticas por 'tenant '/' brand'; nombres DNS privados individuales y capas SG.

16) Lista de comprobación prod

• Plan CIDR sin intersecciones; dual-stack listo (IPv6).
• Hub-and-Spoke, Transit, peering; on-prem ⇄ cloud - BGP, pares de enlaces de respaldo.
• Todos los PaaS/repositorios/DB - a través de private endpoints + endpoint policies.
• Internal LB/Ingress; perímetro público - sólo en edge/WAF.
• Split-horizon DNS, zonas privadas y conditional-forwarding están configurados.
• El resultado predeterminado es «deny»; NAT/proxy están restringidos y registrados.
• Mesh mTLS + SPIFFE; JWT-authz en L7; Vault/ESO, secretos cortos.
• NetworkPolicy/SG/NACL - «mínimo necesario», flow-logs y reachability-análisis.
• OTel Coleccionista dentro; alertas a la fuga egress, SLO por 'site/region/vpc'.
• PCI/auditoría: registros WORM, KMS/HSM, aislamiento CDE, acceso runbook.

17) TL; DR

Construya la red de acuerdo con el esquema hub-and-spoke con un plan CIDR claro, use puntos de acceso privados para cada PaaS/almacenamiento/BD, y el tráfico hacia afuera sólo a través de puntos de control egress. Internal LB/Ingress, mTLS + SPIFFE, split-horizon DNS, estrictos NetworkPolicy/SG y telemetría a través de OTel. Para iGaming/finanzas, agregue segmentación PCI, KMS/Vault y auditoría sin cambios; PSP/KYC retire a través de canales privados o un proxy altamente controlado.