SOAR-Berechtigungen zu IAM migrieren

Unterstützt in:

Google SecOps SOAR

Dieses Dokument richtet sich sowohl an Kunden von Google Security Operations Unified als auch an SOAR-Standalone-Nutzer, die ihre Umgebung von vorhandenen SOAR-Berechtigungsgruppen zu Google Cloud Identity and Access Management (IAM) für die Zugriffssteuerung migrieren müssen. Video zur SOAR-IAM-Migration

Hinweis :Mit dem Migrationstool können Sie neue benutzerdefinierte IAM-Bindungen für vorhandene Berechtigungen für SOAR-Einstellungen vorschlagen. Weitere Informationen finden Sie unter Feature-RBAC.

Der Google Cloud -Konsolenbestätigungsprozess automatisiert die Umstellung von SOAR-Berechtigungen aufGoogle Cloud -IAM, indem er die folgenden wichtigen Schritte ausführt:

• Liest vorhandene Berechtigungskonfigurationen, einschließlich benutzerdefinierter Berechtigungsgruppen und Nutzerzuweisungen.
• Erstellt benutzerdefinierte IAM-Rollen, die die vorhandenen Berechtigungsgruppen replizieren.
• Ordnet vorhandene Nutzer und Gruppen neu erstellten IAM-Rollen zu, damit alle Zugriffsberechtigungen beibehalten werden.
• Erstellt IAM-Richtlinien, um Nutzer und Gruppen an ihre zugewiesenen Rollen zu binden.

Hinweis

Bestätigen Sie vor dem Start der Migration, dass die folgenden Anforderungen erfüllt sind:

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

• Achten Sie darauf, dass Sie für die Google Cloud Console und SOAR dieselbe Identität (E-Mail-Adresse oder Konto) verwenden.

• Zuordnung zu IdP-Gruppen: Wenn Sie die Mitarbeiteridentitätsföderation für die Authentifizierung verwenden, prüfen Sie auf der Seite Gruppenzuordnung, ob alle Nutzer entsprechenden Gruppen des Identitätsanbieters (IdP) zugeordnet sind. Informationen zur Zuordnung zu IdP-Gruppen finden Sie unter Nutzer in der Plattform zuordnen. Das Migrationstool erstellt mithilfe dieser Zuordnungen ein Script, das Nutzer-E-Mail-Adressen oder Gruppen an IAM-Prinzipale bindet.

• Zuordnung zu E‑Mail-Gruppen: Wenn Sie Cloud Identity für die Authentifizierung verwenden, prüfen Sie auf der Seite Gruppenzuordnung, ob alle Nutzer entsprechenden E‑Mail-Gruppen zugeordnet sind. Informationen zur E-Mail-Zuordnung finden Sie unter Nutzer auf der Plattform mithilfe von Cloud Identity zuordnen. Das Migrationstool erstellt mithilfe dieser Zuordnungen ein Script, das Nutzer-E-Mail-Adressen oder Gruppen an IAM-Prinzipale bindet.

• Optional: SOAR-API-Schlüssel. Wenn Sie keine SOAR-Berechtigungen haben, um den aktuellen Nutzer auf der Seite Gruppenzuordnungen zuzuordnen, können Sie einen SOAR-Administrator bitten, einen SOAR-API-Schlüssel bereitzustellen, und diesen zum Generieren der Skripts verwenden.

Der SOAR-Administrator sollte die Schritte im folgenden Verfahren ausführen:

1. Rufen Sie in der Google SecOps-Plattform SOAR-Einstellungen> „Erweitert“ > „Berechtigungsgruppen (API-Schlüssel)“ auf.
2. Erstellen Sie eine Berechtigungsgruppe und achten Sie darauf, dass das Modul Einstellungen und die Optionen unter „Einstellungen“ alle ausgewählt sind.
3. Gehen Sie zu SOAR-Einstellungen> „Erweitert“ > „API-Schlüssel“.
4. Fügen Sie einen neuen API-Schlüssel hinzu und wählen Sie dabei die von Ihnen erstellte Berechtigungsgruppe aus.
5. Kopieren Sie den generierten API-Schlüssel.

