Private Endpunkte und interne Netzwerke

1) Warum ein privates Netzwerk

• Isolierung von PaaS/DB/Speichern von öffentlichen IPs;
• Vereinfachung der Compliance (PCI DSS/DSGVO);
• vorhersehbare Verzögerungen und Routing.

2) Basismodell: VPC/VNet und Hubs

Adressraum: einheitlicher CIDR-Plan, keine Überschneidungen (z.B. '10. 0. 0. 0/12 'wird in Umgebungen und Hubs geschnitten).
Segmentierung: Subnetze' ingress', 'app', 'data', 'ops', 'shared' mit separaten Routen/ACL/SG.
Transit Hub: zentraler VPC/VNet mit Gateways (VPN/DirectConnect/ExpressRoute/Interconnect), Inter-VPC peering/Transit Gateway und Netzwerk-Firewall.
Dual-Stack: Planung von IPv6 im Voraus (spart NAT, verbessert die Skalierung von Adressen).

3) Private Endpunkte: Prinzipien

• Der Verkehr läuft innerhalb des Anbieternetzwerks (nicht über das Internet).
• Endpoint-Richtlinie schränkt ein, wohin Sie gehen können (Präfixe/ARN/Ressourcen).
• DNS wird mit privaten IPs überschrieben (siehe § 6).

Typische Ziele: Objektstore (S3/GCS/Blob), Secret/KMS, Warteschlangen, DB-gesteuerte Ereignisbusse, Analysedienste, Artefaktregister.

4) Eingang und Ausgleich innen

Der Internal Load Balancer (ILB) für L4/7 ist nur in privaten Subnetzen sichtbar.

• 'Service' vom Typ 'LoadBalancer' mit internen Anmerkungen.
• Melden Sie sich über Internal Ingress (Nginx/Contour/Gateway API) an einer privaten Adresse an.
• API Gateway (privat): private Integration in Backends; nach außen - bei Bedarf nur über die Kante.

Beispiel: K8s Ingress als interne

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-Kontur: „default is deny“

• NAT Gateway (für Updates/Repositories) + egress allowlist über FQDN/IP;
• TLS-Inspektion/Proxy, wenn die Politik Kontrolle erfordert;
• Private Endpunkte zu PaaS/Registern anstelle von NAT.
• SG/NACL: ausdrückliche Genehmigungen pro Dienst, „Ost-West“ - Minimum.
• Egress-Richtlinien K8s (CNI/OPA Gatekeeper/Calico NetworkPolicy) - Verbot von externen IPs, Berechtigungen für Cluster/Endpoints.

6) DNS: split-horizon и private zones

Teilen Sie die inneren Zonen ('.internal. corp') und öffentlich.
Private DNS-Zonen für Provider-Dienste: überschreiben öffentliche Namen (z.B. 'bucket. s3. region. amazonaws. com') auf private A/AAAA-Einträge.
Forwarders/Conditional DNS между on-prem ↔ cloud.
Namensformat: Einkapseln der Umgebung/Region ('api. eu1. internal. corp'), PII vermeiden.

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

7) Netzwerkverbindungsmuster

Peering (VPC↔VPC/VNet↔VNet): einfach und schnell Transit wird nicht immer unterstützt → verwenden Sie den Transit Gateway/Virtual WAN/Cloud Router für den Stern (Hub-and-Spoke).
On-prem ⇄ cloud: IPsec VPN zum Start, dann Standleitung (DC/ER/IC) mit BGP und Backup (zwei Provider, verschiedene Einstiegspunkte).
Segmentierung VRF/Route-Domain: Isolierung von prod/stage/dev und Kartenperimeter.

8) Zero Trust und interne Authentifizierung

mTLS-default (service mesh: Istio/Linkerd/Consul), Maschinenidentität: SPIFFE/SPIRE.
L7-Richtlinien: Autorisierung durch JWT/claims/scopes, Einschränkung der Routen/Methoden auf Proxy-Ebene.
Secrets: HashiCorp Vault/КMS + External Secrets Operator; kurzlebige Credenchels (STS).
Bastion/Privileged Access: Zugang zum Privaten nur über Broker/JIT-Session (MFA, Command Recording).

Beispiel: Envoy Filter mTLS + JWT-authz (Fragment)

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) Daten und PaaS innerhalb der Privatsphäre

Basen/Cluster: nur private Adressen; Admin über bastion/JIT.
Speicher: Zugriff von VPC über private Endpoint; endpoint policy erlaubt nur die gewünschten Baquets/Container.
Warteschlangen/Busse: private Schnittstellen; Produzenten/Konsumenten - im selben VPC/Peering.
Artefaktregister: privater Zugriff von CI/CD-Runnern in privaten Subnetzen.

