Beide für Defense in Depth kombinieren

Defense in Depth bedeutet, unabhängige Steuerungselemente zu kombinieren, damit ein Fehler oder eine Lücke in einem Element die Workload nicht ungeschützt lässt. In einer VPC sind Security Groups und Network ACLs zwei solche Ebenen. Zusammen mit Route Tables, WAF und Network Firewall bilden sie überlappende Schutzbarrieren um Ihre Ressourcen.

Security Groups bieten eine granulare, ressourcenbezogene und zustandsbehaftete Kontrolle mit ausschließlich erlaubenden Regeln. NACLs bieten eine grobe, subnetzweite und zustandslose Kontrolle mit Allow und Deny. Wenn Sie beide gemeinsam verwenden, können Sie eine breite Grundlage für das Subnetz festlegen und jede Ressource präzise anpassen.

Damit eingehender Datenverkehr eine Instance erreicht, müssen sowohl die NACL als auch die Security Group ihn erlauben. Eine Verweigerung auf einer der beiden Ebenen verwirft das Paket. Diese UND-Logik bedeutet, dass eine restriktive NACL als zusätzliche Absicherung dient, selbst wenn versehentlich eine zu permissive Security Group erstellt wurde.

Verwenden Sie NACLs, um Leitplanken auf Subnetzebene durchzusetzen, die kein Ressourcenverantwortlicher außer Kraft setzen kann, beispielsweise das Verweigern eines bekannten schädlichen CIDR-Bereichs oder das Blockieren von Datenverkehr zwischen Schichten, die niemals miteinander kommunizieren sollten. Da NACLs grobgranular sind, sollten diese Regeln breit gefasst und stabil bleiben.

Verwenden Sie Security Groups für die alltäglichen Regeln nach dem Prinzip der geringsten Rechte: Öffnen Sie Port 443 für die Webschicht, erlauben Sie der Anwendungsschicht den Zugriff auf die Datenbank und verweisen Sie auf Gruppen statt auf IPs. Hier liegt der größte Teil Ihrer Netzwerkregeln, da diese präzise und zustandsbehaftet sind.

Bei einem klassischen Schichtenmodell befinden sich öffentliche, private Anwendungs- und private Datensubnetze in getrennten Schichten. NACLs verhindern, dass das Datensubnetz direkt mit dem Internet kommuniziert, während Security Groups die Webschicht mit der Anwendungsschicht und diese mit der Datenbank verketten. Selbst wenn ein Angreifer eine Schicht kompromittiert, trifft er in der nächsten weiterhin auf beide Steuerungselemente.

Eine Schichtung verkleinert den Schadensradius einer Kompromittierung. Wenn ein Anwendungsserver kompromittiert wird, verhindern restriktive Security Groups, dass er die Datenschicht scannt, und NACLs unterbinden laterale Bewegungen im gesamten Subnetz. Der Angreifer ist eingeschlossen, statt sich frei in der VPC bewegen zu können.

Bestätigen Sie durch die Analyse von VPC Flow Logs, dass Ihre geschichteten Regeln tatsächlich wie vorgesehen funktionieren. Reject-Einträge zeigen blockierte Versuche; unerwartete Accept-Einträge weisen auf Lücken hin. Kombinieren Sie Flow Logs mit Athena-Abfragen, um zu prüfen, ob der Datenverkehr zwischen den Schichten Ihrem vorgesehenen Design entspricht.

Da NACLs zustandslos sind und standardmäßig auf 20 Regeln pro Richtung begrenzt sind, sollten Sie keine granularen Richtlinien darin abbilden. Eine Überfrachtung von NACLs führt zu Problemen mit kurzlebigen Ports und einer unüberschaubaren Anzahl von Regeln. Halten Sie sie einfach und übertragen Sie die detaillierten Regeln auf Security Groups.

Security Groups und NACLs filtern ausschließlich nach IP, Port und Protokoll. Um HTTP-Inhalte zu untersuchen, SQL-Injection zu blockieren oder nach Domain zu filtern, benötigen Sie höhere Schichten: WAF für Webanfragen und AWS Network Firewall für Deep Packet Inspection. Beide werden später in dieser Kategorie behandelt.

Eine ausgereifte VPC kombiniert Routingtabellen, NACLs, Security Groups, Network Firewall und WAF. Jede Komponente fängt dabei Bedrohungen ab, die die anderen möglicherweise übersehen. In der SCS-C02-Prüfung wird bewertet, ob Sie das richtige Kontrollmittel auf der richtigen Schicht auswählen und die Komponenten kombinieren, statt sich auf eine einzelne zu verlassen.

Überlegen Sie, wie mehrschichtige Kontrollmechanismen zusammenspielen.

Defense in Depth kombiniert NACLs und Security Groups, sodass eine Lücke in der einen Komponente von der anderen abgefangen wird. Beide müssen eingehenden Datenverkehr zulassen, damit dieser passieren kann. Eine restriktive NACL dient daher als zusätzliche Absicherung. Verwenden Sie NACLs für grobe Leitplanken auf Subnetzebene und Security Groups für feine, ressourcenbezogene Least-Privilege-Regeln. Überprüfen Sie die Konfiguration mit Flow Logs, halten Sie NACLs einfach und fügen Sie für inhaltsbasierte Filterung WAF oder Network Firewall hinzu.