Häufig gestellte Fragen zur SOAR-Migration

Unterstützt in:

Antworten auf häufig gestellte Fragen zum SOAR-Migrationsprozess. Hier finden Sie Lösungen für häufige Probleme und Best Practices für eine erfolgreiche Umstellung.

Migrationsumfang und ‑auswirkungen

F: Warum ist diese Migration erforderlich?

Wir modernisieren die SOAR-Infrastruktur durch die Migration zu Google Cloud. Dieses wichtige Upgrade bietet entscheidende Vorteile, darunter eine höhere Zuverlässigkeit, verbesserte Sicherheit, bessere Compliance und eine detailliertere Zugriffssteuerung. Außerdem erhalten Sie Zugriff auf agentische KI-Funktionen durch die Integration des Model Context Protocol (MCP).

Die Migration bietet Folgendes:

  • Die Zuverlässigkeit und Monitoring-Funktionen von SOAR werden durch die Nutzung der erstklassigen API-Ebene von Google verbessert. Diese Ebene bietet eine führende API-Lösung mit erweiterten Funktionen für die Kontingentverwaltung, Audits und Observability.
  • Ermöglicht die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) für Funktionen und Daten auf der gesamten Plattform.
  • Bietet erweiterte Compliance-Funktionen wie VPC Service Controls, Datenstandort und vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK).

F: Was ist der Umfang der Migration?

Die Migration umfasst die folgenden Komponenten:

  • SOAR-Projekt zu einem vom Kunden verwalteten Google Cloud Projekt migrieren.
  • SOAR-Authentifizierung und -Berechtigungen zu Google Cloud IAM migrieren.
  • SOAR-APIs zu Chronicle API migrieren.
  • Remote-Agents migrieren
  • Migration von SOAR-Audit-Logs.

F: Was sind die unmittelbaren Änderungen nach der Migration?

Unmittelbar nach der Migration werden Sie einige wichtige Änderungen bemerken:

  • GCP-Projekteigentum: Ihr SOAR-Projekt wird von Google in Ihr eigenes Projekt Google Cloud migriert.
  • Authentifizierung:
    • Unified SecOps-Kunden: Keine Änderung. Die Authentifizierung wird weiterhin von Google Cloud IAM verwaltet.
    • SOAR Standalone-Kunden: Die Authentifizierung wird jetzt von Google Cloud IAM verwaltet. Für Nutzer, die SAML verwenden, bedeutet dies die Einführung der Mitarbeiteridentitätsföderation. Die SAML-Konfiguration wird dann nicht mehr im SOAR-System selbst gespeichert und verwaltet, was zu stärkeren Sicherheitskontrollen führt.
  • RBAC: Nutzerberechtigungen werden detaillierter und über IAM verwaltet. Umgebungen und SOC-Rollen werden weiterhin im SOAR-Modul mit Identitätsanbietergruppen (Identity Provider, IdP) verwaltet.
  • Audit-Logging: Audit-Logs sind detaillierter und werden in **Cloud-Audit-Logs ** verwaltet.
  • Neue URL (nur SOAR): SOAR-Standalone-Nutzer erhalten eine neue URL (neue Domain) für den Zugriff auf SOAR.

F: Wie werden Kunden / Partner über diese Migration informiert?

Allen Kunden und Partnern wird ein In-Product-Pop-up mit dem Migrationsdatum und einem Link zu einem auszufüllenden Formular angezeigt. Sie werden aufgefordert, das Migrationsdatum und den Migrationszeitraum zu bestätigen.

F: Ändern sich unsere Infrastrukturkosten, weil SOAR an unser Google Cloud -Projekt gebunden ist?

Nein, Ihre Kosten sind davon nicht betroffen. Auf dem Frontend sollte sich nichts ändern. In Ihrem Projekt werden keine neuen Ressourcen ausgeführt, sodass keine Kosten anfallen.

F: Wie verbinden wir unser Projekt mit SOAR?

