Guia de validação pré-migração

Compatível com:

Este documento descreve uma abordagem de diagnóstico sistemática e detalhada para validar a instância do Google Security Operations e a configuração de autenticação antes da migração do SOAR. Este guia se concentra no padrão SAML e OIDC usado para autenticação e autorização do usuário.

Validação da configuração da API Chronicle

Para verificar se a API Chronicle está configurada corretamente no seu Google Cloud projeto, siga estas etapas:

  1. Faça login no Google Cloud console e selecione o projeto correto na lista projeto na barra de navegação superior. Google Cloud
  2. Abra o menu de navegação (≡) e acesse APIs e serviços > APIs e serviços ativados.
  3. Acesse a lista de APIs e serviços ativados para encontrar Chronicle API.

  4. Se estiver listada:a API está ativada.

    Se NÃO estiver listada: clique em + ATIVAR APIS E SERVIÇOS na parte de cima, pesquise Chronicle API e clique em Ativar.

Para verificar se a conta de serviço foi criada, faça o seguinte:

  1. Acesse a página IAM no Google Cloud console.
  2. Revelar contas ocultas (etapa essencial): selecione a caixa no lado direito da barra de filtros que diz Incluir concessões de papel fornecidas pelo Google.
  3. Pesquisar o agente:na barra de filtros, digite chronicle. Você está procurando um endereço de e-mail que corresponda a este padrão específico: service-[PROJECT_NUMBER]@gcp-sa-chronicle.iam.gserviceaccount.com
  4. Verificar permissões:confira se ele tem o papel de Agente de serviço do Chronicle. Se o papel estiver ausente, clique em editar Editar e adicione-o novamente.

Validação da configuração do Google SecOps

  1. Noconsole, selecione o projeto correto na lista. Google Cloud Google Cloud
  2. Acesse Segurança > Google SecOps e a guia Logon único vai aparecer.
  3. Se o Google SecOps estiver ativado, você vai encontrar uma guia chamada Logon único. Caso contrário, a iniciação do cliente potencial está incompleta. Forneça o Google Cloud ID do projeto no formulário do Google encontrado na notificação no produto. Confirme a data e o horário da migração e envie o formulário. Se você não receber uma resposta em até 72 horas após o envio, entre em contato com soar-migration-to-gcom@google.com.
  4. Se a guia existir, clique em Acessar o SecOps. O login bem-sucedido confirma que a configuração de autenticação está correta. Se o login falhar, use a próxima seção para depurar a configuração. Se o login falhar, use a próxima seção para depurar a configuração.

Fluxo e solução de problemas do SAML

Esta seção oferece uma visão geral do processo de autenticação SAML e descreve uma abordagem sistemática para diagnosticar e resolver problemas comuns de configuração.

Arquitetura do fluxo de trabalho de autenticação

É fundamental entender o fluxo de solicitações para isolar pontos de falha. O diagrama a seguir ilustra o caminho sequencial de um login bem-sucedido.

Arquitetura do fluxo de trabalho de autenticação

Procedimento detalhado de solução de problemas

Para diagnosticar e rastrear o processo de autenticação SAML de maneira eficaz, use os utilitários baseados na Web listados nas seções a seguir.

Embora o Google não endosse nenhum produto específico, as ferramentas a seguir são conhecidas por ajudar na solução de problemas do processo:

  • Validação de SAML: https://www.samltool.io/
    • Finalidade:usado para decodificar e validar solicitações e respostas SAML brutas.
  • Inspeção de JWT: https://www.jwt.io/
    • Finalidade:usado para inspecionar as declarações e o conteúdo de JSON Web Tokens (JWTs).

Fase 1: preparação do ambiente

Antes de começar, confira se o ambiente do navegador está pronto para capturar o tráfego de rede seguindo estas etapas:

  1. Abra uma nova guia do navegador ou use uma janela anônima.

  2. Abra as ferramentas para desenvolvedores usando o atalho do seu sistema operacional:

    • Windows: pressione F12
    • Linux: pressione Ctrl + Shift + I
    • macOS: pressione Cmd + Option + I

  3. Navegue até a guia Rede.

  4. Selecione a caixa Preservar registro para garantir que nenhum dado seja perdido durante os redirecionamentos.

    Preservar registro

  5. Navegue até o URL do ambiente do Google SecOps para iniciar o fluxo de login. Você vai receber esse URL por e-mail depois de concluir a configuração do Google SecOps na etapa 5 do estágio 1 da migração para clientes independentes do SOAR. O assunto do e-mail é Your Google SecOps instance is ready.

