valentint - Fotolia

Firewall und ACL einer AWS Virtual Private Cloud konfigurieren

Sobald eine AWS VPC angelegt ist, sollte diese abgesichert werden. Erst durch Firewall und ACL sind EC2-Instanzen der VPC bereit für weitere Aufgaben.

Nachdem wir im ersten Artikel dieser AWS-Reihe die IAM-Umgebung (Identity Access Management) aufgesetzt und im zweiten Artikel die grundlegende Virtual Private Cloud konfiguriert haben, zeigen wir in diesem Artikel die weitere Konfiguration der AWS VPC mit Firewall und Netzwerk-ACL (Access Control List).

Klickt man nach dem Erstellen der grundlegenden Virtual Private Cloud im VPC-Dashboard auf Your VPCs, taucht die neue VPC (gegebenenfalls neben anderen vorhandenen VPCs) in der VPC-Liste auf.

Markiert man diese, sind im unteren Bereich unterhalb des zugehörigen AWS-Namens für die VPC (hier vpc-e653d48e) die drei Reiter Summary, Flow Logs und Tags zu sehen, wobei der Reiter Tags das oben im Verlauf des Assistenten vergebene Tag Name=VPC TechTarget zeigt.

Tags dienen zum schnellen Durchsuchen des AWS-Inventars nach AWS-Objekten. Im Reiter Summary finden sich Details wie der eingegebene CIDR-Block (Classless Inter-Domain Routing) und zwei Links, welche auf verwandte Ressourcen führen, zum Beispiel eine DHCP-OptionSet, die standardmäßig weit offene Netzwerk-ACL und die Routing-Tabelle, hier rtb-85a5ded.

Die Summary-Ansicht der ersten Virtual Private Cloud.
Abbildung 1: Die Summary-Ansicht der ersten Virtual Private Cloud.

Klickt man im VPC Dashboard auf Subnets, so ist das neu erstellte Subnetz Public Subnet1 TechTarget zu sehen. Markiert man es, zeigt der Reiter Summary analog zur VPC die Details des Subnetzes an, wobei wieder alle blau gefärbten Einträge Links sind, zum Beispiel auf die übergeordnete VPC, die Network ACL und die Routing-Tabelle des Subnetzes.

Die Summary-Ansicht des ersten öffentlichen Subnetzes.
Abbildung 2: Die Summary-Ansicht des ersten öffentlichen Subnetzes.

Letztere sollte man dann zur Kontrolle auch anklicken. Alternativ wechselt man direkt zum Tab Route Table.

Hier ist zu erkennen, dass diese Routing-Tabelle das Subnetz wie erwartet mit dem per Default erzeugten Internetgateway Igw-cae3e6a3 verbindet. Das bedeutet, dass jede EC2-Instanz, die später in diesem Subnetz erzeugt wird, aus dem Internet erreichbar ist, indem sie eine öffentliche IP-Adresse aus dem AWS-Pool erhält, während Datenverkehr „aus“ dem VPC 10.0.0./16 auf das Target local zeigt. Die vorhandenen Internet-Gateways finden sich, wie zu erwarten, im VPC-Dashboard im Menü Internet Gateways. Markiert man hier das gerade erwähnte Gateway, hat es hier im Summary-Tab den Status attached und bei Attached VPC ID: verweist der blaue Link vpc-e653d48e wieder auf die angeschlossene VPC. Ein Klick darauf würde wieder zurück zur VPC-Ansicht führen.

Das bei einem öffentlichen Subnetz automatisch erstellte Internet-Gateway macht die VPC von außen erreichbar.
Abbildung 3: Das bei einem öffentlichen Subnetz automatisch erstellte Internet-Gateway macht die VPC von außen erreichbar.

Es ist jederzeit möglich, weitere Internet-Gateways zu erstellen. Alternativ gibt es noch so genannte Egress Only Internet Gateways. Für die Gegenrichtung ist es außerdem jederzeit möglich, ein NAT-Gateway zu erstellen. Ein solches erlaubt es bei Bedarf in einem privaten Subnetz gestarteten EC2-Instanzen, via Masquerading Kontakt mit der Außenwelt aufzunehmen.

