AWS-Security-Group-Regel-Generator

Der AWS Security Group Rule Generator erstellt EC2-Security-Group-Regeln aus strukturierter CSV-Eingabe. Geben Sie Regeln als Zeilen mit Richtung, Protokoll, Portbereich, Quelle/Ziel und Beschreibung ein und erhalten Sie AWS-CLI-Befehle, Terraform-aws_security_group_rule-Ressourcen oder CloudFormation-Vorlagen-Snippets, bereit für skriptgesteuerte, wiederholbare Bereitstellungen.

AWS Security Groups verstehen

Wenn Sie Workloads auf AWS betreiben, sind Security Groups der primäre Mechanismus zur Steuerung des Netzwerkzugriffs auf Ihre EC2-Instanzen, RDS-Datenbanken, Lambda-Funktionen und die meisten anderen vernetzten Ressourcen. Anders als herkömmliche Firewalls, die vor Ihrem Netzwerk stehen, sind Security Groups direkt an Netzwerk-Interfaces angebunden und folgen Ihren Instanzen überall hin -- wenn Sie eine Instanz stoppen und neu starten oder sie an ein anderes Subnetz anhängen, wandern die Security Groups mit.

Das Wichtigste bei AWS Security Groups ist, dass sie zustandsbehaftet und ausschließlich erlaubend sind. Zustandsbehaftet bedeutet, dass wenn Sie eingehenden Datenverkehr auf Port 443 erlauben, der Rückverkehr für diese Verbindung unabhängig von den ausgehenden Regeln automatisch zugelassen wird. Ausschließlich erlaubend bedeutet, dass es keine "Deny"-Aktion gibt -- Sie können keine Regel schreiben, die eine bestimmte IP explizit blockiert. Wenn eine IP-Adresse von keiner Allow-Regel erfasst wird, wird sie implizit abgelehnt. Dies unterscheidet sich grundlegend von iptables oder Azure NSGs, bei denen Sie explizite Deny-Regeln schreiben können, und bedeutet, dass Security Groups am besten geeignet sind, um zu definieren, was Sie erlauben möchten, statt was Sie blockieren wollen. Für explizite Ablehnungen benötigen Sie Network ACLs auf Subnetzebene.

Die Verwaltung von Security Groups über die AWS-Konsole funktioniert für eine Handvoll Regeln, bricht aber in Produktionsumgebungen schnell zusammen. Eine typische dreischichtige Webanwendung hat möglicherweise separate Security Groups für den Load Balancer, die Webserver, die Anwendungsserver und die Datenbank -- jeweils mit fünf bis zehn Regeln. Über die Konsole vorgenommene Änderungen werden nicht nachverfolgt, können vor der Bereitstellung nicht überprüft werden und sind schwer über mehrere Umgebungen hinweg zu replizieren. Dieser Generator ermöglicht einen Infrastructure-as-Code-Workflow: Definieren Sie Ihre Regeln in einer Tabelle, generieren Sie CLI-Befehle oder Terraform-Code, prüfen Sie in einem Pull Request und stellen Sie konsistent über Entwicklungs-, Staging- und Produktionsumgebungen bereit.

So generieren Sie AWS Security Group-Regeln

1. Bereiten Sie Ihre Regeldaten im CSV-Format mit den Spalten vor: Richtung, Protokoll, Portbereich, Quelle/Ziel und Beschreibung.
2. Fügen Sie die CSV in den Generator ein oder laden Sie sie hoch.
3. Wählen Sie das Ausgabeformat: AWS CLI, Terraform HCL oder CloudFormation JSON/YAML.
4. Geben Sie die Ziel-Security-Group-ID ein (z. B. sg-0123456789abcdef0).
5. Kopieren Sie die generierten Befehle oder Konfigurationsblöcke für die Bereitstellung.

CSV-Eingabeformat und generierte Ausgabe

CSV-Eingabe

direction,protocol,from_port,to_port,source,description
ingress,tcp,443,443,0.0.0.0/0,HTTPS from internet
ingress,tcp,22,22,10.0.0.0/8,SSH from internal
ingress,tcp,3306,3306,sg-0abcdef1234567890,MySQL from app tier
egress,tcp,443,443,0.0.0.0/0,HTTPS outbound
ingress,-1,-1,-1,sg-0abcdef1234567890,All traffic from app tier

AWS CLI-Ausgabe

aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --ip-permissions '[{"IpProtocol":"tcp","FromPort":443,"ToPort":443,"IpRanges":[{"CidrIp":"0.0.0.0/0","Description":"HTTPS from internet"}]}]'

aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --ip-permissions '[{"IpProtocol":"tcp","FromPort":22,"ToPort":22,"IpRanges":[{"CidrIp":"10.0.0.0/8","Description":"SSH from internal"}]}]'

aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --ip-permissions '[{"IpProtocol":"tcp","FromPort":3306,"ToPort":3306,"UserIdGroupPairs":[{"GroupId":"sg-0abcdef1234567890","Description":"MySQL from app tier"}]}]'

Terraform-Ausgabe

resource "aws_security_group_rule" "https_from_internet" {
  type              = "ingress"
  from_port         = 443
  to_port           = 443
  protocol          = "tcp"
  cidr_blocks       = ["0.0.0.0/0"]
  security_group_id = "sg-0123456789abcdef0"
  description       = "HTTPS from internet"
}

resource "aws_security_group_rule" "ssh_from_internal" {
  type              = "ingress"
  from_port         = 22
  to_port           = 22
  protocol          = "tcp"
  cidr_blocks       = ["10.0.0.0/8"]
  security_group_id = "sg-0123456789abcdef0"
  description       = "SSH from internal"
}

AWS Security Group-Quelltypen

Wann den AWS Security Group Generator verwenden

• VPC-Aufbau -- Generieren Sie alle Security-Group-Regeln für eine neue VPC-Bereitstellung aus einem einzigen CSV-Planungsdokument.
• Compliance-Automatisierung -- Konvertieren Sie Sicherheitsrichtlinien-Tabellen in durchsetzbare AWS-CLI-Befehle oder Terraform-Code.
• Konsistenz über mehrere Konten -- Generieren Sie identische Security-Group-Regelsätze für die Bereitstellung über Entwicklungs-, Staging- und Produktionskonten hinweg.
• Migration aus On-Premises -- Übersetzen Sie bestehende iptables- oder Firewall-Regeln bei der Cloud-Migration in das AWS-Security-Group-Format.
• Audit und Dokumentation -- Exportieren Sie bestehende Regeln als CSV, überprüfen Sie diese und regenerieren Sie saubere Konfigurationen.

Wie AWS Security Groups funktionieren

Zustandsbehaftetes Verhalten

AWS Security Groups sind zustandsbehaftet -- wenn Sie eingehenden Datenverkehr auf Port 443 erlauben, wird der Rückverkehr unabhängig von den ausgehenden Regeln automatisch zugelassen. Dies unterscheidet sich von iptables oder nftables, wo Sie Rückverkehr explizit erlauben oder Connection Tracking verwenden müssen.

Regellimits

Jede Security Group unterstützt standardmäßig bis zu 60 eingehende Regeln und 60 ausgehende Regeln (anpassbar über einen Kontingenterhöhungsantrag). Jeder CIDR-Block, jede Security-Group-Referenz oder Präfixliste zählt als eine Regel. Verwenden Sie den Allowlist Builder, um die Anzahl der CIDR-Einträge zu minimieren.

Auswertung

Alle Regeln in einer Security Group werden gemeinsam ausgewertet -- es gibt keine Reihenfolge. Wenn eine beliebige Regel den Datenverkehr erlaubt, wird er zugelassen. Es gibt keine "Deny"-Aktion in Security Groups; das Fehlen einer passenden Allow-Regel ist eine implizite Ablehnung. Für explizite Deny-Regeln verwenden Sie stattdessen Network ACLs.

Security-Group-Referenzen

Eine der leistungsfähigsten Funktionen von AWS Security Groups ist die Möglichkeit, andere Security Groups als Quellen oder Ziele zu referenzieren. Anstatt CIDR-Blöcke für Ihre Anwendungsserver anzugeben, referenzieren Sie die Security-Group-ID der Anwendungsschicht. Das bedeutet, dass wenn Sie Instanzen zur Anwendungsschicht hinzufügen oder daraus entfernen, die Datenbank-Security-Group automatisch den Zugriff gewährt oder entzieht, ohne dass Regeländerungen erforderlich sind.

Praktische Hinweise zu AWS Security Groups

Der häufigste Fehler bei der Verwaltung von Security Groups ist die zu großzügige Verwendung von 0.0.0.0/0 (gesamter Datenverkehr). In der Eile, Dinge zum Laufen zu bringen, öffnen Techniker SSH (Port 22) für 0.0.0.0/0 "vorübergehend" und vergessen, es später einzuschränken. AWS Security Hub und Config Rules können dies erkennen, aber Prävention ist besser als Erkennung. Verwenden Sie Security-Group-Referenzen für die Kommunikation zwischen Schichten, beschränken Sie SSH auf das VPN oder die Security Group des Bastion-Hosts und begrenzen Sie 0.0.0.0/0 auf Ports, die wirklich öffentlichen Zugang benötigen (typischerweise nur 80 und 443 auf Load Balancern).

