Fehler im Security Command Center beheben

Auf dieser Seite finden Sie eine Liste von Referenzleitfäden und -techniken zur Behebung von SCC-Fehlern.

Hinweise

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 über die Google Cloud Console Berechtigungsfehler auftreten, bitten Sie Ihren Administrator um Unterstützung. Weitere Informationen zu Rollen finden Sie unter Zugriffssteuerung. Informationen zum Beheben von Ressourcenfehlern finden Sie in der Dokumentation der betroffenen Produkte.

Ergebnisse in der Google Cloud Console ansehen

SCC-Fehler sind Konfigurationsfehler, die verhindern, dass Security Command Center wie erwartet funktioniert. Die Quelle Security Command Center generiert diese Ergebnisse.

Wenn Security Command Center für Ihre Organisation oder Ihr Projekt eingerichtet ist, werden Fehlerergebnisse generiert, sobald diese erkannt werden. Sie können SCC-Fehler in der Google Cloud Console ansehen.

So prüfen Sie Ergebnisse in der Google Cloud Console:

  1. Wechseln Sie in der Google Cloud Console zur Seite Ergebnisse des Security Command Center.

    Zu Ergebnissen

  2. Wählen Sie Ihr Google Cloud-Projekt oder Ihre Organisation aus.

    Projektauswahl

  3. Wählen Sie im Abschnitt Schnellfilter im Unterbereich Anzeigename der Quelle die Option Security Command Center aus.

  4. Klicken Sie auf den Namen des Ergebnisses unter Category, um Details zu einem bestimmten Ergebnis aufzurufen. Der Bereich mit den Ergebnisdetails wird erweitert und enthält nun die folgenden Informationen:

    • KI-generierte ZusammenfassungVorschau: Eine dynamisch generierte Erklärung des gefundenen Problems
    • Beschreibung: Eine kurze Erklärung des erkannten Fehlers.
    • Ereigniszeit: Zeitpunkt, an dem das Ergebnis aufgetreten ist
    • Anzeigename der Ressource: die betroffene Ressource
    • Nächste Schritte: Anleitungen zur Fehlerbehebung
    • Kanonischer Name des Ergebnisses: Eine eindeutige Kennung für das Ergebnis
    • Anzeigename der Quelle: Security Command Center

  5. Optional: Klicken Sie auf den Tab JSON, um die vollständige JSON-Definition des Ergebnisses aufzurufen.

    Im Bereich wird die JSON-Definition des Ergebnisses angezeigt. Hier können Sie alle Attribute des Ergebnisses prüfen.

Deaktivierung von SCC-Fehlern nach Korrektur

Nachdem Sie ein Ergebnis vom Typ SCC error korrigiert haben, legt Security Command Center den Status des Ergebnisses beim nächsten Scan automatisch auf INACTIVE fest. Wie lange es dauert, bis Security Command Center den Status eines behobenen Ergebnisses auf INACTIVE setzt, hängt davon ab, wann Sie das Ergebnis korrigieren und den Zeitplan des Scans, der den Fehler erkennt.

Informationen zur Scanhäufigkeit für ein SCC error-Ergebnis finden Sie in der Zusammenfassung des Ergebnisses unter Fehlerdetektoren.

SCC-Fehler beheben

Dieser Abschnitt enthält Anweisungen zur Behebung aller SCC-Fehler.

API disabled

Kategoriename in der API: API_DISABLED

Einer der folgenden Dienste ist für das Projekt deaktiviert:

Der deaktivierte Dienst kann keine Ergebnisse generieren.

So können Sie dieses Ergebnis beheben:

  1. Prüfen Sie das Ergebnis, um festzustellen, welche API deaktiviert ist.

  2. API aktivieren:

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

APS no resource value configs match any resources

Kategoriename in der API: APS_NO_RESOURCE_VALUE_CONFIGS_MATCH_ANY_RESOURCES

Ressourcenwertkonfigurationen sind für Angriffspfadsimulationen definiert, stimmen aber mit keinen Ressourceninstanzen in Ihrer Umgebung überein. Für die Simulationen wird stattdessen der Standardsatz hochwertiger Ressourcen verwendet.