Der Assistent zum Erstellen eines NAT-Gateways verlangt lediglich die Angabe des öffentliches Subnetzes, in dem das NAT-Gateway positioniert werden soll, sowie eine so genannte Elastic IP (EIP), welche sich im Zuge des NAT-Gateway-Assistenten mit Create New EIP erstellen lässt. Alternativ kann man auch manuell eine EC2-Instanz mit Linux erstellen und darin IPCop oder ahnliche Tools installieren.

Elastic IPs sind öffentliche IP-Adressen, die einer Instanz (in diesem Sinne ist auch das NAT-Gateway eine virtuelle Maschine) zugeordnet werden können. Im Unterschied zu dynamischen IPs, die bei jedem Start einer in einem öffentlichen Subnetz gestarteten EC2-Instanz dynamisch aus Amazons Adress-Pool vergeben werden, bleiben EIPs auch nach dem Terminieren einer Instanz erhalten und mit dem Nutzerkonto zur weiteren Verwendung verbunden. Zusätzliche Kosten verursachen EIPs nur dann, wenn sie nicht explizit einer aktiven Instanz zugeordnet sind, womit Amazon ein Horten von EIPs verhindern will.

Firewall und ACLs der AWS VPC einrichten

Nun sind beinahe alle Elemente der VPC erkundet. Was hier noch fehlt sind Sicherheitsgruppen und Netzwerk-ACLs. Bei beiden logischen Konstrukten handelt es sich im Prinzip um Firewalls. Beide werden im VPC-Dashboard im Bereich Security konfiguriert. Network-ACLs operieren auf Subnetz-Ebene, damit steuern sie also nicht den Traffic, der ein Subnetz erreicht oder verlässt und wirken so weniger granular als Sicherheitsgruppen, die auf Instanzenebene operieren.

Da AWS für jede VPC stets eine Default-Network-ACL generiert, die jegliche Traffic-Art (Type = All Traffic, Protocol = ALL, Port-Range = ALL) in das verbundene (Reiter Subnet Associations) Subnetz (Reiter Inbound Rules, Source=0.0.0.0/0) und aus dem verbundenen Subnetz (Reiter Outbound Rules, Destination=0.0.0.0/0) erlaubt, also „wide open“ ist, kann man Netwerk-ACLs solange ignorieren, bis man sie zur Erhöhung der Sicherheit benötigt.

Netzwerk-ACLs steuern den Traffic-Fluss zwischen Subnetzen anhand von Policies.
Abbildung 4: Netzwerk-ACLs steuern den Traffic-Fluss zwischen Subnetzen anhand von Policies.

Anders bei Security Groups. Eine Sicherheitsgruppe fungiert als virtuelle Firewall auf Ebene einzelner Instanzen. Darin erstellt man Regeln für den ein- und ausgehenden Datenverkehr und weist anschließend der Security Group die gewünschten Instanzen zu.

Security Groups steuern den Traffic-Flow von und zu den einzelnen Instanzen.
Abbildung 5: Security Groups steuern den Traffic-Flow von und zu den einzelnen Instanzen.

Hierbei steuern konkret Inbound Rules, welcher Datenverkehr die der Sicherheitsgruppe zugewiesenen Instanzen erreicht. Die im Reiter Outbound Rules angegebenen Regeln steuern hingegen, an welche Ziele die der Sicherheitsgruppe zugewiesenen Instanzen Datenverkehr senden dürfen. Dabei arbeiten Security Groups im Gegensatz zu Network ACLs nach dem Prinzip der Stateful Packet Inspection.

Auch hier erzeugt AWS stets eine mit der VPC verknüpfte Standard-Sicherheitsgruppe, der automatisch sämtliche Instanzen zugewiesen sind, die nicht explizit vom Admin in eine andere Security Group befördert werden. Da Security Groups vor allem auch im Zusammenhang mit EC2-Instanzen von Bedeutung sind, werden sie im nächsten Teil dieser Workshop-Reihe näher behandelt.

Folgen Sie SearchDataCenter.de auch auf Twitter, Google+, Xing und Facebook!

Artikel wurde zuletzt im April 2017 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Public-Cloud-Infrastruktur

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchEnterpriseSoftware.de

Close