Domande frequenti sulla migrazione di SOAR
Leggi le risposte alle domande frequenti relative alla procedura di migrazione di SOAR. Trova soluzioni ai problemi frequenti e scopri le best practice per una transizione senza intoppi.
Ambito e impatto della migrazione
D: Perché è necessaria questa migrazione?
Stiamo modernizzando l'infrastruttura SOAR eseguendo la migrazione a Google Cloud. Questo upgrade fondamentale 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 i seguenti vantaggi:
- 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 su 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 degli agenti remoti.
- Migrazione degli audit log SOAR.
D: Quali sono le modifiche immediate dopo la migrazione?
Subito dopo la migrazione, noterai diverse modifiche chiave:
- Proprietà del progetto GCP: il tuo progetto SOAR verrà migrato dalla proprietà di Google al tuo progetto di proprietà del cliente Google Cloud .
- Autenticazione:
- Clienti di SecOps unificati: 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ù 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 log: gli audit log 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 nel prodotto che include la data di migrazione e un link a un modulo da compilare. Verrà chiesto di confermare la data e la fascia oraria di migrazione.
D: I costi dell'infrastruttura cambieranno in seguito al collegamento di SOAR al nostro Google Cloud progetto?
No, i costi non subiranno variazioni. 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 di SecOps unificati, abbiamo già l'ID del tuo progetto. Google Cloud 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 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 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 di Google SecOps con considerazioni speciali come i Controlli di servizio VPC, quali passaggi sono necessari?
Per abilitare la migrazione, devi definire regole sia in entrata sia in uscita all'interno della policy dei Controlli di servizio VPC. Se il tuo Google Cloud progetto ha i Controlli di servizio VPC, contatta il team di assistenza per indicazioni dettagliate su queste regole specifiche.
Tempi di inattività e continuità
D: Si verifica un tempo 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 ingestion, playbook e 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 inseriti automaticamente una volta ripresi i servizi SOAR?
Sì. Una volta che il sistema sarà di nuovo online, l'inserimento e i playbook riprenderanno ed elaboreranno tutti gli avvisi generati o inseriti durante il tempo di inattività.
D: Che 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 in caso di problemi 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 la riuscita della migrazione.
Se riscontri problemi di accesso dopo la migrazione, è probabile che la configurazione dell'autenticazione non sia corretta. Dovrai coordinarti con il tuo provider di identità 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 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 intoppi, 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 di Cloud Identity) o ai gruppi IdP (per i clienti di 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 di 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 saperne di più, 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 sullo 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?
Se riscontri problemi di accesso dopo la migrazione, è probabile che la configurazione dell'autenticazione non sia corretta. Dovrai coordinarti con il tuo provider di identità 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.
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 unificato di Google SecOps, assicurati di utilizzare IAM per gestire ruoli e autorizzazioni per la parte SIEM della piattaforma. Per saperne di più, 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 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 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 è utile, 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 predefiniti di Chronicle prima della migrazione. Google Cloud
Al termine della migrazione, i ruoli predefiniti di Chronicle (ad esempio chronicle.apiAdmin) includeranno automaticamente le autorizzazioni SOAR. Ad esempio, il ruolo Amministratore API Chronicle includerà ora le autorizzazioni di amministratore SOAR.
Per garantire l'accesso con privilegi minimi, segui questi passaggi:
- Esamina i ruoli predefiniti nella pagina Ruoli IAM, incluso Amministratore API Chronicle, 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 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 nella pagina Mapping gruppi vedo ancora la colonna Gruppi di autorizzazioni. Perché?
Dopo una migrazione riuscita, la colonna Gruppi di autorizzazioni viene ancora visualizzata nella pagina Mapping 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: 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 personaggi 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.