WICHTIG:

Machen Sie bei jeder Aufgabe Screenshots von Ihrer Arbeit, um sie Ihrem Portfolio hinzuzufügen.

WICHTIG: Dieses Lab sollte nur auf einem Computer oder Laptop durchgeführt werden.

Pro Lab sind nur 5 Versuche zulässig.

Zur Erinnerung: Es ist ganz normal, beim ersten Versuch nicht alle Fragen richtig zu beantworten oder eine Aufgabe wiederholen zu müssen – das gehört zum Lernprozess.

Sobald ein Lab gestartet wurde, kann der Timer nicht mehr pausiert werden. Nach 1 Stunde und 30 Minuten wird das Lab beendet und Sie müssen von vorne beginnen.

Weitere Informationen finden Sie in den technischen Tipps zum Lab.

Aktivitätsübersicht

Dieses Lab ist Teil des Abschlussprojekts. In diesem Lab wenden Sie Ihr Wissen über Cloud-Cybersicherheit an, um Sicherheitslücken zu identifizieren und zu beheben.

Ihnen wird ein Szenario und eine Reihe von Aufgaben präsentiert, die Sie im Google Cloud Security Command Center erledigen sollen. Dabei müssen Sie mithilfe Ihrer neuen Kenntnisse aktive Sicherheitslücken im Zusammenhang mit einem Sicherheitsvorfall analysieren und beheben, Fragen zu den Sicherheitslücken beantworten und Aufgaben lösen, bei denen Ihre Cloud-Cybersicherheitskenntnisse bewertet werden.

Außerdem gibt es im Lab eine Reihe von Challenges. Eine Challenge ist eine Aufgabe, die Sie ohne Anleitung lösen müssen.

Wenn Sie dieses Lab erfolgreich absolviert haben, können Sie Sicherheitslücken und Fehlkonfigurationen in der Cloud-Umgebung erkennen, priorisieren und beheben. Dies sind unverzichtbare Fähigkeiten dafür, die Sicherheit von Google Cloud-Umgebungen zu verbessern und das Risiko von Datenpannen, unbefugtem Zugriff und anderen Sicherheitsvorfällen zu verringern.

Szenario

Seit einem Jahr arbeiten Sie als Junior Cloud Security Analyst bei Cymbal Retail. Cymbal Retail ist marktführend mit 170 Ladengeschäften und einer Onlineplattform in 28 Ländern. 2022 erwirtschaftete das Unternehmen einen Umsatz von 15 Milliarden US-Dollar und beschäftigt derzeit 80.400 Mitarbeitende weltweit.

Cymbal Retail hat einen großen Kundenstamm und täglich finden zahlreiche Transaktionen auf der Onlineplattform statt. Das Unternehmen legt großen Wert auf die Sicherheit seiner Kundinnen und Kunden, Mitarbeitenden und Assets und sorgt dafür, dass die jeweiligen Abläufe in allen Ländern, in denen es tätig ist, den internen und externen Erwartungen an die Einhaltung regulatorischer Anforderungen entsprechen.

Vor Kurzem war das Unternehmen von einer massiven Datenpanne betroffen. Als Junior-Mitglied des Sicherheitsteams unterstützen Sie das Team während des gesamten Lebenszyklus dieses Sicherheitsvorfalls. Zuerst identifizieren Sie die Sicherheitslücken, die zu der Datenpanne geführt haben. Dann isolieren und beheben Sie die Datenpanne, um weiteren unbefugten Zugriff zu verhindern. Anschließend stellen Sie die kompromittierten Systeme wieder her, beheben alle noch ausstehenden Compliance-Probleme und überprüfen die Einhaltung der Frameworks.

So gehen Sie vor: Zuerst untersuchen Sie die Sicherheitslücken und Ergebnisse im Google Cloud Security Command Center. Als Nächstes fahren Sie die alte VM herunter und erstellen eine neue VM aus einem Snapshot. Dann widerrufen Sie den öffentlichen Zugriff auf den Storage-Bucket und wechseln zur einheitlichen Zugriffssteuerung auf Bucket-Ebene. Als Nächstes beschränken Sie den Zugriff auf die Firewallports und korrigieren die Firewallregeln. Zum Schluss erstellen Sie einen Bericht, mit dem Sie die Behebung der Sicherheitslücken dokumentieren.

Einrichtung

Bevor Sie auf „Lab starten“ klicken

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 die Ressourcen für das Lab verfügbar sind.

In diesem praxisorientierten Lab führen Sie die Aktivitäten eigenständig in einer echten Cloud-Umgebung durch, nicht in einer Simulation oder einer 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, 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: Wenn Sie über ein persönliches Google Cloud-Konto oder -Projekt verfügen, verwenden Sie es nicht für dieses Lab. So werden zusätzliche Kosten für Ihr Konto vermieden.

Lab starten und bei der Google Cloud Console anmelden

1. Klicken Sie auf Lab starten. Auf der linken Seite befindet sich der Bereich Details zum Lab mit diesen Informationen:

   • Restzeit
   • Schaltfläche Google Cloud Console öffnen
   • Temporäre Anmeldedaten für das Lab
   • Ggf. weitere Informationen für dieses Lab
   Hinweis: Wenn Sie für das Lab bezahlen müssen, wird ein Pop-up-Fenster geöffnet, in dem Sie Ihre Zahlungsmethode auswählen können.

