Behebung von Security Health Analytics-Ergebnissen

Auf dieser Seite finden Sie eine Liste von Referenzleitfäden und -techniken zur Behebung von Security Health Analytics-Ergebnissen mithilfe von Security Command Center.

Sie benötigen ausreichende IAM-Rollen (Identity and Access Management), um die Ergebnisse anzusehen oder zu bearbeiten und auf Google Cloud-Ressourcen zuzugreifen oder diese zu ändern. Wenn beim Zugriff auf Security Command Center in der Google Cloud Console Berechtigungsfehler auftreten, wenden Sie sich an Ihren Administrator. Informationen zu Rollen finden Sie unter Zugriffssteuerung. Informationen zum Beheben von Ressourcenfehlern finden Sie in der Dokumentation für betroffene Produkte.

Hinweis: Wenn Sie Premium-Kunde sind und auf die Standardstufe umstellen möchten, sollten Sie alle Ergebnisse beheben, bevor Sie Ihre Stufe ändern. Die von Premium-Detektoren gemeldeten Ergebnisse können in der Standardstufe nicht automatisch aufgelöst werden. Weitere Informationen finden Sie unter Zwischen Stufen wechseln.

Behebung von Security Health Analytics-Ergebnissen

Dieser Abschnitt enthält Anweisungen zur Behebung aller Ergebnisse von Security Health Analytics.

Bei Suchergebnissen, die CIS-Benchmarks zugeordnet sind, stammen die Informationen zur Behebung von Problemen, sofern nicht anders angegeben, vom Center for Internet Security (CIS). Weitere Informationen finden Sie unter Detektoren und Compliance.

Achtung: Wenn Sie diese Konfiguration falsch vornehmen, kann sich dies auf die Produktionsumgebung auswirken. Wenn Sie einige vorgeschlagene Google Cloud-Dienste aktivieren, können Sie außerdem Ihre Cloud-Kosten erhöhen. Informieren Sie sich über die Auswirkungen aller Korrekturmaßnahmen, bevor Sie Änderungen vornehmen.

Deaktivierung von Ergebnissen nach der Behebung

Nachdem Sie eine Sicherheitslücke oder Fehlkonfiguration behoben haben, wird der Status des Ergebnisses in Security Health Analytics beim nächsten Scan automatisch auf INACTIVE gesetzt. Wie lange es dauert, bis ein behobenes Ergebnis in Security Health Analytics auf INACTIVE gesetzt wird, hängt davon ab, wann das Ergebnis behoben wird und wie der Zeitplan des Scans ist, bei dem das Ergebnis erkannt wird.

In Security Health Analytics wird der Status eines Ergebnisses auch auf INACTIVE gesetzt, wenn bei einem Scan festgestellt wird, dass die von dem Ergebnis betroffene Ressource gelöscht wurde. Wenn Sie einen Hinweis zu einer gelöschten Ressource aus dem Display entfernen möchten, während Sie darauf warten, dass Security Health Analytics erkennt, dass die Ressource gelöscht wurde, können Sie den Hinweis stummschalten. Informationen zum Ausblenden von Ergebnissen finden Sie unter Ergebnisse in Security Command Center ausblenden.

Verwenden Sie die Funktion „Stummschalten“ nicht, um behobene Probleme für vorhandene Ressourcen auszublenden. Wenn das Problem wieder auftritt und Security Health Analytics den Status ACTIVE des Ergebnisses wiederherstellt, wird es möglicherweise nicht angezeigt, da stummgeschaltete Ergebnisse von allen Ergebnisabfragen ausgeschlossen sind, in denen NOT mute="MUTED" angegeben ist, z. B. die Standardergebnisabfrage.

Informationen zu Scanintervallen finden Sie unter Security Health Analytics-Scantypen.

Access Transparency disabled

Kategoriename in der API: ACCESS_TRANSPARENCY_DISABLED

Access Transparency-Logs erfassen, wenn Google Cloud-Mitarbeiter zur Bereitstellung von Support auf die Projekte in Ihrer Organisation zugreifen. Aktivieren Sie Access Transparency, um zu protokollieren, wer von Google Cloud wann und warum auf Ihre Daten zugreift. Weitere Informationen finden Sie unter Access Transparency.

Damit Access Transparency für ein Projekt aktiviert werden kann, muss es mit einem Rechnungskonto verknüpft sein.

Erforderliche Rollen

Bitten Sie Ihren Administrator, Ihnen die IAM-Rolle Access Transparency Admin (roles/axt.admin) auf Organisationsebene zu gewähren, um die Berechtigungen zu erhalten, die Sie für diese Aufgabe benötigen. Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff verwalten.

Diese vordefinierte Rolle enthält die Berechtigungen axt.labels.get und axt.labels.set, die für diese Aufgabe erforderlich sind. Sie können diese Berechtigungen auch mit einer benutzerdefinierten Rolle oder anderen vordefinierten Rollen erhalten.

Schritte zur Abhilfe

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Prüfen Sie Ihre Berechtigungen auf Organisationsebene:

   1. Rufen Sie in der Google Cloud Console die Seite Identitäts- und Zugriffsverwaltung auf.

      Identitäts- und Zugriffsverwaltung aufrufen

   2. Wenn Sie dazu aufgefordert werden, wählen Sie im Auswahlmenü die Google Cloud-Organisation aus.

2. Wählen Sie über das Auswahlmenü ein beliebiges Google Cloud-Projekt in der Organisation aus.

   Access Transparency wird auf einer Google Cloud-Projektseite konfiguriert, aber für die gesamte Organisation aktiviert.

3. Gehen Sie zur Seite IAM & Verwaltung > Einstellungen.

4. Klicken Sie auf Access Transparency aktivieren.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

AlloyDB auto backup disabled

Kategoriename in der API: ALLOYDB_AUTO_BACKUP_DISABLED

In einem AlloyDB for PostgreSQL-Cluster sind keine automatischen Sicherungen aktiviert.

Aktivieren Sie automatische Sicherungen für Ihren Cluster, um Datenverlust besser zu verhindern. Weitere Informationen finden Sie unter Zusätzliche automatische Sicherungen konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite „AlloyDB for PostgreSQL-Cluster“ auf.

   AlloyDB for PostgreSQL-Cluster aufrufen

2. Klicken Sie in der Spalte Ressourcenname auf einen Cluster.

3. Klicken Sie auf Datenschutz.

4. Klicken Sie unter dem Bereich Richtlinie für automatische Sicherungen in der Zeile Automatische Sicherungen auf Bearbeiten.

5. Klicken Sie das Kästchen Automatische Sicherungen an.

6. Klicken Sie auf Aktualisieren.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

AlloyDB backups disabled

Kategoriename in der API: ALLOYDB_BACKUPS_DISABLED

Für einen AlloyDB for PostgreSQL-Cluster sind weder automatische noch kontinuierliche Sicherungen aktiviert.

Aktivieren Sie automatische oder kontinuierliche Sicherungen für Ihren Cluster, um Datenverluste besser zu verhindern. Weitere Informationen finden Sie unter Zusätzliche Sicherungen konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite „AlloyDB for PostgreSQL-Cluster“ auf.

   AlloyDB for PostgreSQL-Cluster aufrufen

2. Klicken Sie in der Spalte Ressourcenname auf den Namen des Clusters, der im Ergebnis angegeben ist.

3. Klicken Sie auf Datenschutz.

4. Richten Sie eine Sicherungsrichtlinie ein.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

AlloyDB CMEK disabled

Kategoriename in der API: ALLOYDB_CMEK_DISABLED

Ein AlloyDB-Cluster verwendet keine vom Kunden verwalteten Verschlüsselungsschlüssel (CMEK).

Mit CMEK werden die Schlüssel, die Sie in Cloud KMS erstellen und verwalten, die Schlüssel umschließen, die Google zum Verschlüsseln Ihrer Daten verwendet. Dadurch haben Sie mehr Kontrolle über den Zugriff auf Ihre Daten. Weitere Informationen finden Sie unter Informationen zu CMEK. CMEK verursacht zusätzliche Kosten im Zusammenhang mit Cloud KMS.

Achtung: Diese Abhilfemaßnahmen können Ihre Produktionsumgebung beeinträchtigen. Verschieben Sie ggf. Arbeitslasten, Daten oder Berechtigungen in neue Ressourcen, bevor Sie vorhandene Assets löschen.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite „AlloyDB for PostgreSQL-Cluster“ auf.

   AlloyDB for PostgreSQL-Cluster aufrufen

2. Klicken Sie in der Spalte Ressourcenname auf den Namen des Clusters, der im Ergebnis angegeben ist.

3. Klicken Sie auf Sicherung erstellen. Legen Sie eine Sicherungs-ID fest.

4. Klicken Sie auf Erstellen.

5. Klicken Sie im Bereich Sicherung/Wiederherstellung neben dem ausgewählten Eintrag Sicherungs-ID auf Wiederherstellen.

6. Legen Sie eine neue Cluster-ID und ein neues Netzwerk fest.

7. Klicken Sie auf Erweiterte Verschlüsselungsoptionen. Wählen Sie den CMEK aus, mit dem Sie den neuen Cluster verschlüsseln möchten.

8. Klicken Sie auf Wiederherstellen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

AlloyDB log min error statement severity

Kategoriename in der API: ALLOYDB_LOG_MIN_ERROR_STATEMENT_SEVERITY

Bei einer AlloyDB for PostgreSQL-Instanz ist das Datenbank-Flag log_min_error_statement nicht auf error oder einen anderen empfohlenen Wert festgelegt.

Das Flag log_min_error_statement steuert, ob SQL-Anweisungen, die Fehlerbedingungen verursachen, in Serverlogs aufgezeichnet werden. SQL-Anweisungen mit dem angegebenen Schweregrad oder höher werden in Logs geschrieben. Je höher der Schweregrad, desto weniger Meldungen werden aufgezeichnet. Wenn ein zu hoher Schweregrad festgelegt ist, werden Fehlermeldungen möglicherweise nicht in Logs geschrieben.

Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite „AlloyDB for PostgreSQL-Cluster“ auf.

   AlloyDB for PostgreSQL-Cluster aufrufen

2. Klicken Sie in der Spalte Ressourcenname auf den Cluster.

3. Klicken Sie unter Instanzen in Ihrem Cluster für die Instanz auf Bearbeiten.

4. Klicken Sie auf Advanced Configuration Options.

5. Legen Sie im Bereich Flags für das Datenbank-Flag log_min_error_statement gemäß der Logging-Richtlinie Ihrer Organisation einen der folgenden empfohlenen Werte fest.

   • debug5
   • debug4
   • debug3
   • debug2
   • debug1
   • info
   • notice
   • warning
   • error

6. Klicken Sie auf Instanz aktualisieren.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

AlloyDB log min messages

Kategoriename in der API: ALLOYDB_LOG_MIN_MESSAGES

Bei einer AlloyDB for PostgreSQL-Instanz ist das Datenbank-Flag log_min_messages nicht mindestens auf warning festgelegt.

Das Flag log_min_messages steuert, welche Nachrichtenebenen in Serverlogs aufgezeichnet werden. Je höher der Schweregrad, desto weniger Meldungen werden aufgezeichnet. Wenn Sie den Schwellenwert zu niedrig ansetzen, kann sich der Umfang des Logspeichers erhöhen, was das Auffinden tatsächlicher Fehler erschwert.

Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite „AlloyDB for PostgreSQL-Cluster“ auf.

   AlloyDB for PostgreSQL-Cluster aufrufen

2. Klicken Sie in der Spalte Ressourcenname auf den Cluster.

3. Klicken Sie unter Instanzen in Ihrem Cluster für die Instanz auf Bearbeiten.

4. Klicken Sie auf Advanced Configuration Options.

5. Legen Sie im Bereich Flags für das Datenbank-Flag log_min_messages gemäß der Logging-Richtlinie Ihrer Organisation einen der folgenden empfohlenen Werte fest.

   • debug5
   • debug4
   • debug3
   • debug2
   • debug1
   • info
   • notice
   • warning

6. Klicken Sie auf Instanz aktualisieren.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

AlloyDB log error verbosity

Kategoriename in der API: ALLOYDB_LOG_ERROR_VERBOSITY

Bei einer AlloyDB for PostgreSQL-Instanz ist das Datenbank-Flag log_error_verbosity nicht auf default oder einen anderen weniger restriktiven Wert festgelegt.

Das Flag log_error_verbosity steuert die Detailgenauigkeit von Meldungen, die in Logs geschrieben werden. Je höher der Ausführlichkeitsgrad, desto mehr Details werden in den Meldungen aufgezeichnet. Wir empfehlen, dieses Flag auf default oder einen anderen weniger restriktiven Wert festzulegen.

Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite „AlloyDB for PostgreSQL-Cluster“ auf.

   AlloyDB for PostgreSQL-Cluster aufrufen

2. Klicken Sie in der Spalte Ressourcenname auf den Cluster.

3. Klicken Sie unter Instanzen in Ihrem Cluster für die Instanz auf Bearbeiten.

4. Klicken Sie auf Advanced Configuration Options.

5. Legen Sie im Bereich Flags für das Datenbank-Flag log_error_verbosity gemäß der Logging-Richtlinie Ihrer Organisation einen der folgenden empfohlenen Werte fest.

   • default
   • verbose

6. Klicken Sie auf Instanz aktualisieren.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

AlloyDB Public IP

Kategoriename in der API: ALLOYDB_PUBLIC_IP

Eine AlloyDB for PostgreSQL-Datenbankinstanz hat eine öffentliche IP-Adresse.

Verwenden Sie private anstelle von öffentlichen IP-Adressen, um die Angriffsfläche Ihres Unternehmens zu verringern. Private IP-Adressen bieten eine höhere Netzwerksicherheit und eine geringere Latenz für Ihre Anwendung.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite „AlloyDB for PostgreSQL-Cluster“ auf.

   AlloyDB for PostgreSQL-Cluster aufrufen

2. Klicken Sie in der Spalte Ressourcenname auf den Namen des Clusters, der im Ergebnis angegeben ist.

3. Klicken Sie unter Instanzen in Ihrem Cluster für die Instanz auf Bearbeiten.

4. Entfernen Sie im Bereich Konnektivität das Häkchen bei Öffentliche IP-Adresse aktivieren.

5. Klicken Sie auf Instanz aktualisieren.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

AlloyDB SSL not enforced

Kategoriename in der API: ALLOYDB_SSL_NOT_ENFORCED

Für eine AlloyDB for PostgreSQL-Datenbankinstanz müssen nicht alle eingehenden Verbindungen SSL verwenden.

Damit bei sensiblen Daten bei der Übertragung durch unverschlüsselte Kommunikation keine Datenlecks entstehen, sollten alle bei Ihrer AlloyDB-Datenbank eingehenden Verbindungen SSL verwenden. SSL/TLS konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite „AlloyDB for PostgreSQL-Cluster“ auf.

   AlloyDB for PostgreSQL-Cluster aufrufen

2. Klicken Sie in der Spalte Ressourcenname auf den Namen des Clusters, der im Ergebnis angegeben ist.

3. Klicken Sie unter Instanzen in Ihrem Cluster für die Instanz auf Bearbeiten.

4. Klicken Sie im Bereich Netzwerksicherheit auf das Kästchen für SSL-Verschlüsselung verlangen.

5. Klicken Sie auf Instanz aktualisieren.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Admin service account

Kategoriename in der API: ADMIN_SERVICE_ACCOUNT

Einem Dienstkonto in Ihrer Organisation oder Ihrem Projekt sind Administrator-, Inhaber- oder Bearbeiter-Berechtigungen zugewiesen. Diese Rollen haben umfassende Berechtigungen und sollten nicht Dienstkonten zugewiesen werden. Weitere Informationen zu Dienstkonten und den dafür verfügbaren Rollen finden Sie unter Dienstkonten.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite IAM-Richtlinien auf.

   Zur IAM-Richtlinie

2. Für jedes im Ergebnis identifizierte Hauptkonto:

   1. Klicken Sie neben dem Hauptkonto auf  Hauptkonto bearbeiten.
   2. Wenn Sie Berechtigungen entfernen möchten, klicken Sie neben der Rolle auf Rolle löschen.
   3. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Alpha cluster enabled

Kategoriename in der API: ALPHA_CLUSTER_ENABLED

Alphaclusterfunktionen sind für einen GKE-Cluster (Google Kubernetes Engine) aktiviert.

Mit Alphaclustern können erste Nutzer mit Arbeitslasten experimentieren, die neue Features verwenden, bevor sie für die Allgemeinheit veröffentlicht werden. In Alphaclustern sind alle Features der GKE API aktiviert. Allerdings sind diese Cluster nicht durch das GKE-SLA abgedeckt und erhalten keine Sicherheitsupdates. Außerdem sind automatische Knotenupgrades und die automatische Knotenreparatur deaktiviert und es können keine Upgrades durchgeführt werden. Nach 30 Tagen werden sie außerdem automatisch gelöscht.

Achtung: Diese Abhilfemaßnahmen können Ihre Produktionsumgebung beeinträchtigen. Verschieben Sie ggf. Arbeitslasten, Daten oder Berechtigungen in neue Ressourcen, bevor Sie vorhandene Assets löschen.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

Alphacluster können nicht deaktiviert werden. Sie müssen einen neuen Cluster mit deaktivierten Alphafeatures erstellen.

1. Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.

   Zur Seite "Kubernetes-Cluster"

2. Klicken Sie auf Erstellen.

3. Wählen Sie neben dem zu erstellenden Clustertyp Konfigurieren aus.

4. Im Tab Features muss Kubernetes-Alphafeatures in diesem Cluster aktivieren deaktiviert sein.

   Hinweis: Wenn Sie GKE Autopilot ausgewählt haben, wird diese Option nicht angezeigt, da Alpha-Cluster nicht unterstützt werden.

5. Klicken Sie auf Erstellen.

6. Informationen zum Verschieben von Arbeitslasten auf den neuen Cluster finden Sie unter Arbeitslasten zu anderen Maschinentypen migrieren.

7. Informationen zum Löschen des ursprünglichen Clusters finden Sie unter Cluster löschen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

API key APIs unrestricted

Kategoriename in der API: API_KEY_APIS_UNRESTRICTED

API-Schlüssel werden zu umfassend verwendet.

Uneingeschränkte API-Schlüssel sind unsicher, da sie von Geräten, auf denen der Schlüssel gespeichert wird oder öffentlich sichtbar ist, abgerufen werden können, z. B. aus einem Browser. Konfigurieren Sie API-Schlüssel nach dem Prinzip der geringsten Berechtigung so, dass nur APIs aufgerufen werden, die für die Anwendung erforderlich sind. Weitere Informationen finden Sie unter Einschränkungen für API-Schlüssel anwenden.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite API-Schlüssel auf.

   Zu den API-Schlüsseln

2. Führen Sie für jeden API-Schlüssel die folgenden Schritte aus:

   1. Klicken Sie im Bereich API-Schlüssel in der Zeile für jeden API-Schlüssel, für den Sie APIs einschränken müssen, auf Aktionen.
   2. Klicken Sie im Menü Aktionen auf API-Schlüssel bearbeiten. Die Seite API-Schlüssel bearbeiten wird geöffnet.
   3. Wählen Sie im Abschnitt API-Einschränkungen die Option APIs einschränken aus. Das Drop-down-Menü APIs auswählen wird angezeigt.
   4. Wählen Sie in der Drop-down-Liste APIs auswählen aus, welche APIs zugelassen werden sollen.
      Warnung:Legen Sie für die API-Einschränkungen keine Google Cloud APIs fest, da dadurch der Zugriff auf alle von Google Cloud bereitgestellten Dienste möglich ist.
   5. Klicken Sie auf Speichern. Es kann bis zu fünf Minuten dauern, bis die Einstellungen wirksam werden.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

API key apps unrestricted

Kategoriename in der API: API_KEY_APPS_UNRESTRICTED

API-Schlüssel werden uneingeschränkt verwendet und ermöglichen die Nutzung durch nicht vertrauenswürdige Anwendungen.

Uneingeschränkte API-Schlüssel sind unsicher, da sie auf Geräten, auf denen der Schlüssel gespeichert wird oder öffentlich sichtbar ist, abgerufen werden können, z. B. aus einem Browser. Beschränken Sie nach dem Prinzip der geringsten Berechtigung die Nutzung von API-Schlüsseln auf vertrauenswürdige Hosts, HTTP-Verweis-URLs und Anwendungen. Weitere Informationen finden Sie unter Einschränkungen für API-Schlüssel anwenden.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite API-Schlüssel auf.

   Zu den API-Schlüsseln

2. Führen Sie für jeden API-Schlüssel die folgenden Schritte aus:

   1. Klicken Sie im Bereich API-Schlüssel in der Zeile für jeden API-Schlüssel, für den Sie Anwendungen einschränken müssen, auf Aktionen.
   2. Klicken Sie im Menü Aktionen auf API-Schlüssel bearbeiten. Die Seite API-Schlüssel bearbeiten wird geöffnet.
   3. Wählen Sie auf der Seite API-Schlüssel bearbeiten unter Anwendungseinschränkungen eine Einschränkungskategorie aus. Sie können pro Schlüssel eine Anwendungseinschränkung festlegen.
   4. Klicken Sie im Feld Element hinzufügen, das beim Auswählen einer Einschränkung angezeigt wird, auf Element hinzufügen, um je nach den Anforderungen Ihrer Anwendung Einschränkungen hinzuzufügen.
   5. Wenn Sie alle gewünschten Elemente hinzugefügt haben, klicken Sie auf Fertig.
      Warnung: Legen Sie als HTTP-Verweis-URLs keine Platzhalterzeichen fest, die den Zugriff auf beliebige/breite HTTP-Verweis-URLs zulassen. Beispiel:*, *.[TLD] oder.[TLD]/*. Legen Sie keine IP-Adressen und Verweis-URLs fest, die Host zulassen (0.0.0.0, ::0 oder 0.0.0.0/0).
   6. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

API key exists

Kategoriename in der API: API_KEY_EXISTS

Ein Projekt nutzt API-Schlüssel anstelle der Standardauthentifizierung.

API-Schlüssel sind weniger sicher als andere Authentifizierungsmethoden, da sie einfache verschlüsselte Strings sind und von anderen leicht gefunden und verwendet werden können. Sie können auf Geräten, auf denen der Schlüssel gespeichert wird oder öffentlich sichtbar ist, abgerufen werden, z. B. aus einem Browser. Außerdem lassen sich Nutzer oder Anwendungen, die Anfragen stellen, nicht anhand von API-Schlüsseln eindeutig identifiziert werden. Alternativ können Sie einen standardmäßigen Authentifizierungsablauf mit Dienstkonten oder Nutzerkonten verwenden.

Achtung: Diese Abhilfemaßnahmen können Ihre Produktionsumgebung beeinträchtigen. Verschieben Sie ggf. Arbeitslasten, Daten oder Berechtigungen in neue Ressourcen, bevor Sie vorhandene Assets löschen.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Ihre Anwendungen sollten mit einer alternativen Art der Authentifizierung konfiguriert werden.

2. Rufen Sie in der Google Cloud Console die Seite Anmeldedaten der API auf.

   Zu den API-Anmeldedaten

3. Klicken Sie im Bereich API-Schlüssel in der Zeile für jeden API-Schlüssel, den Sie löschen müssen, auf Aktionen.

4. Klicken Sie im Menü Aktionen auf API-Schlüssel löschen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

API key not rotated

Kategoriename in der API: API_KEY_NOT_ROTATED

Der API-Schlüssel wurde seit mehr als 90 Tagen nicht rotiert.

API-Schlüssel laufen nicht ab. Wenn ein Schlüssel gestohlen wird, kann er unbefristet verwendet werden, wenn er nicht vom Projektinhaber aufgehoben oder rotiert wird. Werden API-Schlüssel regelmäßig neu generiert, können gestohlene API-Schlüssel weniger lange verwendet werden, um Daten auf einem manipulierten oder gekündigten Konto aufzurufen. Rotieren Sie API-Schlüssel mindestens alle 90 Tage. Weitere Informationen finden Sie unter Best Practices für die Verwaltung von API-Schlüsseln.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite API-Schlüssel auf.

   Zu den API-Schlüsseln

2. Führen Sie für jeden API-Schlüssel die folgenden Schritte aus:

   1. Klicken Sie im Bereich API-Schlüssel in der Zeile des zu rotierenden API-Schlüssels auf Aktionen.
   2. Klicken Sie im Menü Aktionen auf API-Schlüssel bearbeiten. Die Seite API-Schlüssel bearbeiten wird geöffnet.
   3. Wenn auf der Seite API-Schlüssel bearbeiten das Datum im Feld Erstellungsdatum älter als 90 Tage ist, klicken Sie auf Schlüssel neu generieren. Es wird ein neuer Schlüssel generiert.
   4. Klicken Sie auf Speichern.
   5. Damit Ihre Anwendungen weiterhin unterbrechungsfrei funktionieren, sollten Sie den neuen API-Schlüssel aktualisieren. Der alte API-Schlüssel funktioniert 24 Stunden, bevor er dauerhaft deaktiviert wird.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Audit config not monitored

Kategoriename in der API: AUDIT_CONFIG_NOT_MONITORED

Logmesswerte und Benachrichtigungen sind nicht so konfiguriert, dass Änderungen an der Audit-Konfiguration überwacht werden.

Cloud-Audit-Logging erstellt Administrator- und Datenzugriffslogs, die Sicherheitsanalysen, das Verfolgen von Ressourcenänderungen und die Complianceprüfung ermöglichen. Durch das Monitoring der Audit-Konfigurationsänderungen sorgen Sie dafür, dass alle Aktivitäten in Ihrem Projekt jederzeit geprüft werden können. Weitere Informationen finden Sie in der Übersicht zu logbasierten Messwerten.

Abhängig von der Menge der Informationen können die Cloud Monitoring-Kosten erheblich sein. Informationen zur Nutzung des Dienstes und seinen Kosten finden Sie unter Google Cloud Observability-Preise.

Bei der Aktivierung der Premium-Stufe von Security Command Center auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standardstufe in der übergeordneten Organisation aktiviert ist.

Erstellen Sie Messwerte, falls nötig, und erstellen Sie Benachrichtigungsrichtlinien, um dieses Ergebnis zu beheben:

Messwert erstellen

1. Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf.

   Weiter zu logbasierten Messwerten

2. Klicken Sie auf Messwert erstellen.

3. Wählen Sie unter Messwerttyp die Option Zähler aus.

4. Unter Details:

   1. Legen Sie unter Name des Logmesswerts einen Namen fest.
   2. Fügen Sie eine Beschreibung hinzu.
   3. Legen Sie Einheiten auf 1 fest.

5. Kopieren Sie unter Filterauswahl den folgenden Text und fügen Sie ihn in das Feld Filter erstellen ein, wobei Sie eventuell vorhandenen Text ersetzen:

     protoPayload.methodName="SetIamPolicy"
     AND protoPayload.serviceData.policyDelta.auditConfigDeltas:*

6. Klicken Sie auf Messwert erstellen. Sie sehen eine Bestätigung.

Benachrichtigungsrichtlinie erstellen

1. Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf:

   Zu Logbasierte Messwerte

   Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Logging ist.

2. Wählen Sie im Bereich Benutzerdefinierte Messwerte den Messwert aus, den Sie im vorherigen Abschnitt erstellt haben.

3. Klicken Sie auf Mehr und dann auf Benachrichtigung mit dem Messwert erstellen.

   Das Dialogfeld Neue Bedingung wird geöffnet. Die Optionen zur Messwert- und Datentransformation sind bereits ausgefüllt.

4. Klicken Sie auf Next (Weiter).
   1. Prüfen Sie die vorkonfigurierten Einstellungen. Sie können den Schwellenwert ändern.
   2. Klicken Sie auf Bedingungsname und geben Sie einen Namen für die Bedingung ein.
5. Klicken Sie auf Weiter.

6. Klicken Sie auf Benachrichtigungskanäle, um Benachrichtigungen zu Ihrer Benachrichtigungsrichtlinie hinzuzufügen. Wählen Sie im Dialogfeld einen oder mehrere Benachrichtigungskanäle aus dem Menü aus und klicken Sie dann auf OK.

   Wenn Sie benachrichtigt werden möchten, wenn Vorfälle geöffnet und geschlossen werden, klicken Sie auf das Kästchen Bei Schließen von Vorfall benachrichtigen. Standardmäßig werden Benachrichtigungen nur gesendet, wenn Vorfälle geöffnet werden.

7. Optional: Aktualisieren Sie die Dauer bis zur automatischen Schließung von Vorfällen. Dieses Feld bestimmt, wann Monitoring Vorfälle ohne Messwertdaten schließt.
8. Optional: Klicken Sie auf Dokumentation und geben Sie alle Informationen ein, die in einer Benachrichtigung angezeigt werden sollen.
9. Klicken Sie auf Name der Benachrichtigung und geben Sie einen Namen für die Benachrichtigungsrichtlinie ein.
10. Klicken Sie auf Richtlinie erstellen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Audit logging disabled

Kategoriename in der API: AUDIT_LOGGING_DISABLED

Dieser Hinweis ist für Aktivierungen auf Projektebene nicht verfügbar.

Audit-Logs sind für einen oder mehrere Google Cloud-Dienste deaktiviert oder ein oder mehrere Prinzipale sind vom Audit-Logging für den Datenzugriff ausgenommen.

Aktivieren Sie Cloud Logging für alle Dienste, um alle Administratoraktivitäten, Lesezugriff und Schreibzugriff auf Nutzerdaten zu verfolgen. Je nach Menge der Informationen können die Cloud Logging-Kosten erheblich sein. Informationen zur Nutzung des Dienstes und seine Kosten finden Sie unter Google Cloud Observability-Preise.

Wenn Hauptkonten entweder in der Standardkonfiguration für das Audit-Logging für den Datenzugriff oder in den Logging-Konfigurationen für einzelne Dienste vom Audit-Logging für den Datenzugriff ausgenommen sind, entfernen Sie die Ausnahme.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Standardkonfiguration für Audit-Logs zum Datenzugriff auf.

   Zur Standardkonfiguration

2. Aktivieren Sie auf dem Tab Logtypen die Protokollierung der Datenzugriffsaudit in der Standardkonfiguration:

   1. Wählen Sie Lesen durch Administrator, Daten lesen und Daten schreiben aus.
   2. Klicken Sie auf Speichern.

3. Entfernen Sie auf dem Tab Ausgenommene Hauptkonten alle ausgenommenen Nutzer aus der Standardkonfiguration:

   1. Entfernen Sie jedes aufgeführte Hauptkonto, indem Sie neben jedem Namen auf Löschen klicken.
   2. Klicken Sie auf Speichern.

4. Rufen Sie die Seite Audit-Logs auf.

   Zu den Audit-Logs

5. Entfernen Sie alle ausgenommenen Hauptkonten aus den Konfigurationen für Audit-Logs zum Datenzugriff einzelner Dienste.

   1. Klicken Sie unter Konfiguration für Audit-Logs zum Datenzugriff auf jeden Dienst, für den ein ausgenommenes Hauptkonto angezeigt wird. Ein Konfigurationsbereich für das Audit-Log wird für den Dienst geöffnet.
   2. Entfernen Sie auf dem Tab Ausgenommene Hauptkonten alle ausgenommenen Hauptkonten. Klicken Sie dazu neben jedem Namen auf  Löschen.
   3. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Auto backup disabled

Kategoriename in der API: AUTO_BACKUP_DISABLED

In einer Cloud SQL-Datenbank sind keine automatischen Sicherungen aktiviert.

Aktivieren Sie automatische Sicherungen Ihrer SQL-Instanzen, um Datenverlust zu vermeiden. Weitere Informationen finden Sie unter On-Demand- und automatische Sicherungen erstellen und verwalten.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Zur Seite „VM-Instanzen“

2. Klicken Sie auf den Instanznamen.

3. Klicken Sie auf Sicherungen.

4. Klicken Sie neben Einstellungen auf  Bearbeiten.

5. Klicken Sie das Kästchen Automatische tägliche Sicherungen an.

6. Optional: Geben Sie im Feld Anzahl der Tage ein, wie viele Tage lang Sicherungen aufbewahrt werden sollen.

7. Optional: Wählen Sie in der Liste Sicherungsfenster das Zeitfenster aus, in dem Sicherungen erstellt werden sollen.

8. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Auto repair disabled

Kategoriename in der API: AUTO_REPAIR_DISABLED

Die Funktion zur automatischen Reparatur eines Google Kubernetes Engine-Clusters (GKE), die Knoten in einem fehlerfreien, laufenden Zustand beibehält, ist deaktiviert.

Wenn die Funktion aktiviert ist, prüft GKE regelmäßig den Zustand jedes Knotens im Cluster. Wenn ein Knoten über einen längeren Zeitraum mehrere Systemdiagnosen hintereinander nicht besteht, initiiert GKE für diesen Knoten einen Reparaturprozess. Weitere Informationen finden Sie unter Knoten automatisch reparieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.

   Zur Seite "Kubernetes-Cluster"

2. Klicken Sie auf den Tab Knoten.

3. Führen Sie für jeden Knotenpool die folgenden Schritte aus:

   1. Klicken Sie auf den Namen des Knotenpools, um zur Detailseite zu wechseln.
   2. Klicken Sie auf  Bearbeiten.
   3. Wählen Sie unter Verwaltung die Option Automatische Reparatur aktivieren aus.
   4. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Auto upgrade disabled

Kategoriename in der API: AUTO_UPGRADE_DISABLED

Das Feature für automatische Upgrades eines GKE-Clusters, das dafür sorgt, dass Cluster und Knotenpools auf der neuesten stabilen Version von Kubernetes bleiben, ist deaktiviert.

Weitere Informationen finden Sie unter Knoten automatisch aktualisieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.

   Zur Seite "Kubernetes-Cluster"

2. Klicken Sie in der Liste der Cluster auf den Namen des Clusters.

3. Klicken Sie auf den Tab Knoten.

4. Führen Sie für jeden Knotenpool die folgenden Schritte aus:

   1. Klicken Sie auf den Namen des Knotenpools, um zur Detailseite zu wechseln.
   2. Klicken Sie auf  Bearbeiten.
   3. Wählen Sie unter Verwaltung die Option Automatisches Upgrade aktivieren aus.
   4. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

BigQuery table CMEK disabled

Kategoriename in der API: BIGQUERY_TABLE_CMEK_DISABLED

Eine BigQuery-Tabelle ist nicht für die Verwendung eines vom Kunden verwalteten Verschlüsselungsschlüssels (Customer-Managed Encryption Key) konfiguriert.

Mit CMEK werden die von Ihnen in Cloud KMS erstellten und verwalteten Schlüssel mit den Schlüsseln umschlossen, die Google Cloud zum Verschlüsseln Ihrer Daten verwendet. Dadurch haben Sie mehr Kontrolle über den Zugriff auf Ihre Daten. Weitere Informationen finden Sie unter Daten mit Cloud KMS-Schlüsseln schützen.

Achtung: Diese Abhilfemaßnahmen können Ihre Produktionsumgebung beeinträchtigen. Verschieben Sie ggf. Arbeitslasten, Daten oder Berechtigungen in neue Ressourcen, bevor Sie vorhandene Assets löschen.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Erstellen Sie eine durch Cloud Key Management Service geschützte Tabelle.
2. Kopieren Sie die Tabelle in die neue CMEK-fähige Tabelle.
3. Löschen Sie die ursprüngliche Tabelle.

Informationen zum Festlegen eines Standard-CMEK, der alle neuen Tabellen in einem Dataset verschlüsselt, finden Sie unter Dataset-Standardschlüssel festlegen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Binary authorization disabled

Kategoriename in der API: BINARY_AUTHORIZATION_DISABLED

Die Binärautorisierung ist in einem GKE-Cluster deaktiviert.

Die Binärautorisierung enthält ein optionales Feature zum Schutz der Sicherheit der Lieferkette, das nur die Bereitstellung von Container-Images im Cluster zulässt, die während des Entwicklungsprozesses von vertrauenswürdigen Stellen signiert wurden. Durch die Erzwingung einer signaturbasierten Bereitstellung erhalten Sie eine bessere Kontrolle über Ihre Container-Umgebung und können sicherstellen, dass nur verifizierte Images bereitgestellt werden dürfen.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.

   Zur Seite "Kubernetes-Cluster"

2. Klicken Sie im Bereich Sicherheit in der Zeile Binärautorisierung auf  Bearbeiten.

   Wenn die Clusterkonfiguration kürzlich geändert wurde, ist die Schaltfläche "Bearbeiten" möglicherweise deaktiviert. Wenn Sie die Clustereinstellungen nicht bearbeiten können, warten Sie ein paar Minuten und versuchen Sie es dann noch einmal.

3. Wählen Sie im Dialogfeld die Option Binärautorisierung aktivieren aus.

4. Klicken Sie auf Änderungen speichern.

5. Rufen Sie die Seite "Binärautorisierung" einrichten auf.

   Zur Binärautorisierung

6. Achten Sie darauf, dass eine Richtlinie, die Attestierer erfordert, konfiguriert ist und die Standardregel des Projekts nicht so konfiguriert ist, dass Alle Images zulassen angezeigt wird. Weitere Informationen finden Sie unter Für GKE einrichten.

   Damit Images, die gegen die Richtlinie verstoßen, bereitgestellt werden dürfen und Verstöße in Cloud Audit Logs protokolliert werden, können Sie den Probelaufmodus aktivieren.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Bucket CMEK disabled

Kategoriename in der API: BUCKET_CMEK_DISABLED

Ein Bucket ist nicht mit vom Kunden verwalteten Verschlüsselungsschlüsseln (CMEK) verschlüsselt.

Wenn Sie einen Standard-CMEK für einen Bucket festlegen, können Sie den Zugriff auf Ihre Daten besser steuern. Weitere Informationen finden Sie unter Vom Kunden verwaltete Verschlüsselungsschlüssel.

Um dieses Ergebnis zu beheben, verwenden Sie CMEK mit einem Bucket, indem Sie vom Kunden verwaltete Verschlüsselungsschlüssel verwenden folgen. CMEK verursacht zusätzliche Kosten im Zusammenhang mit Cloud KMS.

Hinweis: Durch das Festlegen eines Standardschlüssels werden Objekte, die sich derzeit im Bucket befinden, nicht rückwirkend mit einem neuen Schlüssel neu verschlüsselt.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Bucket IAM not monitored

Kategoriename in der API: BUCKET_IAM_NOT_MONITORED

Logmesswerte und Benachrichtigungen sind nicht für das Monitoring von Änderungen an Cloud Storage-IAM-Berechtigungen konfiguriert.

Durch das Monitoring von Änderungen an den Cloud Storage-Bucket-Berechtigungen können Sie privilegierte Nutzer oder verdächtige Aktivitäten identifizieren. Weitere Informationen finden Sie in der Übersicht zu logbasierten Messwerten.

Abhängig von der Menge der Informationen können die Cloud Monitoring-Kosten erheblich sein. Informationen zur Nutzung des Dienstes und seinen Kosten finden Sie unter Google Cloud Observability-Preise.

Bei der Aktivierung der Premium-Stufe von Security Command Center auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standardstufe in der übergeordneten Organisation aktiviert ist.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

Messwert erstellen

1. Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf.

   Weiter zu logbasierten Messwerten

2. Klicken Sie auf Messwert erstellen.

3. Wählen Sie unter Messwerttyp die Option Zähler aus.

4. Unter Details:

   1. Legen Sie unter Name des Logmesswerts einen Namen fest.
   2. Fügen Sie eine Beschreibung hinzu.
   3. Legen Sie Einheiten auf 1 fest.

5. Kopieren Sie unter Filterauswahl den folgenden Text und fügen Sie ihn in das Feld Filter erstellen ein, wobei Sie eventuell vorhandenen Text ersetzen:

     resource.type=gcs_bucket
     AND protoPayload.methodName="storage.setIamPermissions"

6. Klicken Sie auf Messwert erstellen. Sie sehen eine Bestätigung.

Benachrichtigungsrichtlinie erstellen

1. Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf:

   Zu Logbasierte Messwerte

   Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Logging ist.

2. Wählen Sie im Bereich Benutzerdefinierte Messwerte den Messwert aus, den Sie im vorherigen Abschnitt erstellt haben.

3. Klicken Sie auf Mehr und dann auf Benachrichtigung mit dem Messwert erstellen.

   Das Dialogfeld Neue Bedingung wird geöffnet. Die Optionen zur Messwert- und Datentransformation sind bereits ausgefüllt.

4. Klicken Sie auf Next (Weiter).
   1. Prüfen Sie die vorkonfigurierten Einstellungen. Sie können den Schwellenwert ändern.
   2. Klicken Sie auf Bedingungsname und geben Sie einen Namen für die Bedingung ein.
5. Klicken Sie auf Weiter.

6. Klicken Sie auf Benachrichtigungskanäle, um Benachrichtigungen zu Ihrer Benachrichtigungsrichtlinie hinzuzufügen. Wählen Sie im Dialogfeld einen oder mehrere Benachrichtigungskanäle aus dem Menü aus und klicken Sie dann auf OK.

   Wenn Sie benachrichtigt werden möchten, wenn Vorfälle geöffnet und geschlossen werden, klicken Sie auf das Kästchen Bei Schließen von Vorfall benachrichtigen. Standardmäßig werden Benachrichtigungen nur gesendet, wenn Vorfälle geöffnet werden.

7. Optional: Aktualisieren Sie die Dauer bis zur automatischen Schließung von Vorfällen. Dieses Feld bestimmt, wann Monitoring Vorfälle ohne Messwertdaten schließt.
8. Optional: Klicken Sie auf Dokumentation und geben Sie alle Informationen ein, die in einer Benachrichtigung angezeigt werden sollen.
9. Klicken Sie auf Name der Benachrichtigung und geben Sie einen Namen für die Benachrichtigungsrichtlinie ein.
10. Klicken Sie auf Richtlinie erstellen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Bucket logging disabled

Kategoriename in der API: BUCKET_LOGGING_DISABLED

Es ist ein Storage-Bucket vorhanden, für den kein Logging aktiviert ist.

Damit Sicherheitsprobleme besser untersucht und der Speicherverbrauch besser überwacht werden können, sollten Sie Zugriffslogs und Speicherinformationen für Ihre Cloud Storage-Buckets aktivieren. Zugriffslogs liefern Informationen über alle Anfragen an einen bestimmten Bucket und die Speicherlogs liefern Informationen über den Speicherverbrauch dieses Buckets.

Richten Sie zur Behebung dieses Ergebnisses das Logging für den Bucket ein, der im Security Health Analytics-Ergebnis angegeben ist, indem Sie den Leitfaden Verbraucher- und Speicherlogs befolgen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Bucket policy only disabled

Kategoriename in der API: BUCKET_POLICY_ONLY_DISABLED

Der einheitliche Zugriff auf Bucket-Ebene – bisher als "Nur Bucket-Richtlinie" bezeichnet – ist nicht konfiguriert.

Der einheitliche Zugriff auf Bucket-Ebene vereinfacht die Zugriffssteuerung für Buckets, indem Berechtigungen (ACLs) auf Objektebene deaktiviert werden. Wenn dieser aktiviert ist, gewähren nur Bucket-IAM-Berechtigungen auf Bucket-Ebene Zugriff auf den Bucket und die enthaltenen Objekte. Weitere Informationen finden Sie unter Einheitlicher Zugriff auf Bucket-Ebene.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite des Cloud Storage-Browsers auf.

   Zum Cloud Storage-Browser

2. Klicken Sie in der Bucket-Liste auf den Namen des gewünschten Buckets.

3. Klicken Sie auf den Tab Konfiguration.

4. Klicken Sie unter Berechtigungen in der Zeile für Zugriffssteuerung auf Zugriffssteuerungsmodell bearbeiten.

5. Wählen Sie im Dialogfeld die Option Einheitlich aus.

6. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Cloud Asset API disabled

Kategoriename in der API: CLOUD_ASSET_API_DISABLED

Der Cloud Asset Inventory-Dienst ist für das Projekt nicht aktiviert.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite API-Bibliothek auf.

   Zur API-Bibliothek

2. Suchen Sie nach Cloud Asset Inventory.

3. Wählen Sie das Ergebnis für den Dienst Cloud Asset API aus.

4. Achten Sie darauf, dass API aktiviert angezeigt wird.

Cluster logging disabled

Kategoriename in der API: CLUSTER_LOGGING_DISABLED

Logging ist für einen GKE-Cluster nicht aktiviert.

Aktivieren Sie Cloud Logging in Ihren Clustern, um Sicherheitsprobleme zu untersuchen und die Nutzung zu überwachen.

Je nach Menge der Informationen können die Cloud Logging-Kosten erheblich sein. Informationen zur Nutzung des Dienstes und seine Kosten finden Sie unter Google Cloud Observability-Preise.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.

   Zur Seite „Kubernetes-Cluster“

2. Wählen Sie den Cluster aus, der im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

   Wenn die Clusterkonfiguration kürzlich geändert wurde, ist die Schaltfläche "Bearbeiten" möglicherweise deaktiviert. Wenn Sie die Clustereinstellungen nicht bearbeiten können, warten Sie einige Minuten und versuchen Sie es dann noch einmal.

4. Wählen Sie in der Drop-down-Liste Legacy-Stackdriver Logging oder Stackdriver Kubernetes Engine Monitoring die Option Aktiviert aus.

   Diese Optionen sind nicht miteinander kompatibel. Achten Sie darauf, dass Sie entweder Stackdriver Kubernetes Engine Monitoring allein oder Legacy-Stackdriver Logging mit Legacy-Stackdriver Monitoring verwenden.

5. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Cluster monitoring disabled

Kategoriename in der API: CLUSTER_MONITORING_DISABLED

Monitoring ist auf GKE-Clustern deaktiviert.

Aktivieren Sie Cloud Monitoring in Ihren Clustern, um Sicherheitsprobleme zu untersuchen und die Nutzung zu überwachen.

Abhängig von der Menge der Informationen können die Cloud Monitoring-Kosten erheblich sein. Informationen zur Nutzung des Dienstes und seinen Kosten finden Sie unter Google Cloud Observability-Preise.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.

   Zur Seite „Kubernetes-Cluster“

2. Wählen Sie den Cluster aus, der im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

   Wenn die Clusterkonfiguration kürzlich geändert wurde, ist die Schaltfläche "Bearbeiten" möglicherweise deaktiviert. Wenn Sie die Clustereinstellungen nicht bearbeiten können, warten Sie einige Minuten und versuchen Sie es dann noch einmal.

4. Wählen Sie in der Drop-down-Liste Legacy-Stackdriver Monitoring oder Stackdriver Kubernetes Engine Monitoring die Option Aktiviert aus.

   Diese Optionen sind nicht miteinander kompatibel. Achten Sie darauf, dass Sie entweder Stackdriver Kubernetes Engine Monitoring allein oder Legacy-Stackdriver Monitoring mit Legacy-Stackdriver Logging verwenden.

5. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Cluster private Google access disabled

Kategoriename in der API: CLUSTER_PRIVATE_GOOGLE_ACCESS_DISABLED

Clusterhosts sind nicht so konfiguriert, dass sie nur private, interne IP-Adressen für den Zugriff auf Google APIs verwenden.

Mit dem privaten Google-Zugriff können VM-Instanzen, die nur private, interne IP-Adressen haben, die öffentlichen IP-Adressen von Google APIs und Diensten erreichen. Weitere Informationen finden Sie unter Privaten Google-Zugriff konfigurieren.

Bei der Aktivierung der Premium-Stufe von Security Command Center auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standardstufe in der übergeordneten Organisation aktiviert ist.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Virtual Private Cloud-Netzwerke auf.

   Zur Seite VPC-Netzwerke

2. Klicken Sie in der Liste der Netzwerke auf den Namen des Netzwerks.

3. Klicken Sie auf der Seite VPC-Netzwerkdetails auf den Tab Subnetze.

4. Klicken Sie in der Liste der Subnetze auf den Namen des Subnetzes, das dem Kubernetes-Cluster im Ergebnis zugeordnet ist.

5. Klicken Sie auf der Seite Subnetzdetails auf Bearbeiten.

6. Wählen Sie für Privater Google-Zugriff die Option Ein aus.

7. Klicken Sie auf Speichern.

8. Informationen zum Entfernen öffentlicher (externer) IP-Adressen aus VM-Instanzen, deren nur externer Traffic zu Google APIs gehört, finden Sie unter Zuweisung einer statischen externen IP-Adresse aufheben.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Cluster secrets encryption disabled

Kategoriename in der API: CLUSTER_SECRETS_ENCRYPTION_DISABLED

Die Verschlüsselung von Secrets auf Anwendungsebene ist in einem GKE-Cluster deaktiviert.

Die Verschlüsselung von Secrets auf Anwendungsebene sorgt dafür, dass GKE-Secrets mit Cloud KMS-Schlüsseln verschlüsselt werden. Das Feature bietet eine zusätzliche Sicherheitsebene für vertrauliche Daten wie benutzerdefinierte Secrets und Secrets, die für den Betrieb des Clusters erforderlich sind (z. B. Dienstkontoschlüssel). Diese werden alle in etcd gespeichert.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud KMS-Schlüssel auf.

   Zu Cloud KMS-Schlüsseln

2. Überprüfen Sie Ihre Anwendungsschlüssel oder erstellen Sie einen Datenbankverschlüsselungsschlüssel (Database Encryption Key, DEK). Weitere Informationen finden Sie unter Cloud KMS-Schlüssel erstellen.

3. Rufen Sie die Seite Kubernetes-Cluster auf.

   Zur Seite "Kubernetes-Cluster"

4. Wählen Sie den Cluster im Ergebnis aus.

5. Klicken Sie unter Sicherheit im Feld Verschlüsselung von Secrets auf Anwendungsebene auf Verschlüsselung von Secrets auf Anwendungsebene bearbeiten.

6. Klicken Sie auf das Kästchen Verschlüsselung von Secrets auf Anwendungsebene aktivieren und wählen Sie dann den erstellten DEK aus.

7. Klicken Sie auf Änderungen speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Cluster shielded nodes disabled

Kategoriename in der API: CLUSTER_SHIELDED_NODES_DISABLED

Shielded GKE-Knoten sind für einen Cluster nicht aktiviert.

Ohne Shielded GKE-Knoten können Angreifer eine Sicherheitslücke in einem Pod ausnutzen, um Bootstrap-Anmeldedaten zu stehlen und die Identität von Knoten im Cluster anzunehmen. Durch die Sicherheitslücke erhalten die Angreifer Zugriff auf Cluster-Secrets.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.

   Zur Seite "Kubernetes-Cluster"

2. Wählen Sie den Cluster im Ergebnis aus.

3. Klicken Sie unter Sicherheit im Feld Shielded GKE-Knoten auf Shielded GKE-Knoten bearbeiten.

4. Klicken Sie auf das Kästchen Shielded GKE-Knoten aktivieren.

5. Klicken Sie auf Änderungen speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Compute project wide SSH keys allowed

Kategoriename in der API: COMPUTE_PROJECT_WIDE_SSH_KEYS_ALLOWED

Es werden projektweite SSH-Schlüssel verwendet, sodass eine Anmeldung bei allen Instanzen im Projekt möglich ist.

Die Verwendung von projektweiten SSH-Schlüsseln vereinfacht die Verwaltung von SSH-Schlüsseln. Wenn sie jedoch manipuliert wurde, stellt dies ein Sicherheitsrisiko dar, das alle Instanzen innerhalb eines Projekts beeinträchtigen kann. Sie sollten instanzspezifische SSH-Schlüssel verwenden, die die Angriffsfläche begrenzen, wenn SSH-Schlüssel manipuliert wurden. Weitere Informationen finden Sie unter SSH-Schlüssel in Metadaten verwalten.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.

   Zu Seite „VM-Instanzen“

2. Klicken Sie in der Liste der Instanzen auf den Namen der Instanz im Ergebnis.

3. Klicken Sie auf der Seite VM-Instanzdetails auf Bearbeiten.

   Hinweis: Mit Instanzvorlagen erstellte Instanzen können nicht bearbeitet werden. Informationen zum Ändern der Konfiguration einer Instanzvorlage finden Sie unter Instanzvorlagen aktualisieren.

4. Wählen Sie unter SSH-Schlüssel die Option Projektweite SSH-Schlüssel blockieren aus.

5. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Compute Secure Boot disabled

Kategoriename in der API: COMPUTE_SECURE_BOOT_DISABLED

Für diese Shielded VM ist Secure Boot nicht aktiviert.

Das Verwenden von Secure Boot hilft, Ihre virtuellen Maschinen gegen Rootkit- und Bootkit-Angriffe zu schützen. Compute Engine aktiviert Secure Boot nicht standardmäßig, da einige nicht signierte Treiber und andere auf tieferer Ebene arbeitende Software nicht kompatibel sind. Wenn Ihre VM keine inkompatible Software verwendet und der Bootvorgang mit aktiviertem Secure Boot startet, empfiehlt Google, Secure Boot auch zu verwenden. Wenn Sie Module von Drittanbietern mit Nvidia-Treibern verwenden, achten Sie darauf, dass diese mit Secure Boot kompatibel sind, bevor Sie es aktivieren.

Weitere Informationen finden Sie unter Secure Boot.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.

   Zu Seite „VM-Instanzen“

2. Klicken Sie in der Liste der Instanzen auf den Namen der Instanz im Ergebnis.

3. Klicken Sie auf der Seite VM-Instanzdetails auf Stoppen.

4. Wenn die Instanz nicht mehr ausgeführt wird, klicken Sie auf Bearbeiten.

5. Wählen Sie unter Shielded VM die Option Secure Boot aktivieren aus.

6. Klicken Sie auf Speichern.

7. Klicken Sie nun auf Starten, um die Instanz zu starten.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Compute serial ports enabled

Kategoriename in der API: COMPUTE_SERIAL_PORTS_ENABLED

Serielle Ports sind für eine Instanz aktiviert, sodass Verbindungen zur seriellen Konsole der Instanz möglich sind.

Wenn Sie die interaktive serielle Konsole auf einer Instanz aktivieren, können Clients von jeder IP-Adresse aus versuchen, eine Verbindung zu dieser Instanz herzustellen. Daher sollte die Unterstützung der interaktiven seriellen Konsole deaktiviert sein. Weitere Informationen finden Sie unter Zugriff für ein Projekt aktivieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.

   Zu Seite „VM-Instanzen“

2. Klicken Sie in der Liste der Instanzen auf den Namen der Instanz im Ergebnis.

3. Klicken Sie auf der Seite VM-Instanzdetails auf Bearbeiten.

4. Löschen Sie unter Remotezugriff die Option Verbindung mit seriellen Ports aktivieren.

5. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Confidential Computing disabled

Kategoriename in der API: CONFIDENTIAL_COMPUTING_DISABLED

Auf einer Compute Engine-Instanz ist Confidential Computing nicht aktiviert.

Confidential Computing fügt der Ende-zu-Ende-Verschlüsselung eine dritte Säule hinzu, da Daten während der Verwendung verschlüsselt werden. Mit den vertraulichen Ausführungsumgebungen, die von Confidential Computing und AMD Secure Encrypted Virtualization (SEV) bereitgestellt werden, hält Google Cloud den vertraulichen Code und andere Daten während der Verarbeitung verschlüsselt.

Confidential Computing kann nur aktiviert werden, wenn eine Instanz erstellt wird. Daher müssen Sie die aktuelle Instanz löschen und eine neue erstellen.

Weitere Informationen finden Sie unter Confidential VM und Compute Engine.

Hinweis: Confidential Computing wird nur auf N2D-Maschinentypen unterstützt.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.

   Zu Seite „VM-Instanzen“

2. Klicken Sie in der Liste der Instanzen auf den Namen der Instanz im Ergebnis.

3. Klicken Sie auf der Seite VM-Instanzdetails auf Löschen.

4. Erstellen Sie mit der Google Cloud Console eine Confidential VM.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

COS not used

Kategoriename in der API: COS_NOT_USED

Compute Engine-VMs nutzen nicht das Container-Optimized OS, das für die sichere Ausführung von Docker-Containern in Google Cloud entwickelt wurde.

Container-Optimized OS ist das von Google empfohlene Betriebssystem für das Hosting und Ausführen von Containern auf Google Cloud. Es bietet eine minimale Angriffsfläche und automatische Aktualisierungen sorgen dafür, dass Sicherheitslücken rechtzeitig geschlossen werden. Weitere Informationen finden Sie unter Übersicht über Container-Optimized OS.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.

   Zur Seite "Kubernetes-Cluster"

2. Klicken Sie in der Liste der Cluster auf den Namen des Clusters in dem Ergebnis.

3. Klicken Sie auf den Tab Knoten.

4. Führen Sie für jeden Knotenpool die folgenden Schritte aus:

   1. Klicken Sie auf den Namen des Knotenpools, um zur Detailseite zu wechseln.
   2. Klicken Sie auf  Bearbeiten .
   3. Klicken Sie unter Knoten -> Image-Typ auf Ändern.
   4. Wählen Sie Container-Optimized OS aus und klicken Sie dann auf Ändern.
   5. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Custom role not monitored

Kategoriename in der API: CUSTOM_ROLE_NOT_MONITORED

Logmesswerte und Benachrichtigungen sind nicht für das Monitoring von Änderungen an benutzerdefinierten Rollen konfiguriert.

IAM bietet vordefinierte und benutzerdefinierte Rollen, die Zugriff auf bestimmte Google Cloud-Ressourcen gewähren. Durch das Monitoring der Aktivitäten zum Erstellen, Löschen und Aktualisieren von Rollen können Sie frühzeitig überprivilegierte Rollen identifizieren. Weitere Informationen finden Sie in der Übersicht zu logbasierten Messwerten.

Abhängig von der Menge der Informationen können die Cloud Monitoring-Kosten erheblich sein. Informationen zur Nutzung des Dienstes und seinen Kosten finden Sie unter Google Cloud Observability-Preise.

Bei der Aktivierung der Premium-Stufe von Security Command Center auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standardstufe in der übergeordneten Organisation aktiviert ist.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

Messwert erstellen

1. Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf.

   Weiter zu logbasierten Messwerten

2. Klicken Sie auf Messwert erstellen.

3. Wählen Sie unter Messwerttyp die Option Zähler aus.

4. Unter Details:

   1. Legen Sie unter Name des Logmesswerts einen Namen fest.
   2. Fügen Sie eine Beschreibung hinzu.
   3. Legen Sie Einheiten auf 1 fest.

5. Kopieren Sie unter Filterauswahl den folgenden Text und fügen Sie ihn in das Feld Filter erstellen ein, wobei Sie eventuell vorhandenen Text ersetzen:

     resource.type="iam_role"
     AND (protoPayload.methodName="google.iam.admin.v1.CreateRole"
     OR protoPayload.methodName="google.iam.admin.v1.DeleteRole"
     OR protoPayload.methodName="google.iam.admin.v1.UpdateRole")

6. Klicken Sie auf Messwert erstellen. Sie sehen eine Bestätigung.

Benachrichtigungsrichtlinie erstellen

1. Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf:

   Zu Logbasierte Messwerte

   Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Logging ist.

2. Wählen Sie im Bereich Benutzerdefinierte Messwerte den Messwert aus, den Sie im vorherigen Abschnitt erstellt haben.

3. Klicken Sie auf Mehr und dann auf Benachrichtigung mit dem Messwert erstellen.

   Das Dialogfeld Neue Bedingung wird geöffnet. Die Optionen zur Messwert- und Datentransformation sind bereits ausgefüllt.

4. Klicken Sie auf Next (Weiter).
   1. Prüfen Sie die vorkonfigurierten Einstellungen. Sie können den Schwellenwert ändern.
   2. Klicken Sie auf Bedingungsname und geben Sie einen Namen für die Bedingung ein.
5. Klicken Sie auf Weiter.

6. Klicken Sie auf Benachrichtigungskanäle, um Benachrichtigungen zu Ihrer Benachrichtigungsrichtlinie hinzuzufügen. Wählen Sie im Dialogfeld einen oder mehrere Benachrichtigungskanäle aus dem Menü aus und klicken Sie dann auf OK.

   Wenn Sie benachrichtigt werden möchten, wenn Vorfälle geöffnet und geschlossen werden, klicken Sie auf das Kästchen Bei Schließen von Vorfall benachrichtigen. Standardmäßig werden Benachrichtigungen nur gesendet, wenn Vorfälle geöffnet werden.

7. Optional: Aktualisieren Sie die Dauer bis zur automatischen Schließung von Vorfällen. Dieses Feld bestimmt, wann Monitoring Vorfälle ohne Messwertdaten schließt.
8. Optional: Klicken Sie auf Dokumentation und geben Sie alle Informationen ein, die in einer Benachrichtigung angezeigt werden sollen.
9. Klicken Sie auf Name der Benachrichtigung und geben Sie einen Namen für die Benachrichtigungsrichtlinie ein.
10. Klicken Sie auf Richtlinie erstellen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Dataproc CMEK disabled

Kategoriename in der API: DATAPROC_CMEK_DISABLED

Ein Dataproc-Cluster wurde ohne Verschlüsselungskonfiguration CMEK erstellt. Mit CMEK werden die von Ihnen im Cloud Key Management Service erstellten und verwalteten Schlüssel mit den Schlüsseln umschlossen, die Google Cloud zum Verschlüsseln Ihrer Daten verwendet. Dadurch haben Sie mehr Kontrolle über den Zugriff auf Ihre Daten.

Achtung: Diese Abhilfemaßnahmen können Ihre Produktionsumgebung beeinträchtigen. Verschieben Sie ggf. Arbeitslasten, Daten oder Berechtigungen in neue Ressourcen, bevor Sie vorhandene Assets löschen.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Dataproc-Cluster auf.

   Zu Dataproc-Clustern

2. Wählen Sie Ihr Projekt aus und klicken Sie auf Cluster erstellen.

3. Klicken Sie im Bereich Sicherheitseinstellungen verwalten auf Verschlüsselung und wählen Sie Vom Kunden verwalteter Schlüssel aus.

4. Wählen Sie einen vom Kunden verwalteten Schlüssel aus der Liste aus.

   Wenn Sie keinen vom Kunden verwalteten Schlüssel haben, müssen Sie einen erstellen. Weitere Informationen finden Sie unter Vom Kunden verwaltete Verschlüsselungsschlüssel.

5. Achten Sie darauf, dass dem ausgewählten KMS-Schlüssel die Rolle „Cloud KMS CryptoKey-Verschlüsseler/Entschlüsseler“ für das Dienstkonto des Dataproc-Clusters („serviceAccount:[e-mail]“) zugewiesen ist.

6. Nachdem der Cluster erstellt wurde, migrieren Sie alle Arbeitslasten vom alten Cluster zum neuen Cluster.

7. Rufen Sie „Dataproc-Cluster“ auf und wählen Sie Ihr Projekt aus.

8. Wählen Sie den alten Cluster aus und klicken Sie auf Cluster löschen.

9. Wiederholen Sie alle oben genannten Schritte für andere Dataproc-Cluster, die im ausgewählten Projekt verfügbar sind.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Dataproc image outdated

Kategoriename in der API: DATAPROC_IMAGE_OUTDATED

Ein Dataproc-Cluster wurde mit einer Dataproc-Image-Version erstellt, die von Sicherheitslücken im Apache Log4j 2-Dienstprogramm betroffen ist (CVE-2021-44228 und CVE-2021-45046).

Dieser Detektor findet Sicherheitslücken, indem er prüft, ob das Feld softwareConfig.imageVersion im Attribut config eines Cluster eine der folgenden betroffenen Versionen hat:

• Image-Versionen vor 1.3.95.
• Sub-Minor-Image-Versionen vor 1.4.77, 1.5.53 und 2.0.27.

Die Versionsnummer eines benutzerdefinierten Dataproc-Image kann manuell überschrieben werden. Sehen Sie sich die folgenden Szenarien an:

• Sie können die Version eines betroffenen benutzerdefinierten Images ändern, damit es nicht betroffen erscheint. In diesem Fall gibt dieser Detektor kein Ergebnis aus.
• Es ist möglich, die Version eines nicht betroffenen benutzerdefinierten Images mit einem Image zu überschreiben, das bekanntermaßen die Sicherheitslücke aufweist. In diesem Fall gibt dieser Detektor ein falsch-positives Ergebnis aus. Um diese falsch-positiven Ergebnisse zu unterdrücken, können Sie sie stummschalten.

Achtung: Diese Abhilfemaßnahmen können Ihre Produktionsumgebung beeinträchtigen. Verschieben Sie ggf. Arbeitslasten, Daten oder Berechtigungen in neue Ressourcen, bevor Sie vorhandene Assets löschen.

Erstellen Sie den betroffenen Cluster neu und aktualisieren Sie ihn, um dieses Ergebnis zu korrigieren.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Dataset CMEK disabled

Kategoriename in der API: DATASET_CMEK_DISABLED

Ein BigQuery-Dataset ist nicht für die Verwendung eines vom Kunden verwalteten Standardverschlüsselungsschlüssels (Customer-Managed Encryption Key, CMEK) konfiguriert.

Mit CMEK werden die von Ihnen in Cloud KMS erstellten und verwalteten Schlüssel mit den Schlüsseln umschlossen, die Google Cloud zum Verschlüsseln Ihrer Daten verwendet. Dadurch haben Sie mehr Kontrolle über den Zugriff auf Ihre Daten. Weitere Informationen finden Sie unter Daten mit Cloud KMS-Schlüsseln schützen.

Achtung: Diese Abhilfemaßnahmen können Ihre Produktionsumgebung beeinträchtigen. Verschieben Sie ggf. Arbeitslasten, Daten oder Berechtigungen in neue Ressourcen, bevor Sie vorhandene Assets löschen.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

Sie können eine Tabelle nicht zwischen der Standardverschlüsselung und der CMEK-Verschlüsselung wechseln. Folgen Sie der Anleitung unter Dataset-Standardschlüssel festlegen, um einen Standard-CMEK-Schlüssel für die Verschlüsselung aller neuen Tabellen im Dataset festzulegen.

Durch das Festlegen eines Standardschlüssels werden Tabellen, die sich derzeit im Dataset befinden, nicht rückwirkend mit einem neuen Schlüssel neu verschlüsselt. So verwenden Sie CMEK für vorhandene Daten:

1. Erstellen Sie ein neues Dataset.
2. Legen Sie einen Standard-CMEK-Schlüssel für das von Ihnen erstellte Dataset fest.
3. Wie Sie Tabellen in Ihr CMEK-fähiges Dataset kopieren, erfahren Sie in der Anleitung unter Tabelle kopieren.
4. Löschen Sie die ursprünglichen Datasets nach dem erfolgreichen Kopieren der Daten.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Default network

Kategoriename in der API: DEFAULT_NETWORK

Das Standardnetzwerk ist in einem Projekt vorhanden.

Standardnetzwerke haben automatisch erstellte Firewallregeln und Netzwerkkonfigurationen, die eventuell nicht sicher sind. Weitere Informationen finden Sie unter Standardnetzwerk.

Achtung: Diese Abhilfemaßnahmen können Ihre Produktionsumgebung beeinträchtigen. Verschieben Sie ggf. Arbeitslasten, Daten oder Berechtigungen in neue Ressourcen, bevor Sie vorhandene Assets löschen.

Bei der Aktivierung der Premium-Stufe von Security Command Center auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standardstufe in der übergeordneten Organisation aktiviert ist.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke auf.

   Zur Seite VPC-Netzwerke

2. Klicken Sie in der Liste der Netzwerke auf den Namen des Standardnetzwerks.

3. Klicken Sie auf der Seite VPC-Netzwerkdetails auf VPC-Netzwerk löschen.

4. Informationen zum Erstellen eines neuen Netzwerks mit benutzerdefinierten Firewallregeln finden Sie unter Netzwerke erstellen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Default service account used

Kategoriename in der API: DEFAULT_SERVICE_ACCOUNT_USED

Eine Compute Engine-Instanz ist für die Verwendung des Standarddienstkontos konfiguriert.

Das Compute Engine-Standarddienstkonto hat die Bearbeiterrolle für das Projekt, die Lese- und Schreibzugriff auf die meisten Google Cloud-Dienste gewährt. Verwenden Sie zum Schutz vor Rechteausweitungen und unbefugten Zugriffen nicht das Compute Engine-Standarddienstkonto. Erstellen Sie stattdessen ein neues Dienstkonto und weisen Sie nur die Berechtigungen zu, die von Ihrer Instanz benötigt werden. Weitere Informationen zu IAM-Rollen und -Berechtigungen finden Sie unter Zugriffssteuerung.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.

   Zu Seite „VM-Instanzen“

2. Wählen Sie die Instanz aus, die sich auf das Ergebnis von Security Health Analytics bezieht.

3. Klicken Sie auf der Seite Instanzdetails, die geladen wird, auf Beenden.

4. Wenn die Instanz nicht mehr ausgeführt wird, klicken Sie auf Bearbeiten.

5. Wählen Sie im Abschnitt Dienstkonto ein anderes Dienstkonto als das Compute Engine-Standarddienstkonto aus. Möglicherweise müssen Sie zuerst ein neues Dienstkonto erstellen. Weitere Informationen zu IAM-Rollen und -Berechtigungen finden Sie unter Zugriffssteuerung.

6. Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzdetails angezeigt.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Disk CMEK disabled

Kategoriename in der API: DISK_CMEK_DISABLED

Laufwerke auf dieser VM werden nicht mit vom Kunden verwalteten Verschlüsselungsschlüsseln (CMEK) verschlüsselt.

Mit CMEK werden die von Ihnen in Cloud KMS erstellten und verwalteten Schlüssel mit den Schlüsseln umschlossen, die Google Cloud zum Verschlüsseln Ihrer Daten verwendet. Dadurch haben Sie mehr Kontrolle über den Zugriff auf Ihre Daten. Weitere Informationen finden Sie unter Ressourcen mit Cloud KMS-Schlüsseln schützen.

Achtung: Diese Abhilfemaßnahmen können Ihre Produktionsumgebung beeinträchtigen. Verschieben Sie ggf. Arbeitslasten, Daten oder Berechtigungen in neue Ressourcen, bevor Sie vorhandene Assets löschen.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Compute Engine-Laufwerke auf.

   Zu "Compute Engine-Laufwerke"

2. Klicken Sie in der Liste der Laufwerke auf den Namen des Laufwerks, das im Ergebnis angegeben ist.

3. Klicken Sie auf der Seite Laufwerk verwalten auf Löschen.

4. Informationen zum Erstellen eines neuen Laufwerks mit aktiviertem CMEK finden Sie unter Neuen nichtflüchtigen Speicher mit eigenen Schlüsseln verschlüsseln. CMEK verursacht zusätzliche Kosten im Zusammenhang mit Cloud KMS.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Disk CSEK disabled

Kategoriename in der API: DISK_CSEK_DISABLED

Laufwerke auf dieser VM werden nicht mit vom Kunden bereitgestellten Verschlüsselungsschlüsseln (Customer-Supplied Encryption Keys, CSEK) verschlüsselt. Laufwerke für kritische VMs sollten mit CSEK verschlüsselt werden.

Wenn Sie Ihre eigenen Verschlüsselungsschlüssel bereitstellen, sichert Compute Engine die von Google generierten Schlüssel, die für die Ver- und Entschlüsselung Ihrer Daten verwendet werden, mithilfe Ihres Schlüssels. Weitere Informationen finden Sie unter Vom Kunden bereitgestellte Verschlüsselungsschlüssel. Für CSEK fallen zusätzliche Kosten für Cloud KMS an.

Achtung: Diese Abhilfemaßnahmen können Ihre Produktionsumgebung beeinträchtigen. Verschieben Sie ggf. Arbeitslasten, Daten oder Berechtigungen in neue Ressourcen, bevor Sie vorhandene Assets löschen.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

Laufwerk löschen und erstellen

Sie können nur neue nichtflüchtige Speicher mit einem eigenen Schlüssel verschlüsseln. Vorhandene nichtflüchtige Speicher können nicht mit einem eigenen Schlüssel verschlüsselt werden.

1. Rufen Sie in der Google Cloud Console die Seite Compute Engine-Laufwerke auf.

   Zu "Compute Engine-Laufwerke"

2. Klicken Sie in der Liste der Laufwerke auf den Namen des Laufwerks, das im Ergebnis angegeben ist.

3. Klicken Sie auf der Seite Laufwerk verwalten auf Löschen.

4. Informationen zum Erstellen eines neuen Laufwerks mit aktiviertem CSEK finden Sie unter Laufwerke mit vom Kunden bereitgestellten Verschlüsselungsschlüsseln verschlüsseln.

5. Führen Sie die verbleibenden Schritte aus, um den Detektor zu aktivieren.

Detektor aktivieren

1. Rufen Sie in der Google Cloud Console die Seite Assets von Security Command Center auf.

   Zu Assets

2. Wählen Sie im Bereich Ressourcentyp des Bereichs Schnellfilter die Option compute.Disk aus.

   Wenn Sie compute.Disk nicht sehen, klicken Sie auf Mehr ansehen, geben Sie Disk in das Suchfeld ein und klicken Sie dann auf Übernehmen.

   Im Bereich Ergebnisse werden nur Instanzen des Ressourcentyps compute.Disk angezeigt.

3. Klicken Sie in der Spalte Anzeigename das Kästchen neben dem Namen des Laufwerks an, das Sie mit CSEK verwenden möchten, und klicken Sie dann auf Sicherheitsmarkierungen festlegen.

4. Klicken Sie im Dialogfeld auf Add Mark (Markierung hinzufügen).

5. Geben Sie im Feld Schlüssel den Wert enforce_customer_supplied_disk_encryption_keys und im Feld Wert true ein.

6. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

DNS logging disabled

Kategoriename in der API: DNS_LOGGING_DISABLED

Mit dem Monitoring von Cloud DNS-Logs erhalten Sie Einblick in die DNS-Namen, die von den Clients im VPC-Netzwerk angefordert werden. Diese Logs können auf ungewöhnliche Domainnamen überwacht und anhand von Bedrohungsinformationen analysiert werden. Wir empfehlen, DNS-Logging für VPC-Netzwerke zu aktivieren.

Je nach Menge der Informationen können die Cloud DNS-Logging-Kosten erheblich sein. Informationen zur Nutzung des Dienstes und seine Kosten finden Sie unter Preise für Google Cloud Observability: Cloud Logging.

Bei der Aktivierung der Premium-Stufe von Security Command Center auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standardstufe in der übergeordneten Organisation aktiviert ist.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke auf.

   Zur Seite VPC-Netzwerke

2. Klicken Sie in der Liste der Netzwerke auf den Namen des VPC-Netzwerks.

3. Erstellen Sie eine neue Serverrichtlinie (falls noch nicht vorhanden) oder bearbeiten Sie eine vorhandene Richtlinie:

   • Wenn das Netzwerk keine DNS-Serverrichtlinie hat, führen Sie die folgenden Schritte aus:

     1. Klicken Sie auf  Bearbeiten.
     2. Klicken Sie im Feld DNS-Serverrichtlinie auf Neue Serverrichtlinie erstellen.
     3. Geben Sie einen Namen für die neue Serverrichtlinie ein.
     4. Setzen Sie Logs auf Ein.
     5. Klicken Sie auf Speichern.

   • Wenn das Netzwerk eine DNS-Serverrichtlinie hat, führen Sie die folgenden Schritte aus:

     1. Klicken Sie im Feld DNS-Serverrichtlinie auf den Namen der DNS-Richtlinie.
     2. Klicken Sie auf Richtlinie bearbeiten.
     3. Setzen Sie Logs auf Ein.
     4. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

DNSSEC disabled

Kategoriename in der API: DNSSEC_DISABLED

Domain Name System Security Extensions (DNSSEC) ist für Cloud DNS-Zonen deaktiviert.

DNSSEC validiert DNS-Antworten und mindert Risiken wie DNS-Hacker- und Personal-in-the-Middle-Angriffe, indem DNS-Einträge kryptografisch signiert werden. Aktivieren Sie DNSSEC. Weitere Informationen finden Sie unter Übersicht über DNS-Sicherheitserweiterungen (DNSSEC).

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud DNS auf.

   Zu Cloud DNS-Netzwerken

2. Suchen Sie die Zeile mit der DNS-Zone, die im Ergebnis angegeben ist.

3. Klicken Sie in der Zeile auf die DNSSEC-Einstellung und wählen Sie dann unter DNSSEC die Option Ein aus.

4. Lesen Sie die Informationen im angezeigten Dialogfeld. Wenn Sie zufrieden sind, klicken Sie auf Aktivieren.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Effectively Anonymous Users Granted GKE Cluster Access

Kategoriename in der API: GKE_PRIVILEGE_ESCALATION_DEFAULT_USERS_GROUPS

Jemand hat eine RBAC-Bindung erstellt, die auf einen der folgenden Nutzer oder Gruppen verweist:

• system:anonymous
• system:authenticated
• system:unauthenticated

Diese Nutzer und Gruppen sind praktisch anonym und sollten nicht in RoleBindings oder ClusterRoleBindings verwendet werden. Weitere Informationen finden Sie unter Standardrollen und -gruppen vermeiden.

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

1. Öffnen Sie das Manifest für jede betroffene ClusterRoleBinding oder RoleBinding.
2. Legen Sie für die folgenden eingeschränkten Felder einen der zulässigen Werte fest.

Eingeschränkte Felder

• subjects[*].name

Zulässige Werte

• Alle Gruppen, Nutzer oder Dienstkonten, die nicht system:anonymous, system:authenticated oder system:unauthenticated enthalten.

Egress deny rule not set

Kategoriename in der API: EGRESS_DENY_RULE_NOT_SET

In einer Firewall ist keine Regel zum Ablehnen von ausgehendem Traffic festgelegt.

Eine Firewall, die den gesamten ausgehenden Netzwerk-Traffic ablehnt, verhindert alle unerwünschten ausgehenden Netzwerkverbindungen mit Ausnahme dieser Verbindungen, die von anderen Firewalls explizit autorisiert werden. Weitere Informationen finden Sie unter Ausgehende Fälle.

Bei der Aktivierung der Premium-Stufe von Security Command Center auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standardstufe in der übergeordneten Organisation aktiviert ist.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Firewall auf.

   Zur Firewall

2. Klicken Sie auf Firewallregel erstellen.

3. Geben Sie der Firewall einen Namen und optional eine Beschreibung.

4. Wählen Sie unter Traffic-Richtung die Option Ausgehend aus.

5. Wählen Sie unter Aktion bei Übereinstimmung die Option Ablehnen aus.

6. Wählen Sie im Drop-down-Menü Ziele die Option Alle Instanzen im Netzwerk aus.

7. Wählen Sie im Drop-down-Menü Zielfilter die Option IP-Bereiche aus und geben Sie 0.0.0.0/0 in das Feld Ziel-IP-Bereiche ein.

8. Wählen Sie unter Protokolle und Ports die Option Alle ablehnen aus.

9. Klicken Sie auf Regel deaktivieren und wählen Sie unter Erzwingung die Option Aktiviert aus.

10. Klicken Sie auf Erstellen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Essential contacts not configured

Kategoriename in der API: ESSENTIAL_CONTACTS_NOT_CONFIGURED

Ihre Organisation hat keine Person oder Gruppe benannt, die Benachrichtigungen von Google Cloud zu wichtigen Ereignissen wie Angriffen, Sicherheitslücken und Datenvorfällen in Ihrer Google Cloud-Organisation erhält. Wir empfehlen, eine oder mehrere Personen oder Gruppen in Ihrer Organisation als wichtige Kontaktperson zu benennen.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Wichtige Kontakte auf.

   „Wichtige Kontakte“ aufrufen

2. Achten Sie darauf, dass die Organisation in der Ressourcenauswahl oben auf der Seite angezeigt wird. In der Ressourcenauswahl sehen Sie, für welches Projekt, welchen Ordner oder welche Organisation Sie gerade Kontakte verwalten.

3. Klicken Sie auf + Kontakt hinzufügen. Das Steuerfeld Kontakt hinzufügen wird geöffnet.

4. Geben Sie die E-Mail-Adresse des Kontakts in die Felder E-Mail und E-Mail bestätigen ein.

5. Wählen Sie im Abschnitt Benachrichtigungskategorien die Benachrichtigungskategorien aus, für die der Kontakt Benachrichtigungen erhalten soll. Konfigurieren Sie für jede der folgenden Benachrichtigungskategorien entsprechende E‑Mail-Adressen:

   1. Recht
   2. Sicherheit
   3. Sperrung
   4. Technisch

6. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Firewall not monitored

Kategoriename in der API: FIREWALL_NOT_MONITORED

Hinweis: Der logbasierte Messwertfilter für diesen Detektor wurde am 27. Oktober 2021 geändert.

Logmesswerte und Benachrichtigungen sind nicht für das Monitoring von Änderungen an den VPC-Netzwerk-Firewallregeln konfiguriert.

Durch das Erstellen und Aktualisieren von Firewallregeln können Sie sich einen Überblick über Änderungen am Netzwerkzugriff verschaffen und verdächtige Aktivitäten schnell erkennen. Weitere Informationen finden Sie in der Übersicht zu Log-basierten Messwerten.

Abhängig von der Menge der Informationen können die Cloud Monitoring-Kosten erheblich sein. Informationen zur Nutzung des Dienstes und seinen Kosten finden Sie unter Google Cloud Observability-Preise.

Bei der Aktivierung der Premium-Stufe von Security Command Center auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standardstufe in der übergeordneten Organisation aktiviert ist.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

Messwert erstellen

1. Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf.

   Weiter zu logbasierten Messwerten

2. Klicken Sie auf Messwert erstellen.

3. Wählen Sie unter Messwerttyp die Option Zähler aus.

4. Unter Details:

   1. Legen Sie unter Name des Logmesswerts einen Namen fest.
   2. Fügen Sie eine Beschreibung hinzu.
   3. Legen Sie Einheiten auf 1 fest.

5. Kopieren Sie unter Filterauswahl den folgenden Text und fügen Sie ihn in das Feld Filter erstellen ein, wobei Sie eventuell vorhandenen Text ersetzen:

     resource.type="gce_firewall_rule"
     AND (protoPayload.methodName:"compute.firewalls.insert"
     OR protoPayload.methodName:"compute.firewalls.patch"
     OR protoPayload.methodName:"compute.firewalls.delete")

6. Klicken Sie auf Messwert erstellen. Sie sehen eine Bestätigung.

Benachrichtigungsrichtlinie erstellen

1. Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf:

   Zu Logbasierte Messwerte

   Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Logging ist.

2. Wählen Sie im Bereich Benutzerdefinierte Messwerte den Messwert aus, den Sie im vorherigen Abschnitt erstellt haben.

3. Klicken Sie auf Mehr und dann auf Benachrichtigung mit dem Messwert erstellen.

   Das Dialogfeld Neue Bedingung wird geöffnet. Die Optionen zur Messwert- und Datentransformation sind bereits ausgefüllt.

4. Klicken Sie auf Next (Weiter).
   1. Prüfen Sie die vorkonfigurierten Einstellungen. Sie können den Schwellenwert ändern.
   2. Klicken Sie auf Bedingungsname und geben Sie einen Namen für die Bedingung ein.
5. Klicken Sie auf Weiter.

6. Klicken Sie auf Benachrichtigungskanäle, um Benachrichtigungen zu Ihrer Benachrichtigungsrichtlinie hinzuzufügen. Wählen Sie im Dialogfeld einen oder mehrere Benachrichtigungskanäle aus dem Menü aus und klicken Sie dann auf OK.

   Wenn Sie benachrichtigt werden möchten, wenn Vorfälle geöffnet und geschlossen werden, klicken Sie auf das Kästchen Bei Schließen von Vorfall benachrichtigen. Standardmäßig werden Benachrichtigungen nur gesendet, wenn Vorfälle geöffnet werden.

7. Optional: Aktualisieren Sie die Dauer bis zur automatischen Schließung von Vorfällen. Dieses Feld bestimmt, wann Monitoring Vorfälle ohne Messwertdaten schließt.
8. Optional: Klicken Sie auf Dokumentation und geben Sie alle Informationen ein, die in einer Benachrichtigung angezeigt werden sollen.
9. Klicken Sie auf Name der Benachrichtigung und geben Sie einen Namen für die Benachrichtigungsrichtlinie ein.
10. Klicken Sie auf Richtlinie erstellen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Firewall rule logging disabled

Kategoriename in der API: FIREWALL_RULE_LOGGING_DISABLED

Firewallregel-Logging ist deaktiviert.

Durch das Logging der Firewallregeln können Sie die Auswirkungen Ihrer Firewallregeln im Blick behalten, prüfen und analysieren. Diese Informationen sind mitunter nützlich, um den Netzwerkzugriff zu prüfen oder frühzeitig auf eine unzulässige Netzwerknutzung hinzuweisen. Die Kosten für Logs können beträchtlich sein. Weitere Informationen zum Logging von Firewallregeln und den damit verbundenen Kosten finden Sie unter Logging von Firewallregeln verwenden.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Firewall auf.

   Zur Firewall

2. Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.

3. Klicken Sie auf  Bearbeiten.

4. Wählen Sie unter Logs die Option Ein aus.

5. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Flow logs disabled

Kategoriename in der API: FLOW_LOGS_DISABLED

Es gibt ein VPC-Subnetzwerk, in dem Flusslogs deaktiviert sind.

VPC-Flusslogs erfassen eine Stichprobe von Netzwerkflüssen, die von VM-Instanzen gesendet und empfangen werden. Diese Flussprotokolle können für Netzwerküberwachung, Forensik, Echtzeit-Sicherheitsanalysen und Kostenoptimierung verwendet werden. Weitere Informationen zu Flusslogs und ihren Kosten finden Sie unter VPC-Flusslogs verwenden.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke auf.

   Zur Seite VPC-Netzwerke

2. Klicken Sie in der Liste der Netzwerke auf den Namen des Netzwerks.

3. Klicken Sie auf der Seite VPC-Netzwerkdetails auf den Tab Subnetze.

4. Klicken Sie in der Liste der Subnetze auf den Namen des Subnetzes, das in den Ergebnissen angegeben ist.

5. Klicken Sie auf der Seite Subnetzdetails auf Bearbeiten.

6. Wählen Sie unter Flusslogs die Option An aus.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Flow logs settings not recommended

Kategoriename in der API: VPC_FLOW_LOGS_SETTINGS_NOT_RECOMMENDED

In der Konfiguration eines Subnetzes in einem VPC-Netzwerk ist der Dienst für VPC-Flusslogs entweder deaktiviert oder nicht gemäß den Empfehlungen von CIS Benchmark 1.3 konfiguriert. In VPC-Flusslogs wird eine Stichprobe von Netzwerkflüssen aufgezeichnet, die von VM-Instanzen gesendet und empfangen wurden und mit denen sich Bedrohungen erkennen lassen.

Hinweis: VPC-Flusslogs können Kosten verursachen und die CIS-Benchmark-Empfehlungen sind nicht für Kosteneinsparungen optimiert. Verwenden Sie zur Kostensenkung ein Aggregationsintervall von 15 Minuten und eine Stichprobenrate zwischen 5 und 10 %, um ein ausgewogenes Verhältnis zwischen Kosten und Bedrohungserkennung zu erhalten. Allerdings bleibt bei diesen ausgewogenen Einstellungen das Ergebnis unverändert, da die ausgewogenen Einstellungen nicht den aktuellen CIS-Benchmark-Empfehlungen entsprechen.

Weitere Informationen zu VPC-Flusslogs und ihren Kosten finden Sie unter VPC-Flusslogs verwenden.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke auf.

   Zur Seite VPC-Netzwerke

2. Klicken Sie in der Liste der Netzwerke auf den Namen des Netzwerks.

3. Klicken Sie auf der Seite VPC-Netzwerkdetails auf den Tab Subnetze.

4. Klicken Sie in der Liste der Subnetze auf den Namen des Subnetzes, das in den Ergebnissen angegeben ist.

5. Klicken Sie auf der Seite Subnetzdetails auf Bearbeiten.

6. Wählen Sie unter Flusslogs die Option An aus.

   1. Ändern Sie optional die Konfiguration der Logs. Klicken Sie dazu auf die Schaltfläche Logs konfigurieren, um den Tab zu maximieren. In den CIS-Benchmarks werden die folgenden Einstellungen empfohlen:
      1. Legen Sie das Aggregationsintervall auf 5 SEK. fest.
      2. Wählen Sie unter dem Kästchen Zusatzfelder die Option Metadaten einschließen aus.
      3. Legen Sie die Abtastrate auf 100% fest.
      4. Klicken Sie auf die Schaltfläche SPEICHERN.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Full API access

Kategoriename in der API: FULL_API_ACCESS

Eine Compute Engine-Instanz ist so konfiguriert, dass sie das Standarddienstkonto mit uneingeschränktem Zugriff auf alle Google Cloud APIs verwendet.

Wenn eine Instanz mit dem Standarddienstkonto und dem API-Zugriffsbereich Uneingeschränkten Zugriff auf alle Cloud APIs zulassen konfiguriert ist, können Nutzer möglicherweise Vorgänge oder API-Aufrufe ausführen, für die sie keine IAM-Berechtigungen haben. Weitere Informationen finden Sie unter Standardmäßiges Compute Engine-Dienstkonto.

Wichtig: Mit dem folgenden Verfahren werden die APIs geändert, auf die das Standarddienstkonto Zugriff hat. VM-Prozesse oder Arbeitslasten, die das Standarddienstkonto verwenden, sind möglicherweise betroffen. Mit Policy Intelligence können Sie nachvollziehen, wie das Standarddienstkonto verwendet wird. Weitere Informationen finden Sie unter Tools zur Analyse der Dienstkontonutzung.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.

   Zu Seite „VM-Instanzen“

2. Klicken Sie in der Liste der Instanzen auf den Namen der Instanz im Ergebnis.

3. Wenn die Instanz ausgeführt wird, klicken Sie auf Beenden.

4. Wenn die Instanz angehalten wurde, klicken Sie auf Bearbeiten.

5. Wählen Sie im Bereich Sicherheit und Zugriff unter Dienstkonten die Option Standardmäßiges Compute Engine-Dienstkonto aus.

6. Wählen Sie unter Zugriffsbereiche entweder Standardzugriff zulassen oder Zugriff für jede API festlegen aus. Dadurch werden die APIs eingeschränkt, auf die Prozesse oder Arbeitslasten zugreifen können, die das standardmäßige VM-Dienstkonto verwenden.

7. Wenn Sie Zugriff für jede API festlegen ausgewählt haben, gehen Sie so vor:

   • Deaktivieren Sie Cloud Platform, indem Sie die Option auf None (Kein) setzen.
   • Aktivieren Sie die APIs, auf die das Standarddienstkonto der VM zugreifen muss.

8. Klicken Sie auf Speichern.

9. Klicken Sie auf  Starten, um die Instanz zu starten.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

HTTP load balancer

Kategoriename in der API: HTTP_LOAD_BALANCER

Eine Compute Engine-Instanz verwendet einen Load-Balancer, der so konfiguriert ist, dass er statt eines HTTPS-Zielproxys einen Ziel-HTTP-Proxy verwendet.

Um die Integrität Ihrer Daten zu schützen und zu verhindern, dass Eindringlinge Ihre Kommunikation manipulieren, konfigurieren Sie Ihre HTTP(S)-Load-Balancer so, dass nur HTTPS-Traffic zulässig ist. Weitere Informationen finden Sie unter Übersicht über externes HTTP(S)-Load-Balancing.

Bei der Aktivierung der Premium-Stufe von Security Command Center auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standardstufe in der übergeordneten Organisation aktiviert ist.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Ziel-Proxys auf.

   Zu Ziel-Proxys

2. Klicken Sie in der Liste der Zielproxys auf den Namen des Zielproxys im Ergebnis.

3. Klicken Sie auf den Link im Abschnitt URL-Zuordnung.

4. Klicken Sie auf  Bearbeiten.

5. Klicken Sie auf Frontend-Konfiguration.

6. Löschen Sie alle Frontend-IP- und Portkonfigurationen, die HTTP-Traffic zulassen, und erstellen Sie neue Konfigurationen, die HTTPS-Traffic zulassen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Instance OS login disabled

Kategoriename in der API: INSTANCE_OS_LOGIN_DISABLED

OS Login ist für diese Compute Engine-Instanz deaktiviert.

OS Login aktiviert die zentralisierte Verwaltung von SSH-Schlüsseln mit IAM und deaktiviert die metadatenbasierte SSH-Schlüsselkonfiguration aller Instanzen eines Projekts. Lesen Sie die Informationen zum Einrichten und Konfigurieren von OS Login.

Bei der Aktivierung der Premium-Stufe von Security Command Center auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standardstufe in der übergeordneten Organisation aktiviert ist.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.

   Zu Seite „VM-Instanzen“

2. Klicken Sie in der Liste der Instanzen auf den Namen der Instanz im Ergebnis.

3. Klicken Sie auf der Seite Instanzdetails, die geladen wird, auf Beenden.

4. Wenn die Instanz nicht mehr ausgeführt wird, klicken Sie auf Bearbeiten.

5. Achten Sie im Bereich Benutzerdefinierte Metadaten darauf, dass das Element mit dem Schlüssel enable-oslogin den Wert TRUE hat.

6. Klicken Sie auf Speichern.

7. Klicken Sie auf  Starten, um die Instanz zu starten.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Integrity monitoring disabled

Kategoriename in der API: INTEGRITY_MONITORING_DISABLED

Das Integritätsmonitoring ist in einem GKE-Cluster deaktiviert.

Mit dem Integritätsmonitoring können Sie die Laufzeit-Bootintegrität Ihrer Shielded-Knoten mithilfe von Monitoring überwachen und überprüfen. So können Sie auf Integritätsfehler reagieren und verhindern, dass manipulierte Knoten im Cluster bereitgestellt werden.

Achtung: Diese Abhilfemaßnahmen können Ihre Produktionsumgebung beeinträchtigen. Verschieben Sie ggf. Arbeitslasten, Daten oder Berechtigungen in neue Ressourcen, bevor Sie vorhandene Assets löschen.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

Nachdem ein Knoten bereitgestellt wurde, kann er nicht mehr aktualisiert werden, um das Integritätsmonitoring zu aktivieren. Sie müssen einen neuen Knotenpool mit aktiviertem Integritätsmonitoring erstellen.

1. Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.

   Zur Seite "Kubernetes-Cluster"

2. Klicken Sie auf den Namen des Clusters im Ergebnis.

3. Klicken Sie auf Knotenpool hinzufügen.

4. Prüfen Sie auf dem Tab Sicherheit, ob die Option Integritätsmonitoring aktivieren aktiviert ist.

5. Klicken Sie auf Erstellen.

6. Informationen zum Migrieren Ihrer Arbeitslasten von den vorhandenen nicht konformen Knotenpools zu den neuen Knotenpools finden Sie unter Arbeitslasten zu anderen Maschinentypen migrieren.

7. Löschen Sie den ursprünglichen nicht konformen Knotenpool, nachdem die Arbeitslasten verschoben wurden.

   1. Klicken Sie auf der Seite Kubernetes-Cluster im Menü Knotenpools auf den Namen des Knotenpools, den Sie löschen möchten.
   2. Klicken Sie auf Knotenpool entfernen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Intranode visibility disabled

Kategoriename in der API: INTRANODE_VISIBILITY_DISABLED

Knoteninterne Sichtbarkeit ist für einen GKE-Cluster deaktiviert.

Durch das Aktivieren der knoteninternen Sichtbarkeit wird Ihr knoteninterner Pod-zu-Pod-Traffic für das Netzwerk-Fabric sichtbar. Mit diesem Feature können Sie den knoteninternen Traffic mithilfe von VPC-Fluss-Logging und anderen VPC-Features überwachen oder steuern. Für den Abruf von Logs müssen Sie VPC-Flusslogs im ausgewählten Subnetzwerk aktivieren. Weitere Informationen finden Sie unter VPC-Flusslogs verwenden.

Achtung: Diese Abhilfemaßnahmen können Ihre Produktionsumgebung beeinträchtigen. Verschieben Sie ggf. Arbeitslasten, Daten oder Berechtigungen in neue Ressourcen, bevor Sie vorhandene Assets löschen.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

Nachdem ein Knoten bereitgestellt wurde, kann er nicht mehr aktualisiert werden, um das Integritätsmonitoring zu aktivieren. Sie müssen einen neuen Knotenpool mit aktiviertem Integritätsmonitoring erstellen.

1. Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.

   Zur Seite "Kubernetes-Cluster"

2. Klicken Sie im Bereich Netzwerk in der Zeile Knoteninterne Sichtbarkeit auf Knoteninterne Sichtbarkeit bearbeiten.

   Wenn die Clusterkonfiguration kürzlich geändert wurde, ist die Schaltfläche "Bearbeiten" möglicherweise deaktiviert. Wenn Sie die Clustereinstellungen nicht bearbeiten können, warten Sie ein paar Minuten und versuchen Sie es dann noch einmal.

3. Wählen Sie im Dialogfeld die Option Knoteninterne Sichtbarkeit aktivieren aus.

4. Klicken Sie auf Änderungen speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

IP alias disabled

Kategoriename in der API: IP_ALIAS_DISABLED

Ein GKE-Cluster wurde mit deaktivierten Alias-IP-Bereichen erstellt.

Wenn Sie Alias-IP-Bereiche aktivieren, weisen GKE-Cluster IP-Adressen aus einem bekannten CIDR-Block zu. Der Cluster kann so skaliert werden und besser mit Google Cloud-Produkten und -Entitäten interagieren. Weitere Informationen finden Sie unter Alias-IP-Bereiche – Übersicht.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

Sie können einen vorhandenen Cluster nicht migrieren, um Alias-IP-Adressen zu verwenden. So erstellen Sie einen neuen Cluster mit aktivierten Alias-IP-Adressen:

1. Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.

   Zur Seite "Kubernetes-Cluster"

2. Klicken Sie auf Erstellen.

3. Klicken Sie im Navigationsbereich unter Cluster auf Netzwerk.

4. Wählen Sie unter Erweiterte Netzwerkoptionen die Option VPC-natives Traffic-Routing aktivieren (verwendet Alias-IP-Adresse) aus.

5. Klicken Sie auf Erstellen.

   Hinweis: Ein Cluster kann nicht geändert werden, während er sich selbst neu konfiguriert.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

IP forwarding enabled

Kategoriename in der API: IP_FORWARDING_ENABLED

Die IP-Weiterleitung ist für Compute Engine-Instanzen aktiviert.

Verhindern Sie Datenverlust oder die Offenlegung von Informationen, indem Sie die IP-Weiterleitung von Datenpaketen für Ihre VMs deaktivieren.

Achtung: Diese Abhilfemaßnahmen können Ihre Produktionsumgebung beeinträchtigen. Verschieben Sie ggf. Arbeitslasten, Daten oder Berechtigungen in neue Ressourcen, bevor Sie vorhandene Assets löschen.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.

   Zu Seite „VM-Instanzen“

2. Klicken Sie in der Liste der Instanzen auf das Kästchen neben dem Namen der Instanz für das Ergebnis.

3. Klicken Sie auf Löschen.

4. Wählen Sie Instanz erstellen aus, um eine neue Instanz zu erstellen, die die gelöschte Instanz ersetzt.

5. Wenn Sie die IP-Weiterleitung deaktivieren möchten, klicken Sie auf Verwaltung, Laufwerke, Netzwerke, SSH-Schlüssel und dann auf Netzwerke.

6. Klicken Sie unter Netzwerkschnittstellen auf Bearbeiten.

7. Achten Sie darauf, dass im Drop-down-Menü unter IP-Weiterleitung die Option Aus ausgewählt ist.

8. Geben Sie alle anderen Instanzparameter an und klicken Sie dann auf Erstellen. Weitere Informationen finden Sie unter VM-Instanz erstellen und starten.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

KMS key not rotated

Kategoriename in der API: KMS_KEY_NOT_ROTATED

Für einen Cloud KMS-Verschlüsselungsschlüssel ist keine Rotation konfiguriert.

Das Rotieren Ihrer Verschlüsselungsschlüssel bietet regelmäßig Schutz, wenn ein Schlüssel manipuliert wurde, und begrenzt die Anzahl verschlüsselter Nachrichten, die der Kryptoanalyse für eine bestimmte Schlüsselversion zur Verfügung stehen. Weitere Informationen finden Sie unter Schlüsselrotation.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud KMS-Schlüssel auf.

   Zu Cloud KMS-Schlüsseln

2. Klicken Sie auf den Namen des Schlüsselbunds, der in dem Ergebnis angegeben ist.

3. Klicken Sie auf den Namen des im Ergebnis angegebenen Schlüssels.

4. Klicken Sie auf Rotationszeitraum bearbeiten.

5. Legen Sie den Rotationszeitraum auf maximal 90 Tage fest.

6. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

KMS project has owner

Kategoriename in der API: KMS_PROJECT_HAS_OWNER

Ein Nutzer hat roles/Owner-Berechtigungen für ein Projekt mit kryptografischen Schlüsseln. Weitere Informationen finden Sie unter Berechtigungen und Rollen.

Bei der Aktivierung der Premium-Stufe von Security Command Center auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standardstufe in der übergeordneten Organisation aktiviert ist.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die IAM-Seite auf.

   Zur IAM-Seite

2. Wählen Sie ggf. das Projekt im Ergebnis aus.

3. Führen Sie für jedes Mitglied mit der Rolle Inhaber die folgenden Schritte aus:

   1. Klicken Sie auf  Bearbeiten.
   2. Klicken Sie im Bereich Berechtigungen bearbeiten neben der Rolle Inhaber auf Löschen.
   3. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

KMS public key

Kategoriename in der API: KMS_PUBLIC_KEY

Ein Cloud KMS Cryptokey oder Cloud KMS-Schlüsselbund ist öffentlich und für jeden im Internet zugänglich. Weitere Informationen finden Sie unter IAM mit Cloud KMS verwenden.

So beheben Sie dieses Ergebnis, wenn es mit einem kryptografischen Schlüssel zusammenhängt:

1. Rufen Sie in der Google Cloud Console die Seite Kryptografische Schlüssel auf.

   Kryptografische Schlüssel

2. Wählen Sie unter Name den Schlüsselbund aus, der den kryptografischen Schlüssel mit dem Security Health Analytics-Ergebnis enthält.

3. Klicken Sie auf der Seite Schlüsselbunddetails, die geladen wird, das Kästchen neben dem kryptografischen Schlüssel an.

4. Wenn das Infofeld nicht angezeigt wird, klicken Sie auf Infofeld ansehen.

5. Verwenden Sie das Filterfeld vor Rolle / Hauptkonto, um Hauptkonten nach allUsers und allAuthenticatedUsers zu suchen, und klicken Sie auf Löschen, um den Zugriff für diese Hauptkonten zu entfernen.

So beheben Sie dieses Ergebnis, wenn es mit einem Schlüsselbund zusammenhängt:

1. Rufen Sie in der Google Cloud Console die Seite Kryptografische Schlüssel auf.

   Kryptografische Schlüssel

2. Suchen Sie die Zeile mit dem Schlüsselbund in dem Ergebnis und klicken Sie das Kästchen an.

3. Wenn das Infofeld nicht angezeigt wird, klicken Sie auf Infofeld ansehen.

4. Verwenden Sie das Filterfeld vor Rolle / Hauptkonto, um Hauptkonten nach allUsers und allAuthenticatedUsers zu suchen, und klicken Sie auf Löschen, um den Zugriff für diese Hauptkonten zu entfernen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

KMS role separation

Kategoriename in der API: KMS_ROLE_SEPARATION

Dieser Hinweis ist für Aktivierungen auf Projektebene nicht verfügbar.

Mindestens einem Hauptkonto sind mehrere Cloud KMS-Berechtigungen zugewiesen. Wir empfehlen, keinem Konto gleichzeitig Cloud KMS-Administratorberechtigungen und andere Cloud KMS-Berechtigungen zuzuweisen. Weitere Informationen finden Sie unter Berechtigungen und Rollen.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die IAM-Seite auf.

   Seite „IAM“

2. Gehen Sie für jedes Hauptkonto, das in dem Ergebnis aufgeführt ist, so vor:

   1. Prüfen Sie in der Spalte Übernahme, ob die Rolle von einem Ordner oder einer Organisationsressource übernommen wurde. Wenn die Spalte einen Link zu einer übergeordneten Ressource enthält, klicken Sie darauf, um zur IAM-Seite der übergeordneten Ressource zu gelangen.
   2. Klicken Sie neben einem Hauptkonto auf  Bearbeiten.
   3. Klicken Sie zum Entfernen von Berechtigungen neben Cloud KMS-Administrator auf Löschen. Wenn Sie alle Berechtigungen für das Hauptkonto entfernen möchten, klicken Sie neben allen anderen Berechtigungen auf Löschen.

3. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Legacy authorization enabled

Kategoriename in der API: LEGACY_AUTHORIZATION_ENABLED

Die Legacy-Autorisierung ist für GKE-Cluster aktiviert.

In Kubernetes können Sie über eine rollenbasierte Zugriffssteuerung (RBAC) Rollen mit Regeln definieren, die aus einem Set von Berechtigungen bestehen, und Berechtigungen auf Cluster- und Namespace-Ebene erteilen. Durch diese Funktion wird die Sicherheit verbessert, da Nutzer nur Zugriff auf bestimmte Ressourcen haben. Erwägen Sie, die attributbasierte Zugriffssteuerung (ABAC) zu deaktivieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.

   Zur Seite „Kubernetes-Cluster“

2. Wählen Sie den Cluster aus, der im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

   Wenn die Clusterkonfiguration kürzlich geändert wurde, ist die Schaltfläche "Bearbeiten" möglicherweise deaktiviert. Wenn Sie die Clustereinstellungen nicht bearbeiten können, warten Sie einige Minuten und versuchen Sie es dann noch einmal.

4. Wählen Sie in der Drop-down-Liste Alte Autorisierung die Option Deaktiviert aus.

5. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Legacy metadata enabled

Kategoriename in der API: LEGACY_METADATA_ENABLED

Legacy-Metadaten sind für GKE-Cluster aktiviert.

Der Instanzmetadatenserver von Compute Engine macht die Legacy-Endpunkte /0.1/ und /v1beta1/ verfügbar, die keine Metadatenabfrage-Header erzwingen. Dieses Feature in der /v1/ API erschwert potenziellen Angreifern das Abrufen von Instanzmetadaten. Sofern nicht erforderlich, empfehlen wir, diese Legacy-APIs /0.1/ und /v1beta1/ zu deaktivieren.

Weitere Informationen finden Sie unter Legacy-Metadaten-APIs deaktivieren und von dort wechseln.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

Sie können Legacy-Metadaten-APIs nur deaktivieren, wenn Sie einen neuen Cluster erstellen oder einem vorhandenen Cluster einen neuen Knotenpool hinzufügen. Informationen zum Aktualisieren eines vorhandenen Clusters und zum Deaktivieren von Legacy-Metadaten-APIs finden Sie unter Arbeitslasten zu anderen Maschinentypen migrieren.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Legacy network

Kategoriename in der API: LEGACY_NETWORK

Ein Legacy-Netzwerk ist in einem Projekt vorhanden.

Legacy-Netzwerke werden nicht empfohlen, da viele neue Google Cloud-Sicherheitsfeatures in Legacy-Netzwerken nicht unterstützt werden. Verwenden Sie stattdessen VPC-Netzwerke. Weitere Informationen finden Sie unter Legacy-Netzwerke.

Achtung: Diese Abhilfemaßnahmen können Ihre Produktionsumgebung beeinträchtigen. Verschieben Sie ggf. Arbeitslasten, Daten oder Berechtigungen in neue Ressourcen, bevor Sie vorhandene Assets löschen.

Bei der Aktivierung der Premium-Stufe von Security Command Center auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standardstufe in der übergeordneten Organisation aktiviert ist.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke auf.

   Zur Seite VPC-Netzwerke

2. Klicken Sie auf Netzwerk erstellen, um ein neues Nicht-Legacy-Netzwerk zu erstellen.

3. Kehren Sie zur Seite VPC-Netzwerke zurück.

4. Klicken Sie in der Liste der Netzwerke auf legacy_network.

5. Klicken Sie auf der Seite VPC-Netzwerkdetails auf VPC-Netzwerk löschen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Load balancer logging disabled

Kategoriename in der API: LOAD_BALANCER_LOGGING_DISABLED

Das Logging ist für den Backend-Dienst in einem Load Balancer deaktiviert.

Wenn Sie das Logging für einen Load Balancer aktivieren, können Sie den HTTP(S)-Netzwerktraffic für Ihre Webanwendungen ansehen. Weitere Informationen finden Sie unter Load Balancer.

Achtung: Eine hohe Abtastrate kann zu höheren Speicherkosten für die Protokolldatei führen. Sie müssen eine für Ihr Unternehmen geeignete Balance zwischen der Abtastrate und den potenziellen Speicherkosten finden.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Öffnen Sie in der Google Cloud Console die Seite Cloud Load Balancing.

   Zu Cloud Load Balancing

2. Klicken Sie auf den Namen des Load-Balancers.

3. Klicken Sie auf  Bearbeiten.

4. Klicken Sie auf Backend-Konfiguration.

5. Klicken Sie auf der Seite Back-End-Konfiguration auf Bearbeiten.

6. Wählen Sie im Bereich Logging die Option Logging aktivieren und anschließend die beste Abtastrate für Ihr Projekt aus.

7. Klicken Sie auf Aktualisieren, um das Bearbeiten des Backend-Dienstes abzuschließen.

8. Klicken Sie auf Aktualisieren, um das Bearbeiten des Load Balancers abzuschließen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Locked retention policy not set

Kategoriename in der API: LOCKED_RETENTION_POLICY_NOT_SET

Für ein Log ist keine gesperrte Aufbewahrungsrichtlinie festgelegt.

Eine gesperrte Aufbewahrungsrichtlinie verhindert, dass Logs überschrieben werden und dass der Log-Bucket gelöscht wird. Weitere Informationen finden Sie unter Bucket-Sperre.

Bei der Aktivierung der Premium-Stufe von Security Command Center auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standardstufe in der übergeordneten Organisation aktiviert ist.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Storage-Browser auf.

   Zum Storage-Browser

2. Wählen Sie den Bucket aus, der in den Ergebnissen von Security Health Analytics aufgeführt ist.

3. Klicken Sie auf der Seite Bucket-Details auf den Tab Aufbewahrung.

4. Wenn keine Aufbewahrungsrichtlinie festgelegt ist, klicken Sie auf Aufbewahrungsrichtlinie festlegen.

5. Geben Sie eine Aufbewahrungsdauer ein.

6. Klicken Sie auf Speichern. Die Aufbewahrungsrichtlinie wird auf dem Tab Aufbewahrung angezeigt.

7. Klicken Sie auf Sperren, um sicherzustellen, dass die Aufbewahrungsdauer nicht verkürzt oder entfernt wird.

   Achtung:Das Sperren einer Aufbewahrungsrichtlinie kann nicht rückgängig gemacht werden und kann nur durch Löschen des gesamten Buckets rückgängig gemacht werden. Weitere Informationen finden Sie unter Bucket-Sperre.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Log not exported

Kategoriename in der API: LOG_NOT_EXPORTED

Für eine Ressource ist keine entsprechende Logsenke konfiguriert.

Mit Cloud Logging können Sie die Ursache von Problemen in Ihren Systemen und Anwendungen schneller finden. Allerdings werden die meisten Logs nur 30 Tage lang aufbewahrt. Exportieren Sie Kopien aller Logeinträge, um die Speicherdauer zu verlängern. Weitere Informationen finden Sie unter Logexporte.

Bei der Aktivierung der Premium-Stufe von Security Command Center auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standardstufe in der übergeordneten Organisation aktiviert ist.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Log-Router auf.

   Zum "Log Router"

2. Klicken Sie auf Senke erstellen.

3. Lassen Sie die „Einschließen“- und „Ausschließen“-Filter leer, damit alle Logs exportiert werden.

4. Klicken Sie auf Senke erstellen.

   Hinweis:In dieser Anleitung wird eine Senke auf Projektebene erstellt. Senken können auch auf Ordner- oder Organisationsebene erstellt werden. Weitere Informationen finden Sie unter Logs mit der Google Cloud Console exportieren.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Master authorized networks disabled

Kategoriename in der API: MASTER_AUTHORIZED_NETWORKS_DISABLED

Autorisierte Netzwerke auf Steuerungsebene sind in GKE-Clustern nicht aktiviert.

Autorisierte Netzwerke der Steuerungsebene verbessern die Sicherheit des Containerclusters, indem sie bestimmten IP-Adressen den Zugriff auf die Steuerungsebene des Clusters verwehren. Weitere Informationen finden Sie unter Autorisierte Netzwerke für den Zugriff auf Steuerungsebene hinzufügen.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.

   Zur Seite „Kubernetes-Cluster“

2. Wählen Sie den Cluster aus, der im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

   Wenn die Clusterkonfiguration kürzlich geändert wurde, ist die Schaltfläche "Bearbeiten" möglicherweise deaktiviert. Wenn Sie die Clustereinstellungen nicht bearbeiten können, warten Sie einige Minuten und versuchen Sie es dann noch einmal.

4. Wählen Sie in der Drop-down-Liste Autorisierte Netzwerke der Steuerungsebene die Option Aktiviert aus.

5. Klicken Sie auf Autorisiertes Netzwerk hinzufügen.

6. Geben Sie die gewünschten autorisierten Netzwerke an.

7. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

MFA not enforced

Kategoriename in der API: MFA_NOT_ENFORCED

Dieser Hinweis ist für Aktivierungen auf Projektebene nicht verfügbar.

Die Multi-Faktor-Authentifizierung, genauer die Bestätigung in zwei Schritten (2FA), ist für einige Nutzer in Ihrer Organisation deaktiviert.

Die Multi-Faktor-Authentifizierung kann verwendet werden, um Konten vor einem nicht autorisierten Zugriff zu schützen. Sie stellt das wichtigste Tool für den Schutz der Organisation vor manipulierten Anmeldedaten dar. Weitere Informationen finden Sie unter Ihr Unternehmen mit der Bestätigung in zwei Schritten schützen.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Wechseln Sie in der Google Cloud Console zur Seite Admin-Konsole.

   Zur Admin-Konsole

2. Erzwingen Sie die 2-Faktor-Authentifizierung für alle Organisationseinheiten.

Ergebnisse dieses Typs unterdrücken

Wenn Sie Ergebnisse dieses Typs ausblenden möchten, definieren Sie eine Ausblendungsregel, mit der zukünftige Ergebnisse dieses Typs automatisch ausgeblendet werden. Weitere Informationen finden Sie unter Ergebnisse in Security Command Center ausblenden.

Es wird nicht empfohlen, Ergebnisse zu unterdrücken. Sie können Assets aber auch eigene Sicherheitsmarkierungen hinzufügen, damit Security Health Analytics-Detektoren keine Sicherheitsergebnisse für diese Assets erstellen.

• Damit dieses Ergebnis nicht wieder aktiviert wird, fügen Sie das Sicherheitszeichen allow_mfa_not_enforced mit dem Wert true hinzu.
• Um potenzielle Verstöße für bestimmte Organisationseinheiten zu ignorieren, fügen Sie dem Asset das Sicherheitszeichen excluded_orgunits mit einer durch Kommas getrennten Liste mit Pfaden für Organisationseinheiten im Feld Wert hinzu. Beispiel: excluded_orgunits:/people/vendors/vendorA,/people/contractors/contractorA.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Network not monitored

Kategoriename in der API: NETWORK_NOT_MONITORED

Hinweis: Der logbasierte Messwertfilter für diesen Detektor wurde am 27. Oktober 2021 geändert.

Logmesswerte und Benachrichtigungen sind nicht für das Monitoring von Änderungen am VPC-Netzwerk konfiguriert.

Überwachen Sie Änderungen des VPC-Netzwerks, um falsche oder nicht autorisierte Änderungen an der Netzwerkeinrichtung zu erkennen. Weitere Informationen finden Sie in der Übersicht zu Logbasierten Messwerten.

Abhängig von der Menge der Informationen können die Cloud Monitoring-Kosten erheblich sein. Informationen zur Nutzung des Dienstes und seinen Kosten finden Sie unter Google Cloud Observability-Preise.

Bei der Aktivierung der Premium-Stufe von Security Command Center auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standardstufe in der übergeordneten Organisation aktiviert ist.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

Messwert erstellen

1. Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf.

   Weiter zu logbasierten Messwerten

2. Klicken Sie auf Messwert erstellen.

3. Wählen Sie unter Messwerttyp die Option Zähler aus.

4. Unter Details:

   1. Legen Sie unter Name des Logmesswerts einen Namen fest.
   2. Fügen Sie eine Beschreibung hinzu.
   3. Legen Sie Einheiten auf 1 fest.

5. Kopieren Sie unter Filterauswahl den folgenden Text und fügen Sie ihn in das Feld Filter erstellen ein, wobei Sie eventuell vorhandenen Text ersetzen:

     resource.type="gce_network"
     AND (protoPayload.methodName:"compute.networks.insert"
     OR protoPayload.methodName:"compute.networks.patch"
     OR protoPayload.methodName:"compute.networks.delete"
     OR protoPayload.methodName:"compute.networks.removePeering"
     OR protoPayload.methodName:"compute.networks.addPeering")

6. Klicken Sie auf Messwert erstellen. Sie sehen eine Bestätigung.

Benachrichtigungsrichtlinie erstellen

1. Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf:

   Zu Logbasierte Messwerte

   Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Logging ist.

2. Wählen Sie im Bereich Benutzerdefinierte Messwerte den Messwert aus, den Sie im vorherigen Abschnitt erstellt haben.

3. Klicken Sie auf Mehr und dann auf Benachrichtigung mit dem Messwert erstellen.

   Das Dialogfeld Neue Bedingung wird geöffnet. Die Optionen zur Messwert- und Datentransformation sind bereits ausgefüllt.

4. Klicken Sie auf Next (Weiter).
   1. Prüfen Sie die vorkonfigurierten Einstellungen. Sie können den Schwellenwert ändern.
   2. Klicken Sie auf Bedingungsname und geben Sie einen Namen für die Bedingung ein.
5. Klicken Sie auf Weiter.

6. Klicken Sie auf Benachrichtigungskanäle, um Benachrichtigungen zu Ihrer Benachrichtigungsrichtlinie hinzuzufügen. Wählen Sie im Dialogfeld einen oder mehrere Benachrichtigungskanäle aus dem Menü aus und klicken Sie dann auf OK.

   Wenn Sie benachrichtigt werden möchten, wenn Vorfälle geöffnet und geschlossen werden, klicken Sie auf das Kästchen Bei Schließen von Vorfall benachrichtigen. Standardmäßig werden Benachrichtigungen nur gesendet, wenn Vorfälle geöffnet werden.

7. Optional: Aktualisieren Sie die Dauer bis zur automatischen Schließung von Vorfällen. Dieses Feld bestimmt, wann Monitoring Vorfälle ohne Messwertdaten schließt.
8. Optional: Klicken Sie auf Dokumentation und geben Sie alle Informationen ein, die in einer Benachrichtigung angezeigt werden sollen.
9. Klicken Sie auf Name der Benachrichtigung und geben Sie einen Namen für die Benachrichtigungsrichtlinie ein.
10. Klicken Sie auf Richtlinie erstellen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Network policy disabled

Kategoriename in der API: NETWORK_POLICY_DISABLED

Die Netzwerkrichtlinie ist auf GKE-Clustern deaktiviert.

Standardmäßig ist die Pod-zu-Pod-Kommunikation offen. Offene Kommunikation erlaubt Pods, sich direkt über Knoten zu verbinden, mit oder ohne Übersetzung von Netzwerkadressen. Eine NetworkPolicy-Ressource ist wie eine Firewall auf Pod-Ebene, die Verbindungen zwischen Pods einschränkt, es sei denn, die Ressource NetworkPolicy lässt die Verbindung explizit zu. Lesen Sie die Informationen zum Definieren von Netzwerkrichtlinien.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.

   Zur Seite „Kubernetes-Cluster“

2. Klicken Sie auf den Namen des Clusters, der im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie unter Netzwerk in der Zeile für die Calico-Kubernetes-Netzwerkrichtlinie auf Bearbeiten.

   Wenn die Clusterkonfiguration kürzlich geändert wurde, ist die Schaltfläche "Bearbeiten" möglicherweise deaktiviert. Wenn Sie die Clustereinstellungen nicht bearbeiten können, warten Sie einige Minuten und versuchen Sie es dann noch einmal.

4. Wählen Sie im Dialogfeld die Optionen Calico-Kubernetes-Netzwerkrichtlinie für Steuerungsebene aktivieren und Calico-Kubernetes-Netzwerkrichtlinie für Knoten aktivieren aus.

5. Klicken Sie auf Änderungen speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Nodepool boot CMEK disabled

Kategoriename in der API: NODEPOOL_BOOT_CMEK_DISABLED

Bootlaufwerke in diesem Knotenpool werden nicht mit vom Kunden verwalteten Verschlüsselungsschlüsseln (Customer-Managed Encryption Keys, CMEK) verschlüsselt. Mit CMEK kann der Nutzer die Standardverschlüsselungsschlüssel für Bootlaufwerke in einem Knotenpool konfigurieren.

Achtung: Diese Abhilfemaßnahmen können Ihre Produktionsumgebung beeinträchtigen. Verschieben Sie ggf. Arbeitslasten, Daten oder Berechtigungen in neue Ressourcen, bevor Sie vorhandene Assets löschen.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.

   Zur Seite "Kubernetes-Cluster"

2. Klicken Sie in der Liste der Cluster auf den Namen des Clusters in dem Ergebnis.

3. Klicken Sie auf den Tab Knoten.

4. Klicken Sie bei jedem default-pool-Knotenpool auf Löschen.

5. Wenn Sie zur Bestätigung aufgefordert werden, klicken Sie auf Löschen.

6. Informationen zum Erstellen neuer Knotenpools mit CMEK finden Sie unter Vom Kunden verwaltete Verschlüsselungsschlüssel verwenden. CMEK verursacht zusätzliche Kosten im Zusammenhang mit Cloud KMS.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Nodepool secure boot disabled

Kategoriename in der API: NODEPOOL_SECURE_BOOT_DISABLED

Secure Boot ist für einen GKE-Cluster deaktiviert.

Aktivieren Sie Secure Boot für Shielded GKE-Knoten, um die digitalen Signaturen von Knotenkomponenten beim Knoten zu prüfen. Weitere Informationen finden Sie unter Secure Boot.

Achtung: Diese Abhilfemaßnahmen können Ihre Produktionsumgebung beeinträchtigen. Verschieben Sie ggf. Arbeitslasten, Daten oder Berechtigungen in neue Ressourcen, bevor Sie vorhandene Assets löschen.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

Nachdem ein Knotenpool bereitgestellt wurde, kann er nicht mehr aktualisiert werden, um Secure Boot zu aktivieren. Sie müssen einen neuen Knotenpool mit aktiviertem Secure Boot erstellen.

1. Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.

   Zur Seite "Kubernetes-Cluster"

2. Klicken Sie auf den Namen des Clusters im Ergebnis.

3. Klicken Sie auf Knotenpool hinzufügen.

4. Führen Sie im Menü Knotenpools die folgenden Schritte aus:

   1. Klicken Sie auf den Namen des neuen Knotenpools, um den Tab zu maximieren.
   2. Wählen Sie Sicherheit und dann unter Shielded-Optionen die Option Secure Boot aktivieren aus.
   3. Klicken Sie auf Erstellen.
   4. Informationen zum Migrieren Ihrer Arbeitslasten von den vorhandenen nicht konformen Knotenpools zu den neuen Knotenpools finden Sie unter Arbeitslasten zu anderen Maschinentypen migrieren.
   5. Löschen Sie den ursprünglichen nicht konformen Knotenpool, nachdem die Arbeitslasten verschoben wurden.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Non org IAM member

Kategoriename in der API: NON_ORG_IAM_MEMBER

Ein Nutzer außerhalb Ihrer Organisation oder Ihres Projekts hat IAM-Berechtigungen für ein Projekt oder eine Organisation. Übersicht über IAM-Berechtigungen

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die IAM-Seite auf.

   IAM aufrufen

2. Klicken Sie auf das Kästchen neben Nutzern außerhalb Ihrer Organisation oder Ihres Projekts.

3. Klicken Sie auf Entfernen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Object versioning disabled

Kategoriename in der API: OBJECT_VERSIONING_DISABLED

Die Objektversionsverwaltung ist für einen Storage-Bucket, in dem Senken konfiguriert sind, nicht aktiviert.

Damit Sie auch bereits gelöschte oder überschriebene Objekte abrufen können, bietet Cloud Storage die Möglichkeit der Objektversionsverwaltung. Aktivieren Sie die Objektversionierung, um Ihre Cloud Storage-Daten vor dem Überschreiben oder versehentlichen Löschen zu schützen. Objektversionierung aktivieren

Bei der Aktivierung der Premium-Stufe von Security Command Center auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standardstufe in der übergeordneten Organisation aktiviert ist.

Zur Behebung dieses Problems verwenden Sie das Flag --versioning in einem gcloud storage buckets update-Befehl mit dem entsprechenden Wert:

    gcloud storage buckets update gs://finding.assetDisplayName --versioning

Ersetzen Sie finding.assetDisplayName durch den Namen des entsprechenden Buckets.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Open Cassandra port

Kategoriename in der API: OPEN_CASSANDRA_PORT

Firewallregeln, die zulassen, dass beliebige IP-Adressen eine Verbindung zu Cassandra-Ports herstellen, können Ihre Cassandra-Dienste für Angreifer verfügbar machen. Weitere Informationen finden Sie unter VPC-Firewallregeln - Übericht.

Die Cassandra-Dienstports sind

• TCP - 7000, 7001, 7199, 8888, 9042, 9160, 61620, 61621

Dieses Ergebnis wird für anfällige Firewallregeln generiert, auch wenn Sie sie absichtlich deaktivieren. Aktive Ergebnisse für deaktivierte Firewallregeln informieren Sie über unsichere Konfigurationen, die unerwünschten Traffic zulassen, sofern diese aktiviert sind.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Firewall auf.

   Zur Firewall

2. Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.

3. Klicken Sie auf  Bearbeiten.

4. Löschen Sie unter Quell-IP-Bereiche den Wert 0.0.0.0/0.

5. Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.

6. Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.

7. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Open ciscosecure websm port

Kategoriename in der API: OPEN_CISCOSECURE_WEBSM_PORT

Firewallregeln, die zulassen, dass beliebige IP-Adressen eine Verbindung zu CiscoSecure/WebSM-Ports herstellen, können Ihre CiscoSecure/WebSM-Dienste für Angreifer verfügbar machen. Weitere Informationen finden Sie unter VPC-Firewallregeln - Übersicht.

Die CiscoSecure/WebSM-Dienstports sind:

• TCP - 9090

Dieses Ergebnis wird für anfällige Firewallregeln generiert, auch wenn Sie sie absichtlich deaktivieren. Aktive Ergebnisse für deaktivierte Firewallregeln informieren Sie über unsichere Konfigurationen, die unerwünschten Traffic zulassen, sofern diese aktiviert sind.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Firewall auf.

   Zur Firewall

2. Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.

3. Klicken Sie auf  Bearbeiten.

4. Löschen Sie unter Quell-IP-Bereiche den Wert 0.0.0.0/0.

5. Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.

6. Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.

7. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Open directory services port

Kategoriename in der API: OPEN_DIRECTORY_SERVICES_PORT

Firewallregeln, die zulassen, dass beliebige IP-Adressen eine Verbindung zu Verzeichnisports herstellen, können Ihre Verzeichnisdienste für Angreifer verfügbar machen. Weitere Informationen finden Sie unter VPC-Firewallregeln - Übericht.

Die Verzeichnisdienstports sind:

• TCP - 445
• UDP - 445

Dieses Ergebnis wird für anfällige Firewallregeln generiert, auch wenn Sie sie absichtlich deaktivieren. Aktive Ergebnisse für deaktivierte Firewallregeln informieren Sie über unsichere Konfigurationen, die unerwünschten Traffic zulassen, sofern diese aktiviert sind.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Firewall auf.

   Zur Firewall

2. Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.

3. Klicken Sie auf  Bearbeiten.

4. Löschen Sie unter Quell-IP-Bereiche den Wert 0.0.0.0/0.

5. Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.

6. Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.

7. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Open DNS port

Kategoriename in der API: OPEN_DNS_PORT

Firewallregeln, die zulassen, dass beliebige IP-Adressen eine Verbindung zu DNS-Ports herstellen, können Ihre DNS-Dienste für Angreifer verfügbar machen. Weitere Informationen finden Sie unter VPC-Firewallregeln - Übersicht.

Die DNS-Dienstports sind:

• TCP - 53
• UDP - 53

Dieses Ergebnis wird für anfällige Firewallregeln generiert, auch wenn Sie sie absichtlich deaktivieren. Aktive Ergebnisse für deaktivierte Firewallregeln informieren Sie über unsichere Konfigurationen, die unerwünschten Traffic zulassen, sofern diese aktiviert sind.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Firewall auf.

   Zur Firewall

2. Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.

3. Klicken Sie auf  Bearbeiten.

4. Löschen Sie unter Quell-IP-Bereiche den Wert 0.0.0.0/0.

5. Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.

6. Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.

7. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Open Elasticsearch port

Kategoriename in der API: OPEN_ELASTICSEARCH_PORT

Firewallregeln, die zulassen, dass beliebige IP-Adressen eine Verbindung mit Elasticsearch-Ports herstellen, können Ihre Elasticsearch-Dienste für Angreifer verfügbar machen. Weitere Informationen finden Sie unter VPC-Firewallregeln - Übericht.

Die Ports für den Elasticsearch-Dienst sind:

• TCP - 9200, 9300

Dieses Ergebnis wird für anfällige Firewallregeln generiert, auch wenn Sie sie absichtlich deaktivieren. Aktive Ergebnisse für deaktivierte Firewallregeln informieren Sie über unsichere Konfigurationen, die unerwünschten Traffic zulassen, sofern diese aktiviert sind.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Firewall auf.

   Zur Firewall

2. Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.

3. Klicken Sie auf  Bearbeiten.

4. Löschen Sie unter Quell-IP-Bereiche den Wert 0.0.0.0/0.

5. Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.

6. Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.

7. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Open firewall

Kategoriename in der API: OPEN_FIREWALL

Firewallregeln, die Verbindungen von allen IP-Adressen, z. B. 0.0.0.0/0, oder von allen Ports zulassen, können Ressourcen unnötigerweise Angriffen aus unbeabsichtigten Quellen aussetzen. Diese Regeln sollten entfernt oder ausdrücklich auf die vorgesehenen Quell-IP-Bereiche oder -Ports beschränkt werden. Beispielsweise könnten Sie bei öffentlichen Anwendungen die zulässigen Ports auf diejenigen beschränken, die für die Anwendung erforderlich sind, z. B. 80 und 443. Wenn Ihre Anwendung Verbindungen von allen IP-Adressen oder Ports zulassen muss, sollten Sie das Asset auf eine Zulassungsliste setzen. Weitere Informationen finden Sie unter Firewallregeln aktualisieren.

Dieses Ergebnis wird für anfällige Firewallregeln generiert, auch wenn Sie sie absichtlich deaktivieren. Aktive Ergebnisse für deaktivierte Firewallregeln informieren Sie über unsichere Konfigurationen, die unerwünschten Traffic zulassen, sofern diese aktiviert sind.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Firewallregeln auf.

   Zu Firewallregeln

2. Klicken Sie auf die Firewallregel, die im Security Health Analytics-Ergebnis aufgeführt ist, und klicken Sie dann auf Bearbeiten.

3. Bearbeiten Sie unter Quell-IP-Bereiche die IP-Werte, um den Bereich der zulässigen IP-Adressen einzuschränken.

4. Wählen Sie unter Protokolle und Ports die Option Angegebene Protokolle und Ports und dann die zulässigen Protokolle aus.

5. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Open FTP port

Kategoriename in der API: OPEN_FTP_PORT

Firewallregeln, die zulassen, dass beliebige IP-Adressen eine Verbindung mit FTP-Ports herstellen, können Ihre FTP-Dienste für Angreifer verfügbar machen. Weitere Informationen finden Sie unter VPC-Firewallregeln - Übersicht.

Die FTP-Dienstports sind:

• TCP - 21

Dieses Ergebnis wird für anfällige Firewallregeln generiert, auch wenn Sie sie absichtlich deaktivieren. Aktive Ergebnisse für deaktivierte Firewallregeln informieren Sie über unsichere Konfigurationen, die unerwünschten Traffic zulassen, sofern diese aktiviert sind.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Firewall auf.

   Zur Firewall

2. Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.

3. Klicken Sie auf  Bearbeiten.

4. Löschen Sie unter Quell-IP-Bereiche den Wert 0.0.0.0/0.

5. Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.

6. Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.

7. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Open group IAM member

Kategoriename in der API: OPEN_GROUP_IAM_MEMBER

Ein oder mehrere Hauptkonten, die Zugriff auf eine Organisation, ein Projekt oder einen Ordner haben, sind Google Groups-Konten, die ohne Genehmigung verknüpft werden können.

Google Cloud-Kunden können Google Groups verwenden, um Rollen und Berechtigungen für Mitglieder in ihren Organisationen zu verwalten oder Zugriffsrichtlinien auf Sammlungen von Nutzern anzuwenden. Administratoren können Google Groups Rollen und Berechtigungen zuweisen und Mitglieder dann bestimmten Gruppen hinzufügen, statt Rollen direkt an Mitglieder zu erteilen. Gruppenmitglieder übernehmen alle Rollen und Berechtigungen einer Gruppe, wodurch sie auf bestimmte Ressourcen und Dienste zugreifen können.

Wenn ein offenes Google Groups-Konto als Hauptkonto in einer IAM-Bindung verwendet wird, kann jeder die zugehörige Rolle übernehmen, indem er der Gruppe direkt oder indirekt (über eine Untergruppe) beitritt. Wir empfehlen, die Rollen der offenen Gruppen zu widerrufen oder den Zugriff auf diese Gruppen einzuschränken.

Führen Sie eines der folgenden Verfahren aus, um dieses Ergebnis zu korrigieren.

Gruppe aus IAM-Richtlinie entfernen

Achtung: Diese Abhilfemaßnahmen können Ihre Produktionsumgebung beeinträchtigen. Verschieben Sie ggf. Arbeitslasten, Daten oder Berechtigungen in neue Ressourcen, bevor Sie vorhandene Assets löschen.

1. Rufen Sie in der Google Cloud Console die IAM-Seite auf.

   Zu IAM

2. Wählen Sie bei Bedarf das Projekt, den Ordner oder die Organisation im Ergebnis aus.

3. Widerrufen Sie die Rolle für jede offene Gruppe, die im Ergebnis angegeben ist.

Zugriff auf offene Gruppen einschränken

1. Melden Sie sich in Google Groups an.
2. Aktualisieren Sie die Einstellungen jeder offenen Gruppe und ihrer Untergruppen, um anzugeben, wer der Gruppe beitreten kann und wer sie genehmigen muss.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Open HTTP port

Kategoriename in der API: OPEN_HTTP_PORT

Firewallregeln, die zulassen, dass beliebige IP-Adressen eine Verbindung mit HTTP-Ports herstellen, können Ihre HTTP-Dienste für Angreifer verfügbar machen. Weitere Informationen finden Sie unter VPC-Firewallregeln - Übersicht.

Die HTTP-Dienstports sind:

• TCP - 80

Dieses Ergebnis wird für anfällige Firewallregeln generiert, auch wenn Sie sie absichtlich deaktivieren. Aktive Ergebnisse für deaktivierte Firewallregeln informieren Sie über unsichere Konfigurationen, die unerwünschten Traffic zulassen, sofern diese aktiviert sind.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Firewall auf.

   Zur Firewall

2. Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.

3. Klicken Sie auf  Bearbeiten.

4. Löschen Sie unter Quell-IP-Bereiche den Wert 0.0.0.0/0.

5. Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.

6. Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.

7. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Open LDAP port

Kategoriename in der API: OPEN_LDAP_PORT

Firewallregeln, die zulassen, dass beliebige IP-Adressen eine Verbindung zu LDAP-Ports herstellen, können Ihre LDAP-Dienste für Angreifer verfügbar machen. Weitere Informationen finden Sie unter VPC-Firewallregeln - Übersicht.

Die LDAP-Dienstports sind:

• TCP - 389, 636
• UDP - 389

Dieses Ergebnis wird für anfällige Firewallregeln generiert, auch wenn Sie sie absichtlich deaktivieren. Aktive Ergebnisse für deaktivierte Firewallregeln informieren Sie über unsichere Konfigurationen, die unerwünschten Traffic zulassen, sofern diese aktiviert sind.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Firewall auf.

   Zur Firewall

2. Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.

3. Klicken Sie auf  Bearbeiten.

4. Löschen Sie unter Quell-IP-Bereiche den Wert 0.0.0.0/0.

5. Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.

6. Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.

7. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Open Memcached port

Kategoriename in der API: OPEN_MEMCACHED_PORT

Firewallregeln, die zulassen, dass beliebige IP-Adressen eine Verbindung mit Memcached-Ports herstellen, können Ihre Memcached-Dienste für Angreifer verfügbar machen. Weitere Informationen finden Sie unter VPC-Firewallregeln - Übericht.

Die Memcached-Dienst-Ports sind:

• TCP - 11211, 11214, 11215
• UDP - 11211, 11214, 11215

Dieses Ergebnis wird für anfällige Firewallregeln generiert, auch wenn Sie sie absichtlich deaktivieren. Aktive Ergebnisse für deaktivierte Firewallregeln informieren Sie über unsichere Konfigurationen, die unerwünschten Traffic zulassen, sofern diese aktiviert sind.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Firewall auf.

   Zur Firewall

2. Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.

3. Klicken Sie auf  Bearbeiten.

4. Löschen Sie unter Quell-IP-Bereiche den Wert 0.0.0.0/0.

5. Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.

6. Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.

7. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Open MongoDB port

Kategoriename in der API: OPEN_MONGODB_PORT

Firewallregeln, die zulassen, dass beliebige IP-Adressen eine Verbindung mit MongoDB-Ports herstellen, können Ihre MongoDB-Dienste für Angreifer verfügbar machen. Weitere Informationen finden Sie unter VPC-Firewallregeln - Übericht.

Die MongoDB-Dienstports sind:

• TCP - 27017, 27018, 27019

Dieses Ergebnis wird für anfällige Firewallregeln generiert, auch wenn Sie sie absichtlich deaktivieren. Aktive Ergebnisse für deaktivierte Firewallregeln informieren Sie über unsichere Konfigurationen, die unerwünschten Traffic zulassen, sofern diese aktiviert sind.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Firewall auf.

   Zur Firewall

2. Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.

3. Klicken Sie auf  Bearbeiten.

4. Löschen Sie unter Quell-IP-Bereiche den Wert 0.0.0.0/0.

5. Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.

6. Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.

7. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Open MySQL port

Kategoriename in der API: OPEN_MYSQL_PORT

Firewallregeln, die zulassen, dass beliebige IP-Adressen eine Verbindung zu MySQL-Ports herstellen, können Ihre MySQL-Dienste für Angreifer verfügbar machen. Weitere Informationen finden Sie unter VPC-Firewallregeln - Übersicht.

Die MySQL-Dienstports sind:

• TCP - 3306

Dieses Ergebnis wird für anfällige Firewallregeln generiert, auch wenn Sie sie absichtlich deaktivieren. Aktive Ergebnisse für deaktivierte Firewallregeln informieren Sie über unsichere Konfigurationen, die unerwünschten Traffic zulassen, sofern diese aktiviert sind.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Firewall auf.

   Zur Firewall

2. Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.

3. Klicken Sie auf  Bearbeiten.

4. Löschen Sie unter Quell-IP-Bereiche den Wert 0.0.0.0/0.

5. Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.

6. Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.

7. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Open NetBIOS port

Kategoriename in der API: `OPEN_NETBIOS_PORT

Firewallregeln, die zulassen, dass beliebige IP-Adressen eine Verbindung zu NetBIOS-Ports herstellen, können Ihre NetBIOS-Dienste für Angreifer verfügbar machen. Weitere Informationen finden Sie unter VPC-Firewallregeln - Übericht.

Die NetBIOS-Dienstports sind:

• TCP - 137, 138, 139
• UDP - 137, 138, 139

Dieses Ergebnis wird für anfällige Firewallregeln generiert, auch wenn Sie sie absichtlich deaktivieren. Aktive Ergebnisse für deaktivierte Firewallregeln informieren Sie über unsichere Konfigurationen, die unerwünschten Traffic zulassen, sofern diese aktiviert sind.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Firewall auf.

   Zur Firewall

2. Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.

3. Klicken Sie auf  Bearbeiten.

4. Löschen Sie unter Quell-IP-Bereiche den Wert 0.0.0.0/0.

5. Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.

6. Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.

7. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Open OracleDB port

Kategoriename in der API: OPEN_ORACLEDB_PORT

Firewallregeln, die zulassen, dass beliebige IP-Adressen eine Verbindung zu OracleDB-Ports herstellen, können Ihre OracleDB-Dienste für Angreifer verfügbar machen. Weitere Informationen finden Sie unter VPC-Firewallregeln - Übericht.

Die OracleDB-Dienstports sind:

• TCP - 1521, 2483, 2484
• UDP - 2483, 2484

Dieses Ergebnis wird für anfällige Firewallregeln generiert, auch wenn Sie sie absichtlich deaktivieren. Aktive Ergebnisse für deaktivierte Firewallregeln informieren Sie über unsichere Konfigurationen, die unerwünschten Traffic zulassen, sofern diese aktiviert sind.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Firewall auf.

   Zur Firewall

2. Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.

3. Klicken Sie auf  Bearbeiten.

4. Löschen Sie unter Quell-IP-Bereiche den Wert 0.0.0.0/0.

5. Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.

6. Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.

7. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Open POP3 port

Kategoriename in der API: OPEN_POP3_PORT

Firewallregeln, die zulassen, dass beliebige IP-Adressen eine Verbindung zu POP3-Ports herstellen, können Ihre POP3-Dienste für Angreifer verfügbar machen. Weitere Informationen finden Sie unter VPC-Firewallregeln - Übersicht.

Die POP3-Dienstports sind:

• TCP - 110

Dieses Ergebnis wird für anfällige Firewallregeln generiert, auch wenn Sie sie absichtlich deaktivieren. Aktive Ergebnisse für deaktivierte Firewallregeln informieren Sie über unsichere Konfigurationen, die unerwünschten Traffic zulassen, sofern diese aktiviert sind.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Firewall auf.

   Zur Firewall

2. Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.

3. Klicken Sie auf  Bearbeiten.

4. Löschen Sie unter Quell-IP-Bereiche den Wert 0.0.0.0/0.

5. Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.

6. Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.

7. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Open PostgreSQL port

Kategoriename in der API: OPEN_POSTGRESQL_PORT

Firewallregeln, die zulassen, dass beliebige IP-Adressen eine Verbindung mit PostgreSQL-Ports herstellen, können Ihre PostgreSQL-Dienste für Angreifer verfügbar machen. Weitere Informationen finden Sie unter VPC-Firewallregeln - Übericht.

Die PostgreSQL-Dienstports sind:

• TCP - 5432
• UDP - 5432

Dieses Ergebnis wird für anfällige Firewallregeln generiert, auch wenn Sie sie absichtlich deaktivieren. Aktive Ergebnisse für deaktivierte Firewallregeln informieren Sie über unsichere Konfigurationen, die unerwünschten Traffic zulassen, sofern diese aktiviert sind.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Firewall auf.

   Zur Firewall

2. Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.

3. Klicken Sie auf  Bearbeiten.

4. Löschen Sie unter Quell-IP-Bereiche den Wert 0.0.0.0/0.

5. Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.

6. Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.

7. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Open RDP port

Kategoriename in der API: OPEN_RDP_PORT

Firewallregeln, die zulassen, dass beliebige IP-Adressen eine Verbindung mit RDP-Ports herstellen, können Ihre RDP-Dienste für Angreifer verfügbar machen. Weitere Informationen finden Sie unter VPC-Firewallregeln - Übersicht.

Die RDP-Dienstports sind:

• TCP - 3389
• UDP - 3389

Dieses Ergebnis wird für anfällige Firewallregeln generiert, auch wenn Sie sie absichtlich deaktivieren. Aktive Ergebnisse für deaktivierte Firewallregeln informieren Sie über unsichere Konfigurationen, die unerwünschten Traffic zulassen, sofern diese aktiviert sind.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Firewall auf.

   Zur Firewall

2. Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.

3. Klicken Sie auf  Bearbeiten.

4. Löschen Sie unter Quell-IP-Bereiche den Wert 0.0.0.0/0.

5. Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.

6. Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.

7. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Open Redis port

Kategoriename in der API: OPEN_REDIS_PORT

Firewallregeln, die zulassen, dass beliebige IP-Adressen eine Verbindung zu Redis-Ports herstellen, können Ihre Redis-Dienste für Angreifer verfügbar machen. Weitere Informationen finden Sie unter VPC-Firewallregeln - Übersicht.

Die Redis-Dienstports sind:

• TCP - 6379

Dieses Ergebnis wird für anfällige Firewallregeln generiert, auch wenn Sie sie absichtlich deaktivieren. Aktive Ergebnisse für deaktivierte Firewallregeln informieren Sie über unsichere Konfigurationen, die unerwünschten Traffic zulassen, sofern diese aktiviert sind.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Firewall auf.

   Zur Firewall

2. Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.

3. Klicken Sie auf  Bearbeiten.

4. Löschen Sie unter Quell-IP-Bereiche den Wert 0.0.0.0/0.

5. Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.

6. Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.

7. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Open SMTP port

Kategoriename in der API: OPEN_SMTP_PORT

Firewallregeln, die zulassen, dass beliebige IP-Adressen eine Verbindung mit SMTP-Ports herstellen, können Ihre SMTP-Dienste für Angreifer verfügbar machen. Weitere Informationen finden Sie unter VPC-Firewallregeln - Übersicht.

Die SMTP-Dienstports sind:

• TCP - 25

Dieses Ergebnis wird für anfällige Firewallregeln generiert, auch wenn Sie sie absichtlich deaktivieren. Aktive Ergebnisse für deaktivierte Firewallregeln informieren Sie über unsichere Konfigurationen, die unerwünschten Traffic zulassen, sofern diese aktiviert sind.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Firewall auf.

   Zur Firewall

2. Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.

3. Klicken Sie auf  Bearbeiten.

4. Löschen Sie unter Quell-IP-Bereiche den Wert 0.0.0.0/0.

5. Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.

6. Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.

7. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Open SSH port

Kategoriename in der API: OPEN_SSH_PORT

Firewallregeln, die zulassen, dass beliebige IP-Adressen eine Verbindung zu SSH-Ports herstellen, können Ihre SSH-Dienste für Angreifer verfügbar machen. Weitere Informationen finden Sie unter VPC-Firewallregeln - Übersicht.

Die SSH-Dienstports sind:

• SCTP - 22
• TCP - 22

Dieses Ergebnis wird für anfällige Firewallregeln generiert, auch wenn Sie sie absichtlich deaktivieren. Aktive Ergebnisse für deaktivierte Firewallregeln informieren Sie über unsichere Konfigurationen, die unerwünschten Traffic zulassen, sofern diese aktiviert sind.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Firewall auf.

   Zur Firewall

2. Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.

3. Klicken Sie auf  Bearbeiten.

4. Löschen Sie unter Quell-IP-Bereiche den Wert 0.0.0.0/0.

5. Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.

6. Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.

7. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Open Telnet port

Kategoriename in der API: OPEN_TELNET_PORT

Firewallregeln, die zulassen, dass beliebige IP-Adressen eine Verbindung zu Telnet-Ports herstellen, können Ihre Telnet-Dienste für Angreifer verfügbar machen. Weitere Informationen finden Sie unter VPC-Firewallregeln - Übersicht.

Die Ports des Telnet-Dienstes sind:

• TCP - 23

Dieses Ergebnis wird für anfällige Firewallregeln generiert, auch wenn Sie sie absichtlich deaktivieren. Aktive Ergebnisse für deaktivierte Firewallregeln informieren Sie über unsichere Konfigurationen, die unerwünschten Traffic zulassen, sofern diese aktiviert sind.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Firewall auf.

   Zur Firewall

2. Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.

3. Klicken Sie auf  Bearbeiten.

4. Löschen Sie unter Quell-IP-Bereiche den Wert 0.0.0.0/0.

5. Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.

6. Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.

7. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Org policy Confidential VM policy

Kategoriename in der API: ORG_POLICY_CONFIDENTIAL_VM_POLICY

Eine Compute Engine-Ressource verstößt gegen die Organisationsrichtlinie constraints/compute.restrictNonConfidentialComputing. Weitere Informationen zu dieser Einschränkung der Organisationsrichtlinie finden Sie unter Einschränkungen für Organisationsrichtlinien erzwingen.

In Ihrer Organisation muss für diese VM der Confidential VM-Dienst aktiviert sein. VMs, für die dieser Dienst nicht aktiviert ist, verwenden keine Laufzeitarbeitsspeicher-Verschlüsselung, wodurch sie Angriffen auf den Laufzeitarbeitsspeicher ausgesetzt sind.

Hinweis: Für Confidential VM fallen zusätzlich zu den Compute Engine-Preisen zusätzliche Kosten an. Weitere Informationen finden Sie unter Preise.

Bei der Aktivierung der Premium-Stufe von Security Command Center auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standardstufe in der übergeordneten Organisation aktiviert ist.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.

   Zu Seite „VM-Instanzen“

2. Klicken Sie in der Liste der Instanzen auf den Namen der Instanz im Ergebnis.

3. Wenn der Confidential VM-Dienst für die VM nicht erforderlich ist, verschieben Sie ihn in einen neuen Ordner oder ein neues Projekt.

4. Wenn für die VM Confidential VM erforderlich ist, klicken Sie auf Löschen.

5. Informationen zum Erstellen einer neuen Instanz mit aktivierter Confidential VM finden Sie unter Kurzanleitung: Confidential VM-Instanz erstellen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Org policy location restriction

Kategoriename in der API: ORG_POLICY_LOCATION_RESTRICTION

Mit der Einschränkung gcp.resourceLocations der Organisationsrichtlinie können Sie das Erstellen neuer Ressourcen auf von Ihnen ausgewählte Cloud-Regionen einschränken. For more information, see Restricting resource locations.

Hinweis: Einschränkungen für Ressourcenstandorte werden nicht rückwirkend erzwungen. Wenn sich die Werte für Einschränkungen ändern, werden vorhandene Ressourcen nicht geändert. ORG_POLICY_LOCATION_RESTRICTION-Ergebnisse werden möglicherweise generiert, wenn vorhandene Ressourcenstandorte gegen neue Einschränkungen verstoßen.

Bei der Aktivierung der Premium-Stufe von Security Command Center auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standardstufe in der übergeordneten Organisation aktiviert ist.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

Der ORG_POLICY_LOCATION_RESTRICTION-Detektor deckt viele Ressourcentypen ab und die Vorgehensweise zur Fehlerbehebung unterscheidet sich je nach Ressource. Der allgemeine Ansatz zur Behebung von Standortverstößen umfasst Folgendes:

1. Kopieren, verschieben oder sichern Sie die Ressource oder die Daten außerhalb der Region in eine Ressource, die sich innerhalb der Region befindet. Eine Anleitung zum Verschieben von Ressourcen finden Sie in der Dokumentation zu den einzelnen Diensten.
2. Löschen Sie die ursprüngliche Out-of-Region-Ressource oder ihre Daten.

Dieser Ansatz ist nicht für alle Ressourcentypen möglich. Hinweise finden Sie in den angepassten Empfehlungen des Ergebnisses.

Weitere Überlegungen

Beachten Sie Folgendes, wenn Sie dieses Ergebnis beheben.

Verwaltete Ressourcen

Die Lebenszyklen von Ressourcen werden manchmal von anderen Ressourcen verwaltet und gesteuert. Eine verwaltete Compute Engine-Instanzgruppe erstellt und löscht beispielsweise Compute Engine-Instanzen gemäß der Autoscaling-Richtlinie der Instanzgruppe. Wenn verwaltete und verwaltete Ressourcen der Durchsetzung des Standorts unterliegen, werden beide als Verstoß gegen die Organisationsrichtlinie gekennzeichnet. Die Behebung von Ergebnissen für verwaltete Ressourcen sollte in der Verwaltung der Ressource erfolgen, um die Betriebsstabilität zu gewährleisten.

Verwendete Ressourcen

Bestimmte Ressourcen werden von anderen Ressourcen verwendet. Beispielsweise wird ein Compute Engine-Laufwerk, das an eine laufende Compute Engine-Instanz angehängt ist, von der Instanz als genutzt betrachtet. Wenn die verwendete Ressource gegen die Organisationsrichtlinie für Standorte verstößt, müssen Sie dafür sorgen, dass die Ressource nicht verwendet wird, bevor sie den Standortverstoß beheben.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

OS login disabled

Kategoriename in der API: OS_LOGIN_DISABLED

OS Login ist für diese Compute Engine-Instanz deaktiviert.

OS Login aktiviert die zentralisierte Verwaltung von SSH-Schlüsseln mit IAM und deaktiviert die metadatenbasierte SSH-Schlüsselkonfiguration aller Instanzen eines Projekts. Lesen Sie die Informationen zum Einrichten und Konfigurieren von OS Login.

Bei der Aktivierung der Premium-Stufe von Security Command Center auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standardstufe in der übergeordneten Organisation aktiviert ist.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Metadaten auf.

   Zur Seite "Metadaten"

2. Klicken Sie zuerst auf Bearbeiten und dann auf Element hinzufügen.

3. Fügen Sie ein Element mit dem Schlüssel enable-oslogin und dem Wert TRUE hinzu.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Over privileged account

Kategoriename in der API: OVER_PRIVILEGED_ACCOUNT

Ein GKE-Knoten verwendet den Compute Engine-Standarddienstknoten mit standardmäßig weitreichendem Zugriff. Er hat möglicherweise zu umfassende Berechtigungen für das Ausführen Ihres GKE-Clusters.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

Folgen Sie der Anleitung im Hilfeartikel Google-Dienstkonten mit Mindestberechtigung verwenden.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Over privileged scopes

Kategoriename in der API: OVER_PRIVILEGED_SCOPES

Ein Knotendienstkonto hat übermäßige Zugriffsbereiche.

Zugriffsbereiche sind die herkömmliche Methode, Berechtigungen für Ihre Instanz festzulegen. Um die Wahrscheinlichkeit einer Rechteausweitung bei einem Angriff zu reduzieren, sollten Sie für das Ausführen Ihres GKE-Clusters ein Dienstkonto mit minimalen Berechtigungen erstellen und verwenden.

Um dieses Ergebnis zu beheben, folgen Sie der Anleitung unter Google-Dienstkonten mit Mindestberechtigung verwenden.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Over privileged service account user

Kategoriename in der API: OVER_PRIVILEGED_SERVICE_ACCOUNT_USER

Ein Nutzer hat die Rolle iam.serviceAccountUser oder iam.serviceAccountTokenCreator auf Projekt-, Ordner- oder Organisationsebene und nicht für ein bestimmtes Dienstkonto.

Wenn Sie einem Nutzer diese Rollen für ein Projekt, einen Ordner oder eine Organisation zuweisen, erhält er Zugriff auf alle vorhandenen und zukünftigen Dienstkonten mit Zugriff auf diesen Bereich. Dies kann zu einer unbeabsichtigten Rechteausweitung führen. Weitere Informationen erhalten Sie unter Dienstkontoberechtigungen.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die IAM-Seite auf.

   Zur IAM-Seite

2. Wählen Sie bei Bedarf das Projekt, den Ordner oder die Organisation im Ergebnis aus.

3. Führen Sie für jedes Hauptkonto, das roles/iam.serviceAccountUser oder roles/iam.serviceAccountTokenCreator zugewiesen wird, folgende Schritte aus:

   1. Klicken Sie auf  Bearbeiten.
   2. Klicken Sie im Bereich Berechtigungen bearbeiten neben den Rollen auf Löschen.
   3. Klicken Sie auf Speichern.

4. Folgen Sie dieser Anleitung, um es bestimmten Nutzern zu gestatten, die Identität eines einzelnen Dienstkontos zu übernehmen. Sie müssen die Anleitung für jedes Dienstkonto ausführen, für das Sie ausgewählten Nutzern erlauben möchten, dessen Identität zu übernehmen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Owner not monitored

Kategoriename in der API: OWNER_NOT_MONITORED

Logmesswerte und Benachrichtigungen sind nicht für das Monitoring von Zuweisungen oder Änderungen an der Projektinhaberschaft konfiguriert.

Die Cloud IAM-Inhaberrolle hat die höchste Berechtigung für ein Projekt. Zum Schutz Ihrer Ressourcen richten Sie ein, dass Sie benachrichtigt werden, wenn neue Inhaber hinzugefügt oder entfernt werden. Weitere Informationen finden Sie in der Übersicht zu Log-basierten Messwerten.

Abhängig von der Menge der Informationen können die Cloud Monitoring-Kosten erheblich sein. Informationen zur Nutzung des Dienstes und seinen Kosten finden Sie unter Google Cloud Observability-Preise.

Bei der Aktivierung der Premium-Stufe von Security Command Center auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standardstufe in der übergeordneten Organisation aktiviert ist.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

Messwert erstellen

1. Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf.

   Weiter zu logbasierten Messwerten

2. Klicken Sie auf Messwert erstellen.

3. Wählen Sie unter Messwerttyp die Option Zähler aus.

4. Unter Details:

   1. Legen Sie unter Name des Logmesswerts einen Namen fest.
   2. Fügen Sie eine Beschreibung hinzu.
   3. Legen Sie Einheiten auf 1 fest.

5. Kopieren Sie unter Filterauswahl den folgenden Text und fügen Sie ihn in das Feld Filter erstellen ein, wobei Sie eventuell vorhandenen Text ersetzen:

     (protoPayload.serviceName="cloudresourcemanager.googleapis.com")
     AND (ProjectOwnership OR projectOwnerInvitee)
     OR (protoPayload.serviceData.policyDelta.bindingDeltas.action="REMOVE"
     AND protoPayload.serviceData.policyDelta.bindingDeltas.role="roles/owner")
     OR (protoPayload.serviceData.policyDelta.bindingDeltas.action="ADD"
     AND protoPayload.serviceData.policyDelta.bindingDeltas.role="roles/owner")

6. Klicken Sie auf Messwert erstellen. Sie sehen eine Bestätigung.

Benachrichtigungsrichtlinie erstellen

1. Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf:

   Zu Logbasierte Messwerte

   Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Logging ist.

2. Wählen Sie im Bereich Benutzerdefinierte Messwerte den Messwert aus, den Sie im vorherigen Abschnitt erstellt haben.

3. Klicken Sie auf Mehr und dann auf Benachrichtigung mit dem Messwert erstellen.

   Das Dialogfeld Neue Bedingung wird geöffnet. Die Optionen zur Messwert- und Datentransformation sind bereits ausgefüllt.

4. Klicken Sie auf Next (Weiter).
   1. Prüfen Sie die vorkonfigurierten Einstellungen. Sie können den Schwellenwert ändern.
   2. Klicken Sie auf Bedingungsname und geben Sie einen Namen für die Bedingung ein.
5. Klicken Sie auf Weiter.

6. Klicken Sie auf Benachrichtigungskanäle, um Benachrichtigungen zu Ihrer Benachrichtigungsrichtlinie hinzuzufügen. Wählen Sie im Dialogfeld einen oder mehrere Benachrichtigungskanäle aus dem Menü aus und klicken Sie dann auf OK.

   Wenn Sie benachrichtigt werden möchten, wenn Vorfälle geöffnet und geschlossen werden, klicken Sie auf das Kästchen Bei Schließen von Vorfall benachrichtigen. Standardmäßig werden Benachrichtigungen nur gesendet, wenn Vorfälle geöffnet werden.

7. Optional: Aktualisieren Sie die Dauer bis zur automatischen Schließung von Vorfällen. Dieses Feld bestimmt, wann Monitoring Vorfälle ohne Messwertdaten schließt.
8. Optional: Klicken Sie auf Dokumentation und geben Sie alle Informationen ein, die in einer Benachrichtigung angezeigt werden sollen.
9. Klicken Sie auf Name der Benachrichtigung und geben Sie einen Namen für die Benachrichtigungsrichtlinie ein.
10. Klicken Sie auf Richtlinie erstellen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Pod security policy disabled

Kategoriename in der API: POD_SECURITY_POLICY_DISABLED

PodSecurityPolicy ist auf einem GKE-Cluster deaktiviert.

Eine PodSecurityPolicy ist eine Ressource für die Zugangssteuerung, mit der Anforderungen zur Erstellung und Aktualisierung von Pods in einem Cluster validiert werden. Cluster akzeptieren keine Pods, die die in PodSecurityPolicy definierten Bedingungen nicht erfüllen.

Bei der Aktivierung der Premium-Stufe von Security Command Center auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standardstufe in der übergeordneten Organisation aktiviert ist.

Definieren und autorisieren Sie PodSecurityPolicies und aktivieren Sie den PodSecurityPolicy-Controller, um dieses Ergebnis zu beheben. Eine Anleitung finden Sie unter PodSecurityPolicies verwenden.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Primitive roles used

Kategoriename in der API: PRIMITIVE_ROLES_USED

Ein Nutzer hat eine der folgenden einfachen IAM-Rollen: roles/owner, roles/editor oder roles/viewer. Diese Rollen sind zu weit gefasst und sollten nicht verwendet werden. Stattdessen sollten sie nur pro Projekt zugewiesen werden.

Weitere Informationen finden Sie unter Informationen zu Rollen.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite IAM-Richtlinien auf.

   Zur IAM-Richtlinie

2. Verwenden Sie für jeden Nutzer, dem eine einfache Rolle zugewiesen wurde, detaillierte Rollen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Private cluster disabled

Kategoriename in der API: PRIVATE_CLUSTER_DISABLED

Auf einem GKE-Cluster ist ein privater Cluster deaktiviert.

Bei privaten Clustern können Knoten nur private IP-Adressen haben. Mit diesem Feature wird der ausgehende Internetzugriff für Knoten eingeschränkt. Ohne öffentliche IP-Adresse sind Clusterknoten nicht auffindbar und für das öffentliche Internet nicht sichtbar. Mit einem internen Load-Balancer können Sie jedoch Traffic zu diesen Knoten weiterleiten. Weitere Informationen finden Sie unter Private Cluster.

Sie können einen vorhandenen Cluster nicht privat machen. Erstellen Sie einen neuen privaten Cluster, um dieses Ergebnis zu beheben:

1. Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.

   Zur Seite „Kubernetes-Cluster“

2. Klicken Sie auf Cluster erstellen.

3. Wählen Sie im Navigationsmenü unter Cluster die Option Netzwerk aus.

4. Wählen Sie das Optionsfeld für Privater Cluster aus.

5. Klicken Sie unter Erweiterte Netzwerkoptionen das Kästchen für VPC-natives Traffic-Routing aktivieren (verwendet Alias-IP-Adresse) an.

6. Klicken Sie auf Erstellen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Private Google access disabled

Kategoriename in der API: PRIVATE_GOOGLE_ACCESS_DISABLED

Es gibt private Subnetze ohne Zugriff auf öffentliche Google APIs.

Mit dem privaten Google-Zugriff können VM-Instanzen mit ausschließlich internen (privaten) IP-Adressen die öffentlichen IP-Adressen von Google APIs und Diensten erreichen.

Weitere Informationen finden Sie unter Privaten Google-Zugriff konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke auf.

   Zur Seite VPC-Netzwerke

2. Klicken Sie in der Liste der Netzwerke auf den Namen des Netzwerks.

3. Klicken Sie auf der Seite VPC-Netzwerkdetails auf den Tab Subnetze.

4. Klicken Sie in der Liste der Subnetze auf den Namen des Subnetzes, das dem Kubernetes-Cluster im Ergebnis zugeordnet ist.

5. Klicken Sie auf der Seite Subnetzdetails auf Bearbeiten.

6. Wählen Sie für Privater Google-Zugriff die Option Ein aus.

7. Klicken Sie auf Speichern.

8. Informationen zum Entfernen öffentlicher (externer) IP-Adressen aus VM-Instanzen, deren nur externer Traffic zu Google APIs gehört, finden Sie unter Zuweisung einer statischen externen IP-Adresse aufheben.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Public bucket ACL

Kategoriename in der API: PUBLIC_BUCKET_ACL

Buckets sind öffentlich und jeder im Internet kann darauf zugreifen.

Weitere Informationen finden Sie unter Zugriffssteuerung.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Storage-Browser auf.

   Zum Storage-Browser

2. Wählen Sie den Bucket aus, der in den Ergebnissen von Security Health Analytics aufgeführt ist.

3. Klicken Sie auf der Seite Bucket-Details auf den Tab Berechtigungen.

4. Klicken Sie neben Anzeigen nach auf Rollen.

5. Suchen Sie im Feld Filter nach allUsers und allAuthenticatedUsers.

6. Klicken Sie auf Löschen, um alle IAM-Berechtigungen zu entfernen, die allUsers und allAuthenticatedUsers gewährt wurden.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Public Compute image

Kategoriename in der API: PUBLIC_COMPUTE_IMAGE

Ein Compute Engine-Image ist öffentlich und jeder im Internet kann darauf zugreifen. allUsers steht für alle Nutzer im Internet und allAuthenticatedUsers für alle Nutzer, die sich mit einer Google-Konto; Keiner ist auf Nutzer innerhalb Ihrer Organisation beschränkt.

Compute Engine-Images können vertrauliche Informationen wie Verschlüsselungsschlüssel oder lizenzierte Software enthalten. Solche vertraulichen Informationen sollten nicht öffentlich zugänglich sein. Wenn Sie dieses Compute-Image veröffentlichen möchten, darf es keine vertraulichen Informationen enthalten.

Weitere Informationen finden Sie unter Zugriffssteuerung - Übersicht.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Compute Engine-Images auf.

   Zu Compute Engine-Images

2. Klicken Sie auf das Kästchen neben dem Image public-image und dann auf Infofeld anzeigen.

3. Suchen Sie im Feld Filter nach Mitgliedern für allUsers und allAuthenticatedUsers.

4. Erweitern Sie die Rolle, aus der Sie Nutzer entfernen möchten.

5. Klicken Sie auf Löschen, um einen Nutzer aus dieser Rolle zu entfernen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Public dataset

Kategoriename in der API: PUBLIC_DATASET

Ein BigQuery-Dataset ist öffentlich und für jeden im Internet zugänglich. Das IAM-Mitglied allUsers stellt alle Nutzer im Internet dar, allAuthenticatedUsers dagegen alle Nutzer, die bei einem Google-Dienst angemeldet sind. Beide Mitglieder sind nicht auf Nutzer innerhalb der Organisation beschränkt.

Weitere Informationen finden Sie unter Zugriff auf Datasets steuern.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Explorer von BigQuery auf.

   Zu Seite "BigQuery-Dataset"

2. Klicken Sie in der Liste der Datasets auf den Namen des Datasets, das durch das Ergebnis identifiziert wird. Der Bereich Dataset-Informationen wird geöffnet.

3. Klicken Sie oben im Bereich Dataset-Informationen auf Freigabe.

4. Klicken Sie im Drop-down-Menü auf Berechtigungen.

5. Geben Sie im Bereich Dataset-Berechtigungen allUsers und allAuthenticatedUsers ein und entfernen Sie den Zugriff für diese Hauptkonten.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Public IP address

Kategoriename in der API: PUBLIC_IP_ADDRESS

Eine Compute Engine-Instanz hat eine öffentliche IP-Adresse.

Vermeiden Sie es, VMs öffentliche IP-Adressen zuzuweisen, um die Angriffsfläche Ihrer Organisationen zu verringern. Beendete Instanzen werden möglicherweise dennoch mit einem öffentlichen IP-Ergebnis gekennzeichnet, z. B. wenn die Netzwerkschnittstellen so konfiguriert sind, dass beim Start eine sitzungsspezifische öffentliche IP-Adresse zugewiesen wird. Achten Sie darauf, dass die Netzwerkkonfigurationen für beendete Instanzen den externen Zugriff ausschließen.

Weitere Informationen finden Sie unter Sichere Verbindung zu VM-Instanzen herstellen.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.

   Zu Seite VM-Instanzen

2. Klicken Sie in der Liste der Instanzen auf das Kästchen neben dem Namen der Instanz für das Ergebnis.

3. Klicken Sie auf  Bearbeiten.

4. Klicken Sie für jede Schnittstelle unter Netzwerkschnittstellen auf Bearbeiten und legen Sie die externe IP-Adresse auf Keine fest.

5. Klicken Sie auf Fertig und anschließend auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Public log bucket

Kategoriename in der API: PUBLIC_LOG_BUCKET

Dieser Hinweis ist für Aktivierungen auf Projektebene nicht verfügbar.

Ein Storage-Bucket ist öffentlich und wird als Logsenke verwendet. Das bedeutet, dass jeder im Internet auf die in diesem Bucket gespeicherten Logs zugreifen kann. allUsers steht für alle Nutzer im Internet und allAuthenticatedUsers für alle Nutzer, die bei einem Google-Dienst angemeldet sind. Keiner ist auf Nutzer innerhalb Ihrer Organisation beschränkt.

Weitere Informationen finden Sie unter Zugriffssteuerung.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite des Cloud Storage-Browsers auf.

   Zum Cloud Storage-Browser

2. Klicken Sie in der Liste der Buckets auf den Namen des Buckets, der im Ergebnis angegeben ist.

3. Klicken Sie auf den Tab Berechtigungen.

4. Entfernen Sie allUsers und allAuthenticatedUsers aus der Liste der Hauptkonten.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Public SQL instance

Kategoriename in der API: PUBLIC_SQL_INSTANCE

0.0.0.0/0 wurde als zulässiges Netzwerk für die SQL-Instanz festgelegt. Das bedeutet, dass jeder IPv4-Client die Netzwerkfirewall passieren und Anmeldeversuche bei Ihrer Instanz vornehmen kann. Dies gilt auch für potenziell unerwünschte Clients. Clients benötigen weiterhin gültige Anmeldedaten, um sich erfolgreich bei Ihrer Instanz anmelden zu können.

Weitere Informationen finden Sie unter Mit autorisierten Netzwerken autorisieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

4. Klicken Sie im Navigationsbereich auf Verbindungen.

5. Löschen Sie unter Autorisierte Netzwerke den Eintrag 0.0.0.0/0 und fügen Sie die spezifischen IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.

6. Klicken Sie auf Fertig und anschließend auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Pubsub CMEK disabled

Kategoriename in der API: PUBSUB_CMEK_DISABLED

Ein Pub/Sub-Thema wird nicht mit vom Kunden verwalteten Verschlüsselungsschlüsseln (Customer-Managed Encryption Keys, CMEK) verschlüsselt.

Mit CMEK werden die Schlüssel, die Sie in Cloud KMS erstellen und verwalten, die Schlüssel umschließen, die Google zum Verschlüsseln Ihrer Daten verwendet. Dadurch haben Sie mehr Kontrolle über den Zugriff auf Ihre Daten.

Achtung: Diese Abhilfemaßnahmen können Ihre Produktionsumgebung beeinträchtigen. Verschieben Sie ggf. Arbeitslasten, Daten oder Berechtigungen in neue Ressourcen, bevor Sie vorhandene Assets löschen.

Um dieses Ergebnis zu beheben, löschen Sie das vorhandene Thema und erstellen Sie ein neues:

1. Rufen Sie in der Google Cloud Console die Seite "Pub/Sub-Themen" auf.

   Themen aufrufen

2. Wählen Sie gegebenenfalls das Projekt aus, das das Pub/Sub-Thema enthält.

3. Klicken Sie das Kästchen neben dem aufgeführten Thema an und klicken Sie dann auf Löschen.

4. Informationen zum Erstellen eines neuen Pub/Sub-Themas mit aktiviertem CMEK finden Sie unter Vom Kunden verwaltete Verschlüsselungsschlüssel verwenden. CMEK verursacht zusätzliche Kosten im Zusammenhang mit Cloud KMS.

5. Veröffentlichen Sie Ergebnisse oder andere Daten im CMEK-fähigen Pub/Sub-Thema.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Route not monitored

Kategoriename in der API: ROUTE_NOT_MONITORED

Hinweis: Der logbasierte Messwertfilter für diesen Detektor wurde am 27. Oktober 2021 geändert.

Logmesswerte und Benachrichtigungen sind nicht für das Monitoring von Änderungen an der VPC-Netzwerkroute konfiguriert.

Google Cloud-Routen sind Ziele und Hops, die den Pfad definieren, den der Netzwerktraffic von einer VM-Instanz zu einer Ziel-IP-Adresse abruft. Durch das Monitoring von Änderungen an Routentabellen können Sie dafür sorgen, dass der gesamte VPC-Traffic über einen erwarteten Pfad fließt.

Weitere Informationen finden Sie in der Übersicht zu Log-basierten Messwerten.

Abhängig von der Menge der Informationen können die Cloud Monitoring-Kosten erheblich sein. Informationen zur Nutzung des Dienstes und seinen Kosten finden Sie unter Google Cloud Observability-Preise.

Bei der Aktivierung der Premium-Stufe von Security Command Center auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standardstufe in der übergeordneten Organisation aktiviert ist.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

Messwert erstellen

1. Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf.

   Weiter zu logbasierten Messwerten

2. Klicken Sie auf Messwert erstellen.

3. Wählen Sie unter Messwerttyp die Option Zähler aus.

4. Unter Details:

   1. Legen Sie unter Name des Logmesswerts einen Namen fest.
   2. Fügen Sie eine Beschreibung hinzu.
   3. Legen Sie Einheiten auf 1 fest.

5. Kopieren Sie unter Filterauswahl den folgenden Text und fügen Sie ihn in das Feld Filter erstellen ein, wobei Sie eventuell vorhandenen Text ersetzen:

     resource.type="gce_route"
     AND (protoPayload.methodName:"compute.routes.delete"
     OR protoPayload.methodName:"compute.routes.insert")

6. Klicken Sie auf Messwert erstellen. Sie sehen eine Bestätigung.

Benachrichtigungsrichtlinie erstellen

1. Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf:

   Zu Logbasierte Messwerte

   Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Logging ist.

2. Wählen Sie im Bereich Benutzerdefinierte Messwerte den Messwert aus, den Sie im vorherigen Abschnitt erstellt haben.

3. Klicken Sie auf Mehr und dann auf Benachrichtigung mit dem Messwert erstellen.

   Das Dialogfeld Neue Bedingung wird geöffnet. Die Optionen zur Messwert- und Datentransformation sind bereits ausgefüllt.

4. Klicken Sie auf Next (Weiter).
   1. Prüfen Sie die vorkonfigurierten Einstellungen. Sie können den Schwellenwert ändern.
   2. Klicken Sie auf Bedingungsname und geben Sie einen Namen für die Bedingung ein.
5. Klicken Sie auf Weiter.

6. Klicken Sie auf Benachrichtigungskanäle, um Benachrichtigungen zu Ihrer Benachrichtigungsrichtlinie hinzuzufügen. Wählen Sie im Dialogfeld einen oder mehrere Benachrichtigungskanäle aus dem Menü aus und klicken Sie dann auf OK.

   Wenn Sie benachrichtigt werden möchten, wenn Vorfälle geöffnet und geschlossen werden, klicken Sie auf das Kästchen Bei Schließen von Vorfall benachrichtigen. Standardmäßig werden Benachrichtigungen nur gesendet, wenn Vorfälle geöffnet werden.

7. Optional: Aktualisieren Sie die Dauer bis zur automatischen Schließung von Vorfällen. Dieses Feld bestimmt, wann Monitoring Vorfälle ohne Messwertdaten schließt.
8. Optional: Klicken Sie auf Dokumentation und geben Sie alle Informationen ein, die in einer Benachrichtigung angezeigt werden sollen.
9. Klicken Sie auf Name der Benachrichtigung und geben Sie einen Namen für die Benachrichtigungsrichtlinie ein.
10. Klicken Sie auf Richtlinie erstellen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Redis role used on org

Kategoriename in der API: REDIS_ROLE_USED_ON_ORG

Dieser Hinweis ist für Aktivierungen auf Projektebene nicht verfügbar.

Eine Redis-IAM-Rolle wird auf der Organisations- oder Ordnerebene zugewiesen.

Die folgenden Redis-IAM-Rollen sollten nur pro Projekt und nicht auf Organisations- oder Ordnerebene zugewiesen werden:

• roles/redis.admin
• roles/redis.viewer
• roles/redis.editor

Weitere Informationen finden Sie unter Zugriffssteuerung und Berechtigungen.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite IAM-Richtlinien auf.

   Zur IAM-Richtlinie

2. Entfernen Sie die im Ergebnis angegebenen Redis-IAM-Rollen und fügen Sie sie stattdessen den einzelnen Projekten hinzu.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Release channel disabled

Kategoriename in der API: RELEASE_CHANNEL_DISABLED

Ein GKE-Cluster ist nicht auf einer Release-Version abonniert.

Abonnieren Sie eine Release-Version, um Versions-Upgrades für den GKE-Cluster zu automatisieren. Die Features reduzieren auch die Komplexität der Versionsverwaltung, je nachdem, wie viele Features und welche Stabilität erforderlich sind. Weitere Informationen finden Sie unter Release-Versionen.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.

   Zur Seite "Kubernetes-Cluster"

2. Klicken Sie im Bereich Clustergrundlagen in der Zeile Release-Version auf Clustermaster-Version aktualisieren.

   Wenn die Clusterkonfiguration kürzlich geändert wurde, ist die Schaltfläche "Bearbeiten" möglicherweise deaktiviert. Wenn Sie die Clustereinstellungen nicht bearbeiten können, warten Sie ein paar Minuten und versuchen Sie es dann noch einmal.

3. Wählen Sie im Dialogfeld Release-Version und dann die Release-Version aus, die Sie abonnieren möchten.

   Wenn die Version der Steuerungsebene Ihres Clusters nicht auf eine Release-Version aktualisiert werden kann, wird dieser Kanal möglicherweise als Option deaktiviert.

4. Klicken Sie auf Änderungen speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

RSASHA1 for signing

Kategoriename in der API: RSASHA1_FOR_SIGNING

RSASHA1 wird für die Schlüsselsignierung in Cloud DNS-Zonen verwendet. Der zur Schlüsselsignatur verwendete Algorithmus sollte nicht schwach sein.

Um dieses Ergebnis zu beheben, ersetzen Sie den Algorithmus durch einen empfohlenen. Folgen Sie dazu der Anleitung Erweiterte Signaturoptionen verwenden.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Service account key not rotated

Kategoriename in der API: SERVICE_ACCOUNT_KEY_NOT_ROTATED

Dieser Hinweis ist für Aktivierungen auf Projektebene nicht verfügbar.

Ein vom Nutzer verwalteter Dienstkontoschlüssel wurde seit mehr als 90 Tagen nicht mehr rotiert.

Im Allgemeinen sollten vom Nutzer verwaltete Dienstkontoschlüssel mindestens alle 90 Tage rotiert werden, um zu gewährleisten, dass auf Daten nicht mit einem alten Schlüssel zugegriffen werden kann, der möglicherweise verloren gegangen ist oder manipuliert oder gestohlen wurde. Weitere Informationen finden Sie unter Dienstkontoschlüssel rotieren, um Sicherheitsrisiken durch gehackte Schlüssel zu reduzieren.

Wenn Sie das öffentliche/private Schlüsselpaar selbst generiert, den privaten Schlüssel in einem Hardware-Sicherheitsmodul (HSM) gespeichert und den öffentlichen Schlüssel in Google hochgeladen haben, müssen Sie den Schlüssel möglicherweise nicht alle 90 Tage rotieren. Sie können den Schlüssel jedoch rotieren, wenn Sie der Meinung sind, dass er möglicherweise manipuliert wurde.

Achtung: Diese Abhilfemaßnahmen können Ihre Produktionsumgebung beeinträchtigen. Verschieben Sie ggf. Arbeitslasten, Daten oder Berechtigungen in neue Ressourcen, bevor Sie vorhandene Assets löschen.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Dienstkonten auf.

   Zur Seite „Dienstkonten“

2. Wählen Sie bei Bedarf das im Ergebnis angegebene Projekt aus.

3. Suchen Sie in der Liste der Dienstkonten nach dem Dienstkonto, das in den Ergebnissen aufgeführt ist, und klicken Sie auf Löschen. Überlegen Sie vor dem Fortfahren, wie sich das Löschen eines Dienstkontos auf Ihre Produktionsressourcen auswirken könnte.

4. Erstellen Sie einen neuen Dienstkontoschlüssel, um den gelöschten Schlüssel zu ersetzen. Weitere Informationen finden Sie unter Dienstkontoschlüssel erstellen und verwalten.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Service account role separation

Kategoriename in der API: SERVICE_ACCOUNT_ROLE_SEPARATION

Dieser Hinweis ist für Aktivierungen auf Projektebene nicht verfügbar.

Mindestens einem Hauptkonto Ihrer Organisation wurden mehrere Dienstkontoberechtigungen zugewiesen. Ein Konto sollte nicht gleichzeitig Dienstkontoadministrator und andere Dienstkontoberechtigungen haben. Weitere Informationen zu Dienstkonten und den dafür verfügbaren Rollen finden Sie unter Dienstkonten.

Achtung: Diese Abhilfemaßnahmen können Ihre Produktionsumgebung beeinträchtigen. Verschieben Sie ggf. Arbeitslasten, Daten oder Berechtigungen in neue Ressourcen, bevor Sie vorhandene Assets löschen.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite IAM auf.

   Seite „IAM“

2. Gehen Sie für jedes Hauptkonto, das in dem Ergebnis aufgeführt ist, so vor:

   1. Prüfen Sie in der Spalte Übernahme, ob die Rolle von einem Ordner oder einer Organisationsressource übernommen wurde. Wenn die Spalte einen Link zu einer übergeordneten Ressource enthält, klicken Sie darauf, um zur IAM-Seite der übergeordneten Ressource zu gelangen.
   2. Klicken Sie neben einem Hauptkonto auf  Bearbeiten.
   3. Klicken Sie zum Entfernen von Berechtigungen neben Dienstkontoadministrator auf Löschen. Wenn Sie alle Dienstkontoberechtigungen entfernen möchten, klicken Sie neben allen anderen Berechtigungen auf Löschen.

3. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Shielded VM disabled

Kategoriename in der API: SHIELDED_VM_DISABLED

Shielded VM ist auf dieser Compute Engine-Instanz deaktiviert.

Shielded VMs sind virtuelle Maschinen (VMs) in Google Cloud, die durch eine Reihe von Sicherheitsfunktionen gegen Rootkits und Bootkits geschützt werden. Shielded VMs sorgen dafür, dass der Bootloader und die Firmware signiert und verifiziert werden. Weitere Informationen zu Shielded VM.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.

   Zu Seite „VM-Instanzen“

2. Wählen Sie die Instanz aus, die sich auf das Ergebnis von Security Health Analytics bezieht.

3. Klicken Sie auf der Seite Instanzdetails, die geladen wird, auf Beenden.

4. Wenn die Instanz nicht mehr ausgeführt wird, klicken Sie auf Bearbeiten.

5. Verwenden Sie im Bereich Shielded VM die Umschalter vTPM aktivieren und Integrity Monitoring aktivieren, um Shielded VM zu aktivieren.

6. Wenn Sie keine benutzerdefinierten oder nicht signierten Treiber verwenden, können Sie optional auch Secure Boot aktivieren.

7. Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzdetails angezeigt.

8. Klicken Sie auf  Starten, um die Instanz zu starten.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL CMEK disabled

Kategoriename in der API: SQL_CMEK_DISABLED

Eine SQL-Datenbankinstanz verwendet keine vom Kunden verwalteten Verschlüsselungsschlüssel (CMEK).

Mit CMEK werden die Schlüssel, die Sie in Cloud KMS erstellen und verwalten, die Schlüssel umschließen, die Google zum Verschlüsseln Ihrer Daten verwendet. Dadurch haben Sie mehr Kontrolle über den Zugriff auf Ihre Daten. Weitere Informationen finden Sie in der CMEK-Übersicht für Ihr Produkt: Cloud SQL for MySQL, Cloud SQL for PostgreSQL oder Cloud SQL. für SQL Server. CMEK verursacht zusätzliche Kosten im Zusammenhang mit Cloud KMS.

Achtung: Diese Abhilfemaßnahmen können Ihre Produktionsumgebung beeinträchtigen. Verschieben Sie ggf. Arbeitslasten, Daten oder Berechtigungen in neue Ressourcen, bevor Sie vorhandene Assets löschen.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf Löschen.

4. Um eine neue Instanz mit aktiviertem CMEK zu erstellen, folgen Sie der Anleitung zum Konfigurieren von CMEK für Ihr Produkt:

   1. Cloud SQL for MySQL
   2. Cloud SQL for PostgreSQL
   3. Cloud SQL for SQL Server

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL contained database authentication

Kategoriename in der API: SQL_CONTAINED_DATABASE_AUTHENTICATION

Bei einer Datenbankinstanz von Cloud SQL for SQL Server ist das Datenbank-Flag enthaltene Datenbankauthentifizierung nicht auf Aus gesetzt.

Das Flag contained database authentication steuert, ob Sie eigenständige Datenbanken im Datenbankmodul erstellen oder an dieses anhängen können. Eine eigenständige Datenbank enthält alle Datenbankeinstellungen und -metadaten, die zum Definieren der Datenbank erforderlich sind. Außerdem hat die Datenbank keine Konfigurationsabhängigkeiten mit der Instanz des Datenbankmoduls, in der sie installiert ist.

Die Aktivierung dieses Flags wird aus folgenden Gründen nicht empfohlen:

• Nutzer können ohne Authentifizierung auf Datenbank-Engine-Ebene eine Verbindung zur Datenbank herstellen.
• Wenn die Datenbank vom Datenbankmodul isoliert wird, kann sie in eine andere Instanz von SQL Server verschoben werden.

Eigenständige Datenbanken sind konkreten Bedrohungen ausgesetzt, die von Administratoren des SQL Server-Datenbankmoduls erkannt und minimiert werden sollten. Die meisten Bedrohungen sind auf den Authentifizierungsprozess USER WITH PASSWORD zurückzuführen, der die Authentifizierungsgrenze von der Ebene des Datenbankmoduls auf die Ebene der Datenbank verschiebt.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

4. Legen Sie im Bereich Datenbank-Flags für das Datenbank-Flag contained database authentication den Wert Aus fest.

5. Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL cross DB ownership chaining

Kategoriename in der API: SQL_CROSS_DB_OWNERSHIP_CHAINING

Bei einer Cloud SQL for SQL Server-Datenbankinstanz ist das Datenbank-Flag Cross-DB-Inhaberverkettung nicht auf Aus gesetzt.

Mit dem Flag cross db ownership chaining können Sie die datenbankübergreifende Verkettung der Eigentümerschaft auf Datenbankebene steuern oder die datenbankübergreifende Verkettung der Eigentümerschaft für alle Datenbankanweisungen zulassen.

Die Aktivierung dieses Flags wird nicht empfohlen, es sei denn, alle von der SQL Server-Instanz gehosteten Datenbanken nehmen an der datenbankübergreifenden Verkettung der Eigentümerschaft teil und Sie sind sich der Auswirkungen dieser Einstellung auf die Sicherheit bewusst.

Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

4. Legen Sie im Bereich Datenbank-Flags für das Datenbank-Flag cross db ownership chaining den Wert Aus fest.

5. Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL external scripts enabled

Kategoriename in der API: SQL_EXTERNAL_SCRIPTS_ENABLED

Bei einer Datenbankinstanz von Cloud SQL for SQL Server ist das Datenbank-Flag external scripts enabled nicht auf Aus gesetzt.

Wenn diese Einstellung aktiviert ist, wird die Ausführung von Skripts mit bestimmten Remote-Spracherweiterungen aktiviert. Da dieses Feature die Sicherheit des Systems beeinträchtigen kann, empfehlen wir, es zu deaktivieren.

Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

4. Legen Sie im Bereich Datenbank-Flags das Datenbank-Flag external scripts enabled auf den Wert Aus fest.

5. Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL instance not monitored

Kategoriename in der API: SQL_INSTANCE_NOT_MONITORED

Dieser Hinweis ist für Aktivierungen auf Projektebene nicht verfügbar.

Logmesswerte und Benachrichtigungen sind nicht für das Monitoring von Änderungen an der Konfiguration von Cloud SQL-Instanzen konfiguriert.

Eine fehlerhafte Konfiguration der SQL-Instanzoptionen kann zu Sicherheitsrisiken führen. Das Deaktivieren der automatischen Sicherung und der Hochverfügbarkeitsoptionen kann die Geschäftskontinuität beeinträchtigen und das Einschränken autorisierter Netzwerke kann die Präsenz in nicht vertrauenswürdigen Netzwerken erhöhen. Wenn Sie Änderungen an der Konfiguration der SQL-Instanz überwachen, können Sie weniger Zeit für die Erkennung und Korrektur von Fehlkonfigurationen aufwenden.

Weitere Informationen finden Sie in der Übersicht zu Logbasierten Messwerten.

Abhängig von der Menge der Informationen können die Cloud Monitoring-Kosten erheblich sein. Informationen zur Nutzung des Dienstes und seinen Kosten finden Sie unter Google Cloud Observability-Preise.

Bei der Aktivierung der Premium-Stufe von Security Command Center auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standardstufe in der übergeordneten Organisation aktiviert ist.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

Messwert erstellen

1. Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf.

   Weiter zu logbasierten Messwerten

2. Klicken Sie auf Messwert erstellen.

3. Wählen Sie unter Messwerttyp die Option Zähler aus.

4. Unter Details:

   1. Legen Sie unter Name des Logmesswerts einen Namen fest.
   2. Fügen Sie eine Beschreibung hinzu.
   3. Legen Sie Einheiten auf 1 fest.

5. Kopieren Sie unter Filterauswahl den folgenden Text und fügen Sie ihn in das Feld Filter erstellen ein, wobei Sie eventuell vorhandenen Text ersetzen:

     protoPayload.methodName="cloudsql.instances.update"
     OR protoPayload.methodName="cloudsql.instances.create"
     OR protoPayload.methodName="cloudsql.instances.delete"

6. Klicken Sie auf Messwert erstellen. Sie sehen eine Bestätigung.

Benachrichtigungsrichtlinie erstellen

1. Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf:

   Zu Logbasierte Messwerte

   Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Logging ist.

2. Wählen Sie im Bereich Benutzerdefinierte Messwerte den Messwert aus, den Sie im vorherigen Abschnitt erstellt haben.

3. Klicken Sie auf Mehr und dann auf Benachrichtigung mit dem Messwert erstellen.

   Das Dialogfeld Neue Bedingung wird geöffnet. Die Optionen zur Messwert- und Datentransformation sind bereits ausgefüllt.

4. Klicken Sie auf Next (Weiter).
   1. Prüfen Sie die vorkonfigurierten Einstellungen. Sie können den Schwellenwert ändern.
   2. Klicken Sie auf Bedingungsname und geben Sie einen Namen für die Bedingung ein.
5. Klicken Sie auf Weiter.

6. Klicken Sie auf Benachrichtigungskanäle, um Benachrichtigungen zu Ihrer Benachrichtigungsrichtlinie hinzuzufügen. Wählen Sie im Dialogfeld einen oder mehrere Benachrichtigungskanäle aus dem Menü aus und klicken Sie dann auf OK.

   Wenn Sie benachrichtigt werden möchten, wenn Vorfälle geöffnet und geschlossen werden, klicken Sie auf das Kästchen Bei Schließen von Vorfall benachrichtigen. Standardmäßig werden Benachrichtigungen nur gesendet, wenn Vorfälle geöffnet werden.

7. Optional: Aktualisieren Sie die Dauer bis zur automatischen Schließung von Vorfällen. Dieses Feld bestimmt, wann Monitoring Vorfälle ohne Messwertdaten schließt.
8. Optional: Klicken Sie auf Dokumentation und geben Sie alle Informationen ein, die in einer Benachrichtigung angezeigt werden sollen.
9. Klicken Sie auf Name der Benachrichtigung und geben Sie einen Namen für die Benachrichtigungsrichtlinie ein.
10. Klicken Sie auf Richtlinie erstellen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL local infile

Kategoriename in der API: SQL_LOCAL_INFILE

Bei einer Datenbankinstanz von Cloud SQL for MySQL ist das Datenbank-Flag local_infile nicht auf Aus gesetzt. Aufgrund von Sicherheitsproblemen in Verbindung mit dem Flag local_infile sollte es deaktiviert werden. Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

4. Legen Sie im Bereich Datenbank-Flags das Datenbank-Flag local_infile auf den Wert Aus fest.

5. Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL log checkpoints disabled

Kategoriename in der API: SQL_LOG_CHECKPOINTS_DISABLED

Bei einer Datenbankinstanz von Cloud SQL for PostgreSQL ist das Datenbank-Flag log_checkpoints nicht auf On gesetzt.

Wenn log_checkpoints aktiviert ist, werden Prüfpunkte und Neustartpunkte im Serverlog protokolliert. Einige Statistiken sind in den Logeinträgen enthalten, einschließlich der Anzahl der geschriebenen Zwischenspeicher und der Zeit, die zum Schreiben benötigt wurde.

Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

4. Legen Sie im Bereich Datenbank-Flags für das Datenbank-Flag log_checkpoints den Wert Ein fest.

5. Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL log connections disabled

Kategoriename in der API: SQL_LOG_CONNECTIONS_DISABLED

Bei einer Datenbankinstanz von Cloud SQL for PostgreSQL ist das Datenbank-Flag log_connections nicht auf Ein gesetzt.

Wenn log_connections aktiviert ist, werden Verbindungsversuche zum Server zusammen mit der erfolgreichen Clientauthentifizierung protokolliert. Die Logs können bei der Fehlerbehebung und Bestätigung von ungewöhnlichen Verbindungsversuchen zum Server hilfreich sein.

Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

4. Legen Sie im Bereich Datenbank-Flags für das Datenbank-Flag log_connections den Wert Ein fest.

5. Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL log disconnections disabled

Kategoriename in der API: SQL_LOG_DISCONNECTIONS_DISABLED

Bei einer Datenbankinstanz von Cloud SQL for PostgreSQL ist das Datenbank-Flag log_disconnections nicht auf Ein gesetzt.

Wenn Sie die Einstellung log_disconnections aktivieren, werden Logeinträge am Ende jeder Sitzung erstellt. Die Logs sind bei der Fehlerbehebung und Bestätigung von ungewöhnlichen Aktivitäten in einem bestimmten Zeitraum hilfreich. Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

4. Legen Sie im Bereich Datenbank-Flags für das Datenbank-Flag log_disconnections den Wert Ein fest.

5. Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL log duration disabled

Kategoriename in der API: SQL_LOG_DURATION_DISABLED

Bei einer Datenbankinstanz von Cloud SQL for PostgreSQL ist das Datenbank-Flag log_duration nicht auf Ein gesetzt.

Wenn die Option log_duration aktiviert ist, bewirkt diese Einstellung, dass die Ausführungszeit und die Dauer jeder abgeschlossenen Anweisung geloggt werden. Das Monitoring der Zeit, die für die Ausführung von Abfragen benötigt wird, kann entscheidend sein, um langsame Abfragen zu erkennen und Datenbankprobleme zu beheben.

Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

4. Legen Sie im Bereich Datenbank-Flags das Datenbank-Flag log_duration auf Ein fest.

5. Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL log error verbosity

Kategoriename in der API: SQL_LOG_ERROR_VERBOSITY

Bei einer Datenbankinstanz von Cloud SQL for PostgreSQL ist das Datenbank-Flag log_error_verbosity nicht auf default oder verbose gesetzt.

Das Flag log_error_verbosity steuert die Detailgenauigkeit von Meldungen, die in Logs geschrieben werden. Je höher der Ausführlichkeitsgrad, desto mehr Details werden in den Meldungen aufgezeichnet. Wir empfehlen, dieses Flag auf default oder verbose festzulegen.

Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

4. Legen Sie im Bereich Datenbank-Flags das Datenbank-Flag log_error_verbosity auf default oder verbose fest.

5. Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL log lock waits disabled

Kategoriename in der API: SQL_LOG_LOCK_WAITS_DISABLED

Bei einer Datenbankinstanz von Cloud SQL for PostgreSQL ist das Datenbank-Flag log_lock_waits nicht auf An gesetzt.

Wenn Sie die Einstellung log_lock_waits aktivieren, werden Logeinträge erstellt, wenn Sitzungswartezeiten länger als die deadlock_timeout-Zeit zum Abrufen einer Sperre dauern. Die Logs sind hilfreich, wenn Sie feststellen möchten, ob Wartezeiten auf Sperren zu Leistungseinbußen führen.

Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

4. Legen Sie im Bereich Datenbank-Flags für das Datenbank-Flag log_lock_waits den Wert Ein fest.

5. Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL log min duration statement enabled

Kategoriename in der API: SQL_LOG_MIN_DURATION_STATEMENT_ENABLED

Bei einer Cloud SQL for PostgreSQL-Datenbankinstanz ist das Datenbank-Flag log_min_Duration_statement nicht auf -1 festgelegt.

Das Flag log_min_duration_statement bewirkt, dass SQL-Anweisungen, die länger als eine angegebene Zeit ausgeführt werden, in Logs aufgezeichnet werden. Sie sollten diese Einstellung deaktivieren, da SQL-Anweisungen sensible Informationen enthalten, die nicht protokolliert werden sollen. Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

4. Legen Sie im Bereich Datenbank-Flags für das Datenbank-Flag log_min_duration_statement den Wert -1 fest.

5. Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL log min error statement

Kategoriename in der API: SQL_LOG_MIN_ERROR_STATEMENT

Bei einer Datenbankinstanz von Cloud SQL for PostgreSQL ist das Datenbank-Flag log_min_error_statement nicht entsprechend festgelegt.

Das Flag log_min_error_statement steuert, ob SQL-Anweisungen, die Fehlerbedingungen verursachen, in Serverlogs aufgezeichnet werden. SQL-Anweisungen mit dem angegebenen Schweregrad oder höher werden mit Meldungen für die fehlerhaften Anweisungen in Logs geschrieben. Je höher der Schweregrad, desto weniger Meldungen werden aufgezeichnet.

Wenn log_min_error_statement nicht auf den gewünschten Wert festgelegt ist, werden Meldungen möglicherweise nicht als Fehlermeldungen klassifiziert. Ein zu niedrig eingestellter Schweregrad würde die Anzahl der Meldungen erhöhen und das Auffinden tatsächlicher Fehler erschweren. Ein zu hoch eingestellter Schweregrad kann dazu führen, dass Fehlermeldungen für tatsächliche Fehler nicht in Logs geschrieben werden.

Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

4. Legen Sie im Bereich Datenbank-Flags für das Datenbank-Flag log_min_error_statement einen der folgenden empfohlenen Werte fest, entsprechend der Logging-Richtlinie Ihrer Organisation.

   • debug5
   • debug4
   • debug3
   • debug2
   • debug1
   • info
   • notice
   • warning
   • error

5. Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL log min error statement severity

Kategoriename in der API: SQL_LOG_MIN_ERROR_STATEMENT_SEVERITY

Bei einer Datenbankinstanz von Cloud SQL for PostgreSQL ist das Datenbank-Flag log_min_error_statement nicht entsprechend festgelegt.

Das Flag log_min_error_statement steuert, ob SQL-Anweisungen, die Fehlerbedingungen verursachen, in Serverlogs aufgezeichnet werden. SQL-Anweisungen mit dem angegebenen oder einem strikteren Schweregrad werden mit Meldungen für die fehlerhaften Anweisungen in Logs geschrieben. Je strikter der Schweregrad, desto weniger Meldungen werden aufgezeichnet.

Wenn log_min_error_statement nicht auf den gewünschten Wert festgelegt ist, werden Meldungen möglicherweise nicht als Fehlermeldungen klassifiziert. Ein zu niedrig eingestellter Schweregrad würde die Anzahl der Meldungen erhöhen und das Auffinden tatsächlicher Fehler erschweren. Ein zu hoher bzw. strikter Schweregrad kann dazu führen, dass Fehlermeldungen für tatsächliche Fehler nicht geloggt werden.

Wir empfehlen, dieses Flag auf Fehler oder strikter zu setzen.

Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

4. Legen Sie im Bereich Datenbank-Flags für das Datenbank-Flag log_min_error_statement einen der folgenden empfohlenen Werte fest, entsprechend der Logging-Richtlinie Ihrer Organisation.

   • error
   • log
   • fatal
   • panic

5. Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL log min messages

Kategoriename in der API: SQL_LOG_MIN_MESSAGES

Bei einer Datenbankinstanz von Cloud SQL for PostgreSQL ist das Datenbank-Flag log_min_messages nicht mindestens auf Warnung gesetzt.

Das Flag log_min_messages steuert, welche Nachrichtenebenen in Serverlogs aufgezeichnet werden. Je höher der Schweregrad, desto weniger Meldungen werden aufgezeichnet. Wenn Sie den Schwellenwert zu niedrig ansetzen, kann sich der Umfang des Logspeichers erhöhen, was das Auffinden tatsächlicher Fehler erschwert.

Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

4. Legen Sie im Bereich Datenbank-Flags für das Datenbank-Flag log_min_messages gemäß der Logging-Richtlinie Ihrer Organisation einen der folgenden empfohlenen Werte fest.

   • debug5
   • debug4
   • debug3
   • debug2
   • debug1
   • info
   • notice
   • warning

5. Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL log executor stats enabled

Kategoriename in der API: SQL_LOG_EXECUTOR_STATS_ENABLED

Bei einer Datenbankinstanz von Cloud SQL for PostgreSQL ist das Datenbank-Flag log_executor_stats nicht auf Aus gesetzt.

Wenn das Flag log_executor_stats aktiviert ist, werden die Executor-Leistungsstatistiken in die PostgreSQL-Logs für jede Abfrage aufgenommen. Diese Einstellung kann bei der Fehlerbehebung hilfreich sein, gleichzeitig aber die Anzahl der Logs und den Leistungsaufwand erheblich erhöhen.

Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

4. Legen Sie im Bereich Datenbank-Flags das Datenbank-Flag log_executor_stats auf Aus fest.

5. Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL log hostname enabled

Kategoriename in der API: `SQL_LOG_HOSTNAME_ENABLED

Bei einer Datenbankinstanz von Cloud SQL for PostgreSQL ist das Datenbank-Flag log_hostname nicht auf Aus gesetzt.

Wenn das Flag log_hostname aktiviert ist, wird der Hostname des verbindenden Hosts geloggt. Standardmäßig wird in Verbindungslogeinträgen nur die IP-Adresse angezeigt. Diese Einstellung kann bei der Fehlerbehebung hilfreich sein. Allerdings kann sie die Serverleistung beeinträchtigen, da der DNS-Auflösungsprozess für jede geloggte Anweisung eine IP-Adresse in einen Hostnamen umwandeln muss.

Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

4. Legen Sie im Bereich Datenbank-Flags das Datenbank-Flag log_hostname auf Aus fest.

5. Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL log parser stats enabled

Kategoriename in der API: SQL_LOG_PARSER_STATS_ENABLED

Bei einer Datenbankinstanz von Cloud SQL for PostgreSQL ist das Datenbank-Flag log_parser_stats nicht auf Aus gesetzt.

Wenn das Flag log_parser_stats aktiviert ist, werden die Parser-Leistungsstatistiken für jede Abfrage in die PostgreSQL-Logs eingefügt. Diese Einstellung kann bei der Fehlerbehebung hilfreich sein, gleichzeitig aber die Anzahl der Logs und den Leistungsaufwand erheblich erhöhen.

Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

4. Legen Sie im Bereich Datenbank-Flags das Datenbank-Flag log_parser_stats auf Aus fest.

5. Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL log planner stats enabled

Kategoriename in der API: SQL_LOG_PLANNER_STATS_ENABLED

Bei einer Datenbankinstanz von Cloud SQL for PostgreSQL ist das Datenbank-Flag log_planner_stats nicht auf Aus gesetzt.

Wenn das Flag log_planner_stats aktiviert ist, wird eine grobe Profilerstellungsmethode zum Logging der Leistungsstatistiken des PostgreSQL-Planers verwendet. Diese Einstellung kann bei der Fehlerbehebung hilfreich sein, gleichzeitig aber die Anzahl der Logs und den Leistungsaufwand erheblich erhöhen.

Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

4. Legen Sie im Bereich Datenbank-Flags das Datenbank-Flag log_planner_stats auf Aus fest.

5. Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL log statement

Kategoriename in der API: SQL_LOG_STATEMENT

Bei einer Datenbankinstanz von Cloud SQL for PostgreSQL ist das Datenbank-Flag log_statement nicht auf ddl gesetzt.

Der Wert dieses Flags bestimmt, welche SQL-Anweisungen in Logs geschrieben werden. Logging hilft beim Beheben von operativen Problemen und ermöglicht forensische Analysen. Wenn dieses Flag nicht auf den richtigen Wert festgelegt ist, können relevante Informationen übersprungen werden oder in zu vielen Meldungen versteckt sein. Der Wert ddl (alle Datendefinitionsanweisungen) wird empfohlen, sofern in der Logging-Richtlinie Ihrer Organisation nicht anders vorgegeben.

Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

4. Legen Sie im Bereich Datenbank-Flags das Datenbank-Flag log_statement auf ddl fest.

5. Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL log statement stats enabled

Kategoriename in der API: SQL_LOG_STATEMENT_STATS_ENABLED

Bei einer Datenbankinstanz von Cloud SQL for PostgreSQL ist das Datenbank-Flag log_statement_stats nicht auf Aus gesetzt.

Wenn das Flag log_statement_stats aktiviert ist, werden für jede Abfrage End-to-End-Leistungsstatistiken in die PostgreSQL-Logs eingefügt. Diese Einstellung kann bei der Fehlerbehebung hilfreich sein, gleichzeitig aber die Anzahl der Logs und den Leistungsaufwand erheblich erhöhen.

Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

4. Legen Sie im Bereich Datenbank-Flags das Datenbank-Flag log_statement_stats auf Aus fest.

5. Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL log temp files

Kategoriename in der API: SQL_LOG_TEMP_FILES

Bei einer Cloud SQL for PostgreSQL-Datenbankinstanz ist das Datenbank-Flag log_temp_files nicht auf 0 gesetzt.

Temporäre Dateien können für Sortiervorgänge, Hashes und temporäre Abfrageergebnisse erstellt werden. Wenn Sie das Flag log_temp_files auf 0 setzen, werden alle temporären Dateidaten protokolliert. Das Logging aller temporären Dateien ist hilfreich, um potenzielle Leistungsprobleme zu erkennen. Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

4. Legen Sie im Abschnitt Datenbank-Flags für das Datenbank-Flag log_temp_files den Wert 0 fest.

5. Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL no root password

Kategoriename in der API: SQL_NO_ROOT_PASSWORD

Eine MySQL-Datenbankinstanz hat kein Passwort für das Root-Konto. Fügen Sie der MySQL-Datenbankinstanz ein Passwort hinzu. Weitere Informationen finden Sie unter MySQL-Nutzer.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Wählen Sie auf der Seite Instanzdetails den Tab Nutzer aus.

4. Klicken Sie neben dem root-Nutzer auf Mehr   und wählen Sie Passwort ändern aus.

5. Geben Sie ein neues, starkes Passwort ein und klicken Sie auf Ok.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL public IP

Kategoriename in der API: SQL_PUBLIC_IP

Eine Cloud SQL-Datenbank hat eine öffentliche IP-Adresse.

Um die Angriffsfläche Ihres Unternehmens zu reduzieren, sollten Cloud SQL-Datenbanken keine öffentlichen IP-Adressen haben. Private IP-Adressen bieten eine höhere Netzwerksicherheit und eine geringere Latenz für Ihre Anwendung.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie im Menü auf der linken Seite auf Verbindungen.

4. Klicken Sie auf den Tab Netzwerk und entfernen Sie das Häkchen bei Öffentliche IP-Adresse.

5. Wenn die Instanz nicht bereits für die Verwendung einer privaten IP-Adresse konfiguriert ist, finden Sie weitere Informationen unter Private IP-Adresse für eine vorhandene Instanz konfigurieren.

6. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL remote access enabled

Kategoriename in der API: SQL_REMOTE_ACCESS_ENABLED

Bei einer Cloud SQL for SQL Server-Datenbankinstanz ist das Datenbank-Flag Remotezugriff nicht auf Aus gesetzt.

Wenn diese Einstellung aktiviert ist, gewährt sie die Berechtigung, lokal gespeicherte Prozeduren von Remoteservern oder remote gespeicherte Prozeduren vom lokalen Server auszuführen. Diese Funktion kann missbraucht werden, um einen DoS-Angriff (Denial of Service) auf Remote-Servern zu starten, indem die Abfrageverarbeitung auf ein Ziel verlagert wird. Wir empfehlen, diese Einstellung zu deaktivieren, um Missbrauch zu verhindern.

Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

4. Setzen Sie im Bereich Flags die Option Remotezugriff auf Aus.

5. Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL skip show database disabled

Kategoriename in der API: SQL_SKIP_SHOW_DATABASE_DISABLED

Bei einer Cloud SQL for MySQL-Datenbankinstanz ist das Datenbank-Flag skip_show_database nicht auf Ein gesetzt.

Durch Aktivieren dieses Flags wird verhindert, dass Nutzer die Anweisung SHOW DATABASES verwenden, wenn sie nicht die Berechtigung SHOW DATABASES haben. Mit dieser Einstellung können sich Nutzer ohne ausdrückliche Berechtigung keine Datenbanken ansehen, die anderen Nutzern gehören. Wir empfehlen, dieses Flag zu aktivieren.

Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

4. Setzen Sie im Bereich Flags die Option skip_show_database auf Ein.

5. Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL trace flag 3625

Kategoriename in der API: SQL_TRACE_FLAG_3625

Bei einer Cloud SQL for SQL Server-Datenbankinstanz ist das Datenbank-Flag 3625 (Trace-Flag) nicht auf Ein gesetzt.

Mit diesem Flag wird die Menge der Informationen begrenzt, die an Nutzer zurückgegeben werden, die keine Mitglieder der festen Serverrolle "sysadmin" sind. Dazu werden die Parameter einiger Fehlermeldungen mithilfe von Sternchen (******) maskiert. Um die Offenlegung vertraulicher Informationen zu verhindern, empfehlen wir die Aktivierung dieses Flags.

Hinweis: Bestimmte Versionen der CIS-Benchmark empfehlen fälschlicherweise, 3625 (Trace-Flag) auf Aus zu setzen. Die sicherste Einstellung ist aber An. Weitere Informationen finden Sie im CIS-Änderungsvorschlag Datenbank-Flag 3625 (Trace-Flag) für alle Cloud SQL Server-Instanzen auf „An“ setzen (Registrierung erforderlich).

Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

4. Legen Sie im Bereich Datenbank-Flags die Option 3625 auf Ein fest.

5. Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL user connections configured

Kategoriename in der API: SQL_USER_CONNECTIONS_CONFIGURED

Bei einer Datenbankinstanz von Cloud SQL for SQL Server ist das Datenbank-Flag Nutzerverbindungen konfiguriert.

Die Option Nutzerverbindungen gibt die maximale Anzahl gleichzeitiger Nutzerverbindungen an, die auf einer SQL Server-Instanz zulässig sind. Da es sich um eine dynamische (selbst konfigurierende) Option handelt, passt SQL Server die maximale Anzahl an Nutzerverbindungen nach Bedarf automatisch bis zum maximal zulässigen Wert an. Der Standardwert ist 0, d. h., bis zu 32.767 Nutzerverbindungen sind zulässig. Daher sollte das Datenbank-Flag Nutzeroptionen nicht konfiguriert werden.

Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

4. Klicken Sie im Bereich Datenbank-Flags neben Nutzerverbindungen auf Löschen.

5. Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL user options configured

Kategoriename in der API: SQL_USER_OPTIONS_CONFIGURED

Bei einer Cloud SQL for SQL Server-Datenbankinstanz ist das Datenbank-Flag Nutzeroptionen konfiguriert.

Diese Einstellung überschreibt globale Standardwerte der SET-Optionen für alle Nutzer. Da Nutzer und Anwendungen möglicherweise davon ausgehen, dass die SET-Standardoptionen der Datenbank verwendet werden, kann das Festlegen der Nutzeroptionen zu unerwarteten Ergebnissen führen. Daher sollte das Datenbank-Flag Nutzeroptionen nicht konfiguriert werden.

Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

4. Klicken Sie im Bereich Datenbank-Flags neben Nutzeroptionen auf Löschen.

5. Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SQL weak root password

Kategoriename in der API: SQL_WEAK_ROOT_PASSWORD

Eine MySQL-Datenbankinstanz hat ein schwaches Passwort für das Root-Konto festgelegt. Sie sollten ein starkes Passwort für die Instanz festlegen. Weitere Informationen finden Sie unter MySQL-Nutzer.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Wählen Sie auf der Seite Instanzdetails den Tab Nutzer aus.

4. Klicken Sie neben dem root-Nutzer auf Mehr   und wählen Sie Passwort ändern aus.

5. Geben Sie ein neues, starkes Passwort ein und klicken Sie auf Ok.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

SSL not enforced

Kategoriename in der API: SSL_NOT_ENFORCED

Eine Cloud SQL-Datenbankinstanz benötigt nicht alle eingehenden Verbindungen zur Verwendung von SSL.

Damit bei sensiblen Daten bei der Übertragung durch unverschlüsselte Kommunikation keine Datenlecks entstehen, sollten alle bei Ihrer SQL-Datenbank eingehenden Verbindungen SSL verwenden. SSL/TLS konfigurieren.

Sie können dieses Ergebnis beheben, indem Sie für Ihre SQL-Instanzen nur SSL-Verbindungen zulassen:

1. Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.

   Cloud SQL-Instanzen aufrufen

2. Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf dem Tab Verbindungen entweder auf Nur SSL-Verbindungen zulassen oder Vertrauenswürdige Clientzertifikate erforderlich. Weitere Informationen finden Sie unter SSL/TLS-Verschlüsselung erzwingen.

4. Wenn Sie Vertrauenswürdige Clientzertifikate erforderlich ausgewählt haben, erstellen Sie ein neues Clientzertifikat. Weitere Informationen finden Sie unter Neues Clientzertifikat erstellen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Too many KMS users

Kategoriename in der API: TOO_MANY_KMS_USERS

Beschränken Sie die Anzahl der Hauptnutzer, die kryptografische Schlüssel verwenden können, auf drei. Die im Folgenden aufgeführten vordefinierten Rollen gewähren Berechtigungen zum Verschlüsseln, Entschlüsseln oder Signieren von Daten mit kryptografischen Schlüsseln:

• roles/owner
• roles/cloudkms.cryptoKeyEncrypterDecrypter
• roles/cloudkms.cryptoKeyEncrypter
• roles/cloudkms.cryptoKeyDecrypter
• roles/cloudkms.signer
• roles/cloudkms.signerVerifier

Weitere Informationen finden Sie unter Berechtigungen und Rollen.

Bei der Aktivierung der Premium-Stufe von Security Command Center auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standardstufe in der übergeordneten Organisation aktiviert ist.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Cloud KMS-Schlüssel auf.

   Zu Cloud KMS-Schlüsseln

2. Klicken Sie auf den Namen des Schlüsselbunds, der in dem Ergebnis angegeben ist.

3. Klicken Sie auf den Namen des im Ergebnis angegebenen Schlüssels.

4. Klicken Sie auf das Kästchen neben der primären Version und dann auf Show Info Panel (Infofeld ansehen).

5. Reduzieren Sie die Anzahl der Hauptkonten mit Berechtigungen zum Verschlüsseln, Entschlüsseln oder Signieren von Daten auf maximal 3. Wenn Sie Berechtigungen widerrufen möchten, klicken Sie neben jedem Hauptkonto auf Löschen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Unconfirmed AppArmor profile

Kategoriename in der API: GKE_APP_ARMOR

Ein Container kann explizit so konfiguriert werden, dass er von AppArmor nicht eingeschränkt wird. Dies sorgt dafür, dass kein AppArmor-Profil auf den Container angewendet und dieser somit nicht durch ein solches eingeschränkt wird. Die deaktivierte präventive Sicherheitskontrolle erhöht das Risiko eines Container-Escapes.

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben:

1. Öffnen Sie das Manifest für jede betroffene Arbeitslast.
2. Legen Sie für die folgenden eingeschränkten Felder einen der zulässigen Werte fest.

Eingeschränkte Felder

• metadata.annotations["container.apparmor.security.beta.kubernetes.io/*"]

Zulässige Werte

• false

User managed service account key

Kategoriename in der API: USER_MANAGED_SERVICE_ACCOUNT_KEY

Ein Nutzer verwaltet einen Dienstkontoschlüssel. Dienstkontoschlüssel stellen ein Sicherheitsrisiko dar, wenn sie nicht ordnungsgemäß verwaltet werden. Sie sollten nach Möglichkeit eine sicherere Alternative zu Dienstkontoschlüsseln auswählen. Wenn Sie sich mit einem Dienstkontoschlüssel authentifizieren müssen, sind Sie für die Sicherheit des privaten Schlüssels und für andere Vorgänge verantwortlich, die unter Best Practices für die Verwaltung von Dienstkontoschlüsseln beschrieben werden. Wenn Sie keinen Dienstkontoschlüssel erstellen können, ist das Erstellen von Dienstkontoschlüsseln für Ihre Organisation möglicherweise deaktiviert. Weitere Informationen finden Sie unter Standardmäßig sichere Organisationsressourcen verwalten.

Achtung: Diese Abhilfemaßnahmen können Ihre Produktionsumgebung beeinträchtigen. Verschieben Sie ggf. Arbeitslasten, Daten oder Berechtigungen in neue Ressourcen, bevor Sie vorhandene Assets löschen.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:

1. Rufen Sie in der Google Cloud Console die Seite Dienstkonten auf.

   Zur Seite „Dienstkonten“

2. Wählen Sie bei Bedarf das im Ergebnis angegebene Projekt aus.

3. Löschen Sie vom Nutzer verwaltete Dienstkontoschlüssel, die im Ergebnis angegeben sind, wenn sie von keiner Anwendung verwendet werden.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Weak SSL policy

Kategoriename in der API: WEAK_SSL_POLICY

Eine Compute Engine-Instanz hat eine schwache SSL-Richtlinie oder verwendet die Google Cloud-Standard-SSL-Richtlinie mit einer TLS-Version unter 1.2.

HTTPS- und SSL-Proxy-Load-Balancer verwenden SSL-Richtlinien, um die Protokoll- und Chiffresammlungen für die TLS-Verbindungen zwischen Nutzern und dem Internet festzulegen. Durch diese Verbindungen werden sensible Daten verschlüsselt, damit Unbefugte keinen Zugriff auf diese Daten erhalten. Eine schwache SSL-Richtlinie ermöglicht es Clients, die veraltete TLS-Versionen verwenden, eine Verbindung mit einer weniger sicheren Chiffrensammlung oder einem weniger sicheren Protokoll herzustellen. Eine Liste empfohlener und veralteter Chiffresammlungen finden Sie auf der Seite iana.org TLS-Parameter.

Hinweis: Das Aktualisieren einer SSL-Richtlinie kann die Kompatibilität für Nutzer mit veralteten TLS-Versionen verringern.

Bei der Aktivierung der Premium-Stufe von Security Command Center auf Projektebene ist dieses Ergebnis nur verfügbar, wenn die Standardstufe in der übergeordneten Organisation aktiviert ist.

Die Schritte zur Behebung dieses Problems unterscheiden sich je nachdem, ob es durch die Verwendung einer Standard-SSL-Richtlinie von Google Cloud oder einer SSL-Richtlinie ausgelöst wurde, die eine schwache Chiffrensammlung oder eine TLS-Mindestversion unter 1.2 zulässt. Führen Sie die unten stehende Anleitung aus, die dem Auslöser der Abweichung entspricht.

Korrekturmaßnahmen für die Standard-SSL-Richtlinie von Google Cloud

1. Rufen Sie in der Google Cloud Console die Seite Ziel-Proxys auf.

   Zu Ziel-Proxys

2. Suchen Sie den Zielproxy, der in den Ergebnissen und den Weiterleitungsregeln in der Spalte Verwendet von angegeben ist.

3. Informationen zum Erstellen einer neuen SSL-Richtlinie finden Sie unter SSL-Richtlinien verwenden. Die Richtlinie sollte eine Mindest-TLS-Version von 1.2 und ein modernes oder eingeschränktes Profil haben.

4. Wenn Sie ein benutzerdefiniertes Profil verwenden möchten , müssen die folgenden Chiffresammlungen deaktiviert sein:

   • TLS_RSA_WITH_AES_128_GCM_SHA256
   • TLS_RSA_WITH_AES_256_GCM_SHA384
   • TLS_RSA_WITH_AES_128_CBC_SHA
   • TLS_RSA_WITH_AES_256_CBC_SHA
   • TLS_RSA_WITH_3DES_EDE_CBC_SHA

5. Wenden Sie die SSL-Richtlinie auf alle zuvor angegebenen Weiterleitungsregeln an.

Behebung einer schwachen Chiffrensammlung oder einer niedrigeren TLS-Version zulässig

1. Rufen Sie in der Google Cloud Console die Seite SSL-Richtlinien auf .

   SSL-Richtlinien aufrufen

2. Suchen Sie den Load Balancer, der in der Spalte Verwendet von angegeben ist.

3. Klicken Sie unter dem Namen der Richtlinie.

4. Klicken Sie auf  Bearbeiten.

5. Ändern Sie Mindest-TLS-Version in TLS 1.2 und Profil in „Modern“ oder „Eingeschränkt“.

6. Wenn Sie ein benutzerdefiniertes Profil verwenden möchten, müssen die folgenden Chiffresammlungen deaktiviert sein:

   • TLS_RSA_WITH_AES_128_GCM_SHA256
   • TLS_RSA_WITH_AES_256_GCM_SHA384
   • TLS_RSA_WITH_AES_128_CBC_SHA
   • TLS_RSA_WITH_AES_256_CBC_SHA
   • TLS_RSA_WITH_3DES_EDE_CBC_SHA

7. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Web UI enabled

Kategoriename in der API: WEB_UI_ENABLED

Die GKE-Web-UI (Dashboard) ist aktiviert.

Ein Kubernetes-Dienstkonto mit privilegierten Back-Ends ermöglicht die Kubernetes-Weboberfläche. Wenn er manipuliert wurde, kann das Dienstkonto missbraucht werden. Wenn Sie die Google Cloud Console bereits verwenden, erweitert die Kubernetes-Weboberfläche die Angriffsfläche unnötig. Kubernetes-Weboberfläche deaktivieren

Deaktivieren Sie die Kubernetes-Weboberfläche, um dieses Ergebnis zu beheben:

1. Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.

   Zur Seite „Kubernetes-Cluster“

2. Klicken Sie auf den Namen des Clusters, der im Security Health Analytics-Ergebnis aufgeführt ist.

3. Klicken Sie auf  Bearbeiten.

   Wenn die Clusterkonfiguration kürzlich geändert wurde, ist die Schaltfläche "Bearbeiten" möglicherweise deaktiviert. Wenn Sie die Clustereinstellungen nicht bearbeiten können, warten Sie einige Minuten und versuchen Sie es dann noch einmal.

4. Klicken Sie auf Add-ons. Der Abschnitt wird erweitert, damit Sie alle verfügbaren Add-ons sehen.

5. Wählen Sie in der Drop-down-Liste Kubernetes-Dashboard die Option Deaktiviert aus.

6. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Workload Identity disabled

Kategoriename in der API: WORKLOAD_IDENTITY_DISABLED

Workload Identity ist auf einem GKE-Cluster deaktiviert.

Für das Aufrufen von Google Cloud-Diensten aus GKE wird Workload Identity empfohlen, weil es bessere Sicherheitsmerkmale bietet und leichter zu verwalten ist. Wenn diese Funktion aktiviert wird, schützt sie einige potenziell vertrauliche Systemmetadaten vor Nutzerarbeitslasten, die in Ihrem Cluster ausgeführt werden. Lesen Sie die Informationen zur Metadatenverbergung.

Um dieses Ergebnis zu beheben, folgen Sie der Anleitung unter Workload Identity in einem Cluster aktivieren.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Fehlkonfigurationen in AWS beheben

Nur Enterprise-Stufe:Diese Funktion ist nur mit der Enterprise-Stufe von Security Command Center verfügbar.

AWS Cloud Shell Full Access Restricted

Kategoriename in der API: ACCESS_AWSCLOUDSHELLFULLACCESS_RESTRICTED

AWS CloudShell ist eine praktische Möglichkeit, Befehle der Befehlszeile für AWS-Dienste auszuführen. Eine verwaltete IAM-Richtlinie (AWSCloudShellFullAccess) gewährt vollen Zugriff auf CloudShell, was das Hoch- und Herunterladen von Dateien zwischen dem lokalen System eines Nutzers und der CloudShell-Umgebung ermöglicht. Innerhalb der CloudShell-Umgebung hat ein Nutzer sudo-Berechtigungen und kann auf das Internet zugreifen. So ist es beispielsweise möglich, Software zur Dateiübertragung zu installieren und Daten von CloudShell auf externe Internetserver zu verschieben.

Empfehlung: Achten Sie darauf, dass der Zugriff auf „AWSCloudShellFullAccess“ eingeschränkt ist

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

1. Öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
2. Wählen Sie im linken Bereich „Richtlinien“ aus.
3. Suchen Sie nach „AWSCloudShellFullAccess“ und wählen Sie es aus.
4. Klicken Sie auf dem Tab „Angehängte Elemente“ für jedes Element das Kästchen an und wählen Sie „Trennen“ aus.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Access Keys Rotated Every 90 Days or Less

Kategoriename in der API: ACCESS_KEYS_ROTATED_90_DAYS_LESS

Zugriffsschlüssel bestehen aus einer Zugriffsschlüssel-ID und einem geheimen Zugriffsschlüssel, die zum Signieren programmatischer Anfragen an AWS verwendet werden. AWS-Nutzer benötigen eigene Zugriffsschlüssel, um AWS programmatisch über die AWS-Befehlszeile, Tools für Windows PowerShell, die AWS SDKs oder direkte HTTP-Aufrufe mithilfe der APIs für einzelne AWS-Dienste aufzurufen. Es wird empfohlen, alle Zugriffsschlüssel regelmäßig zu rotieren.

Empfehlung: Achten Sie darauf, dass Zugriffsschlüssel mindestens alle 90 Tage rotiert werden

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

1. Rufen Sie die Verwaltungskonsole (https://console.aws.amazon.com/iam) auf.
2. Klicken Sie auf Users.
3. Klicken Sie auf Security Credentials.
4. Als Administrator
    – Klicken Sie auf Make Inactive für Schlüssel, die seit 90 Tagen nicht rotiert wurden.
5. Als IAM-Nutzer
    Klicken Sie auf Make Inactive oder Delete für Schlüssel, die in den letzten 90 Tagen nicht rotiert oder verwendet wurden.
6. Klicken Sie auf Create Access Key.
7. Programmaufruf mit neuen Anmeldedaten für den Zugriffsschlüssel aktualisieren

AWS-CLI

1. Erstellen Sie einen zweiten Zugriffsschlüssel, der standardmäßig aktiv ist, während der erste Zugriffsschlüssel noch aktiv ist. Führen Sie dazu diesen Befehl aus:

aws iam create-access-key

Der Nutzer hat jetzt zwei aktive Zugriffsschlüssel.

2. Aktualisieren Sie alle Anwendungen und Tools, damit sie den neuen Zugriffsschlüssel verwenden.
3. Mit dem folgenden Befehl können Sie prüfen, ob der erste Zugriffsschlüssel noch verwendet wird:

aws iam get-access-key-last-used

4. Sie können beispielsweise einige Tage warten und dann prüfen, ob der alte Zugriffsschlüssel noch verwendet wird, bevor Sie fortfahren.

Auch wenn in Schritt 3 angegeben wird, dass der alte Schlüssel nicht verwendet wird, sollten Sie den ersten Zugriffsschlüssel nicht sofort löschen. Ändern Sie stattdessen den Status des ersten Zugriffsschlüssels mit dem folgenden Befehl in „Inaktiv“:

aws iam update-access-key

5. Verwenden Sie nur den neuen Zugriffsschlüssel, um zu prüfen, ob Ihre Anwendungen funktionieren. Alle Anwendungen und Tools, die noch den ursprünglichen Zugriffsschlüssel verwenden, funktionieren ab diesem Zeitpunkt nicht mehr, da sie keinen Zugriff mehr auf AWS-Ressourcen haben. Wenn Sie eine solche Anwendung oder ein solches Tool finden, können Sie den Status wieder auf „Aktiv“ setzen, um den ersten Zugriffsschlüssel wieder zu aktivieren. Kehren Sie dann zu Schritt 2 zurück und aktualisieren Sie diese Anwendung so, dass sie den neuen Schlüssel verwendet.

6. Warten Sie einige Zeit, um sicherzustellen, dass alle Anwendungen und Tools aktualisiert wurden. Anschließend können Sie den ersten Zugriffsschlüssel mit dem folgenden Befehl löschen:

aws iam delete-access-key

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

All Expired Ssl Tls Certificates Stored Aws Iam Removed

Kategoriename in der API: ALL_EXPIRED_SSL_TLS_CERTIFICATES_STORED_AWS_IAM_REMOVED

Wenn Sie HTTPS-Verbindungen zu Ihrer Website oder Anwendung in AWS aktivieren möchten, benötigen Sie ein SSL/TLS-Serverzertifikat. Sie können ACM oder IAM zum Speichern und Bereitstellen von Serverzertifikaten verwenden.
Verwenden Sie IAM nur als Zertifikatsmanager, wenn Sie HTTPS-Verbindungen in einer Region unterstützen müssen, die von ACM nicht unterstützt wird. IAM verschlüsselt Ihre privaten Schlüssel sicher und speichert die verschlüsselte Version im IAM-SSL-Zertifikatsspeicher. IAM unterstützt die Bereitstellung von Serverzertifikaten in allen Regionen. Sie müssen Ihr Zertifikat jedoch von einem externen Anbieter für die Verwendung mit AWS erhalten. Sie können kein ACM-Zertifikat in IAM hochladen. Außerdem können Sie Ihre Zertifikate nicht über die IAM Console verwalten.

Empfehlung: Achten Sie darauf, dass alle abgelaufenen SSL-/TLS-Zertifikate entfernt werden, die in AWS IAM gespeichert sind.

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

Das Entfernen abgelaufener Zertifikate über die AWS Management Console wird derzeit nicht unterstützt. Verwenden Sie die Befehlszeile, um SSL-/TLS-Zertifikate zu löschen, die in IAM über die AWS API gespeichert sind.

AWS-CLI

Führen Sie zum Löschen eines abgelaufenen Zertifikats den folgenden Befehl aus. Ersetzen Sie dabei CERTIFICATE_NAME durch den Namen des zu löschenden Zertifikats:

aws iam delete-server-certificate --server-certificate-name <CERTIFICATE_NAME>

Wenn der vorherige Befehl erfolgreich ist, wird keine Ausgabe zurückgegeben.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Autoscaling Group Elb Healthcheck Required

Kategoriename in der API: AUTOSCALING_GROUP_ELB_HEALTHCHECK_REQUIRED

Hier wird geprüft, ob Ihre Autoscaling-Gruppen, die mit einem Load Balancer verknüpft sind, Elastic Load Balancing-Systemdiagnosen verwenden.

So kann die Gruppe den Status einer Instanz anhand zusätzlicher Tests des Load Balancers ermitteln. Mit Elastic Load Balancing-Systemdiagnosen lässt sich die Verfügbarkeit von Anwendungen unterstützen, die EC2-Autoscaling-Gruppen verwenden.

Empfehlung: Prüft, ob alle mit einem Load Balancer verknüpften Autoscaling-Gruppen Systemdiagnosen verwenden

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

Systemdiagnosen für Elastic Load Balancing aktivieren

1. Öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/.
2. Wählen Sie im Navigationsbereich unter „Autoscaling“ die Option „Autoscaling-Gruppen“ aus.
3. Klicken Sie das Kästchen für die Gruppe an.
4. Wähle „Bearbeiten“ aus.
5. Wählen Sie unter „Systemdiagnosen“ als „Typ der Systemdiagnose“ die Option „ELB“ aus.
6. Geben Sie für den Kulanzzeitraum für die Systemdiagnose „300“ ein.
7. Wählen Sie unten auf der Seite „Aktualisieren“ aus.

Weitere Informationen zur Verwendung eines Load Balancers mit einer Autoscaling-Gruppe finden Sie im AWS Autoscaling-Nutzerhandbuch.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Auto Minor Version Upgrade Feature Enabled Rds Instances

Kategoriename in der API: AUTO_MINOR_VERSION_UPGRADE_FEATURE_ENABLED_RDS_INSTANCES

Achten Sie darauf, dass für RDS-Datenbankinstanzen das Flag „Auto Minor Version Upgrade“ aktiviert ist, damit während des angegebenen Wartungszeitraums automatisch Engine-Nebenversionen installiert werden. So erhalten RDS-Instanzen die neuen Funktionen, Fehlerkorrekturen und Sicherheitspatches für ihre Datenbank-Engines.

Empfehlung: Achten Sie darauf, dass das automatische Upgrade von Nebenversionen für RDS-Instanzen aktiviert ist

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

1. Melden Sie sich in der AWS Management Console an und rufen Sie das RDS-Dashboard unter https://console.aws.amazon.com/rds/ auf.
2. Klicken Sie im linken Navigationsbereich auf Databases.
3. Wählen Sie die RDS-Instanz aus, die Sie aktualisieren möchten.
4. Klicken Sie oben rechts auf die Schaltfläche Modify.
5. Wählen Sie auf der Seite Modify DB Instance: <instance identifier> im Bereich Maintenance die Option Auto minor version upgrade aus und klicken Sie auf das Optionsfeld Yes.
6. Klicken Sie unten auf der Seite auf Continue und setzen Sie ein Häkchen bei „Sofort anwenden“, um die Änderungen sofort anzuwenden, oder wählen Sie Apply during the next scheduled maintenance window aus, um Ausfallzeiten zu vermeiden.
7. Prüfen Sie die Änderungen und klicken Sie auf Modify DB Instance. Der Instanzstatus sollte sich von „Verfügbar“ zu „Ändern“ und wieder zu „Verfügbar“ ändern. Sobald die Funktion aktiviert ist, sollte sich der Status von Auto Minor Version Upgrade in Yes ändern.

AWS-CLI

1. Führen Sie den Befehl describe-db-instances aus, um alle Namen von RDS-Datenbankinstanzen aufzulisten, die in der ausgewählten AWS-Region verfügbar sind:

aws rds describe-db-instances --region <regionName> --query 'DBInstances[*].DBInstanceIdentifier'

2. Die Befehlsausgabe sollte die ID jeder Datenbankinstanz zurückgeben.
3. Führen Sie den Befehl modify-db-instance aus, um die Konfiguration der ausgewählten RDS-Instanz zu ändern. Die Änderungen werden sofort angewendet. Entfernen Sie --apply-immediately, um die Änderungen während des nächsten geplanten Wartungsfensters anzuwenden und Ausfallzeiten zu vermeiden:

aws rds modify-db-instance --region <regionName> --db-instance-identifier <dbInstanceIdentifier> --auto-minor-version-upgrade --apply-immediately

4. Die Befehlsausgabe sollte die neuen Konfigurationsmetadaten für die RDS-Instanz und den Parameterwert AutoMinorVersionUpgrade enthalten.
5. Führen Sie den Befehl describe-db-instances aus, um zu prüfen, ob die Funktion „Automatisches Upgrade von Nebenversionen“ aktiviert wurde:

aws rds describe-db-instances --region <regionName> --db-instance-identifier <dbInstanceIdentifier> --query 'DBInstances[*].AutoMinorVersionUpgrade'

6. Die Befehlsausgabe sollte den aktuellen Status der Funktion als true zurückgeben. Die Funktion ist enabled und die Engine-Upgrades werden auf die ausgewählte RDS-Instanz angewendet.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Aws Config Enabled All Regions

Kategoriename in der API: AWS_CONFIG_ENABLED_ALL_REGIONS

AWS Config ist ein Webdienst, der die Konfigurationsverwaltung unterstützter AWS-Ressourcen in Ihrem Konto durchführt und Ihnen Protokolldateien zur Verfügung stellt. Zu den erfassten Informationen gehören das Konfigurationselement (AWS-Ressource), Beziehungen zwischen Konfigurationselementen (AWS-Ressourcen) und alle Konfigurationsänderungen zwischen Ressourcen. Wir empfehlen, AWS Config in allen Regionen zu aktivieren.

Empfehlung: Achten Sie darauf, dass AWS Config in allen Regionen aktiviert ist.

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

1. Wählen Sie rechts oben in der Konsole die Region aus, auf die Sie sich konzentrieren möchten.
2. Klickdienste
3. Klicken Sie auf „Konfiguration“.
4. Wenn in dieser Region ein Config-Aufzeichnungsgerät aktiviert ist, rufen Sie über das Navigationsmenü links die Seite „Einstellungen“ auf. Wenn in dieser Region noch kein Konfigurationsrekorder aktiviert ist, wählen Sie „Jetzt starten“ aus.
5. Wählen Sie „Alle in dieser Region unterstützten Ressourcen erfassen“ aus.
6. Globale Ressourcen (IAM-Ressourcen) einschließen
7. S3-Bucket im selben Konto oder in einem anderen verwalteten AWS-Konto angeben
8. SNS-Topic im selben oder einem anderen verwalteten AWS-Konto erstellen

AWS-CLI

1. Achten Sie darauf, dass gemäß den Voraussetzungen für den AWS Config-Dienst ein geeigneter S3-Bucket, ein SNS-Thema und eine IAM-Rolle vorhanden sind.
2. Führen Sie diesen Befehl aus, um einen neuen Konfigurationsrekorder zu erstellen:

aws configservice put-configuration-recorder --configuration-recorder name=default,roleARN=arn:aws:iam::012345678912:role/myConfigRole --recording-group allSupported=true,includeGlobalResourceTypes=true

3. Erstelle lokal eine Konfigurationsdatei für den Übermittlungskanal, in der die Kanalattribute angegeben sind, die aus den zuvor eingerichteten Voraussetzungen stammen:

{
 "name": "default",
 "s3BucketName": "my-config-bucket",
 "snsTopicARN": "arn:aws:sns:us-east-1:012345678912:my-config-notice",
 "configSnapshotDeliveryProperties": {
 "deliveryFrequency": "Twelve_Hours"
 }
}

4. Führen Sie diesen Befehl aus, um einen neuen Übermittlungskanal zu erstellen, der auf die im vorherigen Schritt erstellte JSON-Konfigurationsdatei verweist:

aws configservice put-delivery-channel --delivery-channel file://deliveryChannel.json

5. Starten Sie den Konfigurationsrekorder mit dem folgenden Befehl:

aws configservice start-configuration-recorder --configuration-recorder-name default

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Aws Security Hub Enabled

Kategoriename in der API: AWS_SECURITY_HUB_ENABLED

Der Sicherheits-Hub erfasst Sicherheitsdaten aus AWS-Konten, ‑Diensten und unterstützten Drittanbieterprodukten und hilft Ihnen, Sicherheitstrends zu analysieren und die Sicherheitsprobleme mit der höchsten Priorität zu identifizieren. Wenn Sie Security Hub aktivieren, werden Ergebnisse aus aktivierten AWS-Diensten wie Amazon GuardDuty, Amazon Inspector und Amazon Macie erfasst, zusammengefasst, organisiert und priorisiert. Sie können auch Integrationen mit Sicherheitsprodukten von AWS-Partnern aktivieren.

Empfehlung: Achten Sie darauf, dass AWS Security Hub aktiviert ist.

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

1. Melden Sie sich mit den Anmeldedaten der IAM-Identität in der Security Hub-Konsole an.
2. Wenn Sie die Security Hub-Konsole zum ersten Mal öffnen, wählen Sie „AWS Security Hub aktivieren“ aus.
3. Auf der Begrüßungsseite werden die Sicherheitsstandards aufgeführt, die von Security Hub unterstützt werden.
4. Wählen Sie „Security Hub aktivieren“ aus.

AWS-CLI

1. Führen Sie den Befehl „enable-security-hub“ aus. Wenn Sie die Standardstandards aktivieren möchten, geben Sie --enable-default-standards ein.

aws securityhub enable-security-hub --enable-default-standards

2. Wenn Sie den Sicherheitshub ohne die Standardstandards aktivieren möchten, geben Sie --no-enable-default-standards an.

aws securityhub enable-security-hub --no-enable-default-standards

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Cloudtrail Logs Encrypted Rest Using Kms Cmks

Kategoriename in der API: CLOUDTRAIL_LOGS_ENCRYPTED_REST_USING_KMS_CMKS

AWS CloudTrail ist ein Webdienst, der AWS API-Aufrufe für ein Konto aufzeichnet und diese Protokolle gemäß den IAM-Richtlinien für Nutzer und Ressourcen verfügbar macht. Der AWS Key Management Service (KMS) ist ein verwalteter Dienst, mit dem Sie die Verschlüsselungsschlüssel zum Verschlüsseln von Kontodaten erstellen und steuern können. Er verwendet Hardware Security Modules (HSMs), um die Sicherheit der Verschlüsselungsschlüssel zu schützen. CloudTrail-Protokolle können so konfiguriert werden, dass die serverseitige Verschlüsselung (Server-Side Encryption, SSE) und vom Kunden erstellte KMS-Masterschlüssel (Customer Managed Keys, CMK) verwendet werden, um CloudTrail-Protokolle weiter zu schützen. Wir empfehlen, CloudTrail für die Verwendung von SSE-KMS zu konfigurieren.

Empfehlung: CloudTrail-Logs im Ruhezustand mit KMS-CMKs verschlüsseln

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

1. Melden Sie sich in der AWS Management Console an und öffnen Sie die CloudTrail-Konsole unter https://console.aws.amazon.com/cloudtrail.
2. Wählen Sie im linken Navigationsbereich Trails aus .
3. Auf einen Trail klicken
4. Klicken Sie im Bereich S3 auf die Schaltfläche „Bearbeiten“ (Stiftsymbol).
5. Klicken Sie auf Advanced.
6. Wählen Sie im Drop-down-Menü KMS key Id einen vorhandenen CMEK aus
   . Hinweis: Der CMEK muss sich in derselben Region wie der S3-Bucket befinden.
   Hinweis: Sie müssen eine KMS-Schlüsselrichtlinie auf den ausgewählten CMEK anwenden, damit CloudTrail als Dienst Protokolldateien mit dem bereitgestellten CMEK verschlüsseln und entschlüsseln kann. Hier finden Sie eine Anleitung zum Bearbeiten der ausgewählten Richtlinie für CMEK-Schlüssel.
7. Klicken Sie auf Save.
8. Sie erhalten eine Benachrichtigung, dass Sie zum Entschlüsseln von Protokolldateien Entschlüsselungsberechtigungen für den angegebenen KMS-Schlüssel benötigen.
9. Klicken Sie auf Yes.

AWS-CLI

aws cloudtrail update-trail --name <trail_name> --kms-id <cloudtrail_kms_key>
aws kms put-key-policy --key-id <cloudtrail_kms_key> --policy <cloudtrail_kms_key_policy>

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Cloudtrail Log File Validation Enabled

Kategoriename in der API: CLOUDTRAIL_LOG_FILE_VALIDATION_ENABLED

Bei der Validierung von CloudTrail-Logdateien wird eine digital signierte Digestdatei mit einem Hashwert für jedes Protokoll erstellt, das CloudTrail in S3 schreibt. Anhand dieser Dateien lässt sich feststellen, ob eine Logdatei nach der Übermittlung durch CloudTrail geändert, gelöscht oder unverändert geblieben ist. Es wird empfohlen, die Dateivalidierung für alle CloudTrails zu aktivieren.

Empfehlung: Achten Sie darauf, dass die Validierung der CloudTrail-Logdatei aktiviert ist

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

1. Melden Sie sich in der AWS Management Console an und öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/cloudtrail.
2. Klicken Sie im linken Navigationsbereich auf Trails.
3. Klicken Sie auf den Zielpfad.
4. Klicken Sie im Abschnitt General details auf edit.
5. Im Abschnitt Advanced settings
6. Setzen Sie unter Log file validation ein Häkchen in das Kästchen „Aktivieren“.
7. Klicken Sie auf Save changes.

AWS-CLI

aws cloudtrail update-trail --name <trail_name> --enable-log-file-validation

Die regelmäßige Validierung von Protokollen mithilfe dieser Zusammenfassungen kann mit dem folgenden Befehl durchgeführt werden:

aws cloudtrail validate-logs --trail-arn <trail_arn> --start-time <start_time> --end-time <end_time>

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Cloudtrail Trails Integrated Cloudwatch Logs

Kategoriename in der API: CLOUDTRAIL_TRAILS_INTEGRATED_CLOUDWATCH_LOGS

AWS CloudTrail ist ein Webdienst, mit dem AWS API-Aufrufe in einem bestimmten AWS-Konto aufgezeichnet werden. Zu den aufgezeichneten Informationen gehören die Identität des API-Aufrufers, die Uhrzeit des API-Aufrufs, die Quell-IP-Adresse des API-Aufrufers, die Anfrageparameter und die Antwortelemente, die vom AWS-Dienst zurückgegeben werden. CloudTrail verwendet Amazon S3 für die Speicherung und Übermittlung von Protokolldateien. Protokolldateien werden daher dauerhaft gespeichert. Sie können CloudTrail-Logs nicht nur in einem bestimmten S3-Bucket für die langfristige Analyse erfassen, sondern auch Echtzeitanalysen durchführen, indem Sie CloudTrail so konfigurieren, dass Logs an CloudWatch-Logs gesendet werden. Wenn ein Pfad in allen Regionen eines Kontos aktiviert ist, sendet CloudTrail Protokolldateien aus allen diesen Regionen an eine CloudWatch Logs-Protokollgruppe. Wir empfehlen, CloudTrail-Logs an CloudWatch-Logs zu senden.

Hinweis: Mit dieser Empfehlung soll sichergestellt werden, dass AWS-Kontoaktivitäten erfasst, überwacht und ggf. entsprechend alarmiert werden. CloudWatch-Logs ist eine native Möglichkeit, dies mit AWS-Diensten zu erreichen, schließt aber die Verwendung einer alternativen Lösung nicht aus.

Empfehlung: CloudTrail-Pfade in CloudWatch-Logs einbinden

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

1. Melden Sie sich unter https://console.aws.amazon.com/cloudtrail/ in der CloudTrail Console an.
2. Wählen Sie die Trail aus, die aktualisiert werden soll.
3. Scrolle nach unten zu CloudWatch Logs.
4. Klicken Sie auf Edit.
5. Klicken Sie unter CloudWatch Logs auf das Kästchen Enabled.
6. Wählen Sie unter Log Group die Option „Neu“ oder eine vorhandene Protokollgruppe aus.
7. Bearbeiten Sie Log group name so, dass es mit CloudTrail übereinstimmt, oder wählen Sie die vorhandene CloudWatch-Gruppe aus.
8. Wählen Sie unter IAM Role die Option „Neu“ aus oder wählen Sie eine vorhandene Option aus.
9. Bearbeiten Sie die Role name so, dass sie mit CloudTrail übereinstimmt, oder wählen Sie die vorhandene IAM-Rolle aus.
10. Klicken Sie auf „Änderungen speichern“.

AWS-CLI

aws cloudtrail update-trail --name <trail_name> --cloudwatch-logs-log-group-arn <cloudtrail_log_group_arn> --cloudwatch-logs-role-arn <cloudtrail_cloudwatchLogs_role_arn>

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Cloudwatch Alarm Action Check

Kategoriename in der API: CLOUDWATCH_ALARM_ACTION_CHECK

Hier wird geprüft, ob für Amazon CloudWatch Aktionen definiert sind, wenn ein Alarm zwischen den Status „OK“, „ALARM“ und „INSUFFICIENT_DATA“ wechselt.

Es ist sehr wichtig, Aktionen für den ALARM-Status in Amazon CloudWatch-Benachrichtigungen zu konfigurieren, um eine sofortige Reaktion auszulösen, wenn die überwachten Messwerte Schwellenwerte überschreiten.
Sie sorgt für eine schnelle Problembehebung, reduziert Ausfallzeiten und ermöglicht eine automatisierte Behebung, um die Systemintegrität aufrechtzuerhalten und Ausfälle zu verhindern.

Alarme haben mindestens eine Aktion.
Alarme haben mindestens eine Aktion, wenn der Alarm von einem anderen Status in den Status „INSUFFICIENT_DATA“ wechselt.
Optional: Alarme haben mindestens eine Aktion, wenn der Alarm von einem anderen Status in den Status „OK“ wechselt.

Empfehlung: Prüfen Sie, ob für CloudWatch-Alarme mindestens eine Alarmaktion, eine INSUFFICIENT_DATA-Aktion oder eine OK-Aktion aktiviert ist.

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

So konfigurieren Sie ALARM-Aktionen für Ihre Amazon CloudWatch-Benachrichtigungen:

1. Öffnen Sie die Amazon CloudWatch-Konsole unter https://console.aws.amazon.com/cloudwatch/.
2. Wählen Sie im Navigationsbereich unter „Wecker“ die Option „Alle Wecker“ aus.
3. Wählen Sie den Amazon CloudWatch-Alarm aus, den Sie ändern möchten, klicken Sie auf „Aktionen“ und dann auf „Bearbeiten“.
4. Wählen Sie links „Schritt 2 – optional: Aktionen konfigurieren“ aus.
5. Wählen Sie für den „Weckerstatus-Trigger“ die Option „Wecker klingelt“ aus, um eine ALARM-basierte Aktion einzurichten.
6. Wenn Sie eine Benachrichtigung an ein neu erstelltes SNS-Thema senden möchten, wählen Sie „Neues Thema erstellen“ aus.
7. Geben Sie im Feld „Neues Thema erstellen…“ einen eindeutigen Namen für das SNS-Thema an.
8. Geben Sie im Feld „E-Mail-Endpunkte, die die Benachrichtigung erhalten“ mindestens eine E-Mail-Adresse an.
9. Wählen Sie dann „Topic erstellen“ aus, um das erforderliche Amazon SNS-Topic zu erstellen.
10. Wählen Sie rechts unten „Weiter“, „Weiter“ und dann „Wecker aktualisieren“ aus, um die Änderungen anzuwenden.
11. Öffnen Sie Ihren E-Mail-Client und klicken Sie in der E-Mail von AWS Notifications auf den Link, um das Abo des betreffenden SNS-Themas zu bestätigen.
12. Wiederholen Sie die Schritte 4 bis 11 und wählen Sie in Schritt 5 „OK“ und „Nicht genügend Daten“ für den „Alarmstatus-Trigger“ aus, um Aktionen für diese beiden Status einzurichten.
13. Wiederholen Sie den Vorgang für alle anderen CloudWatch-Benachrichtigungen in derselben AWS-Region.
14. Wiederholen Sie den Vorgang für alle anderen CloudWatch-Benachrichtigungen in allen anderen AWS-Regionen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Cloudwatch Log Group Encrypted

Kategoriename in der API: CLOUDWATCH_LOG_GROUP_ENCRYPTED

Mit dieser Prüfung wird sichergestellt, dass CloudWatch-Protokolle mit KMS konfiguriert sind.

Loggruppendaten werden in CloudWatch-Logs immer verschlüsselt. In CloudWatch Logs wird standardmäßig die serverseitige Verschlüsselung für inaktive Protokolldaten verwendet. Alternativ können Sie für diese Verschlüsselung den AWS Key Management Service verwenden. In diesem Fall erfolgt die Verschlüsselung mit einem AWS KMS-Schlüssel. Die Verschlüsselung mit AWS KMS wird auf Protokollgruppenebene aktiviert, indem Sie einer Protokollgruppe einen KMS-Schlüssel zuweisen, entweder beim Erstellen der Protokollgruppe oder danach.

Empfehlung: Prüfen Sie, ob alle Loggruppen in Amazon CloudWatch-Logs mit KMS verschlüsselt sind

Weitere Informationen finden Sie im Amazon CloudWatch-Benutzerhandbuch unter Logdaten in CloudWatch-Logs mit AWS Key Management Service verschlüsseln.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

CloudTrail CloudWatch Logs Enabled

Kategoriename in der API: CLOUD_TRAIL_CLOUD_WATCH_LOGS_ENABLED

Mit dieser Einstellung wird geprüft, ob CloudTrail-Pfade so konfiguriert sind, dass Protokolle an CloudWatch-Logs gesendet werden. Die Prüfung schlägt fehl, wenn die Eigenschaft „CloudWatchLogsLogGroupArn“ des Logs leer ist.

CloudTrail zeichnet AWS API-Aufrufe auf, die in einem bestimmten Konto getätigt werden. Zu den aufgezeichneten Informationen gehören:

• Die Identität des API-Aufrufers
• Zeitpunkt des API-Aufrufs
• Die Quell-IP-Adresse des API-Aufrufers
• Anfrageparameter
• Die vom AWS-Dienst zurückgegebenen Antwortelemente

CloudTrail verwendet Amazon S3 für die Speicherung und Übermittlung von Protokolldateien. Sie können CloudTrail-Protokolle zur langfristigen Analyse in einem bestimmten S3-Bucket erfassen. Wenn Sie eine Echtzeitanalyse durchführen möchten, können Sie CloudTrail so konfigurieren, dass Protokolle an CloudWatch Logs gesendet werden.

Wenn ein Pfad in allen Regionen eines Kontos aktiviert ist, sendet CloudTrail Protokolldateien aus allen diesen Regionen an eine CloudWatch Logs-Protokollgruppe.

Security Hub empfiehlt, CloudTrail-Logs an CloudWatch-Logs zu senden. Diese Empfehlung soll dafür sorgen, dass Kontoaktivitäten erfasst, überwacht und bei Bedarf entsprechend alarmiert werden. Sie können CloudWatch-Logs verwenden, um dies mit Ihren AWS-Diensten einzurichten. Diese Empfehlung schließt die Verwendung einer anderen Lösung nicht aus.

Wenn Sie CloudTrail-Logs an CloudWatch-Logs senden, können Sie Echtzeit- und Verlaufsprotokolle nach Nutzer, API, Ressource und IP-Adresse erfassen. So können Sie Benachrichtigungen für ungewöhnliche oder sensible Kontoaktivitäten einrichten.

Empfehlung: Prüfen Sie, ob alle CloudTrail-Pfade für das Senden von Logs an AWS CloudWatch konfiguriert sind

Informationen zum Einbinden von CloudTrail in CloudWatch-Logs finden Sie im AWS CloudTrail-Benutzerhandbuch unter Ereignisse an CloudWatch-Logs senden.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

No AWS Credentials in CodeBuild Project Environment Variables

Kategoriename in der API: CODEBUILD_PROJECT_ENVVAR_AWSCRED_CHECK

Hier wird geprüft, ob das Projekt die Umgebungsvariablen AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY enthält.

Authentifizierungsdaten AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY sollten niemals als Klartext gespeichert werden, da dies zu einer unbeabsichtigten Datenpanne und zu unbefugten Zugriffen führen kann.

Empfehlung: Prüft, ob alle Projekte, die die Umgebungsvariablen AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY enthalten, nicht im Klartext vorliegen

Informationen zum Entfernen von Umgebungsvariablen aus einem CodeBuild-Projekt finden Sie im AWS CodeBuild-Benutzerhandbuch unter Einstellungen eines Build-Projekts in AWS CodeBuild ändern. Achten Sie darauf, dass für „Umgebungsvariablen“ nichts ausgewählt ist.

Sie können Umgebungsvariablen mit vertraulichen Werten im AWS Systems Manager Parameter Store oder im AWS Secrets Manager speichern und dann aus Ihrer Build-Spezifikation abrufen. Eine Anleitung finden Sie im Abschnitt „Umgebung“ der AWS CodeBuild-Nutzeranleitung im Feld „Wichtig“.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Codebuild Project Source Repo Url Check

Kategoriename in der API: CODEBUILD_PROJECT_SOURCE_REPO_URL_CHECK

Hier wird geprüft, ob die URL des Bitbucket-Quellrepositories eines AWS CodeBuild-Projekts persönliche Zugriffstokens oder einen Nutzernamen und ein Passwort enthält. Die Prüfung schlägt fehl, wenn die URL des Bitbucket-Quell-Repositories persönliche Zugriffstokens oder einen Nutzernamen und ein Passwort enthält.

Anmeldedaten dürfen nicht im Klartext gespeichert oder übertragen werden und dürfen nicht in der URL des Quell-Repositorys erscheinen. Anstatt persönliche Zugriffstokens oder Anmeldedaten sollten Sie in CodeBuild auf Ihren Quellanbieter zugreifen und die URL des Quell-Repositories so ändern, dass sie nur den Pfad zum Bitbucket-Repository-Speicherort enthält. Die Verwendung von persönlichen Zugriffstokens oder Anmeldedaten kann zu unbeabsichtigter Datenpufferung oder unbefugtem Zugriff führen.

Empfehlung: Prüft, ob alle Projekte, die GitHub oder Bitbucket als Quelle nutzen, OAuth verwenden

Sie können Ihr CodeBuild-Projekt so aktualisieren, dass OAuth verwendet wird.

Grundlegende Authentifizierung/persönliches Zugriffstoken (GitHub) aus der CodeBuild-Projektquelle entfernen

1. Öffnen Sie die CodeBuild-Konsole unter https://console.aws.amazon.com/codebuild/.
2. Wählen Sie das Build-Projekt aus, das persönliche Zugriffstokens oder einen Nutzernamen und ein Passwort enthält.
3. Wählen Sie unter „Bearbeiten“ die Option „Quelle“ aus.
4. Wählen Sie „Verbindung zu GitHub / Bitbucket trennen“ aus.
5. Wählen Sie „Über OAuth verbinden“ und dann „Verbindung zu GitHub / Bitbucket herstellen“ aus.
6. Wählen Sie bei entsprechender Aufforderung „Autorisieren“ aus.
7. Konfigurieren Sie bei Bedarf die Repository-URL und die zusätzlichen Konfigurationseinstellungen neu.
8. Wählen Sie „Quelle aktualisieren“ aus.

Weitere Informationen finden Sie im AWS CodeBuild-Nutzerhandbuch unter CodeBuild-Beispiele für Anwendungsfälle.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Credentials Unused 45 Days Greater Disabled

Kategoriename in der API: CREDENTIALS_UNUSED_45_DAYS_GREATER_DISABLED

AWS IAM-Nutzer können mit verschiedenen Anmeldedaten wie Passwörtern oder Zugriffsschlüsseln auf AWS-Ressourcen zugreifen. Wir empfehlen, alle Anmeldedaten zu deaktivieren oder zu entfernen, die seit mindestens 45 Tagen nicht verwendet wurden.

Empfehlung: Achten Sie darauf, dass Anmeldedaten, die seit mindestens 45 Tagen nicht verwendet wurden, deaktiviert werden

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

So verwalten Sie das nicht verwendete Passwort (Console-Zugriff für IAM-Nutzer):

1. Melden Sie sich in der AWS Management Console an:
2. Klicken Sie auf Services.
3. Klicken Sie auf IAM.
4. Klicken Sie auf Users.
5. Klicken Sie auf Security Credentials.
6. Nutzer auswählen, deren Console last sign-in länger als 45 Tage ist
7. Klicken Sie auf Security credentials.
8. Klicken Sie im Abschnitt Sign-in credentials auf Console passwordManage.
9. Wählen Sie unter „Console Access“ (Konsolenzugriff) die Option Disable
   aus. 10. Klicken Sie auf Apply.

So deaktivieren Sie Zugriffsschlüssel:

1. Melden Sie sich in der AWS Management Console an:
2. Klicken Sie auf Services.
3. Klicken Sie auf IAM.
4. Klicken Sie auf Users.
5. Klicken Sie auf Security Credentials.
6. Wählen Sie alle Zugriffsschlüssel aus, die älter als 45 Tage sind und verwendet wurden, und
   - klicken Sie auf Make Inactive.
7. Wählen Sie alle Zugriffsschlüssel aus, die älter als 45 Tage sind und nicht verwendet wurden, und
   - klicken Sie auf das „X“ zu Delete.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Default Security Group Vpc Restricts All Traffic

Kategoriename in der API: DEFAULT_SECURITY_GROUP_VPC_RESTRICTS_ALL_TRAFFIC

Eine VPC wird mit einer Standardsicherheitsgruppe geliefert, deren anfängliche Einstellungen den gesamten eingehenden Traffic ablehnen, den gesamten ausgehenden Traffic zulassen und den gesamten Traffic zwischen den der Sicherheitsgruppe zugewiesenen Instanzen zulassen. Wenn Sie beim Starten einer Instanz keine Sicherheitsgruppe angeben, wird die Instanz automatisch dieser Standardsicherheitsgruppe zugewiesen. Sicherheitsgruppen ermöglichen die zustandsabhängige Filterung von ein- und ausgehendem Netzwerkverkehr zu AWS-Ressourcen. Es wird empfohlen, dass die Standardsicherheitsgruppe den gesamten Traffic einschränkt.

Die Standardsicherheitsgruppe der Standard-VPC in jeder Region muss entsprechend aktualisiert werden. Alle neu erstellten VPCs enthalten automatisch eine Standardsicherheitsgruppe, die korrigiert werden muss, um dieser Empfehlung zu entsprechen.

HINWEIS:Bei der Implementierung dieser Empfehlung ist die VPC-Flussinstanz-Protokollierung von unschätzbarem Wert, um den Portzugriff mit den geringsten Berechtigungen zu ermitteln, der für die ordnungsgemäße Funktion der Systeme erforderlich ist. Denn damit können alle Pakete akzeptiert und abgelehnt werden, die in den aktuellen Sicherheitsgruppen auftreten. Dadurch wird die Hauptbarriere für die Zugriffssteuerung nach dem Prinzip der geringsten Berechtigung erheblich reduziert: die Ermittlung der Mindestanzahl von Ports, die von den Systemen in der Umgebung benötigt werden. Auch wenn die Empfehlung für die VPC-Flussisolierung in diesem Benchmark nicht als dauerhafte Sicherheitsmaßnahme übernommen wird, sollte sie während der gesamten Phase der Ermittlung und Entwicklung für Sicherheitsgruppen mit den geringsten Berechtigungen verwendet werden.

Empfehlung: Achten Sie darauf, dass die Standardsicherheitsgruppe jeder VPC den gesamten Traffic einschränkt

Mitglieder der Sicherheitsgruppe

So implementieren Sie den vorgeschriebenen Zustand:

1. AWS-Ressourcen in der Standardsicherheitsgruppe ermitteln
2. Erstellen Sie eine Reihe von Sicherheitsgruppen mit den geringsten Berechtigungen für diese Ressourcen.
3. Ressourcen in diese Sicherheitsgruppen platzieren
4. Entfernen Sie die unter 1 aufgeführten Ressourcen aus der Standardsicherheitsgruppe.

Status der Sicherheitsgruppe

1. Melden Sie sich unter https://console.aws.amazon.com/vpc/home in der AWS Management Console an.
2. Wiederholen Sie die folgenden Schritte für alle VPCs, einschließlich des Standard-VPC in jeder AWS-Region:
3. Klicken Sie im linken Bereich auf Security Groups.
4. Führen Sie für jede Standardsicherheitsgruppe die folgenden Schritte aus:
5. Wählen Sie die Sicherheitsgruppe default aus.
6. Klicken Sie auf den Tab Inbound Rules.
7. Alle Regeln für eingehende Anrufe entfernen
8. Klicken Sie auf den Tab Outbound Rules.
9. Entfernen Sie alle ausgehenden Regeln.

Empfohlen:

Bei IAM-Gruppen können Sie das Feld „name“ bearbeiten. Nachdem Sie die Standardgruppenregeln für alle VPCs in allen Regionen korrigiert haben, bearbeiten Sie dieses Feld und fügen Sie Text wie „NICHT VERWENDEN“ hinzu. FÜGEN SIE KEINE REGELN HINZ.“

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Dms Replication Not Public

Kategoriename in der API: DMS_REPLICATION_NOT_PUBLIC

Prüft, ob AWS DMS-Replikationsinstanzen öffentlich sind. Dazu wird der Wert des Felds PubliclyAccessible geprüft.

Eine private Replikationsinstanz hat eine private IP-Adresse, auf die Sie nicht außerhalb des Replikationsnetzwerks zugreifen können. Eine Replikationsinstanz sollte eine private IP-Adresse haben, wenn sich die Quell- und Zieldatenbanken im selben Netzwerk befinden. Das Netzwerk muss außerdem über ein VPN, AWS Direct Connect oder VPC-Peering mit dem VPC der Replikationsinstanz verbunden sein. Weitere Informationen zu öffentlichen und privaten Replikationsinstanzen finden Sie im Benutzerhandbuch für AWS Database Migration Service unter Öffentliche und private Replikationsinstanzen.

Außerdem sollten Sie dafür sorgen, dass der Zugriff auf die Konfiguration Ihrer AWS DMS-Instanz nur autorisierten Nutzern gewährt wird. Dazu müssen Sie die IAM-Berechtigungen der Nutzer einschränken, damit sie die AWS DMS-Einstellungen und ‑Ressourcen nicht ändern können.

Empfehlung: Prüfen Sie, ob Replikationsinstanzen von AWS Database Migration Service öffentlich sind

Die Einstellung für den öffentlichen Zugriff für eine DMS-Replikationsinstanz kann nach dem Erstellen nicht mehr geändert werden. Wenn Sie die Einstellung für den öffentlichen Zugriff ändern möchten, löschen Sie die aktuelle Instanz und erstellen Sie sie dann neu. Wählen Sie nicht die Option „Öffentlich zugänglich“ aus.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Do Setup Access Keys During Initial User Setup All Iam Users Console

Kategoriename in der API: DO_SETUP_ACCESS_KEYS_DURING_INITIAL_USER_SETUP_ALL_IAM_USERS_CONSOLE

In der AWS-Konsole sind beim Erstellen eines neuen IAM-Nutzers standardmäßig keine Kästchen angeklickt. Wenn Sie die IAM-Nutzeranmeldedaten erstellen, müssen Sie festlegen, welche Art von Zugriff erforderlich ist.

Programmzugriff: Der IAM-Nutzer muss möglicherweise API-Aufrufe ausführen, die AWS CLI oder die Tools für Windows PowerShell verwenden. Erstellen Sie in diesem Fall einen Zugriffsschlüssel (Zugriffsschlüssel-ID und geheimer Zugriffsschlüssel) für diesen Nutzer.

Zugriff auf die AWS Management Console: Wenn der Nutzer auf die AWS Management Console zugreifen muss, erstellen Sie ein Passwort für ihn.

Empfehlung: Richten Sie während der anfänglichen Nutzereinrichtung für alle IAM-Nutzer, die ein Console-Passwort haben, keine Zugriffsschlüssel ein.

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

1. Melden Sie sich in der AWS Management Console an:
2. Klicken Sie auf Services.
3. Klicken Sie auf IAM.
4. Klicken Sie auf Users.
5. Klicken Sie auf Security Credentials.
6. Als Administrator
    – Klicken Sie auf das „X“ (Delete) für Schlüssel, die gleichzeitig mit dem Nutzerprofil erstellt, aber nicht verwendet wurden.
7. Als IAM-Nutzer
    – Klicke auf das „X“ (Delete) für Schlüssel, die gleichzeitig mit dem Nutzerprofil erstellt, aber nicht verwendet wurden.

AWS-CLI

aws iam delete-access-key --access-key-id <access-key-id-listed> --user-name <users-name>

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Dynamodb Autoscaling Enabled

Kategoriename in der API: DYNAMODB_AUTOSCALING_ENABLED

Hier wird geprüft, ob die Lese- und Schreibkapazität einer Amazon DynamoDB-Tabelle nach Bedarf skaliert werden kann. Dieser Steuerelemente wird übergeben, wenn für die Tabelle entweder der On-Demand-Kapazitätsmodus oder der bereitgestellte Modus mit konfiguriertem Autoscaling verwendet wird. Wenn Sie die Kapazität an die Nachfrage anpassen, werden Drosselungsausnahmen vermieden, was die Verfügbarkeit Ihrer Anwendungen aufrechterhält.

DynamoDB-Tabellen im Modus „On-Demand-Kapazität“ sind nur durch die Standardtabellenkontingente für den DynamoDB-Durchsatz begrenzt. Wenn Sie diese Kontingente erhöhen möchten, können Sie über den AWS-Support ein Support-Ticket einreichen.

Bei DynamoDB-Tabellen im bereitgestellten Modus mit automatischer Skalierung wird die bereitgestellte Durchsatzkapazität dynamisch an die Verkehrsmuster angepasst. Weitere Informationen zur Drosselung von DynamoDB-Anfragen finden Sie im Amazon DynamoDB Developer Guide unter „Anfragedrosselung und Burst-Kapazität“.

Empfehlung: DynamoDB-Tabellen sollten die Kapazität gemäß Nachfrage automatisch skalieren

Eine ausführliche Anleitung zum Aktivieren der automatischen DynamoDB-Skalierung für vorhandene Tabellen im Kapazitätsmodus finden Sie im Amazon DynamoDB Developer Guide unter Enabling DynamoDB auto scaling on existing tables (Automatische DynamoDB-Skalierung für vorhandene Tabellen aktivieren).

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Dynamodb In Backup Plan

Kategoriename in der API: DYNAMODB_IN_BACKUP_PLAN

Mit dieser Prüfung wird ermittelt, ob für eine DynamoDB-Tabelle ein Sicherungsplan vorhanden ist. Die Prüfung schlägt fehl, wenn für eine DynamoDB-Tabelle kein Sicherungsplan vorhanden ist. Mit dieser Einstellung werden nur DynamoDB-Tabellen ausgewertet, die den Status „AKTIV“ haben.

Mithilfe von Sicherungen können Sie sich nach einem Sicherheitsvorfall schneller erholen. Außerdem erhöhen sie die Ausfallsicherheit Ihrer Systeme. Wenn Sie DynamoDB-Tabellen in einen Sicherungsplan aufnehmen, können Sie Ihre Daten vor unbeabsichtigtem Verlust oder Löschen schützen.

Empfehlung: Für DynamoDB-Tabellen sollte es einen Sicherungsplan geben

Informationen zum Hinzufügen einer DynamoDB-Tabelle zu einem AWS Backup-Sicherungsplan finden Sie im AWS Backup-Entwicklerleitfaden unter Ressourcen einem Sicherungsplan zuweisen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Dynamodb Pitr Enabled

Kategoriename in der API: DYNAMODB_PITR_ENABLED

Die Wiederherstellung zu einem bestimmten Zeitpunkt (Point-In-Time-Recovery, PITR) ist einer der Mechanismen, mit denen DynamoDB-Tabellen gesichert werden können.

Eine Sicherung eines bestimmten Zeitpunkts wird 35 Tage lang aufbewahrt. Wenn Sie eine längere Aufbewahrungsdauer benötigen, lesen Sie den Artikel Geplante Sicherungen für Amazon DynamoDB mit AWS Backup einrichten in der AWS-Dokumentation.

Empfehlung: Prüfen Sie, ob die Wiederherstellung zu einem bestimmten Zeitpunkt für alle AWS DynamoDB-Tabellen aktiviert ist

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

Terraform

Um die PITR für DynamoDB-Tabellen festzulegen, legen Sie den Block point_in_time_recovery fest:

resource "aws_dynamodb_table" "example" {
  # ... other configuration ...
  point_in_time_recovery {
    enabled = true
  }
}

AWS-Konsole

Wiederherstellung zu einem bestimmten Zeitpunkt für eine vorhandene DynamoDB-Tabelle aktivieren

1. Öffnen Sie die DynamoDB-Konsole unter https://console.aws.amazon.com/dynamodb/.
2. Wählen Sie die Tabelle aus, mit der Sie arbeiten möchten, und dann „Sicherungen“.
3. Wählen Sie im Bereich „Wiederherstellung zu einem bestimmten Zeitpunkt“ unter „Status“ die Option „Aktivieren“ aus.
4. Wählen Sie noch einmal „Aktivieren“ aus, um die Änderung zu bestätigen.

AWS-CLI

aws dynamodb update-continuous-backups \
  --table-name "GameScoresOnDemand" \
  --point-in-time-recovery-specification "PointInTimeRecoveryEnabled=true"

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Dynamodb Table Encrypted Kms

Kategoriename in der API: DYNAMODB_TABLE_ENCRYPTED_KMS

Prüft, ob alle DynamoDB-Tabellen mit einem vom Kunden verwalteten KMS-Schlüssel (nicht standardmäßig) verschlüsselt sind.

Empfehlung: Prüft, ob alle DynamoDB-Tabellen mit AWS Key Management Service (KMS) verschlüsselt sind

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

Terraform

Erstellen Sie einen AWS KMS-Schlüssel und verschlüsseln Sie damit die DynamoDB-Ressource, die gegen diese Anforderung verstößt.

resource "aws_kms_key" "dynamodb_encryption" {
  description         = "Used for DynamoDB encryption configuration"
  enable_key_rotation = true
}

resource "aws_dynamodb_table" "example" {
  # ... other configuration ...
  server_side_encryption {
    enabled     = true
    kms_key_arn = aws_kms_key.dynamodb_encryption.arn
  }
}

AWS-Konsole

Es wird davon ausgegangen, dass ein AWS KMS-Schlüssel zum Verschlüsseln von DynamoDB vorhanden ist.

So ändern Sie die Verschlüsselung einer DynamoDB-Tabelle in einen vom Kunden verwalteten und vom Kunden selbst erstellten KMS-Schlüssel.

1. Öffnen Sie die DynamoDB-Konsole unter https://console.aws.amazon.com/dynamodb/.
2. Wählen Sie die Tabelle aus, mit der Sie arbeiten möchten, und dann „Zusätzliche Einstellungen“.
3. Wählen Sie unter „Verschlüsselung“ die Option „Verschlüsselung verwalten“ aus.
4. Wählen Sie für die Verschlüsselung inaktiver Daten die Option „In Ihrem Konto gespeichert und von Ihnen verwaltet“ aus.
5. Wählen Sie den zu verwendenden AWS-Schlüssel aus. Speichern Sie die Änderungen.

AWS-CLI

aws dynamodb update-table \
  --table-name <value> \
  --sse-specification "Enabled=true,SSEType=KMS,KMSMasterKeyId=<kms_key_arn>"

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Ebs Optimized Instance

Kategoriename in der API: EBS_OPTIMIZED_INSTANCE

Prüfen Sie, ob die EBS-Optimierung für Ihre EC2-Instanzen aktiviert ist, die EBS-optimiert werden können

Empfehlung: Prüfen Sie, ob die EBS-Optimierung für alle Instanzen aktiviert ist, die diese unterstützen.

Informationen zum Konfigurieren der Einstellungen für EBS-optimierte Instanzen finden Sie im Amazon EC2-Benutzerhandbuch unter Amazon EBS-optimierte Instanzen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Ebs Snapshot Public Restorable Check

Kategoriename in der API: EBS_SNAPSHOT_PUBLIC_RESTORABLE_CHECK

Prüft, ob Amazon Elastic Block Store-Snapshots nicht öffentlich sind. Die Prüfung schlägt fehl, wenn Amazon EBS-Snapshots von allen wiederhergestellt werden können.

Mit EBS-Snapshots werden die Daten auf Ihren EBS-Volumes zu einem bestimmten Zeitpunkt in Amazon S3 gesichert. Mit den Snapshots können Sie vorherige Zustände von EBS-Volumes wiederherstellen. Es ist selten akzeptabel, einen Snapshot der Öffentlichkeit zugänglich zu machen. In der Regel wurde die Entscheidung, einen Snapshot öffentlich zu teilen, irrtümlich oder ohne vollständige Kenntnis der Auswirkungen getroffen. So wird sichergestellt, dass alle entsprechenden Freigaben geplant und beabsichtigt waren.

Empfehlung: Amazon EBS-Snapshots sollten nicht öffentlich wiederherstellbar sein

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

Aktualisieren Sie Ihren EBS-Snapshot, um das Problem zu beheben. Er muss privat und nicht öffentlich sein.

So machen Sie einen öffentlichen EBS-Snapshot privat:

1. Öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/.
2. Wählen Sie im Navigationsbereich unter „Elastic Block Store“ das Menü „Snapshots“ und dann Ihren öffentlichen Snapshot aus.
3. Wählen Sie unter „Aktionen“ die Option „Berechtigungen ändern“ aus.
4. Wählen Sie „Privat“ aus.
5. Optional: Fügen Sie die AWS-Kontonummern der autorisierten Konten hinzu, für die Sie den Snapshot freigeben möchten, und wählen Sie „Berechtigung hinzufügen“ aus.
6. Wählen Sie „Speichern“ aus.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Ebs Volume Encryption Enabled All Regions

Kategoriename in der API: EBS_VOLUME_ENCRYPTION_ENABLED_ALL_REGIONS

Elastic Compute Cloud (EC2) unterstützt die Ruhedatenverschlüsselung bei Verwendung des Elastic Block Store (EBS)-Dienstes. Die Erzwingung der Verschlüsselung beim Erstellen eines EBS-Volumes ist zwar standardmäßig deaktiviert, wird aber unterstützt.

Empfehlung: Achten Sie darauf, dass die EBS-Volume-Verschlüsselung in allen Regionen aktiviert ist

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

1. Melden Sie sich in der AWS Management Console an und öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/.
2. Klicken Sie unter Account attributes auf EBS encryption.
3. Klicken Sie auf Manage.
4. Klicken Sie auf das Kästchen Enable.
5. Klicken Sie auf Update EBS encryption.
6. Wiederholen Sie diesen Schritt für jede Region, für die die Änderung erforderlich ist.

Hinweis:Die EBS-Volume-Verschlüsselung wird pro Region konfiguriert.

AWS-CLI

1. Ausführen

aws --region <region> ec2 enable-ebs-encryption-by-default

2. Prüfen Sie, ob "EbsEncryptionByDefault": true angezeigt wird.
3. Wiederholen Sie diesen Vorgang für alle Regionen, in denen die Änderung erforderlich ist.

Hinweis:Die EBS-Volume-Verschlüsselung wird pro Region konfiguriert.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Ec2 Instances In Vpc

Kategoriename in der API: EC2_INSTANCES_IN_VPC

Amazon VPC bietet mehr Sicherheitsfunktionen als EC2 Classic. Es wird empfohlen, dass alle Knoten zu einer Amazon VPC gehören.

Empfehlung: Achten Sie darauf, dass alle Instanzen zu einer VPC gehören

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

Terraform

Wenn Sie in Terraform EC2 Classic-Instanzen definiert haben, können Sie Ihre Ressourcen so ändern, dass sie zu einer VPC gehören. Diese Migration hängt von einer Architektur ab, die Ihren Anforderungen am besten entspricht. Im Folgenden finden Sie ein einfaches Terraform-Beispiel für eine öffentlich zugängliche EC2-Instanz in einer VPC.

  resource "aws_vpc" "example_vpc" {
    cidr_block = "10.0.0.0/16"
  }

  resource "aws_subnet" "example_public_subnet" {
    vpc_id            = aws_vpc.example_vpc.id
    cidr_block        = "10.0.1.0/24"
    availability_zone = "1a"
  }

  resource "aws_internet_gateway" "example_igw" {
    vpc_id = aws_vpc.example_vpc.id
  }

  resource "aws_key_pair" "example_key" {
    key_name   = "web-instance-key"
    public_key = "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD3F6tyPEFEzV0LX3X8BsXdMsQz1x2cEikKDEY0aIj41qgxMCP/iteneqXSIFZBp5vizPvaoIR3Um9xK7PGoW8giupGn+EPuxIA4cDM4vzOqOkiMPhz5XK0whEjkVzTo4+S0puvDZuwIsdiW9mxhJc7tgBNL0cYlWSYVkz4G/fslNfRPW5mYAM49f4fhtxPb5ok4Q2Lg9dPKVHO/Bgeu5woMc7RY0p1ej6D4CKFE6lymSDJpW0YHX/wqE9+cfEauh7xZcG0q9t2ta6F6fmX0agvpFyZo8aFbXeUBr7osSCJNgvavWbM/06niWrOvYX2xwWdhXmXSrbX8ZbabVohBK41 [e-mail]"
  }

  resource "aws_security_group" "web_sg" {
    name   = "http and ssh"
    vpc_id = aws_vpc.some_custom_vpc.id

    ingress {
      from_port   = 80
      to_port     = 80
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    }

    ingress {
      from_port   = 22
      to_port     = 22
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    }

    egress {
      from_port   = 0
      to_port     = 0
      protocol    = -1
      cidr_blocks = ["0.0.0.0/0"]
    }
  }

  resource "aws_instance" "web" {
    ami                    = <ami_id>
    instance_type          = <instance_flavor>
    key_name               = aws_key_pair.example_key.name
    monitoring             = true
    subnet_id              = aws_subnet.example_public_subnet.id
    vpc_security_group_ids = [aws_security_group.web_sg.id]
    metadata_options {
      http_tokens = "required"
    }
  }

AWS-Konsole

Informationen zur Migration von EC2 Classic zu VPC finden Sie unter Von EC2 Classic zu einer VPC migrieren.

AWS-CLI

Dieses AWS CLI-Beispiel zeigt dieselbe Infrastruktur, die mit Terraform definiert wurde. Es ist ein einfaches Beispiel für eine öffentlich zugängliche EC2-Instanz in einer VPC.

VPC erstellen

  aws ec2 create-vpc \
  --cidr-block 10.0.0.0/16

Öffentliches Subnetz erstellen

  aws ec2 create-subnet \
  --availability-zone 1a \
  --cidr-block 10.0.1.0/24 \
  --vpc-id <id_from_create-vpc_command>

Internetgateway erstellen

  aws ec2 create-internet-gateway

Internetgateway an VPC anhängen

  aws ec2 attach-internet-gateway \
  --internet-gateway-id <id_from_create-internet-gateway_command> \
  --vpc-id <id_from_create-vpc_command>

Schlüsselpaar erstellen: Ihr privater Schlüssel wird in /.ssh/web-instance-key.pem gespeichert.

  aws ec2 create-key-pair \
  --key-name web-instance-key \
  --query "KeyMaterial" \
  --output text > ~/.ssh/web-instance-key.pem && \
  chmod 400 ~/.ssh/web-instance-key.pem

Sicherheitsgruppe erstellen

  aws ec2 create-security-group \
  --group-name "http and ssh" \
  --vpc-id <id_from_create-vpc_command>

Sicherheitsgruppenregeln erstellen: Für einen eingeschränkteren Zugriff eine eingeschränktere CIDR für SSH auf Port 22 definieren

  aws ec2 authorize-security-group-ingress \
  --group-id <id_from_create-security-group_command>
  --protocol tcp \
  --port 80 \
  --cidr 0.0.0.0/0

  aws ec2 authorize-security-group-ingress \
  --group-id <id_from_create-security-group_command>
  --protocol tcp \
  --port 22 \
  --cidr 0.0.0.0/0

  aws ec2 authorize-security-group-egress \
  --group-id <id_from_create-security-group_command>
  --protocol -1 \
  --port 0 \
  --cidr 0.0.0.0/0

EC2-Instanz erstellen

  aws ec2 run-instances \
  --image-id <ami_id> \
  --instance-type <instance_flavor> \
  --metadata-options "HttpEndpoint=enabled,HttpTokens=required" \
  --monitoring true \
  --key-name web-instance-key \
  --subnet-id <id_from_create-subnet_command> \
  --security-group-ids <id_from_create-security-group_command>

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Ec2 Instance No Public Ip

Kategoriename in der API: EC2_INSTANCE_NO_PUBLIC_IP

Bei EC2-Instanzen mit einer öffentlichen IP-Adresse besteht ein erhöhtes Risiko von Manipulationen. Es wird empfohlen, EC2-Instanzen nicht mit einer öffentlichen IP-Adresse zu konfigurieren.

Empfehlung: Achten Sie darauf, dass keine Instanz eine öffentliche IP-Adresse hat

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

Terraform

Verwenden Sie das Argument associate_public_ip_address = false mit der Ressource aws_instance, damit EC2-Instanzen ohne öffentliche IP-Adresse bereitgestellt werden

resource "aws_instance" "no_public_ip" {
  ...
  associate_public_ip_address = false
}

AWS-Konsole

Standardmäßig ist das Attribut „IPv4-öffentliche Adressierung“ für nicht standardmäßige Subnetze auf „false“ und für standardmäßige Subnetze auf „true“ festgelegt. Eine Ausnahme ist ein nicht standardmäßiges Subnetz, das vom Amazon EC2-Startassistenten für Instanzen erstellt wurde. In diesem Fall wird das Attribut auf „wahr“ gesetzt. Sie können dieses Attribut über die Amazon VPC-Konsole ändern.

So ändern Sie das Verhalten der öffentlichen IPv4-Adressierung Ihres Subnetzes

1. Öffnen Sie die Amazon VPC-Konsole unter https://console.aws.amazon.com/vpc/.
2. Wählen Sie im Navigationsbereich Subnetze aus.
3. Wählen Sie Ihr Subnetz und dann Aktionen > Subnetzeinstellungen bearbeiten aus.
4. Wenn das Kästchen Automatische Zuweisung öffentlicher IPv4-Adresse aktivieren angeklickt ist, wird für alle Instanzen, die im ausgewählten Subnetz gestartet werden, eine öffentliche IPv4-Adresse angefordert. Setzen oder entfernen Sie bei Bedarf ein Häkchen im Kästchen und wählen Sie dann Speichern aus.

AWS-CLI

Mit dem folgenden Befehl wird eine EC2-Instanz in einem Standardsubnetz ausgeführt, ohne dass ihr eine öffentliche IP-Adresse zugewiesen wird.

aws ec2 run-instances \
--image-id <ami_id> \
--instance-type <instance_flavor> \
--no-associate-public-ip-address \
--key-name MyKeyPair

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Ec2 Managedinstance Association Compliance Status Check

Kategoriename in der API: EC2_MANAGEDINSTANCE_ASSOCIATION_COMPLIANCE_STATUS_CHECK

Eine Verknüpfung mit dem State Manager ist eine Konfiguration, die Ihren verwalteten Instanzen zugewiesen wird. In der Konfiguration wird der Status definiert, der auf Ihren Instanzen beibehalten werden soll. Eine Verknüpfung kann beispielsweise angeben, dass Antivirensoftware auf Ihren Instanzen installiert und ausgeführt werden muss oder dass bestimmte Ports geschlossen sein müssen. EC2-Instanzen, die mit AWS Systems Manager verknüpft sind, werden von Systems Manager verwaltet. Dadurch können Sie leichter Patches anwenden, Fehlkonfigurationen beheben und auf Sicherheitsereignisse reagieren.

Empfehlung: Prüfen Sie den Compliancestatus der AWS Systems Manager-Verknüpfung

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

Terraform

Im folgenden Beispiel wird gezeigt, wie Sie eine einfache EC2-Instanz, ein AWS Systems Manager-Dokument (SSM) und eine Verknüpfung zwischen SSM und der EC2-Instanz erstellen. Unterstützt werden Dokumente vom Typ Command und Policy.

resource "aws_instance" "web" {
  ami           = "<iam_id>"
  instance_type = "<instance_flavor>"
}

resource "aws_ssm_document" "check_ip" {
  name          = "check-ip-config"
  document_type = "Command"

  content = <<DOC
  {
    "schemaVersion": "1.2",
    "description": "Check ip configuration of a Linux instance.",
    "parameters": {

    },
    "runtimeConfig": {
      "aws:runShellScript": {
        "properties": [
          {
            "id": "0.aws:runShellScript",
            "runCommand": ["ifconfig"]
          }
        ]
      }
    }
  }
DOC
}

resource "aws_ssm_association" "check_ip_association" {
  name = aws_ssm_document.check_ip.name

  targets {
    key    = "InstanceIds"
    values = [aws_instance.web.id]
  }
}

AWS-Konsole

Informationen zum Konfigurieren von Verknüpfungen mit AWS Systems Manager über die Console finden Sie in der AWS Systems Manager-Dokumentation unter Verknüpfungen erstellen.

AWS-CLI

SSM-Dokument erstellen

aws ssm create-document \
--name <document_name> \
--content  file://path/to-file/document.json \
--document-type "Command"

SSM-Verknüpfung erstellen

aws ssm create-association \
--name <association_name> \
--targets "Key=InstanceIds,Values=<instance-id-1>,<instance-id-2>"

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Ec2 Managedinstance Patch Compliance Status Check

Kategoriename in der API: EC2_MANAGEDINSTANCE_PATCH_COMPLIANCE_STATUS_CHECK

Mit dieser Steuerung wird geprüft, ob der Status der AWS Systems Manager-Verknüpfung „COMPLIANT“ (Einhaltung) oder „NON_COMPLIANT“ (Nichteinhaltung) ist, nachdem die Verknüpfung auf einer Instanz ausgeführt wurde. Die Prüfung schlägt fehl, wenn der Compliance-Status der Verknüpfung „NON_COMPLIANT“ (Nicht konform) ist.

Eine Verknüpfung mit dem State Manager ist eine Konfiguration, die Ihren verwalteten Instanzen zugewiesen wird. In der Konfiguration wird der Status definiert, der auf Ihren Instanzen beibehalten werden soll. Eine Verknüpfung kann beispielsweise angeben, dass Antivirensoftware auf Ihren Instanzen installiert und ausgeführt werden muss oder dass bestimmte Ports geschlossen sein müssen.

Nachdem Sie eine oder mehrere State Manager-Verknüpfungen erstellt haben, sind Informationen zum Compliance-Status sofort verfügbar. Sie können den Compliance-Status in der Console oder als Reaktion auf AWS CLI-Befehle oder entsprechende Systems Manager API-Aktionen aufrufen. Bei Verknüpfungen wird unter „Konfigurationskonformität“ der Konformitätsstatus angezeigt („Konform“ oder „Nicht konform“). Außerdem wird die Schweregradstufe angezeigt, die der Verknüpfung zugewiesen ist, z. B. „Kritisch“ oder „Mittel“.

Weitere Informationen zur Compliance bei State Manager-Verknüpfungen finden Sie im AWS Systems Manager-Benutzerhandbuch unter Compliance bei State Manager-Verknüpfungen.

Empfehlung: Prüfen Sie den Status der AWS Systems Manager-Patchcompliance

Eine fehlgeschlagene Verknüpfung kann verschiedene Ursachen haben, z. B. Ziele und SSM-Dokumentnamen. Um dieses Problem zu beheben, müssen Sie zuerst die Verknüpfung identifizieren und untersuchen, indem Sie sich den Verknüpfungsverlauf ansehen. Eine Anleitung zum Aufrufen des Verknüpfungsverlaufs finden Sie im AWS Systems Manager-Benutzerhandbuch unter Verknüpfungsverläufe ansehen.

Nach der Prüfung können Sie die Verknüpfung bearbeiten, um das erkannte Problem zu beheben. Sie können eine Verknüpfung bearbeiten, um einen neuen Namen, Zeitplan, eine neue Schwere oder neue Ziele anzugeben. Nachdem Sie eine Verknüpfung bearbeitet haben, erstellt AWS Systems Manager eine neue Version. Eine Anleitung zum Bearbeiten einer Verknüpfung finden Sie im AWS Systems Manager-Nutzerhandbuch unter Verknüpfung bearbeiten und neue Version einer Verknüpfung erstellen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Ec2 Metadata Service Allows Imdsv2

Kategoriename in der API: EC2_METADATA_SERVICE_ALLOWS_IMDSV2

Wenn Sie den Metadatendienst auf AWS EC2-Instanzen aktivieren, haben Sie die Möglichkeit, entweder die Instanzmetadatendienst-Version 1 (IMDSv1; eine Anfrage/Antwort-Methode) oder die Instanzmetadatendienst-Version 2 (IMDSv2; eine sitzungsorientierte Methode) zu verwenden.

Empfehlung: Achten Sie darauf, dass der EC2-Metadatendienst nur IMDSv2 zulässt

Über die Console:
1. Melden Sie sich in der AWS Management Console an und öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/
. Wählen Sie im Menü „Instanzen“ die Option „Instanzen“ aus.
3. Wählen Sie für jede Instanz die Instanz und dann „Aktionen“ > „Metadatenoptionen der Instanz ändern“ aus.
4. Wenn der Instanzmetadatendienst aktiviert ist, legen Sie „IMDSv2“ auf „Erforderlich“ fest.

Über die Befehlszeile:

aws ec2 modify-instance-metadata-options --instance-id <instance_id> --http-tokens required

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Ec2 Volume Inuse Check

Kategoriename in der API: EC2_VOLUME_INUSE_CHECK

Sie können nicht bereitgestellte (ungenutzte) EBS-Volumes (Elastic Block Store) in Ihrem AWS-Konto ermitteln und entfernen, um die Kosten Ihrer monatlichen AWS-Rechnung zu senken. Durch das Löschen nicht verwendeter EBS-Volumes verringern Sie auch das Risiko, dass vertrauliche/sensible Daten Ihre Räumlichkeiten verlassen. Außerdem wird geprüft, ob archivierte EC2-Instanzen so konfiguriert sind, dass Volumes bei der Beendigung gelöscht werden.

Standardmäßig sind EC2-Instanzen so konfiguriert, dass die Daten in allen mit der Instanz verknüpften EBS-Volumes und das Stamm-EBS-Volume der Instanz gelöscht werden. Alle nicht-root-EBS-Volumes, die der Instanz beim Start oder während der Ausführung bereitgestellt wurden, werden jedoch standardmäßig nach der Beendigung beibehalten.

Empfehlung: Prüfen Sie, ob EBS-Volumes an EC2-Instanzen angehängt und zum Löschen bei Instanzbeendigung konfiguriert sind

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

Terraform

Um dieses Szenario mit Terraform zu verhindern, erstellen Sie EC2-Instanzen mit eingebetteten EBS-Blöcken. Wenn Sie das Attribut ebs_block_device.delete_on_termination standardmäßig auf true festlegen, werden alle mit der Instanz verknüpften EBS-Blöcke (nicht nur der Stamm) beim Beenden der Instanz gelöscht.

resource "aws_instance" "web" {
    ami                    = <ami_id>
    instance_type          = <instance_flavor>
    ebs_block_device {
      delete_on_termination = true # Default
      device_name           = "/dev/sdh"
    }

AWS-Konsole

So löschen Sie ein EBS-Volume über die Console:

1. Öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/.
2. Wählen Sie im Navigationsbereich Volumes aus.
3. Wählen Sie das zu löschende Volume aus und wählen Sie Aktionen, Volume löschen aus.
4. Hinweis: Wenn „Volume löschen“ ausgegraut ist, ist das Volume an eine Instanz angehängt. Sie müssen das Volume von der Instanz trennen, bevor es gelöscht werden kann.
5. Wählen Sie im Bestätigungsdialogfeld Löschen aus.

AWS-CLI

Mit diesem Beispielbefehl wird ein verfügbares Volume mit der Volume-ID „vol-049df61146c4d7901“ gelöscht. Wenn der Befehl erfolgreich ist, wird keine Ausgabe zurückgegeben.

aws ec2 delete-volume --volume-id vol-049df61146c4d7901

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Efs Encrypted Check

Kategoriename in der API: EFS_ENCRYPTED_CHECK

Amazon EFS unterstützt zwei Formen der Verschlüsselung für Dateisysteme: die Verschlüsselung von Daten während der Übertragung und die Verschlüsselung inaktiver Daten. Dabei wird geprüft, ob alle EFS-Dateisysteme in allen aktivierten Regionen des Kontos mit der Ruhedatenträgerverschlüsselung konfiguriert sind.

Empfehlung: Prüfen Sie, ob EFS zum Verschlüsseln von Dateidaten mit KMS konfiguriert ist

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

Terraform

Mit dem folgenden Code-Snippet können Sie ein KMS-verschlüsseltes EFS erstellen. Hinweis: Das Attribut kms_key_id ist optional. Wenn keine KMS-Schlüssel-ID übergeben wird, wird ein Schlüssel erstellt.

resource "aws_efs_file_system" "encrypted-efs" {
  creation_token = "my-kms-encrypted-efs"
  encrypted      = true
  kms_key_id     = "arn:aws:kms:us-west-2:12344375555:key/16393ebd-3348-483f-b162-99b6648azz23"

  tags = {
    Name = "MyProduct"
  }
}

AWS-Konsole

Informationen zum Konfigurieren von EFS mit Verschlüsselung über die AWS-Konsole finden Sie unter Ruhendes Dateisystem über die Console verschlüsseln.

AWS-CLI

Hinweis: Wenn Sie EFS über die Console erstellen, wird die Ruhedatenträgerverschlüsselung standardmäßig aktiviert. Das ist bei EFS, die über die Befehlszeile, die API oder das SDK erstellt werden, nicht der Fall. Im folgenden Beispiel wird gezeigt, wie Sie ein verschlüsseltes Dateisystem in Ihrer Infrastruktur erstellen.

aws efs create-file-system \
--backup \
--encrypted \
--region us-east-1 \

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Efs In Backup Plan

Kategoriename in der API: EFS_IN_BACKUP_PLAN

Gemäß den Best Practices von Amazon sollten Sie Sicherungen für Ihre Elastic File Systems (EFS) konfigurieren. Dabei werden alle EFS in allen aktivierten Regionen in Ihrem AWS-Konto auf aktivierte Sicherungen geprüft.

Empfehlung: Prüfen Sie, ob EFS-Dateisysteme in AWS-Sicherungsplänen enthalten sind

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

Terraform

Verwenden Sie die Ressource aws_efs_backup_policy, um eine Sicherungsrichtlinie für EFS-Dateisysteme zu konfigurieren.

resource "aws_efs_file_system" "encrypted-efs" {
  creation_token = "my-encrypted-efs"
  encrypted      = true

  tags = merge({
    Name = "${local.resource_prefix.value}-efs"
    }, {
    git_file             = "terraform/aws/efs.tf"
    git_org              = "your_git_org"
    git_repo             = "your_git_repo"
  })
}

resource "aws_efs_backup_policy" "policy" {
  file_system_id = aws_efs_file_system.encrypted-efs.id

  backup_policy {
    status = "ENABLED"
  }
}

AWS-Konsole

Es gibt zwei Möglichkeiten, EFS zu sichern: den AWS-Sicherungsservice und die EFS-zu-EFS-Sicherungslösung. Informationen zum Beheben von nicht gesicherten EFS-Volumes mithilfe der Console finden Sie unter:

1. Amazon EFS-Dateisysteme mit AWS Backup sichern und wiederherstellen
2. EFS-zu-EFS-Sicherung

AWS-CLI

Es gibt mehrere Möglichkeiten, mit der Befehlszeile konforme EFS-Dateisysteme zu erstellen:

1. EFS mit aktivierter automatischer Sicherung erstellen (Standard für Speicherplatz mit einer Zone und sitzungsabhängig von der Verfügbarkeit der Sicherung in der AWS-Region)
2. EFS erstellen und Sicherungsrichtlinie festlegen

Wenn die Behebung jedoch in einem vorhandenen EFS erfolgen muss, ist es am besten, eine Sicherungsrichtlinie zu erstellen und mit dem nicht konformen EFS zu verknüpfen. Sie benötigen einen Befehl für jedes EFS in Ihrer Infrastruktur.

arr=( $(aws efs describe-file-systems | jq -r '.FileSystems[].FileSystemId') )
for efs in "${arr[@]}"
do
  aws efs put-backup-policy \
  --file-system-id "${efs}" \
  --backup-policy "Status=ENABLED"
done

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Elb Acm Certificate Required

Kategoriename in der API: ELB_ACM_CERTIFICATE_REQUIRED

Prüft, ob der klassische Load Balancer HTTPS-/SSL-Zertifikate verwendet, die von AWS Certificate Manager (ACM) bereitgestellt wurden. Die Prüfung schlägt fehl, wenn der mit einem HTTPS-/SSL-Listener konfigurierte klassische Load Balancer kein von ACM bereitgestelltes Zertifikat verwendet.

Sie können entweder ACM oder ein Tool verwenden, das die SSL- und TLS-Protokolle unterstützt, z. B. OpenSSL. Security Hub empfiehlt, Zertifikate für Ihren Load Balancer mit ACM zu erstellen oder zu importieren.

ACM lässt sich in klassische Load Balancer einbinden, sodass Sie das Zertifikat auf Ihrem Load Balancer bereitstellen können. Außerdem sollten Sie diese Zertifikate automatisch verlängern.

Empfehlung: Prüfen Sie, ob alle klassischen Load Balancer SSL-Zertifikate verwenden, die von AWS Certificate Manager bereitgestellt wurden

Informationen zum Verknüpfen eines ACM-SSL/TLS-Zertifikats mit einem klassischen Load Balancer finden Sie im AWS Knowledge Center-Artikel How can I associate an ACM SSL/TLS certificate with a Classic, Application, or Network Load Balancer? (Wie verknüpfe ich ein ACM-SSL/TLS-Zertifikat mit einem klassischen, Anwendungs- oder Netzwerk-Load Balancer?)

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Elb Deletion Protection Enabled

Kategoriename in der API: ELB_DELETION_PROTECTION_ENABLED

Prüft, ob für einen Application Load Balancer der Löschschutz aktiviert ist. Die Funktion schlägt fehl, wenn der Löschschutz nicht konfiguriert ist.

Aktivieren Sie den Löschschutz, um Ihren Application Load Balancer vor dem Löschen zu schützen.

Empfehlung: Der Löschschutz für Application Load Balancer sollte aktiviert sein

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

Sie können den Löschschutz aktivieren, um zu verhindern, dass Ihr Load Balancer versehentlich gelöscht wird. Standardmäßig ist der Löschschutz für Ihren Load Balancer deaktiviert.

Wenn Sie den Löschschutz für Ihren Load Balancer aktivieren, müssen Sie ihn deaktivieren, bevor Sie den Load Balancer löschen können.

So aktivieren Sie den Löschschutz über die Console:

1. Öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/.
2. Wählen Sie im Navigationsbereich unter LOAD BALANCING (LADENVERTEILUNG) die Option Load Balancers (Load Balancer) aus.
3. Wählen Sie den Load Balancer aus.
4. Wählen Sie auf dem Tab Beschreibung die Option Attribute bearbeiten aus.
5. Wählen Sie auf der Seite Load Balancer-Attribute bearbeiten die Option Für Löschschutz aktivieren und dann Speichern aus.
6. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Elb Logging Enabled

Kategoriename in der API: ELB_LOGGING_ENABLED

Hier wird geprüft, ob für den Application Load Balancer und den klassischen Load Balancer Logging aktiviert ist. Die Steuerung schlägt fehl, wenn „access_logs.s3.enabled“ auf „false“ festgelegt ist.

Elastic Load Balancing bietet Zugriffsprotokolle, die detaillierte Informationen zu Anfragen enthalten, die an Ihren Load Balancer gesendet werden. Jedes Protokoll enthält Informationen wie den Zeitpunkt, zu dem die Anfrage empfangen wurde, die IP-Adresse des Clients, Latenzen, Anfragepfade und Serverantworten. Sie können diese Zugriffsprotokolle verwenden, um Zugriffsmuster zu analysieren und Probleme zu beheben.

Weitere Informationen finden Sie im Nutzerhandbuch für klassische Load Balancer unter Zugriffsprotokolle für Ihren klassischen Load Balancer.

Empfehlung: Prüft, ob Logging für klassische und Application Load Balancer aktiviert ist

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

Aktualisieren Sie Ihre Load Balancer, um das Logging zu aktivieren und dieses Problem zu beheben.

So aktivieren Sie Zugriffslogs:

1. Öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/.
2. Wählen Sie im Navigationsbereich Load Balancer aus.
3. Wählen Sie einen Application Load Balancer oder einen klassischen Load Balancer aus.
4. Wählen Sie unter Aktionen die Option Attribute bearbeiten aus.
5. Wählen Sie unter Zugriffsprotokolle die Option Aktivieren aus.
6. Geben Sie Ihren S3-Speicherort ein. Dieser Standort kann vorhanden sein oder für Sie erstellt werden. Wenn Sie kein Präfix angeben, werden die Zugriffsprotokolle im Stammverzeichnis des S3-Buckets gespeichert.
7. Klicken Sie auf Speichern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Elb Tls Https Listeners Only

Kategoriename in der API: ELB_TLS_HTTPS_LISTENERS_ONLY

Mit dieser Prüfung wird sichergestellt, dass alle klassischen Load Balancer für die sichere Kommunikation konfiguriert sind.

Ein Listener ist ein Prozess, der nach Verbindungsanfragen sucht. Er ist mit einem Protokoll und einem Port für Front-End-Verbindungen (Client zum Load Balancer) und einem Protokoll und einem Port für Back-End-Verbindungen (Load Balancer zur Instanz) konfiguriert. Informationen zu den von Elastic Load Balancing unterstützten Ports, Protokollen und Listenerkonfigurationen finden Sie unter Listener für Ihren klassischen Load Balancer.

Empfehlung: Prüfen Sie, ob SSL- oder HTTPS-Listener für alle klassischen Load Balancer konfiguriert sind

Informationen zum Konfigurieren von SSL oder TLS für klassische Load Balancer finden Sie unter HTTPS-/SSL-Load Balancer mit der AWS-Managementkonsole erstellen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Encrypted Volumes

Kategoriename in der API: ENCRYPTED_VOLUMES

Prüft, ob die EBS-Volumes, die angehängt sind, verschlüsselt sind. Damit diese Prüfung bestanden wird, müssen EBS-Volumes verwendet und verschlüsselt sein. Wenn das EBS-Volume nicht angehängt ist, unterliegt es dieser Prüfung nicht.

Für zusätzlichen Schutz Ihrer sensiblen Daten in EBS-Volumes sollten Sie die EBS-Verschlüsselung inaktiver Daten aktivieren. Die Amazon EBS-Verschlüsselung bietet eine einfache Verschlüsselungslösung für Ihre EBS-Ressourcen, bei der Sie keine eigene Schlüsselverwaltungsinfrastruktur erstellen, verwalten und sichern müssen. Beim Erstellen verschlüsselter Volumes und Snapshots werden KMS-Schlüssel verwendet.

Weitere Informationen zur Amazon EBS-Verschlüsselung finden Sie im Amazon EC2-Nutzerhandbuch für Linux-Instanzen.

Empfehlung: Ruhende Daten von angehängten Amazon EBS-Volumes sollten verschlüsselt sein

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

Es gibt keine direkte Möglichkeit, ein vorhandenes unverschlüsseltes Volume oder einen unverschlüsselten Snapshot zu verschlüsseln. Sie können ein neues Volume oder einen neuen Snapshot nur verschlüsseln, wenn Sie es erstellen.

Wenn Sie die Verschlüsselung standardmäßig aktiviert haben, verschlüsselt Amazon EBS das resultierende neue Volume oder den Snapshot mit Ihrem Standardschlüssel für die Amazon EBS-Verschlüsselung. Auch wenn Sie die Verschlüsselung nicht standardmäßig aktiviert haben, können Sie sie beim Erstellen eines einzelnen Volumes oder Snapshots aktivieren. In beiden Fällen können Sie den Standardschlüssel für die Amazon EBS-Verschlüsselung überschreiben und einen symmetrischen vom Kunden verwalteten Schlüssel auswählen.

Weitere Informationen finden Sie im Amazon EC2-Nutzerhandbuch für Linux-Instanzen unter Amazon EBS-Volume erstellen und Amazon EBS-Snapshot kopieren.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Encryption At Rest Enabled Rds Instances

Kategoriename in der API: ENCRYPTION_AT_REST_ENABLED_RDS_INSTANCES

Bei verschlüsselten Amazon RDS-Datenbankinstanzen werden Ihre Daten auf dem Server, auf dem Ihre Amazon RDS-Datenbankinstanzen gehostet werden, mit dem branchenüblichen AES-256-Verschlüsselungsalgorithmus verschlüsselt. Nach der Verschlüsselung Ihrer Daten übernimmt Amazon RDS die Authentifizierung des Zugriffs und die Entschlüsselung Ihrer Daten transparent und mit minimalen Auswirkungen auf die Leistung.

Empfehlung: Achten Sie darauf, dass die Verschlüsselung ruhender Daten für RDS-Instanzen aktiviert ist

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

1. Melden Sie sich in der AWS Management Console an und öffnen Sie das RDS-Dashboard unter https://console.aws.amazon.com/rds/.
2. Klicken Sie im linken Navigationsbereich auf Databases.
3. Wählen Sie die Datenbankinstanz aus, die verschlüsselt werden soll.
4. Klicken Sie rechts oben auf die Schaltfläche Actions und wählen Sie Take Snapshot aus.
5. Geben Sie auf der Seite „Snapshot erstellen“ in das Feld Snapshot Name den Namen einer Datenbank ein, für die Sie einen Snapshot erstellen möchten, und klicken Sie auf Take Snapshot.
6. Wählen Sie den neu erstellten Snapshot aus, klicken Sie rechts oben auf die Schaltfläche Action und wählen Sie im Menü „Aktion“ die Option Copy snapshot aus.
7. Führen Sie auf der Seite „Kopie des Datenbank-Snapshots erstellen“ die folgenden Schritte aus:

• Geben Sie im Feld „Neue Datenbank-Snapshot-ID“ einen Namen für die new snapshot ein.
• Setzen Sie ein Häkchen bei Copy Tags, „Neuer Snapshot muss dieselben Tags wie der Quell-Snapshot haben“.
• Wählen Sie in der Drop-down-Liste Enable Encryption die Option Yes aus, um die Verschlüsselung zu aktivieren. Sie können den Standardverschlüsselungsschlüssel von AWS oder einen benutzerdefinierten Schlüssel aus der Drop-down-Liste „Master Key“ verwenden.

8. Klicken Sie auf Copy Snapshot, um eine verschlüsselte Kopie des ausgewählten Instanz-Snapshots zu erstellen.
9. Wählen Sie die neue verschlüsselte Kopie des Snapshots aus und klicken Sie oben rechts auf die Schaltfläche Action. Wählen Sie dann im Menü „Aktion“ die Schaltfläche Restore Snapshot aus. Dadurch wird der verschlüsselte Snapshot in einer neuen Datenbankinstanz wiederhergestellt.
10. Geben Sie auf der Seite „Datenbankinstanz wiederherstellen“ im Feld „Datenbankinstanz-ID“ einen eindeutigen Namen für die neue Datenbankinstanz ein.
11. Überprüfen Sie die Details der Instanzkonfiguration und klicken Sie auf Restore DB Instance.
12. Sobald die Bereitstellung der neuen Instanz abgeschlossen ist, können Sie die Anwendungskonfiguration so aktualisieren, dass sie auf den Endpunkt der neuen verschlüsselten Datenbankinstanz verweist. Sobald der Datenbankendpunkt auf Anwendungsebene geändert wurde, können Sie die unverschlüsselte Instanz entfernen.

AWS-CLI

1. Führen Sie den Befehl describe-db-instances aus, um alle RDS-Datenbanknamen aufzulisten, die in der ausgewählten AWS-Region verfügbar sind. Die Befehlsausgabe sollte die Datenbankinstanz-ID zurückgeben.

aws rds describe-db-instances --region <region-name> --query 'DBInstances[*].DBInstanceIdentifier'

2. Führen Sie den Befehl create-db-snapshot aus, um einen Snapshot für die ausgewählte Datenbankinstanz zu erstellen. Die Befehlsausgabe gibt den new snapshot mit dem Namen „DB Snapshot Name“ zurück.

aws rds create-db-snapshot --region <region-name> --db-snapshot-identifier <DB-Snapshot-Name> --db-instance-identifier <DB-Name>

3. Führen Sie jetzt den Befehl list-aliases aus, um die Aliasse der KMS-Schlüssel aufzulisten, die in einer bestimmten Region verfügbar sind. In der Befehlsausgabe sollte jeder key alias currently available zurückgegeben werden. Suchen Sie für die Aktivierung der RDS-Verschlüsselung die ID des standardmäßigen AWS-KMS-Schlüssels.

aws kms list-aliases --region <region-name>

4. Führen Sie den Befehl copy-db-snapshot mit der Standard-KMS-Schlüssel-ID für RDS-Instanzen aus, die zuvor zurückgegeben wurde, um eine verschlüsselte Kopie des Snapshots der Datenbankinstanz zu erstellen. Die Befehlsausgabe gibt encrypted instance snapshot configuration zurück.

aws rds copy-db-snapshot --region <region-name> --source-db-snapshot-identifier <DB-Snapshot-Name> --target-db-snapshot-identifier <DB-Snapshot-Name-Encrypted> --copy-tags --kms-key-id <KMS-ID-For-RDS>

5. Führen Sie den Befehl restore-db-instance-from-db-snapshot aus, um den im vorherigen Schritt erstellten verschlüsselten Snapshot in einer neuen Datenbankinstanz wiederherzustellen. Bei Erfolg sollte die Befehlsausgabe die Konfiguration der neuen verschlüsselten Datenbankinstanz zurückgeben.

aws rds restore-db-instance-from-db-snapshot --region <region-name> --db-instance-identifier <DB-Name-Encrypted> --db-snapshot-identifier <DB-Snapshot-Name-Encrypted>

6. Führen Sie den Befehl describe-db-instances aus, um alle RDS-Datenbanknamen aufzulisten, die in der ausgewählten AWS-Region verfügbar sind. Die Ausgabe enthält den Namen der Datenbankinstanz-ID. Wählen Sie den Namen der verschlüsselten Datenbank aus, die wir gerade erstellt haben: DB-Name-Encrypted.

aws rds describe-db-instances --region <region-name> --query 'DBInstances[*].DBInstanceIdentifier'

7. Führen Sie den Befehl describe-db-instances noch einmal mit der zuvor zurückgegebenen RDS-Instanz-ID aus, um festzustellen, ob die ausgewählte Datenbankinstanz verschlüsselt ist. Die Befehlsausgabe sollte den Verschlüsselungsstatus True zurückgeben.

aws rds describe-db-instances --region <region-name> --db-instance-identifier <DB-Name-Encrypted> --query 'DBInstances[*].StorageEncrypted'

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Encryption Enabled Efs File Systems

Kategoriename in der API: ENCRYPTION_ENABLED_EFS_FILE_SYSTEMS

EFS-Daten sollten im Ruhezustand mit AWS KMS (Key Management Service) verschlüsselt werden.

Empfehlung: Achten Sie darauf, dass die Verschlüsselung für EFS-Dateisysteme aktiviert ist

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

1. Melden Sie sich in der AWS Management Console an und rufen Sie das Elastic File System (EFS)-Dashboard auf.
2. Wählen Sie im linken Navigationsbereich File Systems aus.
3. Klicken Sie oben im Dashboard auf die Schaltfläche Create File System, um mit der Einrichtung des Dateisystems zu beginnen.

4. Führen Sie auf der Konfigurationsseite von Configure file system access die folgenden Aktionen aus.
   – Wählen Sie in der Drop-down-Liste „VPC“ die richtige VPC aus.
   – Wählen Sie im Bereich „Bindungsziele erstellen“ die Kästchen für alle Verfügbarkeitszonen (AZs) in der ausgewählten VPC aus. Das sind Ihre Bereitstellungsziele.
   – Klicken Sie auf Next step, um fortzufahren.

5. Führen Sie auf der Seite Configure optional settings die folgenden Schritte aus.
   – „Create“ (Erstellen) tags, um das neue Dateisystem zu beschreiben.
   – Wählen Sie performance mode entsprechend Ihren Anforderungen aus.
   – Klicken Sie das Kästchen Enable encryption an und wählen Sie aws/elasticfilesystem aus dem Drop-down-Menü „KMS-Masterschlüssel auswählen“ aus, um die Verschlüsselung für das neue Dateisystem mit dem Standard-Masterschlüssel zu aktivieren, der von AWS KMS bereitgestellt und verwaltet wird.
   – Klicken Sie auf Next step, um fortzufahren.

6. Prüfen Sie die Details zur Dateisystemkonfiguration auf der Seite review and create und klicken Sie dann auf Create File System, um ein neues AWS EFS-Dateisystem zu erstellen.

7. Kopieren Sie die Daten aus dem alten unverschlüsselten EFS-Dateisystem in das neu erstellte verschlüsselte Dateisystem.
8. Entfernen Sie das unverschlüsselte Dateisystem, sobald die Datenmigration in das neu erstellte verschlüsselte Dateisystem abgeschlossen ist.
9. Ändern Sie die AWS-Region in der Navigationsleiste und wiederholen Sie den gesamten Vorgang für andere AWS-Regionen.

Über die Befehlszeile:
1. Führen Sie den Befehl „describe-file-systems“ aus, um die für das ausgewählte (nicht verschlüsselte) Dateisystem verfügbaren Konfigurationsinformationen zu beschreiben. Im Abschnitt „Audit“ finden Sie Informationen dazu, wie Sie die richtige Ressource ermitteln:

aws efs describe-file-systems --region <region> --file-system-id <file-system-id from audit section step 2 output>

2. Die Befehlsausgabe sollte die angeforderten Konfigurationsinformationen zurückgeben.
3. Wenn Sie ein neues AWS EFS-Dateisystem bereitstellen möchten, müssen Sie eine universell eindeutige Kennung (Universally Unique Identifier, UUID) generieren, um das für den Befehl „create-file-system“ erforderliche Token zu erstellen. Zum Erstellen des erforderlichen Tokens können Sie eine zufällig generierte UUID von „https://www.uuidgenerator.net“ verwenden.
4. Führen Sie den Befehl „create-file-system“ mit dem eindeutigen Token aus, das Sie im vorherigen Schritt erstellt haben.

aws efs create-file-system --region <region> --creation-token <Token (randomly generated UUID from step 3)> --performance-mode generalPurpose --encrypted

5. Die Befehlsausgabe sollte die Metadaten der neuen Dateisystemkonfiguration zurückgeben.
6. Führen Sie den Befehl „create-mount-target“ mit der im vorherigen Schritt zurückgegebenen ID des neu erstellten EFS-Dateisystems und der ID der Verfügbarkeitszone (Availability Zone, AZ) aus, die das Bereitstellungsziel darstellt:

aws efs create-mount-target --region <region> --file-system-id <file-system-id> --subnet-id <subnet-id>

7. Die Befehlsausgabe sollte die Metadaten des neuen Bereitstellungsziels zurückgeben.
8. Jetzt können Sie Ihr Dateisystem über eine EC2-Instanz bereitstellen.
9. Kopieren Sie die Daten aus dem alten unverschlüsselten EFS-Dateisystem in das neu erstellte verschlüsselte Dateisystem.
10. Entfernen Sie das unverschlüsselte Dateisystem, sobald die Datenmigration in das neu erstellte verschlüsselte Dateisystem abgeschlossen ist.

aws efs delete-file-system --region <region> --file-system-id <unencrypted-file-system-id>

11. Ändern Sie die AWS-Region, indem Sie die Option „–region“ aktualisieren, und wiederholen Sie den gesamten Vorgang für andere AWS-Regionen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Iam Password Policy

Kategoriename in der API: IAM_PASSWORD_POLICY

AWS ermöglicht benutzerdefinierte Passwortrichtlinien für Ihr AWS-Konto, um Komplexitätsanforderungen und obligatorische Rotationszeiträume für die Passwörter Ihrer IAM-Nutzer anzugeben. Wenn Sie keine benutzerdefinierte Passwortrichtlinie festlegen, müssen IAM-Nutzerpasswörter der Standard-AWS-Passwortrichtlinie entsprechen. Gemäß den Best Practices für die Sicherheit von AWS sollten Passwörter folgende Anforderungen an die Komplexität erfüllen:

• Das Passwort muss mindestens einen Großbuchstaben enthalten.
• Passworte müssen mindestens einen Kleinbuchstaben enthalten.
• Passworte müssen mindestens ein Symbol enthalten.
• Passwörter müssen mindestens eine Zahl enthalten.
• Das Passwort muss mindestens 14 Zeichen lang sein.
• Es müssen mindestens 24 Passwörter verwendet werden, bevor eine Wiederverwendung zulässig ist.
• Mindestens 90 Tage vor Ablauf des Passworts

Hier werden alle angegebenen Anforderungen an die Passwortrichtlinie geprüft.

Empfehlung: Prüft, ob die Richtlinie für Kontopasswörter für IAM-Nutzer den angegebenen Anforderungen entspricht

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

Terraform

resource "aws_iam_account_password_policy" "strict" {
  allow_users_to_change_password = true
  require_uppercase_characters   = true
  require_lowercase_characters   = true
  require_symbols                = true
  require_numbers                = true
  minimum_password_length        = 14
  password_reuse_prevention      = 24
  max_password_age               = 90
}

AWS-Konsole

Benutzerdefinierte Passwortrichtlinie erstellen

1. Melden Sie sich in der AWS Management Console an und öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
2. Wählen Sie im Navigationsbereich die Option „Kontoeinstellungen“ aus.
3. Wählen Sie im Abschnitt „Passwortrichtlinie“ die Option „Passwortrichtlinie ändern“ aus.
4. Wählen Sie die Optionen aus, die Sie auf Ihre Passwortrichtlinie anwenden möchten, und klicken Sie auf „Änderungen speichern“.

Benutzerdefinierte Passwortrichtlinie ändern

1. Melden Sie sich in der AWS Management Console an und öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
2. Wählen Sie im Navigationsbereich die Option „Kontoeinstellungen“ aus.
3. Wählen Sie im Abschnitt „Passwortrichtlinie“ die Option „Ändern“ aus.
4. Wählen Sie die Optionen aus, die Sie auf Ihre Passwortrichtlinie anwenden möchten, und klicken Sie auf „Änderungen speichern“.

AWS-CLI

aws iam update-account-password-policy \
--allow-users-to-change-password \
--require-uppercase-characters \
--require-lowercase-characters \
--require-symbols \
--require-numbers \
--minimum-password-length 14 \
--password-reuse-prevention 24 \
--max-password-age 90

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Iam Password Policy Prevents Password Reuse

Kategoriename in der API: IAM_PASSWORD_POLICY_PREVENTS_PASSWORD_REUSE

Mit IAM-Passwortrichtlinien lässt sich verhindern, dass ein bestimmtes Passwort vom selben Nutzer wiederverwendet wird. Es wird empfohlen, dass die Passwortrichtlinie die Wiederverwendung von Passwörtern verhindert.

Empfehlung: Achten Sie darauf, dass die IAM-Passwortrichtlinie die Wiederverwendung von Passwörtern verhindert

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

1. Melden Sie sich in der AWS Console an (mit den entsprechenden Berechtigungen zum Ansehen der Kontoeinstellungen für Identity Access Management).
2. IAM-Dienst in der AWS-Konsole aufrufen
3. Klicken Sie im linken Bereich auf „Kontoeinstellungen“.
4. Aktivieren Sie „Wiederverwendung von Passwörtern verhindern“.
5. „Anzahl der Passwörter, die gespeichert werden sollen“ auf 24 festlegen

AWS-CLI

 aws iam update-account-password-policy --password-reuse-prevention 24

Hinweis: Alle Befehle, die mit „aws iam update-account-password-policy“ beginnen, können in einem einzigen Befehl kombiniert werden.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Iam Password Policy Requires Minimum Length 14 Greater

Kategoriename in der API: IAM_PASSWORD_POLICY_REQUIRES_MINIMUM_LENGTH_14_GREATER

Passwortrichtlinien werden unter anderem verwendet, um Anforderungen an die Passwortkomplexität durchzusetzen. Mit IAM-Passwortrichtlinien können Sie dafür sorgen, dass Passwörter mindestens eine bestimmte Länge haben. Wir empfehlen, dass die Passwortrichtlinie eine Mindestlänge von 14 Zeichen verlangt.

Empfehlung: Achten Sie darauf, dass die IAM-Passwortrichtlinie eine Mindestlänge von 14 Zeichen verlangt

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

1. Melden Sie sich in der AWS Console an (mit den entsprechenden Berechtigungen zum Ansehen der Kontoeinstellungen für Identity Access Management).
2. IAM-Dienst in der AWS-Konsole aufrufen
3. Klicken Sie im linken Bereich auf „Kontoeinstellungen“.
4. Legen Sie „Mindestpasswortlänge“ auf 14 oder höher fest.
5. Klicken Sie auf „Passwortrichtlinie anwenden“.

AWS-CLI

 aws iam update-account-password-policy --minimum-password-length 14

Hinweis: Alle Befehle, die mit „aws iam update-account-password-policy“ beginnen, können in einem einzigen Befehl kombiniert werden.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Iam Policies Allow Full Administrative Privileges Attached

Kategoriename in der API: IAM_POLICIES_ALLOW_FULL_ADMINISTRATIVE_PRIVILEGES_ATTACHED

Mit IAM-Richtlinien werden Nutzern, Gruppen oder Rollen Berechtigungen gewährt. Es wird empfohlen und gilt als Standardsicherheitsratschlag, die geringste Berechtigung zu gewähren, d. h. nur die Berechtigungen zu gewähren, die für die Ausführung einer Aufgabe erforderlich sind. Legen Sie fest, was Nutzer tun müssen, und erstellen Sie dann Richtlinien für sie, mit denen sie nur diese Aufgaben ausführen können, anstatt ihnen volle Administratorberechtigungen zu gewähren.

Empfehlung: Achten Sie darauf, dass keine IAM-Richtlinien angehängt sind, die uneingeschränkte „*:*“-Administratorberechtigungen gewähren

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

So trennen Sie die Richtlinie mit den vollständigen Administratorberechtigungen:

1. Melden Sie sich in der AWS Management Console an und öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
2. Klicken Sie im Navigationsbereich auf „Richtlinien“ und suchen Sie nach dem Namen der Richtlinie, den Sie im Analyseschritt gefunden haben.
3. Wählen Sie die Richtlinie aus, die gelöscht werden soll.
4. Wählen Sie im Menü „Richtlinienaktion“ zuerst Detach aus.
5. Alle Nutzer, Gruppen und Rollen auswählen, mit denen diese Richtlinie verknüpft ist
6. Klicken Sie auf Detach Policy.
7. Wählen Sie im Menü „Richtlinienaktion“ die Option Detach aus.

AWS-CLI

Führen Sie die folgenden Schritte aus, um die Richtlinie mit den vollen Administratorberechtigungen zu trennen, die im Analyseschritt gefunden wurde:

1. Hier werden alle IAM-Nutzer, -Gruppen und -Rollen aufgelistet, die der angegebenen verwalteten Richtlinie zugeordnet sind.

 aws iam list-entities-for-policy --policy-arn <policy_arn>

2. Trennen Sie die Richtlinie von allen IAM-Nutzern:

 aws iam detach-user-policy --user-name <iam_user> --policy-arn <policy_arn>

3. Trennen Sie die Richtlinie von allen IAM-Gruppen:

 aws iam detach-group-policy --group-name <iam_group> --policy-arn <policy_arn>

4. Trennen Sie die Richtlinie von allen IAM-Rollen:

 aws iam detach-role-policy --role-name <iam_role> --policy-arn <policy_arn>

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Iam Users Receive Permissions Groups

Kategoriename in der API: IAM_USERS_RECEIVE_PERMISSIONS_GROUPS

IAM-Nutzern wird über IAM-Richtlinien Zugriff auf Dienste, Funktionen und Daten gewährt. Es gibt vier Möglichkeiten, Richtlinien für einen Nutzer zu definieren: 1) Nutzerrichtlinie direkt bearbeiten (Inline-Richtlinie oder Nutzerrichtlinie); 2) Richtlinie direkt mit einem Nutzer verknüpfen; 3) Nutzer einer IAM-Gruppe mit einer verknüpften Richtlinie hinzufügen; 4) Nutzer einer IAM-Gruppe mit einer Inline-Richtlinie hinzufügen.

Wir empfehlen nur die dritte Implementierung.

Empfehlung: Achten Sie darauf, dass IAM-Nutzer Berechtigungen nur über Gruppen erhalten

So erstellen Sie eine IAM-Gruppe und weisen ihr eine Richtlinie zu:

1. Melden Sie sich in der AWS Management Console an und öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
2. Klicken Sie im Navigationsbereich auf Groups und dann auf Create New Group .
3. Geben Sie in das Feld Group Name den Namen der Gruppe ein und klicken Sie dann auf Next Step .
4. Klicken Sie in der Liste der Richtlinien das Kästchen neben jeder Richtlinie an, die auf alle Mitglieder der Gruppe angewendet werden soll. Klicken Sie dann auf Next Step .
5. Klicken Sie auf Create Group.

So fügen Sie einer Gruppe einen Nutzer hinzu:

1. Melden Sie sich in der AWS Management Console an und öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
2. Klicken Sie im Navigationsbereich auf Groups.
3. Gruppe auswählen, der ein Nutzer hinzugefügt werden soll
4. Klicken Sie auf Add Users To Group.
5. Wählen Sie die Nutzer aus, die der Gruppe hinzugefügt werden sollen.
6. Klicken Sie auf Add Users.

So entfernen Sie eine direkte Verknüpfung zwischen einem Nutzer und einer Richtlinie:

1. Melden Sie sich in der AWS Management Console an und öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
2. Klicken Sie im linken Navigationsbereich auf „Nutzer“.
3. Für jeden Nutzer:
   – Nutzer auswählen
   – Tab Permissions anklicken
   – Permissions policies maximieren
   – Für jede Richtlinie auf X und dann auf „Trennen“ oder „Entfernen“ (je nach Richtlinientyp) klicken

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Iam User Group Membership Check

Kategoriename in der API: IAM_USER_GROUP_MEMBERSHIP_CHECK

IAM-Nutzer sollten immer zu einer IAM-Gruppe gehören, um die Best Practices für die IAM-Sicherheit einzuhalten.

Wenn Sie einer Gruppe Nutzer hinzufügen, können Sie Richtlinien für verschiedene Nutzertypen freigeben.

Empfehlung: Prüfen Sie, ob IAM-Nutzer Mitglieder von mindestens einer IAM-Gruppe sind

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

Terraform

resource "aws_iam_user" "example" {
  name = "test-iam-user"
  path = "/users/dev/"
}

resource "aws_iam_group" "example" {
  name = "Developers"
  path = "/users/dev/"
}

resource "aws_iam_user_group_membership" "example" {
  user   = aws_iam_user.example.name
  groups = [aws_iam_group.example.name]
}

AWS-Konsole

Wenn Sie einen IAM-Nutzer über die AWS Management Console löschen, werden die folgenden Informationen automatisch von IAM gelöscht:

1. Nutzer*in
2. Alle Mitgliedschaften in Nutzergruppen. Der Nutzer wird also aus allen IAM-Nutzergruppen entfernt, deren Mitglied er war.
3. Alle Passwörter, die mit dem Nutzer verknüpft sind
4. Alle Zugriffsschlüssel, die dem Nutzer gehören
5. Alle Inline-Richtlinien, die im Nutzer eingebettet sind. Richtlinien, die über Nutzergruppenberechtigungen auf einen Nutzer angewendet werden, sind nicht betroffen.

So löschen Sie einen IAM-Nutzer:

1. Melden Sie sich in der AWS Management Console an und öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
2. Wählen Sie im Navigationsbereich „Nutzer“ und dann das Kästchen neben dem Nutzernamen aus, den Sie löschen möchten.
3. Wählen Sie oben auf der Seite „Löschen“ aus.
4. Geben Sie im Bestätigungsdialogfeld den Nutzernamen in das Textfeld ein, um das Löschen des Nutzers zu bestätigen.
5. Wählen Sie „Löschen“ aus.

So fügen Sie einer IAM-Nutzergruppe einen Nutzer hinzu:

1. Melden Sie sich in der AWS Management Console an und öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
2. Wählen Sie im Navigationsbereich „Nutzergruppen“ und dann den Namen der Gruppe aus.
3. Klicken Sie auf den Tab „Nutzer“ und dann auf „Nutzer hinzufügen“. Klicken Sie die Kästchen neben den Nutzern an, die Sie hinzufügen möchten.
4. Wählen Sie „Nutzer hinzufügen“ aus.

AWS-CLI

Im Gegensatz zur Amazon Web Services-Verwaltungskonsole müssen Sie die dem Nutzer zugewiesenen Elemente manuell löschen, wenn Sie ihn programmatisch löschen. Andernfalls schlägt das Löschen fehl.

Bevor Sie einen Nutzer löschen, entfernen Sie die folgenden Elemente:

1. Passwort ( DeleteLoginProfile )
2. Zugriffsschlüssel ( DeleteAccessKey )
3. Signaturzertifikat ( DeleteSigningCertificate )
4. Öffentlicher SSH-Schlüssel ( DeleteSSHPublicKey )
5. Git-Anmeldedaten ( DeleteServiceSpecificCredential )
6. Gerät für die Multi-Faktor-Authentifizierung (MFA) ( DeactivateMFADevice , DeleteVirtualMFADevice )
7. Inline-Richtlinien ( DeleteUserPolicy )
8. Angehängte verwaltete Richtlinien ( DetachUserPolicy )
9. Gruppenmitgliedschaften ( RemoveUserFromGroup )

So löschen Sie einen Nutzer, nachdem Sie alle mit ihm verknüpften Elemente gelöscht haben:

aws iam delete-user \
  --user-name "test-user"

So fügen Sie einer IAM-Gruppe einen IAM-Nutzer hinzu:

aws iam add-user-to-group \
  --group-name "test-group"
  --user-name "test-user"

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Iam User Mfa Enabled

Kategoriename in der API: IAM_USER_MFA_ENABLED

Die Multi-Faktor-Authentifizierung (MFA) ist eine Best Practice, die neben Nutzernamen und Passwörtern eine zusätzliche Schutzebene bietet. Bei der MFA muss ein Nutzer, der sich in der AWS-Verwaltungskonsole anmeldet, einen zeitlich begrenzten Authentifizierungscode angeben, der von einem registrierten virtuellen oder physischen Gerät bereitgestellt wird.

Empfehlung: Prüfen Sie, ob für AWS IAM-Nutzer die Multi-Faktor-Authentifizierung (MFA) aktiviert ist

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

Terraform

Bei Terraform gibt es einige Möglichkeiten, das Fehlen von MFA-Geräten zu beheben. Sie haben wahrscheinlich bereits eine sinnvolle Struktur, um Ihre Nutzer in Gruppen und restriktiven Richtlinien zu organisieren.

Das folgende Beispiel zeigt, wie Sie

1. Erstellen Sie Nutzer.
2. Erstellen Sie Anmeldeprofile für Nutzer mit einem öffentlichen PGP-Schlüssel.
3. Erstellen Sie eine Gruppe und eine Gruppenrichtlinie, die die Selbstverwaltung des IAM-Profils ermöglicht.
4. Nutzer der Gruppe zuweisen.
5. Virtuelle MFA-Geräte für Nutzer erstellen
6. Geben Sie jedem Nutzer den QR-Code und das Passwort aus.

variable "users" {
  type = set(string)
  default = [
    "[e-mail]",
    "[e-mail]"
  ]
}

resource "aws_iam_user" "test_users" {
  for_each = toset(var.users)
  name     = each.key
}

resource "aws_iam_user_login_profile" "test_users_profile" {
  for_each                = var.users
  user                    = each.key
  # Key pair created using GnuPG, this is the public key
  pgp_key = file("path/to/gpg_pub_key_base64.pem")
  password_reset_required = true
  lifecycle {
    ignore_changes = [
      password_length,
      password_reset_required,
      pgp_key,
    ]
  }
}

resource "aws_iam_virtual_mfa_device" "test_mfa" {
  for_each                = toset(var.users)
  virtual_mfa_device_name = each.key
}

resource "aws_iam_group" "enforce_mfa_group" {
  name = "EnforceMFAGroup"
}

resource "aws_iam_group_membership" "enforce_mfa_group_membership" {
  name  = "EnforceMFAGroupMembership"
  group = aws_iam_group.enforce_mfa_group.name
  users = [for k in aws_iam_user.test_users : k.name]
}

resource "aws_iam_group_policy" "enforce_mfa_policy" {
  name   = "EnforceMFAGroupPolicy"
  group  = aws_iam_group.enforce_mfa_group.id
  policy = <<POLICY
{
  "Version": "2012-10-17",
  "Statement": [
    {
        "Sid": "AllowViewAccountInfo",
        "Effect": "Allow",
        "Action": [
            "iam:GetAccountPasswordPolicy",
            "iam:ListVirtualMFADevices"
        ],
        "Resource": "*"
    },
    {
        "Sid": "AllowManageOwnPasswords",
        "Effect": "Allow",
        "Action": [
            "iam:ChangePassword",
            "iam:GetUser"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnAccessKeys",
        "Effect": "Allow",
        "Action": [
            "iam:CreateAccessKey",
            "iam:DeleteAccessKey",
            "iam:ListAccessKeys",
            "iam:UpdateAccessKey"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnSigningCertificates",
        "Effect": "Allow",
        "Action": [
            "iam:DeleteSigningCertificate",
            "iam:ListSigningCertificates",
            "iam:UpdateSigningCertificate",
            "iam:UploadSigningCertificate"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnSSHPublicKeys",
        "Effect": "Allow",
        "Action": [
            "iam:DeleteSSHPublicKey",
            "iam:GetSSHPublicKey",
            "iam:ListSSHPublicKeys",
            "iam:UpdateSSHPublicKey",
            "iam:UploadSSHPublicKey"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnGitCredentials",
        "Effect": "Allow",
        "Action": [
            "iam:CreateServiceSpecificCredential",
            "iam:DeleteServiceSpecificCredential",
            "iam:ListServiceSpecificCredentials",
            "iam:ResetServiceSpecificCredential",
            "iam:UpdateServiceSpecificCredential"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnVirtualMFADevice",
        "Effect": "Allow",
        "Action": [
            "iam:CreateVirtualMFADevice",
            "iam:DeleteVirtualMFADevice"
        ],
        "Resource": "arn:aws:iam::*:mfa/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnUserMFA",
        "Effect": "Allow",
        "Action": [
            "iam:DeactivateMFADevice",
            "iam:EnableMFADevice",
            "iam:ListMFADevices",
            "iam:ResyncMFADevice"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "DenyAllExceptListedIfNoMFA",
        "Effect": "Deny",
        "NotAction": [
            "iam:CreateVirtualMFADevice",
            "iam:EnableMFADevice",
            "iam:GetUser",
            "iam:ListMFADevices",
            "iam:ListVirtualMFADevices",
            "iam:ResyncMFADevice",
            "sts:GetSessionToken"
        ],
        "Resource": "*",
        "Condition": {
            "BoolIfExists": {
                "aws:MultiFactorAuthPresent": "false"
            }
        }
    }
  ]
}
POLICY
}

output "user_password_map" {
  # Outputs a map in the format {"[e-mail]": <PGPEncryptedPassword>, "[e-mail]": <PGPEncryptedPassword>}
  value = { for k, v in aws_iam_user_login_profile.test_users_profile : k => v.password }
}

output "user_qr_map" {
  # Outputs a map in the format {"[e-mail]": <QRCode>, "[e-mail]": <QRCode>}
  value = { for k, v in aws_iam_virtual_mfa_device.test_mfa : k => v.qr_code_png }
}

AWS-Konsole

Informationen zum Aktivieren der MFA für alle Nutzerkonten mit Zugriff auf die AWS-Konsole finden Sie in der AWS-Dokumentation unter Virtuelles MFA-Gerät (Konsole) aktivieren.

AWS-CLI

MFA-Gerät erstellen

aws iam create-virtual-mfa-device \
  --virtual-mfa-device-name "[e-mail]" \
  --outfile ./QRCode.png \
  --bootstrap-method QRCodePNG

MFA-Gerät für vorhandenen Nutzer aktivieren

aws iam enable-mfa-device \
  --user-name "[e-mail]" \
  --serial-number "arn:aws:iam::123456976749:mfa/[e-mail]" \
  --authentication-code1 123456 \
  --authentication-code2 654321

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Iam User Unused Credentials Check

Kategoriename in der API: IAM_USER_UNUSED_CREDENTIALS_CHECK

Dabei werden IAM-Passwörter oder aktive Zugriffsschlüssel geprüft, die in den letzten 90 Tagen nicht verwendet wurden.

Gemäß den Best Practices sollten Sie alle Anmeldedaten entfernen, deaktivieren oder alle 90 Tage rotieren, die seit mindestens 90 Tagen nicht verwendet wurden. So wird die Wahrscheinlichkeit verringert, dass Anmeldedaten, die mit einem manipulierten oder inaktiven Konto verknüpft sind, verwendet werden.

Empfehlung: Prüfen Sie, ob alle AWS IAM-Nutzer Passwörter oder aktive Zugriffsschlüssel haben, die in der unter „maxCredentialUsageAge“ angegebenen Anzahl von Tagen nicht verwendet wurden (Standardeinstellung: 90)

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

Terraform

Wenn Sie abgelaufene über Terraform erstellte Zugriffsschlüssel entfernen möchten, entfernen Sie die aws_iam_access_key-Ressource aus Ihrem Modul und wenden Sie die Änderung an.

Wenn Sie das Anmeldepasswort eines IAM-Nutzers zurücksetzen möchten, verwenden Sie die -replace, wenn Sie terraform apply ausführen.

Angenommen, das folgende Nutzerprofil für die Anmeldung

resource "aws_iam_user" "example" {
  name          = "[e-mail]"
  path          = "/users/"
  force_destroy = true
}

resource "aws_iam_user_login_profile" "example" {
  user    = aws_iam_user.example.name
  pgp_key = "keybase:some_person_that_exists"
}

Führen Sie den folgenden Befehl aus, um das Passwort des Anmeldeprofils des Nutzers zurückzusetzen.

terraform apply -replace="aws_iam_user_login_profile.example"

AWS-Konsole

So deaktivieren Sie Anmeldedaten für inaktive Konten:

1. Öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
2. Wählen Sie „Nutzer“ aus.
3. Wählen Sie den Namen des Nutzers aus, dessen Anmeldedaten älter als 90 Tage sind bzw. seit mehr als 90 Tagen nicht verwendet wurden.
4. Wählen Sie „Sicherheitsanmeldedaten“ aus.
5. Wählen Sie für alle Anmeldedaten und Zugriffsschlüssel, die seit mindestens 90 Tagen nicht verwendet wurden, die Option „Inaktiv machen“ aus.

So erzwingen Sie bei der nächsten Anmeldung ein neues Passwort für Konsolennutzer:

1. Öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
2. Wählen Sie „Nutzer“ aus.
3. Wählen Sie den Namen des Nutzers aus, dessen Anmeldedaten älter als 90 Tage sind bzw. seit mehr als 90 Tagen nicht verwendet wurden.
4. Wählen Sie „Sicherheitsanmeldedaten“ aus.
5. Wählen Sie unter „Anmeldedaten und Konsolenpasswort“ die Option „Verwalten“ aus.
6. Legen Sie ein neues Passwort fest (automatisch generiert oder benutzerdefiniert).
7. Setzen Sie ein Häkchen bei „Passwort zurücksetzen erforderlich“.
8. Wählen Sie „Übernehmen“ aus.

AWS-CLI

Zugriffsschlüssel deaktivieren

aws iam update-access-key \
  --access-key-id <value> \
  --status "Inactive"

Zugriffsschlüssel löschen

aws iam delete-access-key \
  --access-key-id <value>

Passwort für das Anmeldeprofil eines Nutzers zurücksetzen

aws iam update-login-profile \
  --user-name "[e-mail]" \
  --password <temporary_password> \
  --password-reset-required

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Kms Cmk Not Scheduled For Deletion

Kategoriename in der API: KMS_CMK_NOT_SCHEDULED_FOR_DELETION

Mit dieser Einstellung wird geprüft, ob KMS-Schlüssel zum Löschen geplant sind. Die Prüfung schlägt fehl, wenn ein KMS-Schlüssel zum Löschen geplant ist.

KMS-Schlüssel können nach dem Löschen nicht wiederhergestellt werden. Daten, die mit einem KMS-Schlüssel verschlüsselt wurden, können auch nicht wiederhergestellt werden, wenn der KMS-Schlüssel gelöscht wird. Wenn sinnvolle Daten mit einem KMS-Schlüssel verschlüsselt wurden, der zum Löschen vorgemerkt ist, sollten Sie die Daten entschlüsseln oder mit einem neuen KMS-Schlüssel neu verschlüsseln, es sei denn, Sie führen absichtlich eine kryptografische Vernichtung durch.

Wenn ein KMS-Schlüssel zum Löschen geplant ist, wird eine obligatorische Wartezeit erzwungen, damit das Löschen rückgängig gemacht werden kann, falls es irrtümlich geplant wurde. Die Standardwartezeit beträgt 30 Tage, kann aber auf bis zu 7 Tage reduziert werden, wenn das Löschen des KMS-Schlüssels geplant ist. Während der Wartezeit kann die geplante Löschung abgebrochen werden und der KMS-Schlüssel wird nicht gelöscht.

Weitere Informationen zum Löschen von KMS-Schlüsseln finden Sie im Entwicklerhandbuch für den AWS Key Management Service unter KMS-Schlüssel löschen.

Empfehlung: Prüfen Sie alle CMKs darauf, dass sie nicht zum Löschen geplant sind

Informationen zum Abbrechen eines geplanten Löschens eines KMS-Schlüssels finden Sie im Entwicklerhandbuch für den AWS Key Management Service unter Schlüssellöschung abbrechen (Console).

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Lambda Concurrency Check

Kategoriename in der API: LAMBDA_CONCURRENCY_CHECK

Prüft, ob für die Lambda-Funktion das Limit für die gleichzeitige Ausführung auf Funktionsebene konfiguriert ist. Die Regel hat den Status „NICHT KONFORM“, wenn für die Lambda-Funktion kein Limit für die gleichzeitige Ausführung auf Funktionsebene konfiguriert ist.

Empfehlung: Prüfen Sie, ob für Lambda-Funktionen das Limit für die gleichzeitige Ausführung auf Funktionsebene konfiguriert ist

Informationen zum Konfigurieren eines Limits für die gleichzeitige Ausführung auf Funktionsebene finden Sie in der AWS Lambda-Dokumentation unter Reservierte Nebenläufigkeit konfigurieren.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Lambda Dlq Check

Kategoriename in der API: LAMBDA_DLQ_CHECK

Prüft, ob eine Lambda-Funktion mit einer Dead-Letter-Warteschlange konfiguriert ist. Die Regel hat den Status „NICHT KONFORM“, wenn die Lambda-Funktion nicht mit einer Dead-Letter-Warteschlange konfiguriert ist.

Empfehlung: Prüfen Sie, ob Lambda-Funktionen mit einer Dead-Letter-Warteschlange konfiguriert sind

Informationen zum Aktualisieren von Lambda-Funktionen für die Verwendung von Dead-Letter-Warteschlangen finden Sie in der AWS-Dokumentation unter Dead-Letter-Warteschlangen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Lambda Function Public Access Prohibited

Kategoriename in der API: LAMBDA_FUNCTION_PUBLIC_ACCESS_PROHIBITED

Gemäß den AWS-Best Practices sollte die Lambda-Funktion nicht öffentlich zugänglich sein. Mit dieser Richtlinie werden alle Lambda-Funktionen geprüft, die in allen aktivierten Regionen Ihres Kontos bereitgestellt werden. Die Prüfung schlägt fehl, wenn sie so konfiguriert sind, dass der öffentliche Zugriff zulässig ist.

Empfehlung: Prüfen Sie, ob die an die Lambda-Funktion angehängte Richtlinie den öffentlichen Zugriff verhindert

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

Terraform

Im folgenden Beispiel wird gezeigt, wie Sie mit Terraform eine IAM-Rolle bereitstellen, den Zugriff auf eine Lambda-Funktion einschränken und diese Rolle an die Lambda-Funktion anhängen.

resource "aws_iam_role" "iam_for_lambda" {
  name = "iam_for_lambda"

  assume_role_policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Effect": "Allow",
      "Sid": ""
    }
  ]
}
EOF
}

resource "aws_lambda_function" "test_lambda" {
  filename      = "lambda_function_payload.zip"
  function_name = "lambda_function_name"
  role          = aws_iam_role.iam_for_lambda.arn
  handler       = "index.test"

  source_code_hash = filebase64sha256("lambda_function_payload.zip")

  runtime = "nodejs12.x"

}

AWS-Konsole

Wenn eine Lambda-Funktion diese Prüfung nicht besteht, bedeutet das, dass die ressourcenbasierte Richtlinienbeschreibung für die Lambda-Funktion den öffentlichen Zugriff zulässt.

Um das Problem zu beheben, müssen Sie die Richtlinie aktualisieren, um die Berechtigungen zu entfernen oder die Bedingung AWS:SourceAccount hinzuzufügen. Sie können die ressourcenbasierte Richtlinie nur über die Lambda API aktualisieren.

In der folgenden Anleitung wird die Richtlinie über die Console geprüft und die Berechtigungen über die AWS-Befehlszeile entfernt.

Ressourcenbasierte Richtlinie für eine Lambda-Funktion aufrufen

1. Öffnen Sie die AWS Lambda-Konsole unter https://console.aws.amazon.com/lambda/.
2. Wählen Sie im Navigationsbereich „Funktionen“ aus.
3. Wählen Sie die Funktion aus.
4. Wählen Sie „Berechtigungen“ aus. Die ressourcenbasierte Richtlinie enthält die Berechtigungen, die angewendet werden, wenn ein anderes Konto oder ein anderer AWS-Dienst versucht, auf die Funktion zuzugreifen.
5. Prüfen Sie die ressourcenbasierte Richtlinie.
6. Identifizieren Sie die Richtlinienbeschreibung mit Werten im Feld „Principal“, die die Richtlinie öffentlich machen. Beispiel: "*" oder { "AWS": "*" }

Sie können die Richtlinie nicht über die Console bearbeiten. Wenn Sie Berechtigungen aus der Funktion entfernen möchten, verwenden Sie den Befehl „remove-permission“ in der AWS CLI.

Notieren Sie sich den Wert der Abfrage-ID (Statement ID, Sid) für die Abfrage, die Sie entfernen möchten.

AWS-CLI

Wenn Sie mit der Befehlszeile Berechtigungen aus einer Lambda-Funktion entfernen möchten, geben Sie den Befehl remove-permission wie unten beschrieben ein.

aws lambda remove-permission \
--function-name <value> \
--statement-id <value>

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Lambda Inside Vpc

Kategoriename in der API: LAMBDA_INSIDE_VPC

Prüft, ob sich eine Lambda-Funktion in einer VPC befindet. Möglicherweise werden für Lambda@Edge-Ressourcen Fehler angezeigt.

Die VPC-Subnetz-Routingkonfiguration wird nicht ausgewertet, um die öffentliche Erreichbarkeit zu bestimmen.

Empfehlung: Prüfen Sie, ob Lambda-Funktionen in einer VPC vorhanden sind

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

So konfigurieren Sie eine Funktion für die Verbindung mit privaten Subnetzen in einer Virtual Private Cloud (VPC) in Ihrem Konto:

1. Öffnen Sie die AWS Lambda-Konsole unter https://console.aws.amazon.com/lambda/.
2. Rufen Sie „Functions“ (Funktionen) auf und wählen Sie dann Ihre Lambda-Funktion aus.
3. Scrollen Sie zu „Netzwerk“ und wählen Sie ein VPC mit den Konnektivitätsanforderungen der Funktion aus.
4. Wenn Sie Ihre Funktionen im Hochverfügbarkeitsmodus ausführen möchten, empfiehlt Security Hub, mindestens zwei Subnetze auszuwählen.
5. Wählen Sie mindestens eine Sicherheitsgruppe aus, die die Konnektivitätsanforderungen der Funktion erfüllt.
6. Wählen Sie „Speichern“ aus.

Weitere Informationen finden Sie im AWS Lambda Developer Guide im Abschnitt zum Konfigurieren einer Lambda-Funktion für den Zugriff auf Ressourcen in einer VPC.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Mfa Delete Enabled S3 Buckets

Kategoriename in der API: MFA_DELETE_ENABLED_S3_BUCKETS

Sobald die Funktion „MFA-Löschungen“ für Ihren sensiblen und klassifizierten S3-Bucket aktiviert ist, müssen Nutzer zwei Authentifizierungsmethoden verwenden.

Empfehlung: Achten Sie darauf, dass MFA-Löschungen für S3-Buckets aktiviert sind

Führen Sie die folgenden Schritte aus, um die MFA-Löschfunktion für einen S3-Bucket zu aktivieren.

Hinweis:
– Sie können die Funktion „MFA Delete“ nicht über die AWS Management Console aktivieren. Sie müssen die AWS CLI oder API verwenden.
– Sie müssen Ihr Root-Konto verwenden, um MFA-Löschungen für S3-Buckets zu aktivieren.

Über die Befehlszeile:

1. Befehl „s3api put-bucket-versioning“ ausführen

aws s3api put-bucket-versioning --profile my-root-profile --bucket Bucket_Name --versioning-configuration Status=Enabled,MFADelete=Enabled --mfa “arn:aws:iam::aws_account_id:mfa/root-account-mfa-device passcode”

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Mfa Enabled Root User Account

Kategoriename in der API: MFA_ENABLED_ROOT_USER_ACCOUNT

Das Nutzerkonto „root“ ist der Nutzer mit den meisten Berechtigungen in einem AWS-Konto. Die Multi-Faktor-Authentifizierung (MFA) bietet neben einem Nutzernamen und Passwort einen zusätzlichen Schutz. Wenn die Multi-Faktor-Authentifizierung aktiviert ist, werden Nutzer bei der Anmeldung auf einer AWS-Website nach ihrem Nutzernamen und Passwort sowie nach einem Authentifizierungscode von ihrem AWS-MFA-Gerät gefragt.

Hinweis:Wenn die virtuelle MFA für Root-Konten verwendet wird, wird empfohlen, dass das verwendete Gerät KEIN privates Gerät ist, sondern ein spezielles Mobilgerät (Tablet oder Smartphone), das unabhängig von einzelnen privaten Geräten aufgeladen und gesichert wird. („nicht persönliche virtuelle MFA“) Dadurch wird das Risiko verringert, den Zugriff auf die MFA aufgrund von Geräteverlust, Gerätetausch oder wenn die Person, die das Gerät besitzt, nicht mehr im Unternehmen beschäftigt ist, zu verlieren.

Empfehlung: Achten Sie darauf, dass MFA für das Root-Nutzerkonto aktiviert ist.

Gehen Sie so vor, um die Bestätigung in zwei Schritten für das Root-Nutzerkonto einzurichten:

1. Melden Sie sich in der AWS Management Console an und öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.

Hinweis: Wenn Sie MFA-Geräte für das AWS-Konto „root“ verwalten möchten, müssen Sie sich mit den Anmeldedaten für das „root“-Konto in AWS anmelden. Sie können MFA-Geräte für das Root-Konto nicht mit anderen Anmeldedaten verwalten.

2. Wählen Sie Dashboard aus und maximieren Sie unter Security Status die Ansicht von Activate MFA in Ihrem Stammkonto.
3. Activate MFA auswählen
4. Wählen Sie im Assistenten das Gerät A virtual MFA und dann Next Step aus .
5. IAM generiert und zeigt Konfigurationsinformationen für das virtuelle MFA-Gerät an, einschließlich einer QR-Code-Grafik. Die Abbildung stellt den geheimen Konfigurationsschlüssel dar, der auf Geräten, die keine QR-Codes unterstützen, manuell eingegeben werden kann.
6. Öffnen Sie die Anwendung für die virtuelle Multi-Faktor-Authentifizierung. Eine Liste der Apps, die Sie zum Hosten virtueller MFA-Geräte verwenden können, finden Sie unter Virtuelle MFA-Anwendungen. Wenn die virtuelle MFA-Anwendung mehrere Konten (mehrere virtuelle MFA-Geräte) unterstützt, wählen Sie die Option zum Erstellen eines neuen Kontos (eines neuen virtuellen MFA-Geräts) aus.
7. Prüfen Sie, ob die MFA-App QR-Codes unterstützt, und führen Sie dann einen der folgenden Schritte aus:

• Scannen Sie den QR-Code mit der App. Sie können beispielsweise das Kamerasymbol oder eine Option wie „Code scannen“ auswählen und dann mit der Kamera des Geräts den Code scannen.
• Wählen Sie im Assistenten zum Verwalten des MFA-Geräts die Option „Secret Key für manuelle Konfiguration anzeigen“ aus und geben Sie den geheimen Konfigurationsschlüssel in Ihre MFA-Anwendung ein.

Wenn Sie fertig sind, generiert das virtuelle MFA-Gerät Einmalpasswörter.

Geben Sie im Assistenten zum Verwalten des MFA-Geräts im Feld „Authentifizierungscode 1“ das Einmalpasswort ein, das derzeit auf dem virtuellen MFA-Gerät angezeigt wird. Warten Sie bis zu 30 Sekunden, bis das Gerät ein neues Einmalpasswort generiert. Geben Sie dann das zweite Einmalpasswort in das Feld „Authentifizierungscode 2“ ein. Wählen Sie „Virtuelle MFA zuweisen“ aus.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Multi Factor Authentication Mfa Enabled All Iam Users Console

Kategoriename in der API: MULTI_FACTOR_AUTHENTICATION_MFA_ENABLED_ALL_IAM_USERS_CONSOLE

Die Multi-Faktor-Authentifizierung (MFA) bietet eine zusätzliche Authentifizierungsebene, die über herkömmliche Anmeldedaten hinausgeht. Wenn die MFA aktiviert ist, werden Nutzer bei der Anmeldung in der AWS Console aufgefordert, ihren Nutzernamen und ihr Passwort sowie einen Authentifizierungscode aus ihrem physischen oder virtuellen MFA-Token anzugeben. Wir empfehlen, die Multi-Faktor-Authentifizierung für alle Konten zu aktivieren, die ein Console-Passwort haben.

Empfehlung: Achten Sie darauf, dass die Multi-Faktor-Authentifizierung (MFA) für alle IAM-Nutzer, die ein Console-Passwort haben, aktiviert ist

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

1. Melden Sie sich in der AWS Management Console an und öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
2. Wählen Sie im linken Bereich Users aus.
3. Wählen Sie in der Liste User Name den Namen des Nutzers aus, für den die MFA aktiviert werden soll.
4. Wählen Sie den Tab Security Credentials und dann Manage MFA Device aus.
5. Wählen Sie unter Manage MFA Device wizard das Gerät Virtual MFA und dann Continue aus.

IAM generiert und zeigt Konfigurationsinformationen für das virtuelle MFA-Gerät an, einschließlich einer QR-Code-Grafik. Die Grafik stellt den geheimen Konfigurationsschlüssel dar, der auf Geräten, die keine QR-Codes unterstützen, manuell eingegeben werden kann.

6. Öffnen Sie die Anwendung für die virtuelle Multi-Faktor-Authentifizierung. Eine Liste der Apps, die Sie zum Hosten virtueller MFA-Geräte verwenden können, finden Sie unter „Virtual MFA Applications“ (Virtuelle MFA-Anwendungen) unter https://aws.amazon.com/iam/details/mfa/#Virtual_MFA_Applications. Wenn die virtuelle MFA-Anwendung mehrere Konten (mehrere virtuelle MFA-Geräte) unterstützt, wählen Sie die Option zum Erstellen eines neuen Kontos (eines neuen virtuellen MFA-Geräts) aus.
7. Prüfen Sie, ob die MFA-App QR-Codes unterstützt, und führen Sie dann einen der folgenden Schritte aus:

• Scannen Sie den QR-Code mit der App. Sie können beispielsweise das Kamerasymbol oder eine Option wie „Code scannen“ auswählen und dann mit der Kamera des Geräts den Code scannen.
• Wählen Sie im Assistenten zum Verwalten des MFA-Geräts die Option „Secret Key für manuelle Konfiguration anzeigen“ aus und geben Sie den geheimen Konfigurationsschlüssel in Ihre MFA-Anwendung ein.

Danach generiert das virtuelle MFA-Gerät Einmalpasswörter.

8. Geben Sie in das Feld Manage MFA Device wizard unter MFA Code 1 box die one-time password ein, die derzeit auf dem virtuellen MFA-Gerät angezeigt wird. Warten Sie bis zu 30 Sekunden, bis das Gerät ein neues Einmalpasswort generiert. Geben Sie dann die zweite one-time password in die MFA Code 2 box ein.

9. Klicken Sie auf Assign MFA.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

No Network Acls Allow Ingress 0 0 0 0 Remote Server Administration

Kategoriename in der API: NO_NETWORK_ACLS_ALLOW_INGRESS_0_0_0_0_REMOTE_SERVER_ADMINISTRATION

Die Network Access Control List-Funktion (NACL) ermöglicht die zustandslose Filterung von eingehenden und ausgehenden Netzwerkverkehr zu AWS-Ressourcen. Es wird empfohlen, dass keine NACL den uneingeschränkten Zugriff auf Remote-Server-Verwaltungsports zulässt, z. B. SSH auf Port 22 und RDP auf Port 3389, und zwar weder über das TDP-Protokoll (6), UDP-Protokoll (17) noch über das ALL-Protokoll (-1).

Empfehlung: Achten Sie darauf, dass keine Netzwerk-ACLs eingehenden Traffic von 0.0.0.0/0 an Remote-Server-Verwaltungsports zulassen

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

Gehen Sie so vor:
1. Melden Sie sich in der AWS Management Console unter https://console.aws.amazon.com/vpc/home an.
2. Klicken Sie im linken Bereich auf Network ACLs
3. Führen Sie für jede Netzwerk-ACL, die korrigiert werden soll, die folgenden Schritte aus:
– Wählen Sie die Netzwerk-ACL aus.
– Klicken Sie auf den Tab Inbound Rules.
– Klicken Sie auf Edit inbound rules.
– Führen Sie einen der folgenden Schritte aus: A) Aktualisieren Sie das Feld „Quelle“ auf einen anderen Bereich als 0.0.0.0/0 oder B) klicken Sie auf Delete, um die fehlerhafte eingehende Regel zu entfernen.
– Klicken Sie auf Save.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

No Root User Account Access Key Exists

Kategoriename in der API: NO_ROOT_USER_ACCOUNT_ACCESS_KEY_EXISTS

Das Nutzerkonto „root“ ist der Nutzer mit den meisten Berechtigungen in einem AWS-Konto. AWS-Zugriffsschlüssel ermöglichen programmatischen Zugriff auf ein bestimmtes AWS-Konto. Es wird empfohlen, alle Zugriffsschlüssel zu löschen, die mit dem Root-Nutzerkonto verknüpft sind.

Empfehlung: Achten Sie darauf, dass kein Zugriffsschlüssel für das Root-Nutzerkonto vorhanden ist.

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

1. Melden Sie sich als „root“ in der AWS Management Console an und öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
2. Klicken Sie rechts oben auf <root_account> und wählen Sie in der Drop-down-Liste My Security Credentials aus.
3. Klicken Sie im Pop-out-Bildschirm auf Continue to Security Credentials.
4. Klicken Sie auf Access Keys (Zugriffsschlüssel-ID und geheimer Zugriffsschlüssel).
5. In der Spalte Status (falls aktive Schlüssel vorhanden sind)
6. Klicken Sie auf Delete. Hinweis: Gelöschte Schlüssel können nicht wiederhergestellt werden.

Hinweis: Ein Schlüssel kann zwar inaktiv gemacht werden, er wird aber weiterhin im Befehlszeilenbefehl des Prüfverfahrens angezeigt. Dies kann dazu führen, dass ein Schlüssel fälschlicherweise als nicht konform gekennzeichnet wird.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

No Security Groups Allow Ingress 0 0 0 0 Remote Server Administration

Kategoriename in der API: NO_SECURITY_GROUPS_ALLOW_INGRESS_0_0_0_0_REMOTE_SERVER_ADMINISTRATION

Sicherheitsgruppen ermöglichen die zustandsabhängige Filterung von eingehenden und ausgehenden Netzwerkverkehr zu AWS-Ressourcen. Es wird empfohlen, dass keine Sicherheitsgruppe uneingeschränkten Zugriff auf Remote-Serververwaltungsports zulässt, z. B. SSH auf Port 22 und RDP auf Port 3389, und zwar weder über das TDP-Protokoll (6), UDP-Protokoll (17) noch über das ALL-Protokoll (-1).

Empfehlung: Achten Sie darauf, dass keine Sicherheitsgruppen eingehenden Traffic von 0.0.0.0/0 an Remote-Server-Verwaltungsports zulassen

So implementieren Sie den vorgeschriebenen Zustand:

1. Melden Sie sich unter https://console.aws.amazon.com/vpc/home in der AWS Management Console an.
2. Klicken Sie im linken Bereich auf Security Groups.
3. Führen Sie für jede Sicherheitsgruppe die folgenden Schritte aus:
4. Sicherheitsgruppe auswählen
5. Klicken Sie auf den Tab Inbound Rules.
6. Klicken Sie auf die Schaltfläche Edit inbound rules.
7. Regeln auswählen, die bearbeitet oder entfernt werden sollen
8. Aktualisieren Sie entweder A) das Feld „Quelle“ auf einen anderen Bereich als 0.0.0.0/0 oder B) klicken Sie auf Delete, um die fehlerhafte eingehende Regel zu entfernen.
9. Klicken Sie auf Save rules.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

No Security Groups Allow Ingress 0 Remote Server Administration

Kategoriename in der API: NO_SECURITY_GROUPS_ALLOW_INGRESS_0_REMOTE_SERVER_ADMINISTRATION

Sicherheitsgruppen ermöglichen die zustandsabhängige Filterung von eingehenden und ausgehenden Netzwerkverkehr zu AWS-Ressourcen. Es wird empfohlen, dass keine Sicherheitsgruppe uneingeschränkten Zugriff auf Remote-Serververwaltungsports zulässt, z. B. SSH auf Port 22 und RDP auf Port 3389.

Empfehlung: Achten Sie darauf, dass keine Sicherheitsgruppen eingehenden Traffic von ::/0 an Remote-Server-Verwaltungsports zulassen

So implementieren Sie den vorgeschriebenen Zustand:

1. Melden Sie sich unter https://console.aws.amazon.com/vpc/home in der AWS Management Console an.
2. Klicken Sie im linken Bereich auf Security Groups.
3. Führen Sie für jede Sicherheitsgruppe die folgenden Schritte aus:
4. Sicherheitsgruppe auswählen
5. Klicken Sie auf den Tab Inbound Rules.
6. Klicken Sie auf die Schaltfläche Edit inbound rules.
7. Regeln auswählen, die bearbeitet oder entfernt werden sollen
8. Aktualisieren Sie entweder A) das Feld „Quelladresse“ auf einen anderen Bereich als ::/0 oder B) klicken Sie auf Delete, um die fehlerhafte eingehende Regel zu entfernen.
9. Klicken Sie auf Save rules.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

One Active Access Key Available Any Single Iam User

Kategoriename in der API: ONE_ACTIVE_ACCESS_KEY_AVAILABLE_ANY_SINGLE_IAM_USER

Zugriffsschlüssel sind langfristige Anmeldedaten für einen IAM-Nutzer oder den Nutzer „root“ des AWS-Kontos. Mit Zugriffsschlüsseln können Sie programmatische Anfragen an die AWS-Befehlszeile oder die AWS API signieren (direkt oder mit dem AWS SDK).

Empfehlung: Achten Sie darauf, dass pro IAM-Nutzer nur ein aktiver Zugriffsschlüssel verfügbar ist.

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

1. Melden Sie sich in der AWS Management Console an und rufen Sie das IAM-Dashboard unter https://console.aws.amazon.com/iam/ auf.
2. Wählen Sie im linken Navigationsbereich Users aus.
3. Klicken Sie auf den IAM-Nutzernamen, den Sie prüfen möchten.
4. Wählen Sie auf der Seite „IAM-Nutzerkonfiguration“ den Tab Security Credentials aus.
5. Wählen Sie im Bereich Access Keys einen Zugriffsschlüssel aus, der weniger als 90 Tage alt ist. Dies sollte der einzige aktive Schlüssel sein, mit dem dieser IAM-Nutzer programmatisch auf AWS-Ressourcen zugreift. Testen Sie Ihre Anwendung(en), um sicherzustellen, dass der ausgewählte Zugriffsschlüssel funktioniert.
6. Wählen Sie im selben Bereich Access Keys die nicht aktiven Zugriffsschlüssel aus (außer dem ausgewählten) und deaktivieren Sie sie, indem Sie auf den Link Make Inactive klicken.
7. Wenn das Bestätigungsfeld Change Key Status angezeigt wird, klicken Sie auf Deactivate, um den ausgewählten Schlüssel zu deaktivieren.
8. Wiederholen Sie die Schritte 3 bis 7 für jeden IAM-Nutzer in Ihrem AWS-Konto.

AWS-CLI

1. Wählen Sie anhand der Informationen zum IAM-Nutzer und zum Zugriffsschlüssel in der Audit CLI einen Zugriffsschlüssel aus, der nicht älter als 90 Tage ist. Dies sollte der einzige aktive Schlüssel sein, mit dem dieser IAM-Nutzer programmatisch auf AWS-Ressourcen zugreift. Testen Sie Ihre Anwendung(en), um sicherzustellen, dass der ausgewählte Zugriffsschlüssel funktioniert.

2. Führen Sie den Befehl update-access-key unten mit dem IAM-Nutzernamen und den IDs der nicht aktiven Zugriffsschlüssel aus, um die nicht benötigten Schlüssel zu deaktivieren. Im Bereich „Audit“ finden Sie die nicht benötigte Zugriffsschlüssel-ID für den ausgewählten IAM-Nutzer.

Hinweis: Der Befehl gibt keine Ausgabe zurück:

aws iam update-access-key --access-key-id <access-key-id> --status Inactive --user-name <user-name>

3. Führen Sie den Befehl list-access-keys noch einmal für den IAM-Nutzer aus, um zu prüfen, ob das ausgewählte Zugriffsschlüsselpaar erfolgreich erstellt wurde:deactivated

aws iam list-access-keys --user-name <user-name>

• Die Befehlsausgabe sollte die Metadaten für jeden Zugriffsschlüssel enthalten, der mit dem IAM-Nutzer verknüpft ist. Wenn das inaktive Schlüsselpaar Status auf Inactive gesetzt ist, wurde der Schlüssel erfolgreich deaktiviert und die IAM-Konfiguration für den Nutzerzugriff entspricht jetzt dieser Empfehlung.

4. Wiederholen Sie die Schritte 1 bis 3 für jeden IAM-Nutzer in Ihrem AWS-Konto.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Public Access Given Rds Instance

Kategoriename in der API: PUBLIC_ACCESS_GIVEN_RDS_INSTANCE

Achten Sie darauf, dass in Ihrem AWS-Konto bereitgestellte RDS-Datenbankinstanzen den unbefugten Zugriff einschränken, um Sicherheitsrisiken zu minimieren. Wenn Sie den Zugriff auf eine öffentlich zugängliche RDS-Datenbankinstanz einschränken möchten, müssen Sie das Flag „Öffentlich zugänglich“ für die Datenbank deaktivieren und die mit der Instanz verknüpfte VPC-Sicherheitsgruppe aktualisieren.

Empfehlung: Achten Sie darauf, dass RDS-Instanzen keine öffentliche Zugriffsberechtigung gewährt wird

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

1. Melden Sie sich in der AWS Management Console an und rufen Sie das RDS-Dashboard unter https://console.aws.amazon.com/rds/ auf.
2. Klicken Sie im Navigationsbereich im RDS-Dashboard auf Databases.
3. Wählen Sie die RDS-Instanz aus, die Sie aktualisieren möchten.
4. Klicken Sie im oberen Menü des Dashboards auf Modify.
5. Klicken Sie im Bereich „DB-Instanz ändern“ unter Connectivity auf Additional connectivity configuration und ändern Sie den Wert für Publicly Accessible in „Nicht öffentlich zugänglich“, um den öffentlichen Zugriff einzuschränken. Führen Sie die folgenden Schritte aus, um die Subnetzkonfigurationen zu aktualisieren:
   – Wählen Sie den Tab Connectivity and security aus und klicken Sie im Bereich Networking auf den VPC-Attributwert.
   – Wählen Sie im unteren Bereich des VPC-Dashboards den Tab Details aus und klicken Sie auf den Wert des Attributs „Routentabellen-Konfiguration“.
   – Wählen Sie auf der Seite mit den Details der Routentabelle im unteren Bereich des Dashboards den Tab „Routen“ aus und klicken Sie auf Edit routes.
   – Aktualisieren Sie auf der Seite „Routen bearbeiten“ das Ziel des Ziels, das auf igw-xxxxx festgelegt ist, und klicken Sie auf Save Routen.
6. Klicken Sie im Bereich „DB-Instanz ändern“ auf Continue und führen Sie im Bereich „Planen von Änderungen“ eine der folgenden Aktionen aus:
   – Wählen Sie „Während des nächsten geplanten Wartungsfensters anwenden“ aus, um die Änderungen automatisch während des nächsten geplanten Wartungsfensters anzuwenden.
   – Wählen Sie „Sofort anwenden“ aus, um die Änderungen sofort anzuwenden. Bei dieser Option werden alle ausstehenden Änderungen unabhängig von der Einstellung des Wartungsfensters für diese RDS-Datenbankinstanz so schnell wie möglich asynchron angewendet. Beachten Sie, dass auch alle Änderungen angewendet werden, die sich in der Warteschlange für ausstehende Änderungen befinden. Wenn für eine der ausstehenden Änderungen eine Ausfallzeit erforderlich ist, kann die Auswahl dieser Option zu unerwarteten Ausfallzeiten der Anwendung führen.
7. Wiederholen Sie die Schritte 3 bis 6 für jede RDS-Instanz, die in der aktuellen Region verfügbar ist.
8. Ändern Sie die AWS-Region in der Navigationsleiste, um den Vorgang für andere Regionen zu wiederholen.

AWS-CLI

1. Führen Sie den Befehl describe-db-instances aus, um alle RDS-Datenbanknamens-IDs aufzulisten, die in der ausgewählten AWS-Region verfügbar sind:

aws rds describe-db-instances --region <region-name> --query 'DBInstances[*].DBInstanceIdentifier'

2. Die Befehlsausgabe sollte die ID jeder Datenbankinstanz zurückgeben.
3. Führen Sie den Befehl modify-db-instance aus, um die Konfiguration der ausgewählten RDS-Instanz zu ändern. Deaktivieren Sie dann mit dem folgenden Befehl das Publicly Accessible-Flag für die ausgewählten RDS-Instanzen. Für diesen Befehl wird das Flag „apply-immediately“ verwendet. Wenn Sie to avoid any downtime --no-apply-immediately flag can be used verwenden möchten, gehen Sie so vor:

aws rds modify-db-instance --region <region-name> --db-instance-identifier <db-name> --no-publicly-accessible --apply-immediately

4. Die Befehlsausgabe sollte die PubliclyAccessible-Konfiguration unter ausstehenden Werten enthalten und sollte zum angegebenen Zeitpunkt angewendet werden.
5. Das Aktualisieren des Internet-Gateway-Ziels über die AWS CLI wird derzeit nicht unterstützt. Verwenden Sie die AWS Console, um Informationen zum Internet-Gateway zu aktualisieren.
6. Wiederholen Sie die Schritte 1 bis 5 für jede RDS-Instanz, die in der aktuellen Region bereitgestellt wurde.
7. Ändern Sie die AWS-Region mit dem Filter „–region“, um den Vorgang für andere Regionen zu wiederholen.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Rds Enhanced Monitoring Enabled

Kategoriename in der API: RDS_ENHANCED_MONITORING_ENABLED

Das erweiterte Monitoring bietet Echtzeitmesswerte zum Betriebssystem, auf dem die RDS-Instanz ausgeführt wird, über einen in der Instanz installierten Agenten.

Weitere Informationen finden Sie unter Betriebssystemmesswerte mit erweitertem Monitoring überwachen.

Empfehlung: Prüfen Sie, ob erweitertes Monitoring für alle RDS-Datenbankinstanzen aktiviert ist

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

Terraform

Aktivieren Sie das erweiterte Monitoring für Ihre RDS-Instanzen wie unten beschrieben, um dieses Kontrollelement zu erfüllen:

IAM-Rolle für RDS erstellen:

resource "aws_iam_role" "rds_logging" {
  name = "CustomRoleForRDSMonitoring"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Sid    = "CustomRoleForRDSLogging"
        Principal = {
          Service = "monitoring.rds.amazonaws.com"
        }
      },
    ]
  })
}

Rufen Sie die von AWS verwaltete Richtlinie für das erweiterte RDS-Monitoring ab:

data "aws_iam_policy" "rds_logging" {
  name = "AmazonRDSEnhancedMonitoringRole"
}

Hängen Sie die Richtlinie an die Rolle an:

resource "aws_iam_policy_attachment" "rds_logging" {
  name       = "AttachRdsLogging"
  roles      = [aws_iam_role.rds_logging.name]
  policy_arn = data.aws_iam_policy.rds_logging.arn
}

Definieren Sie ein Monitoring-Intervall und eine Monitoring-Rolle-ARN für die RDS-Instanz, die gegen die Richtlinie verstößt, um das erweiterte Monitoring zu aktivieren:

resource "aws_db_instance" "default" {
  identifier           = "test-rds"
  allocated_storage    = 10
  engine               = "mysql"
  engine_version       = "5.7"
  instance_class       = "db.t3.micro"
  db_name              = "mydb"
  username             = "foo"
  password             = "foobarbaz"
  parameter_group_name = "default.mysql5.7"
  skip_final_snapshot  = true
  monitoring_interval  = 60
  monitoring_role_arn  = aws_iam_role.rds_logging.arn
}

AWS-Konsole

Sie können das erweiterte Monitoring aktivieren, wenn Sie eine DB-Instanz, einen Multi-AZ-DB-Cluster oder ein Lesereplikat erstellen oder eine DB-Instanz oder einen Multi-AZ-DB-Cluster ändern. Wenn Sie eine Datenbankinstanz ändern, um die erweiterte Überwachung zu aktivieren, müssen Sie die Datenbankinstanz nicht neu starten, damit die Änderung wirksam wird.

Sie können das erweiterte Monitoring in der RDS-Konsole aktivieren, indem Sie auf der Seite „Datenbanken“ eine der folgenden Aktionen ausführen:

• Datenbankinstanz oder Multi-AZ-Datenbankcluster erstellen – „Datenbank erstellen“ auswählen
• Lesereplikat erstellen: Wählen Sie „Aktionen“ und dann „Lesereplikat erstellen“ aus.
• DB-Instanz oder Multi-AZ-DB-Cluster ändern: Wählen Sie „Ändern“ aus.

Erweitertes Monitoring in der RDS-Konsole aktivieren oder deaktivieren

1. Scrollen Sie zu „Zusätzliche Konfiguration“.
2. Wählen Sie unter „Monitoring“ die Option „Erweitertes Monitoring für Ihre Datenbankinstanz oder Ihr Lesereplikat aktivieren“ aus. Wenn Sie das erweiterte Monitoring deaktivieren möchten, wählen Sie „Erweitertes Monitoring deaktivieren“ aus.
3. Legen Sie die Eigenschaft „Monitoring Role“ auf die von Ihnen erstellte IAM-Rolle fest, damit Amazon RDS für Sie mit Amazon CloudWatch Logs kommunizieren kann. Wählen Sie „Default“ aus, damit RDS eine Rolle mit dem Namen „rds-monitoring-role“ für Sie erstellt.
4. Legen Sie für die Attributebene „Detaillierungsgrad“ das Intervall in Sekunden fest, das zwischen den Punkten liegt, an denen Messwerte für Ihre Datenbankinstanz oder Ihr Lesereplikat erfasst werden. Für die Detailebene kann einer der folgenden Werte festgelegt werden: 1, 5, 10, 15, 30 oder 60. Die RDS-Konsole wird frühestens alle 5 Sekunden aktualisiert. Wenn Sie in der RDS-Konsole eine Granularität von 1 Sekunde festlegen, werden die Messwerte trotzdem nur alle 5 Sekunden aktualisiert. Mit CloudWatch-Logs können Sie Messwertaktualisierungen im Sekundentakt abrufen.

AWS-CLI

Erstellen Sie die RDS-IAM-Rolle:

aws iam create-role \
  --role-name "CustomRoleForRDSMonitoring" \
  --assume-role-policy-document file://rds-assume-role.json

Hängen Sie die Richtlinie AmazonRDSEnhancedMonitoringRole an die Rolle an:

aws iam attach-role-policy \
  --role-name "CustomRoleForRDSMonitoring"\
  --policy-arn "arn:aws:iam::aws:policy/service-role/AmazonRDSEnhancedMonitoringRole"

Ändern Sie die RDS-Instanz, um das erweiterte Monitoring zu aktivieren. Legen Sie dazu --monitoring-interval und --monitoring-role-arn fest:

aws rds modify-db-instance \
  --db-instance-identifier "test-rds" \
  --monitoring-interval 30 \
  --monitoring-role-arn "arn:aws:iam::<account_id>:role/CustomRoleForRDSMonitoring"

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Rds Instance Deletion Protection Enabled

Kategoriename in der API: RDS_INSTANCE_DELETION_PROTECTION_ENABLED

Wenn Sie den Schutz vor Instanzlöschungen aktivieren, wird eine zusätzliche Schutzebene gegen das versehentliche Löschen der Datenbank oder das Löschen durch eine nicht autorisierte Entität bereitgestellt.

Wenn der Löschschutz aktiviert ist, kann eine RDS-Datenbankinstanz nicht gelöscht werden. Damit ein Löschantrag erfolgreich sein kann, muss der Löschschutz deaktiviert sein.

Empfehlung: Prüfen Sie, ob für alle RDS-Instanzen der Löschschutz aktiviert ist

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

Terraform

Legen Sie in der Ressource aws_db_instance deletion_protection auf true fest, um dieses Problem zu beheben.

resource "aws_db_instance" "example" {
  # ... other configuration ...
  deletion_protection = true
}

AWS-Konsole

Löschschutz für eine RDS-Datenbankinstanz aktivieren

1. Öffnen Sie die Amazon RDS-Konsole unter https://console.aws.amazon.com/rds/.
2. Wählen Sie im Navigationsbereich „Datenbanken“ und dann die Datenbankinstanz aus, die Sie ändern möchten.
3. Wählen Sie „Ändern“ aus.
4. Wählen Sie unter „Löschschutz“ die Option „Löschschutz aktivieren“ aus.
5. Wählen Sie „Weiter“ aus.
6. Wählen Sie unter „Planen von Änderungen“ aus, wann die Änderungen angewendet werden sollen. Sie haben die Wahl zwischen „Während des nächsten geplanten Wartungsfensters anwenden“ und „Sofort anwenden“.
7. Wählen Sie „DB-Instanz ändern“ aus.

AWS-CLI

Dasselbe gilt für die AWS-Befehlszeile. Legen Sie --deletion-protection wie unten gezeigt fest.

aws rds modify-db-instance \
  --db-instance-identifier = "test-rds" \
  --deletion-protection

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Rds In Backup Plan

Kategoriename in der API: RDS_IN_BACKUP_PLAN

Bei dieser Prüfung wird ermittelt, ob für Amazon RDS-Datenbankinstanzen ein Sicherungsplan vorhanden ist. Diese Prüfung schlägt fehl, wenn für eine RDS-Datenbankinstanz kein Sicherungsplan vorhanden ist.

AWS Backup ist ein vollständig verwalteter Sicherungsdienst, mit dem die Sicherung von Daten in AWS-Diensten zentralisiert und automatisiert wird. Mit AWS Backup können Sie Sicherungsrichtlinien erstellen, die als Sicherungspläne bezeichnet werden. Mit diesen Plänen können Sie Ihre Sicherungsanforderungen definieren, z. B. wie oft Ihre Daten gesichert werden sollen und wie lange diese Sicherungen aufbewahrt werden sollen. Wenn Sie RDS-Datenbankinstanzen in einen Sicherungsplan aufnehmen, können Sie Ihre Daten vor unbeabsichtigtem Verlust oder Löschen schützen.

Empfehlung: Für RDS-Datenbankinstanzen sollte es einen Sicherungsplan geben

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

Terraform

Legen Sie in der Ressource aws_db_instance für backup_retention_period einen Wert fest, der größer als 7 ist, um dieses Problem zu beheben.

resource "aws_db_instance" "example" {
  # ... other Configuration ...
  backup_retention_period = 7
}

AWS-Konsole

Automatische Sicherungen sofort aktivieren

1. Öffnen Sie die Amazon RDS-Konsole unter https://console.aws.amazon.com/rds/.
2. Wählen Sie im Navigationsbereich „Datenbanken“ und dann die Datenbankinstanz aus, die Sie ändern möchten.
3. Wählen Sie „Ändern“ aus, um die Seite „DB-Instanz ändern“ zu öffnen.
4. Wählen Sie unter „Sicherungsaufbewahrungszeitraum“ einen positiven Wert aus, z. B. 30 Tage, und klicken Sie dann auf „Weiter“.
5. Wählen Sie den Bereich „Planen von Änderungen“ aus und legen Sie fest, wann die Änderungen angewendet werden sollen: „Während des nächsten geplanten Wartungsfensters anwenden“ oder „Sofort anwenden“.
6. Wählen Sie dann auf der Bestätigungsseite „DB-Instanz ändern“ aus, um Ihre Änderungen zu speichern und automatische Sicherungen zu aktivieren.

AWS-CLI

Dasselbe gilt für die AWS-Befehlszeile. Wenn Sie automatische Sicherungen aktivieren möchten, ändern Sie backup-retention-period in einen Wert, der über 0 (Standardwert) liegt.

aws rds modify-db-instance --db-instance-identifier "test-rds" --backup-retention-period 7

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Rds Logging Enabled

Kategoriename in der API: RDS_LOGGING_ENABLED

Dabei wird geprüft, ob die folgenden Amazon RDS-Logs aktiviert und an CloudWatch gesendet werden.

Für RDS-Datenbanken sollten die relevanten Protokolle aktiviert sein. Die Datenbankprotokollierung bietet detaillierte Einträge zu Anfragen an RDS. Datenbankprotokolle können bei Sicherheits- und Zugriffsaudits helfen und bei der Diagnose von Verfügbarkeitsproblemen unterstützen.

Empfehlung: Prüfen Sie, ob exportierte Logs für alle RDS-Datenbankinstanzen aktiviert sind

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

Terraform

resource "aws_db_instance" "example" {
  # ... other configuration for MySQL ...
  enabled_cloudwatch_logs_exports = ["audit", "error", "general", "slowquery"]
  parameter_group_name            = aws_db_parameter_group.example.name
}

resource "aws_db_parameter_group" "example" {
  name   = "${aws_db_instance.example.dbInstanceIdentifier}-parameter-group"
  family = "mysql5.7"

  parameter {
    name  = "general_log"
    value = 1
  }

  parameter {
    name  = "slow_query_log"
    value = 1
  }

  parameter {
    name  = "log_output"
    value = "FILE"
  }
}

Erstellen Sie für MariaDB zusätzlich eine benutzerdefinierte Optionsgruppe und legen Sie option_group_name in der aws_db_instance-Ressource fest.

resource "aws_db_instance" "example" {
  # ... other configuration for MariaDB ...
  enabled_cloudwatch_logs_exports = ["audit", "error", "general", "slowquery"]
  parameter_group_name            = aws_db_parameter_group.example.name
  option_group_name               = aws_db_option_group.example.name
}

resource "aws_db_option_group" "example" {
  name                     = "mariadb-option-group-for-logs"
  option_group_description = "MariaDB Option Group for Logs"
  engine_name              = "mariadb"
  option {
    option_name = "MARIADB_AUDIT_PLUGIN"
    option_settings {
      name  = "SERVER_AUDIT_EVENTS"
      value = "CONNECT,QUERY,TABLE,QUERY_DDL,QUERY_DML,QUERY_DCL"
    }
  }
}

AWS-Konsole

So erstellen Sie eine benutzerdefinierte DB-Parametergruppe:

1. Öffnen Sie die Amazon RDS-Konsole unter https://console.aws.amazon.com/rds/.
2. Wählen Sie im Navigationsbereich „Parametergruppen“ aus.
3. Wählen Sie „Parametergruppe erstellen“ aus.
4. Wählen Sie in der Liste „Familie der Parametergruppe“ eine DB-Parametergruppenfamilie aus.
5. Wählen Sie in der Liste „Typ“ die Option „DB-Parametergruppe“ aus.
6. Geben Sie unter „Gruppenname“ den Namen der neuen Datenbankparametergruppe ein.
7. Geben Sie unter „Beschreibung“ eine Beschreibung für die neue DB-Parametergruppe ein.
8. Wählen Sie „Erstellen“ aus.

So erstellen Sie mit der Console eine neue Optionsgruppe für MariaDB-Protokolle:

1. Öffnen Sie die Amazon RDS-Konsole unter https://console.aws.amazon.com/rds/.
2. Wählen Sie im Navigationsbereich „Optionengruppen“ aus.
3. Wählen Sie „Gruppe erstellen“ aus.
4. Geben Sie im Fenster „Create option group“ (Optionengruppe erstellen) Folgendes an:
   * Name: Muss in Ihrem AWS-Konto eindeutig sein. Nur Buchstaben, Ziffern und Bindestriche.
   * Beschreibung: Wird nur zu Anzeigezwecken verwendet.
   * Engine: Wählen Sie das Datenbankmodul aus.
   * Hauptversion des Datenbankmoduls: Wählen Sie die Hauptversion Ihres Datenbankmoduls aus.
5. Wählen Sie „Erstellen“ aus.
6. Wählen Sie den Namen der Optionengruppe aus, die Sie gerade erstellt haben.
7. Wählen Sie die Option „Hinzufügen“ aus.
8. Wählen Sie in der Liste „Optionenname“ die Option MARIADB_AUDIT_PLUGIN aus.
9. Legen Sie SERVER_AUDIT_EVENTS auf CONNECT, QUERY, TABLE, QUERY_DDL, QUERY_DML und QUERY_DCL fest.
10. Wählen Sie die Option „Hinzufügen“ aus.

SQL Server-, Oracle- oder PostgreSQL-Logs über die AWS-Management Console in CloudWatch-Logs veröffentlichen

1. Öffnen Sie die Amazon RDS-Konsole unter https://console.aws.amazon.com/rds/.
2. Wählen Sie im Navigationsbereich „Datenbanken“ aus.
3. Wählen Sie die Datenbankinstanz aus, die Sie ändern möchten.
4. Wählen Sie „Ändern“ aus.
5. Wählen Sie unter „Logexporte“ alle Protokolldateien aus, die in CloudWatch Logs veröffentlicht werden sollen.
6. Logexporte sind nur für Datenbankmodulversionen verfügbar, die die Veröffentlichung in CloudWatch-Logs unterstützen.
7. Wählen Sie „Weiter“ aus. Wählen Sie dann auf der Übersichtsseite die Option „DB-Instanz ändern“ aus.

Neue DB-Parametergruppe oder DB-Optionsgruppe auf eine RDS-Datenbankinstanz anwenden

1. Öffnen Sie die Amazon RDS-Konsole unter https://console.aws.amazon.com/rds/.
2. Wählen Sie im Navigationsbereich „Datenbanken“ aus.
3. Wählen Sie die Datenbankinstanz aus, die Sie ändern möchten.
4. Wählen Sie „Ändern“ aus.
5. Ändern Sie unter „Datenbankoptionen“ bei Bedarf die Datenbankparametergruppe und die Datenbankoptionengruppe.
6. Wenn Sie mit den Änderungen fertig sind, wählen Sie „Weiter“ aus. Prüfen Sie die Zusammenfassung der Änderungen.
7. Wählen Sie „DB-Instanz ändern“ aus, um die Änderungen zu speichern.

AWS-CLI

Rufen Sie die Engine-Familien ab und wählen Sie die aus, die der Datenbankinstanz-Engine und ‑Version entspricht.

aws rds describe-db-engine-versions \
  --query "DBEngineVersions[].DBParameterGroupFamily" \
  --engine "mysql"

Erstellen Sie eine Parametergruppe entsprechend der Engine und Version.

aws rds create-db-parameter-group \
  --db-parameter-group-name "rds-mysql-parameter-group" \
  --db-parameter-group-family "mysql5.7" \
  --description "Example parameter group for logs"

Erstellen Sie eine rds-parameters.json-Datei mit den erforderlichen Parametern für die DB-Engine. In diesem Beispiel wird MySQL 5.7 verwendet.

[
  {
    "ParameterName": "general_log",
    "ParameterValue": "1",
    "ApplyMethod": "immediate"
  },
  {
    "ParameterName": "slow_query_log",
    "ParameterValue": "1",
    "ApplyMethod": "immediate"
  },
  {
    "ParameterName": "log_output",
    "ParameterValue": "FILE",
    "ApplyMethod": "immediate"
  }
]

Ändern Sie die Parametergruppe, um die Parameter entsprechend der Datenbank-Engine hinzuzufügen. In diesem Beispiel wird MySQL 5.7 verwendet.

aws rds modify-db-parameter-group \
  --db-parameter-group-name "rds-mysql-parameter-group" \
  --parameters file://rds-parameters.json

Ändern Sie die Datenbankinstanz, um die Parametergruppe zu verknüpfen.

aws rds modify-db-instance \
  --db-instance-identifier "test-rds" \
  --db-parameter-group-name "rds-mysql-parameter-group"

Erstellen Sie für MariaDB zusätzlich eine Optionsgruppe.

aws rds create-option-group \
  --option-group-name "rds-mariadb-option-group" \
  --engine-name "mariadb" \
  --major-engine-version "10.6" \
  --option-group-description "Option group for MariaDB logs"

So erstellen Sie eine rds-mariadb-options.json-Datei:

{
  "OptionName": "MARIADB_AUDIT_PLUGIN",
  "OptionSettings": [
    {
      "Name": "SERVER_AUDIT_EVENTS",
      "Value": "CONNECT,QUERY,TABLE,QUERY_DDL,QUERY_DML,QUERY_DCL"
    }
  ]
}

Fügen Sie die Option der Optionsgruppe hinzu.

aws rds add-option-to-option-group \
  --option-group-name "rds-mariadb-option-group" \
  --options file://rds-mariadb-options.json

Verknüpfen Sie die Optionsgruppe mit der DB-Instanz, indem Sie die MariaDB-Instanz ändern.

aws rds modify-db-instance \
  --db-instance-identifier "rds-test-mariadb" \
  --option-group-name "rds-mariadb-option-group"

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Rds Multi Az Support

Kategoriename in der API: RDS_MULTI_AZ_SUPPORT

RDS-Datenbankinstanzen sollten für mehrere Verfügbarkeitszonen konfiguriert werden. So wird die Verfügbarkeit der gespeicherten Daten sichergestellt. Bei Bereitstellungen mit mehreren AZs ist ein automatischer Failover möglich, wenn ein Problem mit der Verfügbarkeitszone auftritt oder während der regelmäßigen RDS-Wartung.

Empfehlung: Prüfen Sie, ob die Hochverfügbarkeit für alle RDS-Datenbankinstanzen aktiviert ist.

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

Terraform

Um dieses Problem zu beheben, setzen Sie multi_az in der Ressource aws_db_instance auf „wahr“.

resource "aws_db_instance" "example" {
  # ... other configuration ...
  multi_az                = true
}

AWS-Konsole

Mehrere Verfügbarkeitszonen für eine DB-Instanz aktivieren

1. Öffnen Sie die Amazon RDS-Konsole unter https://console.aws.amazon.com/rds/.
2. Wählen Sie im Navigationsbereich „Datenbanken“ und dann die Datenbankinstanz aus, die Sie ändern möchten.
3. Wählen Sie „Ändern“ aus. Die Seite „DB-Instanz ändern“ wird angezeigt.
4. Legen Sie unter „Instanzspezifikationen“ für „Bereitstellung in mehreren AZs“ den Wert „Ja“ fest.
5. Wählen Sie „Weiter“ aus und prüfen Sie die Zusammenfassung der Änderungen.
6. Optional: Wählen Sie „Sofort anwenden“ aus, um die Änderungen sofort anzuwenden. Die Auswahl dieser Option kann in einigen Fällen zu einem Ausfall führen. Weitere Informationen finden Sie im Amazon RDS-Nutzerhandbuch unter „Die Einstellung ‚Sofort anwenden‘ verwenden“.
7. Prüfen Sie auf der Bestätigungsseite die Änderungen. Wenn sie korrekt sind, wählen Sie „DB-Instanz ändern“ aus, um die Änderungen zu speichern.

AWS-CLI

Dasselbe gilt für die AWS-Befehlszeile. Aktivieren Sie die Unterstützung mehrerer AZs, indem Sie die Option --multi-az angeben.

modify-db-instance
  --db-instance-identifier "test-rds" \
  --multi-az

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Redshift Cluster Configuration Check

Kategoriename in der API: REDSHIFT_CLUSTER_CONFIGURATION_CHECK

Dabei werden die wesentlichen Elemente eines Redshift-Clusters geprüft: Verschlüsselung ruhender Daten, Logging und Knotentyp.

Diese Konfigurationselemente sind wichtig für die Wartung eines sicheren und beobachtbaren Redshift-Clusters.

Empfehlung: Prüft, ob für alle Redshift-Cluster die Verschlüsselung ruhender Daten, das Logging und der Knotentyp konfiguriert sind.

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

Terraform

resource "aws_kms_key" "redshift_encryption" {
  description         = "Used for Redshift encryption configuration"
  enable_key_rotation = true
}

resource "aws_redshift_cluster" "example" {
  # ... other configuration ...
  encrypted                           = true
  kms_key_id                          = aws_kms_key.redshift_encryption.id
  logging {
    enable               = true
    log_destination_type = "cloudwatch"
    log_exports          = ["connectionlog", "userlog", "useractivitylog"]
  }
}

AWS-Konsole

Cluster-Audit-Logging aktivieren

1. Öffnen Sie die Amazon Redshift-Konsole unter https://console.aws.amazon.com/redshift/.
2. Wählen Sie im Navigationsmenü „Cluster“ und dann den Namen des zu ändernden Clusters aus.
3. Wählen Sie „Properties“ (Unterkünfte) aus.
4. Wählen Sie „Bearbeiten“ und dann „Audit-Logging bearbeiten“ aus.
5. Legen Sie für „Audit-Logging konfigurieren“ die Option „Aktivieren“ fest, wählen Sie „CloudWatch“ (empfohlen) als Logexporttyp aus und wählen Sie die zu exportierenden Protokolle aus.

Informationen zum Verwalten von Redshift-Audit-Logs mit AWS S3 finden Sie in der AWS-Dokumentation unter Redshift – Datenbank-Audit-Logging.

6. Wählen Sie „Änderungen speichern“ aus.

Datenbankverschlüsselung in einem Cluster ändern

1. Melden Sie sich in der AWS Management Console an und öffnen Sie die Amazon Redshift-Konsole unter https://console.aws.amazon.com/redshift/.
2. Wählen Sie im Navigationsmenü „Cluster“ und dann den Cluster aus, für den Sie die Verschlüsselung ändern möchten.
3. Wählen Sie „Properties“ (Unterkünfte) aus.
4. Wählen Sie „Bearbeiten“ und dann „Verschlüsselung bearbeiten“ aus.
5. Wählen Sie die gewünschte Verschlüsselung (KMS oder HSM) aus und geben Sie Folgendes an:

• Für KMS: zu verwendender Schlüssel
• Für HSM: Verbindung und Clientzertifikat

AWS-CLI

1. KMS-Schlüssel erstellen und Schlüssel-ID abrufen

aws kms create-key \
  --description "Key to encrypt Redshift Clusters"

2. Cluster ändern

aws redshift modify-cluster \
  --cluster-identifiers "test-redshift-cluster" \
  --encrypted \
  --kms-key-id <value>

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Redshift Cluster Maintenancesettings Check

Kategoriename in der API: REDSHIFT_CLUSTER_MAINTENANCESETTINGS_CHECK

Automatische Upgrades der Hauptversion erfolgen gemäß dem Wartungsfenster.

Empfehlung: Prüfen Sie, ob für alle Redshift-Cluster „allowVersionUpgrade“ aktiviert ist und Werte für „preferredMaintenanceWindow“ sowie „automatedSnapshotRetentionPeriod“ festgelegt sind

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

Terraform

Diese Prüfung entspricht allen von Terraform bereitgestellten Standardwerten. Wenn ein Redshift-Cluster fehlschlägt, prüfen Sie die Anforderungen und entfernen Sie die Standardüberschreibungen für die folgenden Attribute der aws_redshift_cluster-Ressource.

resource "aws_redshift_cluster" "example" {

  # ...other configuration ...

  # The following values are compliant and set by default if omitted.
  allow_version_upgrade               = true
  preferred_maintenance_window        = "sat:10:00-sat:10:30"
  automated_snapshot_retention_period = 1
}

AWS-Konsole

Wenn Sie einen Redshift-Cluster über die AWS-Konsole erstellen, entsprechen die Standardwerte bereits dieser Einstellung.

Weitere Informationen finden Sie unter Cluster über die Console verwalten.

AWS-CLI

So beheben Sie dieses Problem mit der AWS CLI:

aws redshift modify-cluster \
  --cluster-identifier "test-redshift-cluster" \
  --allow-version-upgrade

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Redshift Cluster Public Access Check

Kategoriename in der API: REDSHIFT_CLUSTER_PUBLIC_ACCESS_CHECK

Das Attribut „PubliclyAccessible“ der Amazon Redshift-Clusterkonfiguration gibt an, ob der Cluster öffentlich zugänglich ist. Wenn der Cluster so konfiguriert ist, dass „PubliclyAccessible“ auf „true“ gesetzt ist, handelt es sich um eine internetfähige Instanz mit einem öffentlich auflösbaren DNS-Namen, der in eine öffentliche IP-Adresse aufgelöst wird.

Wenn der Cluster nicht öffentlich zugänglich ist, handelt es sich um eine interne Instanz mit einem DNS-Namen, der in eine private IP-Adresse aufgelöst wird. Sofern Sie nicht beabsichtigen, dass Ihr Cluster öffentlich zugänglich ist, sollte die Einstellung „PubliclyAccessible“ nicht auf „true“ festgelegt sein.

Empfehlung: Prüfen Sie, ob Redshift-Cluster öffentlich zugänglich sind

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

Terraform

Um dieses Problem zu beheben, müssen Sie die Redshift-Clusterressource ändern und publicly_accessible auf false setzen. Der Standardwert ist true.

resource "aws_redshift_cluster" "example" {
  # ... other configuration ...
  publicly_accessible = false
}

AWS-Konsole

Öffentlichen Zugriff auf einen Amazon Redshift-Cluster deaktivieren

1. Öffnen Sie die Amazon Redshift-Konsole unter https://console.aws.amazon.com/redshift/.
2. Wählen Sie im Navigationsmenü „Cluster“ und dann den Namen des Clusters mit der zu ändernden Sicherheitsgruppe aus.
3. Wählen Sie „Aktionen“ und dann „Öffentlich zugängliche Einstellung ändern“ aus.
4. Wählen Sie unter „Instanzen und Geräten außerhalb der VPC erlauben, über den Clusterendpunkt eine Verbindung zu Ihrer Datenbank herzustellen“ die Option „Nein“ aus.
5. Wählen Sie „Bestätigen“ aus.

AWS-CLI

Verwenden Sie den Befehl modify-cluster, um --no-publicly-accessible festzulegen.

aws redshift modify-cluster \
  --cluster-identifier "test-redshift-cluster" \
  --no-publicly-accessible

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Restricted Common Ports

Kategoriename in der API: RESTRICTED_COMMON_PORTS

Dabei wird geprüft, ob für die Sicherheitsgruppen uneingeschränkter eintreffender Traffic auf die Ports mit dem höchsten Risiko zugreifen kann. Diese Steuerung schlägt fehl, wenn eine der Regeln in einer Sicherheitsgruppe eingehenden Traffic von „0.0.0.0/0“ oder „::/0“ für diese Ports zulässt.

Der unbeschränkte Zugriff (0.0.0.0/0) erhöht die Wahrscheinlichkeit für schädliche Aktivitäten wie Hacking, Denial-of-Service-Angriffe und Datenverlust.

Sicherheitsgruppen ermöglichen die zustandsabhängige Filterung von eingehenden und ausgehenden Netzwerkverkehr zu AWS-Ressourcen. Keine Sicherheitsgruppe sollte uneingeschränkten Zugriff auf die folgenden Ports zulassen:

• 20, 21 (FTP)
• 22 (SSH)
• 23 (Telnet)
• 25 (SMTP)
• 110 (POP3)
• 135 (RPC)
• 143 (IMAP)
• 445 (CIFS)
• 1433, 1434 (MSSQL)
• 3.000 (Go-, Node.js- und Ruby-Webentwicklungs-Frameworks)
• 3306 (mySQL)
• 3389 (RDP)
• 4333 (ahsp)
• 5.000 (Python-Webentwicklungs-Frameworks)
• 5432 (PostgreSQL)
• 5500 (fcp-addr-srvr1)
• 5601 (OpenSearch-Dashboards)
• 8080 (Proxy)
• 8088 (Legacy-HTTP-Port)
• 8888 (alternativer HTTP-Port)
• 9200 oder 9300 (OpenSearch)

Empfehlung: Sicherheitsgruppen sollten keinen uneingeschränkten Zugriff auf Ports mit hohem Risiko zulassen

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

So löschen Sie eine Sicherheitsgruppenregel:

1. Öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/.
2. Wählen Sie im Navigationsbereich „Sicherheitsgruppen“ aus.
3. Wählen Sie die Sicherheitsgruppe aus, die Sie aktualisieren möchten, und dann „Aktionen“ und dann „Eingehende Regeln bearbeiten“, um eine eingehende Regel zu entfernen, oder „Ausgehende Regeln bearbeiten“, um eine ausgehende Regel zu entfernen.
4. Klicken Sie rechts neben der Regel, die Sie löschen möchten, auf die Schaltfläche „Löschen“.
5. Wählen Sie „Änderungen ansehen“ und dann „Bestätigen“ aus.

Informationen zum Löschen von Regeln aus einer Sicherheitsgruppe finden Sie im Amazon EC2-Nutzerhandbuch unter Sicherheitsgruppenregeln konfigurieren.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Restricted Ssh

Kategoriename in der API: RESTRICTED_SSH

Sicherheitsgruppen ermöglichen die zustandsabhängige Filterung von eingehenden und ausgehenden Netzwerkverkehr zu AWS-Ressourcen.

CIS empfiehlt, dass keine Sicherheitsgruppe uneingeschränkten Zugriff auf Port 22 zulässt. Wenn Sie die uneingeschränkte Konnektivität zu Remote-Konsolendiensten wie SSH entfernen, verringern Sie das Risiko für einen Server.

Empfehlung: Sicherheitsgruppen sollten keinen eingehenden Traffic von 0.0.0.0/0 an Port 22 zulassen

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

Führen Sie die folgenden Schritte für jede Sicherheitsgruppe aus, die mit einem VPC verknüpft ist.

Öffnen Sie die Amazon VPC-Konsole unter https://console.aws.amazon.com/vpc/.

1. Wählen Sie im linken Bereich Sicherheitsgruppen aus.
2. Wählen Sie eine Sicherheitsgruppe aus.
3. Wählen Sie unten auf der Seite den Tab Eingehende Regeln aus.
4. Wählen Sie Regeln bearbeiten aus.
5. Suchen Sie die Regel, die den Zugriff über Port 22 zulässt, und klicken Sie auf das X, um sie zu entfernen.
6. Wählen Sie Regeln speichern aus.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Rotation Customer Created Cmks Enabled

Kategoriename in der API: ROTATION_CUSTOMER_CREATED_CMKS_ENABLED

Prüft, ob die automatische Schlüsselrotation für jeden Schlüssel aktiviert ist und mit der Schlüssel-ID des vom Kunden erstellten AWS KMS-Schlüssels übereinstimmt. Die Regel hat den Status „NICHT KONFORM“, wenn die Rolle „AWS Config-Aufzeichner“ für eine Ressource nicht die Berechtigung „kms:DescribeKey“ hat.

Empfehlung: Achten Sie darauf, dass die Rotation für vom Kunden erstellte CMKs aktiviert ist

Informationen zum Aktivieren der automatischen Schlüsselrotation für AWS KMS finden Sie in der AWS-Dokumentation unter AWS KMS-Schlüssel rotieren.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Rotation Customer Created Symmetric Cmks Enabled

Kategoriename in der API: ROTATION_CUSTOMER_CREATED_SYMMETRIC_CMKS_ENABLED

Mit dem AWS Key Management Service (KMS) können Kunden den Back-Key rotieren. Dabei handelt es sich um Schlüsselmaterial, das im KMS gespeichert ist und mit der Schlüssel-ID des vom Kunden erstellten Kundenmasterschlüssels (CMK) verknüpft ist. Der Back-Key wird für kryptografische Vorgänge wie Verschlüsselung und Entschlüsselung verwendet. Bei der automatischen Schlüsselrotation werden derzeit alle vorherigen Sicherungsschlüssel beibehalten, damit die Entschlüsselung verschlüsselter Daten transparent erfolgen kann. Es wird empfohlen, die CMK-Schlüsselrotation für symmetrische Schlüssel zu aktivieren. Die Schlüsselrotation kann für keine asymmetrischen CMKs aktiviert werden.

Empfehlung: Achten Sie darauf, dass die Rotation für vom Kunden erstellte symmetrische CMKs aktiviert ist.

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

1. Melden Sie sich in der AWS Management Console an und öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam.
2. Wählen Sie im linken Navigationsbereich Customer managed keys aus .
3. Wählen Sie einen vom Kunden verwalteten CMK aus, bei dem Key spec = SYMMETRIC_DEFAULT
4. Öffnen Sie unter „Allgemeine Konfiguration“ den Tab „Schlüsselrotation“.
5. Setzen Sie ein Häkchen in das Kästchen „Diesen KMS-Schlüssel jedes Jahr automatisch rotieren“.

AWS-CLI

1. Führen Sie den folgenden Befehl aus, um die Schlüsselrotation zu aktivieren:

 aws kms enable-key-rotation --key-id <kms_key_id>

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Routing Tables Vpc Peering Are Least Access

Kategoriename in der API: ROUTING_TABLES_VPC_PEERING_ARE_LEAST_ACCESS

Prüft, ob Routingtabellen für das VPC-Peering mit dem Prinzip der geringsten Berechtigung konfiguriert sind.

Empfehlung: Achten Sie darauf, dass Routingtabellen für VPC-Peering den geringsten Zugriff gewähren

Informationen zum Aktualisieren von Routingtabellen für das VPC-Peering finden Sie im AWS VPC-Benutzerhandbuch unter Routingtabellen für eine VPC-Peering-Verbindung aktualisieren.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

S3 Account Level Public Access Blocks

Kategoriename in der API: S3_ACCOUNT_LEVEL_PUBLIC_ACCESS_BLOCKS

Die Funktion „Öffentlichen Zugriff blockieren“ in Amazon S3 bietet Einstellungen für Zugangspunkte, Buckets und Konten, mit denen Sie den öffentlichen Zugriff auf Amazon S3-Ressourcen verwalten können. Standardmäßig ist der öffentliche Zugriff auf neue Buckets, Zugangspunkte und Objekte nicht zulässig.

Empfehlung: Prüfen Sie, ob die erforderlichen S3-Einstellungen zum Blockieren des öffentlichen Zugriffs auf Kontoebene konfiguriert sind.

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

Terraform

Mit der folgenden Terraform-Ressource wird der Zugriff auf S3 auf Kontoebene konfiguriert.

resource "aws_s3_account_public_access_block" "s3_control" {
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

AWS-Konsole

Hier können Sie die Einstellungen zum Blockieren des öffentlichen Zugriffs für alle S3-Buckets in einem AWS-Konto bearbeiten.

1. Melden Sie sich in der AWS Management Console an und öffnen Sie die Amazon S3-Konsole unter https://console.aws.amazon.com/s3/.
2. Wählen Sie für dieses Konto die Einstellungen „Öffentlichen Zugriff blockieren“ aus.
3. Wählen Sie „Bearbeiten“ aus, um die Einstellungen zum Blockieren des öffentlichen Zugriffs für alle Buckets in Ihrem AWS-Konto zu ändern.
4. Wählen Sie die Einstellungen aus, die Sie ändern möchten, und klicken Sie dann auf „Änderungen speichern“.
5. Wenn Sie zur Bestätigung aufgefordert werden, geben Sie „confirm“ ein. Wählen Sie dann „Bestätigen“ aus, um die Änderungen zu speichern.

AWS-CLI

aws s3control put-public-access-block \
--account-id <value> \
--public-access-block-configuration '{"BlockPublicAcls": true, "BlockPublicPolicy": true, "IgnorePublicAcls": true, "RestrictPublicBuckets": true}'

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

S3 Buckets Configured Block Public Access Bucket And Account Settings

Kategoriename in der API: S3_BUCKETS_CONFIGURED_BLOCK_PUBLIC_ACCESS_BUCKET_AND_ACCOUNT_SETTINGS

Amazon S3 bietet Block public access (bucket settings) und Block public access (account settings), um den öffentlichen Zugriff auf Amazon S3-Ressourcen zu verwalten. Standardmäßig werden S3-Buckets und ‑Objekte mit deaktiviertem öffentlichen Zugriff erstellt. Ein AWS IAM-Hauptkonto mit ausreichenden S3-Berechtigungen kann jedoch den öffentlichen Zugriff auf Bucket- oder Objektebene aktivieren. Wenn Block public access (bucket settings) aktiviert ist, wird verhindert, dass ein einzelner Bucket und die darin enthaltenen Objekte öffentlich zugänglich werden. Ebenso verhindert Block public access (account settings), dass alle Buckets und darin enthaltenen Objekte im gesamten Konto öffentlich zugänglich werden.

Empfehlung:

Achten Sie darauf, dass S3-Buckets mit Block public access (bucket settings) konfiguriert sind.

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

Wenn in der Ausgabe für die separaten Konfigurationseinstellungen true steht, sind sie für das Konto festgelegt.

1. Melden Sie sich in der AWS Management Console an und öffnen Sie die Amazon S3-Konsole unter https://console.aws.amazon.com/s3/.
2. Wählen Sie Öffentlichen Zugriff blockieren (Kontoeinstellungen) aus.
3. Wählen Sie Bearbeiten aus, um die Einstellungen zum Blockieren des öffentlichen Zugriffs für alle Buckets in Ihrem AWS-Konto zu ändern.
4. Wählen Sie die Einstellungen aus, die Sie ändern möchten, und klicken Sie dann auf Speichern. Wenn Sie Details zu den einzelnen Einstellungen sehen möchten, halten Sie den Mauszeiger auf die Symbole i.
5. Wenn Sie zur Bestätigung aufgefordert werden, geben Sie confirm ein. Klicken Sie dann auf Bestätigen, um die Änderungen zu speichern.

AWS-CLI

Führen Sie den folgenden Befehl aus, um die Einstellungen für den öffentlichen Zugriff für dieses Konto festzulegen:

aws s3control put-public-access-block
--public-access-block-configuration BlockPublicAcls=true, IgnorePublicAcls=true, BlockPublicPolicy=true, RestrictPublicBuckets=true
--account-id <value>

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

S3 Bucket Access Logging Enabled Cloudtrail S3 Bucket

Kategoriename in der API: S3_BUCKET_ACCESS_LOGGING_ENABLED_CLOUDTRAIL_S3_BUCKET

Bei der S3-Bucket-Zugriffsprotokollierung wird ein Log erstellt, das Zugriffsdatensätze für jede Anfrage an Ihren S3-Bucket enthält. Ein Zugriffsprotokolleintrag enthält Details zur Anfrage, z. B. den Anfragetyp, die in der Anfrage angegebenen Ressourcen und die Uhrzeit und das Datum, zu dem die Anfrage verarbeitet wurde. Es wird empfohlen, das Bucket-Zugriffs-Logging für den CloudTrail-S3-Bucket zu aktivieren.

Empfehlung:

Achten Sie darauf, dass das S3-Bucket-Zugriffs-Logging im CloudTrail S3-Bucket aktiviert ist

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

1. Melden Sie sich in der AWS Management Console an und öffnen Sie die S3-Konsole unter https://console.aws.amazon.com/s3.
2. Klicken Sie unter Alle Buckets auf den Ziel-S3-Bucket.
3. Klicken Sie oben rechts in der Konsole auf Properties (Properties).
4. Klicken Sie unter Bucket: <s3\_bucket\_for\_cloudtrail> auf Logging</s3\_bucket\_for\_cloudtrail>.
5. Bucket-Protokollierung konfigurieren
    – Klicken Sie auf das Kästchen Aktiviert.
    – Wählen Sie in der Liste „Ziel-Bucket“ aus.
    – Geben Sie ein Zielpräfix ein.
6. Klicken Sie auf Speichern.

AWS-CLI

1. Rufen Sie den Namen des S3-Buckets ab, in dem CloudTrail protokolliert:

aws cloudtrail describe-trails --region <region-name> --query trailList[*].S3BucketName

2. Kopieren Sie den Namen des Ziel-Buckets unter und fügen Sie ihn unter ein Präfix für die Protokolldatei hinzu. Fügen Sie optional eine E-Mail-Adresse in die folgende Vorlage ein und speichern Sie sie als :

{
 "LoggingEnabled": {
 "TargetBucket": "<Logging_BucketName>",
 "TargetPrefix": "<LogFilePrefix>",
 "TargetGrants": [
 {
 "Grantee": {
 "Type": "AmazonCustomerByEmail",
 "EmailAddress": "<EmailID>"
 },
 "Permission": "FULL_CONTROL"
 }
 ]
 }
}

3. Führen Sie den Befehl put-bucket-logging mit dem Bucket-Namen und als Eingabe aus. Weitere Informationen finden Sie unter put-bucket-logging:

aws s3api put-bucket-logging --bucket <BucketName> --bucket-logging-status file://<FileName.Json>

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

S3 Bucket Logging Enabled

Kategoriename in der API: S3_BUCKET_LOGGING_ENABLED

Mit der AWS S3-Serverzugriffs-Logging-Funktion werden Zugriffsanfragen an Speicher-Buckets protokolliert. Das ist für Sicherheitsaudits nützlich. Standardmäßig ist das Logging von Serverzugriffen für S3-Buckets nicht aktiviert.

Empfehlung: Prüfen, ob Logging für alle S3-Buckets aktiviert ist

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

Terraform

Das folgende Beispiel zeigt, wie zwei Bucket erstellt werden:

1. Einen Logging-Bucket
2. Einen konformen Bucket

variable "bucket_acl_map" {
  type = map(any)
  default = {
    "logging-bucket"   = "log-delivery-write"
    "compliant-bucket" = "private"
  }
}

resource "aws_s3_bucket" "all" {
  for_each            = var.bucket_acl_map
  bucket              = each.key
  object_lock_enabled = true
  tags = {
    "Pwd"    = "s3"
  }
}

resource "aws_s3_bucket_acl" "private" {
  for_each = var.bucket_acl_map
  bucket   = each.key
  acl      = each.value
}

resource "aws_s3_bucket_versioning" "enabled" {
  for_each = var.bucket_acl_map
  bucket   = each.key
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_logging" "enabled" {
  for_each      = var.bucket_acl_map
  bucket        = each.key
  target_bucket = aws_s3_bucket.all["logging-bucket"].id
  target_prefix = "log/"
}

resource "aws_s3_bucket_server_side_encryption_configuration" "example" {
  for_each = var.bucket_acl_map
  bucket   = each.key

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
    }
  }
}

AWS-Konsole

Informationen zum Aktivieren des S3-Zugriffs-Loggings über die AWS-Konsole finden Sie in der AWS-Dokumentation unter Amazon S3-Serverzugriffs-Logging aktivieren.

AWS-CLI

Im folgenden Beispiel wird Folgendes veranschaulicht:

1. Erstellen Sie eine Bucket-Richtlinie, um dem Hauptkonto des Logging-Dienstes die Berechtigung PutObject in Ihrem Logging-Bucket zu gewähren.

policy.json

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "S3ServerAccessLogsPolicy",
            "Effect": "Allow",
            "Principal": {"Service": "logging.s3.amazonaws.com"},
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::MyBucket/Logs/*",
            "Condition": {
                "ArnLike": {"aws:SourceARN": "arn:aws:s3:::SOURCE-BUCKET-NAME"},
                "StringEquals": {"aws:SourceAccount": "SOURCE-AWS-ACCOUNT-ID"}
            }
        }
    ]
}

aws s3api put-bucket-policy \
  --bucket my-bucket
  --policy file://policy.json

2. Richtlinie auf Ihren Logging-Bucket anwenden

logging.json

{
    "LoggingEnabled": {
        "TargetBucket": "MyBucket",
        "TargetPrefix": "Logs/"
    }
}

aws s3api put-bucket-logging \
  --bucket MyBucket \
  --bucket-logging-status file://logging.json

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

S3 Bucket Policy Set Deny Http Requests

Kategoriename in der API: S3_BUCKET_POLICY_SET_DENY_HTTP_REQUESTS

Auf Amazon S3-Bucket-Ebene können Sie Berechtigungen über eine Bucket-Richtlinie konfigurieren, sodass die Objekte nur über HTTPS zugänglich sind.

Empfehlung: Achten Sie darauf, dass die S3-Bucket-Richtlinie auf Ablehnen von HTTP-Anfragen festgelegt ist

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

mit dem AWS Policy Generator:

1. Wiederholen Sie die oben genannten Schritte 1 bis 4.
2. Klicken Sie unten im Editor für Bucket-Richtlinien auf Policy Generator.
3. Richtlinientyp auswählen
   S3 Bucket Policy
4. Anweisungen hinzufügen
   – Effect = Deny (Ablehnen)
   – Principal = *
   – AWS Service = Amazon S3
   – Actions = *
   – Amazon Resource Name =
5. Richtlinie generieren
6. Kopieren Sie den Text und fügen Sie ihn der Bucket-Richtlinie hinzu.

AWS-CLI

1. Exportieren Sie die Bucket-Richtlinie in eine JSON-Datei.

aws s3api get-bucket-policy --bucket <bucket_name> --query Policy --output text > policy.json

2. Fügen Sie der Datei „policy.json“ die folgende Anweisung hinzu:

{
 "Sid": <optional>",
 "Effect": "Deny",
 "Principal": "*",
 "Action": "s3:*",
 "Resource": "arn:aws:s3:::<bucket_name>/*",
 "Condition": {
 "Bool": {
 "aws:SecureTransport": "false"
 }
 }
 }

3. Wenden Sie diese geänderte Richtlinie wieder auf den S3-Bucket an:

aws s3api put-bucket-policy --bucket <bucket_name> --policy file://policy.json

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

S3 Bucket Replication Enabled

Kategoriename in der API: S3_BUCKET_REPLICATION_ENABLED

Mit dieser Einstellung wird geprüft, ob die regionsübergreifende Replikation für einen Amazon S3-Bucket aktiviert ist. Die Prüfung schlägt fehl, wenn für den Bucket keine regionsübergreifende Replikation aktiviert ist oder auch die Replikation innerhalb der Region aktiviert ist.

Bei der Replikation werden Objekte automatisch und asynchron in Buckets in derselben oder in verschiedenen AWS-Regionen kopiert. Bei der Replikation werden neu erstellte Objekte und Objektaktualisierungen aus einem Quell-Bucket in einen oder mehrere Ziel-Buckets kopiert. Gemäß den AWS-Best Practices wird die Replikation für Quell- und Ziel-Buckets empfohlen, die demselben AWS-Konto gehören. Neben der Verfügbarkeit sollten Sie auch andere Einstellungen zur Systemhärtung berücksichtigen.

Empfehlung: Prüfen Sie, ob die regionsübergreifende Replikation für S3-Buckets aktiviert ist

Informationen zum Aktivieren der regionenübergreifenden Replikation für einen S3-Bucket finden Sie im Amazon Simple Storage Service-Benutzerhandbuch unter Replikation für Quell- und Ziel-Buckets konfigurieren, die zum selben Konto gehören. Wählen Sie für „Quell-Bucket“ die Option „Auf alle Objekte im Bucket anwenden“ aus.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

S3 Bucket Server Side Encryption Enabled

Kategoriename in der API: S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED

Dabei wird geprüft, ob für Ihren S3-Bucket entweder die Standardverschlüsselung von Amazon S3 aktiviert ist oder die S3-Bucket-Richtlinie Put-Objektanfragen ohne serverseitige Verschlüsselung ausdrücklich ablehnt.

Empfehlung: Achten Sie darauf, dass alle S3-Buckets die Verschlüsselung ruhender Daten verwenden

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

Terraform

resource "aws_s3_bucket_server_side_encryption_configuration" "enable" {
  bucket = "my-bucket"

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

AWS-Konsole

Standardverschlüsselung für einen S3-Bucket aktivieren

1. Öffnen Sie die Amazon S3-Konsole unter https://console.aws.amazon.com/s3/.
2. Wählen Sie im linken Navigationsbereich „Buckets“ aus.
3. Wählen Sie den S3-Bucket aus der Liste aus.
4. Wählen Sie „Properties“ (Unterkünfte) aus.
5. Wählen Sie „Standardverschlüsselung“ aus.
6. Wählen Sie für die Verschlüsselung entweder AES-256 oder AWS-KMS aus.
7. Wählen Sie AES-256 aus, um Schlüssel zu verwenden, die von Amazon S3 für die Standardverschlüsselung verwaltet werden. Weitere Informationen zur serverseitigen Verschlüsselung von Amazon S3 finden Sie im Amazon Simple Storage Service-Nutzerhandbuch.
8. Wählen Sie „AWS-KMS“ aus, um Schlüssel zu verwenden, die von AWS KMS für die Standardverschlüsselung verwaltet werden. Wählen Sie dann einen Masterschlüssel aus der Liste der von Ihnen erstellten AWS KMS-Masterschlüssel aus.
9. Geben Sie den Amazon-Ressourcennamen (ARN) des zu verwendenden AWS KMS-Schlüssels ein. Sie finden die ARN für Ihren AWS-KMS-Schlüssel in der IAM-Konsole unter „Verschlüsselungsschlüssel“. Alternativ können Sie einen Schlüsselnamen aus der Drop-down-Liste auswählen.
10. Wichtig: Wenn Sie die AWS KMS-Option für Ihre Standardverschlüsselungskonfiguration verwenden, unterliegen Sie den AWS KMS-Kontingenten für RPS (Anfragen pro Sekunde). Weitere Informationen zu AWS KMS-Kontingenten und zum Anfordern einer Kontingenterhöhung finden Sie im AWS Key Management Service Developer Guide.
11. Wählen Sie „Speichern“ aus.

Weitere Informationen zum Erstellen eines AWS KMS-Schlüssels finden Sie im AWS Key Management Service Developer Guide.

Weitere Informationen zur Verwendung von AWS KMS mit Amazon S3 finden Sie im Amazon Simple Storage Service-Nutzerhandbuch.

Wenn Sie die Standardverschlüsselung aktivieren, müssen Sie möglicherweise Ihre Bucket-Richtlinie aktualisieren. Weitere Informationen zum Wechsel von Bucket-Richtlinien zur Standardverschlüsselung finden Sie im Amazon Simple Storage Service-Nutzerhandbuch.

AWS-CLI

aws s3api put-bucket-encryption \
  --bucket my-bucket \
  --server-side-encryption-configuration '{"Rules": [{"ApplyServerSideEncryptionByDefault": {"SSEAlgorithm": "AES256"}}]}'

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

S3 Bucket Versioning Enabled

Kategoriename in der API: S3_BUCKET_VERSIONING_ENABLED

Mit Amazon S3 können Sie mehrere Varianten eines Objekts im selben Bucket speichern. So können Sie sich leichter von unbeabsichtigten Nutzeraktionen und Anwendungsausfällen erholen.

Empfehlung: Prüfen Sie, ob die Versionsverwaltung für alle S3-Buckets aktiviert ist

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

Terraform

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-bucket"

  versioning {
    enabled = true
  }
}

AWS-Konsole

Versionsverwaltung für einen S3-Bucket aktivieren oder deaktivieren

1. Melden Sie sich in der AWS Management Console an und öffnen Sie die Amazon S3-Konsole unter https://console.aws.amazon.com/s3/.
2. Wählen Sie in der Liste der Buckets den Namen des Buckets aus, für den Sie die Versionierung aktivieren möchten.
3. Wählen Sie „Properties“ (Unterkünfte) aus.
4. Wählen Sie unter „Bucket-Versionierung“ die Option „Bearbeiten“ aus.
5. Wählen Sie „Pausieren“ oder „Aktivieren“ und dann „Änderungen speichern“ aus.

AWS-CLI

aws s3control put-bucket-versioning \
--bucket <bucket_name> \
--versioning-configuration Status=Enabled

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

S3 Default Encryption Kms

Kategoriename in der API: S3_DEFAULT_ENCRYPTION_KMS

Prüft, ob die Amazon S3-Buckets mit AWS Key Management Service (AWS KMS) verschlüsselt sind

Empfehlung: Prüfen Sie, ob alle Buckets mit KMS verschlüsselt sind.

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

Terraform

resource "aws_kms_key" "s3_encryption" {
  description         = "Used for S3 Bucket encryption configuration"
  enable_key_rotation = true
}

resource "aws_s3_bucket_server_side_encryption_configuration" "enable" {
  bucket   = "my-bucket"

  rule {
    apply_server_side_encryption_by_default {
      kms_master_key_id = aws_kms_key.s3_encryption.arn
      sse_algorithm     = "aws:kms"
    }
  }
}

AWS-Konsole

Standardverschlüsselung für einen S3-Bucket aktivieren

1. Öffnen Sie die Amazon S3-Konsole unter https://console.aws.amazon.com/s3/.
2. Wählen Sie im linken Navigationsbereich „Buckets“ aus.
3. Wählen Sie den S3-Bucket aus der Liste aus.
4. Wählen Sie „Properties“ (Unterkünfte) aus.
5. Wählen Sie „Standardverschlüsselung“ aus.
6. Wählen Sie für die Verschlüsselung „AWS-KMS“ aus.
7. Wählen Sie „AWS-KMS“ aus, um Schlüssel zu verwenden, die von AWS KMS für die Standardverschlüsselung verwaltet werden. Wählen Sie dann einen Masterschlüssel aus der Liste der von Ihnen erstellten AWS KMS-Masterschlüssel aus. Weitere Informationen zum Erstellen von KMS-Schlüsseln finden Sie in der AWS-Dokumentation unter „Schlüssel erstellen“.
8. Geben Sie den Amazon-Ressourcennamen (ARN) des zu verwendenden AWS KMS-Schlüssels ein. Sie finden die ARN für Ihren AWS-KMS-Schlüssel in der IAM-Konsole unter „Verschlüsselungsschlüssel“. Alternativ können Sie einen Schlüsselnamen aus der Drop-down-Liste auswählen.
9. Wichtig: Diese Lösung unterliegt den RPS-Kontingenten (Anfragen pro Sekunde) von AWS KMS. Weitere Informationen zu AWS KMS-Kontingenten und zum Anfordern einer Kontingenterhöhung finden Sie im AWS Key Management Service Developer Guide.
10. Wählen Sie „Speichern“ aus.

Weitere Informationen zur Verwendung von AWS KMS mit Amazon S3 finden Sie im Amazon Simple Storage Service-Nutzerhandbuch.

Wenn Sie die Standardverschlüsselung aktivieren, müssen Sie möglicherweise Ihre Bucket-Richtlinie aktualisieren. Weitere Informationen zum Wechsel von Bucket-Richtlinien zur Standardverschlüsselung finden Sie im Amazon Simple Storage Service-Nutzerhandbuch.

AWS-CLI

KMS-Schlüssel erstellen

aws kms create-key \
  --description "Key to encrypt S3 buckets"

Schlüsselrotation aktivieren

aws kms enable-key-rotation \
  --key-id <key_id_from_previous_command>

Bucket aktualisieren

aws s3api put-bucket-encryption \
  --bucket my-bucket \
  --server-side-encryption-configuration '{"Rules": [{"ApplyServerSideEncryptionByDefault": {"KMSMasterKeyID": "<id_from_key>", "SSEAlgorithm": "AES256"}}]}'

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Sagemaker Notebook Instance Kms Key Configured

Kategoriename in der API: SAGEMAKER_NOTEBOOK_INSTANCE_KMS_KEY_CONFIGURED

Prüft, ob für eine Amazon SageMaker-Notebookinstanz ein AWS Key Management Service-Schlüssel (AWS KMS) konfiguriert ist. Die Regel hat den Status „NICHT KONFORM“, wenn „KmsKeyId“ für die SageMaker-Notebookinstanz nicht angegeben ist.

Empfehlung: Prüfen Sie, ob für alle SageMaker-Notebookinstanzen die Verwendung von KMS konfiguriert ist.

Informationen zum Konfigurieren von KMS für SageMaker finden Sie in der Amazon SageMaker-Dokumentation unter Schlüsselverwaltung.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Sagemaker Notebook No Direct Internet Access

Kategoriename in der API: SAGEMAKER_NOTEBOOK_NO_DIRECT_INTERNET_ACCESS

Prüft, ob der direkte Internetzugriff für eine SageMaker-Notebookinstanz deaktiviert ist. Dazu wird geprüft, ob das Feld „DirectInternetAccess“ für die Notebook-Instanz deaktiviert ist.

Wenn Sie Ihre SageMaker-Instanz ohne VPC konfigurieren, ist standardmäßig der direkte Internetzugriff auf Ihrer Instanz aktiviert. Sie sollten Ihre Instanz mit einer VPC konfigurieren und die Standardeinstellung in „Deaktivieren – Internetzugriff über eine VPC“ ändern.

Wenn Sie Modelle auf einem Notebook trainieren oder hosten möchten, benötigen Sie Internetzugriff. Damit der Internetzugriff möglich ist, muss Ihre VPC ein NAT-Gateway haben und Ihre Sicherheitsgruppe ausgehende Verbindungen zulassen. Weitere Informationen zum Verbinden einer Notebook-Instanz mit Ressourcen in einer VPC finden Sie im Amazon SageMaker-Entwicklerleitfaden unter „Notebook-Instanz mit Ressourcen in einer VPC verbinden“.

Außerdem sollten Sie dafür sorgen, dass der Zugriff auf Ihre SageMaker-Konfiguration auf autorisierte Nutzer beschränkt ist. Beschränken Sie die IAM-Berechtigungen der Nutzer, um die SageMaker-Einstellungen und ‑Ressourcen zu ändern.

Empfehlung: Prüfen, ob der direkte Internetzugriff für alle Amazon SageMaker-Notebookinstanzen deaktiviert ist

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

Die Einstellung für den Internetzugriff kann nach dem Erstellen einer Notebook-Instanz nicht mehr geändert werden. Sie muss angehalten, gelöscht und neu erstellt werden.

So konfigurieren Sie eine SageMaker-Notebookinstanz, um den direkten Internetzugriff zu verweigern:

1. Öffnen Sie die SageMaker-Konsole unter https://console.aws.amazon.com/sagemaker/.
2. Rufen Sie „Notebook-Instanzen“ auf.
3. Löschen Sie die Instanz, für die der direkte Internetzugriff aktiviert ist. Wählen Sie die Instanz, dann „Aktionen“ und dann „Beenden“ aus.
4. Wählen Sie nach dem Beenden der Instanz „Aktionen“ und dann „Löschen“ aus.
5. Wählen Sie „Notebook-Instanz erstellen“ aus. Geben Sie die Konfigurationsdetails an.
6. Maximieren Sie den Bereich „Netzwerk“ und wählen Sie dann ein VPC, ein Subnetz und eine Sicherheitsgruppe aus. Wählen Sie unter „Direkter Internetzugriff“ die Option „Deaktivieren – Internetzugriff über eine VPC“ aus.
7. Wählen Sie „Notebook-Instanz erstellen“ aus.

Weitere Informationen finden Sie im Amazon SageMaker Developer Guide unter „Notebook-Instanz mit Ressourcen in einer VPC verbinden“.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Secretsmanager Rotation Enabled Check

Kategoriename in der API: SECRETSMANAGER_ROTATION_ENABLED_CHECK

Prüft, ob ein in AWS Secrets Manager gespeichertes Secret für die automatische Rotation konfiguriert ist. Die Steuerung schlägt fehl, wenn das Secret nicht für die automatische Rotation konfiguriert ist. Wenn Sie einen benutzerdefinierten Wert für den Parameter maximumAllowedRotationFrequency angeben, wird die Prüfung nur bestanden, wenn das Secret innerhalb des angegebenen Zeitraums automatisch rotiert wird.

Mit Secret Manager können Sie die Sicherheit Ihres Unternehmens verbessern. Zu Secrets gehören Datenbankanmeldedaten, Passwörter und API-Schlüssel von Drittanbietern. Mit Secret Manager können Sie Secrets zentral speichern, automatisch verschlüsseln, den Zugriff darauf steuern und Secrets sicher und automatisch rotieren.

Secrets Manager kann Secrets rotieren. Sie können die Rotation verwenden, um langfristige Geheimnisse durch kurzfristige zu ersetzen. Durch das Rotieren Ihrer Secrets wird begrenzt, wie lange ein nicht autorisierter Nutzer ein manipuliertes Secret verwenden kann. Aus diesem Grund sollten Sie Ihre Secrets regelmäßig wechseln. Weitere Informationen zur Rotation finden Sie im AWS Secrets Manager-Nutzerhandbuch unter „AWS Secrets Manager-Secrets rotieren“.

Empfehlung: Prüft, ob für alle AWS Secrets Manager-Secrets die Rotation aktiviert ist

Informationen zum Aktivieren der automatischen Rotation für Secrets Manager-Secrets finden Sie im Benutzerhandbuch für AWS Secrets Manager unter „Automatische Rotation für AWS Secrets Manager-Secrets über die Console einrichten“. Sie müssen eine AWS Lambda-Funktion für die Rotation auswählen und konfigurieren.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Sns Encrypted Kms

Kategoriename in der API: SNS_ENCRYPTED_KMS

Prüft, ob ein SNS-Thema im Ruhezustand mit AWS KMS verschlüsselt ist. Die Steuerelemente funktionieren nicht, wenn für ein SNS-Thema kein KMS-Schlüssel für die serverseitige Verschlüsselung (SSE) verwendet wird.

Durch die Verschlüsselung ruhender Daten wird das Risiko verringert, dass auf auf dem Laufwerk gespeicherte Daten von einem Nutzer zugegriffen wird, der nicht bei AWS authentifiziert ist. Außerdem werden weitere Zugriffssteuerungen hinzugefügt, um den Zugriff nicht autorisierter Nutzer auf die Daten einzuschränken. Beispielsweise sind API-Berechtigungen erforderlich, um die Daten zu entschlüsseln, bevor sie gelesen werden können. SNS-Themen sollten ruhende Daten verschlüsseln, um für zusätzliche Sicherheit zu sorgen.

Empfehlung: Prüfen Sie, ob alle SNS-Themen mit KMS verschlüsselt sind

Informationen zum Aktivieren der serverseitigen Verschlüsselung (SSE) für ein SNS-Thema finden Sie im Entwicklerhandbuch für den Amazon Simple Notification Service unter „Serverseitige Verschlüsselung (SSE) für ein Amazon SNS-Thema aktivieren“. Bevor Sie die serverseitige Verschlüsselung verwenden können, müssen Sie auch AWS KMS-Schlüsselrichtlinien konfigurieren, um die Verschlüsselung von Themen sowie die Verschlüsselung und Entschlüsselung von Nachrichten zu ermöglichen. Weitere Informationen finden Sie im Entwicklerhandbuch für Amazon Simple Notification Service unter „AWS KMS-Berechtigungen konfigurieren“.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Vpc Default Security Group Closed

Kategoriename in der API: VPC_DEFAULT_SECURITY_GROUP_CLOSED

Mit dieser Einstellung wird geprüft, ob die Standardsicherheitsgruppe einer VPC eingehenden oder ausgehenden Traffic zulässt. Die Prüfung schlägt fehl, wenn die Sicherheitsgruppe eingehenden oder ausgehenden Traffic zulässt.

Die Regeln für die Standardsicherheitsgruppe erlauben den gesamten ausgehenden und eingehenden Traffic von Netzwerkschnittstellen (und ihren zugehörigen Instanzen), die derselben Sicherheitsgruppe zugewiesen sind. Wir empfehlen, die Standardsicherheitsgruppe nicht zu verwenden. Da die Standardsicherheitsgruppe nicht gelöscht werden kann, sollten Sie die Einstellung für die Standardsicherheitsgruppenregeln ändern, um eingehenden und ausgehenden Traffic einzuschränken. So wird unerwünschter Traffic verhindert, wenn die Standardsicherheitsgruppe versehentlich für Ressourcen wie EC2-Instanzen konfiguriert wird.

Empfehlung: Achten Sie darauf, dass die Standardsicherheitsgruppe jeder VPC den gesamten Traffic einschränkt

Erstellen Sie zuerst neue Sicherheitsgruppen mit den geringsten Berechtigungen, um dieses Problem zu beheben. Eine Anleitung finden Sie im Amazon VPC-Nutzerhandbuch unter „Sicherheitsgruppe erstellen“. Weisen Sie dann die neuen Sicherheitsgruppen Ihren EC2-Instanzen zu. Eine Anleitung finden Sie im Amazon EC2-Nutzerhandbuch für Linux-Instanzen unter „Sicherheitsgruppe einer Instanz ändern“.

Nachdem Sie Ihren Ressourcen die neuen Sicherheitsgruppen zugewiesen haben, entfernen Sie alle ein- und ausgehenden Regeln aus den Standardsicherheitsgruppen. Eine Anleitung finden Sie im Amazon VPC-Nutzerhandbuch unter „Sicherheitsgruppenregeln löschen“.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Vpc Flow Logging Enabled All Vpcs

Kategoriename in der API: VPC_FLOW_LOGGING_ENABLED_ALL_VPCS

Mit VPC-Flusslogs können Sie Informationen zum IP-Traffic erfassen, der an Netzwerkschnittstellen in Ihrem VPC ein- und ausgeht. Nachdem Sie ein Ablaufprotokoll erstellt haben, können Sie die Daten in Amazon CloudWatch Logs aufrufen und abrufen. Es wird empfohlen, VPC-Flusslogs für Pakete vom Typ „Abgelehnt“ für VPCs zu aktivieren.

Empfehlung: Achten Sie darauf, dass VPC-Fluss-Logging in allen VPCs aktiviert ist

Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu korrigieren:

AWS-Konsole

1. In der Verwaltungskonsole anmelden
2. Wählen Sie Services und dann VPC aus.
3. Wählen Sie im linken Navigationsbereich Your VPCs
4. VPC auswählen
5. Wählen Sie im rechten Bereich den Tab Flow Logs aus.
6. Wenn kein Ablaufprotokoll vorhanden ist, klicken Sie auf Create Flow Log.
7. Wählen Sie für „Filter“ die Option Reject aus.
8. Geben Sie Role und Destination Log Group ein
9. Klicken Sie auf Create Log Flow.
10. Klicken Sie auf CloudWatch Logs Group.

Hinweis:Wenn Sie den Filter auf „Ablehnen“ setzen, wird die Menge der Protokolldaten für diese Empfehlung drastisch reduziert. Sie erhalten jedoch ausreichend Informationen, um Sicherheitsverstöße zu erkennen, zu untersuchen und zu beheben. Wenn Sie jedoch eine Sicherheitsgruppe mit den geringsten Berechtigungen erstellen, kann es sehr hilfreich sein, den Filter auf „Alle“ zu setzen, um vorhandene Trafficflüsse zu ermitteln, die für den ordnungsgemäßen Betrieb einer bereits laufenden Umgebung erforderlich sind.

AWS-CLI

1. Erstellen Sie ein Richtliniendokument, benennen Sie es role_policy_document.json und fügen Sie den folgenden Inhalt ein:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Sid": "test",
 "Effect": "Allow",
 "Principal": {
 "Service": "ec2.amazonaws.com"
 },
 "Action": "sts:AssumeRole"
 }
 ]
}

2. Erstellen Sie ein weiteres Richtliniendokument, benennen Sie es iam_policy.json und fügen Sie den folgenden Inhalt ein:

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action":[
 "logs:CreateLogGroup",
 "logs:CreateLogStream",
 "logs:DescribeLogGroups",
 "logs:DescribeLogStreams",
 "logs:PutLogEvents",
 "logs:GetLogEvents",
 "logs:FilterLogEvents"
 ],
 "Resource": "*"
 }
 ]
}

3. Führen Sie den folgenden Befehl aus, um eine IAM-Rolle zu erstellen:

aws iam create-role --role-name <aws_support_iam_role> --assume-role-policy-document file://<file-path>role_policy_document.json

4. Führen Sie den folgenden Befehl aus, um eine IAM-Richtlinie zu erstellen:

aws iam create-policy --policy-name <ami-policy-name> --policy-document file://<file-path>iam-policy.json

5. Führen Sie den Befehl attach-group-policy mit der im vorherigen Schritt zurückgegebenen ARN der IAM-Richtlinie aus, um die Richtlinie an die IAM-Rolle anzuhängen. Wenn der Befehl erfolgreich ist, wird keine Ausgabe zurückgegeben:

aws iam attach-group-policy --policy-arn arn:aws:iam::<aws-account-id>:policy/<iam-policy-name> --group-name <group-name>

6. Führen Sie describe-vpcs aus, um den in der ausgewählten Region verfügbaren VpcId abzurufen:

aws ec2 describe-vpcs --region <region>

7. Die Befehlsausgabe sollte die VPC-ID zurückgeben, die in der ausgewählten Region verfügbar ist.
8. Führen Sie create-flow-logs aus, um ein Flussprotokoll für die VPC zu erstellen:

aws ec2 create-flow-logs --resource-type VPC --resource-ids <vpc-id> --traffic-type REJECT --log-group-name <log-group-name> --deliver-logs-permission-arn <iam-role-arn>

9. Wiederholen Sie Schritt 8 für andere VPCs, die in der ausgewählten Region verfügbar sind.
10. Ändern Sie die Region, indem Sie „–region“ aktualisieren, und wiederholen Sie die Behebung für andere VPCs.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Vpc Sg Open Only To Authorized Ports

Kategoriename in der API: VPC_SG_OPEN_ONLY_TO_AUTHORIZED_PORTS

Mit dieser Einstellung wird geprüft, ob eine Amazon EC2-Sicherheitsgruppe uneingeschränkten eingehenden Traffic von nicht autorisierten Ports zulässt. Der Steuerstatus wird so ermittelt:

Wenn Sie den Standardwert für „authorizedTcpPorts“ verwenden, schlägt die Prüfung fehl, wenn die Sicherheitsgruppe uneingeschränkten eingehenden Traffic von einem anderen Port als den Ports 80 und 443 zulässt.

Wenn Sie benutzerdefinierte Werte für „authorizedTcpPorts“ oder „authorizedUdpPorts“ angeben, schlägt die Prüfung fehl, wenn die Sicherheitsgruppe uneingeschränkten eingehenden Traffic von einem nicht aufgeführten Port zulässt.

Wenn kein Parameter verwendet wird, schlägt die Steuerung für alle Sicherheitsgruppen fehl, die eine Regel für uneingeschränkten eingehenden Traffic haben.

Sicherheitsgruppen ermöglichen die zustandsabhängige Filterung von eingehenden und ausgehenden Netzwerkverkehr zu AWS. Sicherheitsgruppenregeln sollten dem Prinzip der geringsten Berechtigung folgen. Der unbeschränkte Zugriff (IP-Adresse mit dem Suffix „/0“) erhöht die Wahrscheinlichkeit für schädliche Aktivitäten wie Hacking, Denial-of-Service-Angriffe und Datenverluste. Sofern ein Port nicht ausdrücklich zugelassen ist, sollte er den uneingeschränkten Zugriff verweigern.

Empfehlung: Prüfen Sie, ob Sicherheitsgruppen mit 0.0.0.0/0 von VPCs nur bestimmten eingehenden TCP/UDP-Traffic zulassen

Informationen zum Ändern einer Sicherheitsgruppe finden Sie im Amazon VPC-Nutzerhandbuch unter Sicherheitsgruppen verwenden.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.

Both VPC VPN Tunnels Up

Kategoriename in der API: VPC_VPN_2_TUNNELS_UP

Ein VPN-Tunnel ist eine verschlüsselte Verbindung, über die Daten innerhalb einer AWS-Site-to-Site-VPN-Verbindung vom Kundennetzwerk zu oder von AWS übertragen werden können. Jede VPN-Verbindung umfasst zwei VPN-Tunnel, die Sie gleichzeitig für Hochverfügbarkeit verwenden können. Es ist wichtig, dass beide VPN-Tunnel für eine VPN-Verbindung aktiviert sind, um eine sichere und hochverfügbare Verbindung zwischen einem AWS-VPC und Ihrem Remote-Netzwerk zu gewährleisten.

Mit dieser Prüfung wird überprüft, ob beide VPN-Tunnel, die von AWS Site-to-Site VPN bereitgestellt werden, den Status „UP“ haben. Die Steuerung schlägt fehl, wenn einer oder beide Tunnel den Status „AUS“ haben.

Empfehlung: Überprüft, ob beide AWS VPC-Tunnel, die von AWS Site-to-Site bereitgestellt werden, im UP-Status sind

Informationen zum Ändern von VPN-Tunneloptionen finden Sie im Benutzerhandbuch für Site-to-Site-VPN von AWS unter Site-to-Site-VPN-Tunneloptionen ändern.

Informationen zu den unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.