GH GambleHub

Private endpoants e reti interne

1) Perché una rete privata

Lo scopo è quello di ridurre al minimo la superficie dell'attacco e il costo dell'egress, collegando servizi critici sui lines privati senza accesso a Internet. Questo dà:
  • Isolamento di PaaS/DB/storage da IP pubblico
  • Semplificazione della conformità (PCI DSS/GDPR)
  • prevedibili ritardi e routing.

2) Modello base: VPC/VNet e hub

Lo spazio di destinazione è un unico piano CIDR, senza intersezioni (es. '10. 0. 0. 0/12 'viene tagliato in ambienti e hub).
Segmentazione: subnet «ingress», «app», «data», «ops», «shared» con percorsi separati/ACL/SG.
Hab in transito: centrale VPC/VNet con gateway (VPN/DirectConnect/ExpressRoute/Interconnect), MJ-VPC peering/Transit Gateway e firewall di rete.
Dual-stack - Pianificazione IPv6 in anticipo (risparmia NAT, migliora la scala degli indirizzi).

3) Private endpoint: principi

Private endpoint/PrivateLink/Private Service Connect è un'interfaccia privata per il servizio gestito (archivio oggetti, code, database, archivio segreto) accessibile solo dallo spazio di destinazione:
  • Il traffico avviene all'interno di una rete di provider (non via Internet).
  • Endpoint policy limita il percorso (prefissi/ARN/risorse).
  • Il DNS viene ridefinito come IP privato (vedere l'articolo 6).

Gli obiettivi tipici sono gli store di oggetti (S3/GCS/Blob), il segreto/KMS, le code, gli eventi pneumatici, i servizi di analisi, i registri artefatti.

4) Ingresso e bilanciamento all'interno

Internal Load Balanner (ILB) per L4/7, visibile solo da sottoassiemi privati.

Kubernetes:
  • «Service» tipo «LoadBalancer» con annotazioni internal.
  • Accesso Internal Ingress (Nginx/Contour/Gateway API) in un indirizzo privato.
  • API Gateway (private): integrazione privata con backend all'esterno, solo tramite edge, se necessario.

Esempio: K8s Ingress come 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) Tracciato Egress: «l'impostazione predefinita è deny»

Senza la diretta Internet da sottoassiemi privati, tutto fuori solo attraverso:
  • NAT Gateway (per update/repository) + egress allowlist su FQDN/IP;
  • Ispezione/proxy TLS se i criteri richiedono il controllo;
  • Private endpoint a PaaS/maiuscole invece di NAT.
  • SG/NACL: autorizzazioni esplicite per il servizio, «est-ovest» minimo.
  • Egress-policy K8s (CNI/OPA Gatekeeper/Calico) - Disabilita IP esterni, autorizzazioni per cluster/endpoint.

6) DNS: split-horizon и private zones

Separare le zone interne ('.internal. corp ') e pubblico.
Private DNS zone per il provider: sostituisce i nomi pubblici (ad esempio, 'bucket. s3. region. amazonaws. com ') per le registrazioni A/AAAA private.
Forwarders/Conditional DNS между on-prem ↔ cloud.
Formato dei nomi: incapsulare l'ambiente/regione ('api. eu1. internal. corp '), evitare il PII.

Esempio di scrittura:

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

7) Pattern interconnessioni

Peering (VPC↔VPC/VNet↔VNet) - Semplice e veloce; il transito non è sempre supportato da Transit Gateway/Virtual WAN/Cloud Router per la stella (hub-and-spoke).
On-prem ⇄ cloud: IPsec VPN per l'avvio, seguito da una linea selezionata (DC/ER/IC) con BGP e riserva (due provider, diversi punti di accesso).
Segmentazione VRF/Route-domain: isolamento prod/stage/uv e perimetro di carte.

8) Zero Trust e autenticazione interna

mTLS-predefinito (servizio mesh: Istio/Linkerd/Consul), identità macchina: SPIFFE/SPIRE.
Criteri L7: autorizzazione per JWT/clims/scopes, limitazione di percorsi/metodi a livello proxy.
Secrets: HashiCorp Vault/КMS + External Secrets Operator; STS.
Base/Privileged Access: accesso alla privacy solo tramite broker/sessione JIT (MFA, record comandi).

Esempio: Invoy filtro mTLS + JWT-authz (sezione)

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) Dati e informazioni all'interno della vetrina

Basi/cluster: solo indirizzi privati; admink tramite base/JIT.
Storage: accesso da VPC con private endpoint endpoint policy consente solo i bustini/contenitori desiderati.
Code/bus: interfacce private; costruttori/consulenti - nello stesso VPC/peering.
Registri manufatti: accesso privato da CI/CD runners in sottoassiemi privati.