2. 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). Die Anmeldeseite wird in einem neuen Browsertab geöffnet.

   Tipp: Sie können die Tabs in getrennten Fenstern nebeneinander anordnen, um bequem zwischen ihnen zu wechseln.

   Hinweis: Wenn das Dialogfeld Konto auswählen angezeigt wird, klicken Sie auf Anderes Konto verwenden.

3. Kopieren Sie bei Bedarf den folgenden Google Cloud-Nutzernamen und fügen Sie ihn in das Dialogfeld Anmelden ein. Klicken Sie dann auf Weiter.

{{{user_0.username | "Google Cloud username"}}}

Sie finden den Google Cloud-Nutzernamen auch im Bereich Details zum Lab.

4. Kopieren Sie das folgende Google Cloud-Passwort und fügen Sie es in das Dialogfeld Willkommen ein. Klicken Sie dann auf Weiter.

{{{user_0.password | "Google Cloud password"}}}

Sie finden das Google Cloud-Passwort auch im Bereich Details zum Lab.

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.

5. Klicken Sie sich durch die nachfolgenden Seiten:
   • Akzeptieren Sie die Nutzungsbedingungen.
   • Fügen Sie keine Wiederherstellungsoptionen oder 2-Faktor-Authentifizierung hinzu (da dies nur ein temporäres Konto ist).
   • Melden Sie sich nicht für kostenlose Testzeiträume an.

Nach wenigen Augenblicken wird die Console in diesem Tab geöffnet.

Hinweis: Wenn Sie sich eine Liste der Google Cloud-Produkte und ‑Dienste ansehen möchten, klicken Sie oben links auf das Navigationsmenü.

Aufgabe 1: Datenpanne analysieren und Informationen sammeln

Eines Morgens entdeckt das Sicherheitsteam ungewöhnliche Aktivitäten in seinen Systemen. Weitere Untersuchungen dieser Aktivität zeigen schnell, dass das Unternehmen einen massiven Sicherheitsverstoß in seinen Anwendungen, Netzwerken, Systemen und Datenrepositories erlitten hat. Angreifende verschafften sich unbefugten Zugriff auf sensible Kundendaten, darunter Kreditkartendaten und personenbezogene Daten. Dieser Vorfall erfordert sofortige Aufmerksamkeit und eine gründliche Untersuchung. Der erste Schritt, um den Umfang und die Auswirkungen dieser Datenpanne zu verstehen, besteht darin, Informationen zu sammeln und die verfügbaren Daten zu analysieren.

In dieser Aufgabe untersuchen Sie die Sicherheitslücken und Ergebnisse im Google Cloud Security Command Center, um herauszufinden, wie die Angreifenden auf die Daten zugegriffen haben und welche Maßnahmen zur Behebung getroffen werden müssen.

Wichtig: Die in diesem Abschnitt aufgeführten Sicherheitslücken setzen voraus, dass zuvor bestimmte Sicherheitsprüfungen durchgeführt wurden. Wenn einige Prüfungen noch nicht ausgeführt wurden, werden die entsprechenden Sicherheitslücken möglicherweise nicht im Security Command Center angezeigt, wenn Sie die Schritte in diesem Abschnitt ausführen. Machen Sie sich aber keine Sorgen. Sie können die Informationen aus dieser Aufgabe aber weiterhin verwenden, um die verfügbaren Ergebnisse zu analysieren und die Schritte zur Behebung in den folgenden Aufgaben auszuführen.

Rufen Sie zuerst das Security Command Center auf, um sich einen Überblick über die aktiven Sicherheitslücken zu verschaffen.

1. Klicken Sie in der Google Cloud Console im Navigationsmenü () auf Sicherheit > Risikoübersicht. Die Seite „Übersicht“ des Security Command Center wird geöffnet.
2. Wählen Sie im Bereich Fehlkonfigurationen den Tab Nach Ressourcentyp aus. Die Sicherheitsergebnisse oder Sicherheitslücken werden nach dem Typ der betroffenen Cloud-Ressource (z. B. Instanzen, Buckets, Datenbanken) organisiert. Wenn Sie aktive Sicherheitslücken und Ergebnisse nach Ressourcentyp überprüfen, können Sie Sicherheitsprobleme effektiv priorisieren und behandeln.

Es gibt sowohl kritische als auch mittlere Sicherheitslücken, die sich auf den Cloud Storage-Bucket, die Compute-Instance-VM und die Firewall beziehen.

Als Nächstes rufen Sie den PCI DSS-Bericht auf.

3. Klicken Sie im Menü Security Command Center auf Compliance. Die Seite „Compliance“ wird geöffnet.
4. Klicken Sie im Abschnitt Google Cloud-Compliance-Standards auf der Kachel PCI DSS 3.2.1 auf Details ansehen. Der Bericht „PCI DSS 3.2.1“ wird geöffnet.
5. Klicken Sie auf die Spalte Ergebnisse, um die Ergebnisse zu sortieren und die aktiven Ergebnisse oben in der Liste anzuzeigen.

