Domande frequenti sulla migrazione di SOAR
Trova le 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, offre 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 dell'accesso 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
- 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 migrazione del progetto SOAR verrà eseguita dalla proprietà di Google al 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 ora sarà 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 autonomi di SOAR 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 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 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 Google Cloud esistente associato al tuo SIEM. Ciò consente la gestione unificata dei flussi amministrativi, come il controllo dell'accesso basato sui ruoli e i log.
D: Per le istanze di Google SecOps con considerazioni speciali come i Controlli di servizio VPC, quali passaggi sono necessari?
Per attivare la migrazione, devi definire le regole in entrata e in uscita all'interno del criterio VPC SC. Per indicazioni dettagliate su queste regole specifiche, contatta il team di assistenza.
Tempi di inattività e continuità
D: Si verifica un downtime 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 e job) verranno sospesi, ma i servizi SIEM continueranno a essere eseguiti in background.
D: I dati generati durante il periodo di inattività verranno inseriti 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 intatta l'istanza SOAR esistente (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à pronto a intervenire per garantire una migrazione riuscita.
D: Quando posso eseguire la migrazione ai nuovi endpoint SOAR nell'API Chronicle?
L'accesso in anteprima ai nuovi endpoint SOAR, che si trovano nella versione beta dell'API Chronicle V1, è disponibile a partire dal 1° novembre 2025. L'accesso generale all'API Chronicle V1 sarà disponibile a partire dal 1° gennaio 2026. Devi completare la migrazione dei gruppi di autorizzazioni SOAR a Cloud IAM prima di eseguire la migrazione dall'API SOAR legacy. Devi aggiornare gli script e le integrazioni per sostituire gli endpoint API SOAR con gli endpoint API Chronicle corrispondenti. Le chiavi API e l'API SOAR legacy funzioneranno fino al 30 giugno 2026.
Autenticazione e autorizzazioni
D: Come faccio a eseguire la migrazione dei miei gruppi di autorizzazioni e delle mie autorizzazioni SOAR?
Stiamo preparando una procedura guidata per la migrazione da utilizzare nella tua console Google Cloud per migrare i 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 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 gruppi IdP per il mapping IdP, quali sono le conseguenze 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 vengono mappate in modo diverso, gli utenti riceveranno nuove autorizzazioni in base alla nuova mappatura.
D: Esistono prerequisiti specifici per i 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 sarà associato a un sottodominio diverso.
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 una fascia oraria diversa per la migrazione?
No. La migrazione al di fuori delle fasce orarie suggerite non è possibile.
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?
Devi creare un ticket di assistenza per registrare il problema e monitorare l'avanzamento.
Hai bisogno di ulteriore assistenza? Ricevi risposte dai membri della community e dai professionisti di Google SecOps.