Sicherheitsgruppen vs. Netzwerk-ACLs: Auswahl Ihrer AWS VPC-Firewall
Navigieren Sie durch die Komplexität der AWS VPC-Sicherheit, indem Sie die Unterschiede zwischen Sicherheitsgruppen (SGs) und Netzwerk-ACLs (NACLs) meistern. Dieser Expertenleitfaden erklärt den Umfang, die Zustandsbehaftung und die Regelauswertung beider Kontrollen. Erfahren Sie, warum SGs ideal für granularen, zustandsbehafteten Instanzschutz sind, während NACLs für breite, zustandslose Subnetzsegmentierung und explizite Verweigerungsrichtlinien unerlässlich sind. Implementieren Sie eine robuste, mehrschichtige Firewall-Strategie für Ihre Cloud-Infrastruktur.
Sicherheitsgruppen vs. Netzwerk-ACLs: Auswahl 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 zum Filtern von Datenverkehr auf Netzwerkebene sind Sicherheitsgruppen (SGs) und Netzwerkzugriffskontrolllisten (NACLs).
Sie sehen in der Konsole ähnlich aus, aber sie versagen auf sehr unterschiedliche Weise. Sicherheitsgruppen sind normalerweise der Ort, an dem Sie die Anwendungsabsicht beschreiben. Netzwerk-ACLs sind der Ort, an dem Sie breite Subnetzgrenzen oder Notfallverweigerungen durchsetzen.
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 bestimmte EC2-Instanzen oder Ressourcen (wie RDS-Datenbanken oder Elastic Load Balancer). Sie steuert den Datenverkehr zur und von der Netzwerkschnittstelle.
- Subnetzebene (Netzwerk-ACLs): Fungiert als zustandslose Firewall für gesamte Subnetze und steuert den Datenverkehr, der die Subnetzgrenze betritt oder verlässt.
Tiefer Einblick in Sicherheitsgruppen (SGs)
Sicherheitsgruppen fungieren als primäre, granulare Firewall für einzelne Ressourcen. Sie sind zustandsbehaftet und filtern nach Protokoll, Port und Quelle oder Ziel.
Hauptmerkmale von Sicherheitsgruppen
| Merkmal | Beschreibung | Auswirkungen auf die Nutzung |
|---|---|---|
| Umfang | Gilt direkt für die Elastic Network Interface (ENI) einer Instanz. | Steuert den Datenverkehr zu und von der Instanz selbst. |
| Zustandsbehaftung | Zustandsbehaftet. Wenn eine eingehende Anfrage explizit erlaubt ist, wird der entsprechende Rückverkehr (ausgehende Antwort) automatisch erlaubt, unabhängig von ausgehenden Regeln. | Vereinfacht die Konfiguration; nur die Richtung des initiierenden Datenverkehrs muss definiert werden. |
| Regeltyp | Nur erlauben. Explizite Verweigerungsregeln sind nicht möglich. Datenverkehr, der keiner expliziten ALLOW-Regel entspricht, wird implizit verweigert. |
Konzentriert sich darauf, zu definieren, was erlaubt ist. |
| Auswertung | Alle Regeln werden ausgewertet, bevor eine Entscheidung getroffen wird. Sie sind nicht nummeriert, und es wird keine implizite DENY verarbeitet, bis alle ALLOW-Regeln fehlschlagen. |
Die Reihenfolge spielt keine Rolle; alle Regeln werden gleich behandelt. |
Beispiel für die Konfiguration einer Sicherheitsgruppe
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 zustandsbehaftete Natur der SG behandelt.
| 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 Datenverkehr, kann aber bei Bedarf eingeschränkt werden) |
# Konzeptionelle Darstellung eines zustandsbehafteten Flusses
Benutzer (Quell-IP) --> [Eingehende SG-Regel: ERLAUBE 22] --> EC2-Instanz
EC2-Instanz (Antwort) --> [Implizite Zustandsverfolgung] --> Benutzer (Antwort empfangen)
Best-Practice-Tipp: Definieren Sie Sicherheitsgruppenregeln immer nach dem Prinzip der geringsten Privilegien. Beschränken Sie Quell-IP-Bereiche wann immer möglich, anstatt 0.0.0.0/0 zuzulassen.
Tiefer Einblick in Netzwerk-ACLs (NACLs)
Netzwerk-ACLs bieten eine zweite Verteidigungsebene und fungieren als zustandsloser Filter an der Subnetzgrenze. Sie sind leistungsstark für die Netzwerksegmentierung und breite Verweigerungsrichtlinien.
Hauptmerkmale von Netzwerk-ACLs
| Merkmal | Beschreibung | Auswirkungen auf die Nutzung |
|---|---|---|
| Umfang | Gilt für ein gesamtes VPC-Subnetz. Ein Subnetz kann jeweils nur einer NACL zugeordnet sein. | Steuert den gesamten Datenverkehr, der das Subnetz betritt oder verlässt, und betrifft alle Instanzen darin. |
| Zustandsbehaftung | Zustandslos. Sowohl eingehende Anfragen als auch die entsprechenden ausgehenden Antworten müssen explizit erlaubt werden. | Erfordert sorgfältige Konfiguration für Rückverkehr (ephemere Ports). |
| Regeltyp | Erlauben und Verweigern. Sie können explizit Regeln definieren, um Datenverkehr zuzulassen oder zu blockieren. | Hervorragend geeignet, um bekannte bösartige IPs zu blockieren oder bestimmte Protokolle netzwerkweit zu verweigern. |
| Auswertung | Regeln sind nummeriert (1 bis 32766) und werden sequentiell ausgewertet, beginnend mit der niedrigsten Nummer. Die erste übereinstimmende Regel wird sofort angewendet. | Die Regelreihenfolge ist entscheidend. Die implizite Verweigerungsregel (die zuletzt verarbeitete Regel) verweigert alles, was nicht explizit erlaubt wurde. |
Umgang mit zustandslosem Datenverkehr (Ephemere Ports)
Da NACLs zustandslos sind, müssen Sie die ephemeren Ports berücksichtigen, die von Clients verwendet werden, die eine Verbindung zu Ihren Servern herstellen. Wenn ein Client eine Verbindung initiiert, verwendet er einen Zielport (z. B. 80 für HTTP) und einen hochnummerierten Quellport (ephemerer Portbereich, typischerweise 1024-65535).
Um Webdatenverkehr (HTTP) in ein Subnetz zuzulassen, benötigen Sie zwei Regeln:
- Eingehende Regel: Erlaubt Datenverkehr auf dem Zielport (z. B. 80).
- Ausgehende Regel: Erlaubt Rückverkehr zum Client unter Verwendung der ephemeren Quellports.
| Regel # | Typ | Protokoll | Portbereich | Quelle/Ziel | Regelaktion |
|---|---|---|---|---|---|
| 100 | Eingehend | TCP | 80 | 0.0.0.0/0 | ERLAUBEN (Webverkehr rein) |
| 110 | Ausgehend | TCP | 1024-65535 | 0.0.0.0/0 | ERLAUBEN (Webantwort raus - Ephemere Ports) |
| * | Implizite Verweigerung | Alle | Alle | Alle | VERWEIGERN (Zuletzt verarbeitet) |
Warnung: Wenn Sie die entsprechende ausgehende Regel für ephemere Ports in einer NACL vergessen, erreicht der Datenverkehr die Instanz (aufgrund der eingehenden Regel), aber die Antwort wird an der Subnetzgrenze verworfen, was zu Verbindungszeitüberschreitungen 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) |
|---|---|---|
| Anwendungsbereich | Instanz-/ENI-Ebene | Subnetzebene |
| Zustand | Zustandsbehaftet | Zustandslos |
| Regeltypen | Nur Erlauben | Erlauben und Verweigern |
| Regelauswertung | Alle Regeln ausgewertet, keine bestimmte Reihenfolge. | Regeln werden sequentiell nach Nummer ausgewertet (niedrigste zuerst); erster Treffer gewinnt. |
| Standardverhalten | Verweigert alle eingehenden, erlaubt alle ausgehenden (sofern nicht eingeschränkt). | Standard-NACL erlaubt alle eingehenden/ausgehenden. Benutzerdefinierte NACLs verweigern alle eingehenden/ausgehenden. |
| Auswirkung auf Datenverkehr | Wendet Regeln nur an, wenn Datenverkehr für eine zugeordnete Ressource bestimmt ist oder von ihr stammt. | Filtert Datenverkehr, der die Subnetzgrenze passiert, und betrifft alle Ressourcen im Subnetz. |
Auswahl der richtigen Firewall: Szenarien und Best Practices
Erfolgreiche VPC-Sicherheit beruht auf der gemeinsamen Verwendung von SGs und NACLs in einem mehrschichtigen Ansatz (Defense in Depth).
Wann Sicherheitsgruppen priorisiert werden sollten
Sicherheitsgruppen sollten das primäre Werkzeug zum Filtern des Netzwerkzugriffs sein, aufgrund ihrer zustandsbehafteten Natur und der Fähigkeit, auf andere SGs zu verweisen, was die Anwendungskonfiguration vereinfacht.
- Feingranulare Anwendungssteuerung: Verwenden Sie SGs, um genau zu definieren, welche Ports und Protokolle für eine bestimmte Anwendung erforderlich sind (z. B. nur Datenverkehr auf Port 3306 von der Webserver-SG zur Datenbank-SG zulassen).
- Interne Kommunikation: Verwalten Sie die Sicherheit für den Datenverkehr 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 werden am besten verwendet, um breite, netzwerkweite Grenzen und Segmentierungsrichtlinien festzulegen.
- Breite Verweigerungsrichtlinien: Verwenden Sie explizite
DENY-Regeln (Regel #100), um bestimmte bösartige IP-Adressen oder IP-Bereiche in einem gesamten Subnetz zu blockieren, bevor der Datenverkehr die Instanzen überhaupt erreicht. - Subnetzsegmentierung: Erzwingen Sie strenge Grenzen zwischen den Schichten Ihrer Architektur (z. B. sicherstellen, dass die NACL des Datenbank-Subnetzes allen eingehenden Datenverkehr aus dem Internet explizit verweigert, unabhängig davon, wie eine SG konfiguriert sein könnte).
- Compliance-Anforderungen: Bestimmte Compliance-Standards können eine Filterung auf Subnetzebene vorschreiben, was NACLs unerlässlich macht.
- Zustandslose Protokollfilterung: NACLs sind erforderlich, wenn Sie zustandslose Protokolle filtern müssen, die SGs nicht effektiv selbst verwalten können (obwohl dies für standardmäßigen TCP/UDP-Datenverkehr selten ist).
Fehler, die zu Ausfällen führen
Der häufigste NACL-Ausfall ist das Vergessen des Rückverkehrs. Jemand erlaubt eingehenden TCP 443 in ein öffentliches Subnetz und lässt die ausgehenden Regeln zu restriktiv. Der Load Balancer oder die Instanz empfängt das SYN, aber die Antwort wird auf dem Weg nach draußen verworfen. Von der Client-Seite sieht es wie eine Zeitüberschreitung aus, und von der Instanz-Seite kann der Dienst völlig gesund erscheinen.
Ein weiterer Fehler ist die Verwendung von NACLs für anwendungsspezifische Richtlinien. Wenn ein Subnetz Web-, Worker- und Admin-Instanzen enthält, gilt eine NACL für alle. Eine für eine Arbeitslast hinzugefügte Regel kann eine andere Arbeitslast im selben Subnetz unerwartet freigeben oder beeinträchtigen. Wenn Sie unterschiedliches Netzwerkverhalten benötigen, verwenden Sie unterschiedliche Sicherheitsgruppen und erwägen Sie separate Subnetze nur, wenn eine echte Grenze durchgesetzt werden muss.
Auch die Regelnummerierung verdient Aufmerksamkeit. Lassen Sie Lücken wie 100, 110, 120 anstelle von 1, 2, 3, damit Sie später Notfallregeln einfügen können. Denken Sie daran, dass der erste Treffer gewinnt. Eine Verweigerung bei Regel 90 schlägt eine Erlaubnis bei Regel 100, selbst wenn die Erlaubnis für die Person, die schnell auf die Konsole schaut, spezifischer erscheint.
Bei Sicherheitsgruppen ist der häufige Fehler breite Quellbereiche. 0.0.0.0/0 auf 443 für einen öffentlichen Load Balancer kann normal sein. Dieselbe Quelle auf SSH, RDP, Redis, PostgreSQL oder einer internen Admin-API ist normalerweise ein Problem. Bevorzugen Sie Sicherheitsgruppenverweise innerhalb der VPC und enge CIDRs für den Operatorzugriff.
Wenn Sie eine vorhandene VPC übernehmen, exportieren Sie die Regeln und gruppieren Sie sie nach Absicht: öffentliche Einstiegspunkte, App-zu-App-Datenverkehr, Datenspeicher, Administration und Notfallverweigerungen. Regeln ohne klaren Eigentümer oder Grund sind der Ort, an dem normalerweise veraltete Exposition lebt.
Der Defense-in-Depth-Ansatz
In einer typischen, gut gestalteten VPC muss der Datenverkehr sowohl eine NACL als auch eine Sicherheitsgruppe passieren. Wenn eine der beiden Sicherheitskontrollen den Datenverkehr verweigert, wird das Paket verworfen.
- Eingehender Fluss: Datenverkehr betritt das Subnetz -> NACL prüft Regeln -> Datenverkehr erreicht Instanz-ENI -> Sicherheitsgruppe prüft Regeln -> Datenverkehr erreicht die Anwendung.
- Ausgehender Fluss: Anwendung generiert Antwort -> Sicherheitsgruppe (Zustandsbehaftete Prüfung bestanden) -> Datenverkehr verlässt Instanz-ENI -> NACL prüft Regeln -> Datenverkehr verlässt das Subnetz.
Durch die Nutzung der NACL für grobe Segmentierung und Verweigerungsregeln und der SG für präzise, zustandsbehaftete, anwendungsspezifische Berechtigungen maximieren Sie die Sicherheitseffektivität, während Sie die Konfiguration einfach halten.
Ein praktisches Entwurfsmuster
Beginnen Sie für die meisten Anwendungs-VPCs mit Sicherheitsgruppen. Geben Sie dem Load Balancer eine öffentlich zugängliche Sicherheitsgruppe, geben Sie den Anwendungsinstanzen eine Sicherheitsgruppe, die nur Datenverkehr von der Sicherheitsgruppe des Load Balancers akzeptiert, und geben Sie der Datenbank eine Sicherheitsgruppe, die nur Datenverkehr von der Sicherheitsgruppe der Anwendung auf dem Datenbankport akzeptiert. Dieses Modell folgt dem Abhängigkeitsgraphen der App und überlebt IP-Änderungen.
Verwenden Sie NACLs sparsamer. Ein guter NACL-Anwendungsfall ist eine Verweigerung auf Subnetzebene für eine bekannte schlechte CIDR, eine harte Grenze um ein Datenbank-Subnetz oder eine Compliance-Regel, die angewendet werden muss, bevor Datenverkehr eine ENI im Subnetz erreicht. NACLs werden schmerzhaft, wenn Teams versuchen, jede Anwendungsregel dort zu spiegeln. Die zustandslosen Rücklauf-Port-Regeln sind leicht falsch zu machen, und eine niedrig nummerierte Verweigerung kann ein ganzes Subnetz lahmlegen.
Wenn eine Verbindung eine Zeitüberschreitung aufweist, überprüfen Sie beide Ebenen im Paketpfad. Für eingehenden Internetverkehr zu einer EC2-Instanz in einem öffentlichen Subnetz muss die Anfrage die eingehende NACL-Regel, die Routingtabelle und die eingehende Sicherheitsgruppenregel passieren. Die Antwort muss die zustandsbehaftete Sicherheitsgruppenverfolgung und die ausgehende NACL-Regel passieren. Wenn SGs korrekt aussehen, aber Clients immer noch hängen, ist die NACL-Regel für ephemere Ports oft das fehlende Stück.
Das sauberste mentale Modell ist dieses: Sicherheitsgruppen sagen, welche Ressourcen mit welchen anderen Ressourcen sprechen dürfen; NACLs sagen, was das Subnetz niemals zulassen wird. Halten Sie diese Aufgaben getrennt, und das Design bleibt einfacher zu prüfen.