Firewall-Richtlinien und ACLs

1) Ziele und Grundsätze

• Least privilege: nur das Notwendige zulassen (explizite allow, implicit deny).
• Segmentation: Isolierung von Umgebungen (prod/stage/dev), Tenanten, kritischen Schleifen (PCI/KMS/DB).
• Egress-Kontrolle: Der ausgehende Datenverkehr ist auf FQDN/IP-Listen und private Endpoint's beschränkt.
• Identity-aware (L7): Entscheidungen werden über eine authentifizierte Entität (SPIFFE/OIDC) und nicht nur über IP getroffen.
• Infrastruktur als Code: Regeln als Code, Review/CI/CD, Änderungsaudit.

2) Taxonomie: Wo und was wir filtern

2. 1 Schichten und Zustand

L3/L4 stateless: klassische ACLs (CIDR, Protokoll, Port).
L3/L4 stateful: security groups/NSG, überwachen Verbindungen.
L7-aware: proxy/WAF/mesh RBAC (Methoden, Pfade, JWT-claims, SNI).
Inline vs Out-of-Band: Die Inline-Firewall leitet den Datenverkehr; out-of-band - Analyse/Warnung.

2. 2 Konturen

Perimeter: edge/WAF/Anti-DDoS.
Core: transit hub / меж-VPC/VNet.
Workload: SG/NSG на VM/ENI/POD.
App-level: Envoy/Istio/NGINX policy, service-to-service mTLS.

3) Cloud-Modelle

AWS

Security Group (SG): stateful на ENI/instance/LB.
Network ACL (NACL): stateless auf dem Subnetz, Regelreihenfolge, bidirektionale Einträge.
AWS Network Firewall/GWLB: L7 Inspektion/IDS.
Empfehlung: „SG ist die Hauptkontrolle, NACL ist ein grobkörniger Zaun/Deny-Blatt“.

Azure

NSG (stateful), ASG (Anwendungsgruppen nach Tags), Azure FW für L7/IDS, Private Endpoints.
Empfehlung: NSG auf Sabnet + NIC, Service-Tags über ASG.

GCP

VPC Firewall Rules (stateful), Hierarchische FW (organisatorisch/ordnerisch), Cloud Armor (L7), Private Service Connect.
Empfehlung: org-level guardrails + design allow.

4) Regelentwurf: Muster

4. 1 Basissets

Deny all egress → erlauben FQDN/IP zu: Batch-Repositories, Artefakt-Register, APIs von Drittanbietern (über private/feste Ausgänge).
Ost-West-Tief: Die Dienste kommunizieren nur mit den nötigen Abhängigkeiten.
Admin-Zugang: über bastion/JIT mit MFA, Aufzeichnung von Sitzungen.

4. 2 Tags und Gruppen

Verwenden Sie Labels/Tags anstelle von IP: 'env', 'service', 'tier', 'tenant', 'pci = true'.
Richtlinienaktualisierung bei Tag-Änderungen - ohne manuelle Bearbeitung von IP-Grids.

4. 3 Lebenszyklus

Propose → Evaluate (Staging) → Enforce (Prod), mit Dry-Run/Trefferprotokollen.
Obsoleszenz: TTL/Besitzer für jede Regel, Auto-Check ungenutzt.

5) Kubernetes und Service Mesh

5. 1 NetworkPolicy (L3/L4)

Das Minimum sei, „alles zu verbieten, außer das Notwendige“.

yaml apiVersion: networking. k8s. io/v1 kind: NetworkPolicy metadata: { name: deny-all, namespace: core }
spec:
podSelector: {}
policyTypes: ["Ingress","Egress"]
kind: NetworkPolicy metadata: { name: api-egress }
spec:
podSelector: { matchLabels: { app: api } }
egress:
- to:
- namespaceSelector: { matchLabels: { ns: db } }
ports: [{ protocol: TCP, port: 5432 }]
- to:
- ipBlock: { cidr: 10. 100. 0. 0/16 } # Private endpoints ports: [{ protocol: TCP, port: 443 }]

5. 2 L7 RBAC в mesh (Istio/Envoy)

