O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Perguntas frequentes sobre a migração do SOAR

Compatível com:

Google SecOps SOAR

Encontre respostas para 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.

Escopo e impacto da migração

P: Por que essa migração é necessária?

Estamos modernizando a infraestrutura do SOAR ao migrar para o Google Cloud. Esse upgrade essencial oferece benefícios importantes, como maior confiabilidade, segurança aprimorada, maior conformidade e controle de acesso mais granular. Ele também dá acesso aos recursos de IA agêntica por meio da integração com o Protocolo de Contexto de Modelo (MCP).

A migração oferece o seguinte:

Melhora os recursos de confiabilidade e monitoramento do 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 observabilidade.
Desbloqueia o controle de acesso baseado em papéis (RBAC) para recursos e dados em toda a plataforma.
Oferece maior funcionalidade de conformidade, 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 do SOAR para um projeto do Google Cloud de propriedade do cliente.
Migração da autenticação e das permissões do SOAR para o IAM do Google Cloud .
Migração de APIs SOAR para a API Chronicle.
Migração da infraestrutura de autenticação de agentes remotos.

P: Quais são as mudanças imediatas após a migração?

Imediatamente após a migração, você vai notar várias mudanças importantes:

Propriedade do projeto do GCP: seu projeto do SOAR vai migrar da propriedade do Google para o projeto do cliente Google Cloud .
Autenticação:
- Clientes do SecOps unificado: nenhuma mudança. A autenticação ainda será gerenciada pelo Google Cloud IAM.
- Clientes do SOAR independente: a autenticação agora será gerenciada pelo IAM do Google Cloud . Para usuários que usam SAML, isso significa adotar a federação de identidade de colaboradores, e a configuração SAML não será mais armazenada e gerenciada no sistema SOAR, o que leva a controles de segurança mais fortes.
RBAC: as permissões do usuário vão se tornar mais granulares e gerenciadas usando o IAM. Os ambientes e os papéis do SOC vão continuar sendo gerenciados no módulo SOAR usando grupos de provedores de identidade (IdP).
Registros 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 do SOAR independente 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 a ser preenchido. 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 do Google Cloud ?

Não, seus custos não serão afetados. Você não deve notar nenhuma mudança no front-end. Nenhum recurso novo será executado no projeto, então não haverá custos associados.

P: Como conectamos nosso projeto ao SOAR?

O Google vai migrar seu projeto do SOAR para o projeto do Google Cloud . Se você é cliente do Unified SecOps, já temos o ID do projeto do Google Cloud . Se você for um cliente independente do SOAR, compartilhe seu ID do projeto do 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 do SIEM ou precisamos de um projeto separado?

Para uma implantação unificada do Google SecOps (um SIEM, um SOAR), use o ID do projeto do Google Cloud associado ao seu 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, é preciso definir as regras de entrada e saída na política do VPC-SC. Se o projeto do Google Cloud tiver o VPC SC, entre em contato com a equipe de suporte para receber orientações detalhadas sobre essas regras específicas.

Há dois recursos da API que não são compatíveis com o VPC-SC:

Webhooks
Links de aprovação do playbook

P: Como posso verificar se a migração foi bem-sucedida?

Para verificar se a conclusão foi bem-sucedida, acesse Configurações do SOAR > Gerenciamento de licenças. Após a Etapa 1, vai aparecer Google.com depois do número da versão do sistema. Após a Fase 2 da migração das permissões do SOAR para os papéis do IAM , vai aparecer Google.com e CloudIAM Enabled após o número da versão do sistema.

Inatividade e continuidade

P: Há algum tempo de inatividade durante a migração e qual é o impacto dele?

Sim. A inatividade esperada é a seguinte:

Até 2 horas para clientes independentes do SOAR.
Até 1,5 hora 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 em execução em segundo plano.

P: Os dados gerados durante o período de inatividade serão ingeridos automaticamente quando os serviços do SOAR forem retomados?

Sim. Quando o sistema estiver on-line novamente, a ingestão e os playbooks serão retomados e vão processar todos os alertas gerados ou ingeridos durante a inatividade.