Hinweis: Gehen Sie bei der Bewertung des PCI-Berichts unbedingt so vor wie hier beschrieben. Aktualisieren Sie die Seite nicht, da sonst die erforderlichen Filter entfernt werden und die korrekten Informationen nicht angezeigt werden.

Der Payment Card Industry Data Security Standard (PCI DSS) ist ein Regelwerk mit Sicherheitsanforderungen, die Unternehmen einhalten müssen, um sensible Karteninhaberdaten zu schützen. Als Einzelhandelsunternehmen, das Kreditkartenzahlungen akzeptiert und verarbeitet, muss Cymbal Retail auch die PCI DSS-Anforderungen erfüllen, um die Daten von Karteninhaberinnen und Karteninhabern zu schützen.

Beim Durchgehen des PCI DSS 3.2.1-Berichts stellen Sie fest, dass darin die nicht konformen Regeln aufgeführt sind, die mit der Datenpanne zusammenhängen:

• Firewallregel-Logging sollte aktiviert sein, damit Sie Netzwerkzugriffe prüfen können: Diese Warnung mit mittlerem Schweregrad weist darauf hin, dass das Firewallregel-Logging deaktiviert ist. Das bedeutet, dass es keine Aufzeichnungen darüber gibt, welche Firewallregeln angewendet werden und welcher Traffic zugelassen oder abgelehnt wird. Das ist ein Sicherheitsrisiko, da es somit schwierig wird, verdächtige Aktivitäten zu verfolgen und zu untersuchen.
• Firewallregeln sollten keine Verbindungen von allen IP-Adressen über den TCP- oder UDP-Port 3389 zulassen: Diese schwerwiegende Sicherheitslücke weist darauf hin, dass die Firewall so konfiguriert ist, dass RDP-Traffic (Remote Desktop Protocol) für alle Instanzen im Netzwerk aus dem gesamten Internet zugelassen wird. Das ist ein Sicherheitsrisiko, da sich so jeder im Internet mit dem RDP-Port auf jeder Instanz im Netzwerk verbinden kann.
• Firewallregeln sollten keine Verbindungen von allen IP-Adressen über den TCP- oder SCTP-Port 22 zulassen: Diese schwerwiegende Sicherheitslücke weist darauf hin, dass die Firewall so konfiguriert ist, dass Secure Shell-Traffic (SSH) von allen IP-Adressen im Internet zu allen Instanzen im Netzwerk zugelassen wird. SSH ist ein Protokoll, das einen sicheren Remotezugriff auf einen Computer ermöglicht. Wenn Angreifende über SSH Zugriff auf einen Computer erhalten, können sie möglicherweise Daten stehlen, Malware installieren oder Abläufe stören.
• VMs sollten keine öffentlichen IP-Adressen zugewiesen werden: Dieses schwerwiegende Ergebnis deutet darauf hin, dass eine bestimmte IP-Adresse aktiv im öffentlichen Internet verfügbar gemacht wurde und möglicherweise von unbefugten Personen aufgerufen werden kann. Dies wird als potenzielles Sicherheitsrisiko betrachtet, da Angreifende so nach Sicherheitslücken suchen oder Angriffe auf die zugehörige Ressource starten könnten.
• Cloud Storage-Buckets sollten nicht anonym oder öffentlich zugänglich sein: Dieses schwerwiegende Ergebnis weist darauf hin, dass es einen ACL-Eintrag (Access Control List) für den Speicher-Bucket gibt, der öffentlich zugänglich ist. Das bedeutet, dass jeder im Internet Dateien lesen kann, die in diesem Bucket gespeichert sind. Dies ist eine Sicherheitslücke mit hohem Risiko, die vorrangig behoben werden muss.
• Instanzen sollten nicht so konfiguriert werden, dass sie das Standarddienstkonto mit Vollzugriff auf alle Cloud APIs nutzen: Dieses Ergebnis mit mittlerem Schweregrad weist darauf hin, dass einer bestimmten Identität oder einem Dienstkonto Vollzugriff auf alle Google Cloud APIs gewährt wurde. Dieses Ergebnis wird als erhebliches Sicherheitsrisiko eingestuft, da es der Identität oder dem Dienstkonto die Möglichkeit gibt, beliebige Aktionen in der Google Cloud-Umgebung auszuführen, einschließlich des Zugriffs auf sensible Daten, der Änderung von Konfigurationen und des Löschens von Ressourcen.

Da Sie sich auf die Identifizierung und Behebung der Probleme im Zusammenhang mit dem Sicherheitsvorfall konzentrieren, ignorieren Sie bitte die folgenden Ergebnisse, da sie nicht mit den Behebungsaufgaben zusammenhängen, die Sie durchführen:

• VPC-Flusslogs sollten für alle Subnetze im VPC-Netzwerk aktiviert sein: Es gibt mehrere Ergebnisse mit niedriger Schwere für deaktivierte Flusslogs. Dies bedeutet, dass Flusslogs für eine Reihe von Subnetzwerken im Google Cloud-Projekt, das für dieses Lab verwendet wird, nicht aktiviert sind. Dies ist ein potenzielles Sicherheitsrisiko, da Flusslogs wertvolle Einblicke in die Muster des Netzwerkverkehrs bieten, die zur Identifizierung verdächtiger Aktivitäten und zur Untersuchung von Sicherheitsvorfällen beitragen können.