Aus den folgenden Gründen, die in der Ergebnisbeschreibung in der Google Cloud Console aufgeführt sind, stimmen Konfigurationen von Ressourcenwerten möglicherweise mit keiner Ressource überein:

  • Keine der Ressourcenwertkonfigurationen stimmt mit Ressourceninstanzen überein.
  • Eine oder mehrere Ressourcenwertkonfigurationen, die NONE angeben, überschreiben jede andere gültige Konfiguration.
  • Alle definierten Ressourcenwertkonfigurationen geben den Wert NONE an.

So können Sie dieses Ergebnis beheben:

  1. Rufen Sie in den Einstellungen von Security Command Center die Seite Angriffspfadsimulation auf:

    Einstellungen aufrufen

  2. Wählen Sie Ihre Organisation aus. Die Seite Angriffspfadsimulation wird mit den vorhandenen Konfigurationen geöffnet.

  3. Suchen Sie in der Spalte Ressourcenwert der Liste Ressourcenwertkonfigurationen nach Werten von None.

  4. Gehen Sie für jede Konfiguration, in der None angegeben ist, so vor:

    1. Klicken Sie auf den Namen einer Ressourcenwertkonfiguration, um die Konfigurationsspezifikationen aufzurufen.

    2. Bearbeiten Sie bei Bedarf die Ressourcenattributspezifikationen, um die Anzahl der Ressourceninstanzen zu reduzieren, die der Konfiguration entsprechen.

  5. Wenn das Problem nicht durch eine zu allgemeine None-Spezifikation verursacht wird, gehen Sie so vor:

    1. Klicken Sie auf die Namen der einzelnen Konfigurationen, die den Wert HIGH, MEDIUM oder LOW angeben, um die Spezifikationen des Ressourcenattributs aufzurufen.

    2. Prüfen Sie die Konfiguration und ändern Sie sie gegebenenfalls, um den Bereich, den Ressourcentyp, das Tag oder die Labelspezifikation an die beabsichtigten Ressourcen anzupassen.

  6. Falls erforderlich, erstellen Sie eine neue Konfiguration für Ressourcenwerte.

Ihre Änderungen werden auf die nächste Angriffspfadsimulation angewendet.

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

APS resource value assignment limit exceeded

Kategoriename in der API: APS_RESOURCE_VALUE_ASSIGNMENT_LIMIT_EXCEEDED

In der letzten Simulation des Angriffspfads hat die Anzahl der Instanzen von hochwertigen Ressourcen, wie in den Konfigurationen für den Ressourcenwert angegeben, das Limit von 1.000 Ressourceninstanzen in einem Satz hochwertiger Ressourcen überschritten. Daher hat Security Command Center die übermäßige Anzahl von Instanzen aus dem Satz hochwertiger Ressourcen ausgeschlossen.

Um dieses Ergebnis zu beheben, können Sie die folgenden Aktionen ausprobieren:

  • Verwenden Sie Tags oder Labels, um die Anzahl der Übereinstimmungen für einen bestimmten Ressourcentyp oder innerhalb eines angegebenen Bereichs zu reduzieren. Die Tags oder Labels müssen auf die Ressourceninstanzen angewendet werden, bevor sie mit einer Ressourcenwertkonfiguration abgeglichen werden können.
  • Erstellen Sie eine Ressourcenwertkonfiguration, die einer Teilmenge der in einer anderen Konfiguration angegebenen Ressourcen den Ressourcenwert NONE zuweist. Wenn Sie den Wert NONE angeben, werden alle anderen Konfigurationen überschrieben und die Ressourceninstanzen werden aus Ihrem Satz hochwertiger Ressourcen ausgeschlossen.
  • Reduzieren Sie in der Konfiguration des Ressourcenwerts die Spezifikation für das Bereichsressourcenattribut.
  • Löschen Sie Ressourcenwertkonfigurationen, die den Wert LOW zuweisen.

