Network ACL vs. Security Group: Häufigste Designfehler

Network ACL vs. Security Group ist eine der häufigsten Quellen für Fehlkonfigurationen in Cloud-Netzwerken – nicht, weil die Konzepte kompliziert wären, sondern weil sie in der Praxis oft verwechselt, falsch kombiniert oder mit falschen Erwartungen betrieben werden. In vielen Teams entsteht ein trügerisches Sicherheitsgefühl: „Die Security Group ist korrekt, also muss der Traffic durchgehen“ – und trotzdem droppen Verbindungen. Oder umgekehrt: „Die Network ACL ist nur ein extra Schutz“ – und plötzlich sind ganze Subnetze abgeschnitten, weil Ephemeral Ports oder Rückwege übersehen wurden. Der Kern ist, dass Network ACLs (NACLs) und Security Groups (SGs) auf unterschiedlichen Ebenen wirken, mit unterschiedlichen Semantiken, und damit auch unterschiedliche Failure Modes produzieren. Wer die Unterschiede sauber versteht, kann Designs bauen, die sowohl sicher als auch operativ robust sind: NACLs als grobe Subnetz-Leitplanken, Security Groups als präzise Workload-Policies. Dieser Artikel zeigt die wichtigsten Unterschiede, typische Designfehler, die in Incidents immer wieder auftauchen, und eine praxistaugliche Checkliste, wie Sie Konnektivität verlässlich absichern, ohne sich selbst mit schwer debuggbaren Drops zu blockieren.

Grundverständnis: Wo NACLs und Security Groups im Datenpfad sitzen

Ein typischer Denkfehler ist, NACLs und Security Groups als „zwei Arten von Firewalls“ zu betrachten, die man beliebig austauschen kann. In Wahrheit sind sie unterschiedliche Kontrollpunkte:

• Network ACL: Subnetz-Ebene (um Subnetze herum). Sie filtert Traffic typischerweise vor der Instanz/Workload. Das ist ein grobes, netzorientiertes Kontrollinstrument.
• Security Group: Instanz-/ENI-/Workload-Ebene. Sie filtert Traffic an der Workload-Schnittstelle und eignet sich für präzise Zugriffskontrolle.

Konzeptionell gilt: Ein Paket muss beide Schichten passieren. Wenn eine Schicht blockt, ist die Verbindung blockiert – selbst wenn die andere „offen“ ist. Deshalb ist der wichtigste Betriebsgrundsatz: NACL und SG müssen als gemeinsame Policy gedacht werden, nicht als unabhängige Alternativen.

Stateful vs. stateless: Der Unterschied, der die meisten Incidents erklärt

Der zweite große Unterschied ist die Zustandsbehandlung. In vielen Cloud-Modellen sind Security Groups stateful, NACLs dagegen stateless. Das bedeutet nicht „besser“ oder „schlechter“, sondern „anders“ – und genau dort passieren die häufigsten Designfehler.

• Stateful (Security Group): Wenn eine Verbindung in eine Richtung erlaubt wurde, sind Rückpakete für diese Verbindung typischerweise automatisch erlaubt. Sie müssen berücksichtigen, dass Verbindungen als Flows betrachtet werden.
• Stateless (Network ACL): Jede Richtung wird separat bewertet. Sie müssen also Ingress und Egress jeweils vollständig erlauben, inklusive Rückverkehr.

Warum stateless Regeln Ephemeral Ports so gefährlich machen

Bei TCP/UDP nutzen Clients meist einen dynamischen Quellport (Ephemeral Port). Der Server hört auf einem festen Zielport (z. B. 443). Bei stateless Filtering müssen Sie daher den Rückverkehr so erlauben, dass die Antwortpakete an Ephemeral Ports beim Client ankommen dürfen. Wird der Ephemeral-Port-Bereich falsch oder zu eng konfiguriert, wirkt es wie „SYN geht raus, aber nichts kommt zurück“.

Als Vereinfachung kann man den Erfolg eines Flows als logische UND-Verknüpfung aus vier Richtungsprüfungen betrachten (Client→Server und Server→Client, jeweils am Subnetzfilter und am Workloadfilter). Formal als Denkmodell:

