Security Groups und Schlüsselpaare

Eine Security Group ist eine virtuelle zustandsbehaftete Firewall, die den eingehenden und ausgehenden Datenverkehr zu und von einer EC2-Instanz (oder anderen AWS-Ressourcen wie RDS, Lambda und ELB) steuert. Security Groups arbeiten auf der Instanzebene – jede Regel legt ein Protokoll (TCP/UDP/ICMP), einen Portbereich und eine Quelle bzw. ein Ziel (IP-Bereich oder eine andere Security Group) fest. Im Gegensatz zu herkömmlichen Firewalls sind Security Groups zustandsbehaftet: Wenn Sie eingehenden Datenverkehr zulassen, wird der Antwortverkehr automatisch ausgehend zugelassen, ohne dass dafür eine explizite Regel erforderlich ist.

Security Groups verfügen über separate Regelgruppen für eingehenden und ausgehenden Datenverkehr. Regeln für eingehenden Datenverkehr steuern den Datenverkehr, der bei der Instanz eintrifft – standardmäßig wird der gesamte eingehende Datenverkehr verweigert. Regeln für ausgehenden Datenverkehr steuern den Datenverkehr, der die Instanz verlässt – standardmäßig ist der gesamte ausgehende Datenverkehr zulässig. Sie fügen explizite Allow-Regeln hinzu; explizite Deny-Regeln gibt es bei Security Groups nicht (verwenden Sie Network ACLs für explizite Ablehnungen). Alle Regeln einer Security Group werden gemeinsam nach einer logischen ODER-Verknüpfung ausgewertet – jede passende Allow-Regel lässt den Datenverkehr zu.

Security Groups unterstützen Verweise auf Security Groups als Quelle oder Ziel. Dies ist flexibler und sicherer als die Angabe von IP-Bereichen. Beispielsweise lässt eine ALB-Security-Group Datenverkehr von 0.0.0.0/0 auf Port 443 zu. Die Security Group der EC2-Instanzen lässt eingehenden Datenverkehr auf Port 8080 nur von der ID der ALB-Security-Group zu – nicht von einer beliebigen IP-Adresse. Wenn ein ALB ersetzt oder skaliert wird, gilt die Regel weiterhin korrekt, ohne dass IP-Adressen geändert werden müssen. Dieses Muster schafft eine geschichtete, dynamische Schutzmaßnahme für mehrstufige Architekturen.

Zustandsbehaftet bedeutet, dass die Security Group den Verbindungsstatus verfolgt. Wenn Ihre eingehende Regel TCP-Port 80 aus dem Internet zulässt und ein Client eine Anfrage stellt, werden die Antwortpakete (ausgehend) automatisch an den Client zurück zugelassen – auch wenn keine ausgehende Regel für Port 80 vorhanden ist. Dies unterscheidet sich grundlegend von Network ACLs, die zustandslos sind und explizite Regeln für beide Richtungen des Datenverkehrs erfordern. Die Zustandsbehaftung erleichtert die Konfiguration von Security Groups für typische Datenverkehrsmuster von Anwendungen.

Sie können einer einzelnen EC2-Instanz mehrere Security Groups zuordnen (standardmäßig bis zu 5, anpassbar). Die Regeln aller zugeordneten Security Groups werden mittels einer Vereinigungsmenge (ODER-Logik) kombiniert – wenn eine beliebige Security Group eine Anfrage zulässt, wird die Anfrage gestattet. Das bedeutet, dass Security Groups Berechtigungen nur hinzufügen, niemals einschränken können. Wenn Sie den Zugriff verschärfen möchten, müssen Sie Regeln entfernen oder ändern und dürfen nicht einfach eine restriktivere Security Group hinzufügen. Berücksichtigen Sie dieses additive Verhalten bei Prüfungsfragen zur Zugriffsbeschränkung.

Jede VPC enthält eine Standard-Security-Group. Ihre Standardregeln: Eingehender Datenverkehr von anderen Instanzen, die sich ebenfalls in der Standard-Security-Group befinden, ist vollständig zulässig; ausgehender Datenverkehr zu allen Zielen ist zulässig. Dies ist bewusst großzügig gestaltet, damit neue Instanzen standardmäßig miteinander kommunizieren können. Erstellen Sie für Produktionsumgebungen eine benutzerdefinierte Security Group mit streng beschränkten Regeln für eingehenden Datenverkehr und entfernen Sie Zuordnungen von Instanzen zur Standard-Security-Group, um eine versehentliche Offenlegung zu vermeiden.

