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 uses AI technology to translate content into your preferred language. AI translations can contain errors.

Domande frequenti sulla migrazione di SOAR

Supportato in:

Google SecOps SOAR

Trova risposte alle domande più comuni sulla procedura di migrazione SOAR. Trova soluzioni a 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à, migliore sicurezza, maggiore conformità e controllo dell'accesso più granulare. Inoltre, fornisce l'accesso alle funzionalità di AI agentica tramite l'integrazione del Model Context Protocol (MCP).

La migrazione fornisce quanto segue:

Migliora l'affidabilità e le funzionalità di monitoraggio di SOAR utilizzando il miglior livello API 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 basato sui 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 coinvolge i seguenti componenti:

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

D: Quali sono i cambiamenti immediati dopo la migrazione?

Subito dopo la migrazione, noterai diverse modifiche importanti:

Proprietà del progetto GCP: la proprietà del tuo progetto SOAR verrà trasferita da Google al tuo progetto Google Cloud di proprietà del cliente.
Autenticazione:
- Clienti Unified SecOps: nessuna modifica. L'autenticazione continuerà a essere gestita da Google Cloud IAM.
- Clienti SOAR Standalone: l'autenticazione ora verrà gestita da Google Cloud IAM. Per gli utenti che utilizzano SAML, ciò significa adottare la federazione delle identità della 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ù rigorosi.
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).
Audit logging: gli audit log saranno più dettagliati e gestiti in **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 nel prodotto che include la data della migrazione e un link a un modulo da compilare. Verrà chiesto di confermare la data e l'ora della migrazione.

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

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 progetto Google Cloud . Se sei un cliente Unified SecOps, abbiamo già il tuo ID progetto Google Cloud . Se sei un cliente autonomo di SOAR, dovrai condividere con noi il tuo ID progetto Google Cloud .

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

Per un deployment unificato di Google SecOps (un SIEM, un SOAR), devi utilizzare l'ID progetto esistente associato al tuo SIEM. Google Cloud Ciò consente la gestione unificata dei flussi amministrativi, come il controllo dell'accesso basato sui ruoli e i log.

D: Quali passaggi sono necessari per le istanze Google SecOps con considerazioni speciali come i Controlli di servizio VPC?

Per attivare la migrazione, devi definire le regole in entrata e 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.

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

Verifica il completamento dell'operazione andando a Impostazioni SOAR > Gestione licenze. Dopo la fase 1, dopo il numero di versione del sistema verrà visualizzato Google.com. Dopo la migrazione di 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 verifica un periodo di inattività durante la migrazione e qual è il suo impatto?

Sì. Il tempo di inattività previsto è il seguente:

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

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

D: I dati generati durante il periodo di inattività verranno acquisiti automaticamente una volta ripristinati i servizi SOAR?

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

D: Cosa succede ai playbook in esecuzione quando inizia il periodo 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 qualcosa va storto durante la migrazione?

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

Se riscontri problemi di accesso dopo la migrazione, è probabile che la configurazione dell'autenticazione non sia corretta. Per utilizzare la guida alla risoluzione dei problemi per l'identificazione e la risoluzione, dovrai coordinarti con l'amministratore di Identity, IDP o Google Cloud . Se il problema persiste o non è correlato all'accesso, apri un ticket 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 a partire da metà gennaio 2026.

L'API SOAR legacy e le chiavi API verranno ritirate e non funzioneranno più dopo il 30 settembre 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 console Google Cloud per migrare i gruppi di autorizzazioni esistenti ai ruoli IAM personalizzati. 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 personalizzate e utilizzare solo i ruoli predefiniti?

Puoi disattivare la migrazione automatica e mappare manualmente i gruppi IdP ai ruoli Cloud IAM.

D: Siamo un cliente SOAR autonomo con un provider SAML personalizzato con autenticazione manuale. Se modifichiamo questa impostazione in modo da utilizzare i gruppi IdP per la mappatura IdP, quali sono le conseguenze per gli 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 vengono mappate in modo diverso, gli utenti riceveranno nuove autorizzazioni in base alla nuova mappatura.

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 fornitore è associato a un sottodominio diverso. Per ulteriori informazioni, leggi la guida alla migrazione MSSP.

D: Come faccio ad autenticarmi all'API Chronicle?

Segui le istruzioni riportate in Autenticazione nell'API Chronicle.

D: Quali sono i nuovi IP necessari per accedere alla nuova API SOAR? Non è necessario inserire indirizzi IP nella lista consentita per accedere all'API Chronicle. Se vuoi, 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 progetto Google Cloud 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ì. Il BigQuery gestito esistente continuerà a funzionare.

Logistica e assistenza

D: Posso scegliere un orario diverso per la migrazione?

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

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

Riceverai una notifica via email all'inizio e alla fine del processo di migrazione.

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

Esegui la migrazione dei gruppi di autorizzazioni SOAR a IAM

La sezione seguente tratta 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 che 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 un ticket 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 basato sulle funzionalità.

D. Si è verificato un errore durante il tentativo 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 completo del gruppo (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 il binding a un principal che ha già binding condizionali. Per risolvere il problema, esegui di nuovo lo script e assicurati di selezionare Nessuna anziché Specifica una nuova condizione.

Problemi di accesso dopo la migrazione

D. Perché ricevo un errore "403 - Vietato" 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 al tuo utente manca il ruolo IAM Google Cloud assegnato, che 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.

Se vuoi, 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 è utile, apri un ticket di assistenza.

Autorizzazioni e ruoli

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

La migrazione manuale di IAM 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: Dopo la migrazione, alcuni utenti sembrano avere più autorizzazioni in SOAR del previsto. Perché?

Ciò può accadere se utenti o gruppi sono già stati assegnati a ruoli Chronicle broad Google Cloud predefiniti prima della migrazione. Dopo aver completato la 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 tutti i principal assegnati (utenti e gruppi).
Verifica che a questi ruoli siano assegnati solo gli utenti che richiedono le autorizzazioni SOAR.
Per limitare l'accesso a SOAR per entità specifiche, rimuovile dai ruoli predefiniti e assegnale a un ruolo personalizzato che escluda esplicitamente le autorizzazioni di amministratore SOAR.

D: La migrazione è riuscita, ma continuo a vedere la colonna Gruppi di autorizzazioni nella pagina Mappatura gruppi. Perché?

Dopo una migrazione riuscita, la colonna Gruppi di autorizzazioni viene ancora visualizzata nella pagina Mappatura gruppi per la compatibilità con le versioni precedenti. Non eliminare queste assegnazioni. La colonna verrà rimossa entro il 30 settembre 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: acquisisci familiarità con le autorizzazioni IAM Google Cloud richieste per diversi ruoli e funzioni SOAR.
Esegui test approfonditi: dopo la migrazione, testa l'accesso per diversi ruoli e buyer persona per assicurarti che tutto funzioni come previsto.
Contatta l'assistenza: per eventuali 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.