Anleitungen zum Erstellen, Bearbeiten oder Löschen einer Konfiguration für den Ressourcenwert finden Sie unter Gruppe hochwertiger Ressourcen definieren und verwalten.

Weitere Informationen zu den unterstützten Assets und Scaneinstellungen dieses Ergebnistyps.

GKE service account missing permissions

Kategoriename in der API: GKE_SERVICE_ACCOUNT_MISSING_PERMISSIONS

Container Threat Detection kann keine Ergebnisse für einen Google Kubernetes Engine-Cluster generieren, da das GKE-Standarddienstkonto im Cluster nicht die erforderlichen Berechtigungen hat. Auf diese Weise wird verhindert, dass Container Threat Detection auf dem Cluster erfolgreich aktiviert wird.

Sie können dieses Ergebnis beheben, indem Sie das GKE-Standarddienstkonto wiederherstellen und prüfen, ob das Dienstkonto die Rolle Kubernetes Engine-Dienst-Agent roles/container.serviceAgent hat.

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

KTD blocked by admission controller

Kategoriename in der API: KTD_BLOCKED_BY_ADMISSION_CONTROLLER

Container Threat Detection kann in einem Cluster nicht aktiviert werden, da ein Admission-Controller eines Drittanbieters die Bereitstellung des erforderlichen Kubernetes DaemonSet-Objekts verhindert.

Zur Behebung dieses Ergebnisses müssen Sie dafür sorgen, dass die auf dem Cluster ausgeführten Zugangs-Controller Container Threat Detection erlauben, die erforderlichen Kubernetes-Objekte zu erstellen.

Zugangssteuerung prüfen

Prüfen Sie, ob der Zugangs-Controller in Ihrem Cluster die Bereitstellung des Container Threat Detection-DaemonSet-Objekts ablehnt.

  1. Sehen Sie sich in der Ergebnisbeschreibung bei den Ergebnisdetails in der Google Cloud Console die enthaltene Fehlermeldung von Kubernetes an. Die Kubernetes-Fehlermeldung sollte in etwa so aussehen:

    generic::failed_precondition: incompatible admission webhook:
admission webhook "example.webhook.sh" denied the request:
[example-constraint] you must provide labels: {"example-required-label"}.

  2. Suchen Sie in den Cloud-Audit-Logs zu Administratoraktivitäten für das Projekt, das Ihren Cluster enthält, nach der Fehlermeldung, die im Feld Beschreibung der Ergebnisdetails angezeigt wird.

  3. Wenn der Admission-Controller funktioniert, die Bereitstellung des Container Threat Detection-DaemonSet-Objekts aber ablehnt, konfigurieren Sie den Admission-Controller so, dass das von Google verwaltete Dienstkonto für Container Threat Detection Objekte im kube-system-Namespace verwalten kann.

    Das Dienstkonto für Container Threat Detection muss bestimmte Kubernetes-Objekte verwalten können.

Weitere Informationen zur Verwendung von Admission-Controllern mit Container Threat Detection finden Sie unter PodSecurityPolicy- und Admission-Controller.

Fehlerbehebung bestätigen

Nachdem Sie den Fehler behoben haben, versucht Security Command Center automatisch, Container Threat Detection zu aktivieren. Nachdem Sie auf die Aktivierung gewartet haben, können Sie mit den folgenden Schritten prüfen, ob Container Threat Detection aktiv ist:

  1. Rufen Sie in der Console die Seite Arbeitslasten von Kubernetes Engine auf.

    Zur Seite „Kubernetes-Arbeitslasten“

  2. Wählen Sie bei Bedarf Systemarbeitslasten anzeigen aus.

  3. Filtern Sie auf der Seite Arbeitslasten die Arbeitslasten zuerst nach dem Clusternamen.

  4. Suchen Sie nach der Arbeitslast container-watcher. Wenn container-watcher vorhanden ist und der Status OK lautet, ist Container Threat Detection aktiv.

KTD image pull failure

Kategoriename in der API: KTD_IMAGE_PULL_FAILURE

