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 wichtige Vorteile, darunter eine höhere Zuverlässigkeit, verbesserte Sicherheit, bessere Compliance und eine detailliertere Zugriffssteuerung. Außerdem bietet es ü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 kundenverwaltete 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 das, dass sie die Mitarbeiteridentitätsföderation einführen müssen. 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 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 die einheitliche Verwaltung administrativer Abläufe wie RBAC und Logs.

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. Wenn Ihr Google Cloud Projekt VPC SC hat, wenden Sie sich an das Supportteam, um detaillierte Informationen zu diesen spezifischen Regeln zu erhalten.

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.

Wenn nach der Migration Probleme beim Zugriff auftreten, ist die Authentifizierung wahrscheinlich nicht richtig eingerichtet. Sie müssen sich mit Ihrem Identitäts-, IdP- oder Google Cloud Administrator abstimmen, um den Leitfaden zur Fehlerbehebung zur Identifizierung und Behebung zu verwenden. Wenn das Problem weiterhin besteht oder nicht mit dem Zugriff zusammenhängt, öffnen Sie ein Support-Ticket, um das Problem zu dokumentieren und die Lösung zu verfolgen.

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

Ab Mitte Januar 2026 können Sie zur neuen SOAR-Endpunktversion 1 in der Chronicle API migrieren.

Die alte SOAR API und die alten API-Schlüssel werden eingestellt und funktionieren nach dem 30. September 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 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 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 die Zuordnung von IdP-Gruppen ändern, welche Auswirkungen hat das auf bestehende Nutzerkonten?

Wenn Ihre bestehenden Nutzer einer der Gruppen entsprechen und die Berechtigungen richtig zugeordnet sind, sollte es keine Auswirkungen auf Ihre bestehenden 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 „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 ist mit einer anderen Subdomain verknüpft. Weitere Informationen finden Sie im Migrationsleitfaden für MSSPs.

F: Wie authentifiziere ich mich bei der Chronicle API?

Folgen Sie der Anleitung unter Bei der Chronicle API authentifizieren.

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?

Wenn nach der Migration Probleme beim Zugriff auftreten, ist die Authentifizierungseinrichtung wahrscheinlich falsch. Sie müssen sich mit Ihrem Identitäts-, IdP- oder Google Cloud Administrator abstimmen, um den Leitfaden zur Fehlerbehebung zur Identifizierung und Behebung zu verwenden. Wenn das Problem weiterhin besteht oder nicht mit dem Zugriff zusammenhängt, öffnen Sie ein Support-Ticket, um das Problem zu dokumentieren und die Lösung zu verfolgen.

SOAR-Berechtigungsgruppen zu IAM migrieren

Im folgenden Abschnitt werden häufige Probleme behandelt, die während und nach der Migration von Berechtigungen zu IAM auftreten.

Probleme mit Migrationstools und ‑skripten

F: Warum kann ich das Migrationsskript in der Google Cloud Console nicht sehen oder laden?

Dafür gibt es zwei mögliche Gründe:

  • Fehlende Berechtigungen: Das Migrationstool erfordert, dass Ihr Nutzerkonto sowohl in der Google Cloud als auch in der Google SecOps-Instanz über ausreichende Berechtigungen verfügt. Achten Sie darauf, dass Sie mit einem Konto angemeldet sind, das die erforderlichen IAM-Rollen in Google Cloud hat und auch ein anerkannter Nutzer in Google SecOps SOAR ist. Wenn Sie unterschiedliche Konten für Google Cloud und SOAR verwenden, kann es zu Autorisierungsfehlern kommen. Wenn Sie die erforderlichen Berechtigungen haben und das Migrationsskript trotzdem nicht laden können, erstellen Sie ein Support-Ticket.

  • SIEM verwendet Cloud IAM nicht: Wenn Sie ein Google SecOps Unified-Kunde sind, müssen Sie IAM verwenden, um Rollen und Berechtigungen für die SIEM-Seite der Plattform zu verwalten. Weitere Informationen finden Sie im Migrationsleitfaden für die Migration von Legacy-RBAC zu Feature-RBAC.

F: Beim Ausführen der Migrationsskripts erhalte ich eine Fehlermeldung. Was soll ich tun?

  • Fehler – „Gruppe nicht vorhanden“: Wenn Sie add-iam-policy-binding commands verwenden, achten Sie darauf, dass Sie für das Flag --member die vollständige E‑Mail-Adresse der Gruppe (z. B. your-group@example.com) und nicht nur den kurzen Gruppennamen verwenden.

  • Fehler im Zusammenhang mit vorhandenen Rollen: Konflikte können auftreten, wenn eine Bindung an ein Hauptkonto erfolgt, das bereits bedingte Bindungen hat. Führen Sie das Skript noch einmal aus und wählen Sie Keine anstelle von Neue Bedingung angeben aus, um das Problem zu beheben.