• Berechtigungen: Prüfen Sie, ob Sie die erforderlichen Berechtigungen haben:

  • Chronicle API-Administrator
  • Administrator von Chronicle-Dienst
  • Chronicle SOAR Admin

Warnung :Nachdem Sie IAM aktiviert haben, werden alle vordefinierten Chronicle-Rollen mit SOAR-Berechtigungen aktiviert. „Chronicle API Admin“ umfasst jetzt SOAR-Administratorberechtigungen. Wenn die Prinzipale (Nutzer / Gruppen), die den vordefinierten Chronicle-Rollen zugewiesen sind, keine oder nur eingeschränkte SOAR-Berechtigungen haben sollen, empfiehlt sich deren Zuweisung zu einer benutzerdefinierten Rolle, die SOAR-Berechtigungen explizit ausschließt.

Wenn nach der Migration ungelöste Probleme auftreten, klicken Sie auf IAM deaktivieren, um die Migration von Berechtigungsgruppen zu IAM-Rollen rückgängig zu machen. Die neu erstellten IAM-Rollen und ‑Bindungen werden nicht gelöscht.

Eine vollständige Liste der für jede Rolle erforderlichen Berechtigungen finden Sie unter Erforderliche IAM-Berechtigungen.

Es gibt zwei Möglichkeiten, SOAR-Berechtigungen zu migrieren:

• Google Cloud CLI verwenden
• Terraform verwenden

SOAR-Berechtigungen mit der Google Cloud CLI migrieren

So migrieren Sie Ihre SOAR-Berechtigungen zu Google Cloud IAM:

1. Rufen Sie in der Google Cloud Console die Google SecOps-Verwaltungseinstellungen auf.
2. Klicken Sie auf den Tab SOAR IAM Migration (SOAR-IAM-Migration).
3. Kopieren Sie im Abschnitt Rollenbindungen migrieren die Google Cloud CLI-Befehle. Wenn Sie die Möglichkeit haben, eine neue Bedingung anzugeben, wählen Sie „2“ aus. Keine. .
4. Klicken Sie in der Google Cloud -Symbolleiste auf Cloud Shell aktivieren.
5. Fügen Sie die Google Cloud CLI-Befehle in das Terminalfenster ein und drücken Sie die Eingabetaste.
6. Prüfen Sie, ob die Skripts erfolgreich ausgeführt wurden.
7. Kehren Sie zur Google Cloud Console zurück und klicken Sie im Bereich Finished with this task (Aufgabe abgeschlossen) auf Enable IAM (IAM aktivieren).

SOAR-Berechtigungen mit Terraform migrieren

So migrieren Sie Ihre SOAR-Berechtigungen mit Terraform zu Google Cloud IAM:

1. Rufen Sie in der Google Cloud Console die Google SecOps-Verwaltungseinstellungen auf.
2. Klicken Sie auf den Tab SOAR IAM Migration (SOAR-IAM-Migration).
3. Kopieren Sie im Abschnitt Rollenbindungen migrieren die Google Cloud CLI-Befehle.
4. Rufen Sie Ihr Terraform-Repository auf und ordnen Sie die Google Cloud CLI-Befehle den entsprechenden Terraform-Befehlen zu. In der folgenden Tabelle wird der Google Cloud CLI-Befehl zum Erstellen einer benutzerdefinierten Rolle den Terraform-Befehlen zugeordnet.

gcloud-Flag	Terraform-Argument	Hinweise
ROLE_ID (positionell)	role_id	Geben Sie in Terraform nicht das Präfix projects/PROJECT_ID/roles/ an. Verwenden Sie nur den ID-String (z. B. myCustomRole).
--project	project	Die ID des Projekts, in dem die benutzerdefinierte Rolle definiert ist.
--title	title	Ein für Menschen lesbarer Titel für die Rolle.
--description	description	Eine Zusammenfassung des Zwecks und der Berechtigungen der Rolle.
--permissions	permissions	gcloud akzeptiert einen kommagetrennten String. Terraform erfordert eine Liste mit Strings: ["perm.a", "perm.b"].
--stage	stage	Zulässige Werte: ALPHA, BETA, GA, DEPRECATED, DISABLED, EAP.

