Anleitung 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. In diesem Leitfaden geht es um die SAML- und OIDC-Standards, die für die Nutzerauthentifizierung und -autorisierung verwendet werden.

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 das richtige Google Cloud Projekt aus der Projektliste aus.
2. Öffnen Sie das Navigationsmenü (≡) und rufen Sie APIs und Dienste > Aktivierte APIs und Dienste auf.
3. Rufen Sie die Liste der aktivierten APIs und Dienste auf, um Chronicle API zu finden.

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. Ausgeblendete Konten einblenden (wichtiger Schritt): Sie müssen das Kästchen rechts neben der Filterleiste mit der Bezeichnung Von Google bereitgestellte Rollenzuweisungen einschließen anklicken.
3. Nach dem Agenten 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.

Validierung der Google SecOps-Einrichtung

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 (SSO) 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 Projekt-ID von Google Cloud in das Google-Formular ein, das Sie in der produktinternen Benachrichtigung finden. Bestätigen Sie das Datum und das Zeitfenster für die Migration und reichen Sie das Formular ein. 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, prüfen Sie, ob Ihre Firewall oder Ihr Proxy die Domains in der Zulassungsliste für Netzwerkzugriff und Domains zulässt. Wenn das Problem weiterhin besteht, lesen 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

Den Anfragefluss zu verstehen, ist entscheidend, um Fehlerquellen 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 diagnostizieren und zu verfolgen, können Sie die in den folgenden Abschnitten aufgeführten webbasierten Dienstprogramme verwenden.

Google empfiehlt zwar kein bestimmtes Produkt, aber die folgenden Tools sind dafür bekannt, dass sie bei der Fehlerbehebung helfen:

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

Phase 1: Umgebung vorbereiten

Bevor Sie beginnen, müssen Sie Ihre Browserumgebung für die Erfassung des Netzwerkverkehrs vorbereiten. 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 + Umschalttaste + 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 von Migrationsphase 1 für SOAR-Standalone-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 wurde.

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 Anfragewert und fügen Sie ihn in das SAML-Validierungstool (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 Attribute überprüft, die nach der Authentifizierung vom IdP an Google Cloud zurückgegeben werden.

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 Antwortwert und fügen Sie ihn in das SAML-Validierungstool ein.

4. Überprüfung:

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

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

     

Die folgende Abbildung 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 gleich. Es ist die Google-Syntax. Die rechte Seite entspricht den Attributschlüsseln für die Anforderung, die in der SAML-Antwort angezeigt werden.

[0] ist für die angegebenen Attribute (last_name, user_email, first_name) von entscheidender Bedeutung 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 für die Anmeldung bei Google SecOps SOAR authentifiziert.

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 den String jwt.

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

   

4. Überprüfung:

   • Vergleichen Sie die decodierten Anforderungen für given_name, family_name, email und idpgroups.
   • Übereinstimmungsbestätigung: 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 Hauptkontoformat für Ihre Identitätseinrichtung (Mitarbeiteridentitätsföderation oder Cloud Identity für von Google verwaltete Konten).

Phase 5: SOAR-Berechtigungen prüfen

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

Administratoren erhalten 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 in dieser neuen SOAR-Instanz einige IdP-Gruppenzuordnungen hinzufügen. Neue Instanzen haben standardmäßig eine leere Seite Gruppenzuordnung. So validieren Sie den Gruppenzugriff für andere Nutzer und fügen der neuen SOAR-Instanz IdP-Gruppenzuordnungen hinzu:

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 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 kopieren. Gehen Sie dazu zu Einstellungen > Erweitert > Gruppenzuordnung.

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

OIDC-Ablauf und Fehlerbehebung

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

Architektur des Authentifizierungsworkflows

Den Anfragefluss zu verstehen, ist entscheidend, um Fehlerquellen 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 zu verfolgen, können Sie Entwicklertools im Browser und Online-JWT-Decoder verwenden.

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

Phase 1: Umgebung vorbereiten

Bevor Sie beginnen, müssen Sie Ihre Browserumgebung für die Erfassung von Netzwerkaktivitäten vorbereiten. 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 + Umschalttaste + 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 von Migrationsphase 1 für SOAR-Standalone-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 anfängliche 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 die client_id mit der in Ihrem OIDC-Anbieter konfigurierten ü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 dabei POOL_ID und PROVIDER_ID durch Ihren Pool und Anbieter aus der Workforce Identity-Fö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 erforderlich sind (z. B. „email“, „profile“).

Phase 3: Callback und Tokenaustausch validieren

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

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

   

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

3. Hinter den Kulissen: Die Workforce Identity-Föderation tauscht diesen Code gegen Tokens (ID-Token, Zugriffstoken) vom Token-Endpunkt des OIDC-Anbieters aus. Fehler in dieser Phase sind häufig in Cloud Logging für die Identitätsföderation von Arbeitskräften sichtbar.

   • Attributweitergabe 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 die Workforce Identity-Föderation auf, um das IdP-Token zu debuggen. Sie können auch das vollständige Token prüfen. Weitere Informationen finden Sie unter Produktkonfiguration prüfen.

   

Phase 4: Google SecOps-Authentifizierung validieren

In diesem Schritt wird geprüft, ob Google Cloud den Nutzer für die Anmeldung bei Google SecOps SOAR authentifiziert.

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 den String jwt.

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

   

4. Überprüfung:

   • Vergleichen Sie die decodierten Anforderungen für sub, given_name, family_name, email und idpgroups.
   • Übereinstimmungsbestätigung: Diese Werte müssen den Attributen entsprechen, die von Ihrem OIDC-Anbieter freigegeben wurden, und wie sie in den Attributzuordnungen der Workforce Identity-Föderation zugeordnet sind. Beispiel: attribute.first_name in Google Cloud sollte given_name im JWT zugeordnet werden.
   • IAM-Rollen: Wenn die Anforderungen 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 sind.

Phase 5: SOAR-Berechtigungen prüfen

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

Administratoren erhalten 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 in dieser neuen SOAR-Instanz einige IdP-Gruppenzuordnungen hinzufügen. Neue Instanzen haben standardmäßig eine leere Seite Gruppenzuordnung. So validieren Sie den Gruppenzugriff für andere Nutzer und fügen der neuen SOAR-Instanz IdP-Gruppenzuordnungen hinzu:

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 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 kopieren. Gehen Sie dazu zu Einstellungen > Erweitert > Gruppenzuordnung.

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

Häufige OIDC-Fehler:

• invalid_redirect_uri vom IdP: Achten Sie darauf, dass der 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. Sogar ein abschließender Schrägstrich oder eine Abweichung zwischen http und https führt dazu.

• Fehlende Anforderungen im JWT:

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

  2. WIF-Seite: Achten Sie darauf, dass diese eingehenden Anforderungen im Abschnitt „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

Gruppenzuordnungen bleiben in Google SecOps auch nach Abschluss der Migration wichtig

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, damit er auf Google SecOps zugreifen kann. Weitere Informationen finden Sie unter Auf eine Instanz zugreifen.

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