Hinweis: Das Aktivieren des Logging für Cloud-Ressourcen ist wichtig, um die Beobachtbarkeit aufrechtzuerhalten. Sie werden dieses Ergebnis in dieser Lab-Aktivität jedoch nicht beheben, da die Subnetzwerke Teil dieser Lab-Umgebung sind. Daher ist dieses Ergebnis auch nach Abschluss der Behebungsaufgaben im Bericht sichtbar.

• Einfache Rollen („Owner“, „Writer“, „Reader“) gewähren zu viele Berechtigungen und sollten nicht verwendet werden: Diese Warnung mit mittlerem Schweregrad weist darauf hin, dass in der Google Cloud-Umgebung einfache Rollen verwendet werden. Dies ist ein potenzielles Sicherheitsrisiko, da einfache Rollen einen umfassenden Zugriff auf eine Vielzahl von Ressourcen gewähren.
• Eine Regel zum Ablehnen von ausgehendem Traffic sollte festgelegt sein: Dieses Ergebnis mit niedrigem Schweregrad weist darauf hin, dass für die überwachte Firewall keine Regel zum Ablehnen von ausgehendem Traffic definiert ist. Dieses Ergebnis wirft potenzielle Sicherheitsbedenken auf, da es darauf hindeutet, dass der ausgehende Traffic nicht eingeschränkt ist, was möglicherweise sensible Daten offenlegt oder unbefugte Kommunikation ermöglicht.

In der folgenden Tabelle sind die im Bericht aufgeführten Regeln mit der entsprechenden Kategorie von Ergebnissen verknüpft. Das hilft Ihnen später bei der Untersuchung der Ergebnisse nach Ressourcentyp:

Ergebniskategorie	Regel
Firewallregel-Logging deaktiviert	Firewallregel-Logging sollte aktiviert sein, damit Sie Netzwerkzugriffe prüfen können
Offener RDP-Port	Firewallregeln sollten keine Verbindungen von allen IP-Adressen über den TCP- oder UDP-Port 3389 zulassen
Offener SSH-Port	Firewallregeln sollten keine Verbindungen von allen IP-Adressen über den TCP- oder SCTP-Port 22 zulassen
Öffentliche IP-Adresse	VMs sollten keine öffentlichen IP-Adressen zugewiesen werden
ACL des öffentlichen Buckets	Cloud Storage-Buckets sollten nicht anonym oder öffentlich zugänglich sein
Vollständiger API-Zugriff	Instanzen sollten nicht so konfiguriert werden, dass sie das Standarddienstkonto mit Vollzugriff auf alle Cloud APIs nutzen
Flusslogs deaktiviert	VPC-Flusslogs sollten für alle Subnetze im VPC-Netzwerk aktiviert sein
Einfache Rollen verwendet	Einfache Rollen („Owner“, „Writer“, „Reader“) gewähren zu viele Berechtigungen und sollten nicht verwendet werden
Ablehnungsregel für ausgehenden Traffic nicht festgelegt	Eine Regel zum Ablehnen von ausgehendem Traffic sollte festgelegt sein

Insgesamt deuten diese Ergebnisse auf einen kritischen Mangel an Sicherheitskontrollen und die Nichteinhaltung wesentlicher PCI DSS-Anforderungen hin. Sie verweisen auch auf die mit der Datenpanne verbundenen Sicherheitslücken.

Als Nächstes rufen Sie das Security Command Center auf und filtern die Ergebnisse, um die Sicherheitslücken in der Google Cloud-Umgebung genauer zu untersuchen und zu analysieren.

6. Klicken Sie in der Google Cloud Console im Navigationsmenü () auf Sicherheit > Ergebnisse. Die Seite Ergebnisse wird geöffnet.
7. Wählen Sie im Bereich Schnellfilter im Abschnitt Ressourcentyp das Kästchen für den Ressourcentyp Google Cloud Storage-Bucket aus.

Es sollten die folgenden aktiven Ergebnisse für den Speicher-Bucket aufgeführt sein:

• ACL des öffentlichen Buckets: Dieses Ergebnis wird im PCI DSS-Bericht aufgeführt und bedeutet, dass jeder mit Internetzugang die im Bucket gespeicherten Daten lesen kann.
• „Nur Bucket-Richtlinie“ deaktiviert: Dies bedeutet, dass es keine explizite Bucket-Richtlinie gibt, die regelt, wer auf die Daten im Bucket zugreifen kann.
• Bucket-Logging deaktiviert: Dies bedeutet, dass für den Bucket kein Logging aktiviert ist. Daher ist es schwierig, nachzuverfolgen, wer auf die Daten zugreift.

Diese Ergebnisse deuten darauf hin, dass der Bucket mit einer Kombination von Sicherheitseinstellungen konfiguriert ist, die die Daten einem unbefugten Zugriff aussetzen könnten. Sie müssen diese Ergebnisse beheben, indem Sie die Zugriffssteuerungsliste entfernen, die den öffentlichen Zugriff vorsieht, indem Sie den öffentlichen Bucket-Zugriff deaktivieren und die einheitliche Zugriffsrichtlinie auf Bucket-Ebene aktivieren.

