Leitfaden zur Validierung vor der Migration

Unterstützt in:

Google SecOps SOAR

In diesem Dokument wird ein systematischer, schrittweiser Diagnoseansatz zur Validierung der Google Security Operations-Instanz und der Authentifizierungseinrichtung vor der SOAR-Migration beschrieben. Dieser Leitfaden konzentriert sich auf den SAML- und OIDC-Standard, der für die Nutzerauthentifizierung und ‑autorisierung verwendet wird.

Einrichtung der Chronicle API validieren

So prüfen Sie, ob die Chronicle API in Ihrem Google Cloud Projekt, gehen Sie wie folgt vor:

1. Melden Sie sich in der Google Cloud Console an und wählen Sie in der oberen Navigationsleiste das richtige Google Cloud Projekt aus der Liste Projekt aus.
2. Öffnen Sie das Navigationsmenü (≡) und rufen Sie APIs & Dienste > Aktivierte APIs und Dienste auf.
3. Suchen Sie in der Liste der Aktivierten APIs und Dienste nach Chronicle API.

4. Wenn sie aufgeführt ist:Die API ist aktiviert.

   Wenn sie NICHT aufgeführt ist: Klicken Sie oben auf + APIs UND DIENSTE AKTIVIEREN, suchen Sie nach Chronicle API und klicken Sie auf Aktivieren.

So prüfen Sie, ob das Dienstkonto erstellt wurde:

1. Rufen Sie in der Google Cloud Console die Seite IAM auf.
2. Verborgene Konten einblenden (wichtiger Schritt): Sie müssen das Kästchen rechts neben der Filterleiste auswählen, in dem Von Google bereitgestellte Rollenzuweisungen hinzufügen steht.
3. Nach dem Agent suchen:Geben Sie in der Filterleiste chronicle ein. Sie suchen nach einer E‑Mail-Adresse, die diesem Muster entspricht: service-[PROJECT_NUMBER]@gcp-sa-chronicle.iam.gserviceaccount.com
4. Berechtigungen prüfen:Prüfen Sie, ob die Rolle Chronicle Service Agent zugewiesen ist. Wenn die Rolle fehlt, klicken Sie auf Bearbeiten Bearbeiten und fügen Sie sie wieder hinzu.

Google SecOps-Einrichtung validieren

1. Wählen Sie in der Google Cloud Console das richtige Google Cloud Projekt aus der Liste aus.
2. Rufen Sie Sicherheit > Google SecOps auf. Der Tab Einmalanmeldung wird angezeigt.
3. Wenn Google SecOps aktiviert ist, sollte ein Tab mit dem Namen Einmalanmeldung angezeigt werden. Wenn nicht, ist die Initiierung des potenziellen Kunden nicht abgeschlossen. Geben Sie die Google Cloud Projekt-ID in das Google-Formular ein, das in der In-Product-Benachrichtigung enthalten ist. Bestätigen Sie das Migrationsdatum und das Zeitfenster und senden Sie das Formular ab. Wenn Sie innerhalb von 72 Stunden nach der Einreichung keine Antwort erhalten, wenden Sie sich an [e-mail].
4. Wenn der Tab vorhanden ist, klicken Sie auf Zu SecOps wechseln. Eine erfolgreiche Anmeldung bestätigt, dass die Authentifizierungskonfiguration korrekt ist. Wenn die Anmeldung fehlschlägt, verwenden Sie den nächsten Abschnitt, um die Konfiguration zu debuggen. Wenn die Anmeldung fehlschlägt, verwenden Sie den nächsten Abschnitt, um die Konfiguration zu debuggen.

SAML-Ablauf und Fehlerbehebung

In diesem Abschnitt finden Sie eine Übersicht über den SAML-Authentifizierungsprozess und einen systematischen Ansatz zur Diagnose und Behebung häufiger Konfigurationsprobleme.

Architektur des Authentifizierungsworkflows

