Reorganizamos a estrutura de navegação da documentação para se alinhar diretamente aos seus fluxos de trabalho operacionais. Consulte as notas da versão e o vídeo explicativo para mais informações.

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 de SOAR

Compatível com:

Google SecOps 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 Google Cloud. Esse upgrade essencial oferece benefícios importantes, incluindo maior confiabilidade, segurança aprimorada, mais conformidade 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 de 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 Google Cloud IAM.
- 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 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 do SOC vão continuar sendo gerenciados no módulo SOAR usando grupos do 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 autônomos 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 do SOAR para o projeto Google Cloud . Se você é cliente do Unified SecOps, já temos seu ID do projeto Google Cloud . Se você for um cliente independente do SOAR, compartilhe seu 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. Se o seu Google Cloud projeto tiver o VPC SC, entre em contato com a equipe de suporte para receber orientações detalhadas sobre essas regras específicas.

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. Depois da Etapa 1, vai aparecer Google.com após o número da versão do sistema. Após a migração da Fase 2 das permissões do SOAR para os papéis do IAM , as opções Google.com e CloudIAM Enabled vão aparecer após o número da versão do sistema.

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,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 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 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.

Se você tiver problemas de acesso após a migração, provavelmente a configuração de autenticação está incorreta. Coordene com seu 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 a questão e acompanhar a resolução.

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

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

A API SOAR legada e as chaves de API serão descontinuadas e não vão mais funcionar após 30 de setembro de 2026. 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 os scripts e as integrações atuais para substituir os endpoints legados da API SOAR pelos endpoints correspondentes da API Chronicle.

Autenticação e permissões

P: Como migro meus grupos e permissões do SOAR?

Você vai usar um script de migração no seu console Google Cloud para 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 do IdP no mapeamento do 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: Existem 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 de MSSP.

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

Siga as instruções em Autenticar com a API do Chronicle.

P: Quais são os novos IPs necessários para acessar a nova API SOAR? Não é necessário permitir que nenhum endereço IP acesse a API Chronicle. Se quiser, adicione à 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 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?

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. Faça 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 SOAR do Google SecOps. Usar contas diferentes para Google Cloud e 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, verifique se está usando 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, e não apenas o nome abreviado do grupo.
Erros relacionados a papéis preexistentes: podem ocorrer conflitos ao vincular a um principal que já tem vinculações condicionais. Para resolver isso, 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 a função do IAM Google Cloud atribuída ao seu usuário não tem as permissões necessárias para o lado do SOAR da plataforma Google SecOps. Isso é comum se você estiver usando papéis personalizados do IAM.

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

Se quiser, examine as ferramentas para desenvolvedores do navegador e identifique chamadas de API específicas que retornam um erro 403. O payload da 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 tenho problemas de permissão. Como posso resolver isso?

A migração manual do IAM às vezes resulta na falta de permissões necessárias para papéis do SOAR. Recomendamos usar o script de migração fornecido para garantir que todas as permissões necessárias estejam configuradas corretamente. Se você ainda planeja fazer a migração manual, revise com atenção as permissões do IAM do Google SecOps para criar as funções personalizadas 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á estavam atribuídos a papéis amplos Google Cloud predefinidos do Chronicle 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 agora vai incluir permissões de administrador do SOAR.

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

Analise seus papéis predefinidos na página Papéis do IAM, incluindo o administrador da API Chronicle, para identificar todos os principais atribuídos (usuários e grupos).
Confirme se apenas os usuários que precisam de permissões do SOAR estão atribuídos a essas funções.
Para limitar o acesso do SOAR a principais específicos, remova-os das funções predefinidas e atribua a eles uma função personalizada 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 será exibida na página Mapeamento de grupos para compatibilidade com versões anteriores. Não exclua essas atividades. A coluna será removida até 30 de setembro de 2026 sem afetar os clientes.

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.
Analise as permissões do IAM: familiarize-se com as permissões Google Cloud do IAM necessárias para diferentes funções e papéis do SOAR.
Teste detalhadamente: após a migração, teste o acesso para diferentes funções e personas de usuários para garantir que tudo funcione conforme o esperado.
Entre em contato com o suporte: se houver erros persistentes ou comportamento inesperado, 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.