GSP909
Übersicht
In diesem Lab verwenden Sie eine Apigee X-Richtlinie zum Schutz vor Bedrohungen, um APIs vor inhaltsbasierten Bedrohungen zu schützen. Außerdem konfigurieren Sie Cloud Armor für einen globalen externen HTTPS-Load-Balancer, um WAF-Funktionen (Web Application Firewall) wie DDoS-Schutz (Distributed Denial of Service), OWASP Top Ten-Schutz sowie IP- und standortbasierte Zugriffssteuerung bereitzustellen.
Ein Load Balancer und eine verwaltete Instanzgruppe mit virtuellen Maschinen zur Vermittlung (Bridge-VMs) wurden erstellt, um den Zugriff auf Ihre Laufzeitinstanz zu ermöglichen. Die Architektur für diese Konfiguration ist hier dargestellt:

Eingehende API-Aufrufe gelangen über einen globalen externen HTTPS-Load-Balancer in das Kundenprojekt. Der externe HTTPS-Load-Balancer kann keine Aufrufe an das Mandantenprojekt weiterleiten. Stattdessen leitet er die Anfrage an eine verwaltete Instanzgruppe von Bridge-VMs im Kundenprojekt weiter. Diese Bridge-VMs befinden sich im per Peering verbundenen Netzwerk, das mit der Apigee-Laufzeitinstanz verbunden ist. So können die VMs API-Aufrufe an die Laufzeitinstanz weiterleiten.
HTTP-Traffic, der an den Load Balancer gesendet wird, wird an die Bridge-VMs und dann an die Apigee-Laufzeitinstanz weitergeleitet. Sie fügen Cloud Armor-Sicherheitsrichtlinien hinzu, um zu verhindern, dass bestimmter Traffic an die Laufzeit gesendet wird.
Bei JSON- und XML-Angriffen kommen speziell konstruierte Nutzlasten zum Einsatz, die JSON- beziehungsweise XML-Parser überlasten und so Denial-of-Service-Angriffe auf Anwendungsebene auslösen können. Cloud Armor erkennt diese Arten von Angriffen nicht, Apigee hingegen schon. Die Richtlinien JSONThreatProtection und XMLThreatProtection können solche schädlichen Nutzlasten erkennen, ohne sie in einen Parser laden zu müssen. In diesem Lab verwenden Sie die Richtlinie JSONThreatProtection, um sich vor ungültig formatierten JSON-Nutzlasten zu schützen.
Die Anleitungen in diesem Lab gelten sowohl für kostenpflichtige als auch für Evaluierungsorganisationen.
Ziele
Aufgaben in diesem Lab:
- Mit Apigee-Richtlinien zum Schutz vor Bedrohungen schädliche JSON- und XML-Nutzlasten blockieren
- Cloud Armor-Richtlinie erstellen
- Cloud Armor-Regel zum Blockieren und Zulassen von Anfragen erstellen
- Cloud Armor-Richtlinie auf einen Load Balancer anwenden
- Cloud Armor-Richtlinie mit HTTP-Traffic testen
Einrichtung
Vor dem Klick auf „Start Lab“ (Lab starten)
Lesen Sie diese Anleitung. Labs sind zeitlich begrenzt und können nicht pausiert werden. Der Timer beginnt zu laufen, wenn Sie auf Lab starten klicken, und zeigt Ihnen, wie lange Google Cloud-Ressourcen für das Lab verfügbar sind.
In diesem praxisorientierten Lab können Sie die Lab-Aktivitäten in einer echten Cloud-Umgebung durchführen – nicht in einer Simulations- oder Demo-Umgebung. Dazu erhalten Sie neue, temporäre Anmeldedaten, mit denen Sie für die Dauer des Labs auf Google Cloud zugreifen können.
Für dieses Lab benötigen Sie Folgendes:
- Einen Standardbrowser (empfohlen wird Chrome)
Hinweis: Nutzen Sie den privaten oder Inkognitomodus (empfohlen), um dieses Lab durchzuführen. So wird verhindert, dass es zu Konflikten zwischen Ihrem persönlichen Konto und dem Teilnehmerkonto kommt und zusätzliche Gebühren für Ihr persönliches Konto erhoben werden.
- Zeit für die Durchführung des Labs – denken Sie daran, dass Sie ein begonnenes Lab nicht unterbrechen können.
Hinweis: Verwenden Sie für dieses Lab nur das Teilnehmerkonto. Wenn Sie ein anderes Google Cloud-Konto verwenden, fallen dafür möglicherweise Kosten an.
Hinweis: Sie sollten für dieses Lab ein neues Inkognitofenster verwenden.
Lab starten und bei der Google Cloud Console anmelden
-
Klicken Sie auf Lab starten. Wenn Sie für das Lab bezahlen müssen, wird ein Dialogfeld geöffnet, in dem Sie Ihre Zahlungsmethode auswählen können.
Auf der linken Seite befindet sich der Bereich „Details zum Lab“ mit diesen Informationen:
- Schaltfläche „Google Cloud Console öffnen“
- Restzeit
- Temporäre Anmeldedaten für das Lab
- Ggf. weitere Informationen für dieses Lab
-
Klicken Sie auf Google Cloud Console öffnen (oder klicken Sie mit der rechten Maustaste und wählen Sie Link in Inkognitofenster öffnen aus, wenn Sie Chrome verwenden).
Im Lab werden Ressourcen aktiviert. Anschließend wird ein weiterer Tab mit der Seite „Anmelden“ geöffnet.
Tipp: Ordnen Sie die Tabs nebeneinander in separaten Fenstern an.
Hinweis: Wird das Dialogfeld Konto auswählen angezeigt, klicken Sie auf Anderes Konto verwenden.
-
Kopieren Sie bei Bedarf den folgenden Nutzernamen und fügen Sie ihn in das Dialogfeld Anmelden ein.
{{{user_0.username | "Username"}}}
Sie finden den Nutzernamen auch im Bereich „Details zum Lab“.
-
Klicken Sie auf Weiter.
-
Kopieren Sie das folgende Passwort und fügen Sie es in das Dialogfeld Willkommen ein.
{{{user_0.password | "Password"}}}
Sie finden das Passwort auch im Bereich „Details zum Lab“.
-
Klicken Sie auf Weiter.
Wichtig: Sie müssen die für das Lab bereitgestellten Anmeldedaten verwenden. Nutzen Sie nicht die Anmeldedaten Ihres Google Cloud-Kontos.
Hinweis: Wenn Sie Ihr eigenes Google Cloud-Konto für dieses Lab nutzen, können zusätzliche Kosten anfallen.
-
Klicken Sie sich durch die nachfolgenden Seiten:
- Akzeptieren Sie die Nutzungsbedingungen.
- Fügen Sie keine Wiederherstellungsoptionen oder Zwei-Faktor-Authentifizierung hinzu (da dies nur ein temporäres Konto ist).
- Melden Sie sich nicht für kostenlose Testversionen an.
Nach wenigen Augenblicken wird die Google Cloud Console in diesem Tab geöffnet.
Hinweis: Wenn Sie auf Google Cloud-Produkte und ‑Dienste zugreifen möchten, klicken Sie auf das Navigationsmenü oder geben Sie den Namen des Produkts oder Dienstes in das Feld Suchen ein.
Cloud Shell aktivieren
Cloud Shell ist eine virtuelle Maschine, auf der Entwicklertools installiert sind. Sie bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft auf Google Cloud. Mit Cloud Shell erhalten Sie Befehlszeilenzugriff auf Ihre Google Cloud-Ressourcen.
-
Klicken Sie oben in der Google Cloud Console auf Cloud Shell aktivieren
.
-
Klicken Sie sich durch die folgenden Fenster:
- Fahren Sie mit dem Informationsfenster zu Cloud Shell fort.
- Autorisieren Sie Cloud Shell, Ihre Anmeldedaten für Google Cloud API-Aufrufe zu verwenden.
Wenn eine Verbindung besteht, sind Sie bereits authentifiziert und das Projekt ist auf Project_ID, eingestellt. Die Ausgabe enthält eine Zeile, in der die Project_ID für diese Sitzung angegeben ist:
Ihr Cloud-Projekt in dieser Sitzung ist festgelegt als {{{project_0.project_id | "PROJECT_ID"}}}
gcloud ist das Befehlszeilentool für Google Cloud. Das Tool ist in Cloud Shell vorinstalliert und unterstützt die Tab-Vervollständigung.
- (Optional) Sie können den aktiven Kontonamen mit diesem Befehl auflisten:
gcloud auth list
- Klicken Sie auf Autorisieren.
Ausgabe:
ACTIVE: *
ACCOUNT: {{{user_0.username | "ACCOUNT"}}}
Um das aktive Konto festzulegen, führen Sie diesen Befehl aus:
$ gcloud config set account `ACCOUNT`
- (Optional) Sie können die Projekt-ID mit diesem Befehl auflisten:
gcloud config list project
Ausgabe:
[core]
project = {{{project_0.project_id | "PROJECT_ID"}}}
Hinweis: Die vollständige Dokumentation für gcloud finden Sie in Google Cloud in der Übersicht zur gcloud CLI.
Aufgabe 1: Freigegebenen Ablauf für den JSON-Bedrohungsschutz erstellen
In dieser Aufgabe erstellen Sie einen freigegebenen (gemeinsam genutzten) Ablauf mit einer JSONThreatProtection-Richtlinie und verwenden dann einen Ablauf-Hook, um ihn für alle Apigee APIs zu aktivieren.
Die JSONThreatProtection-Richtlinie lehnt eingehende JSON-Anfragen ab, die die festgelegten Grenzwerte überschreiten. Wenn Sie die Richtlinie in einen freigegebenen Ablauf einfügen und den Ablauf mit einem Ablauf-Hook verknüpfen, kann die Richtlinie alle Anfragen für alle in einer Umgebung bereitgestellten Proxys schützen.
Apigee-Konsole öffnen
So öffnen Sie die Apigee-Konsole:
- Geben Sie in der Google Cloud Console in das Feld Suchen
Apigee ein und klicken Sie dann in den Suchergebnissen auf Apigee API Management.
Die Apigee-Konsole wird geöffnet und auf der Landingpage werden Quick Links zu häufig verwendeten Standorten angezeigt.
- Klicken Sie im Navigationsmenü (
) neben Apigee auf Favorisieren (
).
Apigee wurde dem Navigationsmenü als Favorit hinzugefügt.
Freigegebenen Ablauf erstellen
-
Wählen Sie im Navigationsmenü Proxyentwicklung > Freigegebene Abläufe aus.
-
Klicken Sie auf Erstellen.
Ein freigegebener Ablauf kann eine Reihe von Richtlinien und Bedingungen enthalten und mithilfe einer FlowCallout-Richtlinie in API-Proxys oder anderen freigegebenen Abläufen ausgeführt werden. In diesem Lab verwenden Sie den freigegebenen Ablauf in einem Ablauf-Hook, der ihn an jeden Proxy anhängt, der in der Evaluierungsorganisation bereitgestellt wird.
-
Geben Sie dem freigegebenen Ablauf den Namen protect-json und klicken Sie auf Erstellen.
-
Klicken Sie den Tab Entwickeln an.
-
Klicken Sie für den freigegebenen Ablauf im Menü auf der linken Seite unter Freigegebene Abläufe auf Standard.
-
Klicken Sie im Bereich sharedflows/default.xml auf Richtlinienschritt hinzufügen (
).
-
Klicken Sie unter Richtlinie auswählen auf Neue Richtlinie erstellen.
-
Wählen Sie JSON Threat Protection aus und legen Sie dann JTP-Protect für Display Name und Name fest.
-
Klicken Sie auf Hinzufügen.
Die JSONThreatProtection-Richtlinie enthält mehrere Elemente, die Grenzen für eingehende JSON-Anfragen festlegen. Diese Limits orientieren sich üblicherweise an den maximal zulässigen Werten Ihrer APIs. In diesem Fall sollten Sie die Standardkonfiguration der Richtlinie unverändert beibehalten.
Diese Richtlinie wird nur ausgeführt, wenn der Header Content-Type der Anfrage auf application/json gesetzt ist. Dies zeigt an, dass die eingehende Anfrage eine JSON-Nutzlast hat.
-
Klicken Sie auf Speichern.
-
Klicken Sie auf Bereitstellen und wählen Sie für Umgebung die Option eval aus.
-
Klicken Sie auf Bereitstellen und dann auf Bestätigen.
Freigegebenen Ablauf einem Ablauf-Hook hinzufügen
Der freigegebene Ablauf wird an den Ablauf-Hook „Pre-proxy“ angehängt, damit er vor dem Proxy ausgeführt wird.
-
Gehen Sie zu Verwaltung > Umgebungen.
-
Klicken Sie auf eval > Flow Hooks.
-
Wählen Sie im Drop-down der Zeile Pre-proxy den freigegebenen Ablauf protect-json aus und klicken Sie auf Save.
Sie testen diesen Ablauf-Hook in einer späteren Aufgabe.
Klicken Sie auf Fortschritt prüfen.
Freigegebenen Ablauf und Ablauf-Hook erstellen
Aufgabe 2: Cloud Armor-Sicherheitsrichtlinie hinzufügen
In dieser Aufgabe fügen Sie eine Cloud Armor-Sicherheitsrichtlinie hinzu, um Ihren Load Balancer zu schützen und den Zugriff auf Ihre APIs zu steuern.
Cloud Armor ist die Web Application Firewall (WAF) von Google Cloud. Für einen Load Balancer kann jeweils nur eine Cloud Armor-Richtlinie festgelegt werden. In diesem Lab verwenden Sie eine Cloud Armor-Sicherheitsrichtlinie, um bestimmten Traffic abzulehnen, bevor er die Apigee-Laufzeitinstanz erreicht, und so Ihre API zu schützen.

