Partilhar via

Implemente a integração do GitHub Advanced Security com o Microsoft Defender for Cloud

Este guia guia-o pelos passos de configuração e outras ações para o ajudar a integrar o GitHub Advanced Security (GHAS) e o Microsoft Defender for Cloud. Esta integração ajuda-o a maximizar a segurança das aplicações cloud-native da Microsoft.

Ao seguir este guia, você:

  • Configura o teu repositório GitHub para cobertura Defender para a Cloud.
  • Crie um fator de risco em tempo real.
  • Teste casos de uso reais no Defender for Cloud.
  • Liga o código aos recursos na cloud.
  • Inicia uma campanha de segurança no GitHub. Esta campanha utiliza o contexto de execução para priorizar alertas de segurança GHAS com base no contexto de execução.
  • Criar problemas no GitHub a partir do Defender for Cloud para iniciar a correção.
  • Fechem o ciclo entre as equipas de engenharia e segurança.

Pré-requisitos

Aspeto Detalhes
Requisitos ambientais - Conta GitHub com um conector criado no Defender for Cloud
- Licença GHAS
- Defender Cloud Security Posture Management (CSPM) 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
- Leitor de Segurança na subscrição do Azure (para ver os resultados 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 os seus próprios repositórios ou um repositório GitHub de exemplo que já tenha todo o conteúdo necessário para construir uma imagem de contentor vulnerável. Antes de configurar um repositório, certifique-se de que:

Se quiser usar um repositório de exemplo, clone o seguinte repositório para a sua organização no GitHub: build25-woodgrove/mdc-customer-playbook. Este repositório destina-se a clientes testarem a integração do Defender for Cloud e do GHAS. Tem o GHAS ativado e está integrado num tenant Azure que tem o Defender CSPM ativado.

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.

    Captura de ecrã das seleções para criar um novo segredo de repositório no GitHub.

  3. Adicione os seguintes segredos ao nível do repositório ou da organização:

    Variable Description
    ACR_ENDPOINT O servidor de login do registo de contentores
    ACR_USERNAME O nome de utilizador do registo de contentores
    ACR_PASSWORD A palavra-passe do registo de contentores

    Observação

    Os nomes podem ser escolhidos livremente e 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. O painel de chaves de acesso mostra as chaves do servidor de login, nome de utilizador e palavra-passe.

      Captura de ecrã do painel que lista as chaves de acesso para um registo de contentores no portal Azure.

  4. No seu repositório, selecione Ações.

  5. Selecione o workflow Compilar e Enviar para o ACR, e depois selecione Executar workflow.

    Captura de ecrã da secção Ações de um repositório do GitHub que mostra o histórico de workflow e o botão para executar um workflow.

  6. 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 tag mdc-ghas-integration.

  7. 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):

    1. Defina a subscrição do cluster:

      az account set --subscription $subscriptionID

    2. Defina as credenciais para o cluster:

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

    3. Implemente a imagem:

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

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

Um dos fatores de risco que o Defender for 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 for Cloud, vá a Definições do Ambiente>Criticidade de Recursos.

  2. No painel direito, selecione o link para abrir o Microsoft Defender.

    Captura de ecrã da interface do Defender for Cloud que mostra as seleções para abrir o portal Microsoft Defender.

  3. Selecionar Criar uma nova classificação.

    Captura de ecrã do botão para criar uma nova classificação.

  4. Introduza um nome e descrição.

  5. No construtor de consultas, selecione recurso de nuvem.

  6. 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.

    Captura de ecrã do construtor de consultas do Microsoft Defender com um filtro de nome de recurso aplicado a um recurso na cloud.

  7. 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. O Microsoft Defender aplica a etiqueta de criticidade ao contentor depois de o detetar. Este processo pode demorar até 24 horas.

  8. Escolha um nível de criticidade e depois reveja e submeta a sua regra de classificação.

Passo 3: Valide que o seu ambiente está pronto

Observação

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

  1. Testa se a varredura sem agente do GitHub capta o repositório.

  2. Vai ao Cloud Security Explorer e faz a consulta.

    Captura de ecrã dos resultados da pesquisa no construtor de consultas Cloud Security Explorer, com filtros definidos para repositórios do GitHub e imagens de contentores.

  3. Valide que o Defender for 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.

    Captura de ecrã do Cloud Security Explorer que mostra resultados de análise para uma consulta com filtros para repositórios do GitHub e imagens de contentores.

  4. Verifique que o contentor está em execução e que o Defender for Cloud analisou o cluster AKS.

    Captura de ecrã dos resultados da consulta Cloud Security Explorer com filtros para repositórios do GitHub e imagens de contentores.

  5. Valide que os fatores de risco estão corretamente configurados do lado do Defender for Cloud. Procure o nome do seu contentor na página de inventário do Defender for Cloud, e deverá vê-lo marcado como crítico.

