SOAR-Migration – Übersicht

Unterstützt in:

In diesem Dokument werden der Prozess und die Zeitpläne für die Migration der SOAR-Infrastruktur zu Google Cloudbeschrieben. Die Migration soll die Infrastruktur modernisieren und die Integration in Google Cloud -Dienste verbessern. Davon profitieren sowohl Kunden, die Google Security Operations Unified nutzen, als auch eigenständige SOAR-Nutzer, die zu Google Cloudwechseln.

Diese Migration ist erforderlich, um kritische Infrastrukturupgrades bereitzustellen, darunter eine höhere Zuverlässigkeit, verbesserte Sicherheit, bessere Compliance und eine detailliertere Zugriffssteuerung. Außerdem ermöglicht er den Zugriff auf agentische KI-Funktionen über die Integration des Model Context Protocol (MCP) und erstklassige Dienste wie IAM für die Zugriffssteuerung, Cloud Monitoring und Cloud-Audit-Logs.

Die Migration erfolgt in zwei Phasen: Phase 1 und Phase 2.

Phase 1 umfasst die folgenden Migrationen:

  • Migration Ihres Google-eigenen SOAR-Projekts zur Google Cloud -Infrastruktur. Dies wird von Google durchgeführt.
  • Migration der SOAR-Authentifizierung zu Google Cloud (gilt nur für eigenständige SOAR-Kunden).

Phase 2 umfasst die folgenden Migrationen:

  • Migration von SOAR-Berechtigungsgruppen und ‑Berechtigungen zu Google Cloud IAM.
  • Migration von SOAR APIs zur neuen einheitlichen Chronicle API, was Aktualisierungen vorhandener Skripts und Integrationen erfordert.
  • Migration von Webhooks
  • Migration der Authentifizierungsinfrastruktur für Remote-Agents.

Erfolgreiche Migration prüfen

  • Prüfen Sie, ob Phase 1 erfolgreich abgeschlossen wurde. Rufen Sie dazu die SOAR-Einstellungen > Lizenzverwaltung auf und prüfen Sie, ob nach der Systemversionsnummer Google.com steht.

  • Prüfen Sie, ob die Migration der SOAR-Berechtigungen zu IAM-Rollen in Phase 2 erfolgreich abgeschlossen wurde. Gehen Sie dazu zu SOAR-Einstellungen > Lizenzverwaltung und prüfen Sie, ob nach der Systemversionsnummer Google.com und CloudIAM aktiviert angezeigt wird.

Migrationsphase 1 für Google SecOps Unified-Kunden

In der In-Produkt-Benachrichtigung finden Sie das Datum für die Migration in Phase 1 und ein Google-Formular, mit dem Sie das Zeitfenster bestätigen können. Phase 1 umfasst die folgenden Migrationen.

  • Von Google verwaltetes SOAR-Projekt zu Google Cloudmigrieren

Die Migration führt zu einer Ausfallzeit von bis zu 90 Minuten, in denen die Google SecOps-Plattform nicht verfügbar ist. Während dieser Ausfallzeit werden Ihre SIEM-Dienste im Hintergrund weiter ausgeführt, während SOAR-Dienste vorübergehend pausiert werden. Nach der Ausfallzeit ist die Plattform wieder verfügbar und die SOAR-Dienste verarbeiten alle während der Ausfallzeit generierten oder aufgenommenen Benachrichtigungen.

Sobald die Migration abgeschlossen ist, erhalten Sie eine E‑Mail.

Migrationsphase 1 für eigenständige SOAR-Kunden

Je nach Ihren Anforderungen und Anwendungsfällen können Sie eine der folgenden Migrationsoptionen auswählen:

  • Option 1 (empfohlen) – SOAR-Instanz mit einer vorhandenen SIEM-Instanz vereinheitlichen: Wenn Sie eine vorhandene SIEM-Instanz haben, für die SOAR nicht aktiviert ist, empfehlen wir, Ihre SOAR-Instanz nach Möglichkeit in Ihre vorhandene SIEM-Bereitstellung zu integrieren. Bei dieser Option wird das Google Cloud -Projekt verwendet, das mit Ihrer vorhandenen SIEM-Instanz verknüpft ist. Beide Produkte werden in einer einzigen Google SecOps-Oberfläche mit gemeinsamer Authentifizierung, Zugriffssteuerung und Audit-Logging zusammengeführt.

  • Option 2: Neue Google SecOps-Instanz bereitstellen: Wenn Sie keine SIEM-Instanz haben oder Ihre SOAR- und SIEM-Bereitstellungen getrennt halten müssen, können Sie alternativ eine neue Google SecOps-Instanz in einem dedizierten Google Cloud -Projekt bereitstellen.

