Netzwerk, DNS, Load Balancer und Firewall

Fachliches Bild

Für den Fachbereich bedeutet Netzwerk: Benutzer können das Portal erreichen, Partner können APIs aufrufen, Batchsysteme können Daten übertragen, und Angriffe werden begrenzt. Für Betrieb und Architektur bedeutet es: kontrollierte Kommunikationswege, klare Zonen und messbare Latenz.

DNS und IPAM

DNS gibt Diensten Namen; IPAM verhindert Chaos bei IP-Adressen, Subnetzen und Reservierungen. In Enterprise-Umgebungen ist DNS oft kritischer als einzelne Applikationsserver, weil fast jede Integration davon abhängt.

Firewall und Segmentierung

Firewall-Regeln sollen Geschäftsflüsse ausdrücken, nicht zufällige Portfreigaben. Gute Regeln beschreiben Quelle, Ziel, Port, Protokoll, Zweck, Verantwortliche und Ablaufdatum. Segmentierung reduziert Schadensausbreitung.

Load Balancing und Health Checks

Load Balancer verteilen Traffic und erkennen kaputte Instanzen. Health Checks müssen fachlich sinnvoll sein: Ein HTTP-200 auf /health ist wertlos, wenn die Anwendung ohne Datenbankverbindung keine Bestellungen verarbeiten kann.

Ingress, Routes und API-Gateways

Bei Kubernetes/OpenShift kommen interne Services, Ingress/Route, TLS-Terminierung und eventuell API-Gateways hinzu. Die Grenze zwischen Netzwerkteam und Plattformteam muss sauber definiert werden.

Ausführliche Beispiele

Firewall-Regel fachlich dokumentieren

firewall_rule:
  id: FW-ORDER-API-001
  source_zone: partner-dmz
  destination_zone: app-prod
  destination_service: order-api
  protocol: tcp
  port: 443
  purpose: "Partnerportal sendet Bestellungen an Order API"
  owner: order-platform-team
  review_cycle: quarterly
  expires: 2027-06-30

Nginx-ähnlicher Health-Check-Gedanke

upstream order_backend {
  server order-api-1.internal:8443 max_fails=3 fail_timeout=10s;
  server order-api-2.internal:8443 max_fails=3 fail_timeout=10s;
}

server {
  listen 443 ssl;
  location / {
    proxy_pass https://order_backend;
  }
  location /health/ready {
    proxy_pass https://order_backend/actuator/health/readiness;
  }
}

OpenShift Route-Beispiel

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: order-api
  namespace: orders-prod
spec:
  host: order-api.company.example
  to:
    kind: Service
    name: order-api
  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Redirect

Prüf- und Verständnis-Checkliste

• DNS-Namen folgen Namenskonventionen.
• Firewall-Regeln sind fachlich begründet und regelmäßig geprüft.
• Load Balancer prüfen Readiness und Liveness unterschiedlich.
• Netzwerkdiagramme zeigen Zonen, nicht nur Linien.

Merksatz

Eine Infrastrukturkomponente ist erst enterprise-tauglich, wenn sie geplant, automatisiert, überwacht, geschützt, wiederherstellbar und fachlich begründet ist.