Häufig gestellte Fragen zur SOAR-Migration

Unterstützt in:

Antworten auf häufig gestellte Fragen zur SOAR-Migration 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 höhere Zuverlässigkeit, verbesserte Sicherheit, bessere Compliance und eine detailliertere Zugriffssteuerung. Außerdem bietet er über die Integration des Model Context Protocol (MCP) Zugriff auf agentische KI-Funktionen.

Die Migration bietet Folgendes:

  • Verbessert die Zuverlässigkeit und Monitoring-Funktionen von SOAR durch die Nutzung der erstklassigen API-Ebene von Google. Diese Ebene bietet eine führende API-Lösung mit erweiterten Funktionen für Kontingentverwaltung, Audits und Beobachtbarkeit.
  • Schaltet die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) für Funktionen und Daten auf der gesamten Plattform frei.
  • Bietet erweiterte Compliance-Funktionen wie VPC Service Controls, Datenstandort und kundenverwaltete Verschlüsselungsschlüssel (CMEK).

F: Was umfasst die Migration?

Die Migration umfasst die folgenden Komponenten:

  • SOAR-Projekt wird zu einem kundeneigenen Google Cloud Projekt migriert.
  • SOAR-Authentifizierung und ‑Berechtigungen zu Google Cloud IAM migrieren.
  • SOAR APIs zu Chronicle API migrieren.
  • Authentifizierungsinfrastruktur für Remote-Agents migrieren.

F: Welche Änderungen treten sofort nach der Migration in Kraft?

Unmittelbar nach der Migration gibt es einige wichtige Änderungen:

  • GCP-Projektinhaberschaft: Ihr SOAR-Projekt wird von der Inhaberschaft von Google zu Ihrem kundeninternen Google Cloud -Projekt 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, dass sie die Mitarbeiteridentitätsföderation übernehmen müssen. Die SAML-Konfiguration wird 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 über IdP-Gruppen (Identity Provider) verwaltet.
  • Audit-Logging: Audit-Logs werden detaillierter und 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 und Partner über diese Migration informiert?

Allen Kunden und Partnern wird ein In-Produkt-Pop-up mit dem Migrationsdatum und einem Link zu einem Formular angezeigt, das sie ausfüllen müssen. Sie werden aufgefordert, das Datum und die Uhrzeit der Migration zu bestätigen.

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

Nein, Ihre Kosten sind davon nicht betroffen. Im Frontend sollten Sie keine Änderungen bemerken. 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 zu Ihrem Google Cloud -Projekt. Wenn Sie Unified SecOps-Kunde sind, haben wir Ihre Google Cloud -Projekt-ID bereits. Wenn Sie ein eigenständiger SOAR-Kunde sind, müssen Sie uns Ihre Google Cloud Projekt-ID mitteilen.

F: Sollten Kunden, die bereits eine Google SecOps-Bereitstellung haben, dieselbe Projekt-ID wie für SIEM verwenden oder benötigen sie 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 von administrativen Abläufen wie RBAC und Logs.

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

Um die Migration zu ermöglichen, müssen Sie in Ihrer VPC-SC-Richtlinie sowohl Regeln für eingehenden als auch für ausgehenden Traffic definieren. Wenn Ihr Google Cloud -Projekt VPC Service Controls verwendet, wenden Sie sich an das Supportteam, um detaillierte Informationen zu diesen spezifischen Regeln zu erhalten.

Es gibt zwei API-Funktionen, die mit VPC-SC nicht unterstützt werden:

  • Webhooks
  • Playbook-Genehmigungslinks

F: Wie kann ich prüfen, ob die Migration erfolgreich war?

Prüfen Sie, ob der Vorgang erfolgreich abgeschlossen wurde, indem Sie zu SOAR-Einstellungen > Lizenzverwaltung gehen. Nach Phase 1 wird nach der Systemversionsnummer Google.com angezeigt. Nach der Migration der SOAR-Berechtigungen zu IAM-Rollen in Phase 2 wird nach der Systemversionsnummer sowohl Google.com als auch CloudIAM Enabled angezeigt.