Hinweis: Das Aktivieren des Logging für Cloud-Ressourcen ist wichtig, um die Beobachtbarkeit aufrechtzuerhalten. In dieser Lab-Aktivität beheben Sie das Ergebnis „Bucket-Logging deaktiviert“ jedoch nicht, da dies die Arbeit mit mehreren Projekten erfordern würde. Daher ist dieses Ergebnis auch nach Abschluss der Behebungsmaßnahmen noch sichtbar.

8. Deaktivieren Sie im Bereich Schnellfilter im Abschnitt Ressourcentyp das Kästchen Google Cloud Storage-Bucket und aktivieren Sie das Kästchen für den Ressourcentyp Google Compute Instance.

Die folgenden aktiven Ergebnisse, die sich auf die virtuelle Maschine mit dem Namen cc-app-01 beziehen, sollten aufgeführt sein:

• Fehlerhafte Malware-Domain: Dieser Eintrag zeigt, dass von der google.compute.instance mit dem Namen „cc-app-01“ auf eine Domain zugegriffen wurde, die bekanntermaßen mit Malware in Verbindung steht. Obwohl diese Feststellung als nicht schwerwiegend eingestuft wird, deutet sie darauf hin, dass auf der VM-Instanz schädliche Aktivitäten stattgefunden haben und sie kompromittiert wurde.
• Compute Secure Boot deaktiviert: Dieses Ergebnis mit mittlerem Schweregrad gibt an, dass Secure Boot für die virtuelle Maschine deaktiviert ist. Das ist ein Sicherheitsrisiko, da die virtuelle Maschine mit nicht autorisiertem Code gestartet werden kann, der zum Kompromittieren des Systems verwendet werden könnte.
• Standarddienstkonto verwendet: Dieses Ergebnis mit mittlerem Schweregrad gibt an, dass die virtuelle Maschine das Standarddienstkonto verwendet. Dies ist ein Sicherheitsrisiko, da das Standarddienstkonto über umfangreiche Zugriffsrechte verfügt und kompromittiert werden könnte, wenn Angreifende Zugriff auf das Projekt erhalten.
• Öffentliche IP-Adresse: Dieses Ergebnis mit hoher Schwere wird im PCI DSS-Bericht aufgeführt und gibt an, dass die virtuelle Maschine eine öffentliche IP-Adresse hat. Das ist ein Sicherheitsrisiko, da sich jeder im Internet direkt mit der virtuellen Maschine verbinden kann.
• Vollständiger API-Zugriff: Dieses Ergebnis mit mittlerem Schweregrad wird im PCI DSS-Bericht aufgeführt und gibt an, dass der virtuellen Maschine vollständiger Zugriff auf alle Google Cloud APIs gewährt wurde.

Diese Ergebnisse deuten darauf hin, dass die virtuelle Maschine so konfiguriert war, dass sie sehr anfällig für den Angriff war. Um diese Ergebnisse zu beheben, fahren Sie die ursprüngliche VM (cc-app-01) herunter und erstellen eine VM (cc-app-02) mit einem bereinigten Snapshot des Laufwerks. Die neue VM hat die folgenden Einstellungen:

• Kein Compute-Dienstkonto
• Firewallregel-Tag für eine neue Regel für kontrollierten SSH-Zugriff
• Secure Boot aktiviert
• Öffentliche IP-Adresse auf „Keine“ gesetzt

9. Maximieren Sie im Feld Zeitraum das Drop-down-Menü und wählen Sie Letzte 30 Tage aus. So werden in der Liste Ergebnisse der letzten 30 Tage angezeigt.
10. Deaktivieren Sie im Bereich Schnellfilter im Abschnitt Ressourcentyp das Kästchen Google Compute-Instanz und aktivieren Sie das Kästchen für den Ressourcentyp Google Compute-Firewall.

Die folgenden aktiven Ergebnisse, die sich auf die Firewall beziehen, sollten aufgeführt werden:

• Offener SSH-Port: Dieses Ergebnis mit hohem Schweregrad weist darauf hin, dass die Firewall so konfiguriert ist, dass Secure Shell-Traffic (SSH) aus dem gesamten Internet zu allen Instanzen im Netzwerk zugelassen wird.
• Offener RDP-Port: Dieses Ergebnis mit hohem Schweregrad weist darauf hin, dass die Firewall so konfiguriert ist, dass RDP-Traffic (Remote Desktop Protocol) aus dem gesamten Internet zu allen Instanzen im Netzwerk zugelassen wird.
• Firewallregel-Logging deaktiviert: Dieses Ergebnis mit mittlerem Schweregrad weist darauf hin, dass das Logging von Firewallregeln deaktiviert ist. Das bedeutet, dass es keine Aufzeichnung darüber gibt, welche Firewallregeln angewendet werden und welcher Traffic zugelassen oder abgelehnt wird.

Diese Ergebnisse sind alle im PCI DSS-Bericht aufgeführt und weisen auf eine erhebliche Sicherheitslücke in der Netzwerkkonfiguration hin. Der fehlende eingeschränkte Zugriff auf RDP- und SSH-Ports in Verbindung mit dem deaktivierten Logging von Firewallregeln macht das Netzwerk sehr anfällig für unbefugte Zugriffsversuche und potenzielle Datenpannen. Sie müssen diese beheben, indem Sie die vorhandenen, zu weit gefassten Firewallregeln entfernen und sie durch eine Firewallregel ersetzen, die den SSH-Zugriff nur von den Adressen zulässt, die vom IAP-SSH-Dienst von Google Cloud verwendet werden.