mTLS + Autorisierung durch JWT/claims/scopes/paths.

yaml apiVersion: security. istio. io/v1 kind: AuthorizationPolicy metadata: { name: api-rbac }
spec:
selector: { matchLabels: { app: api } }
rules:
- from:
- source:
principals: ["spiffe://svc. payments"]
to:
- operation: { methods: ["POST"], paths: ["/v1/payouts"] }
when:
- key: request. headers[x-tenant]
values: ["eu-1","eu-2"]

6) Egress-Kontrolle und private Perimeter

Bevorzugen Sie PrivateLink/Private Service Connect zu PaaS/Registern/Speichern.
Der Rest der egress über NAT/Proxy mit allowlist FQDN und feste IP (für Drittanbieter allowlist).
Blockieren Sie direkten Ausgang der Herde/VM zum Internet; Ausnahmen nur über das egress-Gateway.

7) DNS und SNI-bewusste Regeln

Split-Horizon: Die inneren Bereiche werden nicht nach außen gerichtet.
FW/Proxy mit FQDN/SNI-Unterstützung für ausgehende HTTPS (SNI erlaubt).
Pinning auf bestimmte Anbieter-Domains fixieren; Überwachen Sie ihre IP-Änderungen.

8) Protokolle, Audit, Beobachtbarkeit

Aktivieren Sie die Ablaufprotokolle (VPC/VNet/NSG/NACL), senden Sie sie an SIEM.
Korrelieren Sie mit den Anwendungen über 'trace _ id' in den Protokollen.
Metriken: Hit/Miss-Regeln, Top-Talker, Drop-Raten, Verkehrsasymmetrie, „Egress-Leaks“.
Berichte: „ungenutzte Regeln“, „umfassendste Berechtigungen“.

9) Management als Code (IaC) und Prüfungen

Terraform/CloudFormation + modulare Richtlinien nach Vorlagen.
Policy as Code (OPA/Gatekeeper/Conftest): Verbot von'0. 0. 0. 0/0', Anforderung 'description/owner/ttl', Mischverbot prod/dev.
CI: Lint, Static Analysis, Reachability Analyzer, Plan-View, Mandate Peer Review.

10) Erreichbarkeitstests und Chaos

Synthetic-Tests aus verschiedenen Subnetzen/AZ/Regionen: TCP/443, spezifische DB/Broker-Ports.
Zeitlicher Grund für die Überprüfung von DR-Pfaden: Das Deaktivieren der Abhängigkeit sollte → retries/circuit/fallback auslösen.
MTU/MSS: Stellen Sie sicher, dass Perimeter nicht fragmentiert sind (insbesondere IPsec/NAT-T).

11) Leistung und Zuverlässigkeit

Zentralen Engpass vermeiden: inline-FW horizontal skalieren (GWLB/scale sets).
ECMP/AS-path/BGP für die Verteilung zwischen den Hubs.
TLS-Inspektionsprofile: Punktweise einschließen (teuer), Schlüsselabdrücke getrennt aufbewahren, Compliance einhalten.

12) Beispiele für Config (Referenzen, verkürzt)

12. 1 AWS SG: API → Postgres + S3 PrivateLink

hcl resource "aws_security_group" "api" {
name    = "sg-api"
description = "Ingress from ALB, egress to DB and PrivateLink"
vpc_id   = var. vpc_id

ingress { from_port=8080 to_port=8080 protocol="tcp" security_groups=[aws_security_group. alb. id] }
egress { from_port=5432 to_port=5432 protocol="tcp" security_groups=[aws_security_group. db. id] }
egress { from_port=443 to_port=443 protocol="tcp" prefix_list_ids=[aws_vpc_endpoint. s3. prefix_list_id] }
tags = { owner="team-api", env=var. env, ttl="2026-01-01" }
}

12. 2 Azure NSG: deny-by-default + allow bastion

bash az network nsg rule create -g rg -n allow-bastion --nsg-name nsg-app \
--priority 100 --direction Inbound --access Allow --protocol Tcp \
--source-address-prefixes 10. 0. 0. 10 --source-port-ranges "" \
--destination-port-ranges 22 --destination-address-prefixes 10. 1. 0. 0/16