Fase 2: validar a solicitação SAML para o IdP

Esta etapa verifica a mensagem inicial enviada pelo Google Cloud ao seu provedor de identidade (IdP).

  1. Localizar a solicitação:na barra de filtros da guia Rede, pesquise saml.

    Localizar a solicitação

  2. Extrair dados:selecione a solicitação e clique na guia Payload. Localize o parâmetro de string de consulta rotulado como SAMLRequest.

    Extrair dados

  3. Decodificar:copie o valor da solicitação e cole-o na ferramenta Validação de SAML (samltool.io) para decodificá-lo.

    Decodificar

  4. Verificação :

    • Verifique o destino da solicitação.
    • Confirme se esse URL corresponde às configurações do seu IdP.

Fase 3: validar a resposta SAML do IdP

Esta etapa verifica os atributos retornados pelo IdP para Google Cloud após a autenticação.

  1. Localizar a resposta:na barra de filtros da guia Rede, pesquise signin-callback.

    Localizar a resposta

  2. Extrair dados:selecione a solicitação e clique na guia Payload. Localize os dados SAMLResponse.

    Localizar os dados da resposta SAML

  3. Decodificar:copie o valor da resposta e cole-o na ferramenta Validação de SAML.

  4. Verificação :

    • Analise as declarações retornadas (atributos), como groups, first name, last name, e email.
    • Importante: confira se esses atributos correspondem à configuração nas configurações do pool de colaboradores em Google Cloud.

    • Confirme se os valores estão corretos para o usuário específico que está tentando fazer login.

      Configurações do pool de funcionários

A imagem a seguir mostra um mapeamento de atributos:

attribute-mapping

O mapeamento na imagem é o seguinte:

  • google.subject = assertion.subject
  • attribute.last_name = assertion.attributes.last_name[0]
  • attribute.user_email = assertion.attributes.user_email[0]
  • attribute.first_name = assertion.attributes.first_name[0]
  • google.groups = assertion.attributes.groups

A parte esquerda é sempre a mesma: é a sintaxe do Google. O lado direito está de acordo com as chaves de atributo de declaração mostradas na resposta SAML.

O [0] é essencial para os atributos específicos declarados (last_name, user_email e first_name) e não é relevante para subject e groups.

Fase 4: validar a autenticação do Google SecOps

Esta etapa verifica se Google Cloud está autenticando o usuário para fazer login no Google SecOps SOAR.

  1. Localizar o token no navegador do usuário: Na barra de filtros da guia Rede, pesquise o endpoint auth/siem.

    Localizar o token no navegador do usuário

  2. Extrair dados:selecione a solicitação e acesse a guia Payload. Localize a string jwt.

  3. Decodificar: copie a string JWT e cole-a na ferramenta Inspeção de JWT (jwt.io).

    Copie e cole a string JWT.

  4. Verificação :

    • Compare as declarações decodificadas para given_name, family_name, email e idpgroups.
    • Confirmação de correspondência:esses valores precisam corresponder exatamente aos atributos validados na fase 3 (resposta SAML).
    • Se os valores corresponderem e você ainda não tiver acesso, verifique a atribuição de papéis no IAM. Confira se todos os usuários têm um dos papéis predefinidos do Chronicle atribuídos usando o formato principal correto para a configuração de identidade (federação de identidade de colaboradores ou Cloud Identity para contas gerenciadas pelo Google).

Fase 5: validar o acesso às permissões do SOAR

Esta etapa confirma se o sistema atribui permissões no SOAR corretamente pela página Mapeamento de grupos da plataforma.

Os administradores acessam o SOAR automaticamente porque a página Mapeamento de grupos permite o acesso padrão.

Para validar o acesso ao grupo dos usuários, adicione alguns mapeamentos de grupos do IdP a essa nova instância do SOAR. As novas instâncias têm uma página Mapeamento de grupos vazia por padrão. Para validar o acesso ao grupo de outros usuários, adicione mapeamentos de grupos do IdP à nova instância do SOAR e siga estas etapas:

  1. Copie os mapeamentos de grupos da página Mapeamentos de grupos na instância do SOAR.
  2. Peça a um usuário no grupo de acesso do IdP para acessar o novo URL do Google SecOps.

  3. Se o usuário não conseguir acessar o SOAR, siga estas etapas de solução de problemas:

    a. Inspecionar a resposta:abra a solicitação auth/siem da fase 4 e selecione a guia Visualização.

    b. Verificar permissões:localize o objeto permissions na resposta JSON.

