Einführung
Eine Webanwendung muss einen internen Exportpfad blockieren und gleichzeitig den Zustandsendpunkt verfügbar halten. Du bindest eine Pfadregel an, testest, ob Anfragen das Backend erreichen, und aktualisierst die Regel vor der Bereinigung.
Schließe zuerst Erste Schritte mit AWS auf LabEx und Einem Berichtsleser minimale Berechtigungen geben ab. Diese neue VM stellt eine Anwendung und eine unabhängige REST-API-Stage bereit; frühere API- oder Netzwerkressourcen werden nicht benötigt.
Bezug zu Zertifizierungen
Dieses Lab bietet praktische Übungen zu den folgenden Prüfungsthemen.
- Cloud Practitioner (CLF-C02) · Aufgabe 2.4: WAF-Web-ACL-Zuordnung und Regeln zur Anfragefilterung.
- Solutions Architect – Associate (SAA-C03) · Aufgabe 1.2: WAF-Web-ACL-Zuordnung und Regeln zur Anfragefilterung.
- Security – Specialty (SCS-C03) · Aufgabe 3.1: Grundlagenübung: WAF-Web-ACL-Zuordnung und Regeln zur Anfragefilterung.
- Solutions Architect – Professional (SAP-C02) · Aufgabe 2.3: Grundlagenübung: WAF-Web-ACL-Zuordnung und Regeln zur Anfragefilterung.
Eine regionale Web ACL erstellen
In diesem Schritt definierst du eine AWS WAF-Anfrageregel innerhalb einer Webzugriffskontrollliste (Web ACL). WAF untersucht Anfragen, bevor sie die Anwendung erreichen. Die bereitgestellte REST-API hat eine benannte Stage, die mit einer regionalen Web ACL verknüpft werden kann; dieser Einstiegspunkt unterscheidet sich von der HTTP-API im API/Cognito-Kurs.
Öffne AWS View neben Terminal, um Regeln, die Stage-Verknüpfung und das Erreichen des Backends durch jede Anfrage zu vergleichen. Erhalte die unbeteiligte Referenz-Web-ACL und die Referenz-Stage.
Eine Regel kombiniert eine Übereinstimmungsbedingung mit einer Aktion. Eine Standardaktion gilt, wenn keine Regel passt. Wir blockieren /internal/ und erlauben andere Pfade.
Wechsle in das Projektverzeichnis und bestätige die vorbereitete Operatoridentität. Die bereitgestellte Datei stage-arn.txt enthält die ARN der Anwendungs-Stage, keine Zugangsdaten. Die Befehlsersetzung speichert diesen Wert für die spätere Verknüpfung.
cd /home/labex/project
aws sts get-caller-identity --query Arn --output text
STAGE_ARN=$(cat stage-arn.txt)
Erwarte labex-sec05-operator. Bevor eine Web ACL verknüpft ist, erreicht der fiktive interne Export das Backend. curl sendet eine tatsächliche HTTP-Anfrage; -sS entfernt die Fortschrittsausgabe, behält aber Verbindungsfehler bei, und -w gibt den Antwortstatus aus.
curl -sS -w '\nHTTP %{http_code}\n' http://127.0.0.1:8090/internal/export
Erwarte HTTP 200 und eine fiktive Backendantwort. Schreibe eine Regeldatei mit einem Here-Dokument mit Anführungszeichen: Die Zeilen zwischen <<'EOF' und EOF werden exakt wie geschrieben zur JSON-Datei. UriPath wählt den Pfad aus, STARTS_WITH prüft das Präfix, und NONE verhindert seine Transformation. Niedrigere numerische Prioritäten werden zuerst ausgeführt; diese ACL hat eine Regel mit Priorität null. Die Sichtbarkeitseinstellungen deaktivieren optionale Stichproben und Metriken für diese gezielte Übung. Speichere dieselben Einstellungen in visibility.json für die ACL selbst und ihre spätere Aktualisierung.
cat > rules-internal.json <<'EOF'
[{
"Name": "block-private-export",
"Priority": 0,
"Action": {"Block": {}},
"Statement": {"ByteMatchStatement": {
"SearchString": "/internal/",
"FieldToMatch": {"UriPath": {}},
"PositionalConstraint": "STARTS_WITH",
"TextTransformations": [{"Priority": 0, "Type": "NONE"}]
}},
"VisibilityConfig": {"SampledRequestsEnabled": false, "CloudWatchMetricsEnabled": false, "MetricName": "labex-sec05-owned-export"}
}]
EOF
Erstelle die regionale ACL mit der Standardaktion Allow. --cli-binary-format raw-in-base64-out weist AWS CLI v2 an, SearchString als wörtliche Eingabebytes zu interpretieren, statt eine Base64-Zeichenfolge zu erwarten. file:// lädt das Regeldokument; --query wählt nur die resultierende ACL-ID aus.
cat > visibility.json <<'EOF'
{
"SampledRequestsEnabled": false,
"CloudWatchMetricsEnabled": false,
"MetricName": "labex-sec05-owned-export"
}
EOF
ACL_ID=$(aws wafv2 create-web-acl \
--name labex-sec05-owned-export \
--scope REGIONAL \
--default-action Allow={} \
--visibility-config file://visibility.json \
--rules file://rules-internal.json \
--cli-binary-format raw-in-base64-out \
--query Summary.Id \
--output text)
ACL_ARN=$(aws wafv2 get-web-acl \
--name labex-sec05-owned-export \
--scope REGIONAL \
--id "$ACL_ID" \
--query WebACL.ARN \
--output text)
aws wafv2 get-web-acl \
--name labex-sec05-owned-export \
--scope REGIONAL \
--id "$ACL_ID" \
--query 'WebACL.{Name:Name,Default:DefaultAction,Rules:Rules[].Name}'
Erwarte die eigene ACL, die Standardaktion Allow und block-private-export. Das Erstellen einer Richtlinie bindet sie nicht an einen Endpunkt. AWS View sollte weiterhin keine Zielverknüpfung zeigen.
Die ACL verknüpfen und tatsächliche Anfragen testen
In diesem Schritt verbindest du deine Richtlinie mit der bereitgestellten REST-API-Stage und vergleichst eine öffentliche Anfrage mit einer passenden Exportanfrage. Eine Stage bezeichnet eine bereitgestellte API-Umgebung; die Verknüpfung wendet die ACL auf Anfragen an dieser Stage an.
Die verknüpfte Web ACL weist den internen Pfad zurück, bevor er das Backend erreicht.
Verknüpfe nur deine ACL mit der bereitgestellten Ziel-ARN. Die unbeteiligte Referenz-Stage hat bereits ihre eigene Referenz-ACL; ersetze sie nicht.
aws wafv2 associate-web-acl --web-acl-arn "$ACL_ARN" --resource-arn "$STAGE_ARN"
aws wafv2 get-web-acl-for-resource \
--resource-arn "$STAGE_ARN" \
--query WebACL.Name \
--output text
Erwarte labex-sec05-owned-export. Teste den öffentlichen Zustandspfad, der nicht auf /internal/ passt, und dann den internen Exportpfad.
curl -sS -w '\nHTTP %{http_code}\n' http://127.0.0.1:8090/health
curl -sS -w '\nHTTP %{http_code}\n' http://127.0.0.1:8090/internal/export
Erwarte HTTP 200 für den Zustandsendpunkt und HTTP 403 mit block-private-export für den Export. Eine Block-Entscheidung antwortet, bevor das Backend ausgeführt wird. AWS View muss Executed für die Zustandsanfrage und Not reached für die blockierte Anfrage zeigen. Eine Verknüpfung beim Dienst allein reicht nicht aus; diese tatsächlichen HTTP-Ergebnisse belegen die Durchsetzung.
Die Regel aktualisieren und das laufende Verhalten beobachten
In diesem Schritt verschiebst du den Schutz auf das Adminpräfix und zeigst das geänderte Verhalten, ohne die Anwendung neu zu starten. Eine Aktualisierung der Web ACL ersetzt die Regelliste. Ihr Lock-Token schützt vor dem Überschreiben einer gleichzeitigen Änderung; hole ihn unmittelbar vor der Aktualisierung aus der aktuellen Konfiguration beim Dienst und behalte ihn in einer Variablen.
Erstelle das neue Regeldokument, indem du das URI-Präfix in der früheren Datei ersetzt. sed transformiert den Text, und > schreibt die neue Datei, während das ursprüngliche Regeldokument erhalten bleibt.
sed 's|/internal/|/admin/|' rules-internal.json > rules-admin.json
LOCK_TOKEN=$(aws wafv2 get-web-acl \
--name labex-sec05-owned-export \
--scope REGIONAL \
--id "$ACL_ID" \
--query LockToken \
--output text)
aws wafv2 update-web-acl \
--name labex-sec05-owned-export \
--scope REGIONAL \
--id "$ACL_ID" \
--lock-token "$LOCK_TOKEN" \
--default-action Allow={} \
--visibility-config file://visibility.json \
--rules file://rules-admin.json \
--cli-binary-format raw-in-base64-out \
--query NextLockToken \
--output text
Der zurückgegebene Lock-Token bezeichnet die neue ACL-Revision; er ist kein Authentifizierungsnachweis. Jetzt sollte das frühere interne Präfix die Standardaktion Allow durchlaufen, während der Adminexport blockiert werden sollte.
curl -sS -w '\nHTTP %{http_code}\n' http://127.0.0.1:8090/internal/export
curl -sS -w '\nHTTP %{http_code}\n' http://127.0.0.1:8090/admin/export
Erwarte HTTP 200 gefolgt von HTTP 403. AWS View sollte das neue Präfix /admin/, die frühere blockierte interne Anfrage und das aktuelle Paar aus erlaubter interner und blockierter Adminanfrage zeigen. Anfragen verwenden die aktuelle Regel beim Dienst; ein Neustart der VM oder Anwendung ist unnötig. Nicht unterstützte Richtlinientypen verweigern in dieser gezielten Umgebung den Zugriff, statt ihn zuzulassen. Verwende daher nur den hier vermittelten Anweisungstyp.
Nur die eigene ACL lösen und löschen
In diesem Schritt entfernst du deine Richtlinie und bestätigst, dass das gewöhnliche Anwendungsrouting zurückkehrt. Schließe zuerst die vorherigen Funktionsprüfungen ab. Das Lösen der Verknüpfung entfernt die Durchsetzung von dieser Stage; das anschließende Löschen der ACL entfernt die eigene Richtlinienressource.
Löse deine Web ACL von der Ziel-Stage und untersuche die Verknüpfung mit einer erfolgreichen Abfrage direkt beim Dienst. Erwarte eine leere Verknüpfung, statt einen Authentifizierungsfehler als Löschbeleg zu betrachten.
aws wafv2 disassociate-web-acl --resource-arn "$STAGE_ARN"
aws wafv2 get-web-acl-for-resource --resource-arn "$STAGE_ARN" --query WebACL
Der zuvor blockierte Adminexport sollte jetzt wieder das bereitgestellte Backend erreichen.
curl -sS -w '\nHTTP %{http_code}\n' http://127.0.0.1:8090/admin/export
Erwarte HTTP 200. Hole einen aktuellen Lock-Token, lösche nur die eigene ACL und liste die verbleibenden ACLs erfolgreich auf. Der eigene Name muss fehlen, und labex-sec05-reference muss erhalten bleiben.
LOCK_TOKEN=$(aws wafv2 get-web-acl \
--name labex-sec05-owned-export \
--scope REGIONAL \
--id "$ACL_ID" \
--query LockToken \
--output text)
aws wafv2 delete-web-acl \
--name labex-sec05-owned-export \
--scope REGIONAL \
--id "$ACL_ID" \
--lock-token "$LOCK_TOKEN"
aws wafv2 list-web-acls --scope REGIONAL --query 'WebACLs[].Name'
Lasse beide bereitgestellten API-Stages und die Referenz-ACL intakt. Entferne die lokalen Regel- und Sichtbarkeitsdokumente und führe dann die Verifikation dieses Schritts aus, bevor du das temporäre CLI-Profil entfernst.
rm -f rules-internal.json rules-admin.json visibility.json
rm -f /home/labex/.aws/credentials /home/labex/.aws/config
unset STAGE_ARN ACL_ID ACL_ARN LOCK_TOKEN
Zusammenfassung
Du hast eine regionale Web ACL erstellt, sie mit einer REST-API-Stage verknüpft und das tatsächliche Erlauben und Blockieren von HTTP-Anfragen getestet. Eine passende Anfrage wurde vor dem Backend gestoppt, während Zustandsanfragen weiterhin durchgelassen wurden. Das Aktualisieren des URI-Präfixes änderte das laufende Routing; das Lösen der Verknüpfung stellte den Endpunkt wieder her. Du hast nur die eigene ACL gelöscht und die bereitgestellten Stages und die Referenzrichtlinie erhalten.