$\mathrm{FlowOK}=\mathrm{NACL}(c\to s)\wedge \mathrm{NACL}(s\to c)\wedge \mathrm{SG}(c\to s)\wedge \mathrm{SG}(s\to c)$

Bei stateful SGs ist SG(s→c) oft implizit erfüllt, sobald SG(c→s) erlaubt ist – bei NACLs gilt das nicht.

Regel-Logik: Reihenfolge, Default-Verhalten und „Deny“-Missverständnisse

Ein weiterer Fehlercluster entsteht durch falsche Annahmen über Regelreihenfolge und Default-Verhalten.

• NACLs arbeiten häufig mit nummerierten Regeln: Die erste passende Regel gewinnt. Ein zu breiter „Deny“ mit niedriger Nummer kann alles überschreiben.
• Security Groups sind häufig additiv: Wenn irgendeine Regel erlaubt, ist es erlaubt. „Explizites Deny“ gibt es in manchen SG-Modellen nicht.
• Default-Deny vs. Default-Allow: Manche Umgebungen starten mit „alles zu“, andere mit permissiven Defaults. Wer das falsch annimmt, debuggt an der falschen Stelle.

Der häufigste Irrtum: Teams erwarten ein „Deny“ in der Security Group, um Ausnahmen zu modellieren, und wundern sich, dass es nicht greift. Oder sie setzen in der NACL eine „sichere“ Default-Deny-Regel, die aber aufgrund der Reihenfolge legitimen Rückverkehr abschneidet.

Die häufigsten Designfehler bei Network ACLs

NACLs sind mächtig, aber grob. Genau deshalb sind sie prädestiniert für Designfehler, die gleich ganze Subnetze betreffen.

• Ephemeral Ports vergessen: Ingress erlaubt 443, aber Egress/Rückverkehr zu Ephemeral Ports ist geblockt. Ergebnis: Handshake hängt, Timeouts.
• Nur Ingress betrachtet: Stateless bedeutet: Ingress und Egress müssen konsistent sein. Einseitige Öffnungen erzeugen imply Drops.
• Regelreihenfolge falsch: Ein breit gefasster Deny steht vor spezifischen Allows. Ergebnis: „Aber die Allow-Regel ist doch da“.
• Zu breite IP-Bereiche: Aus Bequemlichkeit wird 0.0.0.0/0 erlaubt. Das reduziert die Sicherheitswirkung und erschwert Audits.
• IPv6 nicht gespiegelt: Dual-Stack oder später aktiviertes IPv6 führt zu unerwarteten Pfaden, die nicht in NACL-Policies enthalten sind.
• NACL als Mikrosegmentierung missbraucht: Subnetze sind grob; zu feingranulare Policies führen zu schwer wartbaren Regelwerken.

Typisches Incident-Symptom: „SYN/SYN-ACK fehlt“

Wenn NACLs Rückverkehr blocken, sieht man häufig: Der Client sendet SYN, aber SYN-ACK kommt nie an. Das wirkt wie „Server down“, ist aber oft ein stateless Filterproblem. In der Praxis ist das einer der schnellsten Checks: Wenn nur neue Verbindungen hängen, bestehende aber laufen, ist die Regelbasis für Verbindungsaufbau oft der Schuldige.

Die häufigsten Designfehler bei Security Groups

Security Groups sind präziser, aber auch hier entstehen typische Fehler – vor allem durch falsche Modellierung von Abhängigkeiten und Ports.

• Zu enge Egress-Regeln ohne Dependency-Mapping: DNS, Identität, Telemetrie, Paketquellen oder externe APIs werden vergessen. Ergebnis: sporadische Timeouts und Retries.
• Zu breite Ingress-Regeln: „Temporär 0.0.0.0/0 auf 22/3389“ wird vergessen. Ergebnis: Angriffsfläche und Compliance-Risiko.
• Falsche Source-Definition: Statt einer SG als Quelle wird eine IP verwendet, die sich ändert (Autoscaling, neue Nodes, neue ENIs).
• Missverständnis bei „stateful“: Teams erwarten, dass stateful jede Art von Rückverkehr erlaubt, obwohl nur Rückpakete zu bestehenden Flows gemeint sind.
• Gemischte Ziele in einer SG: Zu viele Services teilen eine SG; Änderungen für einen Service riskieren andere. Ergebnis: hoher Blast Radius.
• Fehlende Trennung von Control Plane und Data Plane: Management-Zugriffe (SSH, API) werden mit Produkttraffic vermischt.

