Sicherheitsgruppen vs. Netzwerk-ACLs: Die Wahl Ihrer AWS VPC-Firewall
Bei der Gestaltung einer sicheren Virtual Private Cloud (VPC)-Umgebung in Amazon Web Services (AWS) verlassen sich Administratoren auf mehrere Kontrollebenen, um den Netzwerkverkehr zu verwalten. Die beiden grundlegenden Komponenten zur Filterung des Traffics auf Netzwerkebene sind Sicherheitsgruppen (SGs) und Netzwerk-Zugriffssteuerungslisten (NACLs).
Obwohl beide als virtuelle Firewalls fungieren und Regeln zur Steuerung des eingehenden und ausgehenden Traffics verwenden, agieren sie auf fundamental unterschiedlichen Schichten der VPC-Architektur und nutzen unterschiedliche Mechanismen zur Regelauswertung. Das Verständnis dieser Unterschiede – insbesondere ihres Geltungsbereichs, ihrer Zustandserhaltung (Statefulness) und ihrer Regelverarbeitung – ist entscheidend für die Etablierung einer robusten und konformen Netzwerksicherheitslage. Dieser Leitfaden bietet einen umfassenden Vergleich und erklärt, wie SGs und NACLs effektiv für eine mehrstufige Verteidigung (Defense in Depth) eingesetzt werden können.
Die Rolle von Firewalls in AWS VPC
AWS bietet Netzwerksicherheit auf zwei primären Ebenen innerhalb einer VPC:
- Instanzebene (Sicherheitsgruppen): Fungiert als Firewall für spezifische EC2-Instanzen oder Ressourcen (wie RDS-Datenbanken oder Elastic Load Balancer). Sie steuert den Traffic zu und von der Netzwerkschnittstelle.
- Subnetz-Ebene (Netzwerk-ACLs): Fungiert als zustandslose Firewall für ganze Subnetze und steuert den Traffic-Fluss, der die Subnetzgrenze passiert.
Tiefer Einblick in Sicherheitsgruppen (SGs)
Sicherheitsgruppen fungieren als primäre, feingranulare Firewall für einzelne Ressourcen. Sie sind zustandsbehaftet (stateful) und operieren auf Schicht 4 (Transportschicht) des OSI-Modells.
Hauptmerkmale von Sicherheitsgruppen
| Merkmal | Beschreibung | Auswirkungen auf die Verwendung |
|---|---|---|
| Geltungsbereich | Gilt direkt für die Elastic Network Interface (ENI) einer Instanz. | Steuert den Traffic-Fluss zu und von der Instanz selbst. |
| Zustandserhaltung (Statefulness) | Zustandsbehaftet (Stateful). Wenn eine eingehende Anfrage explizit erlaubt ist, wird der entsprechende ausgehende Antwortverkehr automatisch erlaubt, unabhängig von ausgehenden Regeln. | Vereinfacht die Konfiguration; es muss nur die initiierende Traffic-Richtung definiert werden. |
| Regeltyp | Nur Erlauben. Explizite Ablehnungsregeln sind nicht möglich. Traffic, der keiner expliziten ALLOW-Regel entspricht, wird implizit abgelehnt. |
Konzentriert sich auf die Definition dessen, was erlaubt ist. |
| Auswertung | Alle Regeln werden ausgewertet, bevor eine Entscheidung getroffen wird. Sie sind nicht nummeriert, und kein implizites DENY wird verarbeitet, bis alle ALLOW-Regeln fehlschlagen. |
Die Reihenfolge ist unerheblich; alle Regeln werden gleich behandelt. |
Konfigurationsbeispiel für Sicherheitsgruppen
Um SSH-Zugriff (Port 22) auf eine EC2-Instanz zu erlauben, benötigen Sie nur eine eingehende Regel. Die ausgehende Regel für die SSH-Antwort wird automatisch durch die Zustandserhaltung (Stateful-Natur) der SG gehandhabt.
| Typ | Protokoll | Portbereich | Quelle | Beschreibung |
|---|---|---|---|---|
| Eingehend | TCP | 22 | 0.0.0.0/0 (oder spezifische Admin-IP) | SSH-Zugriff erlauben |
| Ausgehend | Alle | Alle | 0.0.0.0/0 | (Standard: Erlaubt gesamten Traffic, kann aber bei Bedarf eingeschränkt werden) |
# Konzeptionelle Darstellung eines zustandsbehafteten Flows
Benutzer (Quell-IP) --> [Eingehende SG-Regel: ALLOW 22] --> EC2-Instanz
EC2-Instanz (Antwort) --> [Impliziter Zustand verfolgt] --> Benutzer (Antwort empfangen)
Best-Practice-Tipp: Definieren Sie Sicherheitsgruppenregeln immer nach dem Prinzip der geringsten Rechte. Beschränken Sie die Quell-IP-Bereiche, wann immer möglich, anstatt 0.0.0.0/0 zu erlauben.
Tiefer Einblick in Netzwerk-ACLs (NACLs)
Netzwerk-ACLs bieten eine zweite Verteidigungsebene, die als zustandsloser Filter an der Subnetzgrenze fungiert. Sie sind leistungsstark für die Netzwerksegmentierung und umfassende Ablehnungsrichtlinien.
Hauptmerkmale von Netzwerk-ACLs
| Merkmal | Beschreibung | Auswirkungen auf die Verwendung |
|---|---|---|
| Geltungsbereich | Gilt für ein gesamtes VPC-Subnetz. Ein Subnetz kann immer nur mit einer NACL gleichzeitig verknüpft sein. | Steuert den gesamten Traffic, der in oder aus dem Subnetz tritt, und beeinflusst alle Instanzen darin. |
| Zustandserhaltung (Statefulness) | Zustandslos (Stateless). Sowohl eingehende Anfragen als auch die entsprechenden ausgehenden Antworten müssen explizit erlaubt werden. | Erfordert sorgfältige Konfiguration für den Rückverkehr (ephemere Ports). |
| Regeltyp | Erlauben und Ablehnen. Sie können Regeln explizit definieren, um Traffic zuzulassen oder zu blockieren. | Hervorragend geeignet, um bekannte bösartige IPs zu blockieren oder spezifische Protokolle netzwerkweit abzulehnen. |
| Auswertung | Regeln sind nummeriert (1 bis 32766) und werden sequenziell ausgewertet, beginnend mit der niedrigsten Nummer. Die erste übereinstimmende Regel wird sofort angewendet. | Die Reihenfolge der Regeln ist entscheidend. Die implizite Ablehnungsregel (die zuletzt verarbeitete Regel) lehnt alles ab, was nicht explizit erlaubt wurde. |
Umgang mit zustandslosem Traffic (Ephemere Ports)
Da NACLs zustandslos sind, müssen Sie die von Clients, die sich mit Ihren Servern verbinden, verwendeten ephemeren Ports berücksichtigen. Wenn ein Client eine Verbindung initiiert, verwendet er einen Zielport (z. B. 80 für HTTP) und einen hoch nummerierten Quellport (Bereich der ephemeren Ports, typischerweise 1024-65535).
Um Web-Traffic (HTTP) in ein Subnetz zuzulassen, benötigen Sie zwei Regeln:
- Eingehende Regel: Erlaubt Traffic auf dem Zielport (z. B. 80).
- Ausgehende Regel: Erlaubt Rückverkehr zum Client unter Verwendung der ephemeren Quellports.
| Regel-Nr. | Typ | Protokoll | Portbereich | Quelle/Ziel | Regelaktion |
|---|---|---|---|---|---|
| 100 | Eingehend | TCP | 80 | 0.0.0.0/0 | ERLAUBEN (Web-Traffic eingehend) |
| 110 | Ausgehend | TCP | 1024-65535 | 0.0.0.0/0 | ERLAUBEN (Web-Antwort ausgehend - Ephemere Ports) |
| * | Implizites Ablehnen | Alle | Alle | Alle | ABLEHNEN (Zuletzt verarbeitet) |
Warnung: Wenn Sie die entsprechende ausgehende Regel für ephemere Ports in einer NACL vergessen, erreicht der Traffic die Instanz (aufgrund der eingehenden Regel), aber die Antwort wird an der Subnetzgrenze verworfen, was zu Verbindungs-Timeouts führt.
Vergleichszusammenfassung: SG vs. NACL
Die folgende Tabelle fasst die entscheidenden Unterschiede zwischen den beiden Firewall-Typen zusammen:
| Merkmal | Sicherheitsgruppe (SG) | Netzwerk-ACL (NACL) |
|---|---|---|
| Geltungsbereich | Instanz-/ENI-Ebene | Subnetz-Ebene |
| Zustand | Zustandsbehaftet | Zustandslos |
| Regeltypen | Nur Erlauben | Erlauben und Ablehnen |
| Regelauswertung | Alle Regeln werden ausgewertet, keine spezifische Reihenfolge. | Regeln werden sequenziell nach Nummer ausgewertet (niedrigste zuerst); erste Übereinstimmung gewinnt. |
| Standardverhalten | Lehnt alle eingehenden Verbindungen ab, erlaubt alle ausgehenden (sofern nicht eingeschränkt). | Standard-NACL erlaubt alle eingehenden/ausgehenden Verbindungen. Benutzerdefinierte NACLs lehnen alle eingehenden/ausgehenden Verbindungen ab. |
| Auswirkung auf den Traffic | Wendet Regeln nur an, wenn der Traffic für eine zugeordnete Ressource bestimmt ist oder von dieser stammt. | Filtert Traffic, der die Subnetzgrenze passiert, und beeinflusst alle Ressourcen im Subnetz. |
Die Wahl der richtigen Firewall: Szenarien und Best Practices
Eine erfolgreiche VPC-Sicherheit basiert auf der gemeinsamen Nutzung von SGs und NACLs in einem geschichteten Ansatz (Defense in Depth).
Wann Sicherheitsgruppen priorisiert werden sollten
Sicherheitsgruppen sollten das primäre Werkzeug zur Filterung des Netzwerkzugriffs sein, da sie zustandsbehaftet sind und andere SGs referenzieren können, was die Anwendungskonfiguration vereinfacht.
- Feingranulare Anwendungssteuerung: Verwenden Sie SGs, um genau zu definieren, welche Ports und Protokolle für eine spezifische Anwendung erforderlich sind (z. B. nur Traffic auf Port 3306 vom Webserver-SG zum Datenbank-SG erlauben).
- Interne Kommunikation: Verwalten Sie die Sicherheit für den Traffic zwischen Instanzen innerhalb desselben Subnetzes oder über Subnetze hinweg (z. B. sicherstellen, dass ein Load Balancer mit seinen Zielgruppen kommunizieren kann).
- Einfache Verwaltung: Da sie zustandsbehaftet sind, erfordern SGs weniger Regeln und sind weniger fehleranfällig als die Verwaltung ephemerer Ports mit NACLs.
Wann Netzwerk-ACLs implementiert werden sollten
NACLs eignen sich am besten für die Festlegung breiter, netzwerkweiter Grenzen und Segmentierungsrichtlinien.
- Umfassende Ablehnungsrichtlinien: Verwenden Sie explizite
DENY-Regeln (Regel-Nr. 100), um spezifische, bösartige IP-Adressen oder IP-Bereiche über ein gesamtes Subnetz hinweg zu blockieren, bevor der Traffic überhaupt die Instanzen erreicht. - Subnetzsegmentierung: Setzen Sie strikte Grenzen zwischen den Schichten Ihrer Architektur durch (z. B. sicherstellen, dass die Datenbank-Subnetz-NACL explizit jeglichen eingehenden Traffic aus dem Internet ablehnt, unabhängig davon, wie eine SG konfiguriert sein mag).
- Compliance-Anforderungen: Bestimmte Compliance-Standards können eine Filterung auf Subnetz-Ebene vorschreiben, wodurch NACLs unerlässlich werden.
- Filterung zustandsloser Protokolle: NACLs sind notwendig, wenn Sie zustandslose Protokolle filtern müssen, die SGs allein nicht effektiv verwalten können (obwohl dies bei standardmäßigem TCP/UDP-Traffic selten der Fall ist).
Der Defense-in-Depth-Ansatz
In einer typischen, gut konzipierten VPC muss der Traffic sowohl eine NACL als auch eine Sicherheitsgruppe passieren. Wenn eine der Sicherheitskontrollen den Traffic ablehnt, wird das Paket verworfen.
- Eingehender Fluss: Traffic tritt in das Subnetz ein -> NACL prüft Regeln -> Traffic erreicht die Instanz-ENI -> Sicherheitsgruppe prüft Regeln -> Traffic erreicht die Anwendung.
- Ausgehender Fluss: Anwendung generiert Antwort -> Sicherheitsgruppe (zustandsbehaftete Prüfung bestanden) -> Traffic verlässt die Instanz-ENI -> NACL prüft Regeln -> Traffic verlässt das Subnetz.
Durch die Nutzung der NACL für die grobe Segmentierung und Ablehnungsregeln und der SG für präzise, zustandsbehaftete Berechtigungen auf Anwendungsebene maximieren Sie die Sicherheitseffektivität bei gleichzeitiger Beibehaltung der Konfigurationsvereinfachung.
Fazit
Sicherheitsgruppen und Netzwerk-ACLs sind nicht austauschbar; sie sind komplementäre Werkzeuge, die dazu dienen, verschiedene Schichten Ihrer AWS VPC zu sichern. Sicherheitsgruppen bieten die operative, anwendungsorientierte Sicherheit auf Instanzebene und priorisieren die Vereinfachung durch Zustandserhaltung. Netzwerk-ACLs bieten eine robuste, obligatorische Barriere auf Subnetz-Ebene, indem sie explizite Ablehnungsfunktionen und den Schutz der Netzwerkgrenze ermöglichen. Die Beherrschung der Unterschiede in Geltungsbereich und Zustandserhaltung stellt sicher, dass Sie VPC-Architekturen entwerfen, die nicht nur funktionsfähig, sondern auch widerstandsfähig gegen unautorisierten Netzwerkzugriff sind.