Das Verständnis des Anfrageablaufs ist entscheidend, um Fehlerpunkte zu isolieren. Das folgende Diagramm veranschaulicht den sequenziellen Pfad einer erfolgreichen Anmeldung.

Schrittweise Anleitung zur Fehlerbehebung

Zur Diagnose und Nachverfolgung des SAML-Authentifizierungsprozesses können Sie die webbasierten Dienstprogramme verwenden, die in den folgenden Abschnitten aufgeführt sind.

Google empfiehlt zwar keine bestimmten Produkte, aber die folgenden Tools können bei der Fehlerbehebung helfen:

• SAML-Validierung: https://www.samltool.io/
  • Zweck:Wird zum Decodieren und Validieren von unformatierten SAML-Anfragen und ‑Antworten verwendet.
• JWT-Prüfung: https://www.jwt.io/
  • Zweck:Wird verwendet, um die Ansprüche und Inhalte von JSON Web Tokens (JWTs) zu prüfen.

Phase 1: Umgebung vorbereiten

Bevor Sie beginnen, müssen Sie Ihre Browserumgebung vorbereiten, um den Netzwerkverkehr zu erfassen. Führen Sie dazu die folgenden Schritte aus:

1. Öffnen Sie einen neuen Browsertab oder verwenden Sie ein Inkognitofenster.

2. Öffnen Sie die Entwicklertools mit der Tastenkombination für Ihr Betriebssystem:

   • Windows: Drücken Sie F12.
   • Linux: Drücken Sie Strg + Umschalt + I.
   • macOS: Drücken Sie Cmd + Option + I.

3. Rufen Sie den Tab Netzwerk auf.

4. Wählen Sie das Kästchen Protokoll beibehalten aus, damit bei Weiterleitungen keine Daten verloren gehen.

   

5. Rufen Sie die URL Ihrer Google SecOps-Umgebung auf, um den Anmeldevorgang zu starten. Sie erhalten diese URL per E‑Mail, nachdem Sie die Google SecOps-Einrichtung in Schritt 5 der Migrationsphase 1 für eigenständige SOAR-Kunden abgeschlossen haben. Der Betreff der E‑Mail lautet Your Google SecOps instance is ready.

Phase 2: SAML-Anfrage an den IdP validieren

In diesem Schritt wird die erste Nachricht überprüft, die von Google Cloud an Ihren Identitätsanbieter (IdP) gesendet wird.

1. Anfrage suchen:Suchen Sie in der Filterleiste des Tabs Netzwerk nach saml.

   

2. Daten extrahieren:Wählen Sie die Anfrage aus und klicken Sie auf den Tab Nutzlast. Suchen Sie den Abfragestringparameter mit der Bezeichnung SAMLRequest.

   

3. Decodieren:Kopieren Sie den Wert der Anfrage und fügen Sie ihn in das Tool SAML-Validierung (samltool.io) ein, um ihn zu decodieren.

   

4. Überprüfung :

   • Prüfen Sie das Anfrageziel.
   • Bestätigen Sie, dass diese URL mit den Konfigurationseinstellungen in Ihrem IdP übereinstimmt.

Phase 3: SAML-Antwort vom IdP validieren

In diesem Schritt werden die Attribute überprüft, die nach der Authentifizierung vom IdP an zurückgegeben werden. Google Cloud

1. Antwort suchen:Suchen Sie in der Filterleiste des Tabs Netzwerk nach signin-callback.

   

2. Daten extrahieren:Wählen Sie die Anfrage aus und klicken Sie auf den Tab Nutzlast. Suchen Sie die SAMLResponse-Daten.

   

3. Decodieren:Kopieren Sie den Wert der Antwort und fügen Sie ihn in das Tool SAML-Validierung ein.

4. Überprüfung :

   • Prüfen Sie die zurückgegebenen Ansprüche (Attribute) wie groups, first name, last name, und email.
   • Wichtig: Achten Sie darauf, dass diese Attribute mit der Konfiguration in den Workforce-Pool-Einstellungen in Google Cloudübereinstimmen.

   • Bestätigen Sie, dass die Werte für den jeweiligen Nutzer, der sich anmelden möchte, korrekt sind.

     

