Abbiamo riorganizzato la struttura di navigazione della documentazione per allinearla direttamente ai tuoi flussi di lavoro operativi. Per ulteriori informazioni, consulta le note di rilascio e il video dimostrativo.

Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Domande frequenti sulla migrazione SOAR

Supportato in:

Google SecOps SOAR

Leggi le risposte alle domande frequenti sulla procedura di migrazione SOAR. Trova soluzioni ai problemi frequenti e best practice per una transizione riuscita.

Ambito e impatto della migrazione

D: Perché è necessaria questa migrazione?

Stiamo modernizzando l'infrastruttura SOAR eseguendo la migrazione a Google Cloud. Questo upgrade critico offre vantaggi chiave, tra cui maggiore affidabilità, sicurezza migliorata, maggiore conformità e controllo dell'accesso più granulare. Consente inoltre di accedere alle funzionalità di AI agentica tramite l'integrazione del Model Context Protocol (MCP).

La migrazione offre quanto segue:

Migliora l'affidabilità e le funzionalità di monitoraggio di SOAR utilizzando il livello API avanzatissimo di Google. Questo livello fornisce una soluzione API leader con funzionalità avanzate per la gestione delle quote, l'audit e l'osservabilità.
Sblocca il controllo degli accessi sulla base dei ruoli (RBAC) per funzionalità e dati in tutta la piattaforma.
Fornisce funzionalità di conformità più elevate, come i Controlli di servizio VPC, la residenza dei dati e le chiavi di crittografia gestite dal cliente (CMEK).

D: Qual è l'ambito della migrazione?

La migrazione riguarda i seguenti componenti:

Migrazione del progetto SOAR a un progetto di proprietà del cliente Google Cloud .
Migrazione dell'autenticazione e delle autorizzazioni SOAR a Google Cloud IAM.
Migrazione delle API SOAR all'API Chronicle.
Migrazione dell'infrastruttura di autenticazione degli agenti remoti.

D: Quali sono le modifiche immediate dopo la migrazione?

Subito dopo la migrazione, noterai diverse modifiche chiave:

Proprietà del progetto Google Cloud: la proprietà del tuo progetto SOAR verrà trasferita da Google al tuo progetto di proprietà del cliente Google Cloud .
Autenticazione:
- Clienti Unified SecOps: nessuna modifica. L'autenticazione continuerà a essere gestita da Google Cloud IAM.
- Clienti SOAR Standalone: l'autenticazione verrà ora gestita da Google Cloud IAM. Per gli utenti che utilizzano SAML, ciò significa adottare la federazione delle identità per la forza lavoro e la configurazione SAML non verrà più archiviata e gestita all'interno del sistema SOAR stesso, il che comporta controlli di sicurezza più efficaci.
RBAC: le autorizzazioni utente diventeranno più granulari e verranno gestite utilizzando IAM. Gli ambienti e i ruoli SOC continueranno a essere gestiti all'interno del modulo SOAR utilizzando i gruppi del provider di identità (IdP).
Logging di controllo: i log di controllo saranno più dettagliati e verranno gestiti all'interno di **Cloud Audit Logs **.
Nuovo URL (solo SOAR): gli utenti SOAR Standalone riceveranno un nuovo URL (nuovo dominio) per accedere a SOAR.

D: Come vengono informati i clienti / partner di questa migrazione?

Per tutti i clienti e i partner viene visualizzato un popup in-product che include la data della migrazione e un link a un modulo da compilare. Verrà chiesto di confermare la data e la fascia oraria della migrazione.

D: I costi dell'infrastruttura cambieranno in seguito al collegamento di SOAR al nostro Google Cloud progetto?

No, i costi non subiranno modifiche. Non dovresti notare alcuna modifica nel frontend. Nel tuo progetto non verranno eseguite nuove risorse, quindi non ci sono costi associati.

D: Come colleghiamo il nostro progetto a SOAR?

Google eseguirà la migrazione del tuo progetto SOAR al tuo Google Cloud progetto. Se sei un cliente Unified SecOps, abbiamo già l'ID del tuo Google Cloud progetto. Se sei un cliente SOAR Standalone, dovrai condividere con noi l'ID del tuo Google Cloud progetto.

D: Per i clienti che hanno già un deployment Google SecOps, dobbiamo utilizzare lo stesso ID progetto di SIEM o abbiamo bisogno di un progetto separato?

