Wir haben die Navigationsstruktur unserer Dokumentation neu organisiert, um sie direkt an Ihre betrieblichen Arbeitsabläufe anzupassen. Weitere Informationen finden Sie in den Versionshinweisen und im Video zur Anleitung.

Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Häufig gestellte Fragen zur SOAR-Migration

Unterstützt in:

Google secops SOAR

Antworten auf häufig gestellte Fragen zum SOAR-Migrationsprozess Lösungen für häufig auftretende Probleme und Best Practices für einen erfolgreichen Übergang

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 wird der Zugriff auf agentische KI-Funktionen durch die Integration des Model Context Protocol (MCP) ermöglicht.

Die Migration bietet Folgendes:

Verbessert die Zuverlässigkeit und Monitoringfunktionen 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 das Kontingentmanagement, die Auditierung und die Beobachtbarkeit.
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:

Migration des SOAR-Projekts zu einem vom Kunden verwalteten Google Cloud Projekt
Migration der SOAR-Authentifizierung und -Berechtigungen zu Google Cloud IAM
Migration der SOAR-APIs zur Chronicle API
Migration der Authentifizierungsinfrastruktur für Remote-Agents

F: Welche unmittelbaren Änderungen ergeben sich nach der Migration?

Unmittelbar nach der Migration ergeben sich mehrere wichtige Änderungen:

GCP-Projekteigentümerschaft: Ihr SOAR-Projekt wird von Google zu Ihrem vom Kunden verwalteten Google Cloud Projekt migriert.
Authentifizierung:
- Unified SecOps-Kunden: Keine Änderung. Die Authentifizierung wird weiterhin von by Google Cloud IAM verwaltet.
- Eigenständige SOAR-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 nicht mehr im SOAR-System selbst gespeichert und verwaltet, was zu strengeren Sicherheitskontrollen führt.
RBAC: Die Nutzerberechtigungen werden detaillierter und mit IAM verwaltet. Umgebungen und SOC-Rollen werden weiterhin im SOAR-Modul mit Gruppen des Identitätsanbieters (Identity Provider, IdP) verwaltet.
Audit-Logging: Audit-Logs sind detaillierter und werden in **Cloud-Audit-Logs ** verwaltet.
Neue URL (nur SOAR): Eigenständige SOAR-Nutzer erhalten eine neue URL (neue Domain) für den Zugriff auf SOAR.

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

Für alle Kunden und Partner wird ein In-Product-Pop-up mit dem Migrationsdatum und einem Link zu einem Formular angezeigt, das ausgefüllt werden muss. Sie werden aufgefordert, das Migrationsdatum und das Zeitfenster zu bestätigen.

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

Nein, Ihre Kosten sind nicht betroffen. Sie sollten keine Änderungen im Frontend feststellen. In Ihrem Projekt werden keine neuen Ressourcen ausgeführt, daher fallen keine zusätzlichen Kosten an.

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 bereits Ihre Google Cloud Projekt-ID. Wenn Sie 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 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. So können Sie Verwaltungsabläufe wie RBAC und Logs einheitlich verwalten.

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

Um die Migration zu aktivieren, müssen Sie sowohl Ingress- als auch Egress-Regeln 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 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 unter SOAR-Einstellungen > Lizenzverwaltung , ob die Migration erfolgreich abgeschlossen wurde. Nach Phase 1 wird nach der Systemversionsnummer Google.com angezeigt. Nach Phase 2 der Migration von SOAR-Berechtigungen zu IAM-Rollen werden nach der Systemversionsnummer sowohl Google.com als auch CloudIAM aktiviert angezeigt.

Ausfallzeit und Kontinuität

F: Gibt es während der Migration eine Ausfallzeit und welche Auswirkungen hat sie?

Ja. Die erwartete Ausfallzeit ist wie folgt:

Bis zu 2 Stunden für eigenständige SOAR-Kunden
Bis zu 1,5 Stunden für Google SecOps-Kunden

Während dieser Zeit 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 aufgenommen, sobald die SOAR-Dienste wieder aufgenommen werden?

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

Ja. Durch den Migrationsprozess bleibt Ihre vorhandene SOAR-Instanz vollständig erhalten (wird jedoch deaktiviert). Wenn der Migrationsprozess nicht erfolgreich abgeschlossen wird, können wir zu Ihrer vorhandenen Instanz zurückkehren und die neue entfernen. Dieser Rollback-Prozess dauert bis zu 30 Minuten. Wir führen umfassende Tests und ein genaues Monitoring 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ätsanbieter, IdP oder Google Cloud Administrator abstimmen, um die Anleitung zur Fehlerbehebung für die 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-Endpunkte-Version 1 in der Chronicle API migrieren?