P: O que acontece com os playbooks 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ão ser reiniciados manualmente ou serão retomados após a conclusão da migração.

P: Há um plano de reversão ou contingência se algo der errado durante a migração?

Sim. O processo de migração mantém a instância atual do SOAR totalmente 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 de reversão leva até 30 minutos. Vamos realizar testes extensivos e monitoramento rigoroso, com equipe de plantão para garantir uma migração bem-sucedida.

Se você tiver problemas de acesso após a migração, é provável que a configuração de autenticação esteja incorreta. Você precisará coordenar com o administrador de identidade, IDP ou Google Cloud para usar o guia de solução de problemas para identificação e resolução. Se o problema persistir ou não estiver relacionado ao acesso, abra um tíquete de suporte para documentar o problema e monitorar a resolução.

P: Quando posso migrar para os novos endpoints SOAR v1 na API Chronicle?

Você pode migrar para os novos endpoints v1 do SOAR na API Chronicle a partir de meados de janeiro de 2026.

A API SOAR legada e as chaves de API serão descontinuadas e deixarão de funcionar após 31 de março de 2027. Para garantir uma transição tranquila, siga estas duas etapas obrigatórias:

Primeiro, conclua a migração dos grupos de permissões do SOAR para o Cloud IAM.
Atualize seus scripts e integrações para substituir os endpoints de API legados da API SOAR pelos endpoints de API correspondentes da API Chronicle.

Autenticação e permissões

P: Como faço para migrar meus grupos de permissões e permissões do SOAR?

Você vai usar um script de migração no console do Google Cloud para migrar os grupos de permissões atuais para papéis personalizados do IAM. O script também atribui funções personalizadas aos usuários (para clientes do Cloud Identity) ou aos grupos de IdP (para clientes da federação de identidade de colaboradores).

P: E se eu preferir não migrar os grupos de permissões personalizados e usar apenas os papéis predefinidos?

É possível desativar 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 com autenticação manual. Se mudarmos isso para grupos do IdP para mapeamento do IdP, qual será o impacto nas contas de usuário atuais?

Se os usuários atuais corresponderem a um dos grupos e as permissões forem mapeadas corretamente, não haverá impacto nas contas de usuário preexistentes. No entanto, se os usuários não forem mapeados para grupos, eles não poderão fazer login. Se as permissões forem mapeadas de forma 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 está associado a um subdomínio diferente. Para mais informações, leia o guia de migração do MSSP.

P: Como faço para me autenticar na API Chronicle?

Siga as instruções em Autenticar na API Chronicle.

P: Quais são os novos IPs necessários para acessar a nova API SOAR?

Não é necessário permitir que qualquer endereço IP acesse a API Chronicle. Se quiser, você pode colocar na lista de permissões o intervalo de endereços IP indicado aqui e aqui.

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 projeto do Google Cloud após a conclusão da segunda etapa da migração.

P: Os clientes que enviam dados do 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 houver um problema após a migração?

Migrar grupos de permissões do SOAR para o IAM

A seção a seguir aborda problemas comuns encontrados durante e após a migração de permissões para o IAM.

Problemas com a ferramenta e o script de migração

P: Por que não consigo ver ou carregar o script de migração no console do Google Cloud ?

Há dois motivos possíveis para isso:

Permissões ausentes: a ferramenta de migração exige que sua conta de usuário tenha permissões suficientes na instância do Google Cloud e do Google SecOps. Verifique se você fez login com uma conta que tenha os papéis do IAM necessários em Google Cloud e que também seja um usuário reconhecido no Google SecOps SOAR. O uso de contas diferentes para o Google Cloud e o SOAR pode causar falhas de autorização. Se você tiver as permissões necessárias e ainda não conseguir carregar o script de migração, abra um tíquete de suporte.
O SIEM não usa o Cloud IAM: se você é um cliente unificado do Google SecOps, use o IAM para gerenciar papéis e permissões no lado do SIEM da plataforma. Para mais informações, consulte o guia de migração do RBAC legado para o RBAC de recursos.

