Arquitetura de autenticação para conectores GCP

Quando liga um projeto ou organização da Google Cloud Platform (GCP) ao Microsoft Defender para a Cloud, o serviço utiliza autenticação federada para aceder de forma segura às APIs GCP sem armazenar credenciais duradouras.

A autenticação é realizada através da troca de tokens de curta duração entre o Microsoft Entra ID e o Google Cloud Security Token Service (STS), permitindo que o Defender para a Cloud se faça passar por uma conta de serviço GCP com permissões de âmbito definido.

Este artigo explica os recursos de autenticação criados durante a integração e como funciona o modelo de confiança federada.

Recursos de autenticação criados no GCP

Quando integra um projeto ou organização GCP no Defender para a Cloud, um modelo GCloud é usado para criar os recursos de autenticação necessários para estabelecer a confiança entre o Microsoft Entra ID e o Google Cloud.

Esses recursos incluem:

  • Pool de identidade de carga de trabalho e provedores
  • Contas de serviço e vinculações de política

Estes recursos permitem ao Defender para a Cloud autenticar-se ao GCP e aceder às APIs necessárias para descoberta, avaliação de postura e análise de segurança.

Modelo de fornecedor de identidade

O Defender para a Cloud autentica-se no GCP utilizando federação de identidade de workload.

Um fornecedor de identidade de carga de trabalho está configurado no GCP para confiar nos tokens emitidos pelo Microsoft Entra ID. Esta confiança permite à Defender para a Cloud trocar tokens Microsoft Entra por tokens Google STS e fazer-se passar por uma conta de serviço GCP.

As permissões da conta de serviço são atribuídas ao projeto ou organização ligada e estão limitadas ao acesso exigido pelos planos Defender ativados.

Fluxo de autenticação entre nuvens

O diagrama seguinte mostra como o Defender para a Cloud se autentica no GCP usando identidade federada e troca de tokens.

Diagrama que mostra o processo de autenticação do conector Defender para a Cloud GCP usando identidade federada e troca de tokens.

O processo de autenticação funciona da seguinte forma:

  1. O serviço CSPM do Microsoft Defender para a Cloud adquire um token Microsoft Entra. O ID Microsoft Entra assina o token usando o algoritmo RS256. O token é válido por uma hora.

  2. O token Microsoft Entra é trocado com o Serviço de Tokens de Segurança (STS) da Google.

  3. O Google STS valida o token com o provedor de identidade da carga de trabalho. A validação da audiência é realizada e o token é assinado. Um token Google STS é então devolvido ao Defender para a Cloud.

  4. O Defender para a Cloud utiliza o token Google STS para se fazer passar pela conta do serviço. As credenciais da conta de serviço são utilizadas para verificar o projeto ou a organização GCP.

Suplantação de conta de serviço e âmbito de acesso

Após a autenticação concluída, o Defender para a Cloud opera usando credenciais de conta de serviço falsificadas.

  • O acesso à conta de serviço é limitado aos recursos GCP que foram integrados. Se tiver integrado um único projeto, o acesso fica restrito a esse projeto. Se integrou uma organização GCP, o acesso está restrito aos projetos incluídos nessa organização.

  • As associações de políticas restringem o acesso apenas aos recursos associados.

  • As permissões concedidas à conta do serviço determinam que sinais de segurança o Defender para a Cloud pode recolher.

Este modelo assegura acesso com privilégios mínimos, permitindo ao mesmo tempo uma avaliação contínua de segurança.

Conteúdo relacionado

  • Last updated on