Anleitung zur Validierung vor der Migration

Unterstützt in:

Google SecOps SOAR

In diesem Dokument wird ein systematischer, schrittweiser Diagnoseansatz zum Validieren der Google Security Operations-Instanz und der Authentifizierungseinrichtung vor der SOAR-Migration beschrieben. In dieser Anleitung geht es um den SAML- und OIDC-Standard, der für die Nutzerauthentifizierung und ‑autorisierung verwendet wird.

Validierung der Chronicle API-Einrichtung

So prüfen Sie, ob die Chronicle API in Ihrem Google Cloud -Projekt richtig konfiguriert ist:

1. Melden Sie sich in der Google Cloud Console an und wählen Sie in der oberen Navigationsleiste in der Liste Projekt das richtige Google Cloud Projekt aus.
2. Öffnen Sie das Navigationsmenü (≡) und wählen Sie APIs und Dienste > Aktivierte APIs und Dienste aus.
3. Suchen Sie in der Liste Aktivierte 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 IAM-Seite auf.
2. Verborgene Konten einblenden (wichtiger Schritt): Sie müssen das Kästchen rechts neben der Filterleiste mit der Aufschrift Von Google bereitgestellte Rollenzuweisungen einschließen anklicken.
3. Nach dem Agent suchen:Geben Sie in der Filterleiste chronicle ein. Sie suchen nach einer E‑Mail-Adresse, die diesem bestimmten Muster entspricht: service-[PROJECT_NUMBER]@gcp-sa-chronicle.iam.gserviceaccount.com
4. Berechtigungen prüfen:Das Dienstkonto muss die Rolle Chronicle-Dienst-Agent haben. 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. Gehen Sie zu Sicherheit > Google SecOps. Der Tab Einmalanmeldung wird angezeigt.
3. Wenn Google SecOps aktiviert ist, sollte ein Tab mit dem Namen Einmalanmeldung angezeigt werden. Andernfalls ist die Initiierung des potenziellen Kunden unvollständig. Geben Sie die Google Cloud Projekt-ID im Google-Formular an, das in der In-Product-Benachrichtigung enthalten ist. Bestätigen Sie das Datum und die Uhrzeit der Migration und senden Sie das Formular ab. Wenn Sie innerhalb von 72 Stunden nach dem Einreichen keine Antwort erhalten, wenden Sie sich an [e-mail].
4. Wenn der Tab vorhanden ist, klicken Sie auf Zu SecOps. Eine erfolgreiche Anmeldung bestätigt, dass die Authentifizierungskonfiguration korrekt ist. Wenn die Anmeldung fehlschlägt, können Sie die Konfiguration anhand des nächsten Abschnitts debuggen. Wenn die Anmeldung fehlschlägt, können Sie die Konfiguration anhand des nächsten Abschnitts debuggen.

SAML-Ablauf und Fehlerbehebung

In diesem Abschnitt finden Sie einen Überblick über den SAML-Authentifizierungsprozess und eine systematische Vorgehensweise zur Diagnose und Behebung häufiger Konfigurationsprobleme.

Architektur des Authentifizierungsworkflows

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

Schritt-für-Schritt-Anleitung zur Fehlerbehebung

Um den SAML-Authentifizierungsprozess effektiv zu analysieren und nachzuvollziehen, können Sie die webbasierten Tools 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:Dient zum Prüfen der Ansprüche und Inhalte von JSON Web Tokens (JWTs).

Phase 1: Umgebung vorbereiten

Bevor Sie beginnen, müssen Sie dafür sorgen, dass Ihr Browser bereit ist, Netzwerkverkehr zu erfassen. Führen Sie dazu die folgenden Schritte aus:

1. Öffnen Sie einen neuen Tab im Browser 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 + Wahltaste + I.

3. Rufen Sie den Tab Netzwerk auf.

4. Klicken Sie das Kästchen Protokoll beibehalten an, 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 ursprüngliche Nachricht bestätigt, die von Google Cloud an Ihren Identitätsanbieter (Identity Provider, IDP) gesendet wurde.

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

   

2. Daten extrahieren:Wählen Sie die Anfrage aus und klicken Sie auf den Tab Payload. Suchen Sie nach dem Abfragestringparameter mit dem Label SAMLRequest.

   

