Probleme mit dem Discovery-Dienst beheben

Auf dieser Seite erfahren Sie, wie Sie Probleme mit dem Erkennungsdienst von Sensitive Data Protection beheben. Weitere Informationen zum Erkennungsdienst finden Sie unter Daten profile. Informationen zum Aufrufen von Fehlern im Zusammenhang mit Ihrer Erkennungsscankonfiguration finden Sie unter Konfigurationsfehler ansehen.

Für den Dienst-Agent-Container ist die DLP API nicht aktiviert

Dieses Problem tritt auf, wenn Sie eine Scankonfiguration auf Organisationsebene erstellen und nicht die serviceusage.services.enable Berechtigung für das Projekt haben, das Sie als Dienst-Agent Container ausgewählt haben. Sensitive Data Protection kann die DLP API für das Projekt nicht automatisch aktivieren.

Permission denied to enable service [dlp.googleapis.com]

Führen Sie einen der folgenden Schritte aus, um dieses Problem zu beheben. In beiden Fällen müssen Sie die erforderlichen Berechtigungen erhalten. Weitere Informationen finden Sie unter Rollen, die für die Arbeit mit Datenprofilen auf Organisations- oder Ordnerebene erforderlich sind.

Neuen Dienst-Agent-Container erstellen

  1. Bitten Sie Ihren Administrator, Ihnen die Rolle „Projektersteller“ (roles/resourcemanager.projectCreator) für die Organisation zuzuweisen.
  2. Bearbeiten Sie Ihre Scankonfiguration auf Organisationsebene.
  3. Erstellen Sie im Abschnitt Dienst-Agent-Container einen neuen Dienst-Agent-Container, indem Sie auf Erstellen klicken und der Anleitung folgen.
  4. Speichern Sie Ihre Konfiguration.

Dienst-Agent-Container aktualisieren

  1. Bitten Sie Ihren Administrator, Ihnen eine Rolle mit der Berechtigung serviceusage.services.enable für das Projekt zuzuweisen, das Sie als Dienst-Agent-Container ausgewählt haben.
  2. Rufen Sie die Details der Scan konfiguration auf, um die aktiven Fehler zu sehen.
  3. Suchen Sie diesen Fehler und klicken Sie auf Reparieren.

Der Dienst-Agent ist nicht berechtigt, eine Spalte mit Zugriffssteuerung zu lesen

Dieses Problem tritt auf, wenn Sie mithilfe von Richtlinien-Tags eine Profilerstellung für eine Tabelle durchführen, die die Sicherheit auf Spaltenebene erzwingt. Wenn der Dienst-Agent nicht berechtigt ist, auf die eingeschränkte Spalte zuzugreifen, zeigt Sensitive Data Protection den folgenden Fehler an:

Permission denied for DLP API service account 'SERVICE_AGENT_ID'
while accessing a BigQuery table. Access Denied: BigQuery BigQuery: User does
not have permission to access policy tag "POLICY_TAG_ID" on column FIELD_NAME.

Zum Beheben dieses Problems erteilen Sie dem Dienst-Agent auf der Seite IAM (Identity and Access Management) die Rolle Detaillierter Lesezugriff.

IAM aufrufen

Sensitive Data Protection wiederholt regelmäßig die Profilerstellung für Daten, für die es keine Profile erstellen konnte.

Weitere Informationen zum Zuweisen einer Rolle finden Sie unter Einzelne Rolle zuweisen.

Der Dienst-Agent hat keinen Datenprofilzugriff

Dieses Problem tritt auf, wenn jemand in Ihrer Organisation eine Scankonfiguration auf Organisations- oder Ordnerebene erstellt. Wenn Sie die Details zur Scankonfiguration aufrufen, sehen Sie, dass der Wert für Scanstatus Aktiv mit Fehlern lautet. Wenn Sie sich den Fehler ansehen, zeigt Sensitive Data Protection die folgende Fehlermeldung an:

