Perguntas frequentes sobre a migração do SOAR
Tire dúvidas 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.
Escopo e impacto da migração
P: Por que essa migração é necessária?
Estamos modernizando a infraestrutura de SOAR ao migrar para o Google Cloud. Esse upgrade essencial oferece benefícios importantes, incluindo maior confiabilidade, segurança aprimorada, conformidade mais abrangente e controle de acesso mais granular. Ele também dá acesso a recursos de IA agêntica por meio da integração do Protocolo de Contexto de Modelo (MCP).
A migração oferece o seguinte:
- Melhora a confiabilidade e os recursos de monitoramento da SOAR usando a melhor camada de API do Google. Essa camada oferece uma solução de API líder com recursos avançados para gerenciamento de cotas, auditoria e capacidade de observação.
- Desbloqueia o controle de acesso baseado em papéis (RBAC) para recursos e dados em toda a plataforma.
- Oferece maior funcionalidade de compliance, como VPC Service Controls, residência de dados e chaves de criptografia gerenciadas pelo cliente (CMEK).
P: Qual é o escopo da migração?
A migração envolve os seguintes componentes:
- Migração do projeto SOAR para um projeto Google Cloud de propriedade do cliente.
- Migrar a autenticação e as permissões do SOAR para o Google Cloud IAM.
- Migração de APIs SOAR para a API Chronicle.
- Migração de agentes remotos.
- Migração dos registros de auditoria do SOAR.
P: Quais são as mudanças imediatas após a migração?
Logo após a migração, você vai notar várias mudanças importantes:
- Propriedade do projeto do GCP: seu projeto do SOAR será migrado da propriedade do Google para o projeto Google Cloud de propriedade do cliente.
- Autenticação:
- Clientes do Unified SecOps: nenhuma mudança. A autenticação vai continuar sendo gerenciada pelo IAM Google Cloud .
- Clientes autônomos do SOAR: a autenticação agora será gerenciada pelo Google Cloud IAM. Para usuários que usam SAML, isso significa adotar a federação de identidade de colaboradores. A configuração do SAML não será mais armazenada e gerenciada no próprio sistema SOAR, o que vai resultar em controles de segurança mais fortes.
- RBAC: as permissões de usuário vão se tornar mais granulares e gerenciadas usando o IAM. Os ambientes e as funções de SOC vão continuar sendo gerenciados no módulo SOAR usando grupos de provedor de identidade (IdP).
- Registro de auditoria: os registros de auditoria serão mais detalhados e gerenciados nos **Registros de auditoria do Cloud **.
- Novo URL (somente SOAR): os usuários independentes do SOAR vão receber um novo URL (novo domínio) para acessar o SOAR.
P: Como os clientes / parceiros estão sendo notificados sobre essa migração?
Um pop-up no produto é exibido para todos os clientes e parceiros, incluindo a data de migração e um link para um formulário. Eles vão precisar confirmar a data e o horário da migração.
P: Os custos de infraestrutura vão mudar como resultado da vinculação do SOAR ao nosso projeto Google Cloud ?
Não, seus custos não serão afetados. Você não vai notar nenhuma mudança no front-end. Nenhum novo recurso será executado no seu projeto, então não haverá custos associados.
P: Como conectamos nosso projeto ao SOAR?
O Google vai migrar seu projeto de SOAR para o projeto Google Cloud . Se você for um cliente do Unified SecOps, já temos seu ID do projeto Google Cloud . Se você for um cliente independente do SOAR, compartilhe o ID do projeto Google Cloud com a gente.
P: Para clientes que já têm uma implantação do Google SecOps, devemos usar o mesmo ID do projeto que o SIEM ou precisamos de um projeto separado?
Para uma implantação unificada do Google SecOps (um SIEM, um SOAR), use o ID do projeto Google Cloud associado ao SIEM. Isso permite o gerenciamento unificado de fluxos administrativos, como RBAC e registros.
P: Para instâncias do Google SecOps com considerações especiais, como o VPC Service Controls (VPC SC), quais etapas são necessárias?
Para ativar a migração, defina regras de entrada e saída na política do VPC SC. Para orientações detalhadas sobre essas regras específicas, entre em contato com a equipe de suporte.
Tempo de inatividade e continuidade
P: Há algum tempo de inatividade durante a migração? Qual é o impacto disso?
Sim. O tempo de inatividade esperado é o seguinte:
- Até 2 horas para clientes independentes do SOAR.
- Até 1 hora e meia para clientes do Google SecOps.
Durante esse período, não será possível fazer login na plataforma. Os serviços de SOAR (incluindo ingestão, playbooks e jobs) serão pausados, mas os serviços de SIEM vão continuar sendo executados em segundo plano.
P: Os dados gerados durante o tempo de inatividade serão ingeridos automaticamente quando os serviços do SOAR forem retomados?
Sim. Quando o sistema voltar a ficar on-line, a ingestão e os playbooks serão retomados e processarão todos os alertas gerados ou ingeridos durante o tempo de inatividade.
P: O que acontece com os manuais que estão em execução quando o período de inatividade começa?
O serviço de playbook será desativado antes do início da migração. Alguns playbooks em execução podem falhar e precisar ser reiniciados manualmente ou serão retomados após a conclusão da migração.
P: Existe um plano de reversão ou contingência se algo der errado durante a migração?
Sim. O processo de migração mantém sua instância do SOAR intacta (embora desativada). Se o processo de migração não for concluído, podemos voltar para a instância atual e remover a nova. Esse processo leva até 30 minutos. Vamos realizar testes extensivos e monitoramento rigoroso, com uma equipe de plantão para garantir uma migração bem-sucedida.
P: Quando posso migrar para os novos endpoints do SOAR na API do Chronicle?
O acesso antecipado aos novos endpoints do SOAR, que estão na versão Beta da API V1 do Chronicle, estará disponível a partir de 1º de novembro de 2025. O acesso geral à API V1 do Chronicle estará disponível a partir de 1º de janeiro de 2026. É necessário concluir a migração dos grupos de permissões do SOAR para o Cloud IAM antes de migrar da API SOAR legada. É necessário atualizar seus scripts e integrações para substituir os endpoints da API SOAR pelos endpoints correspondentes da API Chronicle. A API SOAR legada e as chaves de API vão funcionar até 30 de junho de 2026.
Autenticação e permissões
P: Como migro meus grupos e permissões do SOAR?
Estamos preparando um assistente de migração para usar no console do Google Cloud e migrar os grupos de permissões atuais para papéis personalizados do IAM. O script também atribui funções personalizadas a usuários (para clientes do Cloud Identity) ou a grupos do IdP (para clientes da federação de identidade de colaboradores).
P: E se eu preferir não migrar grupos de permissões personalizadas e usar apenas funções predefinidas?
É possível recusar a migração automatizada e mapear manualmente os grupos do IdP para papéis do Cloud IAM.
P: Somos um cliente independente do SOAR com um provedor SAML personalizado e autenticação manual. Se mudarmos para grupos de IdP no mapeamento de IdP, qual será o impacto nas contas de usuário atuais?
Supondo que seus usuários atuais correspondam a um dos grupos e que as permissões estejam mapeadas corretamente, não haverá impacto nas contas de usuário preexistentes. No entanto, se os usuários não estiverem mapeados para grupos, eles não poderão fazer login. Se as permissões forem mapeadas de maneira diferente, os usuários vão receber novas permissões com base no novo mapeamento.
P: Há pré-requisitos específicos para MSSPs que usam vários provedores de identidade?
Os clientes que configuraram vários provedores de identidade na página de autenticação externa do SOAR precisam definir a federação de identidade de colaboradores para autenticação e criar um pool de colaboradores separado para cada provedor. Cada provedor será associado a um subdomínio diferente.
Geração de registros e monitoramento
P: Concluímos a primeira etapa da migração, mas não vemos registros nos registros de auditoria do Cloud.
Os registros são armazenados na plataforma SOAR após a conclusão da primeira etapa da migração. Os registros ficam disponíveis no seu projeto Google Cloud após a conclusão da segunda etapa da migração.
P: Os clientes que enviam dados de SOAR para uma instância gerenciada do BigQuery (BQ) ainda poderão acessar esses dados após a migração?
Sim. O BigQuery gerenciado atual vai continuar funcionando.
Logística e suporte
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 status em tempo real durante a migração?
Você vai receber uma notificação por e-mail no início e no fim do processo de migração.
P: Com quem devemos entrar em contato se um problema surgir após a migração?
Crie um tíquete de suporte para registrar o problema e acompanhar o progresso.
Precisa de mais ajuda? Receba respostas de membros da comunidade e profissionais do Google SecOps.