Die folgende Abbildung zeigt eine Attributzuordnung:

Die Zuordnung in der Abbildung ist wie folgt:

• google.subject = assertion.subject
• attribute.last_name = assertion.attributes.last_name[0]
• attribute.user_email = assertion.attributes.user_email[0]
• attribute.first_name = assertion.attributes.first_name[0]
• google.groups = assertion.attributes.groups

Der linke Teil ist immer gleich. Es ist die Google-Syntax. Die rechte Seite entspricht den Attributschlüsseln für Ansprüche, die in der SAML-Antwort angezeigt werden.

Das [0] ist für die angegebenen Attribute (last_name, user_email, first_name) entscheidend und für subject und groups nicht relevant.

Phase 4: Google SecOps-Authentifizierung validieren

In diesem Schritt wird geprüft, ob Google Cloud den Nutzer authentifiziert, damit er sich in Google SecOps SOAR anmelden kann.

1. Token im Browser des Nutzers suchen:Suchen Sie in der Filterleiste des Tabs Netzwerk nach dem Endpunkt auth/siem.

   

2. Daten extrahieren:Wählen Sie die Anfrage aus und rufen Sie den Tab Nutzlast auf. Suchen Sie die jwt-String.

3. Decodieren: Kopieren Sie die JWT-String und fügen Sie sie in das Tool JWT-Prüfung (jwt.io) ein.

   

4. Überprüfung :

   • Vergleichen Sie die decodierten Ansprüche für given_name, family_name, email und idpgroups.
   • Übereinstimmung bestätigen:Diese Werte müssen genau mit den Attributen übereinstimmen, die in Phase 3 (SAML-Antwort) validiert wurden.
   • Wenn die Werte übereinstimmen und Sie trotzdem keinen Zugriff haben, prüfen Sie die Rollenzuweisung in IAM. Achten Sie darauf, dass allen Nutzern eine der vordefinierten Chronicle-Rollen zugewiesen ist. Verwenden Sie dazu das richtige Hauptkontoformat für Ihre Identitätseinrichtung (Mitarbeiteridentitätsföderation oder Cloud Identity für von Google verwaltete Konten).

Phase 5: Zugriff auf SOAR-Berechtigungen validieren

In diesem Schritt wird bestätigt, dass das System Berechtigungen in SOAR über die Seite Gruppenzuordnung der Plattform korrekt zuweist.

Administratoren haben automatisch Zugriff auf SOAR, da die Seite Gruppenzuordnung Standardzugriff ermöglicht.

Sie können den Gruppenzugriff für Ihre Nutzer validieren, indem Sie einige Zuordnungen zu IdP-Gruppen in dieser neuen SOAR-Instanz hinzufügen. Neue Instanzen haben standardmäßig eine leere Seite Gruppenzuordnung. Wenn Sie den Gruppenzugriff für andere Nutzer validieren möchten, fügen Sie der neuen SOAR-Instanz Zuordnungen zu IdP-Gruppen hinzu. Führen Sie dazu die folgenden Schritte aus:

1. Kopieren Sie die Gruppenzuordnungen von der Seite Gruppenzuordnungen in Ihrer vorhandenen SOAR-Instanz.
2. Bitten Sie einen Nutzer in der IdP-Gruppe, auf die neue Google SecOps-URL zuzugreifen.

3. Wenn der Nutzer nicht auf SOAR zugreifen kann, führen Sie diese Schritte zur Fehlerbehebung aus:

   a. Antwort prüfen:Öffnen Sie die auth/siem-Anfrage aus Phase 4 und wählen Sie den Tab Vorschau aus.

   b. Berechtigungen prüfen:Suchen Sie in der JSON-Antwort nach dem Objekt permissions.