3. Decodieren:Kopieren Sie den Anfragewert 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.
   • Prüfen Sie, ob diese URL mit den Konfigurationseinstellungen in Ihrer Seite „Problemdetails“ übereinstimmt.

Phase 3: SAML-Antwort vom IdP validieren

In diesem Schritt werden die vom Identitätsanbieter zurückgegebenen Attribute nach der Authentifizierung für Google Cloud bestätigt.

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 Payload. SAMLResponse-Daten finden

   

3. Decodieren:Kopieren Sie den Antwortwert und fügen Sie ihn in das Tool SAML Validation ein.

4. Überprüfung:

   • Prüfen Sie die zurückgegebenen Behauptungen (Attribute) wie groups, first name, last name und email.
   • Kritisch:Diese Attribute müssen mit der Konfiguration in den Personalpool-Einstellungen in Google Cloudübereinstimmen.

   • Prüfen Sie, ob die Werte für den jeweiligen Nutzer, der sich anmelden möchte, korrekt sind.

     

Das folgende Bild zeigt eine Attributzuordnung:

Die Zuordnung im Bild sieht so aus:

• 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 derselbe, nämlich die Google-Syntax. Die rechte Seite entspricht den Attributschlüsseln für Ansprüche, die in der SAML-Antwort enthalten sind.

Das [0] ist für die angegebenen Attribute (last_name, user_email , first_name) von entscheidender Bedeutung, nicht jedoch für subject und groups.

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 auf dem Tab Netzwerk in der Filterleiste nach dem Endpunkt auth/siem.

   

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

3. Decodieren:Kopieren Sie den JWT-String und fügen Sie ihn in das Tool JWT Inspection (jwt.io) ein.

   

4. Überprüfung:

   • Vergleichen Sie die decodierten Ansprüche für given_name, family_name, email und idpgroups.
   • Bestätigung der Übereinstimmung:Diese Werte müssen genau mit den Attributen übereinstimmen, die in Phase 3 (SAML-Antwort) validiert wurden.
   • Wenn die Werte übereinstimmen und Sie immer noch 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 Prinzipalformat für Ihre Identitätseinrichtung (Mitarbeiteridentitätsföderation oder Cloud Identity für von Google verwaltete Konten).

Phase 5: SOAR-Berechtigungszugriff validieren

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

Administratoren haben automatisch Zugriff auf SOAR, da auf der Seite Gruppenzuordnung der Standardzugriff aktiviert ist.

Sie können den Gruppenzugriff für Ihre Nutzer validieren, indem Sie einige IDP-Gruppenzuordnungen in dieser neuen SOAR-Instanz hinzufügen. Neue Instanzen haben standardmäßig eine leere Seite Gruppenzuordnung. So validieren Sie den Gruppenzugriff für andere Nutzer: Fügen Sie der neuen SOAR-Instanz IDP-Gruppenzuordnungen hinzu und führen Sie die folgenden Schritte aus:

1. Kopieren Sie 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 die folgenden 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 Phase 1 abschließen, werden die Gruppenzuordnungen aus Ihrer vorhandenen SOAR-Instanz durch alle Zuordnungen überschrieben, die Sie der neuen Google SecOps-Instanz hinzugefügt haben. Sie finden diese Einstellungen unter Einstellungen > „Erweitert“ > „Gruppenzuordnung“.

OIDC-Ablauf und Fehlerbehebung

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

Architektur des Authentifizierungsworkflows

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

Schritt-für-Schritt-Anleitung zur Fehlerbehebung bei OIDC

Um den OIDC-Authentifizierungsprozess effektiv zu diagnostizieren und nachzuvollziehen, können Sie Browser-Entwicklertools und Online-JWT-Decoder verwenden.

• JWT-Prüfung:https://www.jwt.io/
  • Zweck:Dient zum Prüfen der Ansprüche und Inhalte von JSON Web Tokens (JWTs).

Phase 1: Umgebung vorbereiten

Bevor Sie beginnen, müssen Sie dafür sorgen, dass Ihr Browser bereit ist, das Netzwerk 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 + Wahltaste + I.

3. Rufen Sie den Tab Netzwerk auf.

4. Klicken Sie das Kästchen Protokoll beibehalten an, 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 zu Ihrem 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:

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

Phase 3: Callback und Token-Austausch validieren

In diesem Schritt wird die Antwort des IdP an Google Cloudbestätigt.

