Network ACLs vs. Security Groups

AWS stellt innerhalb einer VPC zwei unterschiedliche Firewall-Mechanismen bereit. Security Groups arbeiten auf Instance-Ebene (technisch auf ENI-Ebene) und sind zustandsbehaftet. Network Access Control Lists (NACLs) arbeiten auf Subnetzebene und sind zustandslos. Beide werden für sämtlichen Traffic ausgewertet, der in ein Subnetz oder aus einem Subnetz und den zugehörigen Instances ein- oder ausgeht. Die gemeinsame Verwendung ermöglicht eine mehrschichtige Verteidigung: NACLs als erste Schutzlinie an der Subnetzgrenze und Security Groups als Firewall für einzelne Instances. Die SAA-C03-Prüfung vergleicht diese beiden Mechanismen häufig.

Eine Network ACL (NACL) ist eine nummerierte Liste von Regeln, die auf sämtlichen Traffic angewendet wird, der die Grenze eines Subnetzes überquert. NACLs sind zustandslos – jedes Paket wird unabhängig ausgewertet. Wenn Sie eingehenden TCP-Traffic auf Port 80 zulassen, müssen Sie ausgehenden Rück-Traffic (ephemere Ports 1024–65535) ausdrücklich zulassen, damit die Antwort das Subnetz verlassen kann. Die Regeln werden in numerischer Reihenfolge ausgewertet (niedrigste Nummer zuerst); die erste passende Regel wird angewendet, und es werden keine weiteren Regeln geprüft. Jede VPC enthält eine standardmäßige NACL, die sämtlichen ein- und ausgehenden Traffic zulässt.

NACL-Regeln werden in aufsteigender Reihenfolge der Regelnummer (1 bis 32766) ausgewertet. Die Auswertung endet, sobald eine Regel zutrifft – eine Allow-Regel mit höherer Nummer kann für denselben Traffic durch eine Deny-Regel mit niedrigerer Nummer übersteuert werden. AWS empfiehlt, Regeln in Abständen von 10 oder 100 zu nummerieren, damit später Platz zum Einfügen weiterer Regeln bleibt. Jede NACL endet mit einer Standardregel (* DENY), die sämtlichen Traffic ablehnt, auf den keine explizite Regel zutrifft. Diese Auffangregel kann weder bearbeitet noch gelöscht werden.

Da NACLs zustandslos sind, müssen Sie bei jeder Verbindung beide Richtungen berücksichtigen. Wenn ein Client im Internet eine Verbindung zu Ihrer EC2-Instance über Port 443 herstellt, sendet die Instance die Antwort an den ephemeren Port des Clients zurück (einen zufälligen hohen Port, typischerweise 1024–65535 unter Linux und 49152–65535 unter Windows). Die ausgehenden Regeln Ihrer NACL müssen diesen Bereich ausdrücklich zulassen. Ein häufiger Fehler bei der NACL-Konfiguration besteht darin, eine Allow-Regel für den eingehenden Traffic auf Port 443 zu erstellen, aber die ausgehenden ephemeren Ports nicht zuzulassen. Dadurch werden Verbindungen zwar aufgebaut, Antworten jedoch unbemerkt verworfen.

Zur Erinnerung: Security Groups sind an Instances (oder ENIs) angehängt, lassen nur explizite Allow-Regeln zu (keine Deny-Regeln), sind zustandsbehaftet (Antworten auf zulässigen eingehenden Traffic werden ausgehend automatisch ohne eigene Regel zugelassen) und werten alle angehängten Regeln gemeinsam mit einer ODER-Logik aus. Sie können die IDs anderer Security Groups als Quellen oder Ziele angeben, was wartbarer ist als IP-Bereiche. Security Groups sind der primäre Mechanismus für die Zugriffskontrolle auf Instance-Ebene; NACLs fügen eine zusätzliche Ebene auf Subnetzebene hinzu.

Wichtiger Vergleich für die Prüfung:

• Ebene: NACL = Subnetz; SG = Instance (ENI)
• Zustand: NACL = zustandslos; SG = zustandsbehaftet
• Regeln: NACL = Allow UND Deny; SG = nur Allow (implizites Deny)
• Auswertung: NACL = der Reihe nach (erste passende Regel gewinnt); SG = alle Regeln werden ausgewertet (jede Allow-Regel gewinnt)
• Geltungsbereich: NACL gilt für alle Instances im Subnetz; SG gilt nur für zugeordnete Instances
• Eingehend/Ausgehend: NACL benötigt explizite Regeln in beide Richtungen; SG ist zustandsbehaftet (für Antworten sind nur eingehende Regeln erforderlich)