Optional: Um Zeit zu sparen, können Sie diese Zuordnungen in Ihre vorhandene Google SecOps-Instanz unter Einstellungen > Erweitert > Gruppenzuordnung kopieren.

Hinweis: Wenn Sie die Migration der ersten Phase abschließen, werden alle Zuordnungen, die Sie der neuen Google SecOps-Instanz hinzugefügt haben, durch die Gruppenzuordnungen aus Ihrer vorhandenen SOAR-Instanz überschrieben. Sie finden diese Einstellungen unter Einstellungen > Erweitert > Gruppenzuordnung.

OIDC-Ablauf und Fehlerbehebung

In diesem Abschnitt finden Sie eine Übersicht über den OIDC-Authentifizierungsprozess und einen systematischen Ansatz zur Diagnose und Behebung häufiger Integrationsprobleme.

Architektur des Authentifizierungsworkflows

Das Verständnis des Anfrageablaufs ist entscheidend, um Fehlerpunkte zu isolieren. Das folgende Diagramm veranschaulicht den sequenziellen Pfad einer erfolgreichen Anmeldung.

Schrittweise Anleitung zur Fehlerbehebung bei OIDC

Zur Diagnose und Nachverfolgung des OIDC-Authentifizierungsprozesses können Sie Browser-Entwicklertools und Online-JWT-Decoder verwenden.

• JWT-Prüfung: https://www.jwt.io/
  • Zweck:Wird verwendet, um die Ansprüche und Inhalte von JSON Web Tokens (JWTs) zu prüfen.

Phase 1: Umgebung vorbereiten

Bevor Sie beginnen, müssen Sie Ihre Browserumgebung vorbereiten, um den Netzwerktraffic zu erfassen. Führen Sie dazu die folgenden Schritte aus:

1. Öffnen Sie einen neuen leeren Browsertab oder ein Inkognitofenster.

2. Öffnen Sie die Entwicklertools mit der Tastenkombination für Ihr Betriebssystem:

   • Windows: Drücken Sie F12.
   • Linux: Drücken Sie Strg + Umschalt + I.
   • macOS: Drücken Sie Cmd + Option + I.

3. Rufen Sie den Tab Netzwerk auf.

4. Wählen Sie das Kästchen Protokoll beibehalten aus, damit bei Weiterleitungen keine Daten verloren gehen.

   

5. Rufen Sie die URL Ihrer Google SecOps-Umgebung auf, um den Anmeldevorgang zu starten. Sie erhalten diese URL per E‑Mail, nachdem Sie die Google SecOps-Einrichtung in Schritt 5 der Migrationsphase 1 für eigenständige SOAR-Kunden abgeschlossen haben. Der Betreff der E‑Mail lautet YourGoogle SecOps instance is ready.

Phase 2: Autorisierungsanfrage an einen OIDC-Anbieter validieren

In diesem Schritt wird die erste Weiterleitung von Google Cloud an Ihren OpenID Connect-Anbieter (IdP) überprüft.

1. Anfrage suchen:Suchen Sie auf dem Tab Netzwerk nach der ersten Weiterleitung zum Autorisierungsendpunkt Ihres OIDC-Anbieters. Die URL enthält in der Regel Parameter wie client_id, redirect_uri, scope, response_type und state.

   

2. Überprüfung :

   • Bestätigen Sie, dass die client_id mit der in Ihrem OIDC-Anbieter konfigurierten übereinstimmt.
   • Achten Sie darauf, dass die redirect_uri genau mit https://auth.backstory.chronicle.security/signin-callback/locations/global/workforcePools/POOL_ID/provider/PROVIDER_ID übereinstimmt. Ersetzen Sie dabei POOL_ID und PROVIDER_ID durch Ihren Pool und Bereitsteller aus der Mitarbeiteridentitätsföderation.
   • Prüfen Sie, ob response_type auf „code“ gesetzt ist.
   • Notieren Sie sich den Parameter „scope“, der „openid“ und alle anderen Bereiche enthalten sollte, die zum Freigeben der erforderlichen Ansprüche erforderlich sind (z. B. „email“, „profile“).

