Security Groups (AWS & Azure)

6 Kernkonzepte

Die wichtigsten Konzepte für Security Groups in AWS und Azure: Inbound · Outbound · Quell-IP · Portbereich · Best Practices · Beispiele Security Groups sind virtuelle Firewalls für Cloud-Ressourcen. Sie kontrollieren den Netzwerk-Traffic zu und von Instanzen auf Basis von Regeln für Protokoll, Port und Quelle/Ziel.

Inbound Regeln – Eingehenden Traffic kontrollieren

Quelle · Protokoll · Port · Beschreibung

Inbound Regel Quelle: 0.0.0.0/0 (beliebig) Protokoll: TCP Port: 22 (SSH) Beschreibung: "SSH from anywhere"

Inbound Regeln definieren, welcher Traffic von außen in die Ressource (z.B. EC2-Instanz) gelangen darf. Sie werden durch Quelle, Protokoll und Port definiert.

Typische Inbound Regeln

Port	Protokoll	Quelle	Beschreibung
22	TCP	0.0.0.0/0	SSH (nur mit Key-Pair!)
80	TCP	0.0.0.0/0	HTTP
443	TCP	0.0.0.0/0	HTTPS
3306	TCP	SG-Subnetz	MySQL (nur aus VPC)
3389	TCP	0.0.0.0/0	RDP (Windows)
8080	TCP	0.0.0.0/0	HTTP Alternative

Tipp: Verwenden Sie für SSH (Port 22) und RDP (Port 3389) niemals 0.0.0.0/0. Beschränken Sie den Zugriff auf Ihre eigene IP oder ein VPN.

Outbound Regeln – Ausgehenden Traffic kontrollieren

Ziel · Protokoll · Port · Beschreibung

Outbound Regel Ziel: 0.0.0.0/0 Protokoll: TCP Port: 80, 443 (HTTP/HTTPS) Beschreibung: "Internet access"

Outbound Regeln definieren, welcher Traffic von der Ressource nach außen gesendet werden darf. Standardmäßig ist der gesamte ausgehende Traffic erlaubt.

Typische Outbound Regeln

Port	Protokoll	Ziel	Beschreibung
80	TCP	0.0.0.0/0	HTTP (Updates, APIs)
443	TCP	0.0.0.0/0	HTTPS (Updates, APIs)
53	UDP	0.0.0.0/0	DNS
123	UDP	0.0.0.0/0	NTP (Zeitsynchronisation)
25	TCP	0.0.0.0/0	SMTP (optional)
1024-65535	TCP	0.0.0.0/0	Ephemeral Ports (Rückkanal)

Tipp: Die Standard-Outbound-Regel 0.0.0.0/0 für alle Ports ist praktisch, aber nicht sicher. Beschränken Sie den ausgehenden Traffic auf das Minimum, das Ihre Anwendung benötigt.

AWS Security Groups – EC2, RDS, ELB

SG · VPC · Stateful · Default

# AWS Security Group erstellen aws ec2 create-security-group --group-name web-sg --description "Web Server SG" --vpc-id vpc-xxx # Regel hinzufügen aws ec2 authorize-security-group-ingress --group-id sg-xxx --protocol tcp --port 80 --cidr 0.0.0.0/0

AWS Security Groups sind stateful – der ausgehende Traffic wird automatisch erlaubt, wenn der eingehende Traffic erlaubt wurde. Sie können einer Instanz zugewiesen werden und sind VPC-spezifisch.

AWS Security Group Eigenschaften

Eigenschaft	Beschreibung
Stateful	Return-Traffic wird automatisch erlaubt
VPC-spezifisch	Eine SG gilt nur innerhalb einer VPC
Mehrere SGs	Eine Instanz kann mehreren SGs zugewiesen werden (Union aller Regeln)
Regel-Limit	Maximal 50 Inbound- und 50 Outbound-Regeln pro SG
Quelle	CIDR-Block, eine andere SG oder eine Prefix-Liste

Beispiele

# Web-Server Security Group (AWS CLI)

aws ec2 create-security-group --group-name web-sg --description "Web Server"

# HTTP und HTTPS erlauben

aws ec2 authorize-security-group-ingress --group-id sg-xxx --protocol tcp --port 80 --cidr 0.0.0.0/0

aws ec2 authorize-security-group-ingress --group-id sg-xxx --protocol tcp --port 443 --cidr 0.0.0.0/0

# SSH nur von einer bestimmten IP

aws ec2 authorize-security-group-ingress --group-id sg-xxx --protocol tcp --port 22 --cidr 203.0.113.5/32

# Regel von einer anderen SG erlauben (z.B. für Load Balancer)

aws ec2 authorize-security-group-ingress --group-id sg-xxx --protocol tcp --port 80 --source-group sg-elb

Tipp: Nutzen Sie Security Group Referenzen (Quelle = andere SG) statt IP-CIDR, um den Traffic zwischen Diensten innerhalb der VPC zu vereinfachen – das ist dynamischer und sicherer.

Azure NSG – Network Security Groups

NSG · Subnetz · NIC · Priorität

# Azure NSG erstellen (Azure CLI) az network nsg create --resource-group myRG --name myNSG # Regel hinzufügen az network nsg rule create --nsg-name myNSG --name AllowSSH --priority 100 --direction Inbound --access Allow --protocol Tcp --destination-port-ranges 22 --source-address-prefixes 203.0.113.5/32

Azure Network Security Groups (NSG) sind stateless – Inbound- und Outbound-Regeln müssen separat definiert werden. Sie können auf Subnetz- oder NIC-Ebene zugewiesen werden.

Azure NSG Eigenschaften