Der häufigste operative Fehler: SGs ohne Ownership

Security Groups werden oft als „Netzwerkteam-Thema“ betrachtet, obwohl sie direkt Workload-Zugriff steuern. Ohne klaren Owner und Lifecycle (wer darf ändern, wie wird getestet, wie wird dokumentiert) entstehen schleichende Risiken: zu breite Regeln, unklare Abhängigkeiten und Angst vor Änderungen, weil niemand die Folgen abschätzen kann.

Missverständnis „NACL ist zusätzlich, also egal“

Ein verbreitetes Anti-Pattern ist die Annahme, NACLs seien „nur eine extra Schicht“ und könnten permissiv bleiben, während die Security Groups „die echte Sicherheit“ liefern. Das führt in der Praxis zu zwei Problemen:

• Falsches Sicherheitsmodell: Wenn NACLs sehr offen sind, verlieren Sie eine wirkungsvolle Subnetz-Grenze gegen laterale Bewegungen innerhalb eines Netzes.
• Falsche Debugging-Hypothesen: Teams prüfen nur SGs und übersehen, dass NACLs stateful-ähnliche Erwartungen nicht erfüllen.

Ein robustes Modell nutzt NACLs als Guardrails: grobe, stabile Regeln, die selten geändert werden und klare Netzgrenzen definieren. Security Groups liefern dann die Feinsteuerung pro Workload.

Missverständnis „Security Group ersetzt NACL“

Das Gegenstück ist: NACLs werden entfernt oder extrem vereinfacht, weil SGs „doch reichen“. Auch das kann schiefgehen, insbesondere bei Anforderungen an Subnetz-Isolation, Compliance oder klar definierte Netzwerkzonen.

• Subnetz-Isolation: Wenn bestimmte Subnetze grundsätzlich kein Egress ins Internet haben dürfen, ist eine netzbasierte Schicht oft die stabilere Leitplanke.
• Shared Services: Manche Plattformen betreiben gemeinsame Komponenten im Subnetz; NACLs können Grundgrenzen setzen, bevor SG-Feinregeln greifen.
• Fehlerkaskaden: Eine falsche SG-Änderung kann viele Workloads betreffen; NACL-Guardrails können Blast Radius begrenzen.

Designprinzipien: So kombinieren Sie NACLs und Security Groups sinnvoll

Ein praxistaugliches Design folgt meist einem klaren Schichtenmodell. Ziel ist: Wenige, stabile NACL-Regeln und viele, gezielte SG-Regeln – mit sauberer Ownership.

• NACLs als Zonen-Grenze: „Dieses Subnetz darf nur X/Y/Z sprechen“ – grob, selten geändert, auditierbar.
• Security Groups als Workload-Policy: „Dieser Service darf von genau diesen Quellen auf genau diesen Ports erreicht werden“.
• Explizite Egress-Standards: DNS/NTP/Artefakte/Telemetry als definierte Baseline – nicht als ad-hoc Ausnahme.
• Segmentierung nach Rollen: Web, App, Data, Management, Shared – und dazu passende Templates.

Ein hilfreiches Muster: „Guardrail + Least Privilege“

Wenn Sie ein Minimalmodell brauchen, ist folgende Aufteilung oft stabil:

• NACL: Erlaubt nur notwendige Protokolle/Ports für die Subnetzrolle und blockt alles andere (inkl. unerwünschtem East-West-Traffic).
• Security Group: Erzwingt Least Privilege auf Service-Ebene, mit SG-zu-SG-Referenzen statt IP-Fixierung.

Damit bleibt das NACL-Regelwerk klein, während Security Groups die Flexibilität für dynamische Workloads (Autoscaling, Kubernetes Nodes, neue ENIs) liefern.