Hinweis: Achten Sie darauf, dass jedes --flag in Ihrer Befehlszeile korrekt mit dem entsprechenden Argument im Terraform-Ressourcenblock verknüpft ist.

Google Cloud CLI-Zuordnung zu Terraform-Beispiel

Google Cloud CLI-Befehl:

gcloud iam roles create SOAR_Custom_managedUser_google.com --project="{customer project}" 
--title="SOAR Custom managedUser Role" 
--description="SOAR Custom role generated for IDP Mapping Group ManagedUser" 
--stage=GA 
--permissions=chronicle.cases.get

Terraform-Befehl:

resource "google_project_iam_custom_role" "{terraform_name}" {
  role_id     = "SOAR_Custom_managedUser_google.com"
  title       = "SOAR Custom managedUser Role"
  project     = "{customer project}"
  stage       = "GA"
  permissions = [
    #This is an example!
    "chronicle.cases.get"
  ]
}

IAM-Richtlinienbindungen (Rollen zuweisen)

Wenn Sie Google Cloud CLI projects add-iam-policy-binding verwenden, weisen Sie einem bestimmten Mitglied (Nutzer, Dienstkonto oder Gruppe) eine bestimmte Rolle zu. In der folgenden Tabelle werden Google Cloud CLI-Befehle Terraform-Befehlen zugeordnet. Ordnen Sie die Befehle zu, um IAM-Rollen zuzuweisen.

gcloud-Flag	Terraform-Argument	Hinweise
PROJECT_ID (positionell)	project	Die ID des Zielprojekts.
--member	member	Die Identität des Hauptkontos, z. B. user:email, serviceAccount:email oder group:email.
--role	role	Die Rollen-ID. Verwenden Sie den vollständigen Pfad für benutzerdefinierte Rollen (projects/ID/roles/NAME) und den Kurznamen für Standardrollen (roles/NAME).

Beispiel für die Zuweisung von Rollen

Google Cloud CLI-Befehl:

gcloud projects add-iam-policy-binding
 {customer project}
--member="user:[e-mail]" 
--role="projects/{customer project}/roles/SOAR_Custom_managedUser_google.com"

Terraform-Befehl:

resource "google_project_iam_member" "{terraform_name}" {
  project = "{customer project}"
  role    = "projects/{customer project}/roles/SOAR_Custom_managedUser_google.com"
  member  = "user:[e-mail]"
}

Hinweis :Google empfiehlt die Verwendung von google_project_iam_binding (die Einzahl „binding“ entspricht dem Namen des Google Cloud CLI-Befehls) nicht, da dadurch alle anderen Nutzer mit dieser Rolle entfernt werden, wenn sie nicht in Ihrem Code aufgeführt sind. Verwenden Sie stattdessen google_project_iam_member.

Wichtig :Die Spalte Berechtigungsgruppe wird nach der Migration weiterhin auf der Seite Gruppenzuordnung angezeigt, um die Abwärtskompatibilität mit der alten SOAR API zu gewährleisten. Löschen Sie diese Aufgaben nicht. Die Spalte wird bis zum 30. November 2026 automatisch entfernt. Das hat keine Auswirkungen auf die Kunden.

Migration von Beiträgen

Nachdem Sie auf die Verwendung von IAM-Berechtigungen umgestellt haben, muss jeder curl-Befehl, den Sie zum Aufrufen einer API verwenden, entweder mit einem zugeordneten Dienstkonto (in IDP-Zuordnungsgruppen zugeordnet) oder mit einem Nutzer gesendet werden, der sich mindestens einmal auf der Plattform angemeldet hat.

FAQ

• Eine detaillierte Liste der Probleme und Best Practices finden Sie in den FAQs zur Migration von IAM-Rollen.