Google migriert Ihr SOAR-Projekt in Ihr Google Cloud Projekt. Wenn Sie Unified SecOps-Kunde sind, haben wir Ihre Google Cloud Projekt-ID bereits. Wenn Sie ein SOAR-Standalone-Kunde sind, müssen Sie uns Ihre Google Cloud Projekt-ID mitteilen.

F: Sollten wir für Kunden, die bereits eine Google SecOps-Bereitstellung haben, dieselbe Projekt-ID wie für SIEM verwenden oder benötigen wir ein separates Projekt?

Für eine einheitliche Google SecOps-Bereitstellung (ein SIEM, ein SOAR) sollten Sie die vorhandene Google Cloud Projekt-ID verwenden, die mit Ihrem SIEM verknüpft ist. Dies ermöglicht eine einheitliche Verwaltung administrativer Abläufe wie RBAC und Protokolle.

F: Welche Schritte sind für Google SecOps-Instanzen mit besonderen Anforderungen wie VPC Service Controls (VPC SC) erforderlich?

Damit die Migration möglich ist, müssen Sie sowohl Regeln für eingehenden als auch für ausgehenden Traffic in Ihrer VPC SC-Richtlinie definieren. Ausführliche Informationen zu diesen spezifischen Regeln erhalten Sie vom Supportteam.

Ausfallzeiten und Kontinuität

F: Gibt es während der Migration Ausfallzeiten und welche Auswirkungen haben sie?

Ja. Die voraussichtliche Ausfallzeit ist:

  • Bis zu 2 Stunden für Kunden der eigenständigen SOAR-Plattform.
  • Bis zu 1,5 Stunden für Google SecOps-Kunden.

Während dieses Zeitraums können Sie sich nicht in der Plattform anmelden. SOAR-Dienste (einschließlich Aufnahme, Playbooks und Jobs) werden pausiert, SIEM-Dienste werden jedoch im Hintergrund weiter ausgeführt.

F: Werden Daten, die während der Ausfallzeit generiert wurden, automatisch erfasst, sobald die SOAR-Dienste wieder funktionieren?

Ja. Sobald das System wieder online ist, werden die Aufnahme und die Playbooks fortgesetzt und alle Benachrichtigungen verarbeitet, die während der Ausfallzeit generiert oder aufgenommen wurden.

F: Was passiert mit Playbooks, die ausgeführt werden, wenn die Ausfallzeit beginnt?

Der Playbook-Dienst wird vor Beginn der Migration deaktiviert. Einige laufende Playbooks schlagen möglicherweise fehl und müssen entweder manuell neu gestartet werden oder werden nach Abschluss der Migration fortgesetzt.

F: Gibt es einen Rollback- oder Notfallplan, falls bei der Migration etwas schiefgeht?

Ja. Bei der Migration bleibt Ihre vorhandene SOAR-Instanz vollständig intakt (wird jedoch deaktiviert). Wenn die Migration nicht erfolgreich abgeschlossen wird, können wir zur vorhandenen Instanz zurückkehren und die neue Instanz entfernen. Dieser Rollback-Vorgang kann bis zu 30 Minuten dauern. Wir führen umfangreiche Tests durch und überwachen die Migration genau. Außerdem steht Personal auf Abruf bereit, um für eine erfolgreiche Migration zu sorgen.

F: Wann kann ich zur neuen SOAR-Endpunktversion 1 in der Chronicle API migrieren?

Sie können ab Mitte Januar 2026 während der allgemeinen Verfügbarkeit (GA) zur neuen SOAR-Endpunktversion 1 in der Chronicle API migrieren. Wir empfehlen Ihnen, bis Januar 2026 zu warten, um eine möglichst zuverlässige und stabile Migration zu gewährleisten. Sie können optional eine private Vorschau beantragen, um die SOAR-Endpunkte v1 alpha in der Chronicle API ab dem 24. November 2025 zu verwenden.