Per un deployment Google SecOps unificato (un SIEM, un SOAR), devi utilizzare l'ID progetto esistente Google Cloud associato al tuo SIEM. In questo modo è possibile gestire in modo unificato i flussi amministrativi, come RBAC e log.

D: Per le istanze Google SecOps con considerazioni speciali come i Controlli di servizio VPC (VPC-SC), quali passaggi sono necessari?

Per abilitare la migrazione, devi definire regole sia in entrata sia in uscita all'interno della policy VPC-SC. Se il tuo Google Cloud progetto ha VPC-SC, contatta il team di assistenza per indicazioni dettagliate su queste regole specifiche.

Esistono due funzionalità API non supportate tramite VPC-SC:

Webhook
Link di approvazione del playbook

D: Come faccio a verificare che la migrazione sia andata a buon fine?

Per verificare il completamento, vai a Impostazioni SOAR > Gestione licenze. Dopo la fase 1, dopo il numero di versione del sistema verrà visualizzato Google.com. Dopo la migrazione della fase 2 delle autorizzazioni SOAR ai ruoli IAM , dopo il numero di versione del sistema verranno visualizzati sia Google.com sia CloudIAM Enabled.

Tempi di inattività e continuità

D: Si verificano tempi di inattività durante la migrazione e qual è il loro impatto?

Sì. I tempi di inattività previsti sono i seguenti:

Fino a 2 ore per i clienti SOAR Standalone.
Fino a 1,5 ore per i clienti Google SecOps.

Durante questo periodo, non potrai accedere alla piattaforma. I servizi SOAR (inclusi importazione, playbook, job) verranno messi in pausa, ma i servizi SIEM continueranno a essere eseguiti in background.

D: I dati generati durante il tempo di inattività verranno importati automaticamente una volta ripresi i servizi SOAR?

Sì. Una volta che il sistema sarà di nuovo online, l'importazione e i playbook riprenderanno e verranno elaborati tutti gli avvisi generati o importati durante il tempo di inattività.

D: Cosa succede ai playbook in esecuzione quando inizia il tempo di inattività?

Il servizio playbook verrà disattivato prima dell'inizio della migrazione. Alcuni playbook in esecuzione potrebbero non riuscire e dovranno essere riavviati manualmente o riprenderanno dopo il completamento della migrazione.

D: Esiste un piano di rollback o di emergenza se si verifica un problema durante la migrazione?

Sì. La procedura di migrazione mantiene intatta l'istanza SOAR esistente (anche se disattivata). Se la procedura di migrazione non viene completata correttamente, possiamo tornare all'istanza esistente e rimuovere quella nuova. Questa procedura di rollback richiede fino a 30 minuti. Eseguiremo test approfonditi e un monitoraggio costante, con personale di reperibilità in standby per garantire una migrazione riuscita.

Se riscontri problemi di accesso dopo la migrazione, è probabile che la configurazione dell'autenticazione non sia corretta. Dovrai coordinarti con il tuo team di identità, IdP o Google Cloud amministratore per utilizzare la guida alla risoluzione dei problemi per l'identificazione e la risoluzione. Se il problema persiste o non è correlato all'accesso, apri una richiesta di assistenza per documentare il problema e monitorarne la risoluzione.

D: Quando posso eseguire la migrazione ai nuovi endpoint SOAR v1 nell'API Chronicle?

Puoi eseguire la migrazione ai nuovi endpoint SOAR v1 nell'API Chronicle da metà gennaio 2026.

L'API SOAR legacy e le chiavi API verranno ritirate e non funzioneranno più dopo il 30 novembre 2026. Per garantire una transizione senza problemi, segui questi due passaggi obbligatori:

Devi prima completare la migrazione dei gruppi di autorizzazioni SOAR a Cloud IAM.
Aggiorna gli script e le integrazioni esistenti per sostituire gli endpoint API SOAR legacy con gli endpoint API Chronicle corrispondenti.

Autenticazione e autorizzazioni

D: Come faccio a eseguire la migrazione dei miei gruppi di autorizzazioni e delle mie autorizzazioni SOAR?

Utilizzerai uno script di migrazione nella tua Google Cloud console per eseguire la migrazione dei gruppi di autorizzazioni esistenti ai ruoli personalizzati IAM. Lo script assegna anche ruoli personalizzati agli utenti (per i clienti Cloud Identity) o ai gruppi IdP (per i clienti della federazione delle identità per la forza lavoro).