Zugriffsprobleme nach der Migration

F: Warum erhalte ich nach der IAM-Migration die Fehlermeldung „403 Forbidden“, wenn ich versuche, auf bestimmte Seiten oder Funktionen (z. B. Playbooks oder IDE) zuzugreifen?

Ein 403-Fehler nach der Migration kann darauf hindeuten, dass der Google Cloud IAM-Rolle, die Ihrem Nutzer zugewiesen ist, Berechtigungen fehlen, die für die SOAR-Seite der Google SecOps-Plattform erforderlich sind. Das ist häufig der Fall, wenn Sie benutzerdefinierte IAM-Rollen verwenden.

Google SecOps-Rollen und -Berechtigungen Prüfen Sie, ob Ihre benutzerdefinierte IAM-Rolle alle Berechtigungen enthält, die für den Zugriff auf die erforderlichen SOAR-Funktionen erforderlich sind.

Sehen Sie sich optional die Entwicklertools Ihres Browsers an, um bestimmte API-Aufrufe zu identifizieren, die einen 403-Fehler zurückgeben. Die Antwortnutzlast dokumentiert die fehlende Berechtigung und in der Benutzeroberfläche wird auch ein Benachrichtigungsbanner mit den erforderlichen Zugriffsberechtigungen angezeigt.

Wenn keine dieser Lösungen hilft, erstellen Sie ein Support-Ticket.

Berechtigungen und Rollen

F: Ich habe die IAM-Migration manuell ohne das bereitgestellte Tool durchgeführt und habe jetzt Berechtigungsprobleme. Was kann ich tun?

Bei der manuellen IAM-Migration können manchmal erforderliche Berechtigungen für SOAR-Rollen fehlen. Wir empfehlen dringend, das bereitgestellte Migrationsskript zu verwenden, um sicherzustellen, dass alle erforderlichen Berechtigungen richtig eingerichtet sind. Wenn Sie die manuelle Migration weiterhin planen, lesen Sie sich die Google SecOps IAM-Berechtigungen genau durch, um die benutzerdefinierten Rollen mit den erforderlichen Berechtigungen zu erstellen.

F: Einige Nutzer scheinen nach der Migration mehr Berechtigungen in SOAR zu haben als erwartet. Was ist der Grund für diese Änderung?

Das kann passieren, wenn Nutzern oder Gruppen vor der Migration bereits vordefinierte Chronicle- Google Cloud Rollen zugewiesen waren. Nachdem Sie die Migration abgeschlossen haben, enthalten vordefinierte Chronicle-Rollen wie chronicle.apiAdmin automatisch SOAR-Berechtigungen. Beispielsweise umfasst die Rolle „Chronicle API Admin“ dann SOAR-Administratorberechtigungen.

So sorgen Sie für den Zugriff mit den geringsten Berechtigungen:

  1. Sehen Sie sich auf der Seite IAM-Rollen Ihre vordefinierten Rollen an, einschließlich „Chronicle API Admin“, um alle zugewiesenen Principals (Nutzer und Gruppen) zu ermitteln.
  2. Prüfen Sie, ob diesen Rollen nur Nutzer zugewiesen sind, die SOAR-Berechtigungen benötigen.
  3. Wenn Sie den SOAR-Zugriff für bestimmte Prinzipale einschränken möchten, entfernen Sie sie aus den vordefinierten Rollen und weisen Sie ihnen eine benutzerdefinierte Rolle zu, die SOAR-Administratorberechtigungen explizit ausschließt.

F: Die Migration war erfolgreich, aber ich sehe die Spalte „Berechtigungsgruppen“ auf der Seite „Gruppenzuordnung“ weiterhin. Warum?

Nach einer erfolgreichen Migration wird die Spalte Berechtigungsgruppen auf der Seite Gruppenzuordnung aus Gründen der Abwärtskompatibilität weiterhin angezeigt. Löschen Sie diese Zuweisungen nicht. Die Spalte wird bis zum 30. September 2026 entfernt. Das hat keine Auswirkungen auf Kunden.

Best Practices

  • Migrationsskript verwenden: Verwenden Sie nach Möglichkeit das offizielle Migrationsskript in Google Cloud , um die Umstellung von SOAR-Berechtigungsgruppen auf IAM-Rollen zu verwalten.
  • IAM-Berechtigungen prüfen: Machen Sie sich mit den erforderlichen Google Cloud IAM-Berechtigungen für verschiedene SOAR-Funktionen und -Rollen vertraut.
  • Gründlich testen: Testen Sie nach der Migration den Zugriff für verschiedene Nutzerrollen und ‑identitäten, um sicherzustellen, dass alles wie erwartet funktioniert.
  • Support kontaktieren: Wenn weiterhin Fehler auftreten oder das Verhalten unerwartet ist, wenden Sie sich an den Support und geben Sie so viele Details wie möglich an.

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