Container Threat Detection kann im Cluster nicht aktiviert werden, da ein erforderliches Container-Image nicht aus gcr.io, dem Image-Host von Container Registry, abgerufen (heruntergeladen) werden kann.

Das Abrufen oder Herunterladen eines Container-Images kann aus verschiedenen Gründen fehlschlagen.

Prüfen Sie Folgendes:

  • Achten Sie darauf, dass Ihre VPC-Netzwerk-, DNS- oder Firewalleinstellungen den Netzwerkzugriff vom Cluster auf den Image-Host gcr.io nicht blockieren.
  • Wenn der Cluster privat ist, muss Privater Google-Zugriff aktiviert sein, um den Zugriff auf den Image-Host gcr.io zuzulassen.
  • Wenn die Netzwerkeinstellungen oder der privater Google-Zugriff nicht die Ursache des Fehlers sind, lesen Sie die GKE-Dokumentation zur Fehlerbehebung für die Fehler ImagePullBackOff und ErrImagePull.

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

KTD service account missing permissions

Kategoriename in der API: KTD_SERVICE_ACCOUNT_MISSING_PERMISSIONS

Dem Dienstkonto von Container Threat Detection, das in den Ergebnisdetails in der Google Cloud Console angegeben ist, fehlen erforderliche Berechtigungen. Es werden entweder alle oder einige Container Threat Detection-Ergebnisse nicht an Security Command Center gesendet.

So können Sie dieses Ergebnis beheben:

  1. Weisen Sie dem Dienstkonto die Rolle Container Threat Detection-Dienst-Agent (roles/containerthreatdetection.serviceAgent) zu. Weitere Informationen finden Sie unter Einzelne Rolle zuweisen.

    Wenn Sie eine benutzerdefinierte Rolle verwenden möchten, muss diese die Berechtigungen in der Rolle „Container Threat Detection-Dienst-Agent“ haben.

  2. Achten Sie darauf, dass keine IAM-Ablehnungsrichtlinien festgelegt sind, die das Dienstkonto daran hindern, eine der Berechtigungen in der Rolle des Container Threat Detection-Dienst-Agents zu verwenden. Wenn eine Ablehnungsrichtlinie den Zugriff blockiert, fügen Sie das Dienstkonto als Ausnahmehauptkonto in die Ablehnungsrichtlinie ein.

Weitere Informationen zum Container Threat Detection-Dienstkonto sowie zu den erforderlichen Rollen und Berechtigungen finden Sie unter

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

Misconfigured Cloud Logging Export

Kategoriename in der API: MISCONFIGURED_CLOUD_LOGGING_EXPORT

Das Projekt, das für den kontinuierlichen Export nach Cloud Logging konfiguriert ist, ist nicht verfügbar. Daher kann Security Command Center keine Ergebnisse an Logging senden.

Führen Sie einen der folgenden Schritte aus, um dieses Ergebnis zu beheben:

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

VPC Service Controls Restriction

Kategoriename in der API: VPC_SC_RESTRICTION

Security Health Analytics kann bestimmte Ergebnisse für ein Projekt nicht liefern, da das Projekt durch einen Dienstperimeter geschützt ist. Sie müssen dem Security Command Center-Dienstkonto eingehenden Zugriff auf den Dienstperimeter gewähren.

Die Kennung des Dienstkontos ist eine E-Mail-Adresse im folgenden Format:

service-RESOURCE_KEYWORD-RESOURCE_ID@security-center-api.iam.gserviceaccount.com

Ersetzen Sie Folgendes:

  • RESOURCE_KEYWORD: das Keyword org oder project, je nachdem, zu welcher Ressource das Dienstkonto gehört
  • RESOURCE_ID: einer der folgenden Werte:
    • Die Organisations-ID, wenn das Dienstkonto der Organisation gehört
    • die Projektnummer, wenn das Dienstkonto zu einem Projekt gehört

Wenn Sie sowohl Dienstkonten auf Organisationsebene als auch auf Projektebene haben, wenden Sie die Abhilfe auf beide an.

Führen Sie folgende Schritte aus, um dieses Ergebnis zu beheben.