Phase 3: Callback und Tokenaustausch validieren

In diesem Schritt wird die Antwort des IdP anüberprüft Google Cloud.

1. Callback suchen : Suchen Sie auf dem Tab Netzwerk nach der Anfrage an die URL für den Sign-in-Callback (.../signin-callback/...).

   

2. Daten prüfen:Prüfen Sie die URL-Parameter dieser Anfrage. Sie sollte einen Code-Parameter enthalten, der von Ihrem OIDC-IdP bereitgestellt wird.

3. Hinter den Kulissen:Die Mitarbeiteridentitätsföderation tauscht diesen Code gegen Tokens (ID-Token, Zugriffstoken) vom Tokenendpunkt des OIDC-Anbieters aus. Fehler in dieser Phase sind oft in Cloud Logging für die Mitarbeiteridentitätsföderation sichtbar.

   • Attributweitergabe und vollständiges Token überprüfen:So prüfen Sie, ob Ihre Attributzuordnung in der Mitarbeiteridentitätsföderation die erwarteten Ergebnisse liefert:
     • Fügen Sie die Weiterleitungs-URI, die in der Konfiguration des Anbieters der Mitarbeiteridentitätsföderation angegeben ist, den Weiterleitungs-URIs Ihres Anbieters hinzu (z. B. https://auth.cloud.google/signin-callback/locations/global/workforcePools/POOL_ID/providers/PROVIDER_ID).
     • Rufen Sie Ihren Anbieter der Mitarbeiteridentitätsföderation auf, um das IdP-Token zu debuggen. Sie können auch das vollständige Token prüfen. Weitere Informationen finden Sie unter Produktkonfiguration überprüfen.

   

Phase 4: Google SecOps-Authentifizierung validieren

In diesem Schritt wird geprüft, ob Google Cloud den Nutzer authentifiziert, damit er sich in Google SecOps SOAR anmelden kann.

1. Token im Browser des Nutzers suchen:Suchen Sie in der Filterleiste des Tabs Netzwerk nach dem Endpunkt auth/siem.

   

2. Daten extrahieren:Wählen Sie die Anfrage aus und rufen Sie den Tab Nutzlast auf. Suchen Sie die jwt-String.

3. Decodieren: Kopieren Sie die JWT-String und fügen Sie sie in das Tool JWT-Prüfung (jwt.io) ein.

   

4. Überprüfung :

   • Vergleichen Sie die decodierten Ansprüche für sub, given_name, family_name, email und idpgroups.
   • Übereinstimmung bestätigen: Diese Werte müssen den Attributen entsprechen, die von Ihrem OIDC-Anbieter freigegeben wurden, und der Art und Weise, wie sie in den Attributzuordnungen der Mitarbeiteridentitätsföderation zugeordnet sind. Beispielsweise sollte attribute.first_name in Google Cloud auf given_name im JWT abgebildet werden.
   • IAM-Rollen: Wenn die Ansprüche korrekt sind, der Zugriff aber mit einer Meldung wie Cannot Authenticate user, because user does not have access to the GCP project..., verweigert wird, prüfen Sie die IAM-Rollenzuweisungen. Achten Sie darauf, dass den Gruppen des Nutzers (idp_groups im JWT) die erforderlichen Rollen mit dem richtigen principalSet-Format zugewiesen werden (z. B. principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/group/IDP_GROUP_NAME).

Phase 5: Zugriff auf SOAR-Berechtigungen validieren

In diesem Schritt wird bestätigt, dass das System Berechtigungen in SOAR über die Seite Gruppenzuordnung der Plattform korrekt zuweist.

Administratoren haben automatisch Zugriff auf SOAR, da die Seite Gruppenzuordnung Standardzugriff ermöglicht.

Sie können den Gruppenzugriff für Ihre Nutzer validieren, indem Sie einige Zuordnungen zu IdP-Gruppen in dieser neuen SOAR-Instanz hinzufügen. Neue Instanzen haben standardmäßig eine leere Seite Gruppenzuordnung. Wenn Sie den Gruppenzugriff für andere Nutzer validieren möchten, fügen Sie der neuen SOAR-Instanz Zuordnungen zu IdP-Gruppen hinzu. Führen Sie dazu die folgenden Schritte aus:

1. Kopieren Sie die Gruppenzuordnungen von der Seite Gruppenzuordnungen in Ihrer vorhandenen SOAR-Instanz.
2. Bitten Sie einen Nutzer in der IdP-Gruppe, auf die neue Google SecOps-URL zuzugreifen.

3. Wenn der Nutzer nicht auf SOAR zugreifen kann, führen Sie diese Schritte zur Fehlerbehebung aus:

   a. Antwort prüfen:Öffnen Sie die auth/siem-Anfrage aus Phase 4 und wählen Sie den Tab Vorschau aus.

   b. Berechtigungen prüfen:Suchen Sie in der JSON-Antwort nach dem Objekt permissions.

Optional: Um Zeit zu sparen, können Sie diese Zuordnungen in Ihre vorhandene Google SecOps-Instanz unter Einstellungen > Erweitert > Gruppenzuordnung kopieren.

Hinweis: Wenn Sie die Migration der ersten Phase abschließen, werden alle Zuordnungen, die Sie der neuen Google SecOps-Instanz hinzugefügt haben, durch die Gruppenzuordnungen aus Ihrer vorhandenen SOAR-Instanz überschrieben. Sie finden diese Einstellungen unter Einstellungen > Erweitert > Gruppenzuordnung.

Häufige OIDC-Fehler :

• invalid_redirect_uri vom IdP: Achten Sie darauf, dass die in Ihrem IdP konfigurierte Weiterleitungs-URI genau mit https://auth.backstory.chronicle.security/signin-callback/locations/global/workforcePools/POOL_ID/provider/PROVIDER_ID übereinstimmt. Ersetzen Sie dabei POOL_ID und PROVIDER_ID durch Ihren Pool und Anbieter aus der Mitarbeiteridentitätsföderation. Auch ein nachgestellter Schrägstrich oder eine Abweichung zwischen http und https löst diesen Fehler aus.

• Fehlende Ansprüche im JWT :

  1. IdP-Seite:Prüfen Sie, ob der OIDC-Client so konfiguriert ist, dass die erforderlichen Ansprüche (die in der Mitarbeiteridentitätsföderation zugeordnet sind, z. B. sub, groups, email, given_name, family_name) im ID-Token freigegeben werden.

  2. Seite der Mitarbeiteridentitätsföderation:Achten Sie darauf, dass diese eingehenden Ansprüche im Abschnitt „Attributzuordnung“ der Mitarbeiteridentitätsföderation korrekt zugeordnet sind (z. B. google.groups=assertion.groups). Wenn ein Anspruch im Token vorhanden ist, aber nicht in der Mitarbeiteridentitätsföderation zugeordnet ist, kann die SOAR-Plattform den Nutzer möglicherweise nicht autorisieren. Informationen dazu, wie Sie prüfen, ob Ihre Attributzuordnung die erwarteten Ergebnisse liefert, finden Sie unter Anbieterkonfiguration überprüfen.

Gruppenzuordnungen nach der Migration

Gruppenzuordnungen sind auch nach Abschluss der Migration in Google SecOps entscheidend

Nach der Migration behält die migrierte Instanz die Gruppenzuordnungen bei. Sie dienen als Grundlage für die Bestimmung des Nutzerzugriffs auf SOAR. Sie müssen dafür sorgen, dass jeder Nutzer auf dieser Seite zugeordnet ist, um auf Google SecOps zugreifen zu können. Weitere Informationen finden Sie unter Auf eine Instanz zugreifen.

Benötigen Sie weitere Hilfe? Erhalten Sie Antworten von Community-Mitgliedern und Google SecOps-Experten.