P: Estou recebendo um erro ao tentar executar os scripts de migração. O que devo fazer?

Erro "O grupo não existe": ao usar o add-iam-policy-binding commands, verifique se você está usando o endereço de e-mail completo do grupo (por exemplo, your-group@example.com) para a flag --member, não apenas o nome curto do grupo.
Erros relacionados a papéis preexistentes: podem ocorrer conflitos ao vincular a um principal que já tem vinculações condicionais. Para resolver esse problema, execute o script novamente e selecione Nenhum em vez de Especificar uma nova condição.

Problemas de acesso após a migração

P: Por que recebo um erro "403 Forbidden" ao tentar acessar determinadas páginas ou recursos (como Playbooks ou IDE) após a migração do IAM?

Um erro 403 após a migração pode indicar que o papel do IAM Google Cloud atribuído ao usuário não tem as permissões exigidas pelo SOAR da plataforma Google SecOps. Isso é comum se você estiver usando papéis personalizados do IAM.

Verifique os papéis e as permissões do Google SecOps. Verifique se o papel personalizado do IAM inclui todas as permissões necessárias para acessar os recursos do SOAR.

Se quiser, use as ferramentas para desenvolvedores do navegador para identificar chamadas de API específicas que retornam um erro 403. O payload de resposta documenta a permissão ausente, e um banner de notificação também aparece na interface detalhando o acesso necessário.

Se nenhuma dessas soluções ajudar, abra um tíquete de suporte.

Permissões e papéis

P: Fiz a migração do IAM manualmente sem usar a ferramenta fornecida e agora estou com problemas de permissão. Como posso resolver isso?

A migração manual do IAM às vezes pode resultar na falta de permissões necessárias para os papéis do SOAR. Recomendamos usar o script de migração fornecido para garantir que todas as permissões necessárias sejam configuradas corretamente. Se você ainda planeja realizar a migração manual, revise cuidadosamente as permissões do IAM do Google SecOps para criar os papéis personalizados com as permissões necessárias.

P: Alguns usuários parecem ter mais permissões no SOAR do que o esperado após a migração. Por que isso está acontecendo?

Isso pode acontecer se usuários ou grupos já tiverem sido atribuídos a papéis amplos predefinidos do Chronicle Google Cloud antes da migração. Depois de concluir a migração, os papéis predefinidos do Chronicle (como chronicle.apiAdmin) vão incluir automaticamente permissões do SOAR. Por exemplo, o papel de administrador da API do Chronicle vai incluir permissões de admin do SOAR.

Para garantir o acesso com privilégio mínimo, siga estas etapas:

Revise os papéis predefinidos na página Papéis do IAM, incluindo o administrador da API do Chronicle, para identificar todos os principais atribuídos (usuários e grupos).
Confirme se apenas os usuários que precisam de permissões de SOAR estão atribuídos a esses papéis.
Para limitar o acesso ao SOAR para principais específicos, remova-os dos papéis predefinidos e atribua-os a um papel personalizado que exclua explicitamente as permissões de administrador do SOAR.

P: A migração foi concluída, mas ainda vejo a coluna "Grupos de permissões" na página "Mapeamento de grupos". Por quê?

Após uma migração bem-sucedida, a coluna Grupos de permissões ainda é exibida na página Mapeamento de grupos para compatibilidade com versões anteriores. Não exclua essas atividades. A coluna será removida até 31 de março de 2027 sem impacto para o cliente.

Práticas recomendadas

Use o script de migração: sempre que possível, use o script de migração oficial em Google Cloud para lidar com a transição dos grupos de permissões do SOAR para os papéis do IAM.
Revise as permissões do IAM: conheça as permissões do IAM Google Cloud necessárias para diferentes funções e papéis do SOAR.
Faça um teste completo: após a migração, teste o acesso para diferentes funções e perfis de usuário para garantir que tudo funcione conforme o esperado.
Entre em contato com o suporte: para erros persistentes ou comportamentos inesperados, entre em contato com o suporte e forneça o máximo de detalhes possível.

Precisa de mais ajuda? Receba respostas de membros da comunidade e profissionais do Google SecOps.