EC2-Key Pairs verwenden asymmetrische Kryptografie zur SSH-Authentifizierung. AWS generiert das Key Pair (oder Sie importieren Ihren eigenen öffentlichen Schlüssel): AWS speichert den öffentlichen Schlüssel und fügt ihn beim Start in die Instanz ein; Sie laden den privaten Schlüssel (Datei .pem) herunter und speichern ihn – AWS speichert ihn niemals. SSH verwendet den privaten Schlüssel, um Ihre Identität gegenüber dem Server nachzuweisen, ohne ein Passwort zu übertragen. Der private Schlüssel muss über restriktive Berechtigungen verfügen (chmod 400), andernfalls verweigert SSH seine Verwendung.

Wenn Sie den privaten Schlüssel für eine Linux-EC2-Instanz verlieren, können Sie sich nicht auf herkömmliche Weise per SSH anmelden. Zu den Wiederherstellungsoptionen gehören: Systems Manager Session Manager (wenn der SSM-Agent ausgeführt wird und eine IAM-Rolle zugeordnet ist – kein Schlüssel erforderlich), EC2 Instance Connect (fügt über den Browser oder die CLI einen temporären Schlüssel ein – erfordert einen geöffneten SSH-Port und EIC-Berechtigungen) oder die Instanz stoppen, das Root-EBS-Volume trennen, es an eine andere Instanz anhängen, die Datei authorized_keys ändern, das Volume wieder anhängen und die Instanz neu starten. Verwenden Sie bei Windows Systems Manager, um das Passwort abzurufen.

Wenn Sie SSH (Port 22) für 0.0.0.0/0 öffnen, ist Ihre Instanz Brute-Force- und Credential-Stuffing-Angriffen aus dem gesamten Internet ausgesetzt. Best Practices: Beschränken Sie SSH auf Ihren spezifischen IP-Bereich des Unternehmens oder verwenden Sie einen Bastion Host (Jump Host) in einem öffentlichen Subnetz mit einer streng kontrollierten Security Group. Stellen Sie anschließend per SSH vom Bastion Host aus eine Verbindung zu privaten Instanzen her. Noch besser ist die Verwendung von Systems Manager Session Manager, um die Offenlegung des SSH-Ports vollständig zu vermeiden – es sind überhaupt keine Regeln für eingehenden Datenverkehr erforderlich.

Wichtige Standardlimits für Security Groups (über Service Quotas anpassbar): bis zu 2.500 Security Groups pro VPC, 60 Regeln für eingehenden und 60 Regeln für ausgehenden Datenverkehr pro Security Group sowie 5 Security Groups pro Netzwerkschnittstelle. Wenn Sie eine andere Security Group als Quelle referenzieren, zählt jede Kombination aus referenzierter Security Group und Regel als eine Regel. Wenn Sie Regel-Limits erreichen, konsolidieren Sie die Regeln, indem Sie Security-Group-IDs statt einzelner IP-Bereiche referenzieren, oder verwenden Sie Prefix Lists, um mehrere CIDRs in einer verwaltbaren Einheit zusammenzufassen.

Eine verwaltete Prefix List ist eine Sammlung von CIDR-Blöcken, auf die Sie in Regeln von Security Groups oder in Routingtabellen verweisen können. AWS verwaltet AWS-managed Prefix Lists für Services wie S3 und CloudFront. Dadurch können Sie Datenverkehr zu diesen Services oder von ihnen zulassen, ohne IP-Bereiche selbst pflegen zu müssen, die sich im Laufe der Zeit ändern. Sie können auch customer-managed Prefix Lists erstellen, um Ihre Unternehmens-IP-Bereiche zu gruppieren. Wenn Sie die Prefix List an einer Stelle aktualisieren, übernehmen alle darauf verweisenden Security Groups die Änderung automatisch.

In dieser Lektion haben Sie gelernt: Security Groups sind zustandsbehaftete virtuelle Firewalls, die standardmäßig den Datenverkehr verweigern, die Verkettung von Security Groups über ihre ID ist sicherer und flexibler als die Verwendung von IP-Bereichen und Key Pairs ermöglichen eine asymmetrische SSH-Authentifizierung, während Systems Manager Session Manager offene SSH-Ports überflüssig macht. Als Nächstes behandeln wir die EC2-Speicheroptionen: Instance Store im Vergleich zu EBS.