D: Cosa succede se preferisco non eseguire la migrazione dei gruppi di autorizzazioni personalizzati e utilizzare solo i ruoli predefiniti?

Puoi disattivare la migrazione automatica ed eseguire manualmente il mapping dei gruppi IdP ai ruoli Cloud IAM.

D: Siamo un cliente SOAR Standalone con un provider SAML personalizzato con autenticazione manuale. Se lo modifichiamo in gruppi IdP per il mapping IdP, qual è l'impatto sugli account utente esistenti?

Supponendo che gli utenti esistenti corrispondano a uno dei gruppi e che le autorizzazioni siano mappate correttamente, non dovrebbero esserci conseguenze sugli account utente preesistenti. Tuttavia, se gli utenti non sono mappati ai gruppi, non potranno accedere. Se le autorizzazioni sono mappate in modo diverso, gli utenti riceveranno nuove autorizzazioni in base al nuovo mapping.

D: Esistono prerequisiti specifici per gli MSSP che utilizzano più provider di identità?

I clienti che hanno configurato più provider di identità nella pagina di autenticazione esterna SOAR devono definire la federazione delle identità per la forza lavoro per l' autenticazione e creare un pool di forza lavoro separato per ogni provider. Ogni provider è associato a un sottodominio diverso. Per ulteriori informazioni, consulta la guida alla migrazione per gli MSSP.

D: Come faccio ad autenticarmi all'API Chronicle?

Segui le istruzioni riportate in Autenticazione all'API Chronicle.

D: Quali sono i nuovi IP necessari per accedere alla nuova API SOAR? Non è necessario inserire nella lista consentita alcun indirizzo IP per accedere all'API Chronicle. Facoltativamente, puoi inserire nella lista consentita l'intervallo di indirizzi IP indicato qui e qui.

Logging e monitoraggio

D: Abbiamo completato la prima fase della migrazione, ma non vediamo i log in Cloud Audit Logs.

I log vengono archiviati nella piattaforma SOAR al termine della prima fase di migrazione. I log diventano disponibili nel tuo Google Cloud progetto al termine della seconda fase di migrazione.

D: I clienti che inviano dati SOAR a un'istanza BigQuery (BQ) gestita potranno comunque accedere a questi dati BigQuery dopo la migrazione?

Sì. L'istanza BigQuery gestita esistente continuerà a funzionare.

Logistica e assistenza

D: Posso scegliere una fascia oraria diversa per la migrazione?

No. Non è possibile eseguire la migrazione al di fuori delle fasce orarie suggerite.

D: Riceveremo aggiornamenti di stato in tempo reale durante la migrazione?

Riceverai una notifica via email all'inizio e alla fine della procedura di migrazione.

D: Chi dobbiamo contattare in caso di problemi dopo la migrazione?

Eseguire la migrazione dei gruppi di autorizzazioni SOAR a IAM

La sezione seguente illustra i problemi comuni riscontrati durante e dopo la migrazione delle autorizzazioni a IAM.

Problemi relativi allo strumento e allo script di migrazione

D: Perché non riesco a vedere o caricare lo script di migrazione nella Google Cloud Console?

Esistono due possibili motivi:

Autorizzazioni mancanti: lo strumento di migrazione richiede che il tuo account utente disponga di autorizzazioni sufficienti sia in Google Cloud sia nell'istanza Google SecOps. Assicurati di aver eseguito l'accesso con un account che disponga dei ruoli IAM richiesti in Google Cloud e che sia anche un utente riconosciuto in Google SecOps SOAR. L'utilizzo di account diversi per Google Cloud e SOAR può causare errori di autorizzazione. Se disponi delle autorizzazioni richieste e non riesci comunque a caricare lo script di migrazione, apri una richiesta di assistenza.
SIEM non utilizza Cloud IAM: se sei un cliente Google SecOps Unified, assicurati di utilizzare IAM per gestire ruoli e autorizzazioni per la parte SIEM della piattaforma. Per ulteriori informazioni, consulta la guida alla migrazione da RBAC legacy a RBAC per funzionalità.

D: Ricevo un errore quando tento di eseguire gli script di migrazione. Che cosa devo fare?

