Private endpoants e redes internas

1) Por que a rede privada

• Isolamento de PaaS/DB/armazenamento de IP público;
• simplificação da conformidade (PCI DSS/GDPR);
• atrasos e rotações previsíveis.

2) Modelo básico: VPC/VNet e hub

Espaço de endereço: um único plano CIDR, sem interseções (por exemplo, '10. 0. 0. 0/12 'é cortado por ambientes e hub).
Segmentação: sub-redes 'ingress', 'app', 'data', 'ops',' shared 'com rotas individuais/LCA/SG.
Hab de trânsito: central VPC/VNet com passarelas (VPN/DirectConnect/ExpressRoute/Interconnect), VPC peering/Transit Gateway e redes.
Dual-stack: planejamento do IPv6 com antecedência (economizando NAT, melhorando a escala de endereços).

3) Private endpoants: princípios

• O tráfego é dentro da rede de provedores (não pela Internet).
• Endpoint policy limita para onde você pode ir (prefixos/ARN/recursos).
• O DNS é redefinido para IP privado (consulte parágrafo 6).

Alvos típicos: estores de objeto (S3/GCS/Blob), segredo/KMS, filas, pneus de evento, controle de banco de dados, serviços de análise, registros de artefato.

4) Entrada e equilíbrio no interior

Internal Load Balancer (ILB) para L4/7, visto apenas a partir de subprocuradores privados.

• 'Service' do tipo 'LoadBalancer' com anotações internacionais.
• Entrar pelo Internal Ingress (Nginx/Contour/Gateway API) em um endereço privado.
• API Gateway (private): integração privada com backends; para fora, apenas através de edge, se necessário.

Exemplo: 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) Caminho Egress: «padrão - deny»

• NAT Gateway (para updates/repositórios) + egress allowlist por FQDN/IP;
• TLS inspeção/proxy, se as políticas exigirem controle;
• Private endpoants a PaaS/maiúsculas em vez de NAT.
• SG/NACL: permissões explícitas para o serviço, «leste-oeste» - mínimo.
• As políticas Egress K8s (CNI/OPA Gatekeeper/Calico NetworkPolicy) são uma proibição de IP externo, permissões de cluster/endpoint.

6) DNS: split-horizon и private zones

Divida as zonas internas ('.internal. corp ') e público.
Private DNS zonas para serviços do provedor: substitui nomes públicos (por exemplo, 'bucket. s3. region. amazonaws. com ') para registros A/AAAA privados.
Forwarders/Conditional DNS между on-prem ↔ cloud.
Formato de nome: encapsule ambiente/região ('api. eu1. internal. corp '), evite PII.

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

7) Patternos de interconexão

Peering (VPC↔VPC/VNet↔VNet): simples e rápido; o trânsito nem sempre é suportado, use o Transit Gateway/Virtual WAN/Cloud Router para uma estrela (hub-and-spoke).
On-prem-cloud: IPsec VPN para iniciar, seguido por uma linha selecionada (DC/ER/IC) com BGP e reserva (dois provedores, diferentes pontos de entrada).
Segmentação VRF/Rota-domain: Isolamento pró/estágio/dave e perímetro de cartas.

8) Zero Trust e autenticação interna

mTLS-padrão (serviço mesh: Istio/Linkerd/Consul), identidade de máquina: SPIFFE/SPIRE.
Políticas L7: permissão por JWT/claims/scopes, limitação de rotas/métodos em proxy.
Secrets: HashiCorp Vault/КMS + External Secrets Operator; creadouros curtos (STS).
Basion/Privileged Access: Acesso à privatização somente por meio de um corretor/sessão de JIT (MFA, gravação de comandos).

Exemplo: filtro envoy mTLS + JWT-athz (fatia)

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) Dados e PaaS dentro da porteira

Bases/clusters: apenas endereços privados; admink via basition/JIT.
Armazenamento: acesso VPC por private endpoint; endpoint policy permite apenas os tanques/contêineres necessários.
Filas/pneus: interfaces privadas; provedores/consoadores - no mesmo VPC/peering.
Registros de artefatos: acesso privado a partir de CI/CD runners em subsetores privados.