Eigenschaft	Beschreibung
Stateless	Inbound- und Outbound-Regeln müssen separat definiert werden
Priorität	Jede Regel hat eine Priorität (100-4096) – niedriger = höhere Priorität
Subnetz/NIC	NSG kann auf Subnetz oder einzelne NIC angewendet werden
Default Regeln	Vordefinierte Regeln (können nicht gelöscht werden, nur überschrieben)
Anwendung	Mehrere NSGs können auf eine NIC/Subnetz angewendet werden (geordnet)

Beispiele (Azure CLI)

# NSG erstellen

az network nsg create --resource-group myRG --name web-nsg --location westeurope

# HTTP und HTTPS für Inbound erlauben

az network nsg rule create --nsg-name web-nsg --name AllowHTTP --priority 100 --direction Inbound --access Allow --protocol Tcp --destination-port-ranges 80

az network nsg rule create --nsg-name web-nsg --name AllowHTTPS --priority 101 --direction Inbound --access Allow --protocol Tcp --destination-port-ranges 443

# SSH nur von einer bestimmten IP

az network nsg rule create --nsg-name web-nsg --name AllowSSH --priority 200 --direction Inbound --access Allow --protocol Tcp --destination-port-ranges 22 --source-address-prefixes 203.0.113.5/32

# NSG mit Subnetz verknüpfen

az network vnet subnet update --resource-group myRG --vnet-name myVNet --name mySubnet --network-security-group web-nsg

Tipp: Azure NSGs sind stateless – vergessen Sie nicht, Outbound-Regeln für Return-Traffic zu definieren, wenn Sie den ausgehenden Traffic einschränken. Die Standard-Outbound-Regel erlaubt allen Traffic.

Best Practices – Sicherheit & Wartbarkeit

Least Privilege · Names · Tags

// Best Practices Least Privilege // Minimal notwendige Rechte Beschreibungen // Jede Regel kommentieren Tags // Security Groups kategorisieren Regelmäßige Audits // Nicht verwendete Regeln entfernen

Best Practices helfen, Security Groups sicher und wartbar zu gestalten. Sie reduzieren Angriffsflächen und erleichtern die Fehlersuche.

Empfehlungen

Praxis	Beschreibung
Least Privilege	Nur die unbedingt notwendigen Ports und Quellen freigeben
Beschreibungen	Jede Regel mit einem aussagekräftigen Kommentar versehen
Benennung	Konsistente Namenskonventionen (z.B. `app-tier-sg`, `db-tier-sg`)
Tags	Security Groups mit Metadaten versehen (Umgebung, Owner, Projekt)
Regelmäßige Audits	Nicht verwendete Regeln und SGs identifizieren und entfernen
IP-Beschränkung	SSH/RDP niemals auf `0.0.0.0/0` freigeben
SG-Referenzen	Innerhalb der VPC andere SGs als Quelle nutzen
Protokoll	Immer das spezifischste Protokoll verwenden (TCP, UDP)

Tipp: Führen Sie regelmäßige Security Group Audits durch. In AWS können Sie den VPC Flow Logs und Trusted Advisor nutzen, um offene Ports und nicht genutzte Regeln zu identifizieren.

Beispiele – Praktische Konfigurationen

Web-Server · DB · Load Balancer

// Typische Security Group Konfigurationen Web-Tier: HTTP (80), HTTPS (443) von 0.0.0.0/0 App-Tier: Port 8080 von Web-SG DB-Tier: Port 3306 von App-SG

Beispiele zeigen typische Security Group Konfigurationen für mehrschichtige Anwendungen mit Web-, Applikations- und Datenbankschicht.

Beispiel: 3-Tier Architektur

# Web-Tier SG (AWS)

Port 80: 0.0.0.0/0 (HTTP)

Port 443: 0.0.0.0/0 (HTTPS)

Port 22: 203.0.113.5/32 (SSH)

# App-Tier SG

Port 8080: sg-web (HTTP/App)

Port 22: 203.0.113.5/32 (SSH)

# DB-Tier SG

Port 3306: sg-app (MySQL)

Port 22: 203.0.113.5/32 (SSH)

# Load Balancer SG (zusätzlich)

Port 80: 0.0.0.0/0 (HTTP)

Port 443: 0.0.0.0/0 (HTTPS)

Ausgehend (Outbound): Port 8080 → sg-app

Erklärung:
1. Web-Tier nimmt externe HTTP/HTTPS Anfragen entgegen
2. App-Tier empfängt Traffic nur von der Web-Tier SG
3. DB-Tier empfängt Traffic nur von der App-Tier SG
4. SSH ist nur von einer Administrator-IP erreichbar

Tipp: In einer 3-Tier-Architektur sollte die Datenbank nie direkt dem Internet ausgesetzt werden. Verwenden Sie Security Group Referenzen für interne Kommunikation.

Security Groups im Überblick

Stateful AWS: Return-Traffic automatisch
Keine separate Outbound-Regel

Stateless Azure: In + Out getrennt
Beide Richtungen definieren

0.0.0.0/0 Alle IP-Adressen
Vorsichtig verwenden!

SG-Referenz Andere SG als Quelle
Nur innerhalb VPC

Least Privilege Minimal notwendige Regeln
Sicherheitsprinzip

Audit Regelmäßige Überprüfung
Nicht verwendete Regeln entfernen

Quick Summary

Inbound

Eingehender Traffic

Outbound

Ausgehender Traffic

AWS

Stateful, VPC

Azure

Stateless, Priorität

Best Practices

Least Privilege, Tags

Beispiele

3-Tier Architektur

Port 22 → 203.0.113.5/32 · Port 80/443 → 0.0.0.0/0 · Port 3306 → sg-app