Diese Seite wurde von der Cloud Translation API übersetzt.

Fehler im Security Command Center beheben

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

Vorbereitung

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 Sie auf eine beim Zugriff auf Security Command Center in der Google Cloud Console erhalten, bitten Sie Ihren Administrator um Unterstützung. Weitere Informationen Informationen zu Rollen finden Sie unter Zugriffssteuerung. Informationen zum Beheben von Ressourcenfehlern finden Sie in der Dokumentation zu den betroffenen Produkten.

Ergebnisse in der Google Cloud Console prüfen

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

Solange Security Command Center für Ihr Unternehmen eingerichtet ist, Organisation oder Projekt werden Fehler gefunden, sobald sie erkannt werden. Sie können SCC-Fehler in der Google Cloud Console ansehen.

So überprüfen Sie die Ergebnisse in der Google Cloud Console:

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

Zu Ergebnissen
Wählen Sie Ihr Google Cloud-Projekt oder Ihre Organisation aus.
Wählen Sie im Abschnitt Schnellfilter im Unterbereich Anzeigename der Quelle die Option Security Command Center aus.
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 Zusammenfassung^Vorschau: 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: Anleitung zur Fehlerbehebung
- Kanonischer Name des Ergebnisses: eine eindeutige Kennzeichnung für das Ergebnis
- Anzeigename der Quelle: Security Command Center
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 der Korrektur

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

Informationen zur Scanhäufigkeit für ein SCC error-Ergebnis: die Zusammenfassung des Ergebnisses 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:

Prüfen Sie das Ergebnis, um festzustellen, welche API deaktiviert ist.
API aktivieren:
- Aktivieren Sie die Container Threat Detection API.
  
  API aktivieren
- Aktivieren Sie die Web Security Scanner API.
  
  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 Ressourceninstanzen in Ihrer Umgebung. Bei den Simulationen werden die sind stattdessen standardmäßig hochwertige Ressourcen festgelegt.

Ressourcenwertkonfigurationen stimmen möglicherweise mit keinen Ressourcen für die Gründe, die in der Ergebnisbeschreibung im Google Cloud Console:

Keine der Ressourcenwertkonfigurationen stimmt mit Ressourceninstanzen überein.
Eine oder mehrere Ressourcenwertkonfigurationen, die NONE angeben, überschreiben alle eine andere gültige Konfiguration.
Alle definierten Konfigurationen für Ressourcenwerte geben den Wert NONE an.

So können Sie dieses Ergebnis beheben:

Rufen Sie in Security Command Center die Seite Simulation des Angriffspfads auf. Einstellungen:

Einstellungen aufrufen
Wählen Sie Ihre Organisation aus. Die Seite Simulation des Angriffspfads wird geöffnet mit den vorhandenen Konfigurationen.
In der Spalte Ressourcenwert der Ressourcenwertkonfigurationen suchen Sie nach Werten von None.
Gehen Sie für jede Konfiguration, in der None angegeben ist, so vor:
1. Klicken Sie auf den Namen einer Ressourcenwertkonfiguration, um die Konfigurationsspezifikationen.
2. Bearbeiten Sie bei Bedarf die Spezifikationen für Ressourcenattribute. um die Anzahl der Ressourceninstanzen zu reduzieren, die der Konfiguration entsprechen.
Wenn das Problem nicht durch eine zu breite None-Spezifikation verursacht wird, Gehen Sie so vor:
1. Klicken Sie auf die Namen jeder Konfiguration, die den Wert HIGH angibt. MEDIUM oder LOW, um die Spezifikationen für Ressourcenattribute aufzurufen.
2. Prüfen Sie die Konfiguration und korrigieren Sie sie bei Bedarf, um den Umfang zu korrigieren. Ressourcentyp, Tag oder Label an die vorgesehenen Ressourcen.
Erstellen Sie bei Bedarf eine neue Konfiguration für den Ressourcenwert.

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 Angriffspfadsimulation: die Anzahl der Instanzen hochwertiger Ressourcen, wie vom Ressourcenwertkonfigurationen, das Limit von 1.000 Ressourceninstanzen in einem Satz hochwertiger Ressourcen. Daher hat Security Command Center die Übermäßig viele Instanzen aus dem Satz hochwertiger Ressourcen.

