Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Perguntas frequentes sobre a migração do SOAR

Compatível com:

Google SecOps SOAR

Confira as 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 Google Cloud. Esse upgrade essencial oferece benefícios importantes, incluindo maior confiabilidade, segurança aprimorada, maior conformidade e controle de acesso mais granular. Ele também oferece acesso aos recursos de IA agêntica pela integração do Protocolo de Contexto de Modelo (MCP).

A migração oferece o seguinte:

Melhora a confiabilidade e os recursos de 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 de propriedade do cliente Google Cloud .
Migração da autenticação e das permissões do SOAR para o Google Cloud IAM.
Migração das APIs do 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?

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

Propriedade do projeto do GCP: o projeto do SOAR será migrado da propriedade do Google para o seu projeto de propriedade do cliente Google Cloud .
Autenticação:
- Clientes do SecOps unificado: nenhuma mudança. A autenticação continuará sendo gerenciada pelo Google Cloud IAM.
- Clientes independentes 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, e a configuração SAML não será mais armazenada e gerenciada no próprio sistema SOAR, o que leva a controles de segurança mais fortes.
RBAC: as permissões do usuário se tornarão mais granulares e gerenciadas usando o IAM. Os ambientes e as funções do SOC continuarão 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 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 dessa 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: Nossos custos de infraestrutura vão mudar como resultado da vinculação do SOAR ao nosso Google Cloud projeto?

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 há custos associados.

P: Como conectamos nosso projeto ao SOAR?

O Google vai migrar seu projeto do SOAR para o seu Google Cloud projeto. Se você for um cliente do SecOps unificado, já temos o ID do seu Google Cloud projeto. Se você for um cliente independente do SOAR, precisará compartilhar o ID do seu Google Cloud projeto conosco.

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), você deve usar o ID do projeto existente 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, você precisa definir 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.

Tempo de inatividade e continuidade

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

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 do SOAR (incluindo ingestão, playbooks e jobs) serão pausados, mas os serviços do SIEM continuarão 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 playbooks que estão em execução quando o tempo de inatividade começa?

O serviço de playbook será desativado antes do início da migração. Alguns playbooks em execução poderão 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 de contingência se algo der errado durante a migração?

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

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 sua identidade, IDP ou Google Cloud administrador 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 v1 do SOAR 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 e as chaves de API legadas do SOAR serão descontinuadas e não funcionarão mais 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 seus scripts e integrações atuais para substituir os endpoints da API legada do 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 Google Cloud console para migrar grupos de permissões atuais para papéis personalizados do IAM. O script também atribui papéis personalizados a usuários (para clientes do Cloud Identity) ou a grupos de IdP (para clientes da federação de identidade de colaboradores).

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

Você pode desativar a migração automatizada e mapear manualmente os grupos de 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 de IdP para 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 as permissões sejam 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 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 está associado a um subdomínio diferente. Para mais informações, leia o guia de migração do MSSP.

P: Como faço a autenticação 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 nenhum endereço IP acesse a API Chronicle. Se preferir, você pode permitir 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 de migração. Os registros ficam disponíveis no seu Google Cloud projeto após a conclusão de a segunda etapa de migração.

P: Os clientes que enviam dados do SOAR para uma instância gerenciada do BigQuery (BQ) ainda poderão acessar esses dados do BigQuery após a migração?

Sim. O BigQuery gerenciado atual continuará funcionando.

Logística e suporte

P: Posso escolher um horário diferente para a migraçã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 final 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 noe na instância do Google SecOps. Google Cloud Verifique se você fez login com uma conta que tem os papéis do IAM necessários em Google Cloud e também é um usuário reconhecido no Google SecOps SOAR. O uso de contas diferentes para 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ê for um cliente unificado do Google SecOps, verifique se está usando o IAM para gerenciar papéis e permissões para o 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: conflitos podem ocorrer 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 estou recebendo 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 Google Cloud papel do IAM atribuído 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.

Verifique os papéis e 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 necessários.

Se preferir, examine 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: Realizei a migração do IAM manualmente sem usar a ferramenta fornecida e agora tenho problemas de permissão. Como posso corrigir isso?

A migração manual do IAM pode resultar na falta de permissões necessárias para papéis do SOAR. Recomendamos o uso do 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 antes da migração. Google Cloud Depois de concluir a migração, os papéis predefinidos do Chronicle (como chronicle.apiAdmin) vão incluir automaticamente as permissões do SOAR. Por exemplo, o papel de administrador da API do Chronicle agora 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 Chronicle, para identificar todos os principais atribuídos (usuários e grupos).
Confirme se apenas os usuários que exigem permissões do SOAR estão atribuídos a esses papéis.
Para limitar o acesso do SOAR a principais específicos, remova-os dos papéis predefinidos e atribua-os a uma função personalizada que exclua explicitamente as permissões de administrador do SOAR.

P: A migração foi bem-sucedida, mas ainda posso ver 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 atribuições. A coluna será removida até 30 de setembro de 2026 sem nenhum impacto no 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 de grupos de permissões do SOAR para papéis do IAM.
Revise as permissões do IAM: familiarize-se com as permissões do IAM necessárias para diferentes funções e papéis do SOAR. Google Cloud
Faça um teste completo: após a migração, teste o acesso para diferentes papéis e personas de usuário para garantir que tudo funcione conforme o esperado.
Entre em contato com o suporte: para 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.