Sie erhalten eine In-Produkt-Benachrichtigung, wenn wir bereit sind, Phase 1 für Sie zu starten. Beachte Folgendes:

  1. Identifizieren oder richten Sie Ihr Google Cloud -Projekt basierend auf der ausgewählten Migrationsoption ein:
    • Option 1 (mit einem vorhandenen SIEM zusammenführen): Verwenden Sie das vorhandene Google Cloud Projekt, das mit Ihrer SIEM-Instanz verknüpft ist.
    • Option 2 (Neue Google SecOps-Instanz bereitstellen): Richten Sie ein Google Cloud -Projekt ein. Sie können auch ein Google Cloud -Projekt verwenden, das für den Zugriff auf den Google SecOps-Support eingerichtet wurde, aber noch keine Google Security Operations-Instanz hat.
  2. Aktivieren Sie die Chronicle API im Google Cloud Projekt, falls sie noch nicht aktiviert ist.
  3. Richten Sie die Google Cloud -Authentifizierung für den Zugriff auf SOAR ein. Weitere Informationen finden Sie unter Google Cloud -Authentifizierung für den Zugriff auf SOAR einrichten.
  4. Geben Sie die Projekt-ID von Google Cloud im Google-Formular in der produktinternen Benachrichtigung an und bestätigen Sie das Datum und den Zeitraum für die Migration, bevor Sie das Formular einreichen.
  5. Nehmen Sie die E‑Mail-Einladung zur Seite „Google Security Operations herunterladen“ an und schließen Sie die Einrichtung ab (wenn Sie eine neue Google SecOps-Instanz bereitstellen). Achten Sie darauf, dass die Angaben zu Ihrer Region korrekt sind.
  6. Prüfen Sie anhand der Anleitung zur Validierung vor der Migration, ob die vorherigen Schritte korrekt eingerichtet wurden.

Nachdem Sie die Schritte ausgeführt haben, führt Google die Migration zum geplanten Datum und zur geplanten Uhrzeit durch. Für die Migration müssen SOAR-Dienste für etwa zwei Stunden unterbrochen werden. Nach Abschluss erhalten Sie eine E-Mail mit der neuen URL für den Zugriff auf die SOAR-Plattform. Die alte URL bleibt bis zum 30. Juni 2026 funktionsfähig und leitet zur neuen URL weiter.

Google Cloud -Authentifizierung für den Zugriff auf SOAR einrichten

Konfigurieren Sie je nach gewünschtem Identitätstyp eine der folgenden Optionen. Möglicherweise benötigen Sie Hilfe von Ihrem Google Cloud und Identitäts- oder IdP-Administrator, um diese Schritte auszuführen.

Option 1: Cloud Identity-Authentifizierung in Google Cloud konfigurieren(von Google verwaltete Konten)

Dieses Szenario ist anwendbar, wenn Sie Nutzerkonten direkt in Cloud Identity mit von Google verwalteten Nutzernamen und Passwörtern verwalten. Sie gilt nicht, wenn Sie Cloud Identity für SSO mit einem externen Identitätsanbieter wie Okta oder Azure AD verwenden.

Gehen Sie folgendermaßen vor:

  1. Cloud Identity in Google Cloudeinrichten.

    Sie können diesen Schritt überspringen, wenn Sie Cloud Identity bereits mit einem von Google verwalteten Nutzernamen und Passwort eingerichtet haben.

  2. Prüfen Sie, ob alle vorhandenen SOAR-Nutzer in der Cloud Identity-Admin-Konsole konfiguriert sind.

  3. Weisen Sie die erforderlichen Rollen in IAM zu, indem Sie das Format für die Rollenzuweisung für Google-Konten verwenden.

    1. Weisen Sie dem Onboarding-SME die folgenden vordefinierten IAM-Rollen in Google Cloud zu:

    2. Weisen Sie allen vorhandenen SOAR-Nutzern eine der folgenden vordefinierten IAM-Rollen zu:

  4. Schließen Sie die Authentifizierungseinrichtung in SOAR ab, indem Sie jeden Nutzer (einschließlich Administratoren) einer E-Mail-Nutzergruppe zuordnen.

    1. Rufen Sie die SOAR-Einstellungen > Erweitert > Gruppenzuordnung auf.

    2. Klicken Sie auf add Hinzufügen und geben Sie die folgenden Informationen ein:

      • IdP / Nutzergruppe: Der Name der E-Mail-Nutzergruppe (z. B. T1-Analysten).
      • Berechtigungsgruppen: Wählen Sie die Berechtigungsgruppen aus.
      • SOC-Rollen: Wählen Sie die SOC-Rollen aus.
      • Umgebungen: Wählen Sie die Umgebungen aus (z. B. Alle Umgebungen).
      • Gruppenmitglieder: Geben Sie die erforderlichen Nutzer-E-Mail-Adressen ein. Drücken Sie nach jeder E‑Mail-Adresse die Eingabetaste.

    3. Klicken Sie auf Hinzufügen.

      Jedes Mal, wenn sich ein Nutzer auf der Plattform anmeldet, wird er automatisch auf der Seite SOAR-Einstellungen > Organisation > Nutzerverwaltung hinzugefügt. Die migrierte Instanz behält diese Zuordnungen bei, die als Grundlage für die Bestimmung des Nutzerzugriffs auf SOAR dienen. Sie müssen dafür sorgen, dass jeder Nutzer auf dieser Seite zugeordnet ist, damit er auf Google SecOps zugreifen kann.

