Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este guia orienta você por todas as etapas de instalação para ajudá-lo a aproveitar ao máximo a segurança de aplicativos nativos de nuvem da Microsoft integrando o GitHub Advanced Security (GHAS) e o Microsoft Defender para Nuvem (MDC).
Seguindo este guia, você:
- Configurar seu repositório GitHub para cobertura do Microsoft Defender para Nuvem (MDC)
- Criar um fator de risco de tempo de execução
- Testar casos reais de uso no MDC
- Vincular código a recursos de nuvem
- Inicie uma campanha de segurança no GitHub, aproveitando o contexto de runtime para priorizar os alertas de segurança do GHAS com base no contexto de runtime
- Criar questões no GitHub a partir do MDC para iniciar a remediação
- Fechar o loop entre as equipes de Engenharia & Segurança
Pré-requisitos
| Aspecto | Detalhes |
|---|---|
| Requisitos ambientais | - Conta do GitHub com um conector criado no Microsoft Defender para Nuvem (MDC) - Licença de GHAS (Segurança Avançada) do GitHub - Defender CSPM habilitado na assinatura – GitHub Security Copilot (opcional para correção automatizada) |
| Funções &permissões | - Permissões de administrador de segurança - Leitor de Segurança na Assinatura do Azure (para exibir os resultados no MDC) – Proprietário da organização do GitHub |
| Ambientes de nuvem | - Disponível apenas em nuvens comerciais (não em US Gov, China Gov ou outras nuvens soberanas) |
Prepare o seu ambiente
Etapa 1: Configurar o repositório GitHub e executar o fluxo de trabalho
Para testar a integração, use seus próprios repositórios ou um repositório GitHub de exemplo que já tenha todo o conteúdo para criar uma imagem de contêiner vulnerável.
Certifique-se de definir um conector para a organização GitHub que você planeja usar no portal do Microsoft Defender para Nuvem. Para definição de conector, siga as etapas em Conectar suas organizações do GitHub.
Verifique se você tem a verificação de código sem agente configurada para o conector do GitHub. Caso contrário, siga as etapas em: Configurar a verificação de código sem agente (versão prévia).
Observação
Verifique se o repositório usado para a integração é privado.
Se você quiser usar um repositório de exemplo, clone o repositório a seguir para sua organização do GitHub. Esse repositório tem o GHAS habilitado e está integrado a um locatário do Azure com DCSPM habilitado:build25-woodgrove/mdc-customer-playbook. Esse repositório serve para os clientes testarem a integração do Microsoft Defender para Nuvem e GHAS.
No repositório, siga estas etapas:
- Vá para Configurações.
- No painel esquerdo, selecione Segredos e Variáveis>Ações.
- Adicione os seguintes segredos no nível do repositório ou da organização:
| Variable | Description |
|---|---|
| ACR_ENDPOINT | O servidor de logon do Registro de Contêiner do Azure |
| ACR_PASSWORD | A senha do Registro de Contêiner do Azure |
| ACR_USERNAME | O nome de usuário do Registro de Contêiner do Azure |
Observação
Os nomes podem ser escolhidos livremente e não precisam seguir um padrão específico.
Você pode encontrar essas informações no portal do Azure seguindo estas etapas:
Selecione o ACR no qual você deseja implantar.
Selecione Chaves de Acesso em Configurações.
No repositório, selecione Ações.
Selecione o fluxo de trabalho Compilar e Enviar por push para o ACR e execute o fluxo de trabalho.
Verifique se a imagem foi implantada no Registro de Contêiner do Azure.
Para o repositório de exemplo fornecido: a imagem deve estar em um registro chamado mdc-mock-0001 com a marca mdc-ghas-integration.
Implante a mesma imagem que um contêiner em execução no cluster. Uma maneira de concluir essa etapa é conectando-se ao cluster e usando o
kubectl runcomando. Este é um exemplo para o AKS:Defina a assinatura do cluster:
az account set --subscription $subscriptionIDDefina as credenciais para o cluster:
az aks get-credentials --resource-group $resourceGroupName --name $kubernetesClusterName --overwrite-existingImplante a imagem:
kubectl run $containerName --image=$registryName.azurecr.io/mdc-mock-0001:mdc-ghas-integration
Etapa 2: Criar o primeiro fator de risco – Regra Comercialmente Crítica
Um dos fatores de risco que o Defender para Nuvem detecta para essa integração é a criticidade dos negócios. As organizações podem criar regras para rotular recursos diferentes como comercialmente críticos.
No portal do Microsoft Defender para Nuvem (portal do Azure), vá para Configurações de Ambiente, escolha Resource Criticality.
No painel direito, selecione o link para abrir o Microsoft Defender.
Selecione Criar uma nova classificação.
Insira um nome e uma descrição.
Escolha o recurso de nuvem no criador de consultas.
Escreva uma consulta para definir o Nome do Recurso igual ao nome do contêiner que você implantou no cluster para validação e selecione Avançar.
Na página Ativos de Visualização , se o Microsoft Defender já tiver detectado seu recurso, o nome do contêiner será exibido com o tipo de ativo sendo K8s-container ou K8s-pod. Mesmo que ainda não esteja visível na página de recursos de pré-visualização, prossiga para a próxima etapa. O Microsoft Defender aplica o rótulo de criticidade ao contêiner uma vez detectado. Esse processo pode levar até 24 horas.
Escolha um nível de criticidade e, em seguida, examine e envie sua regra de classificação.
Etapa 3: validar se o ambiente está pronto
Observação
Pode levar até 24 horas após as etapas anteriores serem aplicadas para ver os resultados a seguir.
Teste se a varredura sem agente do GitHub detecta o repositório.
Valide se o MDC (no ACR) examinou a imagem do contêiner e a usou para criar um contêiner. Em sua consulta, adicione as condições para sua implantação específica.
Valide que o contêiner está em execução e que o MDC digitalizou o cluster AKS.
Valide se os fatores de risco estão configurados corretamente no lado do MDC. Pesquise o nome do contêiner na página de inventário do MDC e você deverá vê-lo marcado como crítico.
Etapa 4: Criar uma campanha do GitHub
Como o fluxo de trabalho implanta uma imagem que cria um contêiner em execução com um dos fatores de risco (comercialmente crítico), os desenvolvedores podem ver fatores de risco no GitHub.
Observação
Depois de classificar o recurso como crítico, pode levar até 12 horas para que o MDC envie os dados para o GitHub. Saiba mais aqui.
No GitHub, acesse a organização do GitHub usada para o teste de instalação.
Selecione Segurança>Campanhas>Crie uma campanha a partir de filtros de verificação de código.
Crie a campanha a seguir. Esta campanha mostra alertas abertos com gravidade média em que a imagem implantada do repositório está vinculada a um recurso crítico. Seu repositório de testes deve ser detectado dentro desta campanha.
Selecione Salvar e , em seguida, Publicar como campanha.
Insira as informações necessárias e, em seguida, publique a campanha.
Etapa 5: Avaliar o código para recomendações de nuvem
Use a experiência do SDLC da Recomendação C2C e o enriquecimento dos alertas de segurança para entender o status dos problemas de segurança e atribuir as recomendações para resolução à equipe de engenharia adequada, com a ajuda da conexão entre alertas de segurança Dependabot e CVEs correspondentes na guia Recomendação de Runtime CVE Associada.
Exibir as recomendações do C2C
- No portal do MDC, vá para a guia Recomendações .
- Pesquise o nome do contêiner que você criou e abra uma das recomendações que diz: **Atualizar ***.
- Se você usou o repositório de exemplo, procure: Atualizar a recomendação de expansão de colchetes.
- Vá para a guia Insights de Remediação e visualize o diagrama de código para a nuvem.
- O diagrama mapeia seu contêiner em execução, para a imagem de contêiner no repositório de código, para o repositório de código de origem no GitHub.
Enriquecimento bidirecional
Selecione a guia CVEs associados . Observe que alguns CVEs têm um link na coluna Alertas do GitHub relacionados.
Selecione o link Exibir no GitHub para abrir o alerta de segurança do GHAS relevante.
Mobilização de engenharia
Para fechar o loop entre as equipes de Segurança e Engenharia, você pode criar um problema do GitHub para um aplicativo em contêiner priorizando para a equipe de engenharia os problemas de segurança nos quais eles devem se concentrar. Essa priorização pode incluir a transmissão de descobertas que o GHAS não detectou, mas que o MDC identificou para CVEs que não fazem parte de dependências diretas, como vulnerabilidades na imagem de base, no sistema operacional ou em softwares de terceiros, como o NGINX.
O problema no GitHub é gerado automaticamente com todas as CVEs encontradas no escopo da recomendação; as versões com e sem alertas do Dependabot correspondem, incluindo outros contextos de tempo de execução no repositório de origem.
Quando você atribui o problema, o status do problema é atualizado no portal do MDC.
Correções de agentes
No lado do GitHub, se você tiver uma licença do GitHub Copilot, poderá resolver o problema com a ajuda do GitHub Coding Agent:
- Atribua o GitHub Coding Agent ao problema.
- Examine a correção gerada.
- Se parecer razoável, aplique a correção.
- Observe a atualização do status do problema no MDC para Closed.