10) Beobachtbarkeit in privaten Netzwerken

OpenTelemetry Collector ist wie ein Telemetrie-Gateway: inländische Exporteure in Self-Hosted (Prometheus/Tempo/Loki/ClickHouse) oder in Managed Backends über private Endpunkte.
Flow Logs/NSG/NACL Logs und Reachability Analyzer sind obligatorisch.
SLO-Schnitte: 'site/region/vpc/subnet', Warnhinweise für egress leakage und unerwartete' internet direction'.

11) Prüfung und Verifizierung

Policy as Code (OPA/Gatekeeper) für Netzwerkregeln/Ingress/Service.
Kanarische Routen: Test-Domains im privaten DNS, Synthetic-Checks aus verschiedenen Subnetzen/AZ/Regionen.
Chaos-Netzwerk: Verzögerungen/Verluste in inter-VPC/inter-AZ (netem/Toxiproxy), Zeitüberschreitungen und Retry-Richtlinien.

12) Beispiele für Konfigurationen

12. 1 Terraform: Tags und Routen (Idee)

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: Alles außer dem Notwendigen verbieten

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

Allgemeines „Management-Internet“ aus privaten Subnetzen; fehlende Egress-Kontrolle.
Split-Brain DNS und zufällige manuelle '/etc/hosts'.
Sich überschneidende CIDRs und „NAT-Matroschkas“.
Öffentliche Endpoint's für DB/Speicher „aus Gründen der Bequemlichkeit“.
Keine Ablaufprotokolle/Regelprüfung; „offen“ SG'0. 0. 0. 0/0`.
Langlebige statische Zugriffsschlüssel im Code/CI.

14) Kosten und Leistung

Private Endpunkte sind oft günstiger als ein permanenter NAT-Egress und sicherer.
Planen Sie NAT-Cluster/az-local für die Bandbreite, damit kein Bottleneck entsteht.
Cache/Edge und SWR reduzieren den regionalübergreifenden Verkehr.
Protokollauswahl: HTTP/2/gRPC im Inneren → weniger Verbindungen und TLS-Overhead.

15) Spezifität von iGaming/Finanzen

PCI DSS: Card Loop (CDE) in einem separaten Netzwerk/VRF, kein Internet; Zugriff auf Store/PSP-Protokolle nur über private Endpunkte; unveränderliche Audits (WORM/Object Lock).
KMS/Vault: Schlüssel sind pro Region/Marke segmentiert; Signaturoperationen (HSM) sind nur im CDE über mTLS verfügbar.
PSP/KYC: wenn es private Konnektivität/Märkte gibt - verwenden Sie; ansonsten - egress über einen vertrauenswürdigen Proxy mit HMAC/mTLS und expliziter allowlist.
Multi-Tenant: Tags und Richtlinien für 'tenant '/' brand'; separate private DNS-Namen und SG-Ebenen.

16) Checkliste Prod-Ready

• CIDR-Plan ohne Überschneidungen; Dual-Stack bereit (IPv6).
• Hub-and-Spoke, Transit, peering; on-prem ⇄ cloud - BGP, Backup-Link-Paare.
• Alle PaaS/Speicher/DB - über private Endpunkte + Endpunktrichtlinien.
• Internal LB/Ingress; public perimeter - nur auf edge/WAF.
• Split-horizon DNS, private Zonen und conditional-forwarding sind konfiguriert.
• Egress default „deny“; NATs/Proxys sind begrenzt und werden protokolliert.
• Mesh mTLS + SPIFFE; JWT-authz auf der L7; Vault/ESO, kurze Geheimnisse.
• NetworkPolicy/SG/NACL - „minimum necessary“, Flow-Logs und Reachability-Analyse.
• OTel Sammler innen; Leckagealerts egress, SLO durch 'site/region/vpc'.
• PCI/Audit: WORM-Logs, KMS/HSM, CDE-Isolation, Runbook-Zugriff.

17) TL; DR

Bauen Sie Ihr Netzwerk nach einem Hub-and-Spoke-Schema mit einem klaren CIDR-Plan auf, verwenden Sie private Endpunkte für jeden PaaS/Speicher/DB und den Datenverkehr nach außen nur über verwaltete Egress-Punkte. Im Inneren befinden sich interne LB/Ingress, mTLS + SPIFFE, Split-Horizon DNS, strikte NetworkPolicy/SG und Telemetrie über OTel. Für iGaming/Finanzen fügen Sie PCI-Segmentierung, KMS/Vault und unveränderliches Audit hinzu; PSP/KYC wird über private Kanäle oder einen streng kontrollierten Proxy ausgegeben.