None of the driver projects (PROJECT_ID) have MISSING_PERMISSION
permission for organizations/ORGANIZATION_ID.

Dieser Fehler ist aufgetreten, da Sensitive Data Protection Ihrem Dienst-Agent während der Erstellung der Scankonfiguration nicht automatisch die Rolle DLP-Organisationsdatendaten-Treiber zuweisen konnte. Der Ersteller der Scankonfiguration hat keine Berechtigungen zum Gewähren des Zugriffs auf die Datenprofilerstellung, sodass Sensitive Data Protection dies in seinem Namen nicht tun konnte.

Informationen zum Beheben dieses Problems finden Sie unter Datenprofiling-Zugriff auf einen Dienst-Agent gewähren.

Das Dienstkonto ist nicht berechtigt, eine Tabelle abzufragen

Dieses Problem tritt auf, wenn Sensitive Data Protection versucht, ein Profil für eine Tabelle zu erstellen, die der Dienst-Agent nicht abfragen darf. Sensitive Data Protection zeigt den folgenden Fehler an:

Permission denied error: Permission denied for DLP API service account 'SERVICE_AGENT_ID'
while accessing BigQuery table. Access Denied: Table TABLE: User does not have
permission to query table TABLE. Permission denied for DLP API service account
'SERVICE_AGENT_ID' while accessing BigQuery table. Access Denied: Table TABLE:
User does not have permission to query TABLE. [TIMESTAMP]

Prüfen Sie, ob die Tabelle noch vorhanden ist. Wenn die Tabelle vorhanden ist, führen Sie die folgenden Schritte aus.

  1. Aktivieren Sie Cloud Shell in der Google Cloud Console.

    Cloud Shell aktivieren

    Unten in der Google Cloud Console wird eine Cloud Shell Sitzung gestartet und eine Eingabeaufforderung angezeigt. Cloud Shell ist eine Shell-Umgebung in der das Google Cloud CLI bereits installiert ist und Werte für Ihr aktuelles Projekt bereits festgelegt sind. Das Initialisieren der Sitzung kann einige Sekunden dauern.

  2. Rufen Sie die aktuelle IAM-Richtlinie für die Tabelle ab und drucken Sie sie an stdout:

    bq get-iam-policy TABLE

    Ersetzen Sie TABLE durch den vollständigen Ressourcennamen der BigQuery-Tabelle im Format PROJECT_ID:DATASET_ID.TABLE_ID, z. B. project-id:dataset-id.table-id.

  3. Weisen Sie dem Dienst-Agent die Rolle DLP API-Dienst-Agent (roles/dlp.serviceAgent) zu:

    bq add-iam-policy-binding --member=serviceAccount:SERVICE_AGENT_ID \
    --role=roles/dlp.serviceAgent TABLE

    Dabei gilt:

    • SERVICE_AGENT_ID: Die ID des Dienst-Agents, der die Tabelle abfragen muss, z. B. service-0123456789@dlp-api.iam.gserviceaccount.com.

    • TABLE: Der vollständige Ressourcenname der BigQuery-Tabelle im Format PROJECT_ID:DATASET_ID.TABLE_ID, z. B. project-id:dataset-id.table-id.

      Die Ausgabe sieht etwa so aus:

    Successfully added member 'SERVICE_AGENT_ID' to role 'roles/dlp.serviceAgent' in IAM policy for table 'TABLE':

{
 "bindings": [
   {
     "members": [
       "serviceAccount:SERVICE_AGENT_ID"
     ],
     "role": "roles/dlp.serviceAgent"
   }
 ],
 "etag": "BwXNAPbVq+A=",
 "version": 1
}

    Sensitive Data Protection wiederholt regelmäßig die Profilerstellung für Daten, für die es keine Profile erstellen konnte.

Das Dienstkonto ist nicht berechtigt, in einem Pub/Sub-Thema zu veröffentlichen