10) Observabilidade em redes privadas

OpenTelemetry Colector - Como uma passarela de telemetria: exportadores internos em self-hosted (Prometheus/Tempo/Loki/ClickHouse) ou backends controlados por private endpoants.
Flow logs/NSG/NACL logs e reachability analyzer - obrigatório.
Corte SLO: 'site/region/vpc/subnet', alertas para fuga de egress e «direção de internet» inesperada.

11) Testes e verificação

Policy as Code (OPA/Gatekeeper) para regras de rede/Ingress/Service.
Rotas Canary: domínios de teste em private DNS, verificações synthetic de diferentes subretas/AZ/regiões.
Rede Chaos: atrasos/perdas em mage-VPC/mage-AZ (netem/Toxiproxy), verificações de temporizações e políticas retry.

12) Exemplos de configuração

12. 1 Terraform: marcas e rotas (ideia)

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: proibir tudo, exceto o necessário

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

Uma «gestão da internet» geral de subprocuradores privados; não há controle egress.
Split brain DNS e manual aleatório '/etc/hosts'.
CIDR e NAT que se cruzam.
Endpoint público para BB/armazenamento «por conveniência».
Falta de logs de fluxo/auditoria de regras; «abertos» SG '0. 0. 0. 0/0`.
Chaves de acesso estáticas de longa duração no código/CI.

14) Custo e desempenho

Private endpoint muitas vezes é mais barato que o NAT egress permanente e mais seguro.
Planeje clusters NAT/az-local para não criar bottleneck.
O dinheiro/edge e o SWR reduzem o tráfego cruzado regional.
Selecione os protocolos: há menos conexões dentro do e um overhead TLS.

15) Especificidades do iGaming/Finanças

PCI DSS: circuito de cartas (CDE) em uma rede separada/ERRF, sem internet; Acesso aos logs/logs PSP somente por private endpoants; auditorias imutáveis (WORM/Object Lock).
KMS/Vault: as chaves são segmentadas per região/marca; as operações de assinatura (HSM) estão disponíveis apenas da CDE por mTLS.
PSP/KYC: Se houver private connectividade/marcadores, use; senão: egress através de proxy confiável com HMAC/mTLS e allowlist explícito.
Multi-tenência: tags e políticas por 'tenant '/' brand'; nomes privados DNS e camadas SG.

16) Folha de cheque pró-prontidão

• Plano CIDR sem interseções; dual-stack pronto (IPv6).
• Hub-and-Spoke, Transit, peering; on-prem-cloud - BGP, lentes de reserva.
• Todos os PaaS/armazenamento/BD - via private endpoants + endpoint policies.
• Internal LB/Ingress; perímetro público - apenas em edge/WAF.
• Split-horizonte DNS, private áreas e conditional-forwarding configurados.
• Egress padrão «deny»; NAT/proxy são limitados e registrados.
• Mesh mTLS + SPIFFE; JWT-athz em L7; Vault/ESO, segredos curtos.
• NetworkPolicy/SG/NACL - «mínimo necessário», flow-logs e reachability-análise.
• OtTel Captor dentro; alertas para fuga de egress, SLO por 'site/region/vpc'.
• PCI/auditoria: revistas WORM, KMS/HSM, confinamento CDE, runbook de acesso.

17) TL; DR

Construa uma rede com um esquema de hub-and-spoke com um plano CIDR claro, use o private endpoints para cada PaaS/armazenamento/BD e o tráfego para fora apenas através de pontos egress controlados. Internamente - Internal LB/Ingress, mTLS+SPIFFE, split-horizonte DNS, NetworkPolicy/SG rigorosos e telemetria via OTel. Para o iGaming/Finanças, adicione segmentação PCI, KMS/Vault e auditoria imutável; O PSP/KYC retire através de canais privados ou um proxy altamente controlado.