Configurar a integração nativa de segurança avançada do GitHub com o Microsoft Defender para a Cloud

Este guia fornece passos de configuração e outras ações para o ajudar a integrar o GitHub Advanced Security (GHAS) e o Microsoft Defender para a Cloud com um caso de uso que o ajude a validar a integração de ponta a ponta. 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 for Cloud.
• Crie um fator de risco em tempo real.
• Teste casos de uso reais no Defender for Cloud.
• Liga o código aos recursos de runtime.
• Inicia uma campanha de segurança no GitHub. Esta campanha utiliza o contexto de execução para priorizar os alertas de segurança do GHAS.
• Criar problemas no GitHub a partir do Defender for Cloud para iniciar a remediação.
• Fechem o ciclo entre as equipas de engenharia e segurança.

Pré-requisitos

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:

• Defines um conector para a organização GitHub que planeias usar no portal Defender for Cloud. Siga os passos em Ligue o seu ambiente de GitHub ao Microsoft Defender para a Cloud.

• Configuras a análise de código sem agente para o teu conector do GitHub. Siga os passos em Configurar a análise de código sem agente (pré-visualização).

• O repositório que usas para a integração é privado.

Se quiser usar um repositório de exemplo, clone o seguinte repositório para a sua organização 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 do 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áveisAçõ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	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 do 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.

      

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

5. Selecione o workflow Compilar e Enviar para o ACR, e depois selecione Executar 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 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: Crie o exemplo de 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 AmbienteCriticidade de Recursos.

2. No painel direito, selecione o link para abrir o 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.

   

7. Na página Pré-visualizar Recursos, 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

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 que:

• Código completo para visibilidade em tempo de execução
• Os repositórios de código-fonte são continuamente monitorizados pelo Microsoft Defender para a Cloud para vulnerabilidades de segurança.
• Artefatos de construção (como imagens de contêineres) são verificados nos registos de contêineres 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 for Cloud correlaciona e traça cada artefacto desde o código, passando pela compilação e implementação, até ao tempo de execução — e vice-versa.

1. Teste que a varredura sem agente do GitHub capta o repositório.

2. 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. Consulte Papéis de utilizador e permissões para mais informações.

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.

   

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

   

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.

   Observação

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

6. Se já usa fatores de risco, pode verificar a sua configuração em Definiçõesde Criticidade de Recursos.

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

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.

Para criar uma campanha de digitalização, precisa trabalhar ao nível da organização da GitHub. Esta experiência não está disponível ao nível do repositório individual.

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

2. Selecionar SegurançaCampanhasCriar CampanhaA partir de filtros de varredura de código. Esta campanha define quais os artefactos descobertos na nuvem (como imagens de contentores ou cargas de trabalho) são avaliados e acompanhados em todo o seu ambiente.

   

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.

   

4. Selecione GuardarPublicar como campanha.

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

Passo 5: Avaliar as recomendações

Use recomendações de código para tempo de execução 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.

Recomendações de código para tempo de execução

Para visualizar as recomendações do código para execução:

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 do software Update , o nome da recomendação começa com Update.

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

3. Aceda ao separador Remediation Insights e visualize o diagrama de código para runtime. 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.

   Quando a campanha decorre, o Defender apresenta código a recomendações em tempo de execução que correlacionam as descobertas na cloud com o código e construem artefactos.

A perspetiva seguinte fornece contexto sobre os ativos afetados e os sinais de risco. Esta perspetiva ajuda-o a perceber porque é que uma recomendação foi gerada antes de agir.

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

Alertas de segurança

Os alertas de segurança aparecem como parte do fluxo de avaliação de recomendações. Estes alertas fornecem contexto adicional sobre riscos ativos e ajudam a priorizar a remediação, mas não criam automaticamente problemas no GitHub.

1. Selecione o separador CVEs Associados. Note que alguns IDs CVE têm uma ligação 'Ver no GitHub' na coluna Related GitHub Alerts.

2. Selecione o link para abrir o alerta de segurança GHAS relevante. (Para visualizar o conteúdo de alertas GHAS no GitHub, deve ter permissões de acesso ao repositório relevante do GitHub. Contacta o administrador do teu GitHub se não o fizeres.)

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.

Da perspetiva de recomendações, podes gerar explicitamente um problema no GitHub para acompanhar o trabalho de remediação.

1. Abra a recomendação relevante de software para atualização.

2. Selecione o separador Insights de Remediação.

3. Revise a caixa de Runtime afetada.

4. Validar se já existe um problema GitHub - Se já existir um problema GitHub, é exibido um ícone de GitHub na caixa. Passe o rato sobre o ícone para ver os detalhes da questão.
   Se não existir nenhum problema e tiveres as permissões necessárias, podes gerar um novo problema no GitHub.

5. Selecione Executar ação.

6. Selecione a opção Gerar problema do GitHub na janela de contexto.

7. Se o problema foi criado com sucesso, verá uma notificação popup com um link para o problema.

8. A questão é criada no repositório de origem.

   Observação

   Se a opção Gerar issue do GitHub não estiver disponível, podem estar em falta permissões do GitHub ou do repositório.
   Contacte o seu GitHub ou administrador do repositório para solicitar acesso.

   

9. Quando o problema é atribuído a um utilizador do GitHub ou se o seu estado é alterado, a atualização é refletida no portal Defender for Cloud.

Acompanhar atualizações de propriedade e estado - Alterações ao estado da emissão ou à cessão feitas em GitHub são refletidas em Microsoft Defender para a Cloud, permitindo-lhe acompanhar o progresso da propriedade e da remediação.

Fazer correções agenciais

Do lado do GitHub, se tiver uma licença do GitHub Copilot, pode resolver o problema com a ajuda do assistente de codificaçã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

• O que é a integração de Segurança Avançada do GitHub com o Microsoft Defender para a Cloud (pré-visualização)?
• Visão geral da segurança do Microsoft Defender para DevOps em Nuvem
• Quickstart: Liga o teu ambiente GitHub ao Microsoft Defender para a Cloud
• Configurar a análise de código sem agente (pré-visualização)