Dieses Problem tritt auf, wenn Sensitive Data Protection versucht, Benachrichtigungen in einem Pub/Sub-Thema zu veröffentlichen, für das der Dienst-Agent keinen Veröffentlichungszugriff hat. Sensitive Data Protection zeigt den folgenden Fehler an:

Permission missing to publish notifications on Cloud Pub/Sub topic 'TOPIC_NAME'.
The DLP API service account 'SERVICE_AGENT_ID' must must have at least the Pub/Sub Publisher role.

Um dieses Problem zu beheben, gewähren Sie Ihrem Dienst-Agent Veröffentlichungszugriff, auf Projekt- oder Themaebene. Ein Beispiel für eine Rolle mit Veröffentlichungszugriff ist die Rolle Pub/Sub-Publisher.

Wenn es Konfigurations- oder Berechtigungsprobleme mit dem Pub/Sub-Thema gibt, versucht Sensitive Data Protection bis zu zwei Wochen lang, die Pub/Sub-Benachrichtigung zu senden. Nach zwei Wochen wird die Benachrichtigung verworfen.

Mit der Inspektionsvorlage kann kein Profil für Daten in einer anderen Region erstellt werden

Dieses Problem tritt auf, wenn Sensitive Data Protection versucht, ein Profil für Daten zu erstellen, die sich nicht in derselben Region wie die Inspektionsvorlage befinden. Sensitive Data Protection zeigt den folgenden Fehler an:

Data in region DATA_REGION cannot be profiled using template in region
TEMPLATE_REGION. Regional template can only be used to profile data
in the same region. If profiling data in multiple regions, use a global template.

In dieser Fehlermeldung ist DATA_REGION die Region, in der sich die Daten befinden, und TEMPLATE_REGION die Region, in der sich die Inspektions vorlage befindet.

Zur Behebung dieses Problems können Sie die regionsspezifische Vorlage in die Region global kopieren:

  1. Kopieren Sie die Inspektionsvorlage in die Region global.

  2. Kopieren Sie auf der Seite Details zur Inspektionsvorlage den vollständigen Ressourcennamen der Vorlage. Der vollständige Ressourcenname hat dieses Format:

    projects/PROJECT_ID/locations/REGION/inspectTemplates/TEMPLATE_ID

  3. Bearbeiten Sie die Scankonfiguration und geben Sie den vollständigen Ressourcennamen der neuen Inspektionsvorlage ein.

  4. Klicken Sie auf Speichern.

Sensitive Data Protection wiederholt regelmäßig die Profilerstellung für Daten, für die es keine Profile erstellen konnte.

Sensitive Data Protection hat versucht, ein Profil für eine nicht unterstützte Tabelle zu erstellen

Dieses Problem tritt auf, wenn Sensitive Data Protection versucht, ein Profil für eine nicht unterstützte Tabelle zu erstellen. Für diese Tabelle erhalten Sie trotzdem ein Teilprofil mit den Metadaten der Tabelle. Das Teilprofil enthält jedoch den folgenden Fehler:

Unimplemented error: Table of type `TABLE_TYPE` is not currently supported for inspection. [DATE_TIME].

Wenn Sie keine Teilprofile und Fehler für nicht unterstützte Tabellen erhalten möchten, gehen Sie so vor:

  1. Bearbeiten Sie die Scankonfiguration.
  2. Klicken Sie im Schritt Zeitpläne verwalten auf Zeitplan bearbeiten.
  3. Klicken Sie im angezeigten Bereich auf den Tab Bedingungen.
  4. Klicken Sie im Abschnitt Tabellen für die Profilerstellung auf Unterstützte Tabellen profilieren.

Weitere Informationen finden Sie unter Zeitpläne verwalten.

Der vorgefertigte Looker Studio-Bericht wird nicht richtig geladen

Weitere Informationen finden Sie unter Fehler mit dem vorgefertigten Bericht beheben.

Weitere Informationen finden Sie unter Fehlerbehebung bei Fehlern in der Dokumentation zum Steuern des IAM-Zugriffs auf Ressourcen basierend auf der Datensensibilität.

Nächste Schritte