Opcional: para economizar tempo, copie esses mapeamentos para sua instância do Google SecOps em Configurações > Avançado > Mapeamento de grupos.

Fluxo e solução de problemas do OIDC

Esta seção oferece uma visão geral do processo de autenticação OIDC e descreve uma abordagem sistemática para diagnosticar e resolver problemas comuns de integração.

Arquitetura do fluxo de trabalho de autenticação

É fundamental entender o fluxo de solicitações para isolar pontos de falha. O diagrama a seguir ilustra o caminho sequencial de um login bem-sucedido.

Arquitetura do fluxo de trabalho de autenticação

Procedimento detalhado de solução de problemas do OIDC

Para diagnosticar e rastrear o processo de autenticação OIDC de maneira eficaz, use as ferramentas para desenvolvedores do navegador e os decodificadores JWT on-line.

  • Inspeção de JWT: https://www.jwt.io/
    • Finalidade:usado para inspecionar as declarações e o conteúdo de JSON Web Tokens (JWTs).

Fase 1: preparação do ambiente

Antes de começar, confira se o ambiente do navegador está pronto para capturar a rede seguindo estas etapas:

  1. Abra uma nova guia em branco do navegador ou em uma janela anônima.

  2. Abra as ferramentas para desenvolvedores usando o atalho do seu sistema operacional:

    • Windows: pressione F12
    • Linux: pressione Ctrl + Shift + I
    • macOS: pressione Cmd + Option + I

  3. Navegue até a guia Rede.

  4. Selecione a caixa Preservar registro para garantir que nenhum dado seja perdido durante os redirecionamentos.

    Preservar registro

  5. Navegue até o URL do ambiente do Google SecOps para iniciar o fluxo de login. Você vai receber esse URL por e-mail depois de concluir a configuração do Google SecOps na etapa 5 do estágio 1 da migração para clientes independentes do SOAR. O assunto do e-mail é YourGoogle SecOps instance is ready.

Fase 2: validar a solicitação de autorização para um provedor OIDC

Esta etapa verifica o redirecionamento inicial do Google Cloud para o provedor OpenID Connect (IdP).

  1. Localizar a solicitação:na guia Rede, procure o redirecionamento inicial para o endpoint de autorização do provedor OIDC. O URL normalmente contém parâmetros como client_id, redirect_uri, scope, response_type e state.

    Localizar a solicitação

  2. Verificação :

    • Confirme se o client_id corresponde ao configurado no provedor OIDC.
    • Confira se o redirect_uri corresponde exatamente a https://auth.backstory.chronicle.security/signin-callback/locations/global/workforcePools/POOL_ID/provider/PROVIDER_ID, substituindo POOL_ID e PROVIDER_ID pelo pool e provedor da federação de identidade de colaboradores.
    • Verifique se o response_type está definido como código.
    • Observe o parâmetro de escopo, que precisa incluir o openid e outros escopos necessários para liberar as declarações necessárias (por exemplo, e-mail, perfil).

Fase 3: validar o callback e a troca de tokens