Ausfallzeiten und Kontinuität

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

Ja. Die erwartete Ausfallzeit ist wie folgt:

  • Bis zu 2 Stunden für SOAR-Standalone-Kunden.
  • Bis zu 1,5 Stunden für Google SecOps-Kunden.

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

F: Werden während der Ausfallzeit generierte Daten automatisch aufgenommen, sobald die SOAR-Dienste wieder verfügbar sind?

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 Ruhezeit 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 während der Migration etwas schiefgeht?

Ja. Ihre vorhandene SOAR-Instanz bleibt während des Migrationsprozesses vollständig intakt (wenn auch deaktiviert). Wenn die Migration nicht erfolgreich abgeschlossen wird, können wir zu Ihrer vorhandenen Instanz zurückwechseln und die neue Instanz entfernen. Dieser Rollback-Vorgang dauert bis zu 30 Minuten. Wir führen umfangreiche Tests und eine genaue Überwachung durch. Außerdem steht ein Bereitschaftsteam zur Verfügung, um eine erfolgreiche Migration zu gewährleisten.

Wenn nach der Migration Zugriffsprobleme auftreten, ist die Authentifizierung wahrscheinlich falsch eingerichtet. Sie müssen sich mit Ihrem Identitäts-, IDP- oder Google Cloud Administrator abstimmen, um die Anleitung 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 Version 1 der SOAR-Endpunkte in der Chronicle API migrieren?

Ab Mitte Januar 2026 können Sie in der Chronicle API zu den neuen SOAR-Endpunkten v1 migrieren.

Die alte SOAR API und die zugehörigen API-Schlüssel werden eingestellt und funktionieren nach dem 31. März 2027 nicht mehr. Führen Sie die folgenden zwei Schritte aus, um einen reibungslosen Übergang zu gewährleisten:

  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 Console, 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 zuweisen.

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

Wenn Ihre bestehenden Nutzer einer der Gruppen entsprechen und die Berechtigungen korrekt zugeordnet sind, sollte es keine Auswirkungen auf Ihre bestehenden Nutzerkonten geben. Wenn Nutzer jedoch keinen Gruppen zugeordnet sind, können sie sich nicht anmelden. Wenn Berechtigungen anders zugeordnet sind, 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 Identitätsföderation von Mitarbeitern für die Authentifizierung definieren und für jeden Anbieter einen separaten Personalpool erstellen. Jeder Anbieter ist mit einer anderen Subdomain verknüpft. Weitere Informationen finden Sie im MSSP-Migrationsleitfaden.

F: Wie authentifiziere ich mich bei der Chronicle API?

Folgen Sie der Anleitung unter Bei der Chronicle API authentifizieren.

F: Welche neuen IP-Adressen sind für den Zugriff auf die neue SOAR API erforderlich?

Es ist nicht erforderlich, IP-Adressen für den Zugriff auf die Chronicle API auf die Zulassungsliste zu setzen. Optional können Sie die hier und hier angegebenen IP-Adressbereiche auf die Zulassungsliste setzen.

Logging und Monitoring

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

Protokolle 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 senden, nach der Migration weiterhin auf diese BigQuery-Daten zugreifen?

Ja. Die vorhandene verwaltete BigQuery-Instanz funktioniert weiterhin.

Logistik und Support

F: Kann ich ein anderes Zeitfenster 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 Statusupdates in Echtzeit?

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

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

Wenn nach der Migration Zugriffsprobleme auftreten, ist die Authentifizierungseinrichtung wahrscheinlich falsch. Sie müssen sich mit Ihrem Identitäts-, IDP- oder Google Cloud Administrator abstimmen, um die Anleitung 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 können.

