Perguntas frequentes sobre a migração do SOAR
Obtenha respostas a perguntas comuns sobre o processo de migração do SOAR. Encontre soluções para problemas frequentes e práticas recomendadas para uma transição bem-sucedida.
Âmbito e impacto da migração
P: Por que motivo é necessária esta migração?
Estamos a modernizar a infraestrutura SOAR através da migração para Google Cloud. Esta atualização crítica oferece vantagens importantes, incluindo fiabilidade melhorada, segurança melhorada, maior conformidade e controlo de acesso mais detalhado. Também dá acesso a capacidades de IA com agência através da integração do protocolo Model Context Protocol (MCP).
A migração oferece o seguinte:
- Melhora a fiabilidade e as capacidades de monitorização da SOAR através da utilização da camada de API de excelência da Google. Esta camada oferece uma solução de API líder com funcionalidades avançadas para a gestão de quotas, a auditoria e a observabilidade.
- Desbloqueia o controlo de acesso baseado em funções (CABF) para funcionalidades e dados em toda a plataforma.
- Oferece uma funcionalidade de conformidade mais elevada, como VPC Service Controls, residência dos dados e chaves de encriptação geridas pelo cliente (CMEK).
P: Qual é o âmbito da migração?
A migração envolve os seguintes componentes:
- Migrar o projeto SOAR para um projeto do Google Cloud pertencente ao cliente.
- Migrar a autenticação e as autorizações de SOAR para o Google Cloud IAM.
- Migrar APIs SOAR para a API Chronicle.
- Migrar agentes remotos.
- Migração de registos de auditoria de SOAR.
P: Quais são as alterações imediatas após a migração?
Imediatamente após a migração, vai notar várias alterações importantes:
- Propriedade do projeto da GCP: o seu projeto SOAR vai ser migrado da propriedade da Google para o projeto Google Cloud pertencente ao cliente.
- Autenticação:
- Clientes do SecOps unificado: sem alterações. A autenticação vai continuar a ser gerida pelo Google Cloud IAM.
- Clientes autónomos do SOAR: a autenticação vai ser gerida pelo Google Cloud IAM. Para os utilizadores que usam SAML, isto significa adotar a federação de identidades da força de trabalho, e a configuração SAML vai deixar de ser armazenada e gerida no próprio sistema SOAR, o que leva a controlos de segurança mais fortes.
- CABF: as autorizações dos utilizadores vão tornar-se mais detalhadas e vão ser geridas através do IAM. Os ambientes e as funções SOC vão continuar a ser geridos no módulo SOAR através de grupos de fornecedores de identidade (IdP).
- Registo de auditoria: os registos de auditoria vão ser mais detalhados e geridos nos **registos de auditoria do Cloud **.
- Novo URL (apenas SOAR): os utilizadores autónomos do SOAR vão receber um novo URL (novo domínio) para aceder ao SOAR.
P: Como é que os clientes / parceiros estão a ser notificados desta migração?
É apresentado um pop-up no produto a todos os clientes e parceiros, que inclui a data de migração e um link para um formulário a preencher. É pedido ao utilizador que confirme a data e a hora da migração.
P: Os custos da nossa infraestrutura vão mudar como resultado da associação do SOAR ao nosso Google Cloud projeto?
Não, os seus custos não são afetados. Não deve sentir qualquer alteração no frontend. Não são executados novos recursos no seu projeto, pelo que não existem custos associados.
P: Como podemos associar o nosso projeto ao SOAR?
A Google vai migrar o seu projeto SOAR para o projeto Google Cloud . Se for cliente do Unified SecOps, já temos o seu Google Cloud ID do projeto. Se for um cliente autónomo do SOAR, tem de partilhar o seu Google Cloud ID do projeto connosco.
P: Para os clientes que já têm uma implementação do Google SecOps, devemos usar o mesmo ID do projeto que o SIEM ou precisamos de um projeto separado?
Para uma implementação unificada do Google SecOps (um SIEM e um SOAR), deve usar o ID do projeto Google Cloud existente associado ao seu SIEM. Isto permite a gestão unificada de fluxos administrativos, como RBAC e registos.
P: Para instâncias do Google SecOps com considerações especiais, como os VPC Service Controls (VPC SC), que passos são necessários?
Para ativar a migração, tem de definir regras de entrada e saída na sua política de SC da VPC. Para orientações detalhadas sobre estas regras específicas, contacte a equipa de apoio técnico.
Tempo de inatividade e continuidade
P: Existe algum tempo de inatividade durante a migração e qual é o seu impacto?
Sim. O tempo de inatividade previsto é o seguinte:
- Até 2 horas para clientes autónomos do SOAR.
- Até 1,5 horas para clientes do Google SecOps.
Durante este período, não pode iniciar sessão na plataforma. Os serviços SOAR (incluindo carregamento, manuais de procedimentos e tarefas) vão ser pausados, mas os serviços SIEM vão continuar a ser executados em segundo plano.
P: Os dados gerados durante o tempo de inatividade são carregados automaticamente assim que os serviços SOAR forem retomados?
Sim. Quando o sistema voltar a estar online, a ingestão e os playbooks são retomados e processam todos os alertas gerados ou ingeridos durante o tempo de inatividade.
P: O que acontece aos manuais de estratégias que estão em execução quando o período de descanso começa?
O serviço de manuais de vendas é desativado antes do início da migração. Alguns manuais de vendas em execução podem falhar e têm de ser reiniciados manualmente ou são retomados após a conclusão da migração.
P: Existe um plano de reversão ou de contingência se algo correr mal durante a migração?
Sim. O processo de migração mantém a sua instância SOAR existente totalmente intacta (embora desativada). Se o processo de migração não for concluído com êxito, podemos reverter para a instância existente e remover a nova. Este processo de reversão demora até 30 minutos. Vamos realizar testes extensivos e uma monitorização rigorosa, com pessoal de serviço em permanência para garantir uma migração bem-sucedida.
P: Quando posso migrar para os novos pontos finais do SOAR na API Chronicle?
O acesso antecipado aos novos pontos finais SOAR, que estão na versão beta da API Chronicle V1, está disponível a partir de 1 de novembro de 2025. O acesso geral à API Chronicle V1 vai estar disponível a partir de 1 de janeiro de 2026. Tem de concluir a migração dos grupos de autorizações do SOAR para o Cloud IAM antes de migrar da API SOAR antiga. Tem de atualizar os seus scripts e integrações para substituir os pontos finais da API SOAR pelos pontos finais da API Chronicle correspondentes. A API SOAR antiga e as chaves da API vão funcionar até 30 de junho de 2026.
Autenticação e autorizações
P: Como posso migrar as minhas autorizações e grupos de autorizações da SOAR?
Estamos a preparar um assistente de migração para usar na sua Google Cloud consola para migrar grupos de autorizações existentes para funções personalizadas do IAM. O script também atribui funções personalizadas a utilizadores (para clientes do Cloud Identity) ou a grupos do IdP (para clientes da Workforce Identity Federation).
P: E se preferir não migrar grupos de autorizações personalizadas e usar apenas funções predefinidas?
Pode recusar a migração automática e mapear manualmente os grupos do IdP para as funções da IAM do Google Cloud.
P: Somos um cliente autónomo do SOAR com um fornecedor SAML personalizado com autenticação manual. Se alterarmos esta opção para grupos do IdP para o mapeamento do IdP, qual é o impacto nas contas de utilizador existentes?
Partindo do princípio de que os seus utilizadores existentes correspondem a um dos grupos e as autorizações estão mapeadas corretamente, não deve haver qualquer impacto nas suas contas de utilizador pré-existentes. No entanto, se os utilizadores não estiverem mapeados para grupos, não podem iniciar sessão. Se as autorizações forem mapeadas de forma diferente, os utilizadores recebem novas autorizações com base no novo mapeamento.
P: Existem pré-requisitos específicos para os MSSPs que usam vários fornecedores de identidade?
Os clientes que configuraram vários fornecedores de identidade na página de autenticação externa do SOAR devem definir a Workforce Identity Federation para a autenticação e criar um Workforce Pool separado para cada fornecedor. Cada fornecedor é associado a um subdomínio diferente.
Registo e monitorização
P: Concluímos a primeira fase da migração, mas não vemos registos nos registos do Cloud Audit Logs.
Os registos são armazenados na plataforma SOAR após a conclusão da primeira fase de migração. Os registos ficam disponíveis no seu Google Cloud projeto após a conclusão da segunda fase de migração.
P: Os clientes que enviam dados SOAR para uma instância do BigQuery (BQ) gerida vão continuar a poder aceder a estes dados do BigQuery após a migração?
Sim. O BigQuery gerido existente vai continuar a funcionar.
Logística e apoio técnico
P: Posso escolher um horário diferente para a migração?
Não. Não é possível migrar fora dos horários sugeridos.
P: Vamos receber atualizações de estado em tempo real durante a migração?
Vai receber uma notificação por email no início e no fim do processo de migração.
P: Quem devemos contactar se surgir um problema após a migração?
Deve criar um registo de apoio técnico para registar o problema e acompanhar o progresso.
Precisa de mais ajuda? Receba respostas de membros da comunidade e profissionais da Google SecOps.