Nachdem Sie die Sicherheitslücken analysiert haben, können Sie nun die Ergebnisse des Berichts beheben.

Aufgabe 2: Sicherheitslücken in Compute Engine beheben

In dieser Aufgabe fahren Sie die anfällige VM cc-app-01 herunter und erstellen eine neue VM aus einem Snapshot, der vor der Malware-Infektion aufgenommen wurde. VM-Snapshots eignen sich gut, um das System in einen bereinigten Zustand zurückzusetzen. Außerdem wird sichergestellt, dass die neue VM nicht mit derselben Malware infiziert wird, die die ursprüngliche VM kompromittiert hat.

1. Klicken Sie in der Google Cloud Console auf das Navigationsmenü ().
2. Wählen Sie Compute Engine > VM-Instanzen aus. Die Seite „VM-Instanzen“ wird geöffnet.

Die aktuelle VM cc-app-01 sollte unter „VM-Instanzen“ aufgeführt sein. Dies ist die anfällige VM, die kompromittiert wurde und heruntergefahren werden muss.

3. Markieren Sie das Kästchen für die VM cc-app-01.
4. Klicken Sie auf Beenden.
5. Ein Pop-up-Fenster wird angezeigt, in dem Sie gefragt werden, ob die VM beendet werden soll. Klicken Sie auf Beenden.

Klicken Sie auf Fortschritt prüfen, um zu sehen, ob Sie die Aufgabe richtig ausgeführt haben.

VM mit Sicherheitslücke herunterfahren

Als Nächstes erstellen Sie eine neue VM aus einem Snapshot. Dieser Snapshot wurde bereits im Rahmen des langfristigen Datensicherungsplans von Cymbal Retail erstellt.

6. Klicken Sie in der Aktionsleiste auf + Instanz erstellen.
7. Geben Sie im Abschnitt Maschinenkonfiguration im Feld Name den Namen cc-app-02 ein.
8. Wählen Sie als Maschinentyp im Drop-down-Menü die Option Gemeinsam genutzter Kern > e2-medium aus.
9. Klicken Sie auf den Bereich Betriebssystem und Speicher und dann auf Ändern für Betriebssystem und Speicher.
10. Wählen Sie den Tab Snapshots aus.
11. Maximieren Sie das Drop-down-Menü Snapshot und wählen Sie cc-app01-snapshot aus.
12. Klicken Sie auf Auswählen.
13. Geben Sie im Abschnitt Netzwerk im Feld Netzwerk-Tags den Wert cc ein. Mit diesem Tag wenden Sie Firewallregeln auf diese bestimmte VM an.
14. Maximieren Sie im Abschnitt Netzwerkschnittstellen das Standard-Netzwerk.
15. Maximieren Sie das Drop-down-Menü Externe IPv4-Adresse und wählen Sie Keine aus.
16. Maximieren Sie im Abschnitt Sicherheit für den Abschnitt Identität und API-Zugriff das Drop-down-Menü Dienstkonten und wählen Sie Dienstkonto für Qwiklabs-Nutzer aus.
17. Klicken Sie auf Erstellen.

Die neue VM cc-app-02 sollte jetzt aus dem Snapshot cc-app01-snapshot erstellt werden. (Es kann einige Minuten dauern, bis die neue VM erstellt ist.)

Aktivieren Sie jetzt Secure Boot für die neue VM cc-app-02, um das Ergebnis Secure Boot deaktiviert zu beheben.

18. Markieren Sie das Kästchen für die VM cc-app-02.
19. Klicken Sie auf Beenden.
20. Ein Pop-up-Fenster wird angezeigt, in dem Sie gefragt werden, ob die VM beendet werden soll. Klicken Sie auf Beenden.

Warten Sie, bis die VM cc-app-02 beendet ist, bevor Sie fortfahren.

21. Klicken Sie im Abschnitt VM-Instanzen auf den Link cc-app-02. Die Seite „cc-app-02“ wird geöffnet.
22. Klicken Sie in der Symbolleiste cc-app-02 auf Bearbeiten. Die Seite „cc-app-02-Instanz bearbeiten“ wird geöffnet.
23. Scrollen Sie nach unten zum Abschnitt Sicherheit und Zugriff und wählen Sie unter Shielded VM das Kästchen für die Option Secure Boot aktivieren aus. Dadurch wird das Ergebnis Compute Secure Boot deaktiviert behoben.
24. Klicken Sie auf Speichern.
25. Wählen Sie im Menü Compute Engine die Option VM-Instanzen aus.
26. Markieren Sie das Kästchen für die VM cc-app-02.
27. Klicken Sie auf Starten/Fortsetzen.
28. Ein Pop-up-Fenster wird angezeigt, in dem Sie aufgefordert werden, den Start der VM zu bestätigen. Klicken Sie auf Starten.

Die VM-Instanz cc-app-02 wird neu gestartet und die Sicherheitslücke Secure Boot deaktiviert wird behoben.