Sie können ab Mitte Januar 2026 zu den neuen SOAR-Endpunkten Version 1 in der Chronicle API migrieren.

Die Legacy-SOAR-API und -API-Schlüssel werden verworfen und funktionieren nach dem 30. November 2026 nicht mehr. Führen Sie die folgenden beiden obligatorischen Schritte aus, um einen reibungslosen Übergang zu gewährleisten:

Sie müssen zuerst die Migration von SOAR-Berechtigungsgruppen zu Cloud IAM abschließen.
Aktualisieren Sie Ihre vorhandenen Skripts und Integrationen, um die Legacy-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 Skript weist benutzerdefinierte Rollen auch Nutzern (für Cloud Identity-Kunden) oder zu IdP-Gruppen (für Workforce Identity Federation-Kunden) zu.

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

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

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

Wenn Ihre vorhandenen Nutzer einer der Gruppen entsprechen und die Berechtigungen korrekt zugeordnet sind, sollten sich keine Auswirkungen auf Ihre vorhandenen Nutzerkonten ergeben. Wenn Nutzer jedoch nicht 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 Authentifizierung von SOAR konfiguriert haben, sollten die Mitarbeiteridentitätsföderation für die Authentifizierung definieren und für jeden Anbieter einen separaten Mitarbeiterpool 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 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 den Cloud-Audit-Logs.

Logs werden nach Abschluss der ersten Migrationsphase auf der SOAR-Plattform gespeichert. Logs sind nach Abschluss der zweiten Migrationsphase in Ihrem Google Cloud Projekt verfügbar.

F: Können Kunden, die SOAR-Daten an eine verwaltete BigQuery-Instanz (BQ) 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 Statusaktualisierungen in Echtzeit?

Sie erhalten sowohl zu Beginn als auch am Ende des Migrationsprozesses eine E-Mail-Benachrichtigung.

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

SOAR-Berechtigungsgruppen zu IAM migrieren

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

Probleme mit dem Migrationstool und ‑skript

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 Google Cloud als auch in der Google SecOps-Instanz ausreichende Berechtigungen haben. 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. Die Verwendung verschiedener Konten für Google Cloud und SOAR kann 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 nicht Cloud IAM: Wenn Sie Google SecOps Unified-Kunde sind, achten Sie darauf, dass Sie IAM verwenden, um Rollen und Berechtigungen für die SIEM-Seite der Plattform zu verwalten. Weitere Informationen finden Sie im Migrationsleitfaden von Legacy-RBAC zu Feature-RBAC.

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

Fehler: „Group does not exist“ : Wenn Sie die add-iam-policy-binding commands verwenden, achten Sie darauf, dass Sie die vollständige E-Mail-Adresse der Gruppe (z. B. your-group@example.com) für das Flag --member verwenden und nicht nur den kurzen Gruppennamen.
Fehler im Zusammenhang mit vorhandenen Rollen: Es können Konflikte auftreten, wenn Sie eine Bindung an ein Prinzipal vornehmen, das bereits bedingte Bindungen hat. Führen Sie das Skript noch einmal aus und wählen Sie Ohne anstelle von Neue Bedingung angeben aus, um dieses Problem zu beheben.

Zugriffsprobleme nach der Migration

F: Warum erhalte ich nach der IAM-Migration einen „403 Forbidden“-Fehler, 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 Ihrem Nutzer zugewiesenen IAM-Rolle 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. Die Antwortnutzlast dokumentiert die fehlende Berechtigung. Außerdem wird in der Benutzeroberfläche ein Benachrichtigungsbanner mit den erforderlichen Zugriffsberechtigungen 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 beheben?

Bei der manuellen IAM-Migration fehlen manchmal die erforderlichen Berechtigungen für SOAR-Rollen. 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, prüfen Sie die Google SecOps-IAM-Berechtigungen sorgfältig, 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. Warum passiert das?

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

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

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

F: Die Migration war erfolgreich, aber ich sehe die Spalte „Berechtigungsgruppen“ immer noch auf der Seite „Gruppenzuordnung“. 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. November 2026 entfernt, ohne dass sich dies auf Kunden auswirkt.

Best Practices

Migrationsskript verwenden: Verwenden Sie nach Möglichkeit das offizielle Migrationsskript Google Cloud , um den Übergang von SOAR-Berechtigungsgruppen zu 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: Wenden Sie sich bei anhaltenden Fehlern oder unerwartetem Verhalten 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