1. Callback suchen: Suchen Sie auf dem Tab Network (Netzwerk) nach der Anfrage an die signin-callback-URL (.../signin-callback/...).

   

2. Daten prüfen:Prüfen Sie die URL-Parameter dieser Anfrage. Er sollte einen von Ihrem OIDC-IdP bereitgestellten „code“-Parameter enthalten.

3. Hinter den Kulissen:Bei der Mitarbeiteridentitätsföderation wird dieser Code am Token-Endpunkt des OIDC-Anbieters gegen Tokens (ID-Token, Zugriffstoken) ausgetauscht. Fehler in dieser Phase sind häufig in Cloud Logging für die Identitätsföderation von Arbeitslasten sichtbar.

   • Weitergabe von Attributen und vollständiges Token prüfen:So prüfen Sie, ob die Attributzuordnung in der Mitarbeiteridentitätsföderation die erwarteten Ergebnisse liefert:
     • Fügen Sie den Weiterleitungs-URI, der 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 für Mitarbeiteridentitätsföderation auf, um das IdP-Token zu debuggen. Sie können sich auch das vollständige Token ansehen. Weitere Informationen finden Sie unter Produktkonfiguration überprüfen.

   

Phase 4: Google SecOps-Authentifizierung validieren

Mit diesem Schritt wird überprü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 auf dem Tab Netzwerk in der Filterleiste nach dem Endpunkt auth/siem.

   

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

3. Decodieren:Kopieren Sie den JWT-String und fügen Sie ihn in das Tool JWT Inspection (jwt.io) ein.

   

4. Überprüfung:

   • Vergleichen Sie die decodierten Ansprüche für sub, given_name, family_name, email und idpgroups.
   • Bestätigung der Übereinstimmung:Diese Werte müssen den von Ihrem OIDC-Anbieter freigegebenen Attributen und der Art und Weise entsprechen, wie sie in den Attributzuordnungen der Mitarbeiteridentitätsföderation zugeordnet sind. Beispiel: attribute.first_name in Google Cloud sollte dem given_name im JWT entsprechen.
   • 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 im richtigen principalSet-Format (z. B. principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/group/IDP_GROUP_NAME) zugewiesen werden.

Phase 5: SOAR-Berechtigungszugriff validieren

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

Administratoren haben automatisch Zugriff auf SOAR, da auf der Seite Gruppenzuordnung der Standardzugriff aktiviert ist.

Sie können den Gruppenzugriff für Ihre Nutzer validieren, indem Sie einige IDP-Gruppenzuordnungen in dieser neuen SOAR-Instanz hinzufügen. Neue Instanzen haben standardmäßig eine leere Seite Gruppenzuordnung. So validieren Sie den Gruppenzugriff für andere Nutzer: Fügen Sie der neuen SOAR-Instanz IDP-Gruppenzuordnungen hinzu und führen Sie die folgenden Schritte aus:

1. Kopieren Sie 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 die folgenden 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 Phase 1 abschließen, werden die Gruppenzuordnungen aus Ihrer vorhandenen SOAR-Instanz durch alle Zuordnungen überschrieben, die Sie der neuen Google SecOps-Instanz hinzugefügt haben. Sie finden diese Einstellungen unter Einstellungen > „Erweitert“ > „Gruppenzuordnung“.

Häufige OIDC-Fehler:

• invalid_redirect_uri vom IdP: Achten Sie darauf, dass der in Ihrem IdP konfigurierte Redirect-URI genau mit https://auth.backstory.chronicle.security/signin-callback/locations/global/workforcePools/POOL_ID/provider/PROVIDER_ID übereinstimmt. Ersetzen Sie 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 kann diesen Fehler auslösen.

• Fehlende Claims im JWT:

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

  2. WIF-Seite:Achten Sie darauf, dass diese eingehenden Behauptungen im Abschnitt „WIF Attribute Mapping“ (WIF-Attributzuordnung) korrekt zugeordnet sind, z. B. „google.groups=assertion.groups“. Wenn ein Anspruch im Token vorhanden, aber nicht in WIF 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 prüfen.

Gruppenzuordnungen nach der Migration

Gruppenzuordnung ist auch nach der Migration in Google SecOps von entscheidender Bedeutung

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? Antworten von Community-Mitgliedern und Google SecOps-Experten erhalten