Hinweis: Der Load Balancer kann erst vollständig konfiguriert werden, wenn die IP-Adresse der Apigee-Laufzeitinstanz bekannt ist. Bis dahin werden möglicherweise als „unhealthy“ markierte Instanzen angezeigt.
Neue Sicherheitsrichtlinie erstellen
-
Klicken Sie im Tab „Cloud Console“ im Navigationsmenü (
) auf Alle Produkte anzeigen und wählen Sie im Bereich Netzwerk die Option Netzwerksicherheit aus. Rufen Sie dann Cloud Armor-Richtlinien auf.
-
Klicken Sie auf Richtlinie erstellen.
-
Geben Sie für Name protect-apis ein.
Diese Sicherheitsrichtlinie verwendet Regeln, um bestimmten Traffic zu blockieren, der für die Apigee APIs bestimmt ist.
-
Wählen Sie als Aktion der Standardregel die Option Ablehnen aus.
Nutzerkonten erhalten nur dann Zugriff auf die APIs, wenn sie einer Regel entsprechen, die den Traffic ausdrücklich zulässt.
-
Wählen Sie im Drop-down-Menü Status „Abgelehnt“ die Option 403 (Unzulässig) aus.
Wenn eine Anfrage keiner Regel entspricht, die den Traffic zulässt, wird der Statuscode „403 (Unzulässig)“ zurückgegeben.
-
Klicken Sie auf Nächster Schritt.
Regel für Sicherheitsrichtlinie hinzufügen, um Anfragen nach Ländercode des Ursprungslands zuzulassen
Diese Regel lässt nur Anfragen aus den angegebenen Ländern zu.
-
Klicken Sie auf Regel hinzufügen.
-
Klicken Sie auf Erweiterter Modus.
Eine Regel im Standardmodus kann nur IP-Adressen oder IP-Adressbereiche angeben, die übereinstimmen sollen. In diesem Fall sollten Sie zulässige Ländercodes angeben.
-
Geben Sie für Abgleich den folgenden Ausdruck an:
origin.region_code == 'US'
Für Cloud Armor wird region_code als ISO 3166-2-Region angegeben. Diese Regel lässt Anfragen zu, die aus den USA kommen.
-
Geben Sie für Aktion die Option Zulassen an.
-
Setzen Sie die Priorität auf 1000 und klicken Sie dann auf ÄNDERUNG AN REGEL SPEICHERN.
Regel zum Blockieren von SQL-Injection-Angriffen hinzufügen
Diese Regel blockiert Anfragen mit SQL-Eingaben, die zu einer SQL-Injection führen könnten.
-
Klicken Sie auf Regel hinzufügen.
-
Klicken Sie auf Erweiterter Modus.
-
Geben Sie für Abgleich den folgenden Ausdruck an:
evaluatePreconfiguredExpr('sqli-stable', ['owasp-crs-v030001-id942251-sqli', 'owasp-crs-v030001-id942420-sqli', 'owasp-crs-v030001-id942431-sqli', 'owasp-crs-v030001-id942460-sqli', 'owasp-crs-v030001-id942421-sqli', 'owasp-crs-v030001-id942432-sqli'])
Dieser Ausdruck gibt eine vorkonfigurierte Cloud Armor-Regel an. Die vorkonfigurierten Regeln verwenden Open-Source-Signaturen nach Branchenstandard, um schädliche Anfragen zu erkennen. Bestimmte Signaturen können deaktiviert werden, indem ihre Namen angegeben werden.
In diesem Fall sind Signaturen der Empfindlichkeitsstufen 3 und 4 deaktiviert. Die Empfindlichkeitsstufe einer Signatur, auch Paranoia-Stufe genannt, beschreibt den Kompromiss zwischen einem höheren Sicherheitsniveau und einer größeren Zahl von Fehlalarmen.
Stufe 1 ist die Standardstufe für die Sicherheit, bei der es selten oder nie zu Fehlalarmen kommen sollte. Level 2 bietet zusätzlichen Schutz vor komplexen und verschleierten Angriffen. Signaturen der Stufen 3 und 4 sind aggressiver und führen deutlich häufiger zu Fehlalarmen. So können beispielsweise POST-Anfragen mit einfachen JSON-Nutzdaten von Signaturen der Stufe 3 oder 4 fälschlicherweise blockiert werden.
-
Lassen Sie Aktion auf Ablehnen gesetzt und Status „Abgelehnt“ auf 403 (Unzulässig).
-
Legen Sie für Priorität den Wert 500 fest.
Bei der Auswertung von Cloud Armor-Richtlinienregeln bestimmt die erste Regel, die auf die Anfrage zutrifft, welche Aktion ausgeführt wird. Die Prüfung auf SQL-Injection muss vor der Regionsprüfung erfolgen, da Anfragen abgelehnt werden sollen, die aus einer zulässigen Region stammen, aber SQL-Injection-Muster enthalten. Durch die Wahl einer kleineren Prioritätsnummer wird die Prüfung auf SQL-Injection vor der Regionsprüfung durchgeführt.
-
Klicken Sie auf ÄNDERUNG AN REGEL SPEICHERN.
Sehen Sie sich die Zusammenfassung auf der rechten Seite an. Die Richtlinie enthält 3 Regeln. Die Regeln werden in der Reihenfolge von der niedrigsten zur höchsten Prioritätsnummer ausgewertet. Die erste Regel, die auf die Anfrage zutrifft, wird angewendet.
Die erste Regel verweigert den Zugriff, wenn SQL-Injection-Muster erkannt werden.
Die zweite Regel lässt den Zugriff zu, wenn die Anfrage aus den USA stammt.
Die letzte Regel lehnt den Zugriff für den gesamten Traffic ab.
-
Klicken Sie auf Richtlinie erstellen.
Auf dem Tab Richtlinien sehen Sie, dass die neue Richtlinie protect-apis 0 Ziele hat, da Sie sie noch nicht Ihrem Load Balancer zugewiesen haben.
Richtlinie dem Load Balancer zuweisen
-
Klicken Sie neben protect-apis auf den Button für das Richtlinienmenü (
) und dann auf Richtlinie auf Ziel anwenden.
-
Wählen Sie im Drop-down-Menü Backend Service 1 die Option apigee-proxy-backend aus und klicken Sie dann auf Hinzufügen.
Auf der Seite mit den Details der Richtlinie protect-apis sollte bald angezeigt werden, dass die Richtlinie auf ein Ziel angewendet wird.
Hinweis: Es kann einige Minuten dauern, bis die Änderungen in Cloud Armor auf das Ziel übertragen werden.
Klicken Sie auf Fortschritt prüfen.
Cloud Armor-Sicherheitsrichtlinie hinzufügen
Aufgabe 3: Warten, bis die Apigee-Instanz bereitgestellt wurde
In dieser Aufgabe warten Sie, bis die Bereitstellung der Apigee-Evaluierungsorganisation abgeschlossen ist.
Die Bereitstellung der Apigee-Organisation kann längere Zeit in Anspruch nehmen. Sie können den Fortschritt mit der Apigee API verfolgen.
Monitoring-Script starten
-
Prüfen Sie in der Cloud Shell mit dem folgenden Befehl, ob die Variable GOOGLE_CLOUD_PROJECT den Namen Ihres Projekts enthält:
echo ${GOOGLE_CLOUD_PROJECT}
Die Variable GOOGLE_CLOUD_PROJECT sollte den Namen Ihres Projekts enthalten, der mit dem Namen Ihrer Apigee-Organisation identisch ist.
-
Wenn die Variable GOOGLE_CLOUD_PROJECT nicht festgelegt ist, legen Sie sie manuell mit einem Befehl fest, der so aussieht. Dabei ersetzen Sie {project} durch den Namen Ihres Projekts:
export GOOGLE_CLOUD_PROJECT={project}
Hinweis: Die geschweiften Klammern müssen in diesem Schritt entfernt werden.
-
Fügen Sie den folgenden Befehl in der Cloud Shell ein:
export INSTANCE_NAME=eval-instance; export ENV_NAME=eval; export PREV_INSTANCE_STATE=; echo "waiting for runtime instance ${INSTANCE_NAME} to be active"; while : ; do export INSTANCE_STATE=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${GOOGLE_CLOUD_PROJECT}/instances/${INSTANCE_NAME}" | jq "select(.state != null) | .state" --raw-output); [[ "${INSTANCE_STATE}" == "${PREV_INSTANCE_STATE}" ]] || (echo; echo "INSTANCE_STATE=${INSTANCE_STATE}"); export PREV_INSTANCE_STATE=${INSTANCE_STATE}; [[ "${INSTANCE_STATE}" != "ACTIVE" ]] || break; echo -n "."; sleep 5; done; echo; echo "instance created, waiting for environment ${ENV_NAME} to be attached to instance"; while : ; do export ATTACHMENT_DONE=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${GOOGLE_CLOUD_PROJECT}/instances/${INSTANCE_NAME}/attachments" | jq "select(.attachments != null) | .attachments[] | select(.environment == \"${ENV_NAME}\") | .environment" --join-output); [[ "${ATTACHMENT_DONE}" != "${ENV_NAME}" ]] || break; echo -n "."; sleep 5; done; echo; echo "${ENV_NAME} environment attached, waiting for hello-world to be deployed"; while : ; do export ATTACHMENT_DONE=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${GOOGLE_CLOUD_PROJECT}/instances/${INSTANCE_NAME}/attachments" | jq "select(.attachments != null) | .attachments[] | select(.environment == \"${ENV_NAME}\") | .environment" --join-output); [[ "${ATTACHMENT_DONE}" != "${ENV_NAME}" ]] || break; echo -n "."; sleep 5; done; echo "***ORG IS READY TO USE***";
Diese Befehlsfolge verwendet die Apigee API, um festzustellen, wann die Laufzeitinstanz erstellt und die Umgebung „eval“ angehängt wurde.
-
Warten Sie, bis die Instanz bereit ist.
Wenn der Text ***ORG IS READY TO USE*** angezeigt wird, ist die Instanz bereit.
Hinweis: Wenn der Befehl sofort anzeigt, dass die Organisation einsatzbereit ist, ist die Bereitstellung eventuell schon erfolgt, bevor Sie das Lab gestartet haben.
Während Sie darauf warten, dass die Organisation bereit ist, können Sie sich eine Übersicht zu Cloud Armor, benutzerdefinierte Regeln und vorkonfigurierte Regeln ansehen.
Klicken Sie auf Fortschritt prüfen.
Warten, bis die Instanz bereit ist
Aufgabe 4: Aus einer zulässigen Region testen
In dieser Aufgabe prüfen Sie, ob die Cloud Armor-Sicherheitsrichtlinie Ihre APIs schützt, gleichzeitig aber zulässigen Traffic aus der freigegebenen Region durchlässt und ob der Ablauf-Hook vor JSON-Bedrohungen schützt.
Eine virtuelle Maschine (VM) namens apigeex-test-vm wurde automatisch erstellt. Sie können diese VM verwenden, um die API aus den USA aufzurufen.
-
Öffnen Sie in der Cloud Shell eine SSH-Verbindung zu Ihrer Test-VM in den USA:
TEST_VM_ZONE=$(gcloud compute instances list --filter="name=('apigeex-test-vm')" --format "value(zone)")
gcloud compute ssh apigeex-test-vm --zone=${TEST_VM_ZONE} --force-key-file-overwrite
-
Drücken Sie J, wenn Möchten Sie fortfahren (J/N)? angezeigt wird.
-
Drücken Sie für jede in der Cloud Shell gestellte Frage auf die Eingabetaste beziehungsweise auf die Return-Taste, um die Standardeingabe zu übernehmen.
Die Identität, mit der Sie angemeldet sind, ist das Inhaberkonto des Projekts. Daher ist der SSH-Zugriff auf diese VM erlaubt.
Ihre Cloud Shell-Sitzung wird jetzt in der VM ausgeführt.
-
Prüfen Sie, ob der API-Proxy „hello-world“ nun zugänglich ist:
export PREV_STATUS_CODE=; echo "waiting for hello-world to be accessible"; while : ; do export STATUS_CODE=$(curl -k -s -o /dev/null -w "%{http_code}" --max-time 5 -X GET "https://eval.example.com/hello-world"); [[ "${STATUS_CODE}" == "${PREV_STATUS_CODE}" ]] || (echo; echo "STATUS_CODE=${STATUS_CODE}"); export PREV_STATUS_CODE=${STATUS_CODE}; [[ "${STATUS_CODE}" != "200" ]] || break; echo -n "."; sleep 5; done; echo; echo "***HELLO-WORLD IS ACCESSIBLE***";
Es kann eine Weile dauern, bis der Proxy „hello-world“ bereitgestellt und über den externen Load Balancer verfügbar ist. Wenn diese Befehle ***HELLO-WORLD IS ACCESSIBLE*** zurückgeben, ist der Proxy „hello-world“ verfügbar.
-
Rufen Sie den bereitgestellten API-Proxy hello-world in der Umgebung eval auf:
curl -i -k "https://eval.example.com/hello-world"
Ein DNS-Eintrag für den Hostnamen eval.example.com wurde mit der eingehenden IP-Adresse für Ihren Load Balancer erstellt.
Die Option -i zeigt den Statuscode und den Header für die Antwort an.
Die Option -k überspringt die Überprüfung des TLS-Zertifikats des Load Balancers, da dieser ein selbst signiertes Zertifikat verwendet und kein von einer bekannten Zertifizierungsstelle ausgestelltes Zertifikat.
Hinweis: In Produktionsumgebungen sollte die Option „-k“ nicht zum Umgehen der Zertifikatsprüfung verwendet werden.
Da sich die VM in den USA befindet, sollte der curl-Befehl die vom Proxy hello-world generierte Antwort Hello, Guest! zurückgeben.
HTTP/2 200
x-powered-by: Apigee
access-control-allow-origin: *
x-frame-options: ALLOW-FROM RESOURCE-URL
x-xss-protection: 1
x-content-type-options: nosniff
content-type: text/plain; charset=utf-8
content-length: 13
etag: W/"d-GHB1ZrJKk/wdVTdB/jgBsw"
date: Mon, 30 Aug 2021 19:14:45 GMT
alt-svc: clear
alt-svc: clear
x-request-id: b5532b95-c051-4f21-a131-07da1574edc3
server: apigee
via: 1.1 google, 1.1 google
Hello, Guest!
-
Rufen Sie den Proxy hello-world mit diesem Befehl auf:
curl -i -k -X POST "https://eval.example.com/hello-world" -H "Content-Type: application/json" -d '{ "ThisIsAReallyLongElementNameIMeanReallyReallyReallyLong": 42 }'
Diese Anfrage überschreitet das Limit ObjectEntryNameLength, das in der JSONThreatProtection-Richtlinie im freigegebenen Ablauf festgelegt ist. Der freigegebene Ablauf wird mit dem Ablauf-Hook „Pre-proxy“ an alle API-Proxys angehängt.
Die Antwort sollte in etwa so aussehen:
HTTP/2 500
content-type: application/json
x-request-id: 5360a9fb-b0b9-4fce-968c-22c2d3fd57dd
content-length: 235
date: Mon, 30 Aug 2021 19:16:17 GMT
server: apigee
via: 1.1 google
alt-svc: clear
{"fault":{"faultstring":"JSONThreatProtection[JTP-Protect]: Execution failed. reason: JSONThreatProtection[JTP-Protect]: Exceeded object entry name length at line 1","detail":{"errorcode":"steps.jsonthreatprotection.ExecutionFailed"}}}
Hinweis: Standardmäßig wird der Statuscode 500 zurückgegeben, der auf einen Serverfehler hindeutet. In einer Produktionsumgebung ist es sinnvoller, den Fehlercode so zu ändern, dass er auf ein Problem mit der Anfrage (zum Beispiel „400 Bad Request“) und nicht auf einen Serverfehler hinweist.
-
Versuchen Sie, den API-Proxy hello-world mit diesem Befehl aufzurufen:
curl -i -k "https://eval.example.com/hello-world?item=name'%20OR%20'a'='a"
Der Abfrageparameter item verwendet ein SQL-Injection-Muster, das unbeabsichtigte Auswirkungen haben kann, wenn eine SQL-Abfrage durch das Verketten von Strings erstellt wird.
Das SQL-Injection-Muster wird von Cloud Armor erfolgreich erkannt und die Anfrage wird blockiert. Es wird die Antwort „403 Forbidden“ zurückgegeben:
HTTP/2 403
content-length: 134
content-type: text/html; charset=UTF-8
date: Thu, 22 Jul 2021 18:50:03 GMT
alt-svc: clear
<!doctype html><meta charset="utf-8"><meta name=viewport content="width=device-width, initial-scale=1"><title>403</title>403 Forbidden
Hinweis: Es kann einige Minuten dauern, bis Cloud Armor-Regeln vollständig übernommen werden. Wenn die Anfrage nicht blockiert wird, wiederholen Sie den Aufruf, bis die Blockierung greift.
-
Geben Sie exit ein, um die SSH-Verbindung zu Ihrer VM in den USA zu schließen.
Aufgabe 5: Sicherheitsrichtlinie aus einer nicht zulässigen Region testen
In dieser Aufgabe prüfen Sie, ob die Cloud Armor-Sicherheitsrichtlinie Traffic aus einer Region blockiert, die nicht auf der Zulassungsliste steht.
Eine VM namens apigeex-outside-us wurde automatisch in der Zone erstellt. Sie können sie verwenden, um die API von außerhalb der USA aufzurufen.
- Öffnen Sie in der Cloud Shell eine SSH-Verbindung zu Ihrer Test-VM außerhalb der USA:
export SECOND_VM_NAME=apigeex-outside-us
export SECOND_VM_ZONE={{{project_0.default_zone_2| Secondary Zone}}}
gcloud compute ssh ${SECOND_VM_NAME} --zone=${SECOND_VM_ZONE} --force-key-file-overwrite
-
Wenn Sie zur Autorisierung aufgefordert werden, klicken Sie auf Autorisieren.
-
Drücken Sie für jede in der Cloud Shell gestellte Frage auf die Eingabetaste beziehungsweise auf die Return-Taste, um die Standardeingabe zu übernehmen.
Die Identität, mit der Sie angemeldet sind, ist das Inhaberkonto des Projekts. Daher ist der SSH-Zugriff auf diese VM erlaubt.
Ihre Cloud Shell-Sitzung wird jetzt in der VM ausgeführt.
-
Rufen Sie den bereitgestellten API-Proxy hello-world in der Umgebung eval auf:
curl -i -k "https://eval.example.com/hello-world"
Da sich die VM nicht in den USA befindet, sollte Cloud Armor die Anfrage blockieren und den Fehlercode 403 zurückgeben:
HTTP/2 403
content-length: 134
content-type: text/html; charset=UTF-8
date: Thu, 22 Jul 2021 22:47:06 GMT
alt-svc: clear
<!doctype html><meta charset="utf-8"><meta name=viewport content="width=device-width, initial-scale=1"><title>403</title>403 Forbidden
Aufgabe 6: Richtlinienüberwachung für Cloud Armor
In dieser Aufgabe sehen Sie sich das Cloud Armor-Richtlinien-Dashboard in Cloud Monitoring an.
-
Rufen Sie im Tab Cloud Console die Seite Monitoring > Dashboards auf.
-
Klicken Sie auf Cloud Armor Policies Overview.
Auf diesem Dashboard sehen Sie die Anzahl zugelassener und blockierter Anfragen für alle Cloud Armor-Richtlinien. Sie haben derzeit nur eine Richtlinie.
-
Klicken Sie im Bereich Richtlinien auf protect-apis.
Auf diesem Dashboard sehen Sie die Anzahl zugelassener und blockierter Anfragen für die Richtlinie protect-apis.
Wenn Sie Details zu einzelnen Anfragen sehen möchten, müssen Sie das Logging von Anfragen für den Load Balancer aktivieren.
Das wars! Sie haben das Lab erfolgreich abgeschlossen.
In diesem Lab haben Sie eine Cloud Armor-Richtlinie erstellt und damit eingehenden Traffic basierend auf Ihren Cloud Armor-Regeln abgelehnt oder zugelassen.
Weitere Informationen
Google Cloud-Schulungen und -Zertifizierungen
In unseren Schulungen erfahren Sie alles zum optimalen Einsatz unserer Google Cloud-Technologien und können sich entsprechend zertifizieren lassen. Unsere Kurse vermitteln technische Fähigkeiten und Best Practices, damit Sie möglichst schnell mit Google Cloud loslegen und Ihr Wissen fortlaufend erweitern können. Wir bieten On-Demand-, Präsenz- und virtuelle Schulungen für Anfänger wie Fortgeschrittene an, die Sie individuell in Ihrem eigenen Zeitplan absolvieren können. Mit unseren Zertifizierungen weisen Sie nach, dass Sie Experte im Bereich Google Cloud-Technologien sind.
Anleitung zuletzt am 17. September 2025 aktualisiert
Lab zuletzt am 17. September 2025 getestet
© 2026 Google LLC. Alle Rechte vorbehalten. Google und das Google-Logo sind Marken von Google LLC. Alle anderen Unternehmens- und Produktnamen können Marken der jeweils mit ihnen verbundenen Unternehmen sein.