Esegui la migrazione delle autorizzazioni SOAR a IAM

Supportata in:

Google SecOps SOAR

Questo documento è rivolto sia ai clienti unificati di Google Security Operations sia agli utenti autonomi di SOAR che devono eseguire la migrazione del proprio ambiente dai gruppi di autorizzazioni SOAR esistenti a Google Cloud Identity and Access Management (IAM) per controllo dell'accesso. Per una procedura dettagliata di questa procedura, guarda il video sulla migrazione IAM SOAR

Nota: lo strumento di migrazione può aiutarti a proporre nuove associazioni IAM personalizzate per le autorizzazioni Impostazioni SOAR esistenti. Per saperne di più, consulta RBAC delle funzionalità.

La procedura di verifica della console Google Cloud automatizza la transizione dalle autorizzazioni SOAR a Google Cloud IAM eseguendo i seguenti passaggi chiave:

• Legge le configurazioni delle autorizzazioni esistenti, inclusi i gruppi di autorizzazioni personalizzati e le assegnazioni degli utenti.
• Genera ruoli IAM personalizzati che replicano i gruppi di autorizzazioni esistenti.
• Mappa gli utenti e i gruppi esistenti ai ruoli IAM appena creati per garantire che tutti i privilegi di accesso vengano mantenuti.
• Crea policy IAM per associare utenti e gruppi ai ruoli assegnati.

Prima di iniziare

Prima di iniziare la migrazione, verifica che siano soddisfatti i seguenti requisiti:

• Se sei un cliente Google SecOps unificato, assicurati di utilizzare Cloud IAM per gestire i ruoli e le autorizzazioni per il lato SIEM della piattaforma. Per saperne di più, consulta Esegui la migrazione da RBAC legacy a RBAC delle funzionalità.

• Assicurati di utilizzare la stessa identità (email o account) sia per la console Google Cloud sia per SOAR.

• Mappatura gruppi di IdP: se utilizzi la federazione delle identità per la forza lavoro per l'autenticazione, verifica che tutti gli utenti siano mappati a gruppi del provider di identità (IdP) nella pagina Mappatura gruppi. Per informazioni sulla mappatura di gruppi IdP, consulta Mappa gli utenti nella piattaforma. Lo strumento di migrazione utilizza queste mappature per creare uno script che associa email o gruppi di utenti a entità IAM.

• Mappatura gruppi di email: se utilizzi Cloud Identity per l'autenticazione, verifica che tutti gli utenti siano mappati a gruppi di email nella pagina Mappatura gruppi. Per informazioni sulla mappatura di email, consulta Mappa gli utenti nella piattaforma utilizzando Cloud Identity. Lo strumento di migrazione utilizza queste mappature per creare uno script che associa email o gruppi di utenti a entità IAM.

• (Facoltativo) Chiave API SOAR. Se non disponi delle autorizzazioni SOAR per mappare l'utente corrente nella pagina Mappature di gruppi, puoi chiedere a un amministratore SOAR di fornire una chiave API SOAR e utilizzarla per generare gli script.

L'amministratore SOAR deve eseguire i passaggi della seguente procedura:

1. Nella piattaforma Google SecOps, vai a Impostazioni SOAR > Avanzate > Gruppi di autorizzazioni (chiavi API).
2. Crea un gruppo di autorizzazioni assicurandoti che il modulo Impostazioni e le opzioni in Impostazioni siano tutti selezionati.
3. Vai a Impostazioni SOAR > Avanzate > Chiavi API.
4. Aggiungi una nuova chiave API assicurandoti di selezionare il gruppo di autorizzazioni che hai creato.
5. Copia la chiave API generata.

• Autorizzazioni: verifica di disporre delle autorizzazioni necessarie:

  • Chronicle API Admin
  • Chronicle Service Admin
  • Chronicle SOAR Admin

Avviso: dopo aver abilitato IAM, tutti i ruoli predefiniti di Chronicle verranno attivati con le autorizzazioni SOAR. Chronicle API Admin includerà ora le autorizzazioni amministrative di SOAR Admin. Se non vuoi che le entità (utenti/gruppi) assegnate ai ruoli predefiniti di Chronicle dispongano delle autorizzazioni SOAR o se vuoi limitare le loro autorizzazioni, ti consigliamo di assegnarle a un ruolo personalizzato che escluda esplicitamente le autorizzazioni SOAR.

Dopo la migrazione, se sono presenti problemi non risolti, fai clic su Disattiva IAM per ripristinare la migrazione dai gruppi di autorizzazioni ai ruoli IAM. I ruoli e le associazioni IAM appena creati non verranno eliminati.

Per un elenco completo delle autorizzazioni necessarie per ogni ruolo, consulta Autorizzazioni IAM richieste.

Esistono due modi per eseguire la migrazione delle autorizzazioni SOAR:

