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 de usuários.

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

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

  1. Faça login no console doGoogle Cloud e selecione o projeto Google Cloud correto na lista projeto na barra de navegação superior.
  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 ela estiver na lista:a API está ativada.

    Se ela NÃO estiver na lista: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 do IAM no console do Google Cloud .
  2. Revelar contas ocultas (etapa crucial): marque a caixa no lado direito da barra de filtro que diz Incluir concessões de papel fornecidas pelo Google.
  3. Pesquisar o agente:na barra de filtro, 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 a função estiver faltando, clique em Editar Editar e adicione-a novamente.

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

  1. No console Google Cloud , selecione o Google Cloud projeto correto na lista.
  2. Acesse Segurança > Google SecOps. 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 da perspectiva está incompleta. Forneça o ID do projeto Google Cloud 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. Um 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 do SAML e solução de problemas

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

Entender o fluxo de solicitações é fundamental 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 ajudam a resolver problemas no processo:

  • Validação do 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 dos JSON Web Tokens (JWTs).

Fase 1: preparação do ambiente

Antes de começar, verifique 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. Acesse a guia Rede.

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

    Preservar registro

  5. Acesse 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 da Fase 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 por Google Cloud ao seu provedor de identidade (IDP).

  1. Localize 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 na ferramenta Validação do SAML (samltool.io) para decodificar.

    Decodificar

  4. Verificação:

    • Verifique o Destino da solicitação.
    • Confirme se o URL corresponde às configurações de configuração no 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. Localize 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 de SAMLResponse.

    Localizar os dados da resposta SAML

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

  4. Verificação:

    • Analise as declarações (atributos) retornadas, como groups, first name, last name e email.
    • Importante:verifique se esses atributos correspondem à configuração nas configurações do pool de força de trabalho 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] é fundamental para os atributos específicos declarados (last_name, user_email , first_name), mas 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. Localize o token no navegador do usuário:na barra de filtro 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 na ferramenta Inspeção de JWT (jwt.io).

    Copie e cole a string JWT

  4. Verificação:

    • Compare as declarações decodificadas de 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. Verifique se todos os usuários estão atribuídos a uma das funções predefinidas do Chronicle usando o formato principal correto para sua configuração de identidade (federação de identidade de colaboradores ou Cloud Identity para contas gerenciadas do Google).

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

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

Os administradores acessam o SOAR automaticamente porque a página Mapeamento de grupos ativa 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. Por padrão, as novas instâncias têm uma página Mapeamento de grupo vazia. Para validar o acesso ao grupo de outros usuários, adicione mapeamentos de grupo do IdP à nova instância do SOAR e siga estas etapas:

  1. Copie os mapeamentos de grupo da página Mapeamentos de grupo na sua instância do SOAR.
  2. Peça para um usuário no grupo do IdP 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. Inspecione a resposta:abra a solicitação auth/siem da Fase 4 e selecione a guia Prévia.

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

Opcional: para economizar tempo, copie esses mapeamentos para sua instância atual 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 do OIDC e descreve uma abordagem sistemática para diagnosticar e resolver problemas comuns de integração.

Arquitetura do fluxo de trabalho de autenticação

Entender o fluxo de solicitações é fundamental 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 para solução de problemas do OIDC

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

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

Fase 1: preparação do ambiente

Antes de começar, verifique se o ambiente do navegador está pronto para capturar a rede concluindo as seguintes 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. Acesse a guia Rede.

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

    Preservar registro

  5. Acesse 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 da Fase 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 de Google Cloud para seu provedor OpenID Connect (IdP).

  1. Localize a solicitação:na guia Rede, procure o redirecionamento inicial para o endpoint de autorização do seu provedor OIDC. O URL geralmente 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 seu provedor OIDC.
    • Verifique se 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 da força de trabalho.
    • Verifique se response_type está definido como código.
    • Observe o parâmetro de escopo, que precisa incluir 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 de volta para Google Cloud.

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

    Localizar o callback

  2. Verificar dados:confira os parâmetros de URL desta solicitação. Ele precisa conter um parâmetro de código fornecido pelo seu 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 etapa geralmente ficam visíveis no Cloud Logging para a federação de identidade da força de trabalho.

    • Verifique a propagação de atributos e o token completo:para verificar se o mapeamento de atributos na federação de identidade da força de trabalho produz os resultados esperados:
      • Adicione o URI de redirecionamento, fornecido na configuração do provedor da Federação de identidade da força de trabalho, aos URIs de redirecionamento do provedor (por exemplo, https://auth.cloud.google/signin-callback/locations/global/workforcePools/POOL_ID/providers/PROVIDER_ID).
      • Acesse seu provedor de federação de identidade da força de trabalho 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. Localize o token no navegador do usuário:na barra de filtro 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 na ferramenta Inspeção de JWT (jwt.io).

    Copie e cole a string JWT

  4. Verificação:

    • Compare as declarações decodificadas de sub, given_name, family_name, email e idpgroups.
    • Confirmação de correspondência:esses valores precisam corresponder aos atributos divulgados pelo seu provedor de 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 deve 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. Verifique se os grupos do usuário (idp_groups no JWT) têm as funções necessárias 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

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

Os administradores acessam o SOAR automaticamente porque a página Mapeamento de grupos ativa 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. Por padrão, as novas instâncias têm uma página Mapeamento de grupo vazia. Para validar o acesso ao grupo de outros usuários, adicione mapeamentos de grupo do IdP à nova instância do SOAR e siga estas etapas:

  1. Copie os mapeamentos de grupo da página Mapeamentos de grupo na sua instância do SOAR.
  2. Peça para um usuário no grupo do IdP 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. Inspecione a resposta:abra a solicitação auth/siem da Fase 4 e selecione a guia Prévia.

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

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

Erros comuns do OIDC:

  • invalid_redirect_uri do IdP:verifique 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 da força de trabalho. Até mesmo uma barra invertida no final 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 (mapeadas no WIF, como sub, groups, email, given_name, family_name) no token de ID.

    2. Lado do WIF:verifique 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á não autorizar o usuário. Para verificar se o mapeamento de atributos produz os resultados esperados, consulte Verificar a configuração do provedor.

Mapeamentos de grupo após a migração

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

Após a migração, a instância migrada vai manter os mapeamentos de grupo. Elas servem como base para determinar o acesso do usuário ao SOAR. Verifique se todos os usuários estão mapeados nessa página para acessar o Google SecOps. Consulte Acessar uma instância para mais informações.

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