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, bitten Sie Ihren Administrator um Unterstützung. Informationen zu Rollen finden Sie unter Zugriffssteuerung. Informationen zum Beheben von Ressourcenfehlern finden Sie in der Dokumentation zu den betroffenen Produkten.
Behebung von Security Health Analytics-Ergebnissen
Dieser Abschnitt enthält Anweisungen zur Behebung aller Ergebnisse von Security Health Analytics.
Deaktivierung von Ergebnissen nach der Korrektur
Nachdem Sie eine Sicherheitslücke oder ein fehlerhaftes Konfigurationsergebnis behoben haben, setzt Security Health Analytics den Status des Ergebnisses automatisch auf INACTIVE
, wenn das nächste Mal nach dem Ergebnis gesucht wird.
Wie lange Security Health Analytics benötigt, um ein korrigiertes Ergebnis auf INACTIVE
zu setzen, hängt davon ab, wann das Ergebnis repariert wurde und vom Zeitplan des Scans, der das Ergebnis erkennt.
Security Health Analytics setzt den Status eines Ergebnisses außerdem auf INACTIVE
, wenn ein Scan erkennt, dass die von dem Ergebnis betroffene Ressource gelöscht ist. Wenn Sie ein Ergebnis für eine gelöschte Ressource von Ihrer Anzeige entfernen möchten, während Security Health Analytics feststellt, dass die Ressource gelöscht wurde, können Sie das Ergebnis ausblenden. Informationen zum Ausblenden eines Ergebnisses finden Sie unter Ergebnisse in Security Command Center ausblenden.
Verwenden Sie die Ausblendung nicht, um korrigierte Ergebnisse für vorhandene Ressourcen auszublenden.
Wenn das Problem wieder auftritt und Security Health Analytics den Status ACTIVE
des Ergebnisses wiederherstellt, sehen Sie das reaktivierte Ergebnis möglicherweise nicht. Das liegt daran, dass ausgeblendete Ergebnisse von jeder Ergebnisabfrage ausgeschlossen werden, die NOT mute="MUTED"
angibt, z. B. der Standardergebnisabfrage.
Informationen zu Scanintervallen finden Sie unter Scantypen für Security Health Analytics.
Access Transparency disabled
Kategoriename in der API: ACCESS_TRANSPARENCY_DISABLED
Access Transparency-Logs, wenn Google Cloud-Mitarbeiter auf Projekte in Ihrer Organisation zugreifen, um Support zu bieten. Aktivieren Sie Access Transparency, um zu protokollieren, wer von Google Cloud wann und warum auf Ihre Informationen zugreift. Weitere Informationen finden Sie unter Access Transparency.
Damit Access Transparency für ein Projekt aktiviert werden kann, muss das Projekt 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 zum Ausführen dieser 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 zum Ausführen dieser Aufgabe erforderlich sind. Möglicherweise können Sie 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:
Prüfen Sie Ihre Berechtigungen auf Organisationsebene:
Rufen Sie in der Google Cloud Console die Seite Identity and Access Management auf.
Wenn Sie dazu aufgefordert werden, wählen Sie im Auswahlmenü die Google Cloud-Organisation aus.
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.
Gehen Sie zur Seite IAM & Verwaltung > Einstellungen.
Klicken Sie auf Access Transparency aktivieren.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denAlloyDB auto backup disabled
Kategoriename in der API: ALLOYDB_AUTO_BACKUP_DISABLED
Für einen AlloyDB for PostgreSQL-Cluster sind keine automatischen Sicherungen aktiviert.
Aktivieren Sie automatische Sicherungen für Ihren Cluster, um Datenverluste zu vermeiden. Weitere Informationen finden Sie unter Zusätzliche automatische Sicherungen konfigurieren.
Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:
Rufen Sie in der Google Cloud Console die AlloyDB for PostgreSQL-Clusterseite auf.
Klicken Sie in der Spalte Ressourcenname auf einen Cluster.
Klicken Sie auf Datenschutz.
Klicken Sie im Bereich Richtlinie für automatische Sicherungen in der Zeile Automatische Sicherungen auf Bearbeiten.
Klicken Sie das Kästchen Automatische Sicherungen an.
Klicken Sie auf Aktualisieren.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denAlloyDB log min error statement severity
Kategoriename in der API: ALLOYDB_LOG_MIN_ERROR_STATEMENT_SEVERITY
Für eine 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 der Schweregrad zu hoch 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:
Rufen Sie in der Google Cloud Console die AlloyDB for PostgreSQL-Clusterseite auf.
Klicken Sie in der Spalte Ressourcenname auf den Cluster.
Klicken Sie im Bereich Instanzen im Cluster für die Instanz auf Bearbeiten.
Klicken Sie auf Advanced Configuration Options.
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
Klicken Sie auf Instanz aktualisieren.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denAlloyDB log min messages
Kategoriename in der API: ALLOYDB_LOG_MIN_MESSAGES
Für eine AlloyDB for PostgreSQL-Instanz ist das Datenbank-Flag log_min_messages
nicht mindestens auf warning
festgelegt.
Das Flag log_min_messages
steuert, welche Meldungsebenen in Serverlogs aufgezeichnet werden. Je höher der Schweregrad, desto weniger Meldungen werden aufgezeichnet. Wenn Sie den Schwellenwert zu niedrig ansetzen, kann sich die Größe und Länge 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:
Rufen Sie in der Google Cloud Console die AlloyDB for PostgreSQL-Clusterseite auf.
Klicken Sie in der Spalte Ressourcenname auf den Cluster.
Klicken Sie im Bereich Instanzen im Cluster für die Instanz auf Bearbeiten.
Klicken Sie auf Advanced Configuration Options.
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
Klicken Sie auf Instanz aktualisieren.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denAlloyDB log error verbosity
Kategoriename in der API: ALLOYDB_LOG_ERROR_VERBOSITY
Für eine 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 den Detaillierungsgrad der protokollierten Nachrichten. 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:
Rufen Sie in der Google Cloud Console die AlloyDB for PostgreSQL-Clusterseite auf.
Klicken Sie in der Spalte Ressourcenname auf den Cluster.
Klicken Sie im Bereich Instanzen im Cluster für die Instanz auf Bearbeiten.
Klicken Sie auf Advanced Configuration Options.
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
Klicken Sie auf Instanz aktualisieren.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denAdmin service account
Kategoriename in der API: ADMIN_SERVICE_ACCOUNT
Einem Dienstkonto in Ihrer Organisation oder Ihrem Projekt sind die Berechtigungen Administrator, Inhaber oder Bearbeiter 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:
Rufen Sie in der Google Cloud Console die Seite IAM-Richtlinien auf.
Für jedes im Ergebnis identifizierte Hauptkonto:
- Klicken Sie neben dem Hauptkonto auf Bearbeiten edit.
- Klicken Sie neben der entsprechenden Rolle oben auf Löschen delete, um die Berechtigungen zu entfernen.
- Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denAlpha 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.
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.
Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.
Klicken Sie auf Erstellen.
Wählen Sie neben dem zu erstellenden Clustertyp Konfigurieren aus.
Im Tab Features muss Kubernetes-Alphafeatures in diesem Cluster aktivieren deaktiviert sein.
Klicken Sie auf Erstellen.
Informationen zum Verschieben von Arbeitslasten auf den neuen Cluster finden Sie unter Arbeitslasten zu anderen Maschinentypen migrieren.
Informationen zum Löschen des ursprünglichen Clusters finden Sie unter Cluster löschen.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denAPI 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:
Rufen Sie in der Google Cloud Console die Seite API-Schlüssel auf.
Führen Sie für jeden API-Schlüssel die folgenden Schritte aus:
- Rufen Sie im Abschnitt API-Schlüssel in der Zeile für jeden API-Schlüssel, für den Sie APIs einschränken müssen, das Menü Aktionen auf. Klicken Sie dazu auf .
- Klicken Sie im Menü Aktionen auf API-Schlüssel bearbeiten. Die Seite API-Schlüssel bearbeiten wird geöffnet.
- Wählen Sie im Abschnitt API-Einschränkungen die Option APIs einschränken aus. Das Drop-down-Menü APIs auswählen wird angezeigt.
- Wählen Sie in der Drop-down-Liste APIs auswählen aus, welche APIs zugelassen werden sollen.
- Klicken Sie auf Speichern. Es kann bis zu fünf Minuten dauern, bis die Einstellungen wirksam werden.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denAPI 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:
Rufen Sie in der Google Cloud Console die Seite API-Schlüssel auf.
Führen Sie für jeden API-Schlüssel die folgenden Schritte aus:
- Rufen Sie im Abschnitt API-Schlüssel in der Zeile für jeden API-Schlüssel, für den Sie Anwendungen einschränken müssen, das Menü Aktionen auf. Klicken Sie dazu auf das Symbol .
- Klicken Sie im Menü Aktionen auf API-Schlüssel bearbeiten. Die Seite API-Schlüssel bearbeiten wird geöffnet.
- 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.
- 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.
- Wenn Sie alle gewünschten Elemente hinzugefügt haben, klicken Sie auf Fertig.
- Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denAPI 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 einfach verschlüsselte Strings sind und von anderen leicht erkannt und verwendet werden können. Sie können über einen Browser auf Geräten abgerufen werden, auf denen der Schlüssel gespeichert ist oder beispielsweise öffentlich sichtbar ist. Außerdem lassen sich mit API-Schlüsseln Nutzer oder Anwendungen, die Anfragen stellen, nicht eindeutig identifizieren. Alternativ können Sie einen standardmäßigen Authentifizierungsvorgang mit Dienstkonten oder Nutzerkonten verwenden.
Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:
- Ihre Anwendungen sollten mit einer alternativen Art der Authentifizierung konfiguriert werden.
Rufen Sie in der Google Cloud Console die Seite Anmeldedaten der API auf.
Zeigen Sie im Abschnitt API-Schlüssel in der Zeile für jeden API-Schlüssel, den Sie löschen müssen, das Menü Aktionen an. Dazu klicken Sie auf das Symbol
.Klicken Sie im Menü Aktionen auf API-Schlüssel löschen.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denAPI 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 API-Schlüssel sichern.
Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:
Rufen Sie in der Google Cloud Console die Seite API-Schlüssel auf.
Führen Sie für jeden API-Schlüssel die folgenden Schritte aus:
- Klicken im Bereich API-Schlüssel in der Zeile des zu rotierenden API-Schlüssels auf das Symbol , um das Menü Aktionen aufzurufen.
- Klicken Sie im Menü Aktionen auf API-Schlüssel bearbeiten. Die Seite API-Schlüssel bearbeiten wird geöffnet.
- Wenn auf der Seite API-Schlüssel bearbeiten das Datum im Feld Erstellungsdatum älter als 90 Tage ist, ersetzen Sie den Schlüssel, indem Sie auf Schlüssel neu generieren oben auf der Seite klicken. Ein neuer Ersatzschlüssel wird generiert.
- Klicken Sie auf Speichern.
- 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.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denAudit 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 Kostenoptimierung für die Google Cloud-Beobachtbarkeit.
Bei Aktivierungen 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
Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf.
Klicken Sie auf Messwert erstellen.
Wählen Sie unter Messwerttyp die Option Zähler aus.
Unter Details:
- Legen Sie unter Name des Logmesswerts einen Namen fest.
- Fügen Sie eine Beschreibung hinzu.
- Legen Sie Einheiten auf 1 fest.
Kopieren Sie unter Filterauswahl den folgenden Text und fügen Sie ihn in das Feld Filter erstellen ein. Ersetzen Sie bei Bedarf den vorhandenen Text:
protoPayload.methodName="SetIamPolicy" AND protoPayload.serviceData.policyDelta.auditConfigDeltas:*
Klicken Sie auf Messwert erstellen. Sie sehen eine Bestätigung.
Benachrichtigungsrichtlinie erstellen
-
Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf:
Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.
- Wählen Sie im Bereich Benutzerdefinierte Messwerte den Messwert aus, den Sie im vorherigen Abschnitt erstellt haben.
-
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.
- Klicken Sie auf Weiter.
- Prüfen Sie die vorkonfigurierten Einstellungen. Sie können den Schwellenwert ändern.
- Klicken Sie auf Bedingungsname und geben Sie einen Namen für die Bedingung ein.
- Klicken Sie auf Weiter.
Klicken Sie auf Benachrichtigungskanäle, um der Benachrichtigungsrichtlinie Benachrichtigungen hinzuzufügen. Wählen Sie im Dialogfeld einen oder mehrere Benachrichtigungskanäle aus dem Menü aus und klicken Sie dann auf OK.
Um beim Öffnen und Schließen von Vorfällen benachrichtigt zu werden, aktivieren Sie die Option Bei Schließung des Vorfalls benachrichtigen. Standardmäßig werden Benachrichtigungen nur gesendet, wenn Vorfälle geöffnet werden.
- Optional: Aktualisieren Sie die Dauer bis zur automatischen Schließung von Vorfällen. Dieses Feld bestimmt, wann Monitoring Vorfälle ohne Messwertdaten schließt.
- Optional: Klicken Sie auf Dokumentation und geben Sie alle Informationen ein, die in einer Benachrichtigung angezeigt werden sollen.
- Klicken Sie auf Name der Benachrichtigung und geben Sie einen Namen für die Benachrichtigungsrichtlinie ein.
- Klicken Sie auf Richtlinie erstellen.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denAudit logging disabled
Kategoriename in der API: AUDIT_LOGGING_DISABLED
Dieses Ergebnis ist für Aktivierungen auf Projektebene nicht verfügbar.
Audit-Logging ist für einen oder mehrere Google Cloud-Dienste deaktiviert oder ein oder mehrere Hauptkonten 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 seinen Kosten finden Sie unter Kostenoptimierung für die Google Cloud-Beobachtbarkeit.
Wenn Hauptkonten in der Standardkonfiguration des Audit-Loggings 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:
Rufen Sie in der Google Cloud Console die Seite Standardkonfiguration der Audit-Logs zum Datenzugriff auf.
Aktivieren Sie auf dem Tab Logtypen das Audit-Logging für den Datenzugriff in der Standardkonfiguration:
- Wählen Sie Lesen durch Administrator, Daten lesen und Daten schreiben aus.
- Klicken Sie auf Speichern.
Entfernen Sie auf dem Tab Ausgenommene Hauptkonten alle ausgenommenen Nutzer aus der Standardkonfiguration:
- Entfernen Sie jedes aufgeführte Hauptkonto. Klicken Sie dazu neben dem jeweiligen Namen auf Löschen delete.
- Klicken Sie auf Speichern.
Rufen Sie die Seite Audit-Logs auf.
Entfernen Sie alle ausgenommenen Hauptkonten aus den Audit-Log-Konfigurationen für den Datenzugriff einzelner Dienste.
- Klicken Sie unter Konfiguration von Audit-Logs zum Datenzugriff auf jeden Dienst, für den ein ausgenommenes Hauptkonto angezeigt wird. Ein Audit-Log-Konfigurationsbereich wird für den Dienst geöffnet.
- Entfernen Sie auf dem Tab Ausgenommene Hauptkonten alle ausgenommenen Hauptkonten. Klicken Sie dazu neben jedem Namen auf Löschen delete.
- Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denAuto 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:
Rufen Sie in der Google Cloud Console die Seite SQL-Instanzsicherungen auf.
Klicken Sie neben Einstellungen auf editBearbeiten.
Klicken Sie das Kästchen Automatische Sicherungen an.
Wählen Sie im Drop-down-Menü ein Zeitfenster für die automatische Sicherung Ihrer Daten aus.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denAuto 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:
Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.
Klicken Sie auf den Tab Knoten.
Führen Sie für jeden Knotenpool die folgenden Schritte aus:
- Klicken Sie auf den Namen des Knotenpools, um zur Detailseite zu wechseln.
- Klicken Sie auf Bearbeiten edit.
- Wählen Sie unter Verwaltung die Option Automatische Reparatur aktivieren aus.
- Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denAuto 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:
Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.
Klicken Sie in der Liste der Cluster auf den Namen des Clusters.
Klicken Sie auf den Tab Knoten.
Führen Sie für jeden Knotenpool die folgenden Schritte aus:
- Klicken Sie auf den Namen des Knotenpools, um zur Detailseite zu wechseln.
- Klicken Sie auf Bearbeiten edit.
- Wählen Sie unter Verwaltung die Option Automatisches Upgrade aktivieren aus.
- Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denBigQuery 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.
Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:
- Erstellen Sie eine durch Cloud Key Management Service geschützte Tabelle.
- Kopieren Sie die Tabelle in die neue CMEK-fähige Tabelle.
- 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.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denBinary 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:
Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.
Klicken Sie im Bereich Sicherheit in der Zeile Binärautorisierung auf das Symbol „Bearbeiten“ (edit).
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.
Wählen Sie im Dialogfeld die Option Binärautorisierung aktivieren aus.
Klicken Sie auf Änderungen speichern.
Rufen Sie die Seite "Binärautorisierung" einrichten auf.
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.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denBucket 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.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denBucket 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 Kostenoptimierung für die Google Cloud-Beobachtbarkeit.
Bei Aktivierungen 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
Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf.
Klicken Sie auf Messwert erstellen.
Wählen Sie unter Messwerttyp die Option Zähler aus.
Unter Details:
- Legen Sie unter Name des Logmesswerts einen Namen fest.
- Fügen Sie eine Beschreibung hinzu.
- Legen Sie Einheiten auf 1 fest.
Kopieren Sie unter Filterauswahl den folgenden Text und fügen Sie ihn in das Feld Filter erstellen ein. Ersetzen Sie bei Bedarf den vorhandenen Text:
resource.type=gcs_bucket AND protoPayload.methodName="storage.setIamPermissions"
Klicken Sie auf Messwert erstellen. Sie sehen eine Bestätigung.
Benachrichtigungsrichtlinie erstellen
-
Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf:
Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.
- Wählen Sie im Bereich Benutzerdefinierte Messwerte den Messwert aus, den Sie im vorherigen Abschnitt erstellt haben.
-
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.
- Klicken Sie auf Weiter.
- Prüfen Sie die vorkonfigurierten Einstellungen. Sie können den Schwellenwert ändern.
- Klicken Sie auf Bedingungsname und geben Sie einen Namen für die Bedingung ein.
- Klicken Sie auf Weiter.
Klicken Sie auf Benachrichtigungskanäle, um der Benachrichtigungsrichtlinie Benachrichtigungen hinzuzufügen. Wählen Sie im Dialogfeld einen oder mehrere Benachrichtigungskanäle aus dem Menü aus und klicken Sie dann auf OK.
Um beim Öffnen und Schließen von Vorfällen benachrichtigt zu werden, aktivieren Sie die Option Bei Schließung des Vorfalls benachrichtigen. Standardmäßig werden Benachrichtigungen nur gesendet, wenn Vorfälle geöffnet werden.
- Optional: Aktualisieren Sie die Dauer bis zur automatischen Schließung von Vorfällen. Dieses Feld bestimmt, wann Monitoring Vorfälle ohne Messwertdaten schließt.
- Optional: Klicken Sie auf Dokumentation und geben Sie alle Informationen ein, die in einer Benachrichtigung angezeigt werden sollen.
- Klicken Sie auf Name der Benachrichtigung und geben Sie einen Namen für die Benachrichtigungsrichtlinie ein.
- Klicken Sie auf Richtlinie erstellen.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denBucket 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.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denBucket 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:
Rufen Sie in der Google Cloud Console die Seite des Cloud Storage-Browsers auf.
Klicken Sie in der Bucket-Liste auf den Namen des gewünschten Buckets.
Klicken Sie auf den Tab Configuration (Konfiguration).
Klicken Sie unter Berechtigungen in der Zeile für Zugriffssteuerung auf das Symbol Bearbeiten (edit).
Wählen Sie im Dialogfeld die Option Einheitlich aus.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denCloud 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:
Rufen Sie in der Google Cloud Console die Seite API-Bibliothek auf.
Suchen Sie nach
Cloud Asset Inventory
.Wählen Sie das Ergebnis für den Dienst Cloud Asset API aus.
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 seinen Kosten finden Sie unter Kostenoptimierung für die Google Cloud-Beobachtbarkeit.
Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:
Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.
Wählen Sie den Cluster aus, der im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit 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.
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.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denCluster 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 Kostenoptimierung für die Google Cloud-Beobachtbarkeit.
Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:
Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.
Wählen Sie den Cluster aus, der im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit 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.
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.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denCluster 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 Aktivierungen 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:
Rufen Sie in der Google Cloud Console die Seite Virtual Private Cloud-Netzwerke auf.
Klicken Sie in der Liste der Netzwerke auf den Namen des Netzwerks.
Klicken Sie auf der Seite VPC-Netzwerkdetails auf den Tab Subnetze.
Klicken Sie in der Liste der Subnetze auf den Namen des Subnetzes, das dem Kubernetes-Cluster im Ergebnis zugeordnet ist.
Klicken Sie auf der Seite mit den Subnetz-Details auf Bearbeiten edit.
Wählen Sie für Privater Google-Zugriff die Option Ein aus.
Klicken Sie auf Speichern.
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.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denCluster 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:
Rufen Sie in der Google Cloud Console die Seite Cloud KMS-Schlüssel auf.
Ü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.
Rufen Sie die Seite Kubernetes-Cluster auf.
Wählen Sie den Cluster im Ergebnis aus.
Klicken Sie unter Sicherheit im Feld Verschlüsselung von Secrets auf Anwendungsebene auf edit Verschlüsselung von Secrets auf Anwendungsebene bearbeiten.
Klicken Sie auf das Kästchen Verschlüsselung von Secrets auf Anwendungsebene aktivieren und wählen Sie dann den erstellten DEK aus.
Klicken Sie auf Änderungen speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denCluster 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:
Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.
Wählen Sie den Cluster im Ergebnis aus.
Klicken Sie unter Sicherheit im Feld Shielded GKE-Knoten auf edit Shielded GKE-Knoten bearbeiten.
Klicken Sie auf das Kästchen Shielded GKE-Knoten aktivieren.
Klicken Sie auf Änderungen speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denCompute 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:
Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.
Klicken Sie in der Liste der Instanzen auf den Namen der Instanz im Ergebnis.
Klicken Sie auf der Seite VM-Instanzdetails auf edit Bearbeiten.
Wählen Sie unter SSH-Schlüssel die Option Projektweite SSH-Schlüssel blockieren aus.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denCompute 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:
Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.
Klicken Sie in der Liste der Instanzen auf den Namen der Instanz im Ergebnis.
Klicken Sie auf der Seite VM-Instanzdetails auf
Stoppen.Wenn die Instanz nicht mehr ausgeführt wird, klicken Sie auf editBearbeiten.
Wählen Sie unter Shielded VM die Option Secure Boot aktivieren aus.
Klicken Sie auf Speichern.
Klicken Sie nun auf
Starten, um die Instanz zu starten.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denCompute 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:
Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.
Klicken Sie in der Liste der Instanzen auf den Namen der Instanz im Ergebnis.
Klicken Sie auf der Seite VM-Instanzdetails auf edit Bearbeiten.
Löschen Sie unter Remotezugriff die Option Verbindung mit seriellen Ports aktivieren.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denConfidential 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.
Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:
Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.
Klicken Sie in der Liste der Instanzen auf den Namen der Instanz im Ergebnis.
Klicken Sie auf der Seite VM-Instanzdetails auf delete Löschen.
Erstellen Sie mit der Google Cloud Console eine Confidential VM.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denCOS 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:
Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.
Klicken Sie in der Liste der Cluster auf den Namen des Clusters in dem Ergebnis.
Klicken Sie auf den Tab Knoten.
Führen Sie für jeden Knotenpool die folgenden Schritte aus:
- Klicken Sie auf den Namen des Knotenpools, um zur Detailseite zu wechseln.
- Klicken Sie auf Bearbeiten edit.
- Klicken Sie unter Knoten -> Image-Typ auf Ändern.
- Wählen Sie Container-Optimized OS aus und klicken Sie dann auf Ändern.
- Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denCustom 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 Kostenoptimierung für die Google Cloud-Beobachtbarkeit.
Bei Aktivierungen 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
Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf.
Klicken Sie auf Messwert erstellen.
Wählen Sie unter Messwerttyp die Option Zähler aus.
Unter Details:
- Legen Sie unter Name des Logmesswerts einen Namen fest.
- Fügen Sie eine Beschreibung hinzu.
- Legen Sie Einheiten auf 1 fest.
Kopieren Sie unter Filterauswahl den folgenden Text und fügen Sie ihn in das Feld Filter erstellen ein. Ersetzen Sie bei Bedarf den vorhandenen Text:
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")
Klicken Sie auf Messwert erstellen. Sie sehen eine Bestätigung.
Benachrichtigungsrichtlinie erstellen
-
Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf:
Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.
- Wählen Sie im Bereich Benutzerdefinierte Messwerte den Messwert aus, den Sie im vorherigen Abschnitt erstellt haben.
-
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.
- Klicken Sie auf Weiter.
- Prüfen Sie die vorkonfigurierten Einstellungen. Sie können den Schwellenwert ändern.
- Klicken Sie auf Bedingungsname und geben Sie einen Namen für die Bedingung ein.
- Klicken Sie auf Weiter.
Klicken Sie auf Benachrichtigungskanäle, um der Benachrichtigungsrichtlinie Benachrichtigungen hinzuzufügen. Wählen Sie im Dialogfeld einen oder mehrere Benachrichtigungskanäle aus dem Menü aus und klicken Sie dann auf OK.
Um beim Öffnen und Schließen von Vorfällen benachrichtigt zu werden, aktivieren Sie die Option Bei Schließung des Vorfalls benachrichtigen. Standardmäßig werden Benachrichtigungen nur gesendet, wenn Vorfälle geöffnet werden.
- Optional: Aktualisieren Sie die Dauer bis zur automatischen Schließung von Vorfällen. Dieses Feld bestimmt, wann Monitoring Vorfälle ohne Messwertdaten schließt.
- Optional: Klicken Sie auf Dokumentation und geben Sie alle Informationen ein, die in einer Benachrichtigung angezeigt werden sollen.
- Klicken Sie auf Name der Benachrichtigung und geben Sie einen Namen für die Benachrichtigungsrichtlinie ein.
- Klicken Sie auf Richtlinie erstellen.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denDataproc CMEK disabled
Kategoriename in der API: DATAPROC_CMEK_DISABLED
Ein Dataproc-Cluster wurde ohne einen Verschlüsselungskonfigurations-CMEK erstellt. Mit CMEK werden die Schlüssel, die Sie in Cloud Key Management Service erstellen und verwalten, von Google Cloud zum Verschlüsseln Ihrer Daten verpackt. So haben Sie mehr Kontrolle über den Zugriff auf Ihre Daten.
Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:
Rufen Sie in der Google Cloud Console die Seite Dataproc-Cluster auf.
Wählen Sie Ihr Projekt aus und klicken Sie auf Cluster erstellen.
Klicken Sie im Abschnitt Sicherheit verwalten auf Verschlüsselung und wählen Sie Vom Kunden verwalteter Schlüssel aus.
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.
Achten Sie darauf, dass dem Dienstkonto des Dataproc-Clusters („serviceAccount:service-project_number@compute-system.iam.gserviceaccount.com“) die Rolle „Cloud KMS CryptoKey-Verschlüsseler/Entschlüsseler“ für den ausgewählten KMS-Schlüssel zugewiesen ist.
Nachdem der Cluster erstellt wurde, migrieren Sie alle Arbeitslasten aus dem alten Cluster zum neuen Cluster.
Rufen Sie die Dataproc-Cluster auf und wählen Sie Ihr Projekt aus.
Wählen Sie den alten Cluster aus und klicken Sie auf delete Löschen.
Wiederholen Sie alle oben genannten Schritte für andere Dataproc-Cluster, die im ausgewählten Projekt verfügbar sind.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denDataproc 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.
Erstellen Sie den betroffenen Cluster neu und aktualisieren Sie ihn, um dieses Ergebnis zu korrigieren.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denDataset 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.
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:
- Erstellen Sie ein neues Dataset.
- Legen Sie einen Standard-CMEK-Schlüssel für das von Ihnen erstellte Dataset fest.
- Wie Sie Tabellen in Ihr CMEK-fähiges Dataset kopieren, erfahren Sie in der Anleitung unter Tabelle kopieren.
- Löschen Sie die ursprünglichen Datasets nach dem erfolgreichen Kopieren der Daten.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denDefault 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.
Bei Aktivierungen 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:
Rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke auf.
Klicken Sie in der Liste der Netzwerke auf den Namen des Netzwerks.
Klicken Sie auf der Seite VPC-Netzwerkdetails auf deleteVPC-Netzwerk löschen.
Informationen zum Erstellen eines neuen Netzwerks mit benutzerdefinierten Firewallregeln finden Sie unter Netzwerke erstellen.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denDefault 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:
Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.
Wählen Sie die Instanz aus, die sich auf das Ergebnis von Security Health Analytics bezieht.
Klicken Sie auf der Seite Instanzdetails, die geladen wird, auf
Beenden.Wenn die Instanz nicht mehr ausgeführt wird, klicken Sie auf editBearbeiten.
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.
Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzdetails angezeigt.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denDisk 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.
Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:
Rufen Sie in der Google Cloud Console die Seite Compute Engine-Laufwerke auf.
Klicken Sie in der Liste der Laufwerke auf den Namen des Laufwerks, das im Ergebnis angegeben ist.
Klicken Sie auf der Seite Laufwerk verwalten auf delete Löschen.
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.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denDisk 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.
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.
Rufen Sie in der Google Cloud Console die Seite Compute Engine-Laufwerke auf.
Klicken Sie in der Liste der Laufwerke auf den Namen des Laufwerks, das im Ergebnis angegeben ist.
Klicken Sie auf der Seite Laufwerk verwalten auf delete Löschen.
Informationen zum Erstellen eines neuen Laufwerks mit aktiviertem CSEK finden Sie unter Laufwerke mit vom Kunden bereitgestellten Verschlüsselungsschlüsseln verschlüsseln.
Führen Sie die verbleibenden Schritte aus, um den Detektor zu aktivieren.
Detektor aktivieren
Rufen Sie in der Google Cloud Console die Seite Assets von Security Command Center auf.
Wählen Sie im Bereich Ressourcentyp des Bereichs Schnellfilter die Option compute.Disk aus.
Wenn compute.Disk nicht angezeigt wird, klicken Sie auf Mehr anzeigen, geben Sie
Disk
in das Suchfeld ein und klicken Sie dann auf Anwenden.Im Bereich Ergebnisse werden jetzt nur noch Instanzen des Ressourcentyps
compute.Disk
angezeigt.Wählen Sie in der Spalte Anzeigename das Kästchen neben dem Namen des Laufwerks aus, das Sie mit CSEK verwenden möchten, und klicken Sie dann auf Sicherheitsmarkierungen festlegen.
Klicken Sie im Dialogfeld auf Add Mark (Markierung hinzufügen).
Geben Sie im Feld Schlüssel den Wert
enforce_customer_supplied_disk_encryption_keys
und im Feld Werttrue
ein.Klicken Sie auf Speichern.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denDNS 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 seinen Kosten finden Sie unter Preise für Google Cloud Observability: Cloud Logging.
Bei Aktivierungen 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:
Rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke auf.
Klicken Sie in der Liste der Netzwerke auf den Namen des VPC-Netzwerks.
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:
- Klicken Sie auf edit Bearbeiten.
- Klicken Sie im Feld DNS-Serverrichtlinie auf Neue Serverrichtlinie erstellen.
- Geben Sie einen Namen für die neue Serverrichtlinie ein.
- Setzen Sie Logs auf Ein.
- Klicken Sie auf Speichern.
Wenn das Netzwerk eine DNS-Serverrichtlinie hat, führen Sie die folgenden Schritte aus:
- Klicken Sie im Feld DNS-Serverrichtlinie auf den Namen der DNS-Richtlinie.
- Klicken Sie auf edit Richtlinie bearbeiten.
- Setzen Sie Logs auf Ein.
- Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denDNSSEC 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:
Rufen Sie in der Google Cloud Console die Seite Cloud DNS auf.
Suchen Sie die Zeile mit der DNS-Zone, die im Ergebnis angegeben ist.
Klicken Sie in der Zeile auf die DNSSEC-Einstellung und wählen Sie dann unter DNSSEC die Option Ein aus.
Lesen Sie die Informationen im angezeigten Dialogfeld. Wenn Sie zufrieden sind, klicken Sie auf Aktivieren.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denEgress 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 Aktivierungen 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:
Rufen Sie in der Google Cloud Console die Seite Firewall auf.
Klicken Sie auf Firewallregel erstellen.
Geben Sie der Firewall einen Namen und optional eine Beschreibung.
Wählen Sie unter Traffic-Richtung die Option Ausgehend aus.
Wählen Sie unter Aktion bei Übereinstimmung die Option Ablehnen aus.
Wählen Sie im Drop-down-Menü Ziele die Option Alle Instanzen im Netzwerk aus.
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.Wählen Sie unter Protokolle und Ports die Option Alle ablehnen aus.
Klicken Sie auf Regel deaktivieren und wählen Sie unter Erzwingung die Option Aktiviert aus.
Klicken Sie auf Erstellen.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denEssential contacts not configured
Kategoriename in der API: ESSENTIAL_CONTACTS_NOT_CONFIGURED
Ihre Organisation hat keine Person oder Gruppe festgelegt, die Benachrichtigungen von Google Cloud über wichtige Ereignisse wie Angriffe, Sicherheitslücken und Datenvorfälle in Ihrer Google Cloud-Organisation erhalten soll. Wir empfehlen, eine oder mehrere Personen oder Gruppen in Ihrem Unternehmen als wesentlichen Kontakt festzulegen.
Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:
Rufen Sie in der Google Cloud Console die Seite Wichtige Kontakte auf.
Prüfen Sie, ob 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 derzeit Kontakte verwalten.
Klicken Sie auf +Kontakt hinzufügen. Der Bereich Kontakt hinzufügen wird geöffnet.
Geben Sie in den Feldern E-Mail und E-Mail bestätigen die E-Mail-Adresse des Kontakts ein.
Wählen Sie im Abschnitt Benachrichtigungskategorien die Benachrichtigungskategorien aus, für die der Kontakt Mitteilungen erhalten soll. Für jede der folgenden Benachrichtigungskategorien müssen geeignete E-Mail-Adressen konfiguriert sein:
- Rechtliches
- Sicherheit
- Sperrung
- Technologie
Klicken Sie auf Speichern. unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu den
Firewall not monitored
Kategoriename in der API: FIREWALL_NOT_MONITORED
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 Kostenoptimierung für die Google Cloud-Beobachtbarkeit.
Bei Aktivierungen 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
Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf.
Klicken Sie auf Messwert erstellen.
Wählen Sie unter Messwerttyp die Option Zähler aus.
Unter Details:
- Legen Sie unter Name des Logmesswerts einen Namen fest.
- Fügen Sie eine Beschreibung hinzu.
- Legen Sie Einheiten auf 1 fest.
Kopieren Sie unter Filterauswahl den folgenden Text und fügen Sie ihn in das Feld Filter erstellen ein. Ersetzen Sie bei Bedarf den vorhandenen Text:
resource.type="gce_firewall_rule" AND (protoPayload.methodName:"compute.firewalls.insert" OR protoPayload.methodName:"compute.firewalls.patch" OR protoPayload.methodName:"compute.firewalls.delete")
Klicken Sie auf Messwert erstellen. Sie sehen eine Bestätigung.
Benachrichtigungsrichtlinie erstellen
-
Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf:
Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.
- Wählen Sie im Bereich Benutzerdefinierte Messwerte den Messwert aus, den Sie im vorherigen Abschnitt erstellt haben.
-
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.
- Klicken Sie auf Weiter.
- Prüfen Sie die vorkonfigurierten Einstellungen. Sie können den Schwellenwert ändern.
- Klicken Sie auf Bedingungsname und geben Sie einen Namen für die Bedingung ein.
- Klicken Sie auf Weiter.
Klicken Sie auf Benachrichtigungskanäle, um der Benachrichtigungsrichtlinie Benachrichtigungen hinzuzufügen. Wählen Sie im Dialogfeld einen oder mehrere Benachrichtigungskanäle aus dem Menü aus und klicken Sie dann auf OK.
Um beim Öffnen und Schließen von Vorfällen benachrichtigt zu werden, aktivieren Sie die Option Bei Schließung des Vorfalls benachrichtigen. Standardmäßig werden Benachrichtigungen nur gesendet, wenn Vorfälle geöffnet werden.
- Optional: Aktualisieren Sie die Dauer bis zur automatischen Schließung von Vorfällen. Dieses Feld bestimmt, wann Monitoring Vorfälle ohne Messwertdaten schließt.
- Optional: Klicken Sie auf Dokumentation und geben Sie alle Informationen ein, die in einer Benachrichtigung angezeigt werden sollen.
- Klicken Sie auf Name der Benachrichtigung und geben Sie einen Namen für die Benachrichtigungsrichtlinie ein.
- Klicken Sie auf Richtlinie erstellen.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denFirewall 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:
Rufen Sie in der Google Cloud Console die Seite Firewall auf.
Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.
Klicken Sie auf edit Bearbeiten.
Wählen Sie unter Logs die Option Ein aus.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denFlow 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:
Rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke auf.
Klicken Sie in der Liste der Netzwerke auf den Namen des Netzwerks.
Klicken Sie auf der Seite VPC-Netzwerkdetails auf den Tab Subnetze.
Klicken Sie in der Liste der Subnetze auf den Namen des Subnetzes, das in den Ergebnissen angegeben ist.
Klicken Sie auf der Seite Subnetzdetails auf edit Bearbeiten.
Wählen Sie unter Fluss-Logs die Option Ein.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denFlow 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.
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:
Rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke auf.
Klicken Sie in der Liste der Netzwerke auf den Namen des Netzwerks.
Klicken Sie auf der Seite VPC-Netzwerkdetails auf den Tab Subnetze.
Klicken Sie in der Liste der Subnetze auf den Namen des Subnetzes, das in den Ergebnissen angegeben ist.
Klicken Sie auf der Seite Subnetzdetails auf edit Bearbeiten.
Wählen Sie unter Fluss-Logs die Option Ein.
- Ä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:
- Legen Sie das Aggregationsintervall auf 5 SEK. fest.
- Wählen Sie unter dem Kästchen Zusatzfelder die Option Metadaten einschließen aus.
- Legen Sie die Abtastrate auf 100% fest.
- Klicken Sie auf SAVE (Speichern).
- Ä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:
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denFull 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 standardmäßigen Dienstkontobereich 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.
Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:
Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.
Klicken Sie in der Liste der Instanzen auf den Namen der Instanz im Ergebnis.
Klicken Sie auf
Beenden, wenn die Instanz derzeit gestartet wird.Wenn die Instanz nicht mehr ausgeführt wird, klicken Sie auf editBearbeiten.
Wählen Sie im Drop-down-Menü unter Dienstkonto die Option Compute Engine-Standarddienstkonto aus.
Achten Sie darauf, dass im Abschnitt Zugriffsbereiche nicht die Option Uneingeschränkten Zugriff auf alle Cloud APIs zulassen ausgewählt ist.
Klicken Sie auf Speichern.
Klicken Sie nun auf
Starten, um die Instanz zu starten.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denHTTP 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 Aktivierungen 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:
Rufen Sie in der Google Cloud Console die Seite Zielproxys auf.
Klicken Sie in der Liste der Zielproxys auf den Namen des Zielproxys im Ergebnis.
Klicken Sie auf den Link im Abschnitt URL-Zuordnung.
Klicken Sie auf edit Bearbeiten.
Klicken Sie auf Front-End-Konfiguration.
Löschen Sie alle Frontend-IP- und Portkonfigurationen, die HTTP-Traffic zulassen, und erstellen Sie neue Konfigurationen, die HTTPS-Traffic zulassen.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denInstance 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 Aktivierungen 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:
Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.
Klicken Sie in der Liste der Instanzen auf den Namen der Instanz im Ergebnis.
Klicken Sie auf der Seite Instanzdetails, die geladen wird, auf
Beenden.Klicken Sie nach dem Beenden der Instanz auf edit Bearbeiten.
Achten Sie im Bereich Benutzerdefinierte Metadaten darauf, dass das Element mit dem Schlüssel enable-oslogin den Wert TRUE hat.
Klicken Sie auf Speichern.
Klicken Sie nun auf
Starten, um die Instanz zu starten.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denIntegrity 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.
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.
Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.
Klicken Sie auf den Namen des Clusters im Ergebnis.
Klicken Sie auf Knotenpool hinzufügen.
Prüfen Sie auf dem Tab Sicherheit, ob die Option Integritätsmonitoring aktivieren aktiviert ist.
Klicken Sie auf Erstellen.
Informationen zum Migrieren Ihrer Arbeitslasten von den vorhandenen nicht konformen Knotenpools zu den neuen Knotenpools finden Sie unter Arbeitslasten zu anderen Maschinentypen migrieren.
Löschen Sie den ursprünglichen nicht konformen Knotenpool, nachdem die Arbeitslasten verschoben wurden.
- Klicken Sie auf der Seite Kubernetes-Cluster im Menü Knotenpools auf den Namen des Knotenpools, den Sie löschen möchten.
- Klicken Sie auf Knotenpool entfernen.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denIntranode 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.
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.
Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.
Klicken Sie im Bereich Netzwerk in der Zeile Knoteninterne Sichtbarkeit auf das Symbol „Bearbeiten“ (edit).
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.
Wählen Sie im Dialogfeld die Option Knoteninterne Sichtbarkeit aktivieren aus.
Klicken Sie auf Änderungen speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denIP 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:
Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.
Klicken Sie auf Erstellen.
Klicken Sie im Navigationsbereich unter Cluster auf Netzwerk.
Wählen Sie unter Erweiterte Netzwerkoptionen die Option VPC-natives Traffic-Routing aktivieren (verwendet Alias-IP-Adresse) aus.
Klicken Sie auf Erstellen.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denIP 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.
Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:
Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.
Klicken Sie in der Liste der Instanzen auf das Kästchen neben dem Namen der Instanz für das Ergebnis.
Klicken Sie auf delete Löschen.
Wählen Sie Instanz erstellen aus, um eine neue Instanz zu erstellen, die die gelöschte Instanz ersetzt.
Wenn Sie die IP-Weiterleitung deaktivieren möchten, klicken Sie auf Verwaltung, Laufwerke, Netzwerke, SSH-Schlüssel und dann auf Netzwerke.
Klicken Sie unter Netzwerkschnittstellen auf edit Bearbeiten.
Achten Sie darauf, dass im Drop-down-Menü unter IP-Weiterleitung die Option Aus ausgewählt ist.
Geben Sie alle anderen Instanzparameter an und klicken Sie dann auf Erstellen. Weitere Informationen finden Sie unter VM-Instanz erstellen und starten.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denKMS 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:
Rufen Sie in der Google Cloud Console die Seite Cloud KMS-Schlüssel auf.
Klicken Sie auf den Namen des Schlüsselbunds, der in dem Ergebnis angegeben ist.
Klicken Sie auf den Namen des im Ergebnis angegebenen Schlüssels.
Klicken Sie auf Rotationszeitraum bearbeiten.
Legen Sie den Rotationszeitraum auf maximal 90 Tage fest.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denKMS 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 Aktivierungen 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:
Rufen Sie in der Google Cloud Console die IAM-Seite auf.
Wählen Sie ggf. das Projekt im Ergebnis aus.
Führen Sie für jedes Mitglied mit der Rolle Inhaber die folgenden Schritte aus:
- Klicken Sie auf edit Bearbeiten.
- Klicken Sie im Bereich Bearbeitungsberechtigung neben der Rolle Inhaber auf delete Löschen.
- Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denKMS 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:
Rufen Sie in der Google Cloud Console die Seite Kryptografische Schlüssel auf.
Wählen Sie unter Name den Schlüsselbund aus, der den kryptografischen Schlüssel mit dem Security Health Analytics-Ergebnis enthält.
Klicken Sie auf der Seite Schlüsselbunddetails, die geladen wird, das Kästchen neben dem kryptografischen Schlüssel an.
Wenn das Infofeld nicht angezeigt wird, klicken Sie auf Infofeld ansehen.
Verwenden Sie das Filterfeld vor Rolle/Hauptkonto, um Hauptkonten nach allUsers und allAuthenticatedUsers zu suchen, und klicken Sie auf Löschen. delete, um den Zugriff für diese Hauptkonten zu entfernen.
So beheben Sie dieses Ergebnis, wenn es mit einem Schlüsselbund zusammenhängt:
Rufen Sie in der Google Cloud Console die Seite Kryptografische Schlüssel auf.
Suchen Sie die Zeile mit dem Schlüsselbund in dem Ergebnis und klicken Sie das Kästchen an.
Wenn das Infofeld nicht angezeigt wird, klicken Sie auf Infofeld ansehen.
Verwenden Sie das Filterfeld vor Rolle/Hauptkonto, um Hauptkonten nach allUsers und allAuthenticatedUsers zu suchen, und klicken Sie auf Löschen. delete, um den Zugriff für diese Hauptkonten zu entfernen.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denKMS role separation
Kategoriename in der API: KMS_ROLE_SEPARATION
Dieses Ergebnis 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:
Rufen Sie in der Google Cloud Console die IAM-Seite auf.
Gehen Sie für jedes Hauptkonto, das in dem Ergebnis aufgeführt ist, so vor:
- 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.
- Klicken Sie neben einem Hauptkonto auf Bearbeiten edit.
- Klicken Sie zum Entfernen von Berechtigungen neben Cloud KMS-Administrator auf Löschen delete. Wenn Sie alle Berechtigungen für das Hauptkonto entfernen möchten, klicken Sie neben allen anderen Berechtigungen auf Löschen.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denLegacy 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:
Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.
Wählen Sie den Cluster aus, der im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit 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.
Wählen Sie in der Drop-down-Liste Alte Autorisierung die Option Deaktiviert aus.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denLegacy 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.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denLegacy 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.
Bei Aktivierungen 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:
Rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke auf.
Klicken Sie auf Netzwerk erstellen, um ein neues Nicht-Legacy-Netzwerk zu erstellen.
Kehren Sie zur Seite VPC-Netzwerke zurück.
Klicken Sie in der Liste der Netzwerke auf legacy_network.
Klicken Sie auf der Seite VPC-Netzwerkdetails auf deleteVPC-Netzwerk löschen.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denLoad balancer logging disabled
Kategoriename in der API: LOAD_BALANCER_LOGGING_DISABLED
Logging ist für den Back-End-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.
Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:
Rufen Sie in der Google Cloud Console die Seite Cloud Load Balancing auf.
Klicken Sie auf den Namen des Load-Balancers.
Klicken Sie auf Bearbeiten edit.
Klicken Sie auf Backend-Konfiguration.
Klicken Sie auf der Seite Back-End-Konfiguration auf edit.
Wählen Sie im Bereich Logging die Option Logging aktivieren und dann die beste Abtastrate für Ihr Projekt aus.
Klicken Sie auf Aktualisieren, um die Bearbeitung des Backend-Dienstes abzuschließen.
Klicken Sie auf Aktualisieren, um das Bearbeiten des Load-Balancers abzuschließen.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denLocked 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 Aktivierungen 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:
Rufen Sie in der Google Cloud Console die Seite Storage-Browser auf.
Wählen Sie den Bucket aus, der in den Ergebnissen von Security Health Analytics aufgeführt ist.
Klicken Sie auf der Seite Bucket-Details auf den Tab Aufbewahrung.
Wenn keine Aufbewahrungsrichtlinie festgelegt ist, klicken Sie auf Aufbewahrungsrichtlinie festlegen.
Geben Sie eine Aufbewahrungsdauer ein.
Klicken Sie auf Speichern. Die Aufbewahrungsrichtlinie wird auf dem Tab Aufbewahrung angezeigt.
Klicken Sie auf Sperren, um sicherzustellen, dass die Aufbewahrungsdauer nicht verkürzt oder entfernt wird.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denLog 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 Aktivierungen 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:
Rufen Sie in der Google Cloud Console die Seite Log-Router auf.
Klicken Sie auf Senke erstellen.
Lassen Sie die „Einschließen“- und „Ausschließen“-Filter leer, damit alle Logs exportiert werden.
Klicken Sie auf Senke erstellen.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denMaster 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:
Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.
Wählen Sie den Cluster aus, der im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit 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.
Wählen Sie in der Drop-down-Liste Autorisierte Netzwerke der Steuerungsebene die Option Aktiviert aus.
Klicken Sie auf Autorisiertes Netzwerk hinzufügen.
Geben Sie die gewünschten autorisierten Netzwerke an.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denMFA not enforced
Kategoriename in der API: MFA_NOT_ENFORCED
Dieses Ergebnis 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:
Wechseln Sie in der Google Cloud Console zur Seite Admin-Konsole.
Erzwingen Sie die 2-Faktor-Authentifizierung für alle Organisationseinheiten.
Ergebnisse dieses Typs unterdrücken
Wenn Sie Ergebnisse dieses Typs unterdrücken möchten, definieren Sie eine Ausblendungsregel, die zukünftige Ergebnisse dieses Typs automatisch ausblendet. Weitere Informationen finden Sie unter Ergebnisse in Security Command Center ausblenden.
Obwohl diese Methode nicht empfohlen wird, können Sie Assets auch spezielle Sicherheitsmarkierungen hinzufügen, damit Detektoren von Security Health Analytics 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 Werttrue
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
.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denNetwork not monitored
Kategoriename in der API: NETWORK_NOT_MONITORED
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 Kostenoptimierung für die Google Cloud-Beobachtbarkeit.
Bei Aktivierungen 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
Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf.
Klicken Sie auf Messwert erstellen.
Wählen Sie unter Messwerttyp die Option Zähler aus.
Unter Details:
- Legen Sie unter Name des Logmesswerts einen Namen fest.
- Fügen Sie eine Beschreibung hinzu.
- Legen Sie Einheiten auf 1 fest.
Kopieren Sie unter Filterauswahl den folgenden Text und fügen Sie ihn in das Feld Filter erstellen ein. Ersetzen Sie bei Bedarf den vorhandenen Text:
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")
Klicken Sie auf Messwert erstellen. Sie sehen eine Bestätigung.
Benachrichtigungsrichtlinie erstellen
-
Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf:
Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.
- Wählen Sie im Bereich Benutzerdefinierte Messwerte den Messwert aus, den Sie im vorherigen Abschnitt erstellt haben.
-
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.
- Klicken Sie auf Weiter.
- Prüfen Sie die vorkonfigurierten Einstellungen. Sie können den Schwellenwert ändern.
- Klicken Sie auf Bedingungsname und geben Sie einen Namen für die Bedingung ein.
- Klicken Sie auf Weiter.
Klicken Sie auf Benachrichtigungskanäle, um der Benachrichtigungsrichtlinie Benachrichtigungen hinzuzufügen. Wählen Sie im Dialogfeld einen oder mehrere Benachrichtigungskanäle aus dem Menü aus und klicken Sie dann auf OK.
Um beim Öffnen und Schließen von Vorfällen benachrichtigt zu werden, aktivieren Sie die Option Bei Schließung des Vorfalls benachrichtigen. Standardmäßig werden Benachrichtigungen nur gesendet, wenn Vorfälle geöffnet werden.
- Optional: Aktualisieren Sie die Dauer bis zur automatischen Schließung von Vorfällen. Dieses Feld bestimmt, wann Monitoring Vorfälle ohne Messwertdaten schließt.
- Optional: Klicken Sie auf Dokumentation und geben Sie alle Informationen ein, die in einer Benachrichtigung angezeigt werden sollen.
- Klicken Sie auf Name der Benachrichtigung und geben Sie einen Namen für die Benachrichtigungsrichtlinie ein.
- Klicken Sie auf Richtlinie erstellen.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denNetwork 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:
Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.
Klicken Sie auf den Namen des Clusters, der im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie unter Netzwerk in der Zeile für Calico-Kubernetes-Netzwerkrichtlinie auf edit 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.
Wählen Sie im Dialogfeld Calico-Kubernetes-Netzwerkrichtlinie für Steuerungsebene aktivieren und Calico-Kubernetes-Netzwerkrichtlinie für Knoten aktivieren aus.
Klicken Sie auf Änderungen speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denNodepool 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.
Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:
Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.
Klicken Sie in der Liste der Cluster auf den Namen des Clusters in dem Ergebnis.
Klicken Sie auf den Tab Knoten.
Klicken Sie bei jedem Default-pool-Knotenpool auf Löschen delete.
Wenn Sie zur Bestätigung aufgefordert werden, klicken Sie auf Löschen.
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.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denNodepool 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.
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.
Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.
Klicken Sie auf den Namen des Clusters im Ergebnis.
Klicken Sie auf Knotenpool hinzufügen.
Führen Sie im Menü Knotenpools die folgenden Schritte aus:
- Klicken Sie auf den Namen des neuen Knotenpools, um den Tab zu maximieren.
- Wählen Sie Sicherheit und dann unter Shielded-Optionen die Option Secure Boot aktivieren aus.
- Klicken Sie auf Erstellen.
- Informationen zum Migrieren Ihrer Arbeitslasten von den vorhandenen nicht konformen Knotenpools zu den neuen Knotenpools finden Sie unter Arbeitslasten zu anderen Maschinentypen migrieren.
- Löschen Sie den ursprünglichen nicht konformen Knotenpool, nachdem die Arbeitslasten verschoben wurden.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denNon 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:
Rufen Sie in der Google Cloud Console die IAM-Seite auf.
Klicken Sie auf das Kästchen neben Nutzern außerhalb Ihrer Organisation oder Ihres Projekts.
Klicken Sie auf Entfernen.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denObject 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 Aktivierungen 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 den Befehl gsutil versioning set on
mit dem entsprechenden Wert:
gsutil versioning set on gs://finding.assetDisplayName
Ersetzen Sie finding.assetDisplayName
durch den Namen des entsprechenden Buckets.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denOpen 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:
Rufen Sie in der Google Cloud Console die Seite Firewall auf.
Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.
Klicken Sie auf edit Bearbeiten.
Löschen Sie unter Quell-IP-Bereiche den Wert
0.0.0.0/0
.Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.
Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denOpen 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:
Rufen Sie in der Google Cloud Console die Seite Firewall auf.
Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.
Klicken Sie auf edit Bearbeiten.
Löschen Sie unter Quell-IP-Bereiche den Wert
0.0.0.0/0
.Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.
Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denOpen 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:
Rufen Sie in der Google Cloud Console die Seite Firewall auf.
Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.
Klicken Sie auf edit Bearbeiten.
Löschen Sie unter Quell-IP-Bereiche den Wert
0.0.0.0/0
.Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.
Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denOpen 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:
Rufen Sie in der Google Cloud Console die Seite Firewall auf.
Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.
Klicken Sie auf edit Bearbeiten.
Löschen Sie unter Quell-IP-Bereiche den Wert
0.0.0.0/0
.Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.
Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denOpen 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:
Rufen Sie in der Google Cloud Console die Seite Firewall auf.
Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.
Klicken Sie auf edit Bearbeiten.
Löschen Sie unter Quell-IP-Bereiche den Wert
0.0.0.0/0
.Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.
Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denOpen 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:
Rufen Sie in der Google Cloud Console die Seite Firewallregeln auf.
Klicken Sie auf die Firewallregel, die im Security Health Analytics-Ergebnis aufgeführt ist, und klicken Sie dann auf edit Bearbeiten.
Bearbeiten Sie unter Quell-IP-Bereiche die IP-Werte, um den Bereich der zulässigen IP-Adressen einzuschränken.
Wählen Sie unter Protokolle und Ports die Option Angegebene Protokolle und Ports und dann die zulässigen Protokolle aus.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denOpen 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:
Rufen Sie in der Google Cloud Console die Seite Firewall auf.
Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.
Klicken Sie auf edit Bearbeiten.
Löschen Sie unter Quell-IP-Bereiche den Wert
0.0.0.0/0
.Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.
Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denOpen 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
Rufen Sie in der Google Cloud Console die IAM-Seite auf.
Wählen Sie bei Bedarf das Projekt, den Ordner oder die Organisation im Ergebnis aus.
Widerrufen Sie die Rolle für jede offene Gruppe, die im Ergebnis angegeben ist.
Zugriff auf offene Gruppen einschränken
- Melden Sie sich in Google Groups an.
- Aktualisieren Sie die Einstellungen jeder offenen Gruppe und ihrer Untergruppen, um anzugeben, wer der Gruppe beitreten kann und wer sie genehmigen muss.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denOpen 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:
Rufen Sie in der Google Cloud Console die Seite Firewall auf.
Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.
Klicken Sie auf edit Bearbeiten.
Löschen Sie unter Quell-IP-Bereiche den Wert
0.0.0.0/0
.Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.
Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denOpen 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:
Rufen Sie in der Google Cloud Console die Seite Firewall auf.
Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.
Klicken Sie auf edit Bearbeiten.
Löschen Sie unter Quell-IP-Bereiche den Wert
0.0.0.0/0
.Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.
Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denOpen 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:
Rufen Sie in der Google Cloud Console die Seite Firewall auf.
Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.
Klicken Sie auf edit Bearbeiten.
Löschen Sie unter Quell-IP-Bereiche den Wert
0.0.0.0/0
.Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.
Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denOpen 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:
Rufen Sie in der Google Cloud Console die Seite Firewall auf.
Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.
Klicken Sie auf edit Bearbeiten.
Löschen Sie unter Quell-IP-Bereiche den Wert
0.0.0.0/0
.Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.
Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denOpen 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:
Rufen Sie in der Google Cloud Console die Seite Firewall auf.
Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.
Klicken Sie auf edit Bearbeiten.
Löschen Sie unter Quell-IP-Bereiche den Wert
0.0.0.0/0
.Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.
Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denOpen 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:
Rufen Sie in der Google Cloud Console die Seite Firewall auf.
Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.
Klicken Sie auf edit Bearbeiten.
Löschen Sie unter Quell-IP-Bereiche den Wert
0.0.0.0/0
.Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.
Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denOpen 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:
Rufen Sie in der Google Cloud Console die Seite Firewall auf.
Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.
Klicken Sie auf edit Bearbeiten.
Löschen Sie unter Quell-IP-Bereiche den Wert
0.0.0.0/0
.Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.
Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denOpen 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:
Rufen Sie in der Google Cloud Console die Seite Firewall auf.
Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.
Klicken Sie auf edit Bearbeiten.
Löschen Sie unter Quell-IP-Bereiche den Wert
0.0.0.0/0
.Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.
Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denOpen 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:
Rufen Sie in der Google Cloud Console die Seite Firewall auf.
Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.
Klicken Sie auf edit Bearbeiten.
Löschen Sie unter Quell-IP-Bereiche den Wert
0.0.0.0/0
.Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.
Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denOpen 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:
Rufen Sie in der Google Cloud Console die Seite Firewall auf.
Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.
Klicken Sie auf edit Bearbeiten.
Löschen Sie unter Quell-IP-Bereiche den Wert
0.0.0.0/0
.Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.
Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denOpen 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:
Rufen Sie in der Google Cloud Console die Seite Firewall auf.
Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.
Klicken Sie auf edit Bearbeiten.
Löschen Sie unter Quell-IP-Bereiche den Wert
0.0.0.0/0
.Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.
Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denOpen 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:
Rufen Sie in der Google Cloud Console die Seite Firewall auf.
Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.
Klicken Sie auf edit Bearbeiten.
Löschen Sie unter Quell-IP-Bereiche den Wert
0.0.0.0/0
.Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.
Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denOpen 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:
Rufen Sie in der Google Cloud Console die Seite Firewall auf.
Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.
Klicken Sie auf edit Bearbeiten.
Löschen Sie unter Quell-IP-Bereiche den Wert
0.0.0.0/0
.Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.
Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denOpen 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:
Rufen Sie in der Google Cloud Console die Seite Firewall auf.
Klicken Sie in der Liste der Firewallregeln auf den Namen der Firewallregel in dem Ergebnis.
Klicken Sie auf edit Bearbeiten.
Löschen Sie unter Quell-IP-Bereiche den Wert
0.0.0.0/0
.Fügen Sie bestimmte IP-Adressen oder IP-Bereiche hinzu, die sich mit der Instanz verbinden sollen.
Fügen Sie bestimmte Protokolle und Ports hinzu, die für die Instanz geöffnet werden sollen.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denOrg 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.
Bei Aktivierungen 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:
Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.
Klicken Sie in der Liste der Instanzen auf den Namen der Instanz im Ergebnis.
Wenn der Confidential VM-Dienst für die VM nicht erforderlich ist, verschieben Sie ihn in einen neuen Ordner oder ein neues Projekt.
Wenn für die VM Confidential VM erforderlich ist, klicken Sie auf delete Löschen.
Informationen zum Erstellen einer neuen Instanz mit aktivierter Confidential VM finden Sie unter Kurzanleitung: Confidential VM-Instanz erstellen.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denOrg 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.
Bei Aktivierungen 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:
- 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.
- 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.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denOS 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 Aktivierungen 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:
Rufen Sie in der Google Cloud Console die Seite Metadaten auf.
Klicken Sie zuerst auf Bearbeiten und dann auf Element hinzufügen.
Fügen Sie ein Element mit dem Schlüssel enable-oslogin und dem Wert TRUE hinzu.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denOver 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.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denOver 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.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denOver 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:
Rufen Sie in der Google Cloud Console die IAM-Seite auf.
Wählen Sie bei Bedarf das Projekt, den Ordner oder die Organisation im Ergebnis aus.
Führen Sie für jedes Hauptkonto, das
roles/iam.serviceAccountUser
oderroles/iam.serviceAccountTokenCreator
zugewiesen wird, folgende Schritte aus:- Klicken Sie auf edit Bearbeiten.
- Klicken Sie im Bereich Berechtigungen bearbeiten neben den Rollen auf delete Löschen.
- Klicken Sie auf Speichern.
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.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denOwner 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 Kostenoptimierung für die Google Cloud-Beobachtbarkeit.
Bei Aktivierungen 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
Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf.
Klicken Sie auf Messwert erstellen.
Wählen Sie unter Messwerttyp die Option Zähler aus.
Unter Details:
- Legen Sie unter Name des Logmesswerts einen Namen fest.
- Fügen Sie eine Beschreibung hinzu.
- Legen Sie Einheiten auf 1 fest.
Kopieren Sie unter Filterauswahl den folgenden Text und fügen Sie ihn in das Feld Filter erstellen ein. Ersetzen Sie bei Bedarf den vorhandenen Text:
(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")
Klicken Sie auf Messwert erstellen. Sie sehen eine Bestätigung.
Benachrichtigungsrichtlinie erstellen
-
Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf:
Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.
- Wählen Sie im Bereich Benutzerdefinierte Messwerte den Messwert aus, den Sie im vorherigen Abschnitt erstellt haben.
-
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.
- Klicken Sie auf Weiter.
- Prüfen Sie die vorkonfigurierten Einstellungen. Sie können den Schwellenwert ändern.
- Klicken Sie auf Bedingungsname und geben Sie einen Namen für die Bedingung ein.
- Klicken Sie auf Weiter.
Klicken Sie auf Benachrichtigungskanäle, um der Benachrichtigungsrichtlinie Benachrichtigungen hinzuzufügen. Wählen Sie im Dialogfeld einen oder mehrere Benachrichtigungskanäle aus dem Menü aus und klicken Sie dann auf OK.
Um beim Öffnen und Schließen von Vorfällen benachrichtigt zu werden, aktivieren Sie die Option Bei Schließung des Vorfalls benachrichtigen. Standardmäßig werden Benachrichtigungen nur gesendet, wenn Vorfälle geöffnet werden.
- Optional: Aktualisieren Sie die Dauer bis zur automatischen Schließung von Vorfällen. Dieses Feld bestimmt, wann Monitoring Vorfälle ohne Messwertdaten schließt.
- Optional: Klicken Sie auf Dokumentation und geben Sie alle Informationen ein, die in einer Benachrichtigung angezeigt werden sollen.
- Klicken Sie auf Name der Benachrichtigung und geben Sie einen Namen für die Benachrichtigungsrichtlinie ein.
- Klicken Sie auf Richtlinie erstellen.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denPod 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 Aktivierungen 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.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denPrimitive 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:
Rufen Sie in der Google Cloud Console die Seite IAM-Richtlinien auf.
Verwenden Sie für jeden Nutzer, dem eine einfache Rolle zugewiesen wurde, detaillierte Rollen.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denPrivate 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:
Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.
Klicken Sie auf Cluster erstellen.
Wählen Sie im Navigationsmenü unter Cluster die Option Netzwerk aus.
Wählen Sie das Optionsfeld für Privater Cluster aus.
Klicken Sie unter Erweiterte Netzwerkoptionen das Kästchen für VPC-natives Traffic-Routing aktivieren (verwendet Alias-IP-Adresse) an.
Klicken Sie auf Erstellen.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denPrivate 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:
Rufen Sie in der Google Cloud Console die Seite VPC-Netzwerke auf.
Klicken Sie in der Liste der Netzwerke auf den Namen des Netzwerks.
Klicken Sie auf der Seite VPC-Netzwerkdetails auf den Tab Subnetze.
Klicken Sie in der Liste der Subnetze auf den Namen des Subnetzes, das dem Kubernetes-Cluster im Ergebnis zugeordnet ist.
Klicken Sie auf der Seite mit den Subnetz-Details auf Bearbeiten edit.
Wählen Sie für Privater Google-Zugriff die Option Ein aus.
Klicken Sie auf Speichern.
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.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denPublic 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:
Rufen Sie in der Google Cloud Console die Seite Storage-Browser auf.
Wählen Sie den Bucket aus, der in den Ergebnissen von Security Health Analytics aufgeführt ist.
Klicken Sie auf der Seite Bucket-Details auf den Tab Berechtigungen.
Klicken Sie neben Anzeigen nach auf Rollen.
Suchen Sie im Feld Filter nach allUsers und allAuthenticatedUsers.
Klicken Sie auf Löschen delete, um alle IAM-Berechtigungen zu entfernen, die allUsers und allAuthenticatedUsers gewährt wurden.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denPublic 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:
Rufen Sie in der Google Cloud Console die Seite Compute Engine-Images auf.
Klicken Sie auf das Kästchen neben dem Image public-image und dann auf Infofeld anzeigen.
Suchen Sie im Feld Filter nach Mitgliedern für allUsers und allAuthenticatedUsers.
Erweitern Sie die Rolle, aus der Sie Nutzer entfernen möchten.
Klicken Sie auf delete Löschen, um einen Nutzer aus dieser Rolle zu entfernen.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denPublic 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:
Rufen Sie in der Google Cloud Console die BigQuery-Seite Explorer auf.
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.
Klicken Sie oben im Bereich Dataset-Informationen auf Freigabe.
Klicken Sie im Drop-down-Menü auf Berechtigungen.
Geben Sie im Bereich Dataset-Berechtigungen allUsers und allAuthenticatedUsers ein und entfernen Sie den Zugriff für diese Hauptkonten.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denPublic 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:
Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.
Klicken Sie in der Liste der Instanzen auf das Kästchen neben dem Namen der Instanz für das Ergebnis.
Klicken Sie auf edit Bearbeiten.
Für jede Schnittstelle unter Netzwerkschnittstellen klicken Sie auf edit Bearbeiten und legen Sie die externe IP-Adresse auf Keine fest.
Klicken Sie auf Fertig und anschließend auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denPublic log bucket
Kategoriename in der API: PUBLIC_LOG_BUCKET
Dieses Ergebnis 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:
Rufen Sie in der Google Cloud Console die Seite des Cloud Storage-Browsers auf.
Klicken Sie in der Liste der Buckets auf den Namen des Buckets, der im Ergebnis angegeben ist.
Klicken Sie auf den Tab Berechtigungen.
Entfernen Sie allUsers und allAuthenticatedUsers aus der Liste der Hauptkonten.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denPublic 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:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit Bearbeiten.
Klicken Sie im Navigationsbereich auf Verbindungen.
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.Klicken Sie auf Fertig und anschließend auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denPubsub 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.
Um dieses Ergebnis zu beheben, löschen Sie das vorhandene Thema und erstellen Sie ein neues:
Rufen Sie in der Google Cloud Console die Seite "Pub/Sub-Themen" auf.
Wählen Sie gegebenenfalls das Projekt aus, das das Pub/Sub-Thema enthält.
Klicken Sie das Kästchen neben dem aufgeführten Thema an und klicken Sie dann auf delete Löschen.
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.
Veröffentlichen Sie Ergebnisse oder andere Daten im CMEK-fähigen Pub/Sub-Thema.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denRoute not monitored
Kategoriename in der API: ROUTE_NOT_MONITORED
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 Kostenoptimierung für die Google Cloud-Beobachtbarkeit.
Bei Aktivierungen 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
Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf.
Klicken Sie auf Messwert erstellen.
Wählen Sie unter Messwerttyp die Option Zähler aus.
Unter Details:
- Legen Sie unter Name des Logmesswerts einen Namen fest.
- Fügen Sie eine Beschreibung hinzu.
- Legen Sie Einheiten auf 1 fest.
Kopieren Sie unter Filterauswahl den folgenden Text und fügen Sie ihn in das Feld Filter erstellen ein. Ersetzen Sie bei Bedarf den vorhandenen Text:
resource.type="gce_route" AND (protoPayload.methodName:"compute.routes.delete" OR protoPayload.methodName:"compute.routes.insert")
Klicken Sie auf Messwert erstellen. Sie sehen eine Bestätigung.
Benachrichtigungsrichtlinie erstellen
-
Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf:
Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.
- Wählen Sie im Bereich Benutzerdefinierte Messwerte den Messwert aus, den Sie im vorherigen Abschnitt erstellt haben.
-
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.
- Klicken Sie auf Weiter.
- Prüfen Sie die vorkonfigurierten Einstellungen. Sie können den Schwellenwert ändern.
- Klicken Sie auf Bedingungsname und geben Sie einen Namen für die Bedingung ein.
- Klicken Sie auf Weiter.
Klicken Sie auf Benachrichtigungskanäle, um der Benachrichtigungsrichtlinie Benachrichtigungen hinzuzufügen. Wählen Sie im Dialogfeld einen oder mehrere Benachrichtigungskanäle aus dem Menü aus und klicken Sie dann auf OK.
Um beim Öffnen und Schließen von Vorfällen benachrichtigt zu werden, aktivieren Sie die Option Bei Schließung des Vorfalls benachrichtigen. Standardmäßig werden Benachrichtigungen nur gesendet, wenn Vorfälle geöffnet werden.
- Optional: Aktualisieren Sie die Dauer bis zur automatischen Schließung von Vorfällen. Dieses Feld bestimmt, wann Monitoring Vorfälle ohne Messwertdaten schließt.
- Optional: Klicken Sie auf Dokumentation und geben Sie alle Informationen ein, die in einer Benachrichtigung angezeigt werden sollen.
- Klicken Sie auf Name der Benachrichtigung und geben Sie einen Namen für die Benachrichtigungsrichtlinie ein.
- Klicken Sie auf Richtlinie erstellen.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denRedis role used on org
Kategoriename in der API: REDIS_ROLE_USED_ON_ORG
Dieses Ergebnis 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:
Rufen Sie in der Google Cloud Console die Seite IAM-Richtlinien auf.
Entfernen Sie die im Ergebnis angegebenen Redis-IAM-Rollen und fügen Sie sie stattdessen den einzelnen Projekten hinzu.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denRelease 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:
Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.
Klicken Sie im Abschnitt Clustergrundlagen in der Zeile Release-Version auf das Bearbeitungssymbol (edit).
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.
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.
Klicken Sie auf Änderungen speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denRSASHA1 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.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denService account key not rotated
Kategoriename in der API: SERVICE_ACCOUNT_KEY_NOT_ROTATED
Dieses Ergebnis 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.
Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:
Rufen Sie in der Google Cloud Console die Seite Dienstkonten auf.
Wählen Sie bei Bedarf das im Ergebnis angegebene Projekt aus.
Suchen Sie in der Liste der Dienstkonten nach dem Dienstkonto, das in den Ergebnissen aufgeführt ist, und klicken Sie auf delete Löschen. Erwägen Sie vor dem Fortfahren, wie sich das Löschen eines Dienstkontos auf Ihre Produktionsressourcen auswirken könnte.
Erstellen Sie einen neuen Dienstkontoschlüssel, um den gelöschten Schlüssel zu ersetzen. Weitere Informationen finden Sie unter Dienstkontoschlüssel erstellen.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denService account role separation
Kategoriename in der API: SERVICE_ACCOUNT_ROLE_SEPARATION
Dieses Ergebnis 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.
Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:
Rufen Sie in der Google Cloud Console die Seite IAM auf.
Gehen Sie für jedes Hauptkonto, das in dem Ergebnis aufgeführt ist, so vor:
- 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.
- Klicken Sie neben einem Hauptkonto auf Bearbeiten edit.
- Klicken Sie zum Entfernen von Berechtigungen neben Dienstkontoadministrator auf Löschen delete. Wenn Sie alle Dienstkontoberechtigungen entfernen möchten, klicken Sie neben allen anderen Berechtigungen auf Löschen.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denShielded 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:
Rufen Sie in der Google Cloud Console die Seite VM-Instanzen auf.
Wählen Sie die Instanz aus, die sich auf das Ergebnis von Security Health Analytics bezieht.
Klicken Sie auf der Seite Instanzdetails, die geladen wird, auf
Beenden.Wenn die Instanz nicht mehr ausgeführt wird, klicken Sie auf editBearbeiten.
Verwenden Sie im Bereich Shielded VM die Umschalter vTPM aktivieren und Integrity Monitoring aktivieren, um Shielded VM zu aktivieren.
Wenn Sie keine benutzerdefinierten oder nicht signierten Treiber verwenden, können Sie optional auch Secure Boot aktivieren.
Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzdetails angezeigt.
Klicken Sie nun auf
Starten, um die Instanz zu starten.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL 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.
Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf delete Löschen.
Um eine neue Instanz mit aktiviertem CMEK zu erstellen, folgen Sie der Anleitung zum Konfigurieren von CMEK für Ihr Produkt:
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL 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:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit Bearbeiten.
Legen Sie im Bereich Datenbank-Flags für das Datenbank-Flag contained database authentication den Wert Aus fest.
Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL 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:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit Bearbeiten.
Legen Sie im Bereich Datenbank-Flags für das Datenbank-Flag cross db ownership chaining den Wert Aus fest.
Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL 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:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit Bearbeiten.
Legen Sie im Bereich Datenbank-Flags das Datenbank-Flag external scripts enabled auf den Wert Aus fest.
Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL instance not monitored
Kategoriename in der API: SQL_INSTANCE_NOT_MONITORED
Dieses Ergebnis 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 Kostenoptimierung für die Google Cloud-Beobachtbarkeit.
Bei Aktivierungen 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
Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf.
Klicken Sie auf Messwert erstellen.
Wählen Sie unter Messwerttyp die Option Zähler aus.
Unter Details:
- Legen Sie unter Name des Logmesswerts einen Namen fest.
- Fügen Sie eine Beschreibung hinzu.
- Legen Sie Einheiten auf 1 fest.
Kopieren Sie unter Filterauswahl den folgenden Text und fügen Sie ihn in das Feld Filter erstellen ein. Ersetzen Sie bei Bedarf den vorhandenen Text:
protoPayload.methodName="cloudsql.instances.update" OR protoPayload.methodName="cloudsql.instances.create" OR protoPayload.methodName="cloudsql.instances.delete"
Klicken Sie auf Messwert erstellen. Sie sehen eine Bestätigung.
Benachrichtigungsrichtlinie erstellen
-
Rufen Sie in der Google Cloud Console die Seite Logbasierte Messwerte auf:
Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.
- Wählen Sie im Bereich Benutzerdefinierte Messwerte den Messwert aus, den Sie im vorherigen Abschnitt erstellt haben.
-
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.
- Klicken Sie auf Weiter.
- Prüfen Sie die vorkonfigurierten Einstellungen. Sie können den Schwellenwert ändern.
- Klicken Sie auf Bedingungsname und geben Sie einen Namen für die Bedingung ein.
- Klicken Sie auf Weiter.
Klicken Sie auf Benachrichtigungskanäle, um der Benachrichtigungsrichtlinie Benachrichtigungen hinzuzufügen. Wählen Sie im Dialogfeld einen oder mehrere Benachrichtigungskanäle aus dem Menü aus und klicken Sie dann auf OK.
Um beim Öffnen und Schließen von Vorfällen benachrichtigt zu werden, aktivieren Sie die Option Bei Schließung des Vorfalls benachrichtigen. Standardmäßig werden Benachrichtigungen nur gesendet, wenn Vorfälle geöffnet werden.
- Optional: Aktualisieren Sie die Dauer bis zur automatischen Schließung von Vorfällen. Dieses Feld bestimmt, wann Monitoring Vorfälle ohne Messwertdaten schließt.
- Optional: Klicken Sie auf Dokumentation und geben Sie alle Informationen ein, die in einer Benachrichtigung angezeigt werden sollen.
- Klicken Sie auf Name der Benachrichtigung und geben Sie einen Namen für die Benachrichtigungsrichtlinie ein.
- Klicken Sie auf Richtlinie erstellen.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL 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:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit Bearbeiten.
Legen Sie im Bereich Datenbank-Flags das Datenbank-Flag local_infile auf den Wert Aus fest.
Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL 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:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit Bearbeiten.
Legen Sie im Bereich Datenbank-Flags für das Datenbank-Flag log_checkpoints den Wert Ein fest.
Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL 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:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit Bearbeiten.
Legen Sie im Bereich Datenbank-Flags für das Datenbank-Flag log_connections den Wert Ein fest.
Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL 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:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit Bearbeiten.
Legen Sie im Bereich Datenbank-Flags für das Datenbank-Flag log_disconnections den Wert Ein fest.
Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL 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:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit Bearbeiten.
Legen Sie im Bereich Datenbank-Flags das Datenbank-Flag log_duration auf Ein fest.
Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL log error verbosity
Kategoriename in der API: SQL_LOG_ERROR_VERBOSITY
Bei einer Cloud SQL for PostgreSQL-Datenbankinstanz ist das Datenbank-Flag log_error_verbosity nicht auf default oder verbose 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 Standard oder ausführlich festzulegen.
Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.
Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit Bearbeiten.
Legen Sie im Bereich Datenbank-Flags das Datenbank-Flag log_error_verbosity auf Standard oder ausführlich fest.
Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL 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:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit Bearbeiten.
Legen Sie im Bereich Datenbank-Flags für das Datenbank-Flag log_lock_waits den Wert Ein fest.
Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL 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 log_min_duration_statement 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:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit Bearbeiten.
Legen Sie im Bereich Datenbank-Flags für das Datenbank-Flag log_min_duration_statement den Wert -1 fest.
Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL 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:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit Bearbeiten.
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
Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL 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:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit Bearbeiten.
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
Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL log min messages
Kategoriename in der API: SQL_LOG_MIN_MESSAGES
Bei einer Cloud SQL for PostgreSQL-Datenbankinstanz ist das Datenbank-Flag log_min_messages mindestens auf warning festgelegt.
Das Flag log_min_messages steuert, welche Meldungsebenen in Serverlogs aufgezeichnet werden. Je höher der Schweregrad, desto weniger Meldungen werden aufgezeichnet. Wenn Sie den Schwellenwert zu niedrig ansetzen, kann sich die Größe und Länge 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:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit Bearbeiten.
Legen Sie im Bereich Datenbank-Flags für log_min_messages gemäß der Logging-Richtlinie Ihrer Organisation einen der folgenden empfohlenen Werte fest.
debug5
debug4
debug3
debug2
debug1
info
notice
warning
Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL log executor stats enabled
Kategoriename in der API: SQL_LOG_EXECUTOR_STATS_ENABLED
Bei einer Cloud SQL for PostgreSQL-Datenbankinstanz ist das Datenbank-Flag log_executor_stats nicht auf Aus festgelegt.
Wenn das Flag log_executor_stats aktiviert ist, werden für jede Abfrage Executor-Leistungsstatistiken in die PostgreSQL-Logs 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:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit Bearbeiten.
Legen Sie im Bereich Datenbank-Flags das Datenbank-Flag log_executor_stats auf Aus fest.
Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL 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:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit Bearbeiten.
Legen Sie im Bereich Datenbank-Flags das Datenbank-Flag log_hostname auf Aus fest.
Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL 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:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit Bearbeiten.
Legen Sie im Bereich Datenbank-Flags das Datenbank-Flag log_parser_stats auf Aus fest.
Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL 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:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit Bearbeiten.
Legen Sie im Bereich Datenbank-Flags das Datenbank-Flag log_planner_stats auf Aus fest.
Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL log statement
Kategoriename in der API: SQL_LOG_STATEMENT
Bei einer Cloud SQL for PostgreSQL-Datenbankinstanz ist das Datenbank-Flag log_statement nicht auf ddl
festgelegt.
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:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit Bearbeiten.
Legen Sie im Bereich Datenbank-Flags das Datenbank-Flag log_statement auf
ddl
fest.Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL 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:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit Bearbeiten.
Legen Sie im Bereich Datenbank-Flags das Datenbank-Flag log_statement_stats auf Aus fest.
Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL 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:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit Bearbeiten.
Legen Sie im Abschnitt Datenbank-Flags für das Datenbank-Flag log_temp_files den Wert 0 fest.
Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL 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:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Wählen Sie auf der Seite Instanzdetails den Tab Nutzer aus.
Klicken Sie neben dem
root
-Nutzer auf Mehr und wählen Sie Passwort ändern aus.Geben Sie ein neues, starkes Passwort ein und klicken Sie auf OK.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL 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:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie im Menü auf der linken Seite auf Connections (Verbindungen).
Klicken Sie auf den Tab Netzwerk und entfernen Sie das Häkchen aus dem Kästchen Öffentliche IP-Adresse.
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.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL 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:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit Bearbeiten.
Setzen Sie im Bereich Flags die Option Remotezugriff auf Aus.
Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL 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:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit Bearbeiten.
Setzen Sie im Bereich Flags die Option skip_show_database auf Ein.
Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL 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.
Weitere Informationen finden Sie unter Datenbank-Flags konfigurieren.
Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit Bearbeiten.
Legen Sie im Bereich Datenbank-Flags die Option 3625 auf Ein fest.
Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL 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:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit Bearbeiten.
Klicken Sie im Bereich Datenbank-Flags neben Nutzerverbindungen auf delete Löschen.
Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL 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:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit Bearbeiten.
Klicken Sie im Bereich Datenbank-Flags neben Nutzeroptionen auf delete Löschen.
Klicken Sie auf Speichern. Die neue Konfiguration wird auf der Seite Instanzübersicht angezeigt.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSQL 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:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
Wählen Sie auf der Seite Instanzdetails den Tab Nutzer aus.
Klicken Sie neben dem
root
-Nutzer auf Mehr und wählen Sie Passwort ändern aus.Geben Sie ein neues, starkes Passwort ein und klicken Sie auf OK.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denSSL 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:
Rufen Sie in der Google Cloud Console die Seite Cloud SQL-Instanzen auf.
Wählen Sie die Instanz aus, die im Security Health Analytics-Ergebnis aufgeführt ist.
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.
Wenn Sie Vertrauenswürdige Clientzertifikate erforderlich auswählen, erstellen Sie ein neues Clientzertifikat. Weitere Informationen finden Sie unter Neues Clientzertifikat erstellen.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denToo 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 Aktivierungen 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:
Rufen Sie in der Google Cloud Console die Seite Cloud KMS-Schlüssel auf.
Klicken Sie auf den Namen des Schlüsselbunds, der in dem Ergebnis angegeben ist.
Klicken Sie auf den Namen des im Ergebnis angegebenen Schlüssels.
Klicken Sie auf das Kästchen neben der primären Version und dann auf Show Info Panel (Infofeld ansehen).
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 delete.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denUser 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 unter Best Practices für die Verwaltung von Dienstkontoschlüsseln beschriebene Vorgänge verantwortlich. 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.
Führen Sie folgende Schritte aus, um dieses Ergebnis zu korrigieren:
Rufen Sie in der Google Cloud Console die Seite Dienstkonten auf.
Wählen Sie bei Bedarf das im Ergebnis angegebene Projekt aus.
Löschen Sie vom Nutzer verwaltete Dienstkontoschlüssel, die im Ergebnis angegeben sind, wenn sie von keiner Anwendung verwendet werden.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denWeak 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 TLS-Version niedriger als 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 Cipher Suites finden Sie auf der iana.org-Seite zu TLS-Parametern.
Bei Aktivierungen 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 Ergebnisses hängen davon ab, ob dieses Ergebnis durch die Verwendung einer standardmäßigen Google Cloud-SSL-Richtlinie oder einer SSL-Richtlinie ausgelöst wurde, die eine schwache Cipher Suite oder eine TLS-Mindestversion unter 1.2 zulässt. Folgen Sie der Anleitung unten, die dem Auslöser des Ergebnisses entspricht.
Standardkorrektur für Google Cloud-SSL-Richtlinien
Rufen Sie in der Google Cloud Console die Seite Zielproxys auf.
Suchen Sie den Zielproxy, der in den Ergebnissen und den Weiterleitungsregeln in der Spalte Verwendet von angegeben ist.
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.
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
Wenden Sie die SSL-Richtlinie auf alle zuvor notierten Weiterleitungsregeln an.
Behebung durch eine schwache Cipher Suite oder eine niedrigere TLS-Version möglich
Rufen Sie in der Google Cloud Console die Seite SSL-Richtlinien auf .
Suchen Sie den Load-Balancer, der in der Spalte Verwendet von angegeben ist.
Klicken Sie auf den Namen der Richtlinie.
Klicken Sie auf edit Bearbeiten.
Ändern Sie die Mindestversion für TLS in TLS 1.2 und die Option Profil in „Modern“ oder „Eingeschränkt“.
Wenn Sie ein benutzerdefiniertes Profil verwenden möchten, müssen die folgenden Cipher Suites 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
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denWeb 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:
Rufen Sie in der Google Cloud Console die GKE-Seite Kubernetes Cluster auf.
Klicken Sie auf den Namen des Clusters, der im Security Health Analytics-Ergebnis aufgeführt ist.
Klicken Sie auf edit 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.
Klicken Sie auf Add-ons. Der Abschnitt wird erweitert, damit Sie alle verfügbaren Add-ons sehen.
Wählen Sie in der Drop-down-Liste Kubernetes-Dashboard die Option Deaktiviert aus.
Klicken Sie auf Speichern.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denWorkload 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.
unterstützten Assets und Scaneinstellungen für diesen Ergebnistyp.
Weitere Informationen zu denAWS-Fehlkonfigurationen beheben
AWS Cloud Shell Full Access Restricted
Kategoriename in der API: ACCESS_AWSCLOUDSHELLFULLACCESS_RESTRICTED
AWS CloudShell ist eine bequeme Möglichkeit, CLI-Befehle für AWS-Dienste auszuführen. Eine verwaltete IAM-Richtlinie („AWSCloudShellFullAccess“) bietet vollständigen Zugriff auf Cloud Shell, die das Hochladen und Herunterladen von Dateien zwischen dem lokalen System eines Nutzers und der Cloud Shell-Umgebung ermöglicht. In der Cloud Shell-Umgebung verfügt ein Nutzer über sudo-Berechtigungen und kann auf das Internet zugreifen. Es ist also möglich, Software zur Dateiübertragung zu installieren und Daten von Cloud Shell 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 beheben:AWS-Konsole
- Öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
- Wählen Sie im linken Bereich „Richtlinien“ aus.
- Suchen Sie nach AWSCloudShellFullAccess und wählen Sie es aus.
- Klicken Sie auf dem Tab „Zugewiesene Entitäten“ für jedes Element das Kästchen an und wählen Sie „Trennen“ aus.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denAccess 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, mit denen programmatische Anfragen an AWS signiert werden. AWS-Nutzer benötigen eigene Zugriffsschlüssel, um programmatische Aufrufe an AWS über die AWS-Befehlszeile (AWS CLI), Tools for Windows PowerShell, die AWS SDKs oder direkte HTTP-Aufrufe mithilfe der APIs für einzelne AWS-Dienste auszuführen. Es wird empfohlen, alle Zugriffsschlüssel regelmäßig zu rotieren.
Empfehlung: Zugriffsschlüssel sollten höchstens alle 90 Tage rotiert werden Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben:AWS-Konsole
- Zur Verwaltungskonsole (https://console.aws.amazon.com/iam)
- Klicken Sie auf
Users
. - Klicken Sie auf
Security Credentials
. - Als Administrator
– Klicken Sie für Schlüssel, die seit90
Tagen nicht rotiert wurden, aufMake Inactive
- Als IAM-Nutzer
– Klicken Sie aufMake Inactive
oderDelete
für Schlüssel, die seit90
Tagen nicht rotiert oder verwendet wurden - Klicken Sie auf
Create Access Key
. - Programmatischen Aufruf mit neuen Anmeldedaten für Zugriffsschlüssel aktualisieren
AWS-CLI
- Erstellen Sie einen zweiten Schlüssel, solange der erste Zugriffsschlüssel noch aktiv ist. Er ist standardmäßig aktiv. Führen Sie dazu diesen Befehl aus:
aws iam create-access-key
Der Nutzer hat jetzt zwei aktive Zugriffsschlüssel.
- Aktualisieren Sie alle Anwendungen und Tools so, dass sie den neuen Zugriffsschlüssel verwenden.
- Mit dem folgenden Befehl können Sie feststellen, ob der erste Zugriffsschlüssel noch verwendet wird:
aws iam get-access-key-last-used
- Ein Ansatz besteht darin, einige Tage zu warten und dann den alten Zugriffsschlüssel auf seine Verwendung zu prüfen, bevor Sie fortfahren.
Auch wenn in Schritt 3 angezeigt wird, dass der alte Schlüssel nicht verwendet wird, sollten Sie den ersten Zugriffsschlüssel nicht sofort löschen. Ändern Sie stattdessen mit dem folgenden Befehl den Status des ersten Zugriffsschlüssels in „Inaktiv“:
aws iam update-access-key
-
Verwenden Sie nur den neuen Zugriffsschlüssel, um zu bestätigen, dass Ihre Anwendungen funktionieren. Alle Anwendungen und Tools, die noch den ursprünglichen Zugriffsschlüssel verwenden, funktionieren dann nicht mehr, da sie keinen Zugriff mehr auf AWS-Ressourcen haben. Wenn Sie solche Anwendungen oder Tools finden, können Sie ihren Status wieder in „Aktiv“ ändern, um den ersten Zugriffsschlüssel wieder zu aktivieren. Kehren Sie dann zu Schritt 2 zurück und aktualisieren Sie diese Anwendung, damit der neue Schlüssel verwendet wird.
-
Nachdem Sie einige Zeit gewartet haben, um sicherzustellen, dass alle Anwendungen und Tools aktualisiert wurden, können Sie den ersten Zugriffsschlüssel mit dem folgenden Befehl löschen:
aws iam delete-access-key
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denAll Expired Ssl Tls Certificates Stored Aws Iam Removed
Kategoriename in der API: ALL_EXPIRED_SSL_TLS_CERTIFICATES_STORED_AWS_IAM_REMOVED
Um HTTPS-Verbindungen zu Ihrer Website oder Anwendung in AWS zu ermöglichen, benötigen Sie ein SSL/TLS-Serverzertifikat. Sie können ACM oder IAM verwenden, um Serverzertifikate zu speichern und bereitzustellen.
Verwenden Sie IAM nur dann als Zertifikatmanager, 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-Zertifikatspeicher. IAM unterstützt die Bereitstellung von Serverzertifikaten in allen Regionen. Sie müssen Ihr Zertifikat zur Verwendung mit AWS jedoch von einem externen Anbieter erhalten. Sie können kein ACM-Zertifikat zu IAM hochladen. Außerdem können Sie Ihre Zertifikate nicht über die IAM-Konsole verwalten.
AWS-Konsole
Das Entfernen abgelaufener Zertifikate über die AWS Management Console wird derzeit nicht unterstützt. Verwenden Sie die Befehlszeile, um in IAM gespeicherte SSL/TLS-Zertifikate über die AWS API zu löschen.
AWS-CLI
Führen Sie den folgenden Befehl aus, um ein abgelaufenes Zertifikat zu löschen. 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.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denAutoscaling Group Elb Healthcheck Required
Kategoriename in der API: AUTOSCALING_GROUP_ELB_HEALTHCHECK_REQUIRED
Dadurch wird geprüft, ob Ihre Autoscaling-Gruppen, die mit einem Load-Balancer verknüpft sind, Systemdiagnosen des Elastic Load Balancing verwenden.
Dadurch wird sichergestellt, dass die Gruppe den Zustand einer Instanz anhand zusätzlicher Tests ermitteln kann, die vom Load-Balancer bereitgestellt werden. Die Verwendung von Systemdiagnosen für Elastic Load Balancing kann 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 beheben:AWS-Konsole
So aktivieren Sie Systemdiagnosen für Elastic Load Balancing
- Öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/.
- Wählen Sie im Navigationsbereich unter Autoscaling die Option Autoscaling-Gruppen aus.
- Aktivieren Sie das Kontrollkästchen für Ihre Gruppe.
- Wählen Sie „Bearbeiten“ aus.
- Wählen Sie unter „Systemdiagnosen“ als Typ „Systemdiagnose“ die Option „ELB“ aus.
- Geben Sie als Kulanzzeitraum für die Systemdiagnose 300 ein.
- Wählen Sie unten auf der Seite „Aktualisieren“ aus.
Weitere Informationen zur Verwendung eines Load-Balancers mit einer Autoscaling-Gruppe finden Sie im AWS-Nutzerhandbuch zur automatischen Skalierung.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denAuto 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“ (Automatisches Nebenversionsupgrade) aktiviert ist, damit während des angegebenen Wartungsfensters automatisch Nebenversionen von Engine-Upgrades erhalten werden. So können RDS-Instanzen die neuen Funktionen, Fehlerkorrekturen und Sicherheitspatches für ihre Datenbankmodule erhalten.
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 beheben:AWS-Konsole
- Melden Sie sich in der AWS-Verwaltungskonsole an und gehen Sie zum RDS-Dashboard unter https://console.aws.amazon.com/rds/.
- Klicken Sie im linken Navigationsbereich auf
Databases
. - Wählen Sie die RDS-Instanz aus, die Sie aktualisieren möchten.
- Klicke oben rechts auf die Schaltfläche
Modify
. - Wählen Sie auf der Seite
Modify DB Instance: <instance identifier>
im AbschnittMaintenance
die OptionAuto minor version upgrade
aus und klicken Sie auf das OptionsfeldYes
. - Klicken Sie unten auf der Seite auf
Continue
. Setzen Sie ein Häkchen bei „Sofort übernehmen“, um die Änderungen sofort anzuwenden, oder wählen SieApply during the next scheduled maintenance window
aus, um Ausfallzeiten zu vermeiden. - Prüfen Sie die Änderungen und klicken Sie auf
Modify DB Instance
. Der Instanzstatus sollte sich von „Verfügbar“ in „Bearbeiten“ und dann wieder in „Verfügbar“ ändern. Sobald die Funktion aktiviert ist, sollte sich der Status vonAuto Minor Version Upgrade
inYes
ändern.
AWS-CLI
- Führen Sie den Befehl
describe-db-instances
aus, um alle Namen der RDS-Datenbankinstanzen aufzulisten, die in der ausgewählten AWS-Region verfügbar sind:
aws rds describe-db-instances --region <regionName> --query 'DBInstances[*].DBInstanceIdentifier'
- Die Befehlsausgabe sollte jede Datenbankinstanzkennung zurückgeben.
- Führen Sie den Befehl
modify-db-instance
aus, um die ausgewählte RDS-Instanzkonfiguration zu ändern. Mit diesem Befehl werden die Änderungen sofort angewendet. Entfernen Sie--apply-immediately
, um die Änderungen im nächsten geplanten Wartungsfenster zu übernehmen und Ausfallzeiten zu vermeiden:
aws rds modify-db-instance --region <regionName> --db-instance-identifier <dbInstanceIdentifier> --auto-minor-version-upgrade --apply-immediately
- Die Befehlsausgabe sollte die neuen Konfigurationsmetadaten für die RDS-Instanz enthalten und den Parameterwert
AutoMinorVersionUpgrade
prüfen. - Führen Sie den Befehl
describe-db-instances
aus, um zu prüfen, ob die Funktion zum automatischen Upgrade von Nebenversionen erfolgreich aktiviert wurde:
aws rds describe-db-instances --region <regionName> --db-instance-identifier <dbInstanceIdentifier> --query 'DBInstances[*].AutoMinorVersionUpgrade'
- In der Befehlsausgabe sollte der aktuelle Status der Funktion auf
true
zurückgegeben werden, die Funktion istenabled
und die Upgrades der Nebenmodule werden auf die ausgewählte RDS-Instanz angewendet.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denAws 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 ausführt und Ihnen Protokolldateien bereitstellt. Die aufgezeichneten Informationen umfassen das Konfigurationselement (AWS-Ressource), die Beziehungen zwischen Konfigurationselementen (AWS-Ressourcen) und alle Konfigurationsänderungen zwischen Ressourcen. Es wird empfohlen, 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 beheben:AWS-Konsole
- Wählen Sie rechts oben in der Konsole die Region aus, auf die der Fokus liegen soll.
- Klicke auf „Dienste“.
- Klickkonfiguration
- Wenn ein Config-Recorder in dieser Region aktiviert ist, sollten Sie links über das Navigationsmenü die Seite „Settings“ (Einstellungen) aufrufen. Wenn in dieser Region noch kein Config-Recorder aktiviert ist, sollten Sie „Jetzt starten“ auswählen.
- Wählen Sie „Alle in dieser Region unterstützten Ressourcen aufzeichnen“ aus.
- Globale Ressourcen (IAM-Ressourcen) einbeziehen
- Geben Sie einen S3-Bucket im selben Konto oder in einem anderen verwalteten AWS-Konto an
- SNS-Thema aus demselben AWS-Konto oder einem anderen verwalteten AWS-Konto erstellen
AWS-CLI
- Achten Sie darauf, dass ein entsprechender S3-Bucket, ein SNS-Thema und eine IAM-Rolle gemäß den Voraussetzungen für den AWS Config Service vorhanden sind.
- Führen Sie den folgenden 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
- Erstellen Sie lokal eine Konfigurationsdatei für den Bereitstellungskanal, in der die Kanalattribute angegeben sind, die aus den zuvor eingerichteten Voraussetzungen ausgefüllt wurden:
{
"name": "default",
"s3BucketName": "my-config-bucket",
"snsTopicARN": "arn:aws:sns:us-east-1:012345678912:my-config-notice",
"configSnapshotDeliveryProperties": {
"deliveryFrequency": "Twelve_Hours"
}
}
- Führen Sie den folgenden Befehl aus, um einen neuen Bereitstellungskanal zu erstellen. Verweisen Sie dabei auf die JSON-Konfigurationsdatei, die Sie im vorherigen Schritt erstellt haben:
aws configservice put-delivery-channel --delivery-channel file://deliveryChannel.json
- Starten Sie den Konfigurationsrekorder mit dem folgenden Befehl:
aws configservice start-configuration-recorder --configuration-recorder-name default
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denAws Security Hub Enabled
Kategoriename in der API: AWS_SECURITY_HUB_ENABLED
Der Sicherheits-Hub erfasst Sicherheitsdaten aus AWS-Konten, -Diensten und unterstützten Produkten von Drittanbietern. So können Sie Ihre Sicherheitstrends analysieren und Sicherheitsprobleme mit der höchsten Priorität ermitteln. Wenn Sie Security Hub aktivieren, beginnt er damit, Ergebnisse aus von Ihnen aktivierten AWS-Diensten wie Amazon GuardDuty, Amazon Inspector und Amazon Macie zu verarbeiten, zu aggregieren, zu organisieren und zu priorisieren. 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 beheben:AWS-Konsole
- Melden Sie sich mit den Anmeldedaten der IAM-Identität in der Sicherheits-Hub-Konsole an.
- Wenn Sie die Security Hub-Konsole zum ersten Mal öffnen, wählen Sie „AWS Security Hub aktivieren“ aus.
- Auf der Startseite sind in den Sicherheitsstandards die Sicherheitsstandards aufgeführt, die vom Sicherheits-Hub unterstützt werden.
- Wählen Sie „Sicherheits-Hub aktivieren“ aus.
AWS-CLI
- Führen Sie den Befehl „enable-security-hub“ aus. Fügen Sie
--enable-default-standards
hinzu, um die Standardstandards zu aktivieren.
aws securityhub enable-security-hub --enable-default-standards
- Fügen Sie
--no-enable-default-standards
ein, um den Sicherheits-Hub ohne die Standardstandards zu aktivieren.
aws securityhub enable-security-hub --no-enable-default-standards
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denCloudtrail 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 Logs Nutzern und Ressourcen gemäß IAM-Richtlinien zur Verfügung stellt. AWS Key Management Service (KMS) ist ein verwalteter Dienst, mit dem Sie die Verschlüsselungsschlüssel erstellen und steuern können, die zum Verschlüsseln von Kontodaten verwendet werden. Außerdem werden Hardwaresicherheitsmodule (HSMs) verwendet, um die Sicherheit von Verschlüsselungsschlüsseln zu schützen. CloudTrail-Logs können so konfiguriert werden, dass sie die serverseitige Verschlüsselung (SSE) und vom Kunden erstellte KMS-Masterschlüssel (Customer-Managed Master Keys, CMK) nutzen, um CloudTrail-Logs weiter zu schützen. Es wird empfohlen, CloudTrail für die Verwendung von SSE-KMS zu konfigurieren.
Empfehlung: Achten Sie darauf, dass CloudTrail-Logs im Ruhezustand mit KMS-CMKs verschlüsselt werden Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben:AWS-Konsole
- Melden Sie sich in der AWS-Verwaltungskonsole an und öffnen Sie die CloudTrail-Konsole unter https://console.aws.amazon.com/cloudtrail.
- Wählen Sie im linken Navigationsbereich
Trails
aus . - Auf einen Weg klicken
- Klicken Sie im Abschnitt
S3
auf die Schaltfläche „Bearbeiten“ (Bleistiftsymbol). - Klicken Sie auf
Advanced
. - Wählen Sie einen vorhandenen CMK aus dem Drop-down-Menü
KMS key Id
aus.
– Hinweis: Der CMK muss sich in derselben Region wie der S3-Bucket befinden
– Hinweis: Sie müssen eine KMS-Schlüsselrichtlinie auf den ausgewählten CMK anwenden, damit CloudTrail als Dienst mit dem bereitgestellten CMK ver- und entschlüsseln kann. Hier finden Sie eine Anleitung zum Bearbeiten der ausgewählten CMK-Schlüsselrichtlinie. - Klicken Sie auf
Save
. - In einer Benachrichtigung werden Sie darüber informiert, dass Sie Entschlüsselungsberechtigungen für den angegebenen KMS-Schlüssel benötigen, um Protokolldateien zu entschlüsseln.
- 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>
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denCloudtrail Log File Validation Enabled
Kategoriename in der API: CLOUDTRAIL_LOG_FILE_VALIDATION_ENABLED
Bei der Validierung der CloudTrail-Logdatei wird eine digital signierte Digestdatei erstellt, die einen Hash jedes Logs enthält, das CloudTrail in S3 schreibt. Diese Digest-Dateien können verwendet werden, um festzustellen, ob eine Logdatei nach der Bereitstellung des Logs durch CloudTrail geändert, gelöscht oder unverändert wurde. 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 beheben:AWS-Konsole
- Melden Sie sich in der AWS-Verwaltungskonsole an und öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/cloudtrail.
- Klicken Sie im linken Navigationsbereich auf
Trails
. - Klick auf Zielweg
- Klicke im Abschnitt
General details
aufedit
. - Im Abschnitt
Advanced settings
- Klicken Sie das Kästchen für das Aktivieren unter
Log file validation
an. - Klicken Sie auf
Save changes
.
AWS-CLI
aws cloudtrail update-trail --name <trail_name> --enable-log-file-validation
Beachten Sie, dass eine regelmäßige Validierung von Logs mit diesen Digests mit dem folgenden Befehl durchgeführt werden kann:
aws cloudtrail validate-logs --trail-arn <trail_arn> --start-time <start_time> --end-time <end_time>
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denCloudtrail Trails Integrated Cloudwatch Logs
Kategoriename in der API: CLOUDTRAIL_TRAILS_INTEGRATED_CLOUDWATCH_LOGS
AWS CloudTrail ist ein Webdienst, der AWS API-Aufrufe in einem bestimmten AWS-Konto aufzeichnet. Die aufgezeichneten Informationen umfassen die Identität des API-Aufrufers, den Zeitpunkt des API-Aufrufs, die Quell-IP-Adresse des API-Aufrufers, die Anfrageparameter und die vom AWS-Dienst zurückgegebenen Antwortelemente. CloudTrail verwendet Amazon S3 für die Speicherung und Übermittlung von Logdateien, sodass Protokolldateien dauerhaft gespeichert werden. Neben der Erfassung von CloudTrail-Logs in einem bestimmten S3-Bucket zur Langzeitanalyse kann eine Echtzeitanalyse durchgeführt werden. Dazu muss CloudTrail so konfiguriert werden, dass Logs an CloudWatch-Logs gesendet werden. Für einen Weg, der in allen Regionen in einem Konto aktiviert ist, sendet CloudTrail Logdateien aus allen diesen Regionen an eine CloudWatch-Log-Loggruppe. Es wird empfohlen, CloudTrail-Logs an CloudWatch-Logs zu senden.
Hinweis: Mit dieser Empfehlung soll sichergestellt werden, dass AWS-Kontoaktivitäten erfasst, überwacht und entsprechend gemeldet werden. CloudWatch Logs bietet hierfür eine native Möglichkeit mithilfe von AWS-Diensten, schließt die Verwendung einer alternativen Lösung jedoch nicht aus.
Empfehlung: Achten Sie darauf, dass CloudTrail-Pfade in CloudWatch-Logs eingebunden sind Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben:AWS-Konsole
- Melde dich unter
https://console.aws.amazon.com/cloudtrail/
in der CloudTrail-Konsole an - Wählen Sie die
Trail
aus, die aktualisiert werden soll. - Scrollen Sie nach unten zu „
CloudWatch Logs
“. - Klicken Sie auf
Edit
. - Klicke unter
CloudWatch Logs
auf das FeldEnabled
. - Wählen Sie unter
Log Group
eine neue Loggruppe oder eine vorhandene Loggruppe aus - Bearbeiten Sie die
Log group name
entsprechend dem CloudTrail oder wählen Sie die vorhandene CloudWatch-Gruppe aus. - Wählen Sie unter
IAM Role
eine neue oder eine vorhandene aus. - Passen Sie die
Role name
an den CloudTrail an oder wählen Sie die vorhandene IAM-Rolle aus. - 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>
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denCloudwatch Alarm Action Check
Kategoriename in der API: CLOUDWATCH_ALARM_ACTION_CHECK
Hiermit wird geprüft, ob in Amazon Cloudwatch Aktionen definiert wurden, wenn ein Alarm zwischen den Status „OK“, „ALARM“ und „INSUFFICIENT_DATA“ wechselt.
Die Konfiguration von Aktionen für den ALARM-Status in Amazon CloudWatch-Alarmen ist sehr wichtig, um eine sofortige Reaktion auszulösen, wenn Schwellenwerte für überwachte Metriken überschritten werden.
Sie sorgt für eine schnelle Problemlösung, reduziert Ausfallzeiten und ermöglicht automatisierte Korrekturmaßnahmen, die Aufrechterhaltung des Systemzustands und die Vermeidung von Ausfällen.
Wecker haben mindestens eine Aktion.
Alarme haben mindestens eine Aktion, wenn der Alarm von einem anderen Status in den Status "INSUFFICIENT_DATA" wechselt.
(Optional) Ein Wecker hat mindestens eine Aktion, wenn er aus einem anderen Status in „OK“ wechselt.
AWS-Konsole
So konfigurieren Sie ALARM-Aktionen für Ihre Amazon CloudWatch-Alarme:
- Öffnen Sie die Amazon CloudWatch-Konsole unter https://console.aws.amazon.com/cloudwatch/.
- Wählen Sie im Navigationsbereich unter "Wecker" die Option "Alle Wecker" aus.
- Wählen Sie den Amazon CloudWatch-Alarm aus, den Sie ändern möchten, wählen Sie "Aktionen" und anschließend "Bearbeiten".
- Wählen Sie links „Schritt 2 – Optionale Konfigurationsaktionen“ aus.
- Wählen Sie unter „Auslöser für Alarmstatus“ die Option „Aktiver Alarm“ aus, um eine ALARM-basierte Aktion einzurichten.
- Wählen Sie „Neues Thema erstellen“ aus, um eine Benachrichtigung an ein neu erstelltes SNS-Thema zu senden.
- Geben Sie im Feld "Neues Thema erstellen" einen eindeutigen Namen für das SNS-Thema an.
- Geben Sie im Feld „E-Mail-Endpunkte, die die Benachrichtigung erhalten...“ eine oder mehrere E-Mail-Adressen an.
- Wählen Sie dann „Create Topic“ (Thema erstellen) aus, um das erforderliche Amazon SNS-Thema zu erstellen.
- Wähle unten rechts „Weiter“, „Weiter“ und dann „Wecker aktualisieren“ aus, um die Änderungen zu übernehmen.
- Öffnen Sie Ihren E-Mail-Client und klicken Sie in der E-Mail von AWS Notifications auf den Link, um Ihr Abo für das betreffende SNS-Thema zu bestätigen.
- Wiederholen Sie die Schritte 4 bis 11 und wählen Sie in Schritt 5 für den "Trigger für Alarmstatus" die Optionen "OK" und "Unzureichende Daten" aus, um Aktionen für diese beiden Zustände einzurichten.
- Wiederholen Sie den Vorgang für alle anderen CloudWatch-Alarme in derselben AWS-Region.
- Wiederholen Sie den Vorgang für alle anderen CloudWatch-Alarme in allen anderen AWS-Regionen.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denCloudwatch Log Group Encrypted
Kategoriename in der API: CLOUDWATCH_LOG_GROUP_ENCRYPTED
Durch diese Prüfung wird sichergestellt, dass CloudWatch-Logs mit KMS konfiguriert sind.
Loggruppendaten werden immer in CloudWatch-Logs verschlüsselt. Standardmäßig verwendet CloudWatch Logs für die inaktiven Logdaten die serverseitige Verschlüsselung. Alternativ können Sie AWS Key Management Service für diese Verschlüsselung verwenden. In diesem Fall erfolgt die Verschlüsselung mit einem AWS KMS-Schlüssel. Die Verschlüsselung mit AWS KMS wird auf Loggruppenebene aktiviert, indem ein KMS-Schlüssel mit einer Loggruppe verknüpft wird, entweder beim Erstellen der Loggruppe oder nachdem sie vorhanden ist.
Empfehlung: Prüft, ob alle Loggruppen in Amazon CloudWatch-Logs mit KMS verschlüsselt sindWeitere Informationen finden Sie im Amazon CloudWatch-Nutzerhandbuch unter Logdaten in CloudWatch-Logs mit dem AWS Key Management Service verschlüsseln.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denCloudTrail CloudWatch Logs Enabled
Kategoriename in der API: CLOUD_TRAIL_CLOUD_WATCH_LOGS_ENABLED
Diese Steuerung prüft, ob CloudTrail-Pfade für das Senden von Logs an CloudWatch-Logs konfiguriert sind. Das Steuerelement schlägt fehl, wenn die Eigenschaft „CloudWatchLogsLogGroupArn“ des Pfads leer ist.
CloudTrail zeichnet AWS API-Aufrufe auf, die in einem bestimmten Konto ausgeführt werden. Die aufgezeichneten Informationen umfassen Folgendes:
- Die Identität des API-Aufrufers
- Der Zeitpunkt des API-Aufrufs
- Die Quell-IP-Adresse des API-Aufrufers
- Die Anfrageparameter
- Die vom AWS-Dienst zurückgegebenen Antwortelemente
CloudTrail verwendet Amazon S3 zum Speichern und Bereitstellen von Logdateien. Sie können CloudTrail-Logs in einem bestimmten S3-Bucket zur Langzeitanalyse erfassen. Für Echtzeitanalysen können Sie CloudTrail so konfigurieren, dass Logs an CloudWatch-Logs gesendet werden.
Für einen Weg, der in allen Regionen in einem Konto aktiviert ist, sendet CloudTrail Protokolldateien aus allen diesen Regionen an eine CloudWatch Logs-Loggruppe.
Der Sicherheits-Hub empfiehlt, CloudTrail-Logs an CloudWatch-Logs zu senden. Mit dieser Empfehlung soll sichergestellt werden, dass Kontoaktivitäten erfasst, überwacht und entsprechend gemeldet werden. Sie können CloudWatch-Logs verwenden, um dies mit Ihren AWS-Diensten einzurichten. Diese Empfehlung schließt nicht aus, dass eine andere Lösung verwendet werden kann.
Das Senden von CloudTrail-Logs an CloudWatch-Logs ermöglicht das Logging von Aktivitäten in Echtzeit und des Verlaufs basierend auf Nutzer, API, Ressource und IP-Adresse. Auf diese Weise können Sie Alarme und Benachrichtigungen für ungewöhnliche oder empfindliche Kontoaktivitäten einrichten.
Empfehlung: Prüfen Sie, ob alle CloudTrail-Pfade so konfiguriert sind, dass Logs an AWS CloudWatch gesendet werdenInformationen zur Einbindung von CloudTrail in CloudWatch-Logs finden Sie im AWS CloudTrail-Nutzerhandbuch unter Ereignisse an CloudWatch-Logs senden.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denNo AWS Credentials in CodeBuild Project Environment Variables
Kategoriename in der API: CODEBUILD_PROJECT_ENVVAR_AWSCRED_CHECK
Damit wird geprüft, ob das Projekt die Umgebungsvariablen AWS_ACCESS_KEY_ID
und AWS_SECRET_ACCESS_KEY
enthält.
Die Anmeldedaten für die Authentifizierung AWS_ACCESS_KEY_ID
und AWS_SECRET_ACCESS_KEY
sollten niemals im Klartext gespeichert werden, da dies zu unbeabsichtigten Datenlecks und unbefugtem Zugriff führen könnte.
Informationen zum Entfernen von Umgebungsvariablen aus einem CodeBuild-Projekt finden Sie im AWS CodeBuild-Nutzerhandbuch unter Ändern der Einstellungen eines Build-Projekts in AWS CodeBuild. 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 AWS Secrets Manager speichern und dann aus Ihrer Build-Spezifikation abrufen. Eine Anleitung dazu finden Sie im Feld „Wichtig“ im Abschnitt „Environment“ des AWS CodeBuild-Nutzerhandbuchs.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denCodebuild Project Source Repo Url Check
Kategoriename in der API: CODEBUILD_PROJECT_SOURCE_REPO_URL_CHECK
Damit wird geprüft, ob die Bitbucket-Quell-Repository-URL eines AWS CodeBuild-Projekts persönliche Zugriffstokens oder einen Nutzernamen und ein Passwort enthält. Die Kontrolle schlägt fehl, wenn die Bitbucket-Quell-Repository-URL persönliche Zugriffstokens oder einen Nutzernamen und ein Passwort enthält.
Anmeldedaten sollten nicht im Klartext gespeichert oder übertragen werden und nicht in der URL des Quell-Repositorys erscheinen. Anstelle von persönlichen Zugriffstokens oder Anmeldedaten sollten Sie in CodeBuild auf Ihren Quellanbieter zugreifen und die URL des Quell-Repositorys so ändern, dass sie nur den Pfad zum Speicherort des Bitbucket-Repositorys enthält. Die Verwendung von persönlichen Zugriffstokens oder Anmeldedaten kann zu unbeabsichtigten Datenlecks oder unbefugtem Zugriff führen.
Empfehlung: Prüft, ob alle Projekte, die GitHub oder Bitbucket als Quelle nutzen, OAuth verwendenSie können Ihr CodeBuild-Projekt für die Verwendung von OAuth aktualisieren.
Entfernen der Basisauthentifizierung / (GitHub) Personal Access Token aus der CodeBuild-Projektquelle
- Öffnen Sie die CodeBuild-Konsole unter https://console.aws.amazon.com/codebuild/.
- Wählen Sie das Build-Projekt aus, das persönliche Zugriffstokens oder einen Nutzernamen und ein Passwort enthält.
- Wählen Sie unter „Bearbeiten“ die Option „Quelle“ aus.
- Wählen Sie „Verbindung zu GitHub / Bitbucket trennen“ aus.
- Wählen Sie „Über OAuth verbinden“ und dann „Mit GitHub / Bitbucket verbinden“ aus.
- Wählen Sie bei entsprechender Aufforderung „Autorisieren“ aus.
- Konfigurieren Sie die Repository-URL und zusätzliche Konfigurationseinstellungen nach Bedarf neu.
- Wählen Sie „Quelle aktualisieren“ aus.
Weitere Informationen finden Sie unter CodeBuild-Anwendungsfälle im AWS CodeBuild-Nutzerhandbuch.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denCredentials Unused 45 Days Greater Disabled
Kategoriename in der API: CREDENTIALS_UNUSED_45_DAYS_GREATER_DISABLED
AWS IAM-Nutzer können mit verschiedenen Arten von Anmeldedaten auf AWS-Ressourcen zugreifen, z. B. Passwörter oder Zugriffsschlüssel. Es wird empfohlen, alle Anmeldedaten, die in den letzten 45 Tagen nicht verwendet wurden, zu deaktivieren oder zu entfernen.
Empfehlung: Achten Sie darauf, dass Anmeldedaten, die seit mindestens 45 Tagen nicht verwendet wurden, deaktiviert sind Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben:AWS-Konsole
So verwalten Sie ein nicht verwendetes Passwort (IAM-Zugriff auf die Nutzerkonsole)
- Melden Sie sich in der AWS Management Console an:
- Klicken Sie auf
Services
. - Klicken Sie auf
IAM
. - Klicken Sie auf
Users
. - Klicken Sie auf
Security Credentials
. - Nutzer auswählen, dessen
Console last sign-in
länger als 45 Tage ist - Klicken Sie auf
Security credentials
. - Klicken Sie im Abschnitt
Sign-in credentials
Console password
aufManage
- Wählen Sie unter „Konsolenzugriff“ die Option
Disable
aus.
10. Klicken Sie aufApply
.
So deaktivieren Sie Zugriffsschlüssel:
- Melden Sie sich in der AWS Management Console an:
- Klicken Sie auf
Services
. - Klicken Sie auf
IAM
. - Klicken Sie auf
Users
. - Klicken Sie auf
Security Credentials
. - Wählen Sie alle Zugriffsschlüssel aus, die älter als 45 Tage sind und verwendet wurden.
– Klicken Sie aufMake Inactive
. - Wählen Sie alle Zugriffsschlüssel aus, die älter als 45 Tage sind und nicht verwendet wurden, und
– Klicken Sie auf das „X“, umDelete
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denDefault Security Group Vpc Restricts All Traffic
Kategoriename in der API: DEFAULT_SECURITY_GROUP_VPC_RESTRICTS_ALL_TRAFFIC
Eine VPC umfasst eine Standardsicherheitsgruppe, deren Anfangseinstellungen den gesamten eingehenden Traffic ablehnen, den gesamten ausgehenden Traffic zulassen und den gesamten Traffic zwischen Instanzen zulassen, die der Sicherheitsgruppe zugewiesen sind. Wenn Sie beim Starten einer Instanz keine Sicherheitsgruppe angeben, wird die Instanz automatisch dieser Standardsicherheitsgruppe zugewiesen. Sicherheitsgruppen bieten eine zustandsorientierte Filterung des ein- und ausgehenden Netzwerktraffics zu AWS-Ressourcen. Es wird empfohlen, den gesamten Traffic durch die Standard-Sicherheitsgruppe einzuschränken.
Die Standard-VPC in jeder Region sollte entsprechend aktualisiert werden. Alle neu erstellten VPCs enthalten automatisch eine Standardsicherheitsgruppe, die behoben werden muss, um dieser Empfehlung zu entsprechen.
HINWEIS:Bei der Umsetzung dieser Empfehlung ist das VPC-Fluss-Logging von unschätzbarem Wert, um den Portzugriff mit den geringsten Berechtigungen zu bestimmen, der für ein ordnungsgemäßes Funktionieren der Systeme erforderlich ist, da es alle Annahmen und Ablehnungen von Paketen unter den aktuellen Sicherheitsgruppen protokollieren kann. Dies reduziert die primäre Hürde für das Engineering mit den geringsten Berechtigungen erheblich: Es werden die von Systemen in der Umgebung benötigte Mindestanzahl von Ports ermittelt. Auch wenn die Empfehlung für das VPC-Fluss-Logging in dieser Benchmark nicht als dauerhafte Sicherheitsmaßnahme übernommen wird, sollte sie während jeder Phase der Erkennung und Entwicklung für Sicherheitsgruppen mit den geringsten Berechtigungen verwendet werden.
Empfehlung: Achten Sie darauf, dass die Standardsicherheitsgruppe jeder VPC den gesamten Traffic einschränktMitglieder der Sicherheitsgruppe
So implementieren Sie den vorgeschriebenen Status:
- AWS-Ressourcen identifizieren, die in der Standardsicherheitsgruppe vorhanden sind
- Erstellen Sie eine Gruppe von Sicherheitsgruppen mit den geringsten Berechtigungen für diese Ressourcen
- Ressourcen in diese Sicherheitsgruppen aufnehmen
- Die in Schritt 1 angegebenen Ressourcen aus der Standardsicherheitsgruppe entfernen
Status der Sicherheitsgruppe
- Melden Sie sich unter https://console.aws.amazon.com/vpc/home in der AWS-Verwaltungskonsole an.
- Wiederholen Sie die nächsten Schritte für alle VPCs, einschließlich der Standard-VPC in jeder AWS-Region:
- Klicken Sie im linken Bereich auf
Security Groups
. - Führen Sie für jede Standardsicherheitsgruppe die folgenden Schritte aus:
- Sicherheitsgruppe „
default
“ auswählen - Klicken Sie auf den Tab
Inbound Rules
. - Alle eingehenden Regeln entfernen
- Klicken Sie auf den Tab
Outbound Rules
. - Alle Ausgangsregeln entfernen
Empfohlen:
Mit 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, um Text wie „NICHT VERWENDEN“ hinzuzufügen. KEINE REGELN HINZUFÜGEN“
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denDms 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 außerhalb des Replikationsnetzwerks nicht zugreifen können. Eine Replikationsinstanz sollte eine private IP-Adresse haben, wenn sich die Quell- und die Zieldatenbank im selben Netzwerk befinden. Das Netzwerk muss außerdem über VPN, AWS Direct Connect oder VPC-Peering mit der VPC der Replikationsinstanz verbunden sein. Weitere Informationen zu öffentlichen und privaten Replikationsinstanzen finden Sie unter Öffentliche und private Replikationsinstanzen im Nutzerhandbuch für den AWS Database Migration Service.
Achten Sie außerdem darauf, dass nur autorisierte Nutzer Zugriff auf die Konfiguration Ihrer AWS DMS-Instanz haben. Schränken Sie dazu die IAM-Berechtigungen der Nutzer zum Ändern von AWS DMS-Einstellungen und -Ressourcen ein.
Empfehlung: Prüft, ob Replikationsinstanzen von AWS Database Migration Service öffentlich sindDie Einstellung für den öffentlichen Zugriff für eine DMS-Replikationsinstanz kann nach dem Erstellen nicht mehr geändert werden. Löschen Sie die aktuelle Instanz und erstellen Sie sie dann neu, um die Einstellung für den öffentlichen Zugriff zu ändern. Wählen Sie nicht die Option Öffentlich zugänglich aus.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denDo 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 ausgewählt. Beim Erstellen der IAM-Nutzeranmeldedaten müssen Sie festlegen, welche Art von Zugriff sie benötigen.
Programmatischer Zugriff: Der IAM-Nutzer muss möglicherweise API-Aufrufe ausführen, die AWS CLI oder die Tools for Windows PowerShell verwenden. Erstellen Sie in diesem Fall einen Zugriffsschlüssel (Zugriffsschlüssel-ID und geheimer Zugriffsschlüssel) für diesen Nutzer.
Zugriff auf AWS Management Console: Wenn der Nutzer Zugriff auf die AWS Management Console benötigt, erstellen Sie ein Passwort für den Nutzer.
Empfehlung: Richten Sie bei der Ersteinrichtung von Nutzern mit einem Console-Passwort keine Zugriffsschlüssel für alle IAM-Nutzer ein Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben:AWS-Konsole
- Melden Sie sich in der AWS Management Console an:
- Klicken Sie auf
Services
. - Klicken Sie auf
IAM
. - Klicken Sie auf
Users
. - Klicken Sie auf
Security Credentials
. - Als Administrator
– Klicken Sie bei Schlüsseln, die zur selben Zeit wie das Nutzerprofil erstellt wurden, aber nicht verwendet wurden, auf das X(Delete)
. - Als IAM-Nutzer
– Klicken Sie bei Schlüsseln, die zur selben Zeit wie das Nutzerprofil erstellt wurden, aber nicht verwendet wurden, auf das X(Delete)
.
AWS-CLI
aws iam delete-access-key --access-key-id <access-key-id-listed> --user-name <users-name>
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denDynamodb Autoscaling Enabled
Kategoriename in der API: DYNAMODB_AUTOSCALING_ENABLED
Damit wird geprüft, ob eine Amazon DynamoDB-Tabelle ihre Lese- und Schreibkapazität nach Bedarf skalieren kann. Diese Steuerung gilt, wenn die Tabelle entweder den On-Demand-Kapazitätsmodus oder den Bereitstellungsmodus mit konfiguriertem Autoscaling verwendet. Durch die bedarfsgerechte Skalierung der Kapazität werden Ausnahmen gedrosselt, wodurch die Verfügbarkeit Ihrer Anwendungen aufrechterhalten wird.
DynamoDB-Tabellen im On-Demand-Kapazitätsmodus werden nur durch die Standardtabellenkontingente für den DynamoDB-Durchsatz begrenzt. Wenn Sie diese Kontingente erhöhen möchten, können Sie ein Support-Ticket über den AWS-Support einreichen.
DynamoDB-Tabellen im bereitgestellten Modus mit Autoscaling passen die bereitgestellte Durchsatzkapazität dynamisch in Reaktion auf Traffic-Muster an. Weitere Informationen zur DynamoDB-Anfragedrosselung finden Sie im Amazon DynamoDB-Entwicklerhandbuch unter „Anfragedrosselung und Burst-Kapazität“.
Empfehlung: DynamoDB-Tabellen sollten die Kapazität automatisch je nach Bedarf skalierenEine ausführliche Anleitung zum Aktivieren der automatischen Skalierung von DynamoDB für vorhandene Tabellen im Kapazitätsmodus finden Sie im Amazon DynamoDB-Entwicklerhandbuch unter Aktivierung von DynamoDB-Autoscaling für vorhandene Tabellen.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denDynamodb In Backup Plan
Kategoriename in der API: DYNAMODB_IN_BACKUP_PLAN
Mit diesem Steuerelement wird ausgewertet, ob eine DynamoDB-Tabelle durch einen Sicherungsplan abgedeckt ist. Die Steuerung schlägt fehl, wenn eine DynamoDB-Tabelle nicht durch einen Sicherungsplan abgedeckt ist. Mit diesem Steuerelement werden nur DynamoDB-Tabellen im Status AKTIV ausgewertet.
Sicherungen helfen Ihnen bei der schnelleren Wiederherstellung nach einem Sicherheitsvorfall. Außerdem stärken 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 ein Sicherungsplan vorhanden seinInformationen zum Hinzufügen einer DynamoDB-Tabelle zu einem AWS Backup-Sicherungsplan finden Sie im AWS Backup-Entwicklerhandbuch unter Einem Sicherungsplan Ressourcen zuweisen.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denDynamodb Pitr Enabled
Kategoriename in der API: DYNAMODB_PITR_ENABLED
Die Wiederherstellung zu einem bestimmten Zeitpunkt ist einer der verfügbaren Mechanismen zum Sichern von DynamoDB-Tabellen.
Eine Sicherung zu einem bestimmten Zeitpunkt wird 35 Tage lang gespeichert. Wenn Sie eine längere Aufbewahrung benötigen, lesen Sie in der AWS-Dokumentation den Abschnitt Geplante Sicherungen für Amazon DynamoDB mit AWS Backup einrichten.
Empfehlung: Prüft, 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 beheben: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
So aktivieren Sie die DynamoDB-Wiederherstellung zu einem bestimmten Zeitpunkt für eine vorhandene Tabelle:
- Öffnen Sie die DynamoDB-Konsole unter https://console.aws.amazon.com/dynamodb/.
- Wählen Sie die Tabelle aus, mit der Sie arbeiten möchten, und wählen Sie dann „Sicherungen“ aus.
- Wählen Sie im Abschnitt „Wiederherstellung zu einem bestimmten Zeitpunkt“ unter „Status“ die Option „Aktivieren“ aus.
- Wähle 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"
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denDynamodb 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 beheben:Terraform
Um dieses Problem zu beheben, erstellen Sie einen AWS KMS-Schlüssel und verwenden Sie ihn zum Verschlüsseln der problematischen DynamoDB-Ressource.
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
Angenommen, es ist ein vorhandener AWS KMS-Schlüssel zum Verschlüsseln von DynamoDB verfügbar.
So ändern Sie die Verschlüsselung einer DynamoDB-Tabelle in einen vom Kunden verwalteten und eigenen KMS-Schlüssel:
- Öffnen Sie die DynamoDB-Konsole unter https://console.aws.amazon.com/dynamodb/.
- Wählen Sie die Tabelle aus, mit der Sie arbeiten möchten, und wählen Sie dann „Weitere Einstellungen“ aus.
- Wählen Sie unter „Verschlüsselung“ die Option „Verschlüsselung verwalten“ aus.
- Wählen Sie unter „Verschlüsselung ruhender Daten“ die Option „In Ihrem Konto gespeichert“ aus, die Ihnen gehört und von Ihnen verwaltet wird.
- 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>"
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denEbs Optimized Instance
Kategoriename in der API: EBS_OPTIMIZED_INSTANCE
Prüft, ob die EBS-Optimierung für die EBS-optimierten EC2-Instanzen aktiviert ist
Empfehlung: Prüft, ob die EBS-Optimierung für alle Instanzen aktiviert ist, die die EBS-Optimierung unterstützenInformationen zum Konfigurieren von EBS-optimierten Instanzeinstellungen finden Sie unter Für Amazon EBS optimierte Instanzen im Amazon EC2-Nutzerhandbuch.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denEbs 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 Kontrolle schlägt fehl, wenn Amazon EBS-Snapshots von jemandem wiederhergestellt werden können.
EBS-Snapshots werden verwendet, um die Daten auf Ihren EBS-Volumes zu einem bestimmten Zeitpunkt in Amazon S3 zu sichern. Sie können die Snapshots verwenden, um vorherige Status von EBS-Volumes wiederherzustellen. Es ist selten akzeptabel, eine Momentaufnahme mit der Öffentlichkeit zu teilen. In der Regel wurde die Entscheidung, einen Snapshot öffentlich freizugeben, irrtümlicherweise oder ohne umfassende Kenntnisse über die Auswirkungen getroffen. So wird sichergestellt, dass das Teilen dieser Inhalte vollständig geplant und beabsichtigt war.
Empfehlung: Amazon EBS-Snapshots sollten nicht öffentlich wiederherstellbar sein Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben:AWS-Konsole
Um dieses Problem zu beheben, aktualisieren Sie Ihren EBS-Snapshot, sodass er privat statt öffentlich wird.
So machen Sie einen öffentlichen EBS-Snapshot privat:
- Öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/.
- Wählen Sie im Navigationsbereich unter „Elastic Block Store“ (Elastic Block Store) das Menü „Snapshots“ und dann Ihren öffentlichen Snapshot aus.
- Wählen Sie unter „Aktionen“ die Option „Berechtigungen ändern“ aus.
- Wählen Sie „Privat“ aus.
- (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.
- Wählen Sie „Speichern“ aus.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denEbs Volume Encryption Enabled All Regions
Kategoriename in der API: EBS_VOLUME_ENCRYPTION_ENABLED_ALL_REGIONS
Elastic Compute Cloud (EC2) unterstützt die Verschlüsselung ruhender Daten, wenn der Elastic Block Store-Dienst (EBS) verwendet wird. Wenn diese Option standardmäßig deaktiviert ist, wird das Erzwingen der Verschlüsselung bei der Erstellung eines EBS-Volumes 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 beheben:AWS-Konsole
- Melden Sie sich in der AWS Management Console an und öffnen Sie die Amazon EC2-Konsole über https://console.aws.amazon.com/ec2/.
- Klicken Sie unter
Account attributes
aufEBS encryption
. - Klicken Sie auf
Manage
. - Klicken Sie das Kästchen
Enable
an. - Klicken Sie auf
Update EBS encryption
. - Wiederholen Sie diese Schritte für jede Region, für die eine Änderung erforderlich ist.
Hinweis: Die EBS-Volume-Verschlüsselung wird pro Region konfiguriert.
AWS-CLI
- Ausführen
aws --region <region> ec2 enable-ebs-encryption-by-default
- Prüfen Sie, ob
"EbsEncryptionByDefault": true
angezeigt wird. - Wiederholen Sie alle Regionen, für die die Änderung erforderlich ist.
Hinweis: Die EBS-Volume-Verschlüsselung wird pro Region konfiguriert.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denEc2 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: Sorgt dafür, dass alle Instanzen zu einer VPC gehören Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben:Terraform
Wenn Sie in Terraform klassische EC2-Instanzen definiert haben, können Sie Ihre Ressourcen so ändern, dass sie Teil einer VPC sind. Diese Migration hängt von einer Architektur ab, die Ihren Anforderungen am besten entspricht. Im Folgenden finden Sie ein einfaches Terraform-Beispiel, das eine öffentlich zugängliche EC2 in einer VPC veranschaulicht.
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 email@example.com"
}
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. Das 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 – Dadurch wird Ihr privater Schlüssel 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: Definieren Sie für einen stärkeren Zugriff ein eingeschränktes CIDR für SSH an Port 22
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>
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denEc2 Instance No Public Ip
Kategoriename in der API: EC2_INSTANCE_NO_PUBLIC_IP
Bei EC2-Instanzen mit öffentlicher IP-Adresse besteht ein erhöhtes Risiko einer Manipulation. Es wird empfohlen, EC2-Instanzen nicht mit einer öffentlichen IP-Adresse zu konfigurieren.
Empfehlung: Achten Sie darauf, dass keine Instanzen eine öffentliche IP-Adresse haben Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben: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 für die öffentliche IPv4-Adressierung bei Nicht-Standardsubnetzen auf „false“ und bei Standardsubnetzen auf „true“ festgelegt. Eine Ausnahme stellt ein nicht standardmäßiges Subnetz dar, das vom Assistenten für den Start von Amazon EC2-Instanzen erstellt wurde. Der Assistent setzt das Attribut auf "true". Sie können dieses Attribut mit der Amazon VPC-Konsole ändern.
So ändern Sie das Verhalten der öffentlichen IPv4-Adressierung Ihres Subnetzes
- Öffnen Sie die Amazon VPC-Konsole unter https://console.aws.amazon.com/vpc/.
- Wählen Sie im Navigationsbereich Subnetze aus.
- Wählen Sie Ihr Subnetz und dann Aktionen, Subnetzeinstellungen bearbeiten aus.
- Wenn das Kästchen Automatische Zuweisung öffentlicher IPv4-Adressen aktivieren angeklickt ist, wird eine öffentliche IPv4-Adresse für alle Instanzen angefordert, die im ausgewählten Subnetz gestartet werden. Klicken Sie das Kästchen nach Bedarf an oder entfernen Sie das Häkchen und wählen Sie dann Speichern aus.
AWS-CLI
Mit dem folgenden Befehl wird eine EC2-Instanz in einem Standardsubnetz ausgeführt, ohne ihm eine öffentliche IP-Adresse zuzuordnen.
aws ec2 run-instances \
--image-id <ami_id> \
--instance-type <instance_flavor> \
--no-associate-public-ip-address \
--key-name MyKeyPair
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denEc2 Managedinstance Association Compliance Status Check
Kategoriename in der API: EC2_MANAGEDINSTANCE_ASSOCIATION_COMPLIANCE_STATUS_CHECK
Eine State Manager-Verknüpfung ist eine Konfiguration, die Ihren verwalteten Instanzen zugewiesen wird. Die Konfiguration definiert den Status, den Sie auf Ihren Instanzen beibehalten möchten. Beispielsweise kann eine Verknüpfung angeben, dass auf Ihren Instanzen Antivirensoftware installiert und ausgeführt werden muss oder dass bestimmte Ports geschlossen werden müssen. EC2-Instanzen, die eine Verknüpfung mit AWS Systems Manager haben, werden von Systems Manager verwaltet, was das Anwenden von Patches, das Beheben von Fehlkonfigurationen und das Reagieren auf Sicherheitsereignisse erleichtert.
Empfehlung: Prüft den Compliancestatus der AWS Systems Manager-Verknüpfung Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben:Terraform
Das folgende Beispiel zeigt, wie Sie eine einfache EC2-Instanz, ein AWS Systems Manager-Dokument (SSM) und eine Verknüpfung zwischen SSM und der EC2-Instanz erstellen. Es werden nur Dokumente des Typs Command
und Policy
unterstützt.
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 Erstellen von Verknüpfungen.
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>"
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denEc2 Managedinstance Patch Compliance Status Check
Kategoriename in der API: EC2_MANAGEDINSTANCE_PATCH_COMPLIANCE_STATUS_CHECK
Mit diesem Steuerelement wird geprüft, ob der Status der AWS Systems Manager-Verknüpfungscompliance COMPLIANT oder NON_COMPLIANT ist, nachdem die Verknüpfung auf einer Instanz ausgeführt wurde. Die Steuerung schlägt fehl, wenn der Compliancestatus der Verknüpfung NON_COMPLIANT ist.
Eine State Manager-Verknüpfung ist eine Konfiguration, die Ihren verwalteten Instanzen zugewiesen wird. Die Konfiguration definiert den Status, den Sie auf Ihren Instanzen beibehalten möchten. Beispielsweise kann eine Verknüpfung angeben, dass auf Ihren Instanzen Antivirensoftware installiert und ausgeführt werden muss oder dass bestimmte Ports geschlossen werden müssen.
Nachdem Sie eine oder mehrere State Manager-Verknüpfungen erstellt haben, stehen Ihnen sofort Informationen zum Compliancestatus zur Verfügung. Sie können den Compliancestatus in der Console oder als Reaktion auf AWS CLI-Befehle oder entsprechende Systems Manager API-Aktionen ansehen. Bei Verknüpfungen wird unter „Konfigurationscompliance“ der Compliancestatus angezeigt („Konform“ oder „Nicht konform“). Außerdem wird der Schweregrad angezeigt, der der Verknüpfung zugewiesen ist, z. B. „Kritisch“ oder „Mittel“.
Weitere Informationen zur Compliance der State Manager-Verknüpfung finden Sie im AWS Systems Manager-Nutzerhandbuch unter Informationen zur Einhaltung der State Manager-Verknüpfung.
Empfehlung: Prüft den Status der AWS Systems Manager-PatchcomplianceEine fehlgeschlagene Verknüpfung kann auf verschiedene Dinge zurückzuführen sein, z. B. auf Ziele und SSM-Dokumentnamen. Um dieses Problem zu beheben, müssen Sie zuerst die Verknüpfung identifizieren und untersuchen. Rufen Sie dazu den Verknüpfungsverlauf auf. Eine Anleitung zum Aufrufen des Verknüpfungsverlaufs finden Sie unter Verknüpfungsverlauf ansehen im AWS Systems Manager-Nutzerhandbuch.
Anschließend 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, Schweregrad oder 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 Bearbeiten und Erstellen einer neuen Version einer Verknüpfung.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denEc2 Metadata Service Allows Imdsv2
Kategoriename in der API: EC2_METADATA_SERVICE_ALLOWS_IMDSV2
Beim Aktivieren des Metadatendienstes auf AWS EC2-Instanzen können Nutzer entweder den Instanzmetadatendienst Version 1 (IMDSv1; eine Anfrage/Antwort-Methode) oder den Instanzmetadatendienst Version 2 (IMDSv2; eine sitzungsorientierte Methode) verwenden.
Empfehlung: Achten Sie darauf, dass der EC2-Metadatendienst nur IMDSv2 zulässtÜber die Console:
1. Melden Sie sich in der AWS-Verwaltungskonsole an und öffnen Sie die Amazon EC2-Konsole über https://console.aws.amazon.com/ec2/.
2. Wählen Sie im Menü „Instanzen“ die Option „Instanzen“ aus.
3. Wählen Sie für jede Instanz die entsprechende Instanz aus und klicken Sie dann auf „Aktionen“ > „Optionen für Instanzmetadaten ändern“.
4. Wenn der Instanzmetadatendienst aktiviert ist, setzen Sie IMDSv2 auf "Erforderlich".
Über die Befehlszeile:
aws ec2 modify-instance-metadata-options --instance-id <instance_id> --http-tokens required
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denEc2 Volume Inuse Check
Kategoriename in der API: EC2_VOLUME_INUSE_CHECK
Erkennen und Entfernen nicht angehängter (nicht verwendeter) Elastic Block Store-Volumes (EBS-Volumes) in Ihrem AWS-Konto, um die Kosten Ihrer monatlichen AWS-Rechnung zu senken. Das Löschen nicht verwendeter EBS-Volumes verringert auch das Risiko, dass vertrauliche/sensible Daten Ihr Unternehmen verlassen. Außerdem prüft diese Steuerung auch, ob archivierte EC2-Instanzen zum Löschen von Volumes bei der Beendigung konfiguriert sind.
EC2-Instanzen sind standardmäßig so konfiguriert, dass sie die Daten in allen mit der Instanz verknüpften EBS-Volumes und das Root-EBS-Volume der Instanz löschen. Alle Nicht-Root-EBS-Volumes, die beim Start oder während der Ausführung an die Instanz angehängt sind, bleiben jedoch standardmäßig nach der Beendigung erhalten.
Empfehlung: Prüft, 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 beheben:Terraform
Um dieses Szenario mit Terraform zu verhindern, erstellen Sie EC2-Instanzen mit eingebetteten EBS-Blöcken. Dadurch wird sichergestellt, dass alle mit der Instanz verknüpften EBS-Blöcke (nicht nur das Stammverzeichnis) bei der Instanzbeendigung gelöscht werden, indem das Attribut ebs_block_device.delete_on_termination
standardmäßig auf true
gesetzt ist.
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
- Öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/.
- Wählen Sie im Navigationsbereich Volumes aus.
- Wählen Sie das zu löschende Volume und dann Aktionen, Volume löschen aus.
- 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.
- Wählen Sie im Bestätigungsdialogfeld die Option 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 ausgeführt wurde, wird keine Ausgabe zurückgegeben.
aws ec2 delete-volume --volume-id vol-049df61146c4d7901
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denEfs 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 bei der Übertragung und die Verschlüsselung ruhender Daten. Dadurch wird geprüft, ob für alle EFS-Dateisysteme die Verschlüsselung ruhender Daten für alle aktivierten Regionen im Konto konfiguriert ist.
Empfehlung: Prüft, ob EFS zum Verschlüsseln von Dateidaten mit KMS konfiguriert ist Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben:Terraform
Mit dem folgenden Code-Snippet kann eine KMS-verschlüsselte EFS erstellt werden. Hinweis: Das Attribut kms_key_id
ist optional und ein Schlüssel wird erstellt, wenn keine kms-Schlüssel-ID übergeben wird.
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 mithilfe der AWS-Konsole finden Sie unter Inaktives Dateisystem mit der Konsole verschlüsseln.
AWS-CLI
Beachten Sie, dass beim Erstellen von EFS über die Console die Verschlüsselung ruhender Daten standardmäßig aktiviert ist. Dies gilt jedoch nicht für EFS, die mit der Befehlszeile, der API oder dem SDK erstellt wurden. Im folgenden Beispiel können Sie ein verschlüsseltes Dateisystem in Ihrer Infrastruktur erstellen.
aws efs create-file-system \
--backup \
--encrypted \
--region us-east-1 \
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denEfs In Backup Plan
Kategoriename in der API: EFS_IN_BACKUP_PLAN
In den Best Practices für Amazon wird empfohlen, Sicherungen für Ihre Elastic File Systems (EFS) zu konfigurieren. Dadurch wird in allen EFS in jeder aktivierten Region in Ihrem AWS-Konto nach aktivierten Sicherungen gesucht.
Empfehlung: Prüft, ob EFS-Dateisysteme in AWS-Sicherungsplänen enthalten sind Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben: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-Sicherungsdienst und die EFS-zu-EFS-Sicherungslösung. Wie Sie Probleme mit nicht gesichertem EFS über die Console beheben, erfahren Sie unter:
AWS-CLI
Es gibt mehrere Möglichkeiten, konforme EFS-Dateisysteme über die Befehlszeile zu erstellen:
- EFS mit aktivierter automatischer Sicherung erstellen (standardmäßig für One Zone-Speicher und unter Vorbehalt der Verfügbarkeit von Sicherungen in der AWS-Region)
- EFS erstellen und Sicherungsrichtlinie erstellen
Wenn die Korrektur jedoch in einem vorhandenen EFS erfolgen muss, ist es am besten, eine Sicherungsrichtlinie zu erstellen und mit Ihrem nicht konformen EFS zu verknüpfen. Sie benötigen für jeden EFS einen Befehl 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
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denElb 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 werden. Die Steuerung schlägt fehl, wenn der mit dem HTTPS/SSL-Listener konfigurierte klassische Load Balancer kein von ACM bereitgestelltes Zertifikat verwendet.
Zum Erstellen eines Zertifikats können Sie entweder ACM oder ein Tool verwenden, das die SSL- und TLS-Protokolle unterstützt, z. B. OpenSSL. Security Hub empfiehlt, dass Sie ACM verwenden, um Zertifikate für Ihren Load-Balancer 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üft, ob alle klassischen Load Balancer SSL-Zertifikate verwenden, die von AWS Certificate Manager bereitgestellt wurdenInformationen zum Verknüpfen eines ACM-SSL/TLS-Zertifikats mit einem klassischen Load Balancer finden Sie im AWS Knowledge Center-Artikel Wie kann ich ein ACM-SSL/TLS-Zertifikat mit einem klassischen, Anwendungs- oder Network Load Balancer verknüpfen?.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denElb 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 Steuerung schlägt fehl, wenn der Löschschutz nicht konfiguriert ist.
Aktivieren Sie den Löschschutz, um den 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 beheben:AWS-Konsole
Um zu verhindern, dass Ihr Load-Balancer versehentlich gelöscht wird, können Sie den Löschschutz aktivieren. 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:
- Öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/.
- Wählen Sie im Navigationsbereich unter LOAD BALANCING die Option Load Balancer aus.
- Wählen Sie den Load-Balancer aus.
- Wählen Sie auf dem Tab Beschreibung die Option Attribute bearbeiten aus.
- Wählen Sie auf der Seite Attribute des Load-Balancers bearbeiten die Option Für Löschschutz aktivieren und dann Speichern aus.
- Klicken Sie auf Speichern.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denElb Logging Enabled
Kategoriename in der API: ELB_LOGGING_ENABLED
Dadurch wird geprüft, ob Logging für den Application Load Balancer und den klassischen Load Balancer aktiviert ist. Die Steuerung schlägt fehl, wenn access_logs.s3.enabled auf „false“ gesetzt ist.
Elastic Load Balancing bietet Zugriffslogs, die detaillierte Informationen über Anfragen erfassen, die an Ihren Load-Balancer gesendet werden. Jedes Protokoll enthält Informationen wie die Uhrzeit, zu der die Anfrage eingegangen ist, die IP-Adresse des Clients, Latenzen, Anfragepfade und Serverantworten. Sie können diese Zugriffslogs verwenden, um Traffic-Muster zu analysieren und Probleme zu beheben.
Weitere Informationen finden Sie unter Zugriffslogs für Ihren klassischen Load Balancer im Nutzerhandbuch für klassische 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 beheben:AWS-Konsole
Aktualisieren Sie die Load-Balancer, um das Logging zu aktivieren, um dieses Problem zu beheben.
Zugriffslogs aktivieren
- Öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/.
- Wählen Sie im Navigationsbereich Load Balancer (Load-Balancer) aus.
- Wählen Sie einen Application Load Balancer oder einen Classic Load Balancer aus.
- Wählen Sie unter Aktionen die Option Attribute bearbeiten aus.
- Wählen Sie unter Zugriffslogs die Option Aktivieren aus.
- Gib deinen S3-Standort ein. Dieser Standort kann existieren oder für Sie erstellt werden. Wenn Sie kein Präfix angeben, werden die Zugriffslogs im Stammverzeichnis des S3-Buckets gespeichert.
- Klicken Sie auf Speichern.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denElb 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 Verwendung einer sicheren Kommunikation konfiguriert sind.
Ein Listener ist ein Prozess, der nach Verbindungsanfragen sucht. Sie ist mit einem Protokoll und einem Port für Frontend-Verbindungen (Client zu Load-Balancer) sowie einem Protokoll und einem Port für Backend-Verbindungen (Load-Balancer zu Instanz) konfiguriert. Informationen zu den Ports, Protokollen und Listener-Konfigurationen, die von Elastic Load Balancing unterstützt werden, finden Sie unter Listener für Ihren klassischen Load Balancer.
Empfehlung: Prüft, ob SSL- oder HTTPS-Listener für alle klassischen Load Balancer konfiguriert sindInformationen zum Konfigurieren von SSL oder TLS für klassische Load-Balancer finden Sie unter HTTPS/SSL-Load-Balancer mit der AWS Management Console erstellen.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denEncrypted Volumes
Kategoriename in der API: ENCRYPTED_VOLUMES
Prüft, ob die angehängten EBS-Volumes verschlüsselt sind. Um diese Prüfung zu bestehen, müssen EBS-Volumes aktiv und verschlüsselt sein. Wenn das EBS-Volume nicht angehängt ist, unterliegt es dieser Prüfung nicht.
Für eine zusätzliche Sicherheitsebene der 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, pflegen und schützen müssen. Zum Erstellen verschlüsselter Volumes und Snapshots werden KMS-Schlüssel verwendet.
Weitere Informationen zur Amazon EBS-Verschlüsselung finden Sie unter Amazon EBS-Verschlüsselung im Amazon EC2-Benutzerhandbuch für Linux-Instanzen.
Empfehlung: Ruhende Daten von angehängten Amazon EBS-Volumes sollten verschlüsselt werden Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben:AWS-Konsole
Es gibt keine direkte Möglichkeit, ein vorhandenes unverschlüsseltes Volume oder einen vorhandenen unverschlüsselten Snapshot zu verschlüsseln. Sie können ein neues Volume oder einen neuen Snapshot nur beim Erstellen verschlüsseln.
Wenn Sie die Verschlüsselung standardmäßig aktiviert haben, verschlüsselt Amazon EBS das resultierende neue Volume oder den resultierenden 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 die Verschlüsselung 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 unter Amazon EBS-Volume erstellen und Amazon EBS-Snapshot kopieren im Amazon EC2-Nutzerhandbuch für Linux-Instanzen.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denEncryption At Rest Enabled Rds Instances
Kategoriename in der API: ENCRYPTION_AT_REST_ENABLED_RDS_INSTANCES
Mit Amazon RDS verschlüsselte DB-Instanzen verwenden den branchenüblichen AES-256-Verschlüsselungsalgorithmus, um Ihre Daten auf dem Server zu verschlüsseln, auf dem Ihre Amazon RDS DB-Instanzen gehostet werden. Nach der Verschlüsselung Ihrer Daten führt Amazon RDS die Authentifizierung des Zugriffs und die Entschlüsselung Ihrer Daten transparent mit minimaler Auswirkung auf die Leistung durch.
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 beheben:AWS-Konsole
- Melden Sie sich in der AWS-Verwaltungskonsole an und öffnen Sie das RDS-Dashboard unter https://console.aws.amazon.com/rds/.
- Klicken Sie im linken Navigationsbereich auf
Databases
. - Wählen Sie die Datenbankinstanz aus, die verschlüsselt werden soll.
- Klicken Sie oben rechts auf die Schaltfläche
Actions
und wählen SieTake Snapshot
aus. - Geben Sie auf der Seite "Snapshot erstellen" den Namen der Datenbank, von der Sie einen Snapshot erstellen möchten, in das Feld
Snapshot Name
ein und klicken Sie aufTake Snapshot
. - Wählen Sie den neu erstellten Snapshot aus, klicken Sie auf die Schaltfläche
Action
oben rechts und wählen SieCopy snapshot
aus dem Menü Aktion aus. - Führen Sie auf der Seite "Kopie von DB-Snapshot erstellen" die folgenden Schritte aus:
- Geben Sie im Feld „Neue Datenbank-Snapshot-ID“ einen Namen für die
new snapshot
ein. - Klicken Sie das Kästchen
Copy Tags
an. Der neue Snapshot muss dieselben Tags wie der Quell-Snapshot haben. - Wählen Sie
Yes
aus der Drop-down-ListeEnable Encryption
aus, um die Verschlüsselung zu aktivieren. Sie können den Standardverschlüsselungsschlüssel von AWS oder den benutzerdefinierten Schlüssel aus der Drop-down-Liste „Master Key“ verwenden.
- Klicken Sie auf
Copy Snapshot
, um eine verschlüsselte Kopie des ausgewählten Instanz-Snapshots zu erstellen. - Wählen Sie die neue Snapshot Encrypted Copy aus und klicken Sie oben rechts auf die Schaltfläche
Action
. Wählen Sie dann im Menü „Action“ die SchaltflächeRestore Snapshot
aus. Dadurch wird der verschlüsselte Snapshot in einer neuen Datenbankinstanz wiederhergestellt. - Geben Sie auf der Seite "DB-Instanz wiederherstellen" im Feld "DB-Instanz-ID" einen eindeutigen Namen für die neue Datenbankinstanz ein.
- Prüfen Sie die Details der Instanzkonfiguration und klicken Sie auf
Restore DB Instance
. - Wenn der neue Instanzbereitstellungsprozess abgeschlossen ist, kann die Anwendungskonfiguration so aktualisiert werden, dass sie auf den Endpunkt der neuen verschlüsselten Datenbankinstanz verweist. Nachdem der Datenbankendpunkt auf Anwendungsebene geändert wurde, kann die unverschlüsselte Instanz entfernt werden.
AWS-CLI
- Führen Sie den Befehl
describe-db-instances
aus, um alle in der ausgewählten AWS-Region verfügbaren RDS-Datenbanknamen aufzulisten. Die Befehlsausgabe sollte die Datenbankinstanz-ID zurückgeben.
aws rds describe-db-instances --region <region-name> --query 'DBInstances[*].DBInstanceIdentifier'
- Führen Sie den Befehl
create-db-snapshot
aus, um einen Snapshot für die ausgewählte Datenbankinstanz zu erstellen. Die Befehlsausgabe gibt dennew 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>
- Führen Sie nun den Befehl
list-aliases
aus, um die KMS-Schlüsselaliasse aufzulisten, die in einer bestimmten Region verfügbar sind. Die Befehlsausgabe sollte allekey alias currently available
zurückgeben. Ermitteln Sie für den Aktivierungsprozess der RDS-Verschlüsselung die ID des AWS-Standard-KMS-Schlüssels.
aws kms list-aliases --region <region-name>
- Führen Sie den Befehl
copy-db-snapshot
mit der standardmäßigen KMS-Schlüssel-ID für RDS-Instanzen aus, die zuvor zurückgegeben wurden, um eine verschlüsselte Kopie des Datenbankinstanz-Snapshots zu erstellen. Die Befehlsausgabe gibt denencrypted 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>
- 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. Wenn dies erfolgreich ist, sollte die Befehlsausgabe die neue verschlüsselte Datenbankinstanzkonfiguration 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>
- 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 gibt den Namen der Datenbankinstanz-ID zurück. Wählen Sie den verschlüsselten Datenbanknamen aus, den wir gerade erstellt haben.
aws rds describe-db-instances --region <region-name> --query 'DBInstances[*].DBInstanceIdentifier'
- Führen Sie den Befehl
describe-db-instances
noch einmal mit der zuvor zurückgegebenen RDS-Instanzkennzeichnung aus, um festzustellen, ob die ausgewählte Datenbankinstanz verschlüsselt ist. Die Befehlsausgabe sollte den VerschlüsselungsstatusTrue
zurückgeben.
aws rds describe-db-instances --region <region-name> --db-instance-identifier <DB-Name-Encrypted> --query 'DBInstances[*].StorageEncrypted'
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denEncryption Enabled Efs File Systems
Kategoriename in der API: ENCRYPTION_ENABLED_EFS_FILE_SYSTEMS
EFS-Daten sollten im inaktiven Zustand 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 beheben:AWS-Konsole
- Melden Sie sich bei der AWS Management Console an und gehen Sie zum
Elastic File System (EFS)
-Dashboard. - Wählen Sie im linken Navigationsbereich
File Systems
aus. - Klicken Sie im Hauptmenü des Dashboards auf die Schaltfläche
Create File System
, um die Einrichtung des Dateisystems zu starten. -
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.
– Klicken Sie im Abschnitt „Bereitstellungsziele erstellen“ die Kästchen für alle Verfügbarkeitszonen (Verfügbarkeitszonen) in der ausgewählten VPC an. Dies sind Ihre Bereitstellungsziele.
- Klicken Sie aufNext step
, um fortzufahren. -
Führen Sie auf der Seite
Configure optional settings
folgende Schritte aus.
– Erstellen Sietags
, um das neue Dateisystem zu beschreiben.
– Wählen Sieperformance mode
aus.
– Klicken Sie auf das KästchenEnable encryption
und wählen Sie in der Drop-down-Liste „KMS-Masterschlüssel auswählen“ die Optionaws/elasticfilesystem
aus, um die Verschlüsselung für das neue Dateisystem mit dem von AWS KMS bereitgestellten und verwalteten Standard-Masterschlüssel zu aktivieren.
- Klicken Sie aufNext step
, um fortzufahren. -
Prüfen Sie die Konfigurationsdetails des Dateisystems auf der Seite
review and create
und klicken Sie dann aufCreate File System
, um Ihr neues AWS EFS-Dateisystem zu erstellen. - Kopieren Sie die Daten aus dem alten unverschlüsselten EFS-Dateisystem in das neu erstellte verschlüsselte Dateisystem.
- Entfernen Sie das unverschlüsselte Dateisystem, sobald die Datenmigration zum neu erstellten verschlüsselten Dateisystem abgeschlossen ist.
- Ändern Sie die AWS-Region über die 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 Konfigurationsinformationen zu beschreiben, die für das ausgewählte (unverschlüsselte) Dateisystem verfügbar sind. Informationen zur Ermittlung der richtigen Ressource finden Sie im Abschnitt „Audit“.
aws efs describe-file-systems --region <region> --file-system-id <file-system-id from audit section step 2 output>
- Die Befehlsausgabe sollte die angeforderten Konfigurationsinformationen zurückgeben.
- Wenn Sie ein neues AWS EFS-Dateisystem bereitstellen möchten, müssen Sie eine UUID (Universally Unique Identifier) 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.
- Führen Sie den Befehl create-file-system mit dem eindeutigen Token aus, das im vorherigen Schritt erstellt wurde.
aws efs create-file-system --region <region> --creation-token <Token (randomly generated UUID from step 3)> --performance-mode generalPurpose --encrypted
- Die Befehlsausgabe sollte die Metadaten der neuen Dateisystemkonfiguration zurückgeben.
- Führen Sie den Befehl create-mount-target mit der neu erstellten EFS-Dateisystem-ID aus, die im vorherigen Schritt als Kennung zurückgegeben wurde, und der ID der Verfügbarkeitszone (AZ), die das Bereitstellungsziel darstellt:
aws efs create-mount-target --region <region> --file-system-id <file-system-id> --subnet-id <subnet-id>
- Die Befehlsausgabe sollte die neuen Metadaten des Bereitstellungsziels zurückgeben.
- Jetzt können Sie das Dateisystem aus einer EC2-Instanz bereitstellen.
- Kopieren Sie die Daten aus dem alten unverschlüsselten EFS-Dateisystem in das neu erstellte verschlüsselte Dateisystem.
- Entfernen Sie das unverschlüsselte Dateisystem, sobald die Datenmigration zum neu erstellten verschlüsselten Dateisystem abgeschlossen ist.
aws efs delete-file-system --region <region> --file-system-id <unencrypted-file-system-id>
- Ändern Sie die AWS-Region, indem Sie --region aktualisieren. Wiederholen Sie anschließend den gesamten Vorgang für andere AWS-Regionen.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denIam Password Policy
Kategoriename in der API: IAM_PASSWORD_POLICY
AWS ermöglicht benutzerdefinierte Passwortrichtlinien in Ihrem 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 die IAM-Nutzerpasswörter der AWS-Standard-Passwortrichtlinie entsprechen. In den Best Practices für die AWS-Sicherheit werden die folgenden Anforderungen an die Komplexität von Passwörtern empfohlen:
- Das Passwort muss mindestens einen Großbuchstaben enthalten.
- Passwörter müssen mindestens einen Kleinbuchstaben enthalten.
- Passwörter müssen mindestens ein Symbol enthalten.
- Legen Sie fest, dass mindestens eine Zahl in Passwörtern erforderlich ist.
- Verlangen Sie eine Mindestpasswortlänge von mindestens 14 Zeichen.
- Sie benötigen vor der Wiederverwendung mindestens 24 Passwörter.
- Legen Sie fest, dass vor dem Ablauf des Passworts mindestens 90 Zeichen erforderlich sind
Mit dieser Einstellung werden alle angegebenen Anforderungen der Passwortrichtlinie geprüft.
Empfehlung: Prüft, ob die Richtlinie für Kontopasswörter für IAM-Nutzer die angegebenen Anforderungen erfüllt Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben: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
So erstellen Sie eine benutzerdefinierte Passwortrichtlinie:
- Melden Sie sich in der AWS Management Console an und öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
- Wählen Sie im Navigationsbereich die Option „Kontoeinstellungen“ aus.
- Wählen Sie im Abschnitt „Passwortrichtlinie“ die Option „Passwortrichtlinie ändern“ aus.
- Wählen Sie die Optionen aus, die Sie auf Ihre Passwortrichtlinie anwenden möchten, und wählen Sie „Änderungen speichern“ aus.
So ändern Sie eine benutzerdefinierte Passwortrichtlinie:
- Melden Sie sich in der AWS Management Console an und öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
- Wählen Sie im Navigationsbereich die Option „Kontoeinstellungen“ aus.
- Wählen Sie im Abschnitt „Passwortrichtlinie“ die Option „Ändern“ aus.
- Wählen Sie die Optionen aus, die Sie auf Ihre Passwortrichtlinie anwenden möchten, und wählen Sie „Änderungen speichern“ aus.
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
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denIam Password Policy Prevents Password Reuse
Kategoriename in der API: IAM_PASSWORD_POLICY_PREVENTS_PASSWORD_REUSE
IAM-Passwortrichtlinien können die Wiederverwendung eines bestimmten Passworts durch denselben Nutzer verhindern. Es wird empfohlen, die Wiederverwendung von Passwörtern durch die Passwortrichtlinie zu verhindern.
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 beheben:AWS-Konsole
- In der AWS-Konsole anmelden (mit den entsprechenden Berechtigungen zum Ansehen der Kontoeinstellungen für Identity Access Management)
- Zum IAM-Dienst in der AWS-Konsole
- Klicken Sie im linken Bereich auf Kontoeinstellungen .
- Klicken Sie das Kästchen „Wiederverwendung von Passwörtern verhindern“ an.
- „Anzahl der zu merkenden Passwörter“ auf
24
festgelegt
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.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denIam Password Policy Requires Minimum Length 14 Greater
Kategoriename in der API: IAM_PASSWORD_POLICY_REQUIRES_MINIMUM_LENGTH_14_GREATER
Passwortrichtlinien werden teilweise verwendet, um Anforderungen an die Komplexität von Passwörtern durchzusetzen. Mit IAM-Passwortrichtlinien können Sie dafür sorgen, dass Passwörter mindestens eine bestimmte Länge haben. Die Passwortrichtlinie sollte eine Mindestpasswortlänge von 14 Zeichen voraussetzen.
Empfehlung: Achten Sie darauf, dass die IAM-Passwortrichtlinie eine Mindestlänge von 14 Zeichen erfordert Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben:AWS-Konsole
- In der AWS-Konsole anmelden (mit den entsprechenden Berechtigungen zum Ansehen der Kontoeinstellungen für Identity Access Management)
- Zum IAM-Dienst in der AWS-Konsole
- Klicken Sie im linken Bereich auf Kontoeinstellungen .
- Legen Sie für „Minimale Passwortlänge“ mindestens
14
fest. - 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.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denIam 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 standardmäßige Sicherheitsempfehlung, die geringste Berechtigung zu gewähren, also nur die Berechtigungen zu gewähren, die zum Ausführen einer Aufgabe erforderlich sind. Bestimmen Sie, was Nutzer tun müssen, und erstellen Sie dann Richtlinien, mit denen Nutzer nur diese Aufgaben ausführen können, anstatt vollständige Administratorberechtigungen zu erteilen.
Empfehlung: Achten Sie darauf, dass keine IAM-Richtlinien zugewiesen sind, die vollständige „*:*“-Administratorberechtigungen zulassen Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben:AWS-Konsole
Führen Sie die folgenden Schritte aus, um die Richtlinie zu trennen, die über volle Administratorberechtigungen verfügt:
- Melden Sie sich in der AWS Management Console an und öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
- Klicken Sie im Navigationsbereich auf „Richtlinien“ und suchen Sie dann nach dem Richtliniennamen aus dem Audit-Schritt.
- Wählen Sie die Richtlinie aus, die gelöscht werden soll.
- Wähle im Aktionsmenü für Richtlinien die erste
Detach
aus - Alle Nutzer, Gruppen und Rollen auswählen, denen diese Richtlinie zugeordnet ist
- Klicken Sie auf
Detach Policy
. - Wählen Sie im Aktionsmenü für Richtlinien die Option
Detach
aus.
AWS-CLI
Führen Sie die folgenden Schritte aus, um die Richtlinie zu trennen, die vollständige Administratorberechtigungen hat, wie im Audit-Schritt beschrieben:
- Listet alle IAM-Nutzer, Gruppen und Rollen auf, mit denen die angegebene verwaltete Richtlinie verknüpft ist.
aws iam list-entities-for-policy --policy-arn <policy_arn>
- Trennen Sie die Richtlinie von allen IAM-Nutzern:
aws iam detach-user-policy --user-name <iam_user> --policy-arn <policy_arn>
- Trennen Sie die Richtlinie von allen IAM-Gruppen:
aws iam detach-group-policy --group-name <iam_group> --policy-arn <policy_arn>
- Trennen Sie die Richtlinie von allen IAM-Rollen:
aws iam detach-role-policy --role-name <iam_role> --policy-arn <policy_arn>
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denIam 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) Sie können die Nutzerrichtlinie direkt (auch als Inline-Richtlinie oder Nutzerrichtlinie bezeichnet) bearbeiten, 2) eine Richtlinie direkt mit einem Nutzer verknüpfen, 3) den Nutzer einer IAM-Gruppe mit einer verknüpften Richtlinie hinzufügen und 4) den Nutzer einer IAM-Gruppe mit einer Inline-Richtlinie hinzufügen.
Es wird nur die dritte Implementierung empfohlen.
Empfehlung: Achten Sie darauf, dass IAM-Nutzer Berechtigungen nur über Gruppen erhaltenSo erstellen Sie eine IAM-Gruppe und weisen ihr eine Richtlinie zu:
- Melden Sie sich in der AWS Management Console an und öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
- Klicken Sie im Navigationsbereich auf
Groups
und dann aufCreate New Group
. - Geben Sie im Feld
Group Name
den Namen der Gruppe ein und klicken Sie dann aufNext Step
. - Klicken Sie in der Liste der Richtlinien das Kästchen für jede Richtlinie an, die Sie auf alle Mitglieder der Gruppe anwenden möchten. Klicken Sie dann auf
Next Step
. - Klicken Sie auf
Create Group
.
So fügen Sie einen Nutzer zu einer bestimmten Gruppe hinzu:
- Melden Sie sich in der AWS Management Console an und öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
- Klicken Sie im Navigationsbereich auf
Groups
. - Gruppe auswählen, der ein Nutzer hinzugefügt werden soll
- Klicken Sie auf
Add Users To Group
. - Nutzer auswählen, die der Gruppe hinzugefügt werden sollen
- Klicken Sie auf
Add Users
.
So entfernen Sie eine direkte Verknüpfung zwischen einem Nutzer und einer Richtlinie:
- Melden Sie sich in der AWS Management Console an und öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
- Klicken Sie im linken Navigationsbereich auf „Nutzer“.
- Für jeden Nutzer:
– Wählen Sie den Nutzer aus.
– Klicken Sie auf den TabPermissions
.
– Maximieren SiePermissions policies
.
– Klicken Sie für jede Richtlinie aufX
und dann auf „Trennen“ oder „Entfernen“ (je nach Richtlinientyp).
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denIam User Group Membership Check
Kategoriename in der API: IAM_USER_GROUP_MEMBERSHIP_CHECK
IAM-Nutzer sollten immer Teil einer IAM-Gruppe sein, um die Best Practices für die IAM-Sicherheit einzuhalten.
Durch das Hinzufügen von Nutzern zu einer Gruppe können Richtlinien für verschiedene Nutzertypen freigegeben werden.
Empfehlung: Prüft, ob IAM-Nutzer Mitglieder von mindestens einer IAM-Gruppe sind Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben: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, löscht IAM automatisch die folgenden Informationen für Sie:
- Der Nutzer
- Beliebige Mitgliedschaften in Nutzergruppen, d. h., der Nutzer wird aus allen IAM-Nutzergruppen entfernt, in denen er Mitglied war
- Jedes mit dem Nutzer verknüpfte Passwort
- Alle Zugriffsschlüssel des Nutzers
- Alle in den Nutzer eingebetteten Inline-Richtlinien. Richtlinien, die über Berechtigungen für Nutzergruppen auf einen Nutzer angewendet werden, sind nicht betroffen.
So löschen Sie einen IAM-Nutzer:
- Melden Sie sich in der AWS Management Console an und öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
- Wählen Sie im Navigationsbereich Benutzer und dann das Kontrollkästchen neben dem Benutzernamen, den Sie löschen möchten.
- Wählen Sie oben auf der Seite Löschen aus.
- Geben Sie im Bestätigungsdialogfeld den Nutzernamen in das Texteingabefeld ein, um das Löschen des Nutzers zu bestätigen.
- Wählen Sie Löschen aus.
So fügen Sie einer IAM-Nutzergruppe einen Nutzer hinzu:
- Melden Sie sich in der AWS Management Console an und öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
- Klicken Sie im Navigationsbereich auf Nutzergruppen und dann auf den Namen der Gruppe.
- Wählen Sie den Tab „Nutzer“ und dann „Nutzer hinzufügen“ aus. Klicken Sie die Kästchen neben den Nutzern an, die Sie hinzufügen möchten.
- Wählen Sie „Nutzer hinzufügen“ aus.
AWS-CLI
Anders als bei der Amazon Web Services-Verwaltungskonsole müssen Sie beim programmatischen Löschen eines Nutzers die mit dem Nutzer verknüpften Elemente manuell löschen. Andernfalls schlägt der Löschvorgang fehl.
Entfernen Sie die folgenden Elemente, bevor Sie versuchen, einen Nutzer zu löschen:
- Passwort ( DeleteLoginProfile )
- Zugriffsschlüssel ( DeleteAccessKey )
- Signaturzertifikat ( DeleteSigningCertificate )
- Öffentlicher SSH-Schlüssel ( DeleteSSHPublicKey )
- Git-Anmeldedaten ( DeleteServiceSpecificCredential )
- MFA-Gerät (Multi-Faktor-Authentifizierung) ( DisableMFADevice , DeleteVirtualMFADevice )
- Inline-Richtlinien ( DeleteUserPolicy )
- Angehängte verwaltete Richtlinien ( DetachUserPolicy )
- Gruppenmitgliedschaften ( RemoveUserFromGroup)
So löschen Sie einen Nutzer nach dem Löschen aller mit ihm verknüpften Elemente:
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"
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denIam User Mfa Enabled
Kategoriename in der API: IAM_USER_MFA_ENABLED
Die Multi-Faktor-Authentifizierung (MFA) ist eine Best Practice, bei der Nutzernamen und Passwörter zusätzlich geschützt werden. Wenn sich ein Nutzer bei der MFA in der AWS-Verwaltungskonsole anmeldet, muss er einen zeitkritischen Authentifizierungscode angeben, der von einem registrierten virtuellen oder physischen Gerät bereitgestellt wird.
Empfehlung: Prüft, ob für AWS IAM-Nutzer die Multi-Faktor-Authentifizierung (MFA) aktiviert ist Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben:Terraform
Wenn es um Terraform geht, gibt es mehrere Möglichkeiten, das Fehlen von MFA-Geräten zu beheben. Sie haben wahrscheinlich bereits eine sinnvolle Struktur zum Organisieren Ihrer Nutzer in Gruppen und restriktiven Richtlinien.
Das folgende Beispiel zeigt, wie Sie:
- Nutzer erstellen
- Erstellen Sie Anmeldeprofile von Nutzern mit einem öffentlichen PGP-Schlüssel.
- Erstellen Sie Gruppen- und Gruppenrichtlinien, die die Selbstverwaltung von IAM-Profilen ermöglichen.
- Nutzer an Gruppe anhängen.
- Virtuelle MFA-Geräte für Nutzer erstellen
- Stellen Sie jedem Nutzer den QR-Code und das Passwort für die Ausgabe zur Verfügung.
variable "users" {
type = set(string)
default = [
"test@example.com",
"test2@example.com"
]
}
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 {"test@example.com": <PGPEncryptedPassword>, "test2@example.com": <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 {"test@example.com": <QRCode>, "test2@example.com": <QRCode>}
value = { for k, v in aws_iam_virtual_mfa_device.test_mfa : k => v.qr_code_png }
}
AWS-Konsole
Informationen zum Aktivieren von MFA für Nutzerkonten mit Zugriff auf die AWS-Konsole finden Sie unter Aktivieren eines virtuellen Multi-Faktor-Authentifizierungsgeräts (MFA) (Konsole) in der AWS-Dokumentation.
AWS-CLI
MFA-Gerät erstellen
aws iam create-virtual-mfa-device \
--virtual-mfa-device-name "test@example.com" \
--outfile ./QRCode.png \
--bootstrap-method QRCodePNG
MFA-Gerät für vorhandenen Nutzer aktivieren
aws iam enable-mfa-device \
--user-name "test@example.com" \
--serial-number "arn:aws:iam::123456976749:mfa/test@example.com" \
--authentication-code1 123456 \
--authentication-code2 654321
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denIam User Unused Credentials Check
Kategoriename in der API: IAM_USER_UNUSED_CREDENTIALS_CHECK
Damit wird nach IAM-Passwörtern oder aktiven Zugriffschlüsseln gesucht, die in den letzten 90 Tagen nicht verwendet wurden.
In den Best Practices wird empfohlen, alle Anmeldedaten zu entfernen, zu deaktivieren oder zu rotieren, die 90 Tage oder länger nicht verwendet wurden. So können Anmeldedaten, die mit einem manipulierten oder nicht mehr genutzten Konto verknüpft sind, schneller verwendet werden.
Empfehlung: Prüft, ob alle AWS IAM-Nutzer Passwörter oder aktive Zugriffsschlüssel haben, die in den unter „maxCredentialUsageAge“ angegebenen Tagen nicht verwendet wurden (Standardeinstellung: 90) Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben:Terraform
Wenn Sie abgelaufene Zugriffsschlüssel entfernen möchten, die über Terraform erstellt wurden, entfernen Sie die Ressource aws_iam_access_key
aus Ihrem Modul und wenden Sie die Änderung an.
Verwenden Sie zum Zurücksetzen eines IAM-Passworts für die Nutzeranmeldung das -replace
beim Ausführen von terraform apply
.
Angenommen das folgende Anmeldeprofil des Nutzers
resource "aws_iam_user" "example" {
name = "test@example.com"
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 für das Anmeldeprofil des Nutzers zurückzusetzen.
terraform apply -replace="aws_iam_user_login_profile.example"
AWS-Konsole
So deaktivieren Sie Anmeldedaten für inaktive Konten:
- Öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
- Wählen Sie „Nutzer“ aus.
- Wählen Sie den Namen des Nutzers aus, dessen Anmeldedaten älter als 90 Tage bzw. die zuletzt verwendeten Anmeldedaten sind.
- Wählen Sie Sicherheitsanmeldedaten aus.
- Wählen Sie für alle Anmeldedaten und Zugriffsschlüssel, die mindestens 90 Tage lang nicht verwendet wurden, die Option „Inaktiv“ aus.
So fordern Sie von Konsolennutzern bei der nächsten Anmeldung ein neues Passwort an:
- Öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
- Wählen Sie „Nutzer“ aus.
- Wählen Sie den Namen des Nutzers aus, dessen Anmeldedaten älter als 90 Tage bzw. die zuletzt verwendeten Anmeldedaten sind.
- Wählen Sie Sicherheitsanmeldedaten aus.
- Wählen Sie unter „Anmeldedaten und Konsolenpasswort“ die Option „Verwalten“ aus.
- Legen Sie ein neues Passwort fest (automatisch generiert oder benutzerdefiniert).
- Aktivieren Sie das Kontrollkästchen "Zurücksetzen des Passworts verlangen".
- Wählen Sie „Anwenden“ 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>
So setzen Sie das Passwort für das Anmeldeprofil eines Nutzers zurück:
aws iam update-login-profile \
--user-name "test@example.com" \
--password <temporary_password> \
--password-reset-required
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denKms 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 vorgemerkt sind. Die Kontrolle schlägt fehl, wenn ein KMS-Schlüssel zum Löschen vorgemerkt ist.
KMS-Schlüssel können nach dem Löschen nicht wiederhergestellt werden. Daten, die mit einem KMS-Schlüssel verschlüsselt wurden, sind auch dauerhaft nicht wiederherstellbar, wenn der KMS-Schlüssel gelöscht wird. Wenn wichtige Daten mit einem KMS-Schlüssel verschlüsselt wurden, der zum Löschen vorgemerkt ist, sollten Sie die Daten entschlüsseln oder unter einem neuen KMS-Schlüssel neu verschlüsseln, es sei denn, Sie führen absichtlich eine kryptografische Löschung durch.
Wenn ein KMS-Schlüssel zum Löschen vorgemerkt ist, wird eine obligatorische Wartezeit erzwungen, damit das Löschen rückgängig gemacht werden kann, falls der Löschvorgang irrtümlich geplant wurde. Die standardmäßige Wartezeit beträgt 30 Tage, kann aber auf bis zu 7 Tage reduziert werden, wenn der KMS-Schlüssel zum Löschen vorgemerkt ist. Während der Wartezeit kann das geplante Löschen abgebrochen werden und der KMS-Schlüssel wird nicht gelöscht.
Weitere Informationen zum Löschen von KMS-Schlüsseln finden Sie unter KMS-Schlüssel löschen im AWS Key Management Service-Entwicklerhandbuch.
Empfehlung: Prüft, ob alle CMKs nicht zum Löschen geplant sindInformationen zum Abbrechen eines geplanten Löschens von KMS-Schlüsseln finden Sie im AWS Key Management Service-Entwicklerleitfaden unter Schlüssellöschung planen und abbrechen (Konsole).
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denLambda Concurrency Check
Kategoriename in der API: LAMBDA_CONCURRENCY_CHECK
Prüft, ob für die Lambda-Funktion ein Limit für die gleichzeitige Ausführung auf Funktionsebene konfiguriert ist. Die Regel ist NON_COMPLIANT, wenn die Lambda-Funktion nicht mit einem Limit für die gleichzeitige Ausführung auf Funktionsebene konfiguriert ist.
Empfehlung: Prüft, ob für Lambda-Funktionen das Limit für die gleichzeitige Ausführung auf Funktionsebene konfiguriert istInformationen zum Konfigurieren eines Limits für die gleichzeitige Ausführung auf Funktionsebene finden Sie in der AWS Lambda-Dokumentation unter Reservierte Nebenläufigkeit konfigurieren.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denLambda Dlq Check
Kategoriename in der API: LAMBDA_DLQ_CHECK
Prüft, ob eine Lambda-Funktion mit einer Dead-Letter-Warteschlange konfiguriert ist. Die Regel ist NON_COMPLIANT, wenn die Lambda-Funktion nicht mit einer Dead-Letter-Warteschlange konfiguriert ist.
Empfehlung: Prüft, ob Lambda-Funktionen mit einer Dead-Letter-Warteschlange konfiguriert sindInformationen zum Aktualisieren von Lambda-Funktionen zur Verwendung von DLQs finden Sie in der AWS-Dokumentation unter Dead-Letter-Warteschlangen.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denLambda Function Public Access Prohibited
Kategoriename in der API: LAMBDA_FUNCTION_PUBLIC_ACCESS_PROHIBITED
In den Best Practices von AWS wird empfohlen, die Lambda-Funktion nicht öffentlich zugänglich zu machen. Mit dieser Richtlinie werden alle Lambda-Funktionen geprüft, die in allen aktivierten Regionen in Ihrem Konto bereitgestellt werden. Sie schlägt fehl, wenn sie den öffentlichen Zugriff nicht zulassen.
Empfehlung: Prüft, ob die an die Lambda-Funktion angehängte Richtlinie den öffentlichen Zugriff verhindert Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben:Terraform
Das folgende Beispiel enthält ein Beispiel für die Verwendung von Terraform zur Bereitstellung einer IAM-Rolle, die den Zugriff auf eine Lambda-Funktion einschränkt und diese Rolle der Lambda-Funktion hinzufügt
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 dieses Steuerelement bei einer Lambda-Funktion fehlschlägt, wird angegeben, dass die ressourcenbasierte Richtlinienanweisung 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 Console zum Prüfen der Richtlinie und über die AWS-Befehlszeilenschnittstelle verwendet, um die Berechtigungen zu entfernen.
So rufen Sie die ressourcenbasierte Richtlinie für eine Lambda-Funktion auf:
- Öffnen Sie die AWS Lambda-Konsole unter https://console.aws.amazon.com/lambda/.
- Wählen Sie im Navigationsbereich „Funktionen“ aus.
- Wählen Sie die Funktion aus.
- Wählen Sie „Berechtigungen“ aus. Die ressourcenbasierte Richtlinie zeigt die Berechtigungen, die angewendet werden, wenn ein anderes Konto oder AWS-Dienst versucht, auf die Funktion zuzugreifen.
- Sehen Sie sich die ressourcenbasierte Richtlinie an.
- Ermitteln Sie die Richtlinienanweisung, die die Feldwerte für das Hauptkonto enthält, die die Richtlinie veröffentlichen. Beispiel:
"*"
oder{ "AWS": "*" }
zulassen.
Sie können die Richtlinie nicht über die Console bearbeiten. Verwenden Sie den Befehl remove-permission aus der AWS-Befehlszeile, um Berechtigungen aus der Funktion zu entfernen.
Notieren Sie sich den Wert der Anweisungs-ID (Sid) für die Anweisung, die Sie entfernen möchten.
AWS-CLI
Wenn Sie über die Befehlszeile Berechtigungen aus einer Lambda-Funktion entfernen möchten, führen Sie den Befehl remove-permission
so aus:
aws lambda remove-permission \
--function-name <value> \
--statement-id <value>
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denLambda Inside Vpc
Kategoriename in der API: LAMBDA_INSIDE_VPC
Prüft, ob sich eine Lambda-Funktion in einer VPC befindet. Möglicherweise werden fehlgeschlagene Ergebnisse für Lambda@Edge-Ressourcen angezeigt.
Die Konfiguration des VPC-Subnetz-Routings wird nicht ausgewertet, um die öffentliche Erreichbarkeit zu bestimmen.
Empfehlung: Prüft, ob die Lambda-Funktionen in einer VPC vorhanden sind Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben:AWS-Konsole
So konfigurieren Sie eine Funktion zum Herstellen einer Verbindung zu privaten Subnetzen in einer Virtual Private Cloud (VPC) in Ihrem Konto:
- Öffnen Sie die AWS Lambda-Konsole unter https://console.aws.amazon.com/lambda/.
- Gehen Sie zu „Funktionen“ und wählen Sie die Lambda-Funktion aus.
- Scrollen Sie zu „Netzwerk“ und wählen Sie eine VPC mit den Konnektivitätsanforderungen der Funktion aus.
- Zum Ausführen Ihrer Funktionen im Hochverfügbarkeitsmodus empfiehlt Security Hub, dass Sie mindestens zwei Subnetze auswählen.
- Wählen Sie mindestens eine Sicherheitsgruppe aus, die die Konnektivitätsanforderungen der Funktion hat.
- Wählen Sie „Speichern“ aus.
Weitere Informationen finden Sie im Abschnitt zum Konfigurieren einer Lambda-Funktion für den Zugriff auf Ressourcen in einer VPC im AWS Lambda-Entwicklerhandbuch.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denMfa Delete Enabled S3 Buckets
Kategoriename in der API: MFA_DELETE_ENABLED_S3_BUCKETS
Sobald MFA Delete für Ihren vertraulichen und klassifizierten S3-Bucket aktiviert ist, müssen Nutzer zwei Authentifizierungsformen haben.
Empfehlung: Achten Sie darauf, dass MFA-Löschungen für S3-Buckets aktiviert sindFühren Sie die folgenden Schritte aus, um die MFA-Löschung für einen S3-Bucket zu aktivieren.
Hinweis:
– Sie können 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:
- 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”
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denMfa Enabled Root User Account
Kategoriename in der API: MFA_ENABLED_ROOT_USER_ACCOUNT
Das Root-Nutzerkonto ist der Nutzer mit den meisten Berechtigungen in einem AWS-Konto. Mit der Multi-Faktor-Authentifizierung (MFA) wird der Nutzername und das Passwort zusätzlich geschützt. Wenn MFA aktiviert ist, wird ein Nutzer bei der Anmeldung auf einer AWS-Website aufgefordert, seinen Nutzernamen und sein Passwort sowie einen Authentifizierungscode von seinem AWS-MFA-Gerät einzugeben.
Hinweis: Wenn virtuelle MFA für Root-Konten verwendet wird, sollte das verwendete Gerät KEIN persönliches Gerät sein, sondern ein zweckbestimmtes Mobilgerät (Tablet oder Smartphone), das unabhängig von individuellen persönlichen Geräten verwaltet und geschützt wird. („nicht persönliche virtuelle MFA“) verringern das Risiko, den Zugriff auf die MFA zu verlieren, wenn ein Gerät verloren geht, ein Gerät eingetauscht wird oder die Person, die das Gerät besitzt, nicht mehr im Unternehmen beschäftigt ist.
Empfehlung: Achten Sie darauf, dass MFA für das Root-Nutzerkonto aktiviert istFühren Sie die folgenden Schritte aus, um eine MFA für das Root-Nutzerkonto einzurichten:
- Melden Sie sich in der AWS Management Console an und öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
Hinweis: Um MFA-Geräte für das AWS-Root-Konto zu verwalten, müssen Sie sich mit den Anmeldedaten Ihres Root-Kontos bei AWS anmelden. Sie können MFA-Geräte für das Root-Konto nicht mit anderen Anmeldedaten verwalten.
- Wählen Sie
Dashboard
aus und maximieren Sie unterSecurity Status
in Ihrem Root-KontoActivate MFA
. Activate MFA
auswählen- Wählen Sie im Assistenten
A virtual MFA
Gerät und dannNext Step
aus . - IAM generiert Konfigurationsinformationen für das virtuelle MFA-Gerät, einschließlich einer QR-Code-Grafik, und zeigt diese an. Die Grafik zeigt den „geheimen Konfigurationsschlüssel“, der auf Geräten, die keine QR-Codes unterstützen, manuell eingegeben werden kann.
- Öffnen Sie Ihre virtuelle MFA-Anwendung. Eine Liste der Anwendungen, 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 (ein neues virtuelles MFA-Gerät).
- Stellen Sie fest, 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 auf das Kamerasymbol oder eine Option, die der Option „Code scannen“ ähnelt, auswählen und den Code dann mit der Kamera des Geräts scannen.
- Wählen Sie im Assistenten zum Verwalten des MFA-Geräts die Option Geheimen Schlüssel für manuelle Konfiguration anzeigen aus und geben Sie den geheimen Konfigurationsschlüssel in Ihre MFA-Anwendung ein.
Wenn Sie fertig sind, beginnt das virtuelle MFA-Gerät, Einmalpasswörter zu generieren.
Geben Sie im Assistenten „MFA-Gerät verwalten“ 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 erstellt hat. Geben Sie dann das zweite Einmalpasswort in das Feld Authentication Code 2 (Authentifizierungscode 2) ein. Wählen Sie Virtuelle MFA zuweisen aus.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denMulti 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 zusätzliche Sicherheit bei der Authentifizierung, die über herkömmliche Anmeldedaten hinausgeht. Wenn MFA aktiviert ist, wird ein Nutzer bei der Anmeldung in der AWS-Konsole aufgefordert, seinen Nutzernamen und sein Passwort sowie einen Authentifizierungscode von seinem physischen oder virtuellen MFA-Token einzugeben. Es wird empfohlen, MFA für alle Konten zu aktivieren, die ein Konsolenpasswort haben.
Empfehlung: Achten Sie darauf, dass die Multi-Faktor-Authentifizierung (MFA) für alle IAM-Nutzer aktiviert ist, die ein Console-Passwort haben Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben:AWS-Konsole
- Melden Sie sich in der AWS Management Console an und öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
- Wählen Sie im linken Bereich
Users
aus. - Wählen Sie in der Liste
User Name
den Namen des gewünschten MFA-Nutzers aus. - Wählen Sie den Tab
Security Credentials
und dannManage MFA Device
aus. - Wählen Sie in der
Manage MFA Device wizard
die Option „Virtual MFA
“ und dann „Continue
“ aus.
IAM generiert Konfigurationsinformationen für das virtuelle MFA-Gerät, einschließlich einer QR-Code-Grafik, und zeigt diese an. Die Grafik zeigt den „geheimen Konfigurationsschlüssel“, der auf Geräten, die keine QR-Codes unterstützen, manuell eingegeben werden kann.
- Öffnen Sie Ihre virtuelle MFA-Anwendung. Eine Liste der Apps, die Sie zum Hosten virtueller MFA-Geräte verwenden können, finden Sie unter "Virtual MFA Applications" 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 (ein neues virtuelles MFA-Gerät).
- Stellen Sie fest, 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 auf das Kamerasymbol oder eine Option, die der Option „Code scannen“ ähnelt, auswählen und den Code dann mit der Kamera des Geräts scannen.
- Wählen Sie im Assistenten zum Verwalten des MFA-Geräts die Option Geheimen Schlüssel für manuelle Konfiguration anzeigen aus und geben Sie den geheimen Konfigurationsschlüssel in Ihre MFA-Anwendung ein.
Wenn Sie fertig sind, beginnt das virtuelle MFA-Gerät, Einmalpasswörter zu generieren.
-
Geben Sie in die
Manage MFA Device wizard
imMFA Code 1 box
denone-time password
ein, der derzeit auf dem virtuellen MFA-Gerät angezeigt wird. Warten Sie bis zu 30 Sekunden, bis das Gerät ein neues Einmalpasswort erstellt hat. Geben Sie dann die zweiteone-time password
in dasMFA Code 2 box
ein. -
Klicken Sie auf
Assign MFA
.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denNo 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 NACL-Funktion (Network Access Control List) bietet zustandslose Filterung des ein- und ausgehenden Netzwerktraffics zu AWS-Ressourcen. Es wird empfohlen, keine NACL uneingeschränkten eingehenden Zugriff auf Remote-Serververwaltungsports zu erlauben, z. B. SSH an Port 22
und RDP an Port 3389
, wobei entweder die Protokolle TDP (6), UDP (17) oder ALL (-1) verwendet werden.
AWS-Konsole
Gehen Sie so vor:
1. Melden Sie sich unter https://console.aws.amazon.com/vpc/home in der AWS-Verwaltungskonsole an.
2. Klicken Sie im linken Bereich auf Network ACLs
3. Führen Sie für jede Netzwerk-ACL, die Sie beheben möchten, folgende Schritte aus:
– Wählen Sie die Netzwerk-ACL aus.
– Klicken Sie auf den Tab Inbound Rules
.
– Klicken Sie auf Edit inbound rules
.
– Sie können entweder A) das Feld „Quelle“ in einen anderen Bereich als 0.0.0.0/0 ändern oder B) auf Delete
klicken, um die problematische Eingangsregel zu entfernen.
– Klicken Sie auf Save
.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denNo Root User Account Access Key Exists
Kategoriename in der API: NO_ROOT_USER_ACCOUNT_ACCESS_KEY_EXISTS
Das Root-Nutzerkonto 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 beheben:AWS-Konsole
- Melden Sie sich als Root in der AWS-Verwaltungskonsole an und öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam/.
- Klicken Sie rechts oben auf
<root_account>
und wählen Sie aus der Drop-down-ListeMy Security Credentials
aus. - Klicken Sie im Pop-out-Fenster auf
Continue to Security Credentials
. - Klicken Sie auf
Access Keys
(Access Key ID und Secret Access Key). - In der Spalte
Status
(falls aktive Schlüssel vorhanden sind) - Klicken Sie auf
Delete
. Hinweis: Gelöschte Schlüssel können nicht wiederhergestellt werden.
Hinweis: Auch wenn ein Schlüssel deaktiviert werden kann, wird dieser inaktive Schlüssel weiterhin im CLI-Befehl der Prüfung angezeigt. Dies kann dazu führen, dass ein Schlüssel fälschlicherweise als nicht konform gekennzeichnet wird.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denNo 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 bieten ein zustandsorientiertes Filtern des ein- und ausgehenden Netzwerktraffics zu AWS-Ressourcen. Es wird empfohlen, keine Sicherheitsgruppe zu erlauben, uneingeschränkten eingehenden Zugriff auf Remote-Serververwaltungsports zu erlauben, z. B. SSH an Port 22
und RDP an Port 3389
, wobei entweder die Protokolle TDP (6), UDP (17) oder ALL (-1) verwendet werden.
So implementieren Sie den vorgeschriebenen Status:
- Melden Sie sich unter https://console.aws.amazon.com/vpc/home in der AWS-Verwaltungskonsole an.
- Klicken Sie im linken Bereich auf
Security Groups
. - Führen Sie für jede Sicherheitsgruppe die folgenden Schritte aus:
- Sicherheitsgruppe auswählen
- Klicken Sie auf den Tab
Inbound Rules
. - Klicken Sie auf die Schaltfläche
Edit inbound rules
. - Zu bearbeitende oder zu entfernende Regeln identifizieren
- Sie können entweder A) das Feld „Quelle“ in einen anderen Bereich als 0.0.0.0/0 ändern oder B) auf
Delete
klicken, um die problematische Eingangsregel zu entfernen. - Klicken Sie auf
Save rules
.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denNo Security Groups Allow Ingress 0 Remote Server Administration
Kategoriename in der API: NO_SECURITY_GROUPS_ALLOW_INGRESS_0_REMOTE_SERVER_ADMINISTRATION
Sicherheitsgruppen bieten ein zustandsorientiertes Filtern des ein- und ausgehenden Netzwerktraffics zu AWS-Ressourcen. Keine Sicherheitsgruppe sollte uneingeschränkten eingehenden Zugriff auf Remote-Serververwaltungsports zulassen, z. B. SSH an Port 22
und RDP an Port 3389
.
So implementieren Sie den vorgeschriebenen Status:
- Melden Sie sich unter https://console.aws.amazon.com/vpc/home in der AWS-Verwaltungskonsole an.
- Klicken Sie im linken Bereich auf
Security Groups
. - Führen Sie für jede Sicherheitsgruppe die folgenden Schritte aus:
- Sicherheitsgruppe auswählen
- Klicken Sie auf den Tab
Inbound Rules
. - Klicken Sie auf die Schaltfläche
Edit inbound rules
. - Zu bearbeitende oder zu entfernende Regeln identifizieren
- Sie können entweder A) das Feld „Quelle“ in einen anderen Bereich als ::/0 ändern oder B) auf
Delete
klicken, um die problematische Eingangsregel zu entfernen - Klicken Sie auf
Save rules
.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denOne 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 Root-Nutzer des AWS-Kontos. Sie können Zugriffsschlüssel verwenden, um programmatische Anfragen an die AWS CLI oder AWS API zu signieren (direkt oder mithilfe des AWS SDK).
Empfehlung: Achten Sie darauf, dass für jeden einzelnen IAM-Nutzer nur ein aktiver Zugriffsschlüssel verfügbar ist Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben:AWS-Konsole
- Melden Sie sich in der AWS Management Console an und gehen Sie zum IAM-Dashboard unter
https://console.aws.amazon.com/iam/
. - Wählen Sie im linken Navigationsbereich
Users
aus. - Klicken Sie auf den IAM-Nutzernamen, den Sie untersuchen möchten.
- Wählen Sie auf der IAM-Nutzerkonfigurationsseite den Tab
Security Credentials
aus. - Wählen Sie im Abschnitt „
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. - Geben Sie im selben
Access Keys
-Abschnitt Ihre nicht betriebsbezogenen Zugriffsschlüssel (außer dem ausgewählten) an und deaktivieren Sie sie, indem Sie auf den Link „Make Inactive
“ klicken. - Wenn das Bestätigungsfeld
Change Key Status
angezeigt wird, klicken Sie aufDeactivate
, um den ausgewählten Schlüssel zu deaktivieren. - Wiederholen Sie die Schritte 3 bis 7 für jeden IAM-Nutzer in Ihrem AWS-Konto.
AWS-CLI
-
Verwenden Sie die in
Audit CLI
bereitgestellten Informationen zum IAM-Nutzer und -Zugriffsschlüssel und wählen Sie 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. -
Führen Sie den Befehl
update-access-key
unten mit dem IAM-Nutzernamen und den Schlüssel-IDs für den nicht operativen Zugriff aus, um die unnötigen Schlüssel zu deaktivieren. Ermitteln Sie im Abschnitt „Audit“ die unnötige 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>
- Führen Sie den
list-access-keys
-Audit-Befehl noch einmal für diesen IAM-Nutzer aus, um zu bestätigen, dass das ausgewählte Zugriffsschlüsselpaar erfolgreichdeactivated
wurde:
aws iam list-access-keys --user-name <user-name>
- Die Befehlsausgabe sollte die Metadaten für jeden Zugriffsschlüssel bereitstellen, der mit dem IAM-Nutzer verknüpft ist. Wenn die nicht betriebsfremden Schlüsselpaare
Status
aufInactive
gesetzt sind, wurde der Schlüssel erfolgreich deaktiviert und die IAM-Konfiguration für den Nutzerzugriff entspricht jetzt dieser Empfehlung.
- Wiederholen Sie die Schritte 1 bis 3 für jeden IAM-Nutzer in Ihrem AWS-Konto.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denPublic Access Given Rds Instance
Kategoriename in der API: PUBLIC_ACCESS_GIVEN_RDS_INSTANCE
Achten Sie darauf, dass in Ihrem AWS-Konto bereitgestellte RDS-Datenbankinstanzen unbefugten Zugriff einschränken, um Sicherheitsrisiken zu minimieren. Wenn Sie den Zugriff auf öffentlich zugängliche RDS-Datenbankinstanzen einschränken möchten, müssen Sie das Flag „Öffentlich zugänglich“ der Datenbank deaktivieren und die mit der Instanz verknüpfte VPC-Sicherheitsgruppe aktualisieren.
Empfehlung: Achten Sie darauf, dass RDS-Instanzen kein öffentlicher Zugriff gewährt wird Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben:AWS-Konsole
- Melden Sie sich in der AWS-Verwaltungskonsole an und gehen Sie zum RDS-Dashboard unter https://console.aws.amazon.com/rds/.
- Klicken Sie im Navigationsbereich im RDS-Dashboard auf
Databases
. - Wählen Sie die RDS-Instanz aus, die Sie aktualisieren möchten.
- Klicken Sie im oberen Menü des Dashboards auf
Modify
. - Klicken Sie im Bereich „Datenbankinstanz ändern“ im Abschnitt
Connectivity
aufAdditional connectivity configuration
und ändern Sie den Wert fürPublicly Accessible
in „Nicht öffentlich zugänglich“, um den öffentlichen Zugriff einzuschränken. Führen Sie die folgenden Schritte aus, um Subnetzkonfigurationen zu aktualisieren:
– Wählen Sie den TabConnectivity and security
aus und klicken Sie im AbschnittNetworking
auf den Wert des VPC-Attributs.
– Wählen Sie im unteren Bereich des VPC-Dashboards den TabDetails
aus und klicken Sie auf den Attributwert für die Konfiguration der Routingtabelle.
– Wählen Sie auf der Detailseite der Routentabelle im unteren Bereich des Dashboards den Tab „Routen“ aus und klicken Sie aufEdit routes
.
– Aktualisieren Sie auf der Seite „Routen bearbeiten“ das Ziel des Ziels, das aufigw-xxxxx
gesetzt ist, und klicken Sie aufSave
-Routen. - Klicken Sie im Bereich „DB-Instanz ändern“ auf
Continue
und führen Sie im Abschnitt „Änderungen planen“ je nach Ihren Anforderungen eine der folgenden Aktionen aus:
– Wählen Sie im nächsten geplanten Wartungsfenster „Übernehmen“ aus, um die Änderungen im nächsten geplanten Wartungsfenster automatisch anzuwenden.
– Wählen Sie „Sofort übernehmen“ aus, um die Änderungen sofort zu übernehmen. Mit dieser Option werden alle ausstehenden Änderungen so bald wie möglich asynchron angewendet, unabhängig von der Einstellung für das Wartungsfenster für diese RDS-Datenbankinstanz. Alle Änderungen, die in der Warteschlange für ausstehende Änderungen verfügbar sind, werden ebenfalls angewendet. Wenn für ausstehende Änderungen eine Ausfallzeit erforderlich ist, kann die Auswahl dieser Option zu unerwarteten Ausfallzeiten der Anwendung führen. - Wiederholen Sie die Schritte 3 bis 6 für jede RDS-Instanz, die in der aktuellen Region verfügbar ist.
- Ändern Sie die AWS-Region in der Navigationsleiste, um den Vorgang für andere Regionen zu wiederholen.
AWS-CLI
- Führen Sie den Befehl
describe-db-instances
aus, um alle IDs der RDS-Datenbanknamen aufzulisten, die in der ausgewählten AWS-Region verfügbar sind:
aws rds describe-db-instances --region <region-name> --query 'DBInstances[*].DBInstanceIdentifier'
- Die Befehlsausgabe sollte jede Datenbankinstanzkennung zurückgeben.
- Führen Sie den Befehl
modify-db-instance
aus, um die ausgewählte RDS-Instanzkonfiguration zu ändern. Verwenden Sie dann den folgenden Befehl, um das FlagPublicly Accessible
für die ausgewählten RDS-Instanzen zu deaktivieren. In diesem Befehl wird das Flag „apply-immediately“ verwendet. Wenn Sieto avoid any downtime --no-apply-immediately flag can be used
verwenden möchten:
aws rds modify-db-instance --region <region-name> --db-instance-identifier <db-name> --no-publicly-accessible --apply-immediately
- Die Befehlsausgabe sollte die
PubliclyAccessible
-Konfiguration unter den ausstehenden Werten anzeigen und zum angegebenen Zeitpunkt angewendet werden. - Das Aktualisieren des Internet Gateway-Ziels über die AWS-Befehlszeile wird derzeit nicht unterstützt. Verwenden Sie das Verfahren der AWS-Konsole, um Informationen zu Internet Gateway zu aktualisieren.
- Wiederholen Sie die Schritte 1 bis 5 für jede RDS-Instanz, die in der aktuellen Region bereitgestellt wird.
- Ändern Sie die AWS-Region mit dem Filter --region, um den Vorgang für andere Regionen zu wiederholen.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denRds Enhanced Monitoring Enabled
Kategoriename in der API: RDS_ENHANCED_MONITORING_ENABLED
Das erweiterte Monitoring bietet über einen in der Instanz installierten Agent Echtzeitmesswerte zum Betriebssystem, auf dem die RDS-Instanz ausgeführt wird.
Weitere Informationen finden Sie unter Betriebssystemmesswerte mit erweitertem Monitoring überwachen.
Empfehlung: Prüft, ob erweitertes Monitoring für alle RDS-Datenbankinstanzen aktiviert ist Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben:Terraform
Um dieses Problem zu beheben, aktivieren Sie das erweiterte Monitoring für Ihre RDS-Instanzen so:
Erstellen Sie eine IAM-Rolle für RDS:
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 AWS-verwaltete Richtlinie für erweitertes 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 Monitoringintervall und eine Monitoringrolle für die richtlinienwidrige RDS-Instanz, 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 erweitertes Monitoring 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. Führen Sie dazu auf der Seite „Datenbanken“ eine der folgenden Aktionen aus:
- Datenbankinstanz oder Multi-AZ-Datenbankcluster erstellen: Wählen Sie „Datenbank erstellen“ aus.
- Lesereplikat erstellen: Wählen Sie „Aktionen“ und dann „Lesereplikat erstellen“ aus.
- DB-Instanz oder Multi-AZ-Datenbankcluster ändern: Wählen Sie „Ändern“ aus.
So aktivieren oder deaktivieren Sie das erweiterte Monitoring in der RDS-Konsole:
- Scrollen Sie zu „Zusätzliche Konfiguration“.
- Wählen Sie unter „Monitoring“ die Option Erweitertes Monitoring für Ihre Datenbankinstanz oder das Lesereplikat aktivieren aus. Wählen Sie „Erweitertes Monitoring deaktivieren“ aus, um das erweiterte Monitoring zu deaktivieren.
- Legen Sie für das Attribut „Monitoring-Rolle“ die von Ihnen erstellte IAM-Rolle fest, damit Amazon RDS für Sie mit Amazon CloudWatch Logs kommunizieren kann, oder wählen Sie „Standard“ aus, damit RDS eine Rolle mit dem Namen „rds-monitoring-role“ für Sie erstellt.
- Legen Sie das Attribut „Detaillierungsgrad“ auf das Intervall in Sekunden zwischen Punkten fest, an denen Messwerte für Ihre Datenbankinstanz oder das Lesereplikat erfasst werden. Die Eigenschaft „Detaillierungsgrad“ kann auf einen der folgenden Werte festgelegt werden: 1, 5, 10, 15, 30 oder 60. Die RDS-Konsole wird alle 5 Sekunden am schnellsten aktualisiert. Wenn Sie den Detaillierungsgrad in der RDS-Konsole auf 1 Sekunde festlegen, werden nur alle fünf Sekunden aktualisierte Messwerte angezeigt. Sie können 1-sekündige Messwertaktualisierungen mithilfe von CloudWatch-Logs 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 erweitertes 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"
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denRds Instance Deletion Protection Enabled
Kategoriename in der API: RDS_INSTANCE_DELETION_PROTECTION_ENABLED
Das Aktivieren des Instanzlöschungsschutzes ist eine zusätzliche Schutzebene vor versehentlichem Löschen der Datenbank oder vor dem Löschen durch eine nicht autorisierte Entität.
Wenn der Löschschutz aktiviert ist, kann eine RDS-Datenbankinstanz nicht gelöscht werden. Bevor eine Löschanfrage erfolgreich sein kann, muss der Löschschutz deaktiviert werden.
Empfehlung: Prüft, ob für alle RDS-Instanzen der Löschschutz aktiviert ist Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben:Terraform
Um dies zu ändern, legen Sie deletion_protection
in der Ressource aws_db_instance
auf true
fest.
resource "aws_db_instance" "example" {
# ... other configuration ...
deletion_protection = true
}
AWS-Konsole
So aktivieren Sie den Löschschutz für eine RDS-Datenbankinstanz:
- Öffnen Sie die Amazon RDS-Konsole unter https://console.aws.amazon.com/rds/.
- Wählen Sie im Navigationsbereich „Datenbanken“ und dann die Datenbankinstanz aus, die Sie ändern möchten.
- Wählen Sie „Ändern“ aus.
- Wählen Sie unter Löschschutz die Option Löschschutz aktivieren aus.
- Wählen Sie „Weiter“ aus.
- Wählen Sie unter Planung von Änderungen aus, wann Änderungen angewendet werden sollen. Die Optionen sind „Während des nächsten geplanten Wartungsfensters anwenden“ oder „Sofort anwenden“.
- Wählen Sie „DB-Instanz ändern“ aus.
AWS-CLI
Dasselbe gilt für die AWS-Befehlszeile. Legen Sie --deletion-protection
wie unten fest.
aws rds modify-db-instance \
--db-instance-identifier = "test-rds" \
--deletion-protection
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denRds In Backup Plan
Kategoriename in der API: RDS_IN_BACKUP_PLAN
Mit dieser Prüfung wird bewertet, ob Amazon RDS DB-Instanzen durch einen Sicherungsplan abgedeckt sind. Diese Kontrolle schlägt fehl, wenn eine RDS-Datenbankinstanz nicht durch einen Sicherungsplan abgedeckt ist.
AWS Backup ist ein vollständig verwalteter Sicherungsdienst, der die Sicherung von Daten für alle AWS-Dienste zentralisiert und automatisiert. Mit AWS Backup können Sie Sicherungsrichtlinien, sogenannte Sicherungspläne, erstellen. 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 beheben:Terraform
Um dies zu beheben, legen Sie backup_retention_period
auf einen Wert größer als 7
in der Ressource aws_db_instance
fest.
resource "aws_db_instance" "example" {
# ... other Configuration ...
backup_retention_period = 7
}
AWS-Konsole
Um automatische Sicherungen sofort zu aktivieren
- Öffnen Sie die Amazon RDS-Konsole unter https://console.aws.amazon.com/rds/.
- Wählen Sie im Navigationsbereich Datenbanken und dann die Datenbankinstanz aus, die Sie ändern möchten.
- Wählen Sie „Ändern“ aus, um die Seite „Datenbankinstanz ändern“ zu öffnen.
- Wählen Sie unter „Aufbewahrungsdauer für Sicherung“ einen positiven Wert ungleich null aus, z. B. 30 Tage, und wählen Sie dann „Weiter“ aus.
- Wählen Sie den Abschnitt Planung von Änderungen aus und legen Sie fest, wann Änderungen angewendet werden sollen: Sie können die Änderungen im nächsten geplanten Wartungsfenster übernehmen oder die Option sofort übernehmen.
- Wählen Sie dann auf der Bestätigungsseite die Option DB-Instanz ändern aus, um Ihre Änderungen zu speichern und automatische Sicherungen zu aktivieren.
AWS-CLI
Dasselbe gilt für die AWS-Befehlszeile. Ändern Sie backup-retention-period
auf einen Wert größer als 0
(Standard), um automatische Sicherungen zu aktivieren.
aws rds modify-db-instance --db-instance-identifier "test-rds" --backup-retention-period 7
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denRds Logging Enabled
Kategoriename in der API: RDS_LOGGING_ENABLED
Dadurch wird geprüft, ob die folgenden Logs von Amazon RDS aktiviert und an CloudWatch gesendet werden.
Für RDS-Datenbanken sollten relevante Logs aktiviert sein. Das Datenbank-Logging bietet detaillierte Datensätze zu Anfragen an RDS. Datenbanklogs können bei Sicherheits- und Zugriffsaudits hilfreich sein und bei der Diagnose von Verfügbarkeitsproblemen helfen.
Empfehlung: Prüft, ob exportierte Logs für alle RDS-Datenbankinstanzen aktiviert sind Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben: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 Ressource aws_db_instance
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:
- Öffnen Sie die Amazon RDS-Konsole unter https://console.aws.amazon.com/rds/.
- Wählen Sie im Navigationsbereich „Parametergruppen“ aus.
- Wählen Sie „Parametergruppe erstellen“ aus.
- Wählen Sie in der Liste „Parametergruppenfamilie“ eine DB-Parametergruppenfamilie aus.
- Wählen Sie in der Typliste die Datenbankparametergruppe aus.
- Geben Sie unter „Gruppenname“ den Namen der neuen DB-Parametergruppe ein.
- Geben Sie unter „Beschreibung“ eine Beschreibung für die neue DB-Parametergruppe ein.
- Wählen Sie „Erstellen“ aus.
So erstellen Sie über die Console eine neue Optionsgruppe für das MariaDB-Logging
- Öffnen Sie die Amazon RDS-Konsole unter https://console.aws.amazon.com/rds/.
- Wählen Sie im Navigationsbereich Optionsgruppen aus.
- Wählen Sie „Gruppe erstellen“ aus.
- Geben Sie im Fenster „Optionsgruppe erstellen“ Folgendes an:
* Name: muss innerhalb Ihres AWS-Kontos eindeutig sein. Nur Buchstaben, Ziffern und Bindestriche.
* Beschreibung: Wird nur zu Anzeigezwecken verwendet.
* Engine: Wählen Sie Ihr Datenbankmodul aus.
* Hauptversion der Engine: Wählen Sie die Hauptversion des Datenbankmoduls aus. - Wählen Sie „Erstellen“ aus.
- Wählen Sie den Namen der soeben erstellten Optionsgruppe aus.
- Wählen Sie Option hinzufügen aus.
- Wählen Sie MARIADB_AUDIT_PLUGIN aus der Liste mit den Optionsnamen aus.
- Setzen Sie SERVER_AUDIT_EVENTS auf CONNECT, QUERY, TABLE, QUERY_DDL, QUERY_DML, QUERY_DCL.
- Wählen Sie Option hinzufügen aus.
So veröffentlichen Sie SQL Server DB-, Oracle DB- oder PostgreSQL-Logs von der AWS Management Console in CloudWatch-Logs
- Öffnen Sie die Amazon RDS-Konsole unter https://console.aws.amazon.com/rds/.
- Wählen Sie im Navigationsbereich Datenbanken aus.
- Wählen Sie die Datenbankinstanz aus, die Sie ändern möchten.
- Wählen Sie „Ändern“ aus.
- Wählen Sie unter „Logexporte“ alle Logdateien aus, um mit der Veröffentlichung in CloudWatch-Logs zu beginnen.
- Logexporte sind nur für Versionen des Datenbankmoduls verfügbar, die die Veröffentlichung in CloudWatch-Logs unterstützen.
- Wählen Sie „Weiter“ aus. Wählen Sie dann auf der Zusammenfassungsseite die Option „Datenbankinstanz ändern“ aus.
So wenden Sie eine neue DB-Parametergruppe oder DB-Optionsgruppe auf eine RDS-Datenbankinstanz an:
- Öffnen Sie die Amazon RDS-Konsole unter https://console.aws.amazon.com/rds/.
- Wählen Sie im Navigationsbereich Datenbanken aus.
- Wählen Sie die Datenbankinstanz aus, die Sie ändern möchten.
- Wählen Sie „Ändern“ aus.
- Ändern Sie unter „Datenbankoptionen“ nach Bedarf die DB-Parametergruppe und die DB-Optionsgruppe.
- Wenn Sie mit den Änderungen fertig sind, wählen Sie „Weiter“ aus. Prüfen Sie die Zusammenfassung der Änderungen.
- Wählen Sie Datenbankinstanz ändern aus, um die Änderungen zu speichern.
AWS-CLI
Rufen Sie die Engine-Familien ab und wählen Sie diejenige aus, die der DB-Instanz-Engine und -Version entspricht.
aws rds describe-db-engine-versions \
--query "DBEngineVersions[].DBParameterGroupFamily" \
--engine "mysql"
Erstellen Sie eine Parametergruppe entsprechend der Suchmaschine 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 gemäß DB Engine. In diesem Beispiel wird MySQL5.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 so, dass die Parameter entsprechend der Datenbank-Engine hinzugefügt werden. 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 so, dass sie die Parametergruppe verknüpft.
aws rds modify-db-instance \
--db-instance-identifier "test-rds" \
--db-parameter-group-name "rds-mysql-parameter-group"
Erstellen Sie zusätzlich für MariaDB eine Optionsgruppe, wie im Folgenden beschrieben.
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 Datenbankinstanz. Ändern Sie dazu die MariaDB-Instanz.
aws rds modify-db-instance \
--db-instance-identifier "rds-test-mariadb" \
--option-group-name "rds-mariadb-option-group"
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denRds Multi Az Support
Kategoriename in der API: RDS_MULTI_AZ_SUPPORT
RDS-Datenbankinstanzen sollten für mehrere Verfügbarkeitszonen (Availability Zones, AZs) konfiguriert sein. Dadurch wird die Verfügbarkeit der gespeicherten Daten sichergestellt. Multi-AZ-Bereitstellungen ermöglichen einen automatischen Failover bei Problemen mit der Verfügbarkeit der Verfügbarkeitszone und während der regelmäßigen RDS-Wartung.
Empfehlung: Prüft, ob die Hochverfügbarkeit für alle RDS-Datenbankinstanzen aktiviert ist Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben:Terraform
Um dies zu beheben, setzen Sie multi_az
in der Ressource aws_db_instance
auf „true“.
resource "aws_db_instance" "example" {
# ... other configuration ...
multi_az = true
}
AWS-Konsole
Mehrere Verfügbarkeitszonen für eine DB-Instanz aktivieren
- Öffnen Sie die Amazon RDS-Konsole unter https://console.aws.amazon.com/rds/.
- Wählen Sie im Navigationsbereich Datenbanken und dann die Datenbankinstanz aus, die Sie ändern möchten.
- Wählen Sie „Ändern“ aus. Die Seite "DB-Instanz ändern" wird angezeigt.
- Legen Sie unter „Instanzspezifikationen“ die Multi-AZ-Bereitstellung auf „Ja“ fest.
- Klicken Sie auf „Weiter“ und prüfen Sie dann die Zusammenfassung der Änderungen.
- Optional: Wählen Sie „Sofort übernehmen“ aus, um die Änderungen sofort zu übernehmen. Die Auswahl dieser Option kann in einigen Fällen zu einem Ausfall führen. Weitere Informationen finden Sie unter Verwendung der Einstellung „Sofort anwenden“ im Amazon RDS-Nutzerhandbuch.
- Überprüfen Sie Ihre Änderungen auf der Bestätigungsseite. Wenn sie korrekt sind, wählen Sie „Datenbankinstanz ändern“ aus, um Ihre Änderungen zu speichern.
AWS-CLI
Dasselbe gilt für die AWS-CLI. Aktivieren Sie die Multi-Az-Unterstützung, indem Sie die Option --multi-az
angeben.
modify-db-instance
--db-instance-identifier "test-rds" \
--multi-az
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denRedshift Cluster Configuration Check
Kategoriename in der API: REDSHIFT_CLUSTER_CONFIGURATION_CHECK
Dadurch wird nach wesentlichen Elementen eines Redshift-Clusters gesucht: Verschlüsselung ruhender Daten, Logging und Knotentyp.
Diese Konfigurationselemente sind für die Wartung eines sicheren und beobachtbaren Redshift-Clusters wichtig.
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 beheben: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
So aktivieren Sie Cluster-Audit-Logging
- Öffnen Sie die Amazon Redshift-Konsole unter https://console.aws.amazon.com/redshift/.
- Wählen Sie im Navigationsmenü „Cluster“ und dann den Namen des zu ändernden Clusters aus.
- Wählen Sie „Eigenschaften“ aus.
- Wählen Sie „Audit-Logging bearbeiten und bearbeiten“ aus.
- Setzen Sie „Audit-Logging konfigurieren“ auf „Aktivieren“, legen Sie den Logexporttyp auf „CloudWatch (empfohlen)“ fest und wählen Sie die zu exportierenden Logs aus.
Informationen zur Verwendung von AWS S3 zum Verwalten von Redshift-Audit-Logs finden Sie in der AWS-Dokumentation unter Redshift – Datenbank-Audit-Logging.
- Wähle „Änderungen speichern“ aus.
So ändern Sie die Datenbankverschlüsselung in einem Cluster:
- Melden Sie sich in der AWS-Verwaltungskonsole an und öffnen Sie die Amazon Redshift-Konsole unter https://console.aws.amazon.com/redshift/.
- Wählen Sie im Navigationsmenü „Cluster“ und dann den Cluster aus, dessen Verschlüsselung Sie ändern möchten.
- Wählen Sie „Eigenschaften“ aus.
- Wählen Sie Verschlüsselung bearbeiten und bearbeiten.
- Wählen Sie die zu verwendende 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
- KMS-Schlüssel erstellen und Schlüssel-ID abrufen
aws kms create-key \
--description "Key to encrypt Redshift Clusters"
- Cluster ändern
aws redshift modify-cluster \
--cluster-identifiers "test-redshift-cluster" \
--encrypted \
--kms-key-id <value>
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denRedshift Cluster Maintenancesettings Check
Kategoriename in der API: REDSHIFT_CLUSTER_MAINTENANCESETTINGS_CHECK
Automatische Upgrades der Hauptversion finden je nach Wartungsfenster statt
Empfehlung: Prüft, ob für alle Redshift-Cluster „allowVersionUpgrade“ aktiviert und „preferredMaintenanceWindow“ sowie „automatedSnapshotRetentionPeriod“ festgelegt sind Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben:Terraform
Diese Prüfung ist mit allen von Terraform bereitgestellten Standardwerten kompatibel. Prüfen Sie bei einem fehlerhaften Redshift-Cluster die Anforderungen und entfernen Sie die Standardüberschreibungen für die folgenden Attribute der Ressource aws_redshift_cluster
.
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
Beim Erstellen eines Redshift-Clusters über die AWS-Konsole sind die Standardwerte bereits mit diesem Steuerelement kompatibel.
Weitere Informationen finden Sie unter Cluster mit der Console verwalten.
AWS-CLI
So können Sie dieses Steuerelement mit der AWS-CLI ändern:
aws redshift modify-cluster \
--cluster-identifier "test-redshift-cluster" \
--allow-version-upgrade
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denRedshift Cluster Public Access Check
Kategoriename in der API: REDSHIFT_CLUSTER_PUBLIC_ACCESS_CHECK
Das PubliclyAccessible-Attribut der Amazon Redshift-Clusterkonfiguration gibt an, ob der Cluster öffentlich zugänglich ist. Wenn für den Cluster „PubliclyAccessible“ auf „true“ festgelegt ist, handelt es sich um eine mit dem Internet verbundene 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. Wenn Ihr Cluster nicht öffentlich zugänglich sein soll, sollte er nicht mit PubliclyAccessible auf „true“ konfiguriert werden.
Empfehlung: Prüft, ob Redshift-Cluster öffentlich zugänglich sind Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben:Terraform
Um dieses Steuerelement zu beheben, müssen Sie die Clusterressource für die rote Verschiebung ändern und publicly_accessible
auf false
festlegen. Der Standardwert ist true
.
resource "aws_redshift_cluster" "example" {
# ... other configuration ...
publicly_accessible = false
}
AWS-Konsole
So deaktivieren Sie den öffentlichen Zugriff auf einen Amazon Redshift-Cluster
- Öffnen Sie die Amazon Redshift-Konsole unter https://console.aws.amazon.com/redshift/.
- Wählen Sie im Navigationsmenü „Cluster“ und dann den Namen des Clusters mit der Sicherheitsgruppe aus, die geändert werden soll.
- Wähle „Aktionen“ und dann die Einstellung „Öffentlich zugängliche Einstellungen ändern“ aus.
- Wählen Sie unter „Zulassen, dass Instanzen und Geräte außerhalb der VPC eine Verbindung zu Ihrer Datenbank über den Clusterendpunkt herstellen“ die Option „Nein“ aus.
- 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
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denRestricted Common Ports
Kategoriename in der API: RESTRICTED_COMMON_PORTS
Hiermit wird geprüft, ob uneingeschränkter eingehender Traffic für die Sicherheitsgruppen für die angegebenen Ports mit dem höchsten Risiko zugänglich ist. 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 uneingeschränkte Zugriff (0.0.0.0/0) erhöht das Risiko von schädlichen Aktivitäten wie Hacking, Denial-of-Service-Angriffen und Datenverlust.
Sicherheitsgruppen bieten ein zustandsorientiertes Filtern des ein- und ausgehenden Netzwerktraffics zu AWS-Ressourcen. Keine Sicherheitsgruppe sollte uneingeschränkten eingehenden 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)
- 3000 (Go-, Node.js- und Ruby-Frameworks für Webentwicklung)
- 3306 (MySQL)
- 3389 (RDP)
- 4333 (ahsp)
- 5000 (Python-Frameworks für die Webentwicklung)
- 5432 (Postgresql)
- 5500 (fcp-addr-srvr1)
- 5601 (OpenSearch-Dashboards)
- 8080 (Proxy)
- 8088 (Legacy-HTTP-Port)
- 8888 (alternativer HTTP-Port)
- 9200 oder 9300 (OpenSearch)
AWS-Konsole
So löschen Sie eine Sicherheitsgruppenregel:
- Öffnen Sie die Amazon EC2-Konsole unter https://console.aws.amazon.com/ec2/.
- Wählen Sie im Navigationsbereich „Sicherheitsgruppen“ aus.
- Wählen Sie die Sicherheitsgruppe aus, die Sie aktualisieren möchten, klicken Sie auf „Aktionen“ und dann auf „Regeln für eingehenden Traffic bearbeiten“, um eine Regel für eingehenden Traffic zu entfernen, oder auf „Regeln für ausgehenden Traffic bearbeiten“, um eine Regel für ausgehenden Traffic zu entfernen.
- Klicken Sie auf die Schaltfläche Löschen rechts neben der zu löschenden Regel.
- Wählen Sie „Änderungsvorschau“ aus und bestätigen Sie die Auswahl.
Informationen zum Löschen von Regeln aus einer Sicherheitsgruppe finden Sie unter Regeln aus einer Sicherheitsgruppe löschen im Amazon EC2-Nutzerhandbuch für Linux-Instanzen.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denRestricted Ssh
Kategoriename in der API: RESTRICTED_SSH
Sicherheitsgruppen bieten ein zustandsorientiertes Filtern des ein- und ausgehenden Netzwerktraffics zu AWS-Ressourcen.
CIS empfiehlt, keine Sicherheitsgruppe uneingeschränkten eingehenden Zugriff auf Port 22 zu erlauben. Durch das Entfernen uneingeschränkter Verbindungen zu Remote-Konsolendiensten wie SSH wird das Risiko eines Servers verringert.
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 beheben:AWS-Konsole
Führen Sie die folgenden Schritte für jede Sicherheitsgruppe aus, die mit einer VPC verknüpft ist.
Öffnen Sie die Amazon VPC-Konsole unter https://console.aws.amazon.com/vpc/.
- Wählen Sie im linken Bereich Sicherheitsgruppen aus.
- Wählen Sie eine Sicherheitsgruppe aus.
- Wählen Sie unten auf der Seite den Tab Eingangsregeln aus.
- Wählen Sie Regeln bearbeiten aus.
- Ermitteln Sie die Regel, die den Zugriff über Port 22 zulässt, und klicken Sie auf das X, um sie zu entfernen.
- Wählen Sie Regeln speichern aus.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denRotation 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 ist NON_COMPLIANT, wenn die AWS Config-Recorder-Rolle für eine Ressource nicht die Berechtigung kms:describeKey hat.
Empfehlung: Achten Sie darauf, dass die Rotation für vom Kunden erstellte CMKs aktiviert istInformationen zum Aktivieren der Automatisierungsschlüsselrotation für AWS KMS finden Sie in der AWS-Dokumentation unter AWS KMS-Schlüssel rotieren.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denRotation 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 Sicherungsschlüssel rotieren. Dabei handelt es sich um im KMS gespeichertes Schlüsselmaterial, das mit der Schlüssel-ID des vom Kunden erstellten Masterschlüssels (Customer Created Customer Master Key, CMK) verknüpft ist. Er ist der Sicherungsschlüssel, der für kryptografische Vorgänge wie Verschlüsselung und Entschlüsselung verwendet wird. Bei der automatisierten Schlüsselrotation werden derzeit alle vorherigen Sicherungsschlüssel beibehalten, sodass 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 einen asymmetrischen CMK nicht 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 beheben:AWS-Konsole
- Melden Sie sich in der AWS Management Console an und öffnen Sie die IAM-Konsole unter https://console.aws.amazon.com/iam.
- Wählen Sie im linken Navigationsbereich
Customer managed keys
aus . - Wählen Sie einen vom Kunden verwalteten CMK aus, bei dem
Key spec = SYMMETRIC_DEFAULT
- Öffnen Sie im Bereich „Allgemeine Konfiguration“ den Tab „Schlüsselrotation“.
- Klicken Sie das Kästchen „Diesen KMS-Schlüssel automatisch jährlich rotieren“ an.
AWS-CLI
- Führen Sie den folgenden Befehl aus, um die Schlüsselrotation zu aktivieren:
aws kms enable-key-rotation --key-id <kms_key_id>
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denRouting Tables Vpc Peering Are Least Access
Kategoriename in der API: ROUTING_TABLES_VPC_PEERING_ARE_LEAST_ACCESS
Prüft, ob Routingtabellen für VPC-Peering mit dem Hauptkonto der geringsten Berechtigung konfiguriert sind.
Empfehlung: Achten Sie darauf, dass Routingtabellen für VPC-Peering den geringsten Zugriff gewährenInformationen zum Aktualisieren von Routingtabellen für VPC-Peering finden Sie unter Routingtabellen für eine VPC-Peering-Verbindung aktualisieren im AWS-VPC-Nutzerhandbuch.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denS3 Account Level Public Access Blocks
Kategoriename in der API: S3_ACCOUNT_LEVEL_PUBLIC_ACCESS_BLOCKS
Der öffentliche Zugriff von Amazon S3 Block bietet Einstellungen für Zugangspunkte, Buckets und Konten, mit denen Sie den öffentlichen Zugriff auf Amazon S3-Ressourcen verwalten können. Standardmäßig ist bei neuen Buckets, Zugangspunkten und Objekten kein öffentlicher Zugriff möglich.
Empfehlung: Prüft, 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 beheben: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
So bearbeiten Sie die Einstellungen zum Blockieren des öffentlichen Zugriffs für alle S3-Buckets in einem AWS-Konto.
- Melden Sie sich in der AWS Management Console an und öffnen Sie die Amazon S3-Konsole unter https://console.aws.amazon.com/s3/.
- Wählen Sie die Einstellungen für den öffentlichen Zugriff für dieses Konto blockieren aus.
- Wählen Sie „Bearbeiten“ aus, um die Einstellungen zum Blockieren des öffentlichen Zugriffs für alle Buckets in Ihrem AWS-Konto zu ändern.
- Wählen Sie die Einstellungen aus, die Sie ändern möchten, und klicken Sie dann auf „Änderungen speichern“.
- Wenn Sie zur Bestätigung aufgefordert werden, geben Sie „Bestätigen“ ein. Wähle dann „Bestätigen“ aus, um deine Ä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}'
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denS3 Bucket Logging Enabled
Kategoriename in der API: S3_BUCKET_LOGGING_ENABLED
Das AWS S3-Serverzugriffs-Logging zeichnet Zugriffsanfragen auf Storage-Buckets auf, was für Sicherheitsaudits nützlich ist. Standardmäßig ist das Serverzugriffs-Logging für S3-Buckets nicht aktiviert.
Empfehlung: Prüft, ob Logging für alle S3-Buckets aktiviert ist Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben:Terraform
Das folgende Beispiel zeigt, wie zwei Buckets erstellt werden:
- Einen Logging-Bucket
- Ein konformer 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 Aktivieren des Amazon S3-Server-Zugriffs-Loggings.
AWS-CLI
Das folgende Beispiel zeigt, wie Sie:
- Erstellen Sie eine Bucket-Richtlinie, um
PutObject
in Ihrem Logging-Bucket die Berechtigung des Logging-Diensthauptkontos 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
- Richtlinie auf den Logging-Bucket anwenden
logging.json
{
"LoggingEnabled": {
"TargetBucket": "MyBucket",
"TargetPrefix": "Logs/"
}
}
aws s3api put-bucket-logging \
--bucket MyBucket \
--bucket-logging-status file://logging.json
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denS3 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 so eingestellt ist, dass HTTP-Anfragen abgelehnt werden Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben:AWS-Konsole
mit AWS Policy Generator:
- Wiederholen Sie die Schritte 1 bis 4 oben.
- Klicken Sie unten im Editor für Bucket-Richtlinien auf
Policy Generator
. - Richtlinientyp auswählen
S3 Bucket Policy
- Anweisungen hinzufügen
-Effect
= Ablehnen
-Principal
= *
-AWS Service
= Amazon S3
-Actions
= *
-Amazon Resource Name
= - Richtlinie generieren
- Kopieren Sie den Text und fügen Sie ihn der Bucket-Richtlinie hinzu.
AWS-CLI
- Exportieren Sie die Bucket-Richtlinie in eine JSON-Datei.
aws s3api get-bucket-policy --bucket <bucket_name> --query Policy --output text > policy.json
- Ändern Sie die Datei policy.json, indem Sie diese Anweisung hinzufügen:
{
"Sid": <optional>",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::<bucket_name>/*",
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}
- Wenden Sie diese geänderte Richtlinie auf den S3-Bucket an:
aws s3api put-bucket-policy --bucket <bucket_name> --policy file://policy.json
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denS3 Bucket Replication Enabled
Kategoriename in der API: S3_BUCKET_REPLICATION_ENABLED
Dieses Steuerelement prüft, ob für einen Amazon S3-Bucket die regionsübergreifende Replikation aktiviert ist. Die Steuerung schlägt fehl, wenn für den Bucket keine regionsübergreifende Replikation oder die Replikation für dieselbe Region ebenfalls aktiviert ist.
Replikation ist das automatische, asynchrone Kopieren von Objekten zwischen Buckets in derselben oder in verschiedenen AWS-Regionen. Bei der Replikation werden neu erstellte Objekte und Objektaktualisierungen aus einem Quell-Bucket in einen oder mehrere Ziel-Buckets kopiert. In den Best Practices von AWS wird die Replikation für Quell- und Ziel-Buckets empfohlen, die demselben AWS-Konto gehören. Neben der Verfügbarkeit sollten Sie Einstellungen zur Härtung anderer Systeme in Betracht ziehen.
Empfehlung: Prüft, ob die regionsübergreifende Replikation für S3-Buckets aktiviert istInformationen zum Aktivieren der regionsübergreifenden Replikation für einen S3-Bucket finden Sie im Amazon Simple Storage Service-Nutzerhandbuch unter Replikation für Quell- und Ziel-Buckets konfigurieren, die demselben Konto gehören. Wählen Sie für den Quell-Bucket die Option „Auf alle Objekte im Bucket anwenden“ aus.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denS3 Bucket Server Side Encryption Enabled
Kategoriename in der API: S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED
Dadurch wird geprüft, ob für Ihren S3-Bucket entweder die Standardverschlüsselung von Amazon S3 aktiviert ist oder ob die S3-Bucket-Richtlinie „put-object“-Anfragen ohne serverseitige Verschlüsselung explizit 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 beheben: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
So aktivieren Sie die Standardverschlüsselung für einen S3-Bucket:
- Öffnen Sie die Amazon S3-Konsole unter https://console.aws.amazon.com/s3/.
- Wählen Sie im linken Navigationsbereich die Option Buckets aus.
- Wählen Sie den S3-Bucket aus der Liste aus.
- Wählen Sie „Eigenschaften“ aus.
- Wählen Sie „Standardverschlüsselung“ aus.
- Wählen Sie für die Verschlüsselung entweder AES-256 oder AWS-KMS aus.
- 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 Verwendung der serverseitigen Verschlüsselung von Amazon S3 zum Verschlüsseln Ihrer Daten finden Sie im Amazon Simple Storage Service-Nutzerhandbuch.
- 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.
- Geben Sie den Amazon Resource Name (ARN) des zu verwendenden AWS KMS-Schlüssels ein. Sie finden den 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.
- Wichtig: Wenn Sie die AWS KMS-Option für Ihre Standardverschlüsselungskonfiguration verwenden, gelten für Sie die RPS-Kontingente (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-Entwicklerleitfaden.
- Wählen Sie „Speichern“ aus.
Weitere Informationen zum Erstellen eines AWS KMS-Schlüssels finden Sie im AWS Key Management Service-Entwicklerhandbuch.
Weitere Informationen zur Verwendung von AWS KMS mit Amazon S3 finden Sie im Nutzerhandbuch für Amazon Simple Storage Service.
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"}}]}'
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denS3 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 und die Wiederherstellung nach unbeabsichtigten Nutzeraktionen und Anwendungsfehlern vereinfachen.
Empfehlung: Prüft, ob die Versionsverwaltung für alle S3-Buckets aktiviert ist Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben:Terraform
resource "aws_s3_bucket" "my_bucket" {
bucket = "my-bucket"
versioning {
enabled = true
}
}
AWS-Konsole
Versionsverwaltung für einen S3-Bucket aktivieren oder deaktivieren
- Melden Sie sich in der AWS Management Console an und öffnen Sie die Amazon S3-Konsole unter https://console.aws.amazon.com/s3/.
- Wählen Sie in der Liste der Buckets den Namen des Buckets aus, für den Sie die Versionsverwaltung aktivieren möchten.
- Wählen Sie „Eigenschaften“ aus.
- Wählen Sie unter „Bucket-Versionsverwaltung“ die Option „Bearbeiten“ aus.
- Wählen Sie „Sperren“ oder „Aktivieren“ und dann „Änderungen speichern“ aus.
AWS-CLI
aws s3control put-bucket-versioning \
--bucket <bucket_name> \
--versioning-configuration Status=Enabled
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denS3 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üft, ob alle Buckets mit KMS verschlüsselt sind Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben: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
So aktivieren Sie die Standardverschlüsselung für einen S3-Bucket:
- Öffnen Sie die Amazon S3-Konsole unter https://console.aws.amazon.com/s3/.
- Wählen Sie im linken Navigationsbereich die Option Buckets aus.
- Wählen Sie den S3-Bucket aus der Liste aus.
- Wählen Sie „Eigenschaften“ aus.
- Wählen Sie „Standardverschlüsselung“ aus.
- Wählen Sie für die Verschlüsselung AWS-KMS aus.
- 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 unter AWS-Dokumentation – Schlüssel erstellen.
- Geben Sie den Amazon Resource Name (ARN) des zu verwendenden AWS KMS-Schlüssels ein. Sie finden den 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.
- 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-Entwicklerleitfaden.
- Wählen Sie „Speichern“ aus.
Weitere Informationen zur Verwendung von AWS KMS mit Amazon S3 finden Sie im Nutzerhandbuch für Amazon Simple Storage Service.
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"}}]}'
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denSagemaker Notebook Instance Kms Key Configured
Kategoriename in der API: SAGEMAKER_NOTEBOOK_INSTANCE_KMS_KEY_CONFIGURED
Prüft, ob ein AWS KMS-Schlüssel (AWS Key Management Service) für eine Amazon SageMaker-Notebookinstanz konfiguriert ist. Die Regel ist NON_COMPLIANT, wenn „KmsKeyId“ für die SageMaker-Notebookinstanz nicht angegeben ist.
Empfehlung: Prüft, ob für alle SageMaker-Notebookinstanzen die Verwendung von KMS konfiguriert istInformationen zum Konfigurieren von KMS für SageMaker finden Sie in der Amazon SageMaker-Dokumentation unter Key Management.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denSagemaker Notebook No Direct Internet Access
Kategoriename in der API: SAGEMAKER_NOTEBOOK_NO_DIRECT_INTERNET_ACCESS
Prüfen Sie, ob der direkte Internetzugriff für eine SageMaker-Notebookinstanz deaktiviert ist. Dazu wird geprüft, ob das Feld „DirectInternetAccess“ für die Notebookinstanz deaktiviert ist.
Wenn Sie Ihre SageMaker-Instanz ohne VPC konfigurieren, ist der direkte Internetzugriff für Ihre Instanz standardmäßig aktiviert. Konfigurieren Sie Ihre Instanz mit einer VPC und ändern Sie die Standardeinstellung in „Deaktivieren – Zugriff auf das Internet über eine VPC“.
Sie benötigen einen Internetzugang, um Modelle über ein Notebook zu trainieren oder zu hosten. Für den Internetzugriff muss Ihre VPC ein NAT-Gateway haben und Ihre Sicherheitsgruppe ausgehende Verbindungen zulässt. Weitere Informationen zum Verbinden einer Notebookinstanz mit Ressourcen in einer VPC finden Sie im Amazon SageMaker-Entwicklerleitfaden unter „Notebookinstanz mit Ressourcen in einer VPC verbinden“.
Achten Sie außerdem darauf, dass nur autorisierte Nutzer auf Ihre SageMaker-Konfiguration zugreifen können. Schränken Sie die IAM-Berechtigungen der Nutzer ein, um SageMaker-Einstellungen und -Ressourcen zu ändern.
Empfehlung: Prüft, ob der direkte Internetzugriff für alle Amazon SageMaker-Notebookinstanzen deaktiviert ist Führen Sie die folgenden Schritte aus, um dieses Ergebnis zu beheben:AWS-Konsole
Beachten Sie, dass Sie die Einstellung für den Internetzugriff nicht mehr ändern können, nachdem eine Notebook-Instanz erstellt wurde. Sie muss beendet, gelöscht und neu erstellt werden.
So konfigurieren Sie eine SageMaker-Notebookinstanz, um den direkten Internetzugriff abzulehnen:
- Öffnen Sie die SageMaker-Konsole unter https://console.aws.amazon.com/sagemaker/.
- Rufen Sie die Notebook-Instanzen auf.
- Löschen Sie die Instanz, für die der direkte Internetzugriff aktiviert ist. Wählen Sie die Instanz aus, wählen Sie „Aktionen“ und dann „Beenden“ aus.
- Nachdem die Instanz beendet wurde, wählen Sie „Aktionen“ und dann „Löschen“ aus.
- Wählen Sie Notebookinstanz erstellen aus. Geben Sie die Konfigurationsdetails an.
- Maximieren Sie den Bereich „Netzwerk“ und wählen Sie dann eine VPC, ein Subnetz und eine Sicherheitsgruppe aus. Wählen Sie unter „Direkter Internetzugriff“ die Option „Deaktivieren – Zugriff auf das Internet über eine VPC“ aus.
- Wählen Sie Notebookinstanz erstellen aus.
Weitere Informationen finden Sie im Amazon SageMaker-Entwicklerleitfaden unter Verbinden einer Notebookinstanz mit Ressourcen in einer VPC.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denSecretsmanager Rotation Enabled Check
Kategoriename in der API: SECRETSMANAGER_ROTATION_ENABLED_CHECK
Prüft, ob ein in AWS Secrets Manager gespeichertes Secret mit automatischer Rotation konfiguriert ist. Die Steuerung schlägt fehl, wenn das Secret nicht mit automatischer Rotation konfiguriert ist. Wenn Sie einen benutzerdefinierten Wert für den Parameter maximumAllowedRotationFrequency
angeben, wird das Steuerelement nur übergeben, wenn das Secret innerhalb des angegebenen Zeitfensters automatisch rotiert wird.
Mit Secret Manager können Sie den Sicherheitsstatus Ihrer Organisation verbessern. Secrets umfassen Datenbankanmeldedaten, Passwörter und API-Schlüssel von Drittanbietern. Mit Secret Manager können Sie Secrets zentral speichern, sie automatisch verschlüsseln, den Zugriff auf Secrets steuern sowie Secrets sicher und automatisch rotieren.
Secrets Manager kann Secrets rotieren. Mithilfe der Rotation können Sie langfristige Secrets durch kurzfristige ersetzen. Durch die Rotation von Secrets wird beschränkt, wie lange ein nicht autorisierter Nutzer ein manipuliertes Secret verwenden kann. Aus diesem Grund sollten Sie Ihre Secrets häufig rotieren. Weitere Informationen zur Rotation finden Sie unter AWS Secrets Manager-Secrets rotieren im AWS Secrets Manager-Nutzerhandbuch.
Empfehlung: Prüft, ob für alle AWS Secrets Manager-Secrets die Rotation aktiviert istInformationen zum Aktivieren der automatischen Rotation für Secrets Manager-Secrets finden Sie im AWS Secrets Manager-Nutzerhandbuch unter Automatische Rotation für AWS Secrets Manager-Secrets mithilfe der Konsole einrichten. Sie müssen eine AWS Lambda-Funktion für die Rotation auswählen und konfigurieren.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denSns Encrypted Kms
Kategoriename in der API: SNS_ENCRYPTED_KMS
Prüft, ob ein SNS-Thema im inaktiven Zustand mit AWS KMS verschlüsselt wird. Die Steuerelemente schlagen fehl, wenn ein SNS-Thema keinen KMS-Schlüssel für die serverseitige Verschlüsselung (SSE) verwendet.
Durch die Verschlüsselung ruhender Daten verringert sich das Risiko, dass auf dem Laufwerk gespeicherte Daten von einem nicht bei AWS authentifizierten Nutzer aufgerufen werden. Außerdem werden weitere Zugriffskontrollen hinzugefügt, um den Zugriff nicht autorisierter Nutzer auf die Daten zu begrenzen. Beispielsweise sind API-Berechtigungen erforderlich, um die Daten zu entschlüsseln, bevor sie gelesen werden können. Für eine zusätzliche Sicherheitsebene sollten SNS-Themen im Ruhezustand verschlüsselt werden.
Empfehlung: Prüft, ob alle SNS-Themen mit KMS verschlüsselt sindInformationen zum Aktivieren von SSE für ein SNS-Thema finden Sie im Artikel zum Aktivieren der serverseitigen Verschlüsselung (SSE) für ein Amazon SNS-Thema im Amazon Simple Notification Service-Entwicklerhandbuch. Bevor Sie SSE verwenden können, müssen Sie auch AWS KMS-Schlüsselrichtlinien konfigurieren, um die Verschlüsselung von Themen und die Verschlüsselung und Entschlüsselung von Nachrichten zuzulassen. Weitere Informationen finden Sie unter AWS KMS-Berechtigungen konfigurieren im Amazon Simple Notification Service-Entwicklerhandbuch.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denVpc Default Security Group Closed
Kategoriename in der API: VPC_DEFAULT_SECURITY_GROUP_CLOSED
Hier wird geprüft, ob die Standardsicherheitsgruppe einer VPC eingehenden oder ausgehenden Traffic zulässt. Die Kontrolle schlägt fehl, wenn die Sicherheitsgruppe eingehenden oder ausgehenden Traffic zulässt.
Die Regeln für die Standardsicherheitsgruppe lassen den gesamten ausgehenden und eingehenden Traffic von Netzwerkschnittstellen (und den zugehörigen Instanzen) zu, die derselben Sicherheitsgruppe zugewiesen sind. Wir empfehlen, nicht die Standardsicherheitsgruppe zu verwenden. Da die Standardsicherheitsgruppe nicht gelöscht werden kann, sollten Sie die Einstellung der Regeln für die Standardsicherheitsgruppe so ändern, dass ein- und ausgehender Traffic eingeschränkt wird. Dies verhindert unbeabsichtigten Traffic, 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änktUm dieses Problem zu beheben, erstellen Sie zuerst neue Sicherheitsgruppen mit der geringsten Berechtigung. Eine Anleitung dazu finden Sie im Amazon VPC-Nutzerhandbuch unter „Create a security group“ (Sicherheitsgruppe erstellen). Weisen Sie dann die neuen Sicherheitsgruppen Ihren EC2-Instanzen zu. Eine Anleitung dazu finden Sie unter Sicherheitsgruppe einer Instanz ändern im Amazon EC2-Nutzerhandbuch für Linux-Instanzen.
Nachdem Sie Ihren Ressourcen die neuen Sicherheitsgruppen zugewiesen haben, entfernen Sie alle Regeln für ein- und ausgehenden Traffic aus den Standardsicherheitsgruppen. Eine Anleitung finden Sie unter „Sicherheitsgruppenregeln löschen“ im Amazon VPC-Nutzerhandbuch.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denVpc Flow Logging Enabled All Vpcs
Kategoriename in der API: VPC_FLOW_LOGGING_ENABLED_ALL_VPCS
VPC-Flusslogs sind ein Feature, mit dem Sie Informationen über den IP-Traffic erfassen können, der in Ihrer VPC an Netzwerkschnittstellen ein- und ausgeht. Nachdem Sie ein Flusslog erstellt haben, können Sie die zugehörigen Daten in Amazon CloudWatch Logs ansehen und abrufen. Es wird empfohlen, VPC-Flusslogs für das Paket „Ablehnungen“ 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 beheben:AWS-Konsole
- In der Verwaltungskonsole anmelden
Services
und dannVPC
auswählen- Wählen Sie im linken Navigationsbereich
Your VPCs
aus. - VPC auswählen
- Wählen Sie im rechten Bereich den Tab
Flow Logs
aus. - Wenn kein Flusslog vorhanden ist, klicken Sie auf
Create Flow Log
. - Wählen Sie als Filter
Reject
aus. Role
undDestination Log Group
eingeben- Klicken Sie auf
Create Log Flow
. - Klicken Sie auf
CloudWatch Logs Group
.
Hinweis:Wenn Sie den Filter auf „Ablehnen“ setzen, wird die Aufnahme von Logging-Daten für diese Empfehlung erheblich reduziert. Außerdem erhalten Sie genügend Informationen, um Verstöße zu erkennen, zu untersuchen und zu beheben. In Zeiten mit Sicherheitsgruppen mit geringstmöglichen Berechtigungen kann es jedoch sehr hilfreich sein, den Filter auf „Alle“ zu setzen, um vorhandene Traffic-Flüsse zu erkennen, die für den ordnungsgemäßen Betrieb einer bereits ausgeführten Umgebung erforderlich sind.
AWS-CLI
- Erstellen Sie ein Richtliniendokument, nennen 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"
}
]
}
- Erstellen Sie ein weiteres Richtliniendokument, nennen 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": "*"
}
]
}
- 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
- 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
- Führen Sie den Befehl
attach-group-policy
mit dem im vorherigen Schritt zurückgegebenen IAM-Richtlinien-ARN 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>
- Führen Sie
describe-vpcs
aus, um die in der ausgewählten Region verfügbare VPCID abzurufen:
aws ec2 describe-vpcs --region <region>
- Die Befehlsausgabe sollte die in der ausgewählten Region verfügbare VPC-ID zurückgeben.
- Führen Sie
create-flow-logs
aus, um ein Flusslog für den VPC-PC 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>
- Wiederholen Sie Schritt 8 für andere VPCs, die in der ausgewählten Region verfügbar sind.
- Ändern Sie die Region, indem Sie „--region“ aktualisieren und das Verfahren zur Fehlerbehebung für andere VPCs wiederholen.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denVpc Sg Open Only To Authorized Ports
Kategoriename in der API: VPC_SG_OPEN_ONLY_TO_AUTHORIZED_PORTS
Mit diesem Steuerelement wird geprüft, ob eine Amazon EC2-Sicherheitsgruppe uneingeschränkten eingehenden Traffic von nicht autorisierten Ports zulässt. Der Kontrollstatus wird wie folgt bestimmt:
Wenn Sie den Standardwert für „AuthorizedTcpPorts“ verwenden, schlägt die Steuerung 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 Steuerung 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 mit einer Regel für uneingeschränkten eingehenden Traffic fehl.
Sicherheitsgruppen bieten ein zustandsorientiertes Filtern des ein- und ausgehenden Netzwerktraffics zu AWS. Regeln für Sicherheitsgruppen sollten dem Prinzip der geringsten Berechtigung folgen. Uneingeschränkter Zugriff (IP-Adresse mit dem Suffix /0) erhöht das Risiko von schädlichen Aktivitäten wie Hacking, Denial-of-Service-Angriffen und Datenverlust. Sofern ein Port nicht ausdrücklich erlaubt ist, sollte über den Port uneingeschränkter Zugriff verweigert werden.
Empfehlung: Prüft, ob Sicherheitsgruppen mit 0.0.0.0/0 einer beliebigen VPC nur bestimmten eingehenden TCP/UDP-Traffic zulassenInformationen zum Ändern einer Sicherheitsgruppe finden Sie unter Mit Sicherheitsgruppen arbeiten im Amazon VPC-Nutzerhandbuch.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu denBoth 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, für eine sichere und hochverfügbare Verbindung zwischen einer AWS-VPC und Ihrem Remote-Netzwerk sicherzustellen, dass beide VPN-Tunnel für eine VPN-Verbindung eingerichtet sind.
Dieses Steuerelement prüft, ob beide vom AWS Site-to-Site-VPN bereitgestellte VPN-Tunnel den Status UP haben. Die Steuerung schlägt fehl, wenn sich einer oder beide Tunnel im Status DOWN befinden.
Empfehlung: Prüft, ob beide AWS-VPN-Tunnel, die von AWS Site-to-Site bereitgestellt werden, UP-Status habenInformationen zum Ändern der VPN-Tunneloptionen finden Sie unter Site-to-Site-VPN-Tunneloptionen ändern im AWS Site-to-Site-VPN-Nutzerhandbuch.
unterstützten Einstellungen für Assets und Scans dieses Ergebnistyps.
Weitere Informationen zu den