Bei der Arbeit mit Terraform bevorzugen Sie die Verwendung von aws_security_group_rule-Ressourcen (die dieser Generator erzeugt) gegenüber Inline-ingress- und egress-Blöcken innerhalb einer aws_security_group-Ressource. Inline-Regeln und separate Regelressourcen stehen miteinander in Konflikt, und separate Ressourcen sind einfacher zu verwalten, zu überprüfen und bedingt anzuwenden. Sie verhindern auch das Problem "alle Regeln ändern sich, wenn sich eine ändert", das Inline-Blöcke verursachen.

Regelbeschreibungen sind nicht optional -- sie sind die Dokumentation für Ihr zukünftiges Ich. AWS zeigt Beschreibungen in der Konsole an, und sie erscheinen in Sicherheitsaudits und Compliance-Berichten. Jede Regel sollte das "Warum" dieses Zugangs beantworten: "SSH vom VPN-Gateway" ist besser als "SSH" oder gar keine Beschreibung. Der Generator übernimmt Ihre CSV-Beschreibungen in die Ausgabe, also nehmen Sie sich die Zeit, aussagekräftige zu schreiben.

Häufig gestellte Fragen

Was bedeutet Protokoll -1 in AWS Security Groups? Protokoll -1 bedeutet "gesamter Datenverkehr" -- es erfasst TCP, UDP, ICMP und alle anderen IP-Protokolle. Bei Verwendung von Protokoll -1 setzen Sie sowohl from_port als auch to_port ebenfalls auf -1. So stellt AWS eine "alles erlauben"-Regel dar.

Kann ich eine Security Group in einer anderen VPC referenzieren? Ja, bei gepeerten VPCs. Verwenden Sie die vollständige Security-Group-ID und stellen Sie sicher, dass VPC-Peering konfiguriert ist. Der Generator gibt die GroupId-Referenz aus; für kontoübergreifende Referenzen benötigen Sie zusätzlich die Kontoinhaber-ID.

Wie gehe ich mit IPv4- und IPv6-CIDR-Blöcken um? Der Generator erzeugt automatisch separate IpRanges-(für IPv4) und Ipv6Ranges-(für IPv6)-Einträge basierend auf dem Adressformat. Eine Regel für 0.0.0.0/0 deckt nur IPv4 ab; fügen Sie eine separate Regel für ::/0 hinzu, um IPv6 abzudecken.

Was ist der Unterschied zwischen Security Groups und Network ACLs? Security Groups sind zustandsbehaftet, auf Instanzebene und ausschließlich erlaubend. Network ACLs sind zustandslos, auf Subnetzebene und unterstützen explizite Deny-Regeln. Die meisten Konfigurationen verwenden Security Groups als primäre Kontrolle und Network ACLs als zusätzliche Defense-in-Depth.

Wie bleibe ich innerhalb des 60-Regel-Limits? Aggregieren Sie CIDR-Blöcke mit dem Allowlist Builder, verwenden Sie Security-Group-Referenzen statt einzelner IPs für die Kommunikation zwischen Schichten und kombinieren Sie Portbereiche wo möglich (z. B. from_port: 8000, to_port: 8080 statt 80 einzelner Regeln). Sie können auch eine Kontingenterhöhung über die AWS-Service-Quotas-Konsole beantragen.

Kann ich Regeln für mehrere Security Groups gleichzeitig generieren? Der Generator zielt auf eine einzelne Security Group pro Durchlauf. Für Multi-Group-Konfigurationen führen Sie ihn einmal pro Security Group mit den entsprechenden Regeln für jede Schicht aus. Dies entspricht den Best Practices für die Trennung von Zuständigkeiten im Security-Group-Design.

Verwandte Tools

• Azure NSG Rule Generator - Generierung von Azure NSG-Regeln aus CSV
• iptables Rule Generator - Generierung von iptables-Regeln aus CSV
• Allowlist Builder - Erstellung einer minimalen CIDR-Allowlist aus einer IP-Liste
• Blocklist Builder - Erstellung einer minimalen CIDR-Blocklist aus einer IP-Liste
• Rule Conflict Finder - Auffinden von doppelten, überdeckten oder überlappenden Firewall-Regeln