Option 2: Authentifizierung über die Workforce Identity-Föderation in Google Cloudkonfigurieren

Dieses Szenario ist anwendbar, wenn Sie Ihre Nutzeridentitäten mit externen IdPs wie Microsoft Azure Active Directory, Okta, Ping Identity und AD FS verwalten.

  1. Mitarbeiteridentitätsföderation in Google Cloudeinrichten: Sie können diesen Schritt überspringen, wenn die Einrichtung bereits erfolgt ist.
  2. Achten Sie darauf, dass alle vorhandenen Nutzer in SOAR zu den Workforce-Poolgruppen gehören, die in der Workforce Identity-Föderation eingerichtet wurden.

  3. Weisen Sie die erforderlichen Rollen in IAM zu, indem Sie dem Format für die Rollenzuweisung für Workforce Identities folgen.

    1. Weisen Sie dem Onboarding-SME alle folgenden vordefinierten IAM-Rollen zu.

    2. Weisen Sie allen vorhandenen SOAR-Nutzern eine der folgenden Rollen in IAM zu:

  4. Schließen Sie die Authentifizierungseinrichtung in SOAR ab, indem Sie alle IdP-Gruppen zuordnen, die Zugriff auf SOAR benötigen.

    Achten Sie darauf, dass die vorhandenen Nutzer mindestens einer der IdP-Gruppen zugeordnet sind.

    1. Rufen Sie die SOAR-Einstellungen > Erweitert > Gruppenzuordnung auf.
    2. Klicken Sie auf Hinzufügen Hinzufügen und geben Sie die folgenden Informationen ein:
      • IdP / Nutzergruppe: Geben Sie den Gruppennamen von Ihrem IdP ein.
      • Berechtigungsgruppen: Wählen Sie die Berechtigungsgruppen aus.
      • SOC-Rollen: Wählen Sie die SOC-Rollen aus.
      • Umgebungen: Wählen Sie die Umgebungen aus (z. B. Alle Umgebungen).
    3. Achten Sie darauf, dass Sie die IdP-Gruppe „Admin“ mit Administratorberechtigungen für Berechtigungsgruppen und SOC-Rollen hinzugefügt und „Alle Umgebungen“ ausgewählt haben.
    4. Wenn Sie auf der Seite „Externe Authentifizierung“ bereits IdP-Gruppenzuordnungen haben, sollten Sie diese unverändert lassen, um Ihre vorhandene SOAR-Authentifizierung nicht zu überschreiben. Damit die neue Google Cloud Authentifizierung auf SOAR zugreifen kann, müssen Sie die IdP-Gruppenzuordnung unter Einstellungen > SOAR-Einstellungen > Erweitert > Gruppenzuordnung einrichten.
    5. Klicken Sie auf Hinzufügen. Jedes Mal, wenn sich ein Nutzer auf der Plattform anmeldet, wird er automatisch auf der Seite Einstellungen > Organisation > Nutzerverwaltung hinzugefügt. Die migrierte Instanz behält diese Zuordnungen bei, die als Grundlage für die Bestimmung des Nutzerzugriffs auf SOAR dienen. Sie müssen dafür sorgen, dass jeder Nutzer auf dieser Seite zugeordnet ist, damit er auf Google SecOps zugreifen kann.

Phase 2 der Migration für alle Kunden

Wichtig: Sie müssen Phase 1 abschließen, bevor Sie mit der Migration in Phase 2 beginnen.

Die Migration in Phase 2 ist ab dem 26. Januar 2026 für alle Kunden allgemein verfügbar.

Die endgültige Frist für die Umstellung auf IAM-Rollen in Phase 2 ist der 30. November 2026. Die Frist für die API-Migration wurde bis zum 31. März 2027 verlängert.

SOAR-Berechtigungsgruppen zu Google Cloud IAM migrieren

Migrieren Sie die SOAR-Berechtigungsgruppen und -Berechtigungen mit einem einzigen Klick auf das Migrationsskript in Google Cloudzu IAM. Das Script erstellt für jede Berechtigungsgruppe neue benutzerdefinierte Rollen und weist sie Nutzern für Cloud Identity-Kunden oder IdP-Gruppen für Workforce Identity-Föderation-Kunden zu. Sie können die SOAR-Berechtigungen auch mit Terraform migrieren.