Probleme mit dem Migrationstool und den Migrationsskripts

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: Für das Migrationstool muss Ihr Nutzerkonto sowohl in der Google Cloud als auch in der Google SecOps-Instanz ausreichende Berechtigungen haben. Sie müssen mit einem Konto angemeldet sein, 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 dies zu Autorisierungsfehlern führen. Wenn Sie die erforderlichen Berechtigungen haben und das Migrationsskript trotzdem nicht laden können, öffnen Sie ein Support-Ticket.

  • SIEM verwendet kein Cloud IAM: 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 in der Anleitung zur Migration von Legacy-RBAC zu Feature-RBAC.

F: Beim Ausführen der Migrationsskripts tritt ein Fehler auf. Was soll ich tun?

  • Fehler – „Gruppe existiert nicht“: Wenn Sie add-iam-policy-binding commands verwenden, müssen Sie für das Flag --member die vollständige E-Mail-Adresse der Gruppe (z. B. your-group@example.com) und nicht nur den Kurznamen der Gruppe angeben.

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

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 Ihrem Nutzer zugewiesenen IAM-Rolle Google Cloud Berechtigungen fehlen, die für die SOAR-Seite der Google SecOps-Plattform erforderlich sind. Dies ist häufig der Fall, wenn Sie benutzerdefinierte IAM-Rollen verwenden.

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

Optional können Sie die Entwicklertools Ihres Browsers verwenden, um bestimmte API-Aufrufe zu identifizieren, die einen 403-Fehler zurückgeben. In der Antwortnutzlast wird die fehlende Berechtigung dokumentiert. Außerdem wird in der Benutzeroberfläche ein Benachrichtigungsbanner mit Details zum erforderlichen Zugriff angezeigt.

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

Berechtigungen und Rollen

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

Bei der manuellen IAM-Migration kann es vorkommen, dass erforderliche Berechtigungen für SOAR-Rollen fehlen. Wir empfehlen dringend, das bereitgestellte Migrationsskript zu verwenden, um sicherzustellen, dass alle erforderlichen Berechtigungen korrekt eingerichtet sind. Wenn Sie die Migration trotzdem manuell durchführen möchten, lesen Sie die Informationen zu den IAM-Berechtigungen für Google SecOps sorgfältig 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 wurden. Nach Abschluss der Migration enthalten vordefinierte Chronicle-Rollen wie chronicle.apiAdmin automatisch SOAR-Berechtigungen. Beispielsweise umfasst die Rolle „Chronicle API Admin“ dann „SOAR Admin“-Berechtigungen.

Damit der Zugriff nach dem Prinzip der geringsten Berechtigung erfolgt, führen Sie folgende Schritte aus:

  1. Prüfen Sie Ihre vordefinierten Rollen auf der Seite IAM-Rollen, einschließlich „Chronicle API Admin“, um alle zugewiesenen Hauptkonten (Nutzer und Gruppen) zu identifizieren.
  2. Achten Sie darauf, dass nur Nutzer, die SOAR-Berechtigungen benötigen, diesen Rollen zugewiesen sind.
  3. Wenn Sie den SOAR-Zugriff für bestimmte Hauptkonten einschränken möchten, entfernen Sie sie aus den vordefinierten Rollen und weisen Sie sie einer benutzerdefinierten Rolle zu, die SOAR-Administratorberechtigungen explizit ausschließt.

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

Nach einer erfolgreichen Migration wird die Spalte Berechtigungsgruppen aus Gründen der Abwärtskompatibilität weiterhin auf der Seite Gruppenzuordnung angezeigt. Löschen Sie diese Zuweisungen nicht. Die Spalte wird bis zum 31. März 2027 entfernt, ohne dass dies Auswirkungen auf Kunden hat.

Best Practices

  • Migrationsscript verwenden: Verwenden Sie nach Möglichkeit das offizielle Migrationsscript 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 Personas, um sicherzustellen, dass alles wie erwartet funktioniert.
  • Support kontaktieren: Wenn Sie anhaltende Fehler oder unerwartetes Verhalten feststellen, 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