Passo 4: Criar uma campanha no GitHub

Como o fluxo de trabalho lança uma imagem que cria um contentor em execução com um dos fatores de risco (crítico para o negócio), os programadores podem ver os fatores de risco no GitHub.

Observação

Depois de classificar o seu recurso como crítico, pode demorar até 12 horas até o Defender for Cloud enviar os dados para o GitHub. Mais informações.

  1. No GitHub, vai à organização GitHub que usaste para os testes de configuração.

  2. Selecionar Segurança>Campanhas>Criar Campanha>A partir de filtros de varredura de código.

    Captura de ecrã das opções no GitHub para criar uma campanha a partir de código ou filtros de varrimento secreto.

  3. Crie a seguinte campanha. Esta campanha mostra alertas abertos com gravidade média, onde a imagem distribuída a partir do repositório está associada a um recurso crítico. O seu repositório de testes deve ser detetado com esta campanha.

    Captura de ecrã de uma campanha no GitHub com filtros para alertas abertos, gravidade e risco em tempo de execução.

  4. Selecione Guardar>Publicar como campanha.

  5. Introduza a informação necessária e depois publique a campanha.

Passo 5: Avaliar as recomendações de código para a nuvem

Use recomendações de code-to-cloud e alertas de segurança para compreender o estado dos problemas de segurança. Pode então atribuir a recomendação para resolução à equipa de engenharia relevante com a ajuda da ligação entre os alertas de segurança do Dependabot e os IDs de vulnerabilidades e exposições comuns (CVE) correspondentes no Defender for Cloud.

Para ver as recomendações de código para nuvem:

  1. No portal Defender for Cloud, vá ao separador Recomendações.

  2. Procure o nome do contentor que criou. Depois, abra uma das recomendações que inclua a palavra Atualizar.

    Se usou o repositório de exemplo, procure a recomendação Update brace-expansion.

  3. Vai ao separador Remediation Insights e vê o diagrama code-to-cloud. O diagrama mapeia o teu contentor em execução para a imagem do contentor no repositório de código e para o repositório de código da origem no GitHub.

    Captura de ecrã do separador Remediation Insights que mostra um diagrama das fases de desenvolvimento interligadas.

Ver alertas de segurança

  1. Selecione o separador CVEs associados. Repare que alguns IDs CVE têm um link Ver no GitHub na coluna Alertas Relacionados no GitHub.

  2. Selecione o link para abrir o alerta de segurança GHAS relevante.

Captura de ecrã do separador CVEs Associados que mostra um link para um alerta relacionado no GitHub.

Criar um problema no GitHub

Para fechar o ciclo entre as equipas de segurança e engenharia, pode criar um problema no GitHub que priorize os problemas de segurança em que a equipa de engenharia deve focar-se. Esta priorização pode incluir resultados que o GHAS não detetou, mas que o Defender for Cloud detetou relacionadas com IDs CVE que não fazem parte de dependências diretas. Estas descobertas podem incluir vulnerabilidades na imagem base, no sistema operativo ou em software como o NGINX.

A issue do GitHub é gerada automaticamente com todos os IDs CVE encontrados no âmbito da recomendação. A recomendação é tanto com como sem alertas Dependabot correspondentes, incluindo outros contextos de execução no repositório original.

Captura de ecrã de uma lista de problemas do GitHub que mostra três entradas marcadas com etiquetas de segurança e vulnerabilidade.

Quando atribui o problema, o estado do problema é atualizado no portal Defender for Cloud.

Captura de ecrã de um problema no GitHub com etiquetas de segurança e vulnerabilidades, incluindo detalhes como IDs CVE, fatores de risco em tempo de execução e informações de implementação.

Fazer correções agenciais

Do lado do GitHub, se tiveres uma licença do GitHub Copilot, podes resolver o problema com a ajuda do agente de programação do GitHub:

  1. Atribui um agente de programação do GitHub ao problema.
  2. Revê a correção gerada.
  3. Se a solução parecer razoável, aplique-a.
  4. Observe enquanto o Defender for Cloud atualiza o estado do problema para Fechado.

Conteúdo relacionado

  • Last updated on