Um dieses Ergebnis zu beheben, können Sie Folgendes versuchen:

Tags verwenden oder Labels um die Anzahl der Übereinstimmungen für einen bestimmten Ressourcentyp zu reduzieren oder innerhalb eines bestimmten Umfangs liegen. Die Tags oder Labels müssen auf die Ressourceninstanzen, bevor sie mit einem Ressourcenwert abgeglichen werden können Konfiguration.
Erstellen Sie eine Konfiguration für den Ressourcenwert, die eine Ressourcenwert von NONE mit einer Teilmenge der Ressourcen, die in eine andere Konfiguration. Wenn Sie den Wert NONE angeben, werden alle anderen Konfigurationen und die Ressourceninstanzen aus Ihrem Satz hochwertiger Ressourcen ausschließt.
Reduzieren Sie das Umfang der Ressource. in der Konfiguration des Ressourcenwerts angeben.
Löschen Sie Konfigurationen für den Ressourcenwert, die den Wert LOW zuweisen.

Anleitungen zum Erstellen, Bearbeiten oder Löschen eines Ressourcenwerts Informationen zur Konfiguration finden Sie unter Satz hochwertiger Ressourcen definieren und verwalten.

Informationen zu diesem Ergebnistyp unterstützte Einstellungen für Assets und Scans.

`CIEM service account missing permissions`

Kategoriename in der API: CIEM_SERVICE_ACCOUNT_MISSING_PERMISSIONS

Das vom CIEM-Dienst verwendete Dienstkonto fehlt Berechtigungen. CIEM kann keine oder mehrere Ergebniskategorien generieren.

Um dieses Ergebnis zu beheben, stellen Sie die erforderlichen IAM-Rollen im CIEM-Dienstkonto wieder her:

Öffnen Sie in der Google Cloud Console die Seite IAM.

IAM aufrufen
Wählen Sie das CIEM-Dienstkonto Ihrer Organisation aus. Dienst Die ID des Kontos ist eine E-Mail-Adresse mit dem folgenden Format:
```
service-org-ORGANIZATION_ID@gcp-sa-ciem.iam.gserviceaccount.com
```
Ersetzen Sie ORGANIZATION_ID durch die numerische ID Ihrer Organisation.

Wenn das Dienstkonto nicht in der Liste aufgeführt ist, klicken Sie auf ZUGRIFF GEWÄHREN am auf der Seite und geben Sie das Dienstkonto als neues Hauptkonto ein.
Rolle „CIEM-Dienst-Agent“ gewähren (roles/ciem.serviceAgent) mit dem Dienstkonto. Wenn Sie benutzerdefinierte Rollen verwenden, müssen diese die folgenden Berechtigungen:
- cloudasset.assets.exportResource
- cloudasset.assets.exportIamPolicy
Klicken Sie auf Speichern.

`CIEM AWS CloudTrail configuration error`

Kategoriename in der API: AWS_CLOUDTRAIL_CONFIGURATION_ERROR

Es werden entweder alle oder einige CIEM-AWS-Ergebnisse nicht an Security Command Center. Der AWS CloudTrail-Feed ist fehlgeschlagen und kann nicht erfolgreich ausgeführt werden Daten aufgrund eines Konfigurationsfehlers abzurufen.

Für dieses Ergebnis gibt es drei mögliche Ursachen:

Fehlender AWS CloudTrail-Feed

Erstellen und konfigurieren Sie in der Security Operations Console einen Feed zur Aufnahme von AWS, um dieses Problem zu beheben CloudTrail-Logs Legen Sie das Schlüssel/Wert-Paar Aufnahmelabel auf CIEM und TRUE.

Eine Anleitung zum Erstellen eines Feeds finden Sie unter Erstellen des Feed in der Google SecOps-Dokumentation.
Fehler bei der Feedkonfiguration

Vergewissern Sie sich, dass Sie den Feed richtig konfiguriert haben.

Informationen zum Konfigurieren eines Feeds finden Sie unter Feed konfigurieren in: Google Security Operations zum Aufnehmen von AWS Protokolle in der Google SecOps-Dokumentation.
Unvollständige AWS CloudTrail-Konfiguration