Ausführliche Informationen zum Migrationsskript und zu den Terraform-Befehlen finden Sie unter SOAR-Berechtigungen zu Google Cloud IAM migrieren.

Weitere Informationen zum Einrichten von Berechtigungen finden Sie unter Featurezugriff konfigurieren.

Nach der Migration der Berechtigungen passiert Folgendes:

  • Die Seite SOAR-Einstellungen > Organisation > Berechtigungen ist bis zum 31. März 2027 verfügbar (aus Gründen der Abwärtskompatibilität mit Legacy-APIs). Nehmen Sie auf dieser Seite keine Änderungen vor. Die Berechtigungen werden alle über IAM verwaltet.
  • Die Spalte Berechtigungsgruppe auf der Seite Gruppenzuordnung wird aus Gründen der Abwärtskompatibilität mit der alten SOAR API angezeigt. Löschen Sie diese Zuweisungen nicht. Die Spalte wird bis zum 31. März 2027 automatisch entfernt, ohne dass dies Auswirkungen auf Kunden hat.
  • Der Abschnitt mit den eingeschränkten Aktionen auf der Seite Berechtigungen wird auf die Seite Gruppenzuordnung verschoben.

SOAR APIs zur Chronicle API migrieren

Wenn Sie die SOAR API programmatisch über API-Aufrufe oder Integrationen verwenden, können Sie sie zu den neuen SOAR v1-Beta-Endpunkten migrieren, die als Teil der Chronicle API verfügbar sind.

Sie müssen Ihre Skripts und Integrationen aktualisieren, um die SOAR API-Endpunkte durch die entsprechenden Chronicle API-Endpunkte zu ersetzen. Die Legacy-SOAR-API und die API-Schlüssel sind bis zum 31. März 2027 verfügbar. Danach funktionieren sie nicht mehr. Weitere Informationen finden Sie unter Endpunkte zur Chronicle API migrieren.

Webhooks migrieren

Sie müssen SOAR-Webhooks bis zum 31. März 2027 zur Chronicle API migrieren. Gehen Sie dazu so vor:

Aktualisieren Sie die Webhook-URL auf der Clientseite, indem Sie die alte siemplify-soar.com-Domain durch die neue googleapis.com-Domain ersetzen. Verwenden Sie dazu das neue Anfrageformat. Die alte siemplify-soar.com-Domain funktioniert noch bis zum 31. März 2027.

Beispiel für einen Webhook, der für https://xxxx.siemplify-soar.com/api/external/v1/webhooks/{webhook_id}?api_key=xxxx definiert ist:

muss aktualisiert werden auf: https://us-chronicle.googleapis.com/v1alpha/projects/{project_id}/locations/{location}/instances/{instance/{instance_id}/webhooks/{webhook_id}?api_key=xxxx

Die Authentifizierung für Webhooks bleibt unverändert. Webhooks verwenden weiterhin den API-Schlüssel, der ursprünglich zusammen mit dem Webhook-Link erstellt wurde.

Infrastruktur für die Authentifizierung von Remote-Agents migrieren

In den folgenden Schritten wird beschrieben, wie Sie die Authentifizierungsinfrastruktur Ihrer Remote-Agents zur Authentifizierung mit einem Google Cloud -Dienstkonto migrieren. Bei diesem Vorgang müssen die Remote-Agent-Instanzen oder -Hosts nicht migriert oder ersetzt werden.

  1. Erstellen Sie für den Remote-Agenten ein Dienstkonto anstelle eines API-Schlüssels.
  2. Führen Sie ein Upgrade der Hauptversion des Remote-Agents durch.

Bestehende Remote-Agents sind bis zum 30. November 2026 verfügbar. Danach funktionieren sie nicht mehr. Eine ausführliche Anleitung finden Sie unter Remote-Agents zu Google Cloud migrieren.

Auswirkungen auf SOAR-Audit-Logs

SOAR-Logs sind in Google Cloud verfügbar, sobald Sie die Berechtigungsmigration zu IAM abgeschlossen haben. Alle Aufrufe der Legacy-SOAR API bis zum 31. März 2027 bleiben in den SOAR-Audit-Logs zugänglich. Google SecOps-Kunden finden weitere Informationen unter Google SecOps SOAR-Logs erfassen. Informationen für SOAR-Standalone-Kunden finden Sie unter SOAR-Logs erfassen.

Weitere Änderungen nach der Migration:

Lizenztyp Der Lizenztyp wird jetzt durch die zugewiesenen Berechtigungen des Nutzers in IAM bestimmt.

Landingpage Die Landingpage wird von der Seite „Berechtigungen“ in das Menü Nutzereinstellungen verschoben, das über Ihren Avatar aufgerufen werden kann.

Weitere Informationen

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