Kontrolliere den Zugriff auf deine Website

AWSBeginner
Jetzt üben

Einführung

Entferne und erneuere eine EC2-Regel, beobachte echte Verbindungen und bewahre die SSH-Regel.

Schließe die vorherigen Portfolio-Labs ab. Dieses Lab liefert eigene Ressourcen und benötigte frühere Fähigkeiten. Übernimm Wissen, keine alten Instanzen, Dateien oder Zugangsdaten.

Zertifizierungsbezug

Zertifizierung Aufgaben Übung
AWS Certified Cloud Practitioner (CLF-C02) Task 3.5 EC2-Verbindungen mit einer Sicherheitsgruppe steuern.

Überblick

Entferne und erneuere eine EC2-Regel, beobachte echte Verbindungen und bewahre die SSH-Regel.

Eine blockierte Verbindung beobachten

In diesem Schritt entfernst du nur die Website-Regel und vergleichst die Seitenantwort mit dem Serverstatus.

Dieses Lab stellt einen neuen Server bereit. Öffne das Portfolio aus seinem AWS View und prüfe Alex Morgan, bevor du etwas änderst. Gehe zurück zu Terminal und in den Projektordner:

cd /home/labex/project

Wie zuvor lädt source die Kennungen des aktuellen Servers. Zeige SECURITY_GROUP_ID, die zu ändernde Gruppe:

source website.env
echo "$SECURITY_GROUP_ID"

Eine Sicherheitsgruppe steuert Netzwerkverbindungen einer Instanz. Eine eingehende Regel erlaubt Verbindungen zu ihr. Ein Port bezeichnet den Dienst: SSH nutzt 22, diese HTTP-Website 8081. Andere Websites verwenden oft HTTP 80 oder HTTPS 443; hier gilt der konfigurierte Port dieser Anwendung.

Lies die Gruppe vor der Änderung:

Wie im ersten Lab wählt --query einen Teil der Antwort aus. Hier bleiben nur die eingehenden Regeln der ersten Gruppe, SecurityGroups[0].IpPermissions, damit du dich auf die beiden benötigten Berechtigungen konzentrieren kannst.

aws ec2 describe-security-groups \
  --group-ids "$SECURITY_GROUP_ID" \
  --query 'SecurityGroups[0].IpPermissions'

Die Ausgabe zeigt nur die eingehenden Regeln. FromPort und ToPort geben den Bereich an. Finde getrennte Regeln für 22 und 8081. Die Quelle 198.51.100.10/32 steht für einen vorbereiteten Besucher; /32 bedeutet eine IPv4-Adresse. Es ist nicht die öffentliche Adresse deines Computers, daher behalte den Wert bei.

Entferne nur die Website-Berechtigung. revoke-security-group-ingress entfernt die passende Regel; --protocol tcp wählt das Protokoll, --port 8081 den Webdienst und --cidr die erlaubte Quelle:

aws ec2 revoke-security-group-ingress \
  --group-id "$SECURITY_GROUP_ID" \
  --protocol tcp \
  --port 8081 \
  --cidr 198.51.100.10/32

Die Antwort bestätigt die Änderung. Lade das Portfolio neu: Es sollte Website connection unavailable melden, während die Instanz in AWS View weiterhin running ist.

Eine neue Website-Anfrage scheitert nach Entfernen der Regel; der Server läuft weiter.

AWS View zeigt weiterhin running, obwohl der Website-Zugriff blockiert ist; Kennungen sind Beispiele.

Die Anwendung wurde nicht deinstalliert und der Server nicht angehalten: Eine Netzwerkregel blockiert die Verbindung. Sicherheitsgruppen verfolgen erlaubte Verbindungen; die neue Anfrage dieser Übung prüft die geänderte Regel. Lass die SSH-Regel unverändert.

Website-Zugriff wiederherstellen

In diesem Schritt stellst du die konkrete Berechtigung wieder her und prüfst die Antwort der Anwendung.

authorize-security-group-ingress fügt eine eingehende Regel hinzu. Verwende dieselbe Gruppe, den TCP-Port und die vorbereitete Besucheradresse:

aws ec2 authorize-security-group-ingress \
  --group-id "$SECURITY_GROUP_ID" \
  --protocol tcp \
  --port 8081 \
  --cidr 198.51.100.10/32

Lade das Portfolio neu. Alex Morgan und die drei Projekte sollten wieder erscheinen, ohne Neuinstallation oder Serverneustart. Lies auch die Gruppe erneut, um die Konfiguration zu prüfen:

Nach Wiederherstellung der vorgesehenen Regel antwortet die echte Seite wieder.

aws ec2 describe-security-groups \
  --group-ids "$SECURITY_GROUP_ID" \
  --query 'SecurityGroups[0].IpPermissions'

Prüfe die Website-Regel 8081 und die unveränderte SSH-Regel 22, beide für 198.51.100.10/32. 0.0.0.0/0 würde jede IPv4-Quelle erlauben und wäre zu weit gefasst. Stelle die vorgegebene Quelle ohne weitere Berechtigungen wieder her.

Du hast Konfiguration und tatsächliche Wirkung geprüft: Die benötigte Regel besteht und der Besucherzugriff funktioniert. Das nächste Lab liefert eine neue Website und führt privaten Speicher für ihre Materialien ein.

Zusammenfassung

Du hast eine Website-Regel entfernt und wiederhergestellt, reale Ausfälle und Wiederherstellung beobachtet und SSH bewahrt. Du unterscheidest einen laufenden Server von einer erreichbaren Anwendung und hast die auf den vorgesehenen Besucher begrenzte Berechtigung geprüft.

Offizielle Quellen: security group rules.