Errore: "Il gruppo non esiste": quando utilizzi add-iam-policy-binding commands, assicurati di utilizzare l'indirizzo email di gruppo completo (ad esempio, your-group@example.com) per il flag --member, non solo il nome breve del gruppo.
Errori relativi ai ruoli preesistenti: possono verificarsi conflitti durante l'associazione a un'entità che ha già associazioni condizionali. Per risolvere il problema, esegui di nuovo lo script e assicurati di selezionare Nessuno anziché Specifica una nuova condizione.

Problemi di accesso dopo la migrazione

D: Perché ricevo un errore "403 Forbidden" quando tento di accedere a determinate pagine o funzionalità (come Playbook o IDE) dopo la migrazione IAM?

Un errore 403 dopo la migrazione potrebbe indicare che il Google Cloud ruolo IAM assegnato al tuo utente non dispone delle autorizzazioni richieste dalla parte SOAR della piattaforma Google SecOps. Questo è comune se utilizzi ruoli IAM personalizzati.

Controlla i ruoli e le autorizzazioni di Google SecOps. Assicurati che il tuo ruolo IAM personalizzato includa tutte le autorizzazioni necessarie per accedere alle funzionalità SOAR richieste.

Facoltativamente, esamina gli strumenti per sviluppatori del browser per identificare le chiamate API specifiche che restituiscono un errore 403. Il payload della risposta documenta l'autorizzazione mancante e nell'interfaccia viene visualizzato anche un banner di notifica che descrive l'accesso richiesto.

Se nessuna di queste soluzioni ti aiuta, apri una richiesta di assistenza.

Autorizzazioni e ruoli

D: Ho eseguito la migrazione IAM manualmente senza utilizzare lo strumento fornito e ora ho problemi di autorizzazione. Come posso risolvere il problema?

La migrazione IAM manuale a volte può comportare la mancanza delle autorizzazioni necessarie per i ruoli SOAR. Ti consigliamo vivamente di utilizzare lo script di migrazione fornito per assicurarti che tutte le autorizzazioni richieste siano configurate correttamente. Se prevedi comunque di eseguire la migrazione manuale, esamina attentamente le autorizzazioni IAM di Google SecOps per creare i ruoli personalizzati con le autorizzazioni necessarie.

D: Alcuni utenti sembrano avere più autorizzazioni in SOAR del previsto dopo la migrazione. Perché succede?

Questo può accadere se agli utenti o ai gruppi sono già stati assegnati ruoli ampi Google Cloud predefiniti di Chronicle prima della migrazione. Al termine della migrazione, i ruoli predefiniti di Chronicle (ad esempio chronicle.apiAdmin) includeranno automaticamente le autorizzazioni SOAR. Ad esempio, il ruolo Chronicle API Admin includerà ora le autorizzazioni di SOAR Admin.

Per garantire l'accesso con privilegio minimo, segui questi passaggi:

Esamina i ruoli predefiniti nella pagina Ruoli IAM, incluso Chronicle API Admin, per identificare tutte le entità assegnate (utenti e gruppi).
Verifica che a questi ruoli siano assegnati solo gli utenti che richiedono le autorizzazioni SOAR.
Per limitare l'accesso SOAR a entità specifiche, rimuovile dai ruoli predefiniti e assegnale a un ruolo personalizzato che escluda esplicitamente le autorizzazioni di amministratore SOAR.

D: La migrazione è andata a buon fine, ma nella pagina Mapping gruppi vedo ancora la colonna Gruppi di autorizzazioni. Perché?

Dopo una migrazione riuscita, la colonna Gruppi di autorizzazioni viene comunque visualizzata nella pagina Mapping gruppi per la compatibilità con le versioni precedenti. Non eliminare queste assegnazioni. La colonna verrà rimossa entro il 30 novembre 2026 senza alcun impatto sui clienti.

Best practice

Utilizza lo script di migrazione: quando possibile, utilizza lo script di migrazione ufficiale in Google Cloud per gestire la transizione dai gruppi di autorizzazioni SOAR ai ruoli IAM.
Esamina le autorizzazioni IAM: familiarizza con le autorizzazioni IAM richieste per le diverse funzioni e i diversi ruoli SOAR. Google Cloud
Esegui test approfonditi: dopo la migrazione, testa l'accesso per diversi ruoli utente e persona per assicurarti che tutto funzioni come previsto.
Contatta l'assistenza: in caso di errori persistenti o comportamenti imprevisti, contatta l'assistenza e fornisci il maggior numero di dettagli possibile.

Hai bisogno di ulteriore assistenza? Ricevi risposte dai membri della community e dai professionisti di Google SecOps.