Schritt 1: Bestimmen, welcher Dienstperimeter Security Health Analytics blockiert

  1. Rufen Sie die eindeutige VPC Service Controls-ID und die mit dem Ergebnis verknüpfte Projekt-ID ab:
    1. Klicken Sie auf den Kategorienamen, um die Details des Ergebnisses aufzurufen.
    2. Kopieren Sie im Feld Beschreibung die eindeutige ID von VPC Service Controls, z. B. 5e4GI409D6BTWfOp_6C-uSwmTpOQWcmW82sfZW9VIdRhGO5pXyCJPQ.
    3. Kopieren Sie im Feld Ressourcenpfad die ID des Projekts.

  2. Rufen Sie die Zugriffsrichtlinien-ID und den Namen des Dienstperimeters ab:

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

      Zum Log-Explorer

    2. Wählen Sie in der Symbolleiste das Projekt aus, das mit dem Ergebnis verknüpft ist.

      Projektauswahl

    3. Geben Sie im Suchfilterfeld die eindeutige ID des Fehlers ein.

      Nach Fehler-UID suchen

      Wenn der Fehler nicht in den Abfrageergebnissen angezeigt wird, erweitern Sie die Zeitachse im Histogramm und führen Sie die Abfrage dann noch einmal aus.

    4. Klicken Sie auf den angezeigten Fehler.

    5. Klicken Sie auf Verschachtelte Felder erweitern.

    6. Kopieren Sie den Wert des Felds servicePerimeterName. Der Wert hat folgendes Format:

      accessPolicies/ACCESS_POLICY/servicePerimeters/SERVICE_PERIMETER

      In diesem Beispiel lautet der vollständige Ressourcenname des Dienstperimeters accessPolicies/540107806624/servicePerimeters/vpc_sc_misconfigured.

      • ACCESS_POLICY ist die ID der Zugriffsrichtlinie, z. B. 540107806624.
      • SERVICE_PERIMETER ist der Name des Dienstperimeters, z. B. vpc_sc_misconfigured.

      Vollständiger Ressourcenname des Dienstperimeters

    7. Verwenden Sie die gcloud CLI, um den Anzeigenamen abzurufen, der der Zugriffsrichtlinien-ID entspricht.

      Wenn Sie keine Abfragen auf Organisationsebene stellen können, bitten Sie Ihren Administrator, diesen Schritt auszuführen.

      gcloud access-context-manager policies list --organization ORGANIZATION_ID

      Ersetzen Sie ORGANIZATION_ID durch die numerische ID Ihrer Organisation.

      Die Ausgabe sollte in etwa so aussehen:

      NAME          ORGANIZATION  SCOPES                 TITLE           ETAG
540107806624  549441802605                         default policy  2a9a7e30cbc14371
352948212018  549441802605  projects/393598488212  another_policy  d7b47a9ecebd4659

      Der angezeigte Name ist der Titel, der der Zugriffsrichtlinien-ID entspricht. Notieren Sie sich den Namen der Zugriffsrichtlinie und den Namen des Dienstperimeters. Sie benötigen sie im nächsten Abschnitt.

Schritt 2: Regel für eingehenden Traffic erstellen, die Zugriff auf das Projekt gewährt

Für diesen Abschnitt benötigen Sie Zugriff auf VPC Service Controls auf Organisationsebene. Wenn Sie keinen Zugriff auf Organisationsebene haben, bitten Sie Ihren Administrator, die folgenden Schritte auszuführen.

In den folgenden Schritten erstellen Sie eine Eingangsregel für den Dienstperimeter, den Sie in Schritt 1 ermittelt haben.