Esta etapa verifica a resposta do IdP para Google Cloud.

  1. Localizar o callback:na guia Rede, encontre a solicitação para o URL de callback de login: (.../signin-callback/...).

    Localizar o callback

  2. Verificar dados:confira os parâmetros de URL dessa solicitação. Ele precisa conter um parâmetro de código fornecido pelo IdP OIDC.

  3. Nos bastidores:a federação de identidade de colaboradores troca esse código por tokens (token de ID, token de acesso) do endpoint de token do provedor OIDC. Os erros nessa fase geralmente ficam visíveis no Cloud Logging para a federação de identidade de colaboradores.

    • Verificar a propagação de atributos e o token completo:para verificar se o mapeamento de atributos na federação de identidade de colaboradores produz os resultados esperados:
      • Adicione o URI de redirecionamento, fornecido na configuração do provedor da federação de identidade de colaboradores, aos URIs de redirecionamento do provedor (por exemplo, https://auth.cloud.google/signin-callback/locations/global/workforcePools/POOL_ID/providers/PROVIDER_ID).
      • Acesse o provedor da federação de identidade de colaboradores para depurar o token do IdP. Você também pode verificar o token completo. Para mais informações, consulte Verificar a configuração do produto.

    Exibir token completo Validar atributos

Fase 4: validar a autenticação do Google SecOps

Esta etapa verifica se Google Cloud está autenticando o usuário para fazer login no Google SecOps SOAR.

  1. Localizar o token no navegador do usuário: Na barra de filtros da guia Rede, pesquise o endpoint auth/siem.

    Localizar o token no navegador do usuário

  2. Extrair dados:selecione a solicitação e acesse a guia Payload. Localize a string jwt.

  3. Decodificar: copie a string JWT e cole-a na ferramenta Inspeção de JWT (jwt.io).

    Copie e cole a string JWT.

  4. Verificação :

    • Compare as declarações decodificadas para sub, given_name, family_name, email e idpgroups.
    • Confirmação de correspondência: esses valores precisam corresponder aos atributos liberados pelo provedor OIDC e como eles são mapeados nos mapeamentos de atributos da federação de identidade de colaboradores. Por exemplo, attribute.first_name em Google Cloud precisa ser mapeado para given_name no JWT.
    • Papéis do IAM:se as declarações estiverem corretas, mas o acesso for negado com uma mensagem como Cannot Authenticate user, because user does not have access to the GCP project..., verifique as atribuições de papéis do IAM. Confira se os grupos do usuário (idp_groups no JWT) têm os papéis necessários concedidos usando o formato principalSet correto (por exemplo, principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/group/IDP_GROUP_NAME).

Fase 5: validar o acesso às permissões do SOAR

Esta etapa confirma se o sistema atribui permissões no SOAR corretamente pela página Mapeamento de grupos da plataforma.

Os administradores acessam o SOAR automaticamente porque a página Mapeamento de grupos permite o acesso padrão.

Para validar o acesso ao grupo dos usuários, adicione alguns mapeamentos de grupos do IdP a essa nova instância do SOAR. As novas instâncias têm uma página Mapeamento de grupos vazia por padrão. Para validar o acesso ao grupo de outros usuários, adicione mapeamentos de grupos do IdP à nova instância do SOAR e siga estas etapas:

  1. Copie os mapeamentos de grupos da página Mapeamentos de grupos na instância do SOAR.
  2. Peça a um usuário no grupo de acesso do IdP para acessar o novo URL do Google SecOps.

  3. Se o usuário não conseguir acessar o SOAR, siga estas etapas de solução de problemas:

    a. Inspecionar a resposta:abra a solicitação auth/siem da fase 4 e selecione a guia Visualização.

    b. Verificar permissões:localize o objeto permissions na resposta JSON.

Opcional: para economizar tempo, copie esses mapeamentos para sua instância do Google SecOps em Configurações > Avançado > Mapeamento de grupos.

Erros comuns do OIDC :

  • invalid_redirect_uri do IdP: confira se o URI de redirecionamento configurado no IdP corresponde exatamente a: https://auth.backstory.chronicle.security/signin-callback/locations/global/workforcePools/POOL_ID/provider/PROVIDER_ID, substituindo POOL_ID e PROVIDER_ID pelo pool e provedor da federação de identidade de colaboradores. Até mesmo uma barra invertida à direita ou uma incompatibilidade entre http e https vai acionar isso.

  • Declarações ausentes no JWT :

    1. Lado do IdP:verifique se o cliente OIDC está configurado para liberar as declarações necessárias (que são mapeadas no WIF, como sub, groups, email, given_name, family_name) no token de ID.

    2. Lado do WIF:confira se essas declarações recebidas estão mapeadas corretamente na seção Mapeamento de atributos do WIF (por exemplo, google.groups=assertion.groups). Se uma declaração estiver presente no token, mas não mapeada no WIF, a plataforma SOAR poderá falhar ao autorizar o usuário. Para verificar se o mapeamento de atributos produz os resultados esperados, consulte Verificar a configuração do provedor.

Mapeamentos de grupos após a migração

O mapeamento de grupos continua sendo essencial no Google SecOps após a conclusão da migração

Após a migração, a instância migrada mantém os mapeamentos de grupos. Eles servem como base para determinar o acesso do usuário ao SOAR. É necessário garantir que todos os usuários estejam mapeados nessa página para acessar o Google SecOps. Para mais informações, consulte Acessar uma instância.

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