Richten Sie den S3-Bucket in Ihrem AWS CloudTrail ein, um dieses Problem zu beheben Konfiguration, um sowohl Datenereignisse als auch Verwaltungsereignisse von allen AWS-Konten zu protokollieren Konten, für die Sie CIEM.

Informationen zum Einrichten von CloudTrail finden Sie unter AWS konfigurieren CloudTrail (oder andere Dienst) in der Google SecOps-Dokumentation.

`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 für einen Cluster nicht aktiviert werden, da ein Drittanbieter Admission-Controller verhindert die Bereitstellung der erforderlichen Kubernetes DaemonSet-Objekt.

Um dieses Ergebnis zu beheben, achten Sie darauf, dass die Zulassungs-Controller, die im Cluster ausgeführt werden, erlauben Sie Container Threat Detection, die erforderlichen Kubernetes-Objekten.

Zugangs-Controller prüfen

Prüfen Sie, ob der Admission-Controller in Ihrem Cluster den Bereitstellung des DaemonSet-Objekts von Container Threat Detection.

In der Ergebnisbeschreibung in den Ergebnisdetails in der Sehen Sie sich 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"}.
```
In den Cloud-Audit-Logs zu Administratoraktivitäten für das Projekt das Ihren Cluster enthält, suchen Sie nach der Fehlermeldung, die in in das Feld Beschreibung der Ergebnisdetails ein.
Der Admission-Controller funktioniert, aber lehnt die Bereitstellung ab des DaemonSet-Objekts von Container Threat Detection konfigurieren Sie Ihre Zulassung. Verantwortlichen für die Dienst-Agent für Container Threat Detection um Objekte im Namespace kube-system zu verwalten.

Der Dienst-Agent für Container Threat Detection muss in der Lage sein, bestimmte Kubernetes-Objekte.

Weitere Informationen zur Verwendung von Admission-Controllern mit Container Threat Detection, siehe PodSecurityPolicy und Admission-Controller.

Fehlerbehebung bestätigen

Nachdem Sie den Fehler behoben haben, versucht Security Command Center automatisch, Container Threat Detection aktivieren. Warten Sie, bis die Aktivierung abgeschlossen ist, Mit den folgenden Schritten können Sie prüfen, ob Container Threat Detection aktiv ist:

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

Zur Seite „Kubernetes-Arbeitslasten“
Wählen Sie bei Bedarf Systemarbeitslasten anzeigen aus.
Filtern Sie die Arbeitslasten auf der Seite Arbeitslasten zuerst nach dem Clusternamen.
Suchen Sie nach der Arbeitslast container-watcher. Wenn container-watcher gleich 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 für den Cluster nicht aktiviert werden, da eine erforderliche Container-Image kann nicht von gcr.io abgerufen (heruntergeladen) werden, den Image-Host von Container Registry.

Das Hoch- oder Herunterladen eines Container-Images kann bei mehreren möglichen Gründen.

Prüfen Sie Folgendes:

Achten Sie darauf, dass Ihr VPC-Netzwerk, Ihr DNS oder Ihre Firewall-Einstellungen nicht Netzwerkzugriff vom Cluster auf den Image-Host gcr.io.
Wenn der Cluster privat ist, achten Sie darauf, dass der private Google-Zugriff ist aktiviert, um Zugriff auf den Image-Host gcr.io zu gewähren.
Wenn die Netzwerkeinstellungen oder der privater Google-Zugriff nicht die Ursache des Problems sind, finden Sie in der GKE-Dokumentation zur Fehlerbehebung ImagePullBackOff und ErrImagePull Fehler.

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

Das Container Threat Detection-Dienstkonto, das im Ergebnisdetails in der Google Cloud Console fehlen. Berechtigungen. Entweder alle oder einige Container Threat Detection-Ergebnisse sind nicht an Security Command Center gesendet.

So können Sie dieses Ergebnis beheben:

Gewähren Sie die Container Threat Detection-Dienst-Agent Rolle (roles/containerthreatdetection.serviceAgent) für die Dienstkonto. Weitere Informationen finden Sie unter Eine einzelne Rolle zuweisen

