Einführung
Der öffentliche Pfad einer Lieferanwendung funktioniert bereits, aber die bereitgestellte Zugriffsregel erlaubt HTTP von jeder IPv4-Quelle. Du gibst der Anwendung eine eigene Sicherheitsgruppe, die nur den vorgesehenen Client und Port zulässt. Echte Anfragen zeigen, wie Quellen- und Portbeschränkungen sowie zustandsbehaftete Antworten den Zugriff beeinflussen.
Schließe zuerst „Ein öffentliches Subnetz mit dem Internet verbinden“ ab. Diese neue Umgebung stellt ihr eigenes Netzwerk, ihre öffentliche Adresse, Routen und Anwendung bereit; sie verwendet nicht deine frühere VM. Die CLI ist bereits konfiguriert. Erhalte die bereitgestellten Ressourcen und das unabhängige Referenznetzwerk. Nur deine neue Sicherheitsgruppe ist eine zu löschende Übungsressource.
Bezug zu Zertifizierungen
Dieses Lab bietet praktische Übungen zu folgenden Prüfungsthemen.
- Cloud Practitioner (CLF-C02) · Aufgabe 3.5: Zugriffskontrolle durch Sicherheitsgruppen in einer VPC.
- Solutions Architect – Associate (SAA-C03) · Aufgabe 1.2: Grundlegende Anwendungssicherheit für Netzwerkquellen, Ports und Protokolle.
- CloudOps Engineer – Associate (SOA-C03) · Aufgaben 5.1 und 5.3: Grundlegende Sicherheitsgruppenkonfiguration und Prüfung ihrer Auswirkungen auf die Konnektivität.
- Security – Specialty (SCS-C03) · Aufgabe 3.3: Grundlagenübung zum Erlauben und Verhindern erforderlichen Verkehrs mit Sicherheitsgruppen.
Eine leere Übungssicherheitsgruppe zuordnen
In diesem Schritt prüfst du die funktionierende Anwendung und ersetzt ihre großzügige Zugriffsgruppe durch deine eigene leere Gruppe.
Führe Befehle in Terminal aus und klicke daneben auf AWS View. Die Ansicht liest denselben Ressourcenstatus wie die CLI. Sie zeigt application-network, dessen öffentliches und privates Subnetz sowie eine Anwendung mit der privaten Adresse 10.20.1.10. Die öffentliche Adresse und die Internet-Gateway-Route sind bereits bereitgestellt; lasse sie unverändert.
cd /home/labex/project
Wähle die VPC anhand ihres Name-Tags. --filters begrenzt die Serverergebnisse, --query wählt die ID aus und $(...) speichert das Ergebnis in einer Shell-Variablen:
VPC_ID=$(aws ec2 describe-vpcs \
--filters Name=tag:Name,Values=application-network \
--query 'Vpcs[0].VpcId' \
--output text)
Wähle die bereitgestellte Anwendungsschnittstelle innerhalb dieser VPC:
ENI_ID=$(aws ec2 describe-network-interfaces \
--filters "Name=vpc-id,Values=$VPC_ID" Name=tag:Name,Values=application-interface \
--query 'NetworkInterfaces[0].NetworkInterfaceId' \
--output text)
Eine Sicherheitsgruppe steuert erlaubten Verkehr an der Netzwerkschnittstelle einer zugeordneten Ressource. Eingehende Regeln erlauben Verkehr zur Anwendung; ausgehende Regeln erlauben von ihr initiierte Verbindungen. Speichere die ID der einzigen bereitgestellten Gruppe, damit du sie bei der Bereinigung wieder zuordnen kannst. [0] wählt das erste Element dieser Liste mit nur einer Gruppe:
SUPPLIED_GROUP_ID=$(aws ec2 describe-network-interfaces \
--network-interface-ids "$ENI_ID" \
--query 'NetworkInterfaces[0].Groups[0].GroupId' \
--output text)
Lies ihre Regeln, ohne sie zu ändern:
aws ec2 describe-security-groups \
--group-ids "$SUPPLIED_GROUP_ID" \
--query 'SecurityGroups[].{ID:GroupId,Inbound:IpPermissions,Outbound:IpPermissionsEgress}' \
--output json
Die bereitgestellte Gruppe erlaubt eingehenden TCP-Verkehr auf Port 80 von 0.0.0.0/0, also jeder IPv4-Quelle, sowie sämtlichen ausgehenden Verkehr. HTTP verwendet Anfragen und Antworten; ein Port kennzeichnet den empfangenden Dienst. Diese Anwendung bietet HTTP auf den TCP-Ports 80 und 8081, die bereitgestellte Regel erlaubt aber nur Port 80.
Klicke in AWS View auf Request application · client A und danach auf Request application · client B. Beide liefern auf Port 80 Success und Application online. Client A nutzt 198.51.100.10, Client B 198.51.100.20. Klicke auf Request port 8081; diese Anfrage von Client A schlägt fehl, weil der Port nicht erlaubt ist.
Erstelle eine eigene Gruppe in derselben VPC. --group-name setzt den Namen, --description erklärt den Zweck und die Tag-Spezifikation in Anführungszeichen fügt Eigentums-Tags als ein Argument hinzu. Speichere die neue ID:
GROUP_ID=$(aws ec2 create-security-group \
--group-name parcel-web \
--description "Parcel HTTP access" \
--vpc-id "$VPC_ID" \
--tag-specifications 'ResourceType=security-group,Tags=[{Key=Name,Value=parcel-web},{Key=Project,Value=parcel}]' \
--query 'GroupId' \
--output text)
Eine neue Gruppe hat keine eingehenden Freigaben und erlaubt sämtlichen ausgehenden Verkehr. Sicherheitsgruppen enthalten Erlaubnisregeln, keine expliziten Verweigerungsregeln. Verkehr ohne passende Erlaubnisregel wird blockiert.
--groups ersetzt die Gruppenliste der Schnittstelle. Ordne nur deine neue Gruppe zu; die zusätzliche Beibehaltung der großzügigen Gruppe würde ihre Berechtigungen kombinieren und beide Clients weiterhin zulassen:
aws ec2 modify-network-interface-attribute \
--network-interface-id "$ENI_ID" \
--groups "$GROUP_ID"
Eine erfolgreiche Änderung erzeugt keine Ausgabe. Bestätige, dass die Schnittstelle jetzt nur deine Gruppe hat:
aws ec2 describe-network-interfaces \
--network-interface-ids "$ENI_ID" \
--query 'NetworkInterfaces[].{ID:NetworkInterfaceId,Groups:Groups}' \
--output json
AWS View zeigt jetzt parcel-web und Inbound · none. Sende neue Anfragen von den Clients A und B; beide werden zu Connection failed. Öffentliche Adresse und Route bleiben erhalten, die leere Gruppe erlaubt aber keine eingehende Anfrage. Lasse dieses Terminal geöffnet, um die gespeicherten IDs zu behalten.
Nur den vorgesehenen HTTP-Client zulassen
In diesem Schritt erlaubst du Client A den Zugriff auf Port 80 und prüfst, dass die andere Quelle und der andere Port blockiert bleiben.
Eine eingehende Regel gibt ein Protokoll, einen Portbereich und eine Quelle an. --protocol tcp wählt TCP, --port 80 diesen einzelnen Port und --cidr 198.51.100.10/32 nur die IPv4-Adresse von Client A. Ein /32 enthält eine IPv4-Adresse und ist enger gefasst als 0.0.0.0/0.
Füge die Regel deiner Gruppe hinzu, nicht der bereitgestellten Gruppe:
aws ec2 authorize-security-group-ingress \
--group-id "$GROUP_ID" \
--protocol tcp \
--port 80 \
--cidr 198.51.100.10/32
Die Antwort zeigt den Erfolg und kann die neue Regel-ID enthalten. Lies sämtliche eingehenden Regeln:
aws ec2 describe-security-groups \
--group-ids "$GROUP_ID" \
--query 'SecurityGroups[].IpPermissions' \
--output json
Es gibt eine TCP-Regel mit FromPort und ToPort jeweils 80 und der Quelle 198.51.100.10/32. AWS View zeigt dieselbe eingehende Quelle und denselben Port.
Klicke auf Request application · client A. Das Ergebnis ist Success, Quelle 198.51.100.10, Zielport 80 und Antwortinhalt Application online. Dies ist eine echte Antwort der bereitgestellten Anwendung.
Klicke nun auf Request application · client B und Request port 8081. Beide liefern Connection failed. Die erste Anfrage hat die falsche Quelle; die zweite verwendet Client A, aber den falschen Port. Öffentliche Adresse und Route stellen einen Pfad bereit, während die Sicherheitsgruppe festlegt, welcher Verkehr ihn nutzen darf.
Eine vorübergehende Portfreigabe testen und entfernen
In diesem Schritt zeigst du, dass ein zweiter lauschender Port nur mit einer eigenen Regel erreichbar ist, und entfernst anschließend die vorübergehende Freigabe.
Die bereitgestellte Anwendung bietet HTTP auch auf Port 8081. Behalte dieselbe erlaubte Quelle bei und füge eine vorübergehende Regel für diesen Port hinzu:
aws ec2 authorize-security-group-ingress \
--group-id "$GROUP_ID" \
--protocol tcp \
--port 8081 \
--cidr 198.51.100.10/32
Lies die Regeln erneut:
aws ec2 describe-security-groups \
--group-ids "$GROUP_ID" \
--query 'SecurityGroups[].IpPermissions' \
--output json
Jetzt gibt es zwei TCP-Regeln: Ports 80 und 8081, jeweils auf Client A beschränkt. AWS View zeigt beide. Klicke auf Request port 8081. Das Ergebnis wird zu Success, mit Zielport 8081 und Antwortinhalt Application online. Damit ist bestätigt, dass der zweite Dienst läuft; der frühere Fehler war eine Beschränkung durch die Zugriffsregel.
AWS-View-Beispiel: Beide eng gefassten eingehenden Regeln sind vorhanden und Client A erhält die Anwendungsantwort auf Port 8081. Die erzeugten Ressourcen-IDs unterscheiden sich in deiner Umgebung.
Die Übung benötigt nur Port 80. Das Widerrufen einer Regel entfernt ihre Erlaubnis. Gib dasselbe Protokoll, denselben Port und dieselbe Quelle an, um nur die vorübergehende Regel zu entfernen:
aws ec2 revoke-security-group-ingress \
--group-id "$GROUP_ID" \
--protocol tcp \
--port 8081 \
--cidr 198.51.100.10/32
Die Antwort zeigt den Erfolg. Frage die verbleibenden Regeln ab:
aws ec2 describe-security-groups \
--group-ids "$GROUP_ID" \
--query 'SecurityGroups[].IpPermissions' \
--output json
Nur die Port-80-Regel von Client A bleibt erhalten. Sobald AWS View die 8081-Regel entfernt, klicke erneut auf Request port 8081; die Anfrage schlägt nun fehl. Client A ist auf Port 80 weiterhin erfolgreich, Client B auf Port 80 weiterhin blockiert. Du hast eine Portfreigabe geändert, statt die Anwendung oder ihre Route zu ersetzen.
Zustandsbehaftete HTTP-Antworten beobachten
In diesem Schritt entfernst du die ausgehende Standardregel deiner Gruppe und bestätigst, dass Antworten auf erlaubte eingehende HTTP-Anfragen weiterhin funktionieren.
Sicherheitsgruppen sind zustandsbehaftet: Die Antwort auf eine erlaubte eingehende Anfrage kann die Anwendung verlassen, auch wenn keine ausgehende Regel eine neue Verbindung erlaubt. Eine ausgehende Regel steuert von der Anwendung initiierte Verbindungen; für diese HTTP-Antwort ist sie nicht erforderlich.
Lies deine aktuellen ausgehenden Berechtigungen:
aws ec2 describe-security-groups \
--group-ids "$GROUP_ID" \
--query 'SecurityGroups[].IpPermissionsEgress' \
--output json
Die neue Gruppe hat das Standardziel 0.0.0.0/0 für sämtlichen Verkehr. Im nächsten Befehl nimmt --ip-permissions eine JSON-Liste von Regelspezifikationen als ein Argument in Anführungszeichen entgegen. Der IpProtocol-Wert -1 bedeutet alle Protokolle und IpRanges kennzeichnet die Ziele einer ausgehenden Regel. Entferne genau diese Standardregel:
aws ec2 revoke-security-group-egress \
--group-id "$GROUP_ID" \
--ip-permissions '[{"IpProtocol":"-1","IpRanges":[{"CidrIp":"0.0.0.0/0"}]}]'
Die Antwort zeigt den Erfolg. Lies beide Richtungen:
aws ec2 describe-security-groups \
--group-ids "$GROUP_ID" \
--query 'SecurityGroups[].{Inbound:IpPermissions,Outbound:IpPermissionsEgress}' \
--output json
Eingehend ist weiterhin nur Client A auf Port 80 erlaubt; ausgehend ist leer. AWS View zeigt Outbound · none. Klicke erneut auf Request application · client A. Success und Application online werden weiterhin zurückgegeben: Die Antwort gehört zur erlaubten eingehenden Verbindung.
Prüfe Request application · client B und Request port 8081 erneut. Beide schlagen weiterhin fehl. Zustandsbehaftete Antworten erlauben keinen neuen eingehenden Zugriff von einer anderen Quelle oder auf einen anderen Port. Dieser Test belegt das Antwortverhalten; er testet keine neue, von der Anwendung initiierte ausgehende Verbindung.
AWS-View-Beispiel: Eingehend ist nur Client A auf Port 80 erlaubt, ausgehend ist leer und die echte HTTP-Antwort gelingt weiterhin. Die erzeugten Ressourcen-IDs unterscheiden sich in deiner Umgebung.
Die bereitgestellte Gruppe wiederherstellen und deine löschen
In diesem Schritt stellst du die ursprüngliche Anwendungszuordnung wieder her und löschst nur deine Übungssicherheitsgruppe.
Eine einer Netzwerkschnittstelle zugeordnete Gruppe kann nicht gelöscht werden. Ersetze zuerst deine Gruppe durch die gespeicherte bereitgestellte Gruppe; lösche oder bearbeite die bereitgestellte Gruppe nicht:
aws ec2 modify-network-interface-attribute \
--network-interface-id "$ENI_ID" \
--groups "$SUPPLIED_GROUP_ID"
Bestätige die Zuordnung:
aws ec2 describe-network-interfaces \
--network-interface-ids "$ENI_ID" \
--query 'NetworkInterfaces[].{ID:NetworkInterfaceId,Groups:Groups}' \
--output json
Nur die ursprüngliche Gruppe supplied-application ist zugeordnet. Lösche jetzt deine nicht mehr verwendete Gruppe:
aws ec2 delete-security-group --group-id "$GROUP_ID"
Eine erfolgreiche Löschung erzeugt keine Ausgabe. Frage den vollständigen Gruppenbestand ab, damit die Abwesenheit unabhängig von entfernbaren Tags feststeht:
aws ec2 describe-security-groups \
--query 'SecurityGroups[].{ID:GroupId,Name:GroupName,VPC:VpcId}' \
--output table
parcel-web fehlt. Die bereitgestellte Gruppe und Standardgruppen bleiben erhalten, ebenso VPCs, Subnetze, Anwendungsschnittstelle, öffentliche Adresse und Routen. Eine fehlgeschlagene Bestandsabfrage beweist keine Löschung.
AWS View zeigt wieder supplied-application. Klicke auf die Anfragebuttons für Client A und B; beide Port-80-Anfragen liefern Success, wie im ursprünglichen Zustand. Request port 8081 schlägt fehl, weil die unveränderte bereitgestellte Gruppe nur Port 80 erlaubt.
Führen Sie die Abschlussprüfung dieses Schritts aus.
Zusammenfassung
Du hast eine eigene Sicherheitsgruppe erstellt und zugeordnet, nur Client A auf TCP-Port 80 zugelassen, eine vorübergehende Freigabe für einen zweiten Port getestet und widerrufen sowie zustandsbehaftete HTTP-Antworten ohne ausgehende Freigaben bestätigt. Echte Anfragen unterschieden erlaubten und blockierten Verkehr. Abschließend hast du die bereitgestellte Gruppe wiederhergestellt und nur deine eigene Übungsgruppe gelöscht.
Fahre mit „Einem privaten Subnetz ausgehenden Zugriff geben“ fort, um den ausgehenden Pfad einer privaten Anwendung aufzubauen, ohne unaufgeforderten externen Zugriff zuzulassen.