12. 3 GCP hierarchical firewall: org-guardrail

yaml direction: INGRESS priority: 1000 action: deny enableLogging: true match:
layer4Configs: [{ ipProtocol: "all" }]
srcIpRanges: ["0. 0. 0. 0/0"]
targetResources: ["organizations/123456"]

12. 4 Envoy RBAC (L7 allow)

yaml
- name: envoy. filters. http. rbac typed_config:
rules:
action: ALLOW policies:
payments-post:
permissions: [{ url_path: { path: "/v1/payouts", ignore_case: true } }]
principals: [{ authenticated: { principal_name: { exact: "spiffe://svc. payments" } } }]

13) Antipatterns

`0. 0. 0. 0/0 'in ingress/egress „temporär“ → bleibt für immer.
„Schneeflocken“ (manuelle Bearbeitungen in der Konsole) ohne Code und Revision.
Allgemeines SG/NSG für prod/stage/dev; Mischen von kritischen und unkritischen Subnetzen.
Fehlende egress-Kontrolle und private Endpunkte's → Leck Schlüssel/Geheimnisse nach außen.
Ignorieren von DNS/SNI: Die IP des Anbieters wurde erlaubt - morgen wurde sie gewechselt und der gesamte Bereich geöffnet.
Keine Flow-Logs und Runbooks → Forensics sind möglich.

14) Besonderheiten von iGaming/Finanzen (PCI/Regulatory)

PCI CDE in separatem VRF/Segment, kein Internet; Zugriff auf PSP/Logs - über private Konnektivität/Proxy mit mTLS und HMAC.
Datenresidenz: PII/Zahlungsereignisse - innerhalb des Landes/der Region; überregional - nur Aggregate/anonym.
KMS/Vault/HSM: einzelne Subnetze/SG, nur mTLS-Clients mit Kurzzertifikaten.
WORM-Audit: FW/Flow-Protokolle in unveränderlichem Speicher (Object Lock), Retention ≥ regulatorischem Minimum.
Partner (PSP/KYC): FQDN-Liste, statische IP-Adresse, SLA-Überwachung nach Anbieter.

15) Checkliste Prod-Ready

• Einheitliches Segmentierungsmodell (Hub-and-Spoke, VRF), CIDR ohne Überschneidungen.
• Deny-by-default на egress; private Endpunkte zu PaaS/Speichern.
• SG/NSG stateful für Workload, NACL/Route-Filter für Subnetze/Hubs.
• K8s: NetworkPolicy «deny-all», mesh mTLS + L7 RBAC.
• Tags/Gruppen statt IP; Eigentümer/TTL/Beschreibung jeder Regel.
• IaC + Policy-as-Code; CI mit Erreichbarkeitssimulation; obligatorische Peer-Review.
• Flow Logs sind enthalten; Dashboards Top-Talker, Drop-Raten; Alert auf „Leck egress“.
• Bastion/JIT für den Admin-Zugang; MFA; Protokollierung von Sitzungen.
• Runbook 'und: wie man eine Regel hinzufügt/entfernt, wie man bei einem Vorfall arbeitet; regelmäßige Revisionen der „toten“ Regeln.
• Für PCI/Finanzen: CDE-Isolation, WORM-Audit, FQDN-allow für PSP/KYC, statische egress IP.

16) TL; DR

Bauen Sie Schutz nach Schichten: SG/NSG stateful auf Vorkloaden, NACL/Route-Filter auf Subnetzen, L7 RBAC in Mesh/Proxy, WAF/Edge auf Perimeter. Die Voreinstellung ist deny-by-default, egress nur über überwachte Punkte oder private Endpunkte. Beschreiben Sie Regeln als Code, überprüfen Sie sie mit Richtlinien und Erreichbarkeitssimulatoren und sammeln Sie Flow-Logs. Für iGaming/Finanzen fügen Sie PCI-Segmentierung, WORM-Audit und strenge FQDN-Zulassung zu PSP/KYC hinzu.