Die alte SOAR API und die API-Schlüssel werden eingestellt und funktionieren nach dem 30. Juni 2026 nicht mehr. Damit der Übergang reibungslos verläuft, müssen Sie die folgenden beiden Schritte ausführen:

  1. Sie müssen zuerst die Migration von SOAR-Berechtigungsgruppen zu Cloud IAM abschließen.
  2. Aktualisieren Sie Ihre vorhandenen Skripts und Integrationen, um die alten SOAR API-Endpunkte durch die entsprechenden Chronicle API-Endpunkte zu ersetzen.

Authentifizierung und Berechtigungen

F: Wie migriere ich meine SOAR-Berechtigungsgruppen und ‑Berechtigungen?

Sie verwenden ein Migrationsskript in Ihrer Google Cloud Konsole, um vorhandene Berechtigungsgruppen zu benutzerdefinierten IAM-Rollen zu migrieren. Das Script weist Nutzern (für Cloud Identity-Kunden) oder IdP-Gruppen (für Kunden der Mitarbeiteridentitätsföderation) auch benutzerdefinierte Rollen zu.

F: Was ist, wenn ich benutzerdefinierte Berechtigungsgruppen nicht migrieren und nur vordefinierte Rollen verwenden möchte?

Sie können die automatische Migration deaktivieren und IdP-Gruppen stattdessen manuell Cloud IAM-Rollen zuordnen.

F: Wir sind ein SOAR-Standalone-Kunde mit einem benutzerdefinierten SAML-Anbieter mit manueller Authentifizierung. Wenn wir das auf IdP-Gruppen für die IdP-Zuordnung umstellen, welche Auswirkungen hat das auf bestehende Nutzerkonten?

Wenn Ihre vorhandenen Nutzer einer der Gruppen entsprechen und die Berechtigungen richtig zugeordnet sind, sollte es keine Auswirkungen auf Ihre vorhandenen Nutzerkonten geben. Wenn Nutzer jedoch nicht Gruppen zugeordnet sind, können sie sich nicht anmelden. Wenn Berechtigungen unterschiedlich zugeordnet werden, erhalten Nutzer neue Berechtigungen basierend auf der neuen Zuordnung.

F: Gibt es bestimmte Voraussetzungen für MSSPs, die mehrere Identitätsanbieter verwenden?

Kunden, die mehrere Identitätsanbieter auf der Seite für die externe SOAR-Authentifizierung konfiguriert haben, sollten die Mitarbeiteridentitätsföderation für die Authentifizierung definieren und für jeden Anbieter einen separaten Mitarbeiterpool erstellen. Jeder Anbieter wird einer anderen Subdomain zugeordnet.

F: Welche neuen IPs sind für den Zugriff auf die neue SOAR API erforderlich? Es ist nicht erforderlich, IP-Adressen auf die Zulassungsliste zu setzen, um auf die Chronicle API zuzugreifen. Optional können Sie den hier und hier angegebenen IP-Adressbereich auf die Zulassungsliste setzen.

Logging und Monitoring

F: Wir haben die erste Phase der Migration abgeschlossen, sehen aber keine Logs in Cloud-Audit-Logs.

Logs werden nach Abschluss der ersten Migrationsphase auf der SOAR-Plattform gespeichert. Logs sind in Ihrem Google Cloud Projekt verfügbar, nachdem die zweite Migrationsphase abgeschlossen ist.

F: Können Kunden, die SOAR-Daten an eine verwaltete BigQuery-Instanz (BQ) senden, nach der Migration weiterhin auf diese BigQuery-Daten zugreifen?

Ja. Das vorhandene verwaltete BigQuery funktioniert weiterhin.

Logistik und Support

F: Kann ich einen anderen Zeitraum für die Migration auswählen?

Nein. Eine Migration außerhalb der vorgeschlagenen Zeitfenster ist nicht möglich.

F: Erhalten wir während der Migration Statusaktualisierungen in Echtzeit?

Sie erhalten sowohl zu Beginn als auch am Ende der Migration eine E‑Mail-Benachrichtigung.

F: An wen sollten wir uns wenden, wenn nach der Migration ein Problem auftritt?

Erstellen Sie ein Support-Ticket, um das Problem zu protokollieren und den Fortschritt zu verfolgen.

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