• Con Google Cloud CLI
• Utilizzo di Terraform

Esegui la migrazione delle autorizzazioni SOAR utilizzando Google Cloud CLI

Per eseguire la migrazione delle autorizzazioni SOAR a Google Cloud IAM, segui questi passaggi:

1. Nella console Google Cloud , vai alle impostazioni di amministrazione di Google SecOps.
2. Fai clic sulla scheda SOAR IAM Migration (Migrazione IAM SOAR).
3. Nella sezione Esegui la migrazione delle associazioni di ruoli, copia i comandi di Google Cloud CLI. Quando ti viene data l'opzione di specificare una nuova condizione, seleziona 2. Nessuno. .
4. Nella barra degli strumenti di Google Cloud , fai clic su Attiva Cloud Shell.
5. Nella finestra del terminale, incolla i comandi di Google Cloud CLI e premi Invio.
6. Assicurati che gli script vengano eseguiti correttamente.
7. Torna alla console Google Cloud e, nella sezione Hai finito con questa attività, fai clic su Abilita IAM.

Esegui la migrazione delle autorizzazioni SOAR utilizzando Terraform

Per eseguire la migrazione delle autorizzazioni SOAR a Google Cloud IAM utilizzando Terraform, segui questi passaggi:

1. Nella console Google Cloud , vai alle impostazioni di amministrazione di Google SecOps.
2. Fai clic sulla scheda Migrazione IAM SOAR.
3. Nella sezione Esegui la migrazione delle associazioni di ruoli, copia i comandi di Google Cloud CLI.
4. Vai al tuo repository Terraform e mappa i comandi di Google Cloud CLI ai corrispondenti equivalenti di Terraform. La tabella seguente mappa il comando di creazione di un ruolo personalizzato di Google Cloud CLI con i comandi Terraform.

Flag gcloud	Argomento Terraform	Note
ROLE_ID (Posizionale)	role_id	In Terraform, non includere il prefisso projects/PROJECT_ID/roles/. Utilizza solo la stringa dell'ID (ad esempio, myCustomRole).
--project	project	L'ID del progetto in cui è definito il ruolo personalizzato.
--title	title	Un titolo leggibile per il ruolo.
--description	description	Un riepilogo dello scopo e delle autorizzazioni del ruolo.
--permissions	permissions	gcloud accetta una stringa separata da virgole. Terraform richiede un elenco di stringhe: ["perm.a", "perm.b"].
--stage	stage	Valori validi: ALPHA, BETA, GA, DEPRECATED, DISABLED, EAP.

Nota: assicurati che ogni --flag della riga di comando sia associato correttamente all'argomento corrispondente all'interno del blocco di risorse Terraform.

Esempio di mappatura di Google Cloud CLI a Terraform

Comando Google Cloud CLI:

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

Comando Terraform:

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"
  ]
}

Associazioni di policy IAM (assegnazione dei ruoli)

Quando utilizzi Google Cloud CLI projects add-iam-policy-binding, concedi un ruolo specifico a un membro specifico (utente, account di servizio o gruppo). La tabella seguente mappa i comandi di Google Cloud CLI con i comandi di Terraform. Mappa i comandi per assegnare i ruoli IAM.

Flag gcloud	Argomento Terraform	Note
PROJECT_ID (Posizionale)	project	L'ID del progetto di destinazione.
--member	member	L'identità dell'entità (ad esempio user:email, serviceAccount:email, group:email).
--role	role	L'ID ruolo. Utilizza il percorso completo per i ruoli personalizzati (projects/ID/roles/NAME) e il nome breve per i ruoli standard (roles/NAME).

Esempio di assegnazione di un ruolo

Comando Google Cloud CLI:

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

Comando Terraform:

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

Nota: Google sconsiglia di utilizzare google_project_iam_binding ("binding" al singolare corrisponde al nome del comando Google Cloud CLI), in quanto rimuoverà chiunque altro abbia quel ruolo se non è elencato nel tuo codice. Utilizza invece google_project_iam_member.

Importante: la colonna Gruppo di autorizzazioni continua a essere visualizzata nella pagina Mappatura dei gruppi dopo la migrazione per garantire la compatibilità con le versioni precedenti dell'API SOAR legacy. Non eliminare queste assegnazioni. La colonna verrà rimossa automaticamente entro il 31 marzo 2027 senza alcun impatto sui clienti.

Migrazione dei post

Dopo aver eseguito il passaggio all'utilizzo delle autorizzazioni IAM, ogni comando curl utilizzato per chiamare un'API deve essere inviato con un account di servizio mappato (mappato nei gruppi di mappatura IDP) o con un utente che ha eseguito l'accesso alla piattaforma almeno una volta.

Domande frequenti

• Per un elenco dettagliato dei problemi e delle best practice, consulta le Domande frequenti sulla migrazione dei ruoli IAM.