Klicken Sie auf Fortschritt prüfen, um zu sehen, ob Sie die Aufgabe richtig ausgeführt haben.

Neue VM aus vorhandenem Snapshot erstellen

Challenge: Kompromittierte VM löschen

Löschen Sie die kompromittierte VM cc-app-01.

Klicken Sie auf Fortschritt prüfen, um zu sehen, ob Sie die Aufgabe richtig ausgeführt haben.

Kompromittierte VM löschen

Mit diesen Schritten haben Sie erfolgreich eine neue VM aus dem Snapshot erstellt, die frei von Malware und Fehlkonfigurationen ist. Außerdem haben Sie die kompromittierte VM gelöscht und damit die Quelle der Sicherheitslücke beseitigt.

Aufgabe 3: Bucket-Berechtigungen in Cloud Storage korrigieren

In dieser Aufgabe widerrufen Sie den öffentlichen Zugriff auf den Storage-Bucket und wechseln zur einheitlichen Zugriffssteuerung auf Bucket-Ebene. Dadurch wird das Risiko von Datenpannen erheblich reduziert. Wenn Sie alle Nutzerberechtigungen für den Storage-Bucket entfernen, können Sie unbefugten Zugriff auf die darin gespeicherten Daten verhindern.

1. Wählen Sie im Navigationsmenü () die Option Cloud Storage > Buckets aus. Die Seite „Buckets“ wird geöffnet.
2. Klicken Sie auf folgenden Link zum Storage-Bucket: _bucket. Die Seite mit den Bucket-Details wird geöffnet.

Sie sehen, dass sich im öffentlich zugänglichen Bucket die Datei myfile.csv befindet. Diese Datei enthält die vertraulichen Informationen, die von der böswilligen Akteurin bzw. dem böswilligen Akteur extrahiert wurden. Führen Sie die folgenden Schritte aus, um das Ergebnis ACL des öffentlichen Buckets zu beheben.

3. Klicken Sie auf den Tab Berechtigungen.

4. Klicken Sie unter Öffentlicher Zugriff auf Öffentlichen Zugriff verhindern.

5. Klicken Sie auf Bestätigen.

Challenge: Zugriff auf Storage-Bucket ändern

Stellen Sie die Zugriffssteuerung auf einheitlich um und entfernen Sie die Berechtigungen für die Hauptkonten allUsers aus dem Storage-Bucket, um ein einzelnes Set an Berechtigungen für den Bucket und seine Objekte zu erzwingen. Außerdem müssen Sie dafür sorgen, dass Nutzerinnen und Nutzer, die auf einfache Projektrollen angewiesen sind, um auf den Bucket zuzugreifen, ihren Zugriff nicht verlieren.

Klicken Sie auf Fortschritt prüfen, um zu sehen, ob Sie die Aufgabe richtig ausgeführt haben.

Zugriff auf Storage-Bucket ändern

Sie haben nun den öffentlichen Zugriff auf den Bucket verhindert, die einheitliche Zugriffssteuerung auf Bucket-Ebene aktiviert und alle Nutzerberechtigungen entfernt. Damit haben Sie die Ergebnisse ACL des öffentlichen Buckets, „Nur Bucket-Richtlinie“ deaktiviert und Bucket-Logging deaktiviert behoben.

Aufgabe 4: Zugriff auf Firewallports einschränken

In dieser Aufgabe beschränken Sie den Zugriff auf RDP- und SSH-Ports auf autorisierte Quellnetzwerke, um die Angriffsfläche zu verkleinern und das Risiko eines unbefugten Remotezugriffs zu verringern.

Seien Sie äußerst vorsichtig, wenn Sie Firewallregeln mit zu vielen Berechtigungen ändern. Die Regeln lassen möglicherweise legitimen Traffic zu und eine falsche Einschränkung könnte kritische Abläufe stören. In diesem Lab sorgen Sie dafür, dass die mit dem Ziel-Tag „cc“ gekennzeichneten Compute Engine-VM-Instanzen über SSH-Verbindungen aus dem Adressbereich des Google Cloud Identity-Aware-Proxys (35.235.240.0/20) erreichbar bleiben. Damit der Verwaltungszugriff nicht unterbrochen wird, erstellen Sie eine neue Firewallregel mit eingeschränktem Zugriff für SSH-Traffic, bevor Sie die vorhandene Regel entfernen, die SSH-Verbindungen von jeder Adresse aus zulässt.

Challenge: SSH-Zugriff einschränken

Erstellen Sie eine neue Firewallregel limit-ports. Diese Regel muss den SSH-Zugriff auf autorisierte IP-Adressen aus dem Quellnetzwerk 35.235.240.0/20 auf Compute-Instanzen mit dem Ziel-Tag cc beschränken.

Klicken Sie auf Fortschritt prüfen, um zu sehen, ob Sie die Aufgabe richtig ausgeführt haben.

SSH-Zugriff einschränken

Aufgabe 5: Firewallkonfiguration korrigieren

In dieser Aufgabe löschen Sie drei bestimmte VPC-Firewallregeln, die für den uneingeschränkten Zugriff auf bestimmte Netzwerkprotokolle (ICMP, RDP und SSH) von jeder Quelle innerhalb des VPC-Netzwerks verantwortlich sind. Anschließend aktivieren Sie das Logging für die verbleibenden Firewallregeln.