Führen Sie die folgenden Schritte aus, um einem Dienstkonto eingehenden Zugriff auf einen Dienstperimeter zu gewähren.

  1. Rufen Sie VPC Service Controls auf.

    Zu „VPC Service Controls“

  2. Wählen Sie in der Symbolleiste Ihre Google Cloud-Organisation aus.

    Projektauswahl

  3. Wählen Sie in der Drop-down-Liste die Zugriffsrichtlinie aus, die den Dienstperimeter enthält, auf den Sie Zugriff gewähren möchten.

    Liste der Zugriffsrichtlinien

    Die mit der Zugriffsrichtlinie verknüpften Dienstperimeter werden in der Liste angezeigt.

  4. Klicken Sie auf den Namen des Dienstes.

  5. Klicken Sie auf Perimeter bearbeiten.

  6. Klicken Sie im Navigationsmenü auf Richtlinie für eingehenden Traffic.

  7. Klicken Sie auf Regel hinzufügen.

  8. Konfigurieren Sie die Regel so:

    FROM-Attribute des API-Clients

    1. Wählen Sie für Quelle die Option Alle Quellen aus.
    2. Wählen Sie unter Identität die Option Ausgewählte Identitäten aus.
    3. Klicken Sie im Feld Add User/Service Account (Nutzer/Dienstkonto hinzufügen) auf Select (Auswählen).
    4. Geben Sie die E-Mail-Adresse des Dienstkontos ein. Wenn Sie sowohl Dienstkonten auf Organisationsebene als auch auf Projektebene haben, fügen Sie beide hinzu.
    5. Klicken Sie auf Speichern.

    TO-Attribute von GCP-Diensten/-Ressourcen

    1. Wählen Sie unter Projekt die Option Alle Projekte oder das im Ergebnis angegebene Projekt aus.

    2. Wählen Sie für Dienste die Option Alle Dienste oder jeden der folgenden Dienste aus, die Security Health Analytics benötigt:

      • BigQuery API
      • Binary Authorization API
      • Cloud Logging API
      • Cloud Monitoring API
      • Compute Engine API
      • Kubernetes Engine API

    Wenn ein Dienstperimeter den Zugriff auf einen erforderlichen Dienst einschränkt, kann Security Health Analytics keine Ergebnisse für diesen Dienst liefern.

  9. Klicken Sie im Navigationsmenü auf Speichern.

Weitere Informationen finden Sie unter Richtlinien für eingehenden und ausgehenden Traffic konfigurieren.

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

Security Command Center service account missing permissions

Kategoriename in der API: SCC_SERVICE_ACCOUNT_MISSING_PERMISSIONS

Das von Google verwaltete Dienstkonto von Security Command Center fehlt die Berechtigungen, die für eine ordnungsgemäße Funktion erforderlich sind.

Die Kennung des Dienstkontos ist eine E-Mail-Adresse im folgenden Format:

service-RESOURCE_KEYWORD-RESOURCE_ID@security-center-api.iam.gserviceaccount.com

Ersetzen Sie Folgendes:

  • RESOURCE_KEYWORD: das Keyword org oder project, je nachdem, zu welcher Ressource das Dienstkonto gehört
  • RESOURCE_ID: einer der folgenden Werte:
    • Die Organisations-ID, wenn das Dienstkonto der Organisation gehört
    • die Projektnummer, wenn das Dienstkonto zu einem Projekt gehört

Wenn Sie sowohl Dienstkonten auf Organisationsebene als auch auf Projektebene haben, wenden Sie die Abhilfe auf beide an.

So können Sie dieses Ergebnis beheben:

  1. Weisen Sie dem Dienstkonto die Rolle „Security Center-Dienst-Agent“ (roles/securitycenter.serviceAgent) zu.

    Weitere Informationen finden Sie unter Eine einzelne Rolle zuweisen.

    Wenn Sie eine benutzerdefinierte Rolle verwenden möchten, muss diese die Berechtigungen der Rolle Security Center-Dienst-Agent haben.

  2. Achten Sie darauf, dass keine IAM-Ablehnungsrichtlinien festgelegt sind, die das Dienstkonto daran hindern, die Berechtigungen in den erforderlichen Rollen zu verwenden. Wenn eine Ablehnungsrichtlinie den Zugriff blockiert, fügen Sie das Dienstkonto als Ausnahmehauptkonto in die Ablehnungsrichtlinie ein.

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

Nächste Schritte

Weitere Informationen zu Security Command Center-Fehlern