Troubleshooting: So finden Sie schnell die Schicht, die blockt

Wenn Traffic dropt, verlieren Teams oft Zeit, weil sie nur eine Ebene betrachten. Ein effizientes Vorgehen prüft systematisch die Hypothesen:

• Schritt 1: Richtung und Phase bestimmen – Scheitert DNS, TCP-Connect, TLS oder erst HTTP? Connect/TLS-Probleme deuten häufiger auf Netzwerkfilter hin.
• Schritt 2: Intra-Subnetz vs. Inter-Subnetz vergleichen – Funktioniert es innerhalb eines Subnetzes/AZs, aber nicht über die Grenze? Das spricht für NACL/Route/Policy.
• Schritt 3: Ephemeral-Ports prüfen – Besonders bei NACLs: Rückwege/Client-Ports sind häufig der Grund.
• Schritt 4: Flow Logs / Firewall Logs nutzen – Wenn verfügbar, zeigen sie zumindest, ob Pakete das Subnetz erreichen oder verworfen werden.
• Schritt 5: SG-Referenzen validieren – Wenn Quellen dynamisch sind, ist „IP-Allowlisting“ oft der Fehler. SG-zu-SG ist stabiler.
• Schritt 6: IPv6/IPv4 getrennt testen – Dual-Stack kann „nur eine Familie“ brechen, was wie sporadischer Ausfall wirkt.

Operative Designfehler: Governance, Templates und Change-Management

Viele NACL- und SG-Probleme sind nicht technisch, sondern organisatorisch. Ohne Standards und Ownership entstehen zwei Extreme: Entweder übermäßig offene Regeln („damit es läuft“) oder ein Regelgeflecht, das niemand mehr anfassen will.

• Keine Templates: Jede Anwendung baut ihre eigenen Regeln. Ergebnis: Inkonsistenz, schweres Debugging, Audits werden teuer.
• Kein Review-Prozess: Änderungen werden ad-hoc gemacht. Ergebnis: unbeabsichtigter Blast Radius.
• Fehlende Dokumentation der Dependencies: Teams wissen nicht, warum Egress offen ist. Ergebnis: riskante „Aufräumaktionen“ ohne Beweislage.
• Keine Teststrategie: Es gibt keine synthetischen Probes oder Canary-Validierung. Ergebnis: Fehler werden erst in Produktion sichtbar.

Warum „Default Deny“ ohne Observability gefährlich ist

Default Deny ist ein gutes Ziel, aber nur, wenn Sie Verstöße sichtbar machen: Logs, Metriken und ein Prozess zur schnellen Freigabe. Ohne das wird Default Deny zum Dauer-Incident, weil Teams die Ursache „nur als Timeout“ sehen.

Praxis-Checkliste: Häufigste Fehler und schnelle Gegenmaßnahmen

• NACL blockt Rückverkehr: Ephemeral-Port-Range und bidirektionale Regeln prüfen.
• „Allow steht doch drin“, aber trotzdem Drop: Regelreihenfolge (NACL) und Default-Regeln verifizieren.
• SG ist korrekt, aber Traffic dropt: NACL/Route/Asymmetrie prüfen, nicht nur SG.
• Nur bestimmte Clients betroffen: IPv6 vs. IPv4, unterschiedliche Subnetze, unterschiedliche SG-Zuordnung.
• Nach Scale-Out bricht Zugriff: IP-basierte Regeln durch SG-Referenzen oder definierte Präfixlisten ersetzen.
• „Wir sperren Egress“ und plötzlich TLS/Auth kaputt: DNS/NTP/JWKS/OCSP/Artefaktquellen als Baseline-Dependencies modellieren.

Outbound-Links für verlässliche Referenzen

• AWS: Network ACLs in einer VPC
• AWS: Security Groups – Konzepte und Regeln
• Azure: Network Security Groups – Überblick und Funktionsweise
• Google Cloud: VPC Firewall Rules – Grundlagen und Best Practices
• RFC 793: TCP – Zustandsmodell und Rückverkehr (relevant für stateless Filter)

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.