Domande frequenti sulla migrazione a SOAR

Supportata in:

Ricevi risposte alle domande più comuni sul processo di migrazione a SOAR. Trova soluzioni ai problemi più comuni e best practice per una transizione di successo.

Ambito e impatto della migrazione

D: Perché questa migrazione è necessaria?

Stiamo modernizzando l'infrastruttura SOAR eseguendo la migrazione a Google Cloud. Questo upgrade critico offre vantaggi chiave, tra cui una maggiore affidabilità, una maggiore sicurezza, una 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 offre quanto segue:

  • Migliora l'affidabilità e le funzionalità di monitoraggio di SOAR utilizzando il livello API di Google, il migliore della categoria. Questo livello fornisce una soluzione API leader con funzionalità avanzate per la gestione delle quote, l'auditing e l'osservabilità.
  • Sblocca il controllo degli accessi basato su 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 coinvolge i seguenti componenti:

  • Migrazione del progetto SOAR a un progetto Google Cloud di proprietà del cliente.
  • 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 alcune modifiche importanti:

  • Proprietà del progetto GCP: il tuo progetto SOAR verrà migrato dalla proprietà di Google al tuo progetto Google Cloud di proprietà del cliente.
  • Autenticazione:
    • Clienti di SecOps unificato: nessuna modifica. L'autenticazione continuerà a essere gestita da IAM Google Cloud .
    • Clienti SOAR autonomi: 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 porta a controlli di sicurezza più efficaci.
  • RBAC: le autorizzazioni dell'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 di SOAR autonomo riceveranno un nuovo URL (nuovo dominio) per accedere a SOAR.

D: In che modo i clienti/partner vengono informati di questa migrazione?

A tutti i clienti e partner viene mostrato un popup nel prodotto che include la data della migrazione e un link a un modulo da compilare. Gli verrà chiesto di confermare la data e l'intervallo di tempo della migrazione.

D: I nostri costi di infrastruttura cambieranno in seguito all'associazione di SOAR al nostro progetto Google Cloud ?

No, i costi non subiranno variazioni. Non dovresti notare alcuna modifica sul 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 di Unified SecOps, abbiamo già l'ID progetto Google Cloud . Se sei un cliente SOAR autonomo, dovrai condividere con noi l'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. In questo modo è possibile gestire in modo unificato i flussi amministrativi, come RBAC e i log.

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

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

Esistono due funzionalità dell'API che non sono supportate utilizzando i Controlli di servizio VPC:

  • Webhook
  • Link di approvazione del playbook

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

Verifica che l'operazione sia stata completata correttamente andando su Impostazioni SOAR > Gestione delle licenze. Dopo la Fase 1, verrà visualizzato Google.com dopo il numero di versione del sistema. 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.

Tempo di inattività e continuità

D: È previsto un tempo di inattività durante la migrazione e qual è il suo impatto?

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

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

Durante questo periodo, non potrai accedere alla piattaforma. I servizi SOAR (tra cui 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 è di nuovo online, l'importazione e i playbook riprenderanno ed elaboreranno 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 al termine della migrazione.

D: Esiste un piano di rollback o di emergenza se qualcosa va storto durante la migrazione?

Sì. Il processo di migrazione mantiene l'istanza SOAR esistente completamente intatta (anche se disattivata). Se il processo di migrazione non viene completato correttamente, possiamo tornare all'istanza esistente e rimuovere quella nuova. Questo processo di rollback richiede fino a 30 minuti. Eseguiremo test approfonditi e un monitoraggio attento, con personale di guardia in standby per garantire una migrazione di successo.

Se riscontri problemi di accesso dopo la migrazione, è probabile che la configurazione dell'autenticazione non sia corretta. Dovrai coordinarti con l'amministratore di Identity, IDP o Google Cloud per utilizzare la guida alla risoluzione dei problemi per l'identificazione e la risoluzione. 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 e le chiavi API legacy verranno ritirate e non funzioneranno più dopo il 31 marzo 2027. Per garantire una transizione senza problemi, segui questi due passaggi obbligatori:

  1. Devi prima completare la migrazione dei gruppi di autorizzazioni SOAR a Cloud IAM.
  2. 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 gruppi di autorizzazioni e delle autorizzazioni SOAR?

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

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 passiamo ai gruppi IdP per la mappatura IdP, qual è l'impatto sugli account utente esistenti?

Supponendo che i tuoi utenti esistenti corrispondano a uno dei gruppi e che le autorizzazioni siano mappate correttamente, non dovrebbe esserci alcun impatto 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 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 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 MSSP.

D: Come faccio ad autenticarmi all'API Chronicle?

Segui le istruzioni riportate in Autenticati 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 indicati 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 della migrazione. I log diventano disponibili nel tuo progetto Google Cloud al termine della seconda fase della migrazione.

D: I clienti che inviano dati SOAR a un'istanza Managed BigQuery (BQ) potranno ancora 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. 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 sia all'inizio che alla fine del processo di migrazione.

D: Chi dobbiamo contattare se si verifica un problema dopo la migrazione?

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

Esegui 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 visualizzare o caricare lo script di migrazione nella console Google Cloud ?

I motivi possibili sono due:

  • Autorizzazioni mancanti: lo strumento di migrazione richiede che il tuo account utente disponga di autorizzazioni sufficienti sia nell'istanza 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 un ticket di assistenza.

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

D Ricevo 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: potrebbero verificarsi conflitti durante l'associazione a un'entità che ha già associazioni condizionali. Per risolvere il problema, esegui nuovamente lo script e assicurati di selezionare Nessuna anziché Specifica una nuova condizione.

Problemi di accesso dopo la migrazione

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

Un errore 403 dopo la migrazione potrebbe indicare che al ruolo IAM Google Cloud assegnato al tuo utente mancano le autorizzazioni richieste dal lato SOAR della piattaforma Google SecOps. Questo accade spesso 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 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: Alcuni utenti sembrano avere più autorizzazioni in SOAR del previsto dopo la migrazione. Perché?

Questo può accadere se agli utenti o ai gruppi erano già stati assegnati ruoli Google Cloud Chronicle ampi 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 amministrative di SOAR.

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

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

D: La migrazione è andata a buon fine, ma vedo ancora 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 31 marzo 2027 senza alcun impatto sui clienti.

Best practice

  • Utilizza lo script di migrazione: se 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 le diverse funzioni e i diversi ruoli SOAR.
  • Esegui test approfonditi: dopo la migrazione, testa l'accesso per diversi ruoli utente e personas per assicurarti che tutto funzioni come previsto.
  • Contatta l'assistenza: per eventuali errori persistenti o comportamenti imprevisti, contatta l'assistenza e fornisci quanti più dettagli possibili.

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