Häufig gestellte Fragen zur SOAR-Migration
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 wichtige Vorteile, darunter eine höhere Zuverlässigkeit, verbesserte Sicherheit, bessere Compliance und eine detailliertere Zugriffssteuerung. Außerdem erhalten Sie über die Integration des Model Context Protocol (MCP) Zugriff auf agentische KI-Funktionen.
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 zur 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 feststellen:
- 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 das die Einführung der Mitarbeiteridentitätsföderation. Die SAML-Konfiguration wird dann nicht mehr im SOAR-System 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 Zeitrahmen 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 die 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 behalten die Migration genau im Blick. Außerdem steht ein Bereitschaftsteam zur Verfügung, um für eine erfolgreiche Migration zu sorgen.
F: Wann kann ich zu den neuen SOAR-Endpunkten in der Chronicle API migrieren?
Ab dem 1. November 2025 haben Sie Vorabzugriff auf die neuen SOAR-Endpunkte, die sich in der Betaversion der Chronicle API V1 befinden. Der allgemeine Zugriff auf die Chronicle API V1 ist ab dem 1. Januar 2026 verfügbar. Sie müssen die Migration von SOAR-Berechtigungsgruppen zu Cloud IAM abschließen, bevor Sie von der alten SOAR API migrieren. Sie müssen Ihre Skripts und Integrationen aktualisieren, um die SOAR API-Endpunkte durch die entsprechenden Chronicle API-Endpunkte zu ersetzen. Die bisherige SOAR API und die API-Schlüssel funktionieren bis zum 30. Juni 2026.
Authentifizierung und Berechtigungen
F: Wie migriere ich meine SOAR-Berechtigungsgruppen und ‑Berechtigungen?
Wir bereiten einen Migrationsassistenten vor, mit dem Sie in Ihrer Google Cloud -Konsole vorhandene Berechtigungsgruppen zu benutzerdefinierten IAM-Rollen migrieren können. Das Skript 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 stattdessen IdP-Gruppen 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 anders 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 „Externe SOAR-Authentifizierung“ konfiguriert haben, sollten die Mitarbeiteridentitätsföderation für die Authentifizierung definieren und für jeden Anbieter einen separaten Mitarbeiteridentitäts-Pool erstellen. Jeder Anbieter wird einer anderen Subdomain zugeordnet.
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