Verwenden Sie NACLs für: das Blockieren bestimmter IPs (Security Groups können nicht ablehnen, sondern nur zulassen; NACLs können explizite Deny-Regeln hinzufügen, um bekannte schädliche IPs oder Scraper zu blockieren). Subnetzweite Regeln (wenden Sie dieselbe Regel auf alle Instances in einem Subnetz an, ohne einzelne Security Groups zu ändern). Eine zusätzliche Verteidigungsebene (wenn eine Fehlkonfiguration einer Security Group den Zugriff versehentlich öffnet, kann eine Deny-Regel in der NACL an der Subnetzgrenze den Traffic weiterhin blockieren). In der Praxis verwalten die meisten Teams den Zugriff hauptsächlich über Security Groups und verwenden NACLs nur zum expliziten Blockieren von IPs.

Die standardmäßige NACL (die mit jeder VPC erstellt wird) lässt sämtlichen ein- und ausgehenden Traffic zu. Sie enthält die Regeln 100 Allow All Inbound und 100 Allow All Outbound. Subnetze, die nicht ausdrücklich einer benutzerdefinierten NACL zugeordnet sind, verwenden die standardmäßige NACL. Wenn Sie eine benutzerdefinierte NACL erstellen, enthält sie zunächst nur die standardmäßige Deny-All-Regel (Regel *), die sämtlichen Traffic blockiert, bis Sie explizite Allow-Regeln hinzufügen. Das bedeutet, dass das Zuordnen einer neuen benutzerdefinierten NACL zu einem Subnetz sofort sämtlichen Traffic blockiert. Stellen Sie sicher, dass Sie vor der Zuordnung zu Produktionssubnetzen Allow-Regeln hinzufügen.

Bei eingehendem Traffic zu einer EC2-Instance passiert der Traffic zunächst die NACL an der Subnetzgrenze (Auswertung in Regelreihenfolge). Wenn die NACL den Traffic zulässt, erreicht er anschließend die Security Group der Instance – auch die Security Group muss ihn zulassen. Beide müssen den Traffic erlauben, damit er die Instance erreicht. Bei ausgehendem Traffic wird zuerst die Security Group ausgewertet (zustandsbehaftet – sie lässt den Traffic zu, wenn er eine Antwort auf zulässigen eingehenden Traffic ist), danach die NACL (zustandslos – sie muss eine explizite ausgehende Allow-Regel enthalten). Das Verständnis dieser Reihenfolge erklärt, warum bei zustandsbehafteten Security Groups dennoch Regeln für den Rück-Traffic in zustandslosen NACLs erforderlich sind.

NACLs sind aufgrund ihrer Zustandslosigkeit eine häufige Ursache für schwer zu diagnostizierende Netzwerkprobleme. Typische Symptome sind: Verbindungen werden hergestellt, aber die Datenübertragung stoppt (fehlende Regel für ausgehende ephemere Ports); Traffic fließt nur in eine Richtung (eingehende oder ausgehende Regel vergessen); bestimmte IPs können keine Verbindung herstellen (eine Deny-Regel mit niedrigerer Nummer greift vor der Allow-Regel). Verwenden Sie zur Fehlerbehebung VPC Flow Logs, um zu sehen, ob Pakete auf NACL-Ebene mit ACCEPT oder REJECT behandelt werden. Das Flow Log zeigt die abgelehnten Pakete sowie deren Quelle und Ziel und hilft dadurch, die fehlende Regel zu ermitteln.

Das empfohlene Muster für die VPC-Sicherheit in mehreren Ebenen: NACLs in öffentlichen Subnetzen erlauben aus dem Internet nur die Ports 80, 443 und die erforderlichen kurzlebigen Ports; alles andere wird abgelehnt. Sicherheitsgruppen öffentlicher Subnetze am ALB erlauben Port 80/443 von 0.0.0.0/0. Sicherheitsgruppen privater Anwendungen erlauben Zugriffe ausschließlich von der ID der ALB-Sicherheitsgruppe. Sicherheitsgruppen privater Datenbanken erlauben Zugriffe ausschließlich von der ID der Sicherheitsgruppe der Anwendung. Diese mehrschichtige Verteidigung stellt sicher, dass eine andere Ebene weiterhin Schutz bietet, selbst wenn eine Ebene falsch konfiguriert ist – ein Prinzip, das als geringstmöglicher Zugriff auf jeder Ebene bezeichnet wird.

Testen Sie Ihr Verständnis der Konzepte aus dieser Lektion für AWS Solutions Architect (SAA-C03).

In dieser Lektion haben Sie gelernt: NACLs sind zustandslose Firewalls auf Subnetzebene, die sowohl Allow- als auch Deny-Regeln unterstützen, die in nummerierter Reihenfolge ausgewertet werden, Sicherheitsgruppen sind zustandsbehaftete Firewalls auf Instanzebene mit ausschließlich Allow-Regeln, wobei alle Regeln gemeinsam ausgewertet werden, und Sie verwenden NACLs für explizite IP-Sperren und Regeln für das gesamte Subnetz sowie Sicherheitsgruppen für eine fein abgestufte Zugriffssteuerung auf Instanzebene. Damit ist das Modul „VPC-Grundlagen“ abgeschlossen – als Nächstes beschäftigen wir uns mit RDS und relationalen Datenbanken in AWS.