Challenge: Firewallregeln anpassen

Löschen Sie die Firewallregeln default-allow-icmp, default-allow-rdp und default-allow-ssh. Diese Regeln sind zu allgemein. Wenn Sie sie löschen, schaffen Sie eine sicherere und besser kontrollierbare Netzwerkumgebung.

Durch das Löschen dieser Regeln haben Sie den Zugriff auf diese Protokolle eingeschränkt, wodurch die Wahrscheinlichkeit unbefugter Zugriffsversuche verringert und die Angriffsfläche Ihres Netzwerks reduziert wird.

Firewallregeln anpassen

Challenge: Logging aktivieren

Aktivieren Sie das Logging für die verbleibenden Firewallregeln limit-ports (die Regel, die Sie in einer vorherigen Aufgabe erstellt haben) und default-allow-internal.

Wenn Sie das Logging aktivieren, können Sie den Traffic verfolgen und analysieren, der durch diese Regel zugelassen wird. Dabei handelt es sich wahrscheinlich um internen Traffic zwischen Instanzen in Ihrer VPC.

Klicken Sie auf Fortschritt prüfen, um zu sehen, ob Sie die Aufgabe richtig ausgeführt haben.

Logging aktivieren

Durch das Anpassen von Firewallregeln und das Aktivieren des Loggings haben Sie die Ergebnisse Offener SSH-Port, Offener RDP-Port und Firewallregel-Logging deaktiviert behoben. Die neue Firewallregel schützt das Netzwerk besser und verbessert die Transparenz.

Aufgabe 6: Compliance prüfen

Nachdem Sie die im PCI DSS 3.2.1-Bericht aufgeführten Sicherheitslücken sorgfältig behoben haben, sollten Sie die Wirksamkeit Ihrer Maßnahmen überprüfen. In dieser Aufgabe führen Sie den Bericht noch einmal aus, um sicherzustellen, dass die zuvor identifizierten Sicherheitslücken erfolgreich geschlossen wurden und keine Sicherheitsrisiken mehr für die Umgebung darstellen.

1. Klicken Sie im Menü Security Command Center auf Compliance. Die Seite „Compliance“ wird geöffnet.
2. Klicken Sie im Abschnitt Google Cloud-Compliance-Standards auf der Kachel PCI DSS 3.2.1 auf Details ansehen. Der Bericht „PCI DSS 3.2.1“ wird geöffnet.
3. Klicken Sie auf die Spalte Ergebnisse, um die Ergebnisse zu sortieren und die aktiven Ergebnisse oben in der Liste anzuzeigen.

Alle wichtigen Sicherheitslücken wurden behoben.

Hinweis: Sie haben zwar die Sicherheitslücken mit hohem und mittlerem Schweregrad behoben, die Flusslogs bleiben aber für eine Reihe von Subnetzwerken deaktiviert. Dieses Ergebnis wird auch nach Abschluss der Behebungsaufgaben im Bericht sichtbar sein, da er sich auf diese Lab-Umgebung bezieht.

Fazit

Gut gemacht!

Sie haben das Sicherheitsteam der Cymbal Bank dabei unterstützt, die Auswirkungen der Datenpanne zu mindern, die identifizierten Sicherheitslücken zu schließen und die Sicherheit der Google Cloud-Umgebung der Cymbal Bank deutlich zu verbessern.

Zuerst haben Sie die Sicherheitslücken und Ergebnisse im Google Cloud Security Command Center untersucht und analysiert.

Als Nächstes haben Sie die alte VM heruntergefahren und eine neue VM aus einem Snapshot erstellt, der vor der Malware-Infektion aufgenommen wurde.

Anschließend haben Sie die Cloud Storage-Berechtigungen korrigiert, indem Sie den öffentlichen Zugriff auf den Storage-Bucket aufgehoben und auf eine einheitliche Zugriffssteuerung auf Bucket-Ebene umgestellt haben. Außerdem haben Sie alle Nutzerberechtigungen für den Storage-Bucket entfernt.

Als Nächstes haben Sie die Firewallregeln korrigiert, indem Sie die Firewallregeln „default-allow-icmp“, „default-allow-rdp“ und „default-allow-ssh“ gelöscht und das Logging für die verbleibenden Firewallregeln aktiviert haben.

Zum Schluss führen Sie einen Compliance-Bericht aus, um zu bestätigen, dass die Sicherheitslücken behoben wurden.

Denken Sie daran, dass es für Sie als Sicherheitsanalystin bzw. Sicherheitsanalyst von entscheidender Bedeutung ist, regelmäßige Sicherheitsprüfungen durchzuführen und fortlaufende Überwachungspraktiken zu implementieren, um einen kontinuierlichen Schutz vor sich entwickelnden Bedrohungen und Sicherheitslücken zu gewährleisten.

Lab beenden

Bevor Sie das Lab beenden, sehen Sie nach, ob Sie alle Aufgaben erledigt haben. Wenn Sie soweit sind, klicken Sie auf Lab beenden und dann auf Senden.

Wenn Sie das Lab beenden, haben Sie keinen Zugriff mehr auf die Lab-Umgebung und können auch nicht mehr auf die darin ausgeführten Aufgaben zugreifen.

© 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.