Integração Avançada de Segurança do GitHub com Microsoft Defender para a Cloud – Sandbox Project

Este guia apresenta passos de configuração para um projeto sandbox que o ajuda a avaliar a integração com GitHub Advanced Security (GHAS) e Microsoft Defender para a Cloud de ponta a ponta com um caso de uso simples.

Esta integração ajuda a maximizar a segurança das aplicações cloud-native da Microsoft, correlacionando riscos e contexto em tempo de execução com o código originado para uma remediação mais rápida baseada em IA.

Ao seguir este guia, você:

  • Configure o seu repositório GitHub para cobrir o Defender para a Cloud.
  • Crie um fator de risco em tempo real.
  • Liga o código aos recursos de runtime.
  • Teste casos de uso reais no Defender para a Cloud.

Pré-requisitos

Aspeto Informações
Requisitos ambientais - Conta GitHub com um conector criado no Defender para a Cloud
- Licença GHAS
- Defender Cloud Security Posture Management (DCSPM) ativado na subscrição
- Microsoft Security Copilot (opcional para remediação automática)
Funções e permissões - Permissões de Administrador de Segurança
- Administrador de Segurança na subscrição do Azure (para ver as conclusões no Defender para a Cloud)
- Proprietário da organização GitHub
Ambientes de cloud Disponível apenas em clouds comerciais (não no Azure Government, Azure operado pela 21Vianet, ou noutras clouds soberanas).

Prepare seu ambiente

Passo 1: Configurar o repositório do GitHub e executar o fluxo de trabalho

Para testar a integração, use o repositório GitHub de exemplo Sandbox que já tem todo o conteúdo para construir uma imagem de contentor vulnerável.

Antes de configurar um repositório, certifique-se de que:

  1. Clone o seguinte repositório para a sua organização GitHub:
  1. No repositório, siga estes passos:

    1. Vá para Configurações.
    2. No painel esquerdo, selecione Segredos e variáveis > Ações. Depois seleciona o segredo do novo repositório.
    3. Adicione os seguintes segredos ao nível do repositório ou da organização:
Variable Descrição
ACR_ENDPOINT O servidor de autenticação do registo de contentores.
ACR_USERNAME O nome de utilizador do registo de contentores.
ACR_PASSWORD A senha para o registro do contêiner.

Observação

Pode escolher qualquer nome para estas variáveis. Não precisam de seguir um padrão específico.

Pode encontrar esta informação no portal Azure seguindo estes passos:

  1. Selecione o registo de contentores onde quer implementar.
  2. Em Definições, selecione Teclas de Acesso.
  3. O painel de chaves de acesso mostra as chaves do servidor de autenticação, nome de utilizador e palavra-passe.

No seu repositório, selecione Ações, selecione o fluxo de trabalho Criar e Enviar para o ACR, e depois selecione Executar o fluxo de trabalho.

Verifique se a imagem foi implementada no seu registo de contentores. Para o repositório de exemplo, a imagem deve estar num registo chamado mdc-mock-0001 com a etiqueta mdc-ghas-integration.

Implemente a mesma imagem que um contentor em execução no seu cluster. Uma forma de completar este passo é ligando-te ao cluster e usando o kubectl run comando. Aqui está um exemplo para o Azure Kubernetes Service (AKS):

Defina a subscrição do cluster:

az account set --subscription $subscriptionID

Defina as credenciais para o cluster:

az aks get-credentials --resource-group $resourceGroupName --name $kubernetesClusterName --overwrite-existing

Implemente a imagem:

kubectl run $containerName --image=$registryName.azurecr.io/mdc-mock-0001:mdc-ghas-integration

Passo 2: Crie o exemplo de fator de risco (regra crítica para o negócio)

Um dos fatores de risco que o Defender para a Cloud deteta para esta integração é a criticidade empresarial. As organizações podem criar regras para rotular os recursos como críticos para o negócio.

  1. No portal Defender para a Cloud, vá a Definições do Ambiente>Criticidade de Recursos.
  2. No painel direito, selecione o link para abrir o Microsoft Defender.
  3. Selecionar Criar uma nova classificação.
  4. Introduza um nome e descrição.
  5. No construtor de consultas, selecione recurso de nuvem. Escreva uma consulta para definir o Nome do Recurso igual ao nome do contentor que implementou no seu cluster para validação. Em seguida, selecione Seguinte.
  6. Na página Pré-visualização de Ativos, se o Microsoft Defender já tiver detetado o seu recurso, o nome do contentor aparece com um tipo de ativo K8s-container ou K8s-pod. Mesmo que o nome ainda não seja visível, continue com o passo seguinte.
  7. Escolha um nível de criticidade e depois reveja e submeta a sua regra de classificação.

Observação

O Microsoft Defender aplica a etiqueta de criticidade ao contentor depois de o detetar. Este processo pode demorar até 24 horas.

Passo 3: Valide que o seu ambiente está pronto

A validação confirma que o seu ambiente está corretamente configurado para apresentar recomendações durante o tempo de execução e gerar resultados acionáveis.

Durante esta etapa, o Defender verifica a visibilidade integral do código durante a execução.

  • O Microsoft Defender para a Cloud monitoriza continuamente os repositórios de código-fonte para vulnerabilidades de segurança.
  • Artefactos de construção, como imagens de contentores, são digitalizados em registos de contentores antes da implementação.
  • As cargas de trabalho em tempo de execução implementadas nos clusters Kubernetes são monitorizadas quanto a riscos de segurança.
  • O Defender para a Cloud correlaciona e traça cada artefacto desde o código, passando pela compilação e implementação, ao tempo de execução e vice-versa.

Observação

Pode demorar até 24 horas após a aplicação dos passos anteriores para ver os resultados seguintes.

Verifique se a análise sem agente do GitHub detecta o repositório.

Vai ao Cloud Security Explorer e faz a consulta. As consultas de validação testam se o Defender consegue identificar artefactos produzidos pelas suas linhas de processamento e pelas suas cargas de trabalho. Se as consultas devolverem resultados, indica que a varredura e a correlação estão a funcionar como esperado.

Observação

Se não forem devolvidos resultados, pode indicar que os artefactos ainda não foram gerados, que a varredura não está configurada ou que faltam permissões.

  • Valide que o Defender para a Cloud (no Azure Container Registry) digitalizou a imagem do contentor e usou-a para criar um contentor.
  • Na sua consulta, adicione as condições para a sua implementação específica.
  • Verifique que o contentor está em execução e que o Defender para a Cloud analisou o cluster AKS.
  • Valide que os fatores de risco estão corretamente configurados do lado do Defender para a Cloud. Procure o nome do seu contentor na página de inventário do Defender para a Cloud, e deverá vê-lo marcado como crítico.

Observação

Este passo só é necessário se os fatores de risco ainda não estiverem configurados no seu ambiente.

A validação bem-sucedida garante que passos subsequentes, como recomendações, campanhas e geração de edições no GitHub, produzam resultados significativos.

Passos seguintes