Wenn Sie alternativ eine benutzerdefinierte Rolle, achten Sie darauf, hat die Berechtigungen in der Rolle „Container Threat Detection-Dienst-Agent“.
Achten Sie darauf, dass keine IAM-ablehnung vorhanden ist. Richtlinien, die verhindern, dass das Dienstkonto einer der Berechtigungen in der Rolle „Container Threat Detection-Dienst-Agent“. Wenn es eine Ablehnungsrichtlinie ist, die den Zugriff blockiert, fügen Sie das Dienstkonto als Ausnahme Principal in der Ablehnungsrichtlinie festlegen.

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

Erforderliche IAM-Berechtigungen

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:

Stellen Sie das Projekt wieder her, wenn der Zeitraum für die Wiederherstellung des Projekts noch nicht verstrichen ist.

Hinweis: Sie können die Anzahl der verbleibenden Tage für die Wiederherstellung mithilfe der gcloud projects describe von Google Cloud CLI prüfen. beenden.
Wenn das Projekt endgültig gelöscht wurde, konfigurieren Sie ein neues oder vorhandenes Projekt für Logging-Exporte.

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 ID des Dienstkontos ist eine E-Mail-Adresse mit dem 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 Dienstkonten sowohl auf Organisations- als auch auf Projektebene haben, wenden Sie die Lösung für beide.

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

Schritt 1: Bestimmen, welcher Dienstperimeter Security Health Analytics blockiert

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 den eindeutigen Wert für VPC Service Controls. ID, z. B. 5e4GI409D6BTWfOp_6C-uSwmTpOQWcmW82sfZW9VIdRhGO5pXyCJPQ
3. Kopieren Sie im Feld Ressourcenpfad die ID des Projekts.
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.
3. Geben Sie im Suchfilterfeld die eindeutige ID des Fehlers ein.
  
  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.
7. Um den Anzeigenamen abzurufen, der der Zugriffsrichtlinien-ID entspricht, verwenden Sie über die gcloud CLI.
  
  Wenn Sie keine Abfragen auf Organisationsebene durchführen können, wenden Sie sich an Ihren Administrator um 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 Organisationsebene auf VPC Service Controls Wenn Sie keinen Zugriff auf Organisationsebene haben, um diese Schritte auszuführen.

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

So gewähren Sie einem Dienstkonto eingehenden Zugriff auf einen Dienstperimeter: diese Schritte ausführen.

Rufen Sie VPC Service Controls auf.

Zu „VPC Service Controls“
Wählen Sie in der Symbolleiste Ihre Google Cloud-Organisation aus.
Wählen Sie in der Drop-down-Liste die Zugriffsrichtlinie aus, die den Dienstperimeter enthält, auf den Sie Zugriff gewähren möchten.

Die mit der Zugriffsrichtlinie verknüpften Dienstperimeter werden in der Liste angezeigt.
Klicken Sie auf den Namen des Dienstes.
Klicken Sie auf Perimeter bearbeiten.
Klicken Sie im Navigationsmenü auf Richtlinie für eingehenden Traffic.
Klicken Sie auf Regel hinzufügen.
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 beides verwenden auf Organisations- und 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 unter Dienste die Option Alle Dienste oder jeden der folgenden aus: einzelne Dienste, die Security Health Analytics erfordert:
  - 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, Security Health Analytics kann keine Ergebnisse für diesen Dienst liefern.
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

Dienst-Agent von Security Command Center nicht über die erforderlichen Berechtigungen verfügt.

Die ID des Dienstkontos ist eine E-Mail-Adresse mit dem 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 Dienstkonten sowohl auf Organisations- als auch auf Projektebene haben, wenden Sie die Lösung für beide.

So können Sie dieses Ergebnis beheben:

Security Center-Dienst-Agent gewähren (roles/securitycenter.serviceAgent) dem Dienstkonto eine Rolle zu.

Weitere Informationen finden Sie unter Einzelnen Rolle.

Wenn Sie alternativ eine benutzerdefinierte Rolle, achten Sie darauf, hat die Berechtigungen im Security Center Service Agent-Rolle.
Achten Sie darauf, dass keine IAM-ablehnung vorhanden ist. Richtlinien, die verhindern, dass das Dienstkonto Berechtigungen in den erforderlichen Rollen. Wenn es eine Ablehnungsrichtlinie ist, die den Zugriff blockiert, fügen Sie das Dienstkonto als Ausnahme Principal in der Ablehnungsrichtlinie festlegen.

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

Nächste Schritte

Weitere Informationen zu Security Command Center-Fehlern