10) Osservabilità su reti private

OpenTelemetry Collector - come gateway di telemetria: esportatori interni in self-hosted (Prometheus/Tempo/Loki/ClickHouse) o in backends gestiti con private endpoint.
Flow logs/NSG/NACL logs e reachability analyzer sono obbligatori.
I tagli SLO sono: 'site/region/vpc/subnet', gli alert per la fuoriuscita egress e la «direzione Internet» inaspettata.

11) Test e verifica

Policy as Code (OPA/Gatekeeper) per le regole di rete/Ingress/Service.
Percorsi Canary: domini di prova in private DNS, verifiche synthetic da sottoassiemi/AZ/regioni.
Rete Chaos: ritardi/perdite in MJ-VPC/Mage-AZ (netem/Toxiproxy), controlli timeout e regole retry.

12) Esempi di configurazione

12. 1 Terraform: etichette e percorsi (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: disabilita tutto tranne ciò che è necessario

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

Il «gestore di Internet» condiviso da sottoassiemi privati; la mancanza di egress control.
Split brain DNS e manuali casuali '/etc/hosts'.
CIDR e materassi NAT che si intersecano.
Endpoint pubblici per database/deposito «per comodità».
Nessun login di flusso/controllo delle regole; «aperto» SG '0. 0. 0. 0/0`.
Chiavi di accesso statiche a lunga vita nel codice/CI.

14) Costi e prestazioni

Private endpoint è spesso meno costoso NAT egress e più sicuro.
Pianificare cluster NAT/az-locali per la larghezza di banda senza creare bottleneck.
Cache/edge e SWR riducono il traffico crociato-regionale.
La selezione dei protocolli è che ci sono meno connessioni all'interno del sistema e un overhead TLS.

15) Specificità iGaming/finanza

PCI DSS: tracciato di carte (CDE) su una rete/VRF separata, niente Internet; Accesso allo store/PSP solo con private endpoint verifiche invariate (WORM/Object Lock).
KMS/Vault: le chiavi sono segmentate per regione/marchio; Le operazioni di firma (HSM) sono disponibili solo da CDE.
PSP/KYC: se si dispone di private connettività/market, utilizzare; altrimenti - egress tramite proxy affidabile con allowlist e allowlist esplicito.
Multi-tenenza: tag e regole per «tenant »/« brand»; nomi DNS privati e livelli SG.

16) Assegno-foglio prod-pronto

  • Piano CIDR senza intersezioni dual-stack pronto (IPv6).
  • Hub-and-Spoke, Transit, peering; on-prem cloud - BGP, coppie di lenti di riserva.
  • Tutti i PaaS/depositi/database - tramite private endpoint + endpoint policies.
  • Internal LB/Ingress; perimetro pubblico - solo su edge/WAF.
  • Split-horizon DNS, private zone e conditional-forwarding sono configurati.
  • Egress predefinito «deny» NAT/proxy sono limitati e registrati.
  • Mesh mTLS + SPIFFE; JWT-authz su L7; Vault/ESO, segreti brevi.
  • NetworkPolicy/SG/NACL - «minimo necessario», flow-logs e reachability-analisi.
  • OTel raccoglitore interno alert per fuga di egress, SLO per 'site/region/vpc'.
  • PCI/controllo: registri WORM, KMS/HSM, isolamento CDE, runbook di accesso.

17) TL; DR

Costruisci una rete su un diagramma hub-and-spoke con un piano CIDR chiaro, usa private endpoint per ogni PaaS/archivio/DATABASE e il traffico verso l'esterno solo tramite punti egress controllati. All'interno, internal LB/Ingress, mTLS+SPIFFE, split-horizon DNS, rigidi NetworkPolicy/SG e telemetria attraverso OTel. Per iGaming/Finanza, aggiungere segmentazione PCI, KMS/Vault e controllo invariato; PSP/KYC visualizza tramite canali privati o proxy rigidamente controllati.

Contact

Mettiti in contatto

Scrivici per qualsiasi domanda o richiesta di supporto.Siamo sempre pronti ad aiutarti!

Telegram
@Gamble_GC
Avvia integrazione

L’Email è obbligatoria. Telegram o WhatsApp — opzionali.

Il tuo nome opzionale
Email opzionale
Oggetto opzionale
Messaggio opzionale
Telegram opzionale
@
Se indichi Telegram — ti risponderemo anche lì, oltre che via Email.
WhatsApp opzionale
Formato: +prefisso internazionale e numero (ad es. +39XXXXXXXXX).

Cliccando sul pulsante, acconsenti al trattamento dei dati.