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 fornece etapas de configuração para um projeto de sandbox que ajuda você a avaliar a Segurança Avançada do GitHub (GHAS) e a integração de ponta a ponta da Microsoft Defender para Nuvem com um caso de uso simples.
A integração do GHAS e do Microsoft Defender para Nuvem ajuda a maximizar a segurança de aplicações nativas da nuvem da Microsoft ao correlacionar riscos e contexto em tempo de execução com o código originado para uma remediação mais rápida e baseada em IA.
Seguindo este guia, você:
- Configure seu repositório GitHub para cobertura do Defender para Nuvem.
- Crie um fator de risco de tempo de execução.
- Vincular código a recursos de runtime.
- Teste casos reais de uso no Defender para Nuvem.
Pré-requisitos
| Aspect | Detalhes |
|---|---|
| Requisitos ambientais | – Conta do GitHub com um conector criado no Defender para Nuvem - Licença do GHAS - Gerenciamento de Postura de Segurança na Nuvem do Defender (DCSPM) habilitado na assinatura - Microsoft Security Copilot (opcional para correção automatizada) |
| Funções e permissões | - Permissões de administrador de segurança – Administrador de segurança na assinatura Azure (para exibir as descobertas no Defender para Nuvem) – Proprietário da organização do GitHub |
| Ambientes de nuvem | Disponível apenas em nuvens comerciais (não em Azure Governamental, Azure operados pela 21Vianet 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 o repositório de exemplo do GitHub Sandbox que já tem todo o conteúdo para criar uma imagem de contêiner vulnerável.
Antes de configurar um repositório, verifique se:
- Defina um conector para a organização GitHub que você planeja usar no portal do Defender para Nuvem. Siga as etapas em Conectar seu ambiente do GitHub ao Microsoft Defender para Nuvem.
- Configure a verificação de código sem agente para seu conector GitHub. Siga as etapas em Configurar a verificação de código sem agente (versão prévia).
- Use um repositório privado para a integração.
- Clone o seguinte repositório em sua organização de GitHub:
- https://github.com/build25-woodgrove/mdc-customer-playbook Este repositório tem o GHAS habilitado e está incorporado a um locatário Azure que está com GPSN do Defender habilitado.
No repositório, siga estas etapas:
- Vá para Configurações.
- No painel esquerdo, selecione Segredos e variáveis > Ações. Em seguida, selecione Novo segredo do repositório.
- Adicione os seguintes segredos no nível do repositório ou da organização:
| Variável | Descrição |
|---|---|
| ACR_ENDPOINT | O servidor de autenticação do registro de contêiner. |
| ACR_USERNAME | O nome de usuário do registro de contêiner. |
| ACR_PASSWORD | A senha para o registro de contêiner. |
Note
Você pode escolher qualquer nome para essas variáveis. Eles não precisam seguir um padrão específico.
Você pode encontrar o servidor de autenticação do registro de contêineres, nome de usuário e senha no portal do Azure seguindo estes passos:
- Selecione o registro de contêiner no qual você deseja implantar.
- Em Configurações, selecione chaves de acesso.
- O painel de chaves do Access mostra as chaves do servidor de autenticação, nome de usuário e senha.
No repositório, selecione Ações, selecione o fluxo de trabalho Compilar e Enviar por Push para o ACR e, em seguida, selecione Executar fluxo de trabalho.
Confirme se a imagem foi implantada no registro de containers. Para o repositório de exemplo, a imagem deve estar em um registro chamado mdc-mock-0001 com a marca mdc-ghas-integration.
Implante a mdc-mock-0001:mdc-ghas-integration imagem como um contêiner em execução no seu cluster. Uma forma de implantar a imagem do container no seu cluster é conectando-se ao cluster e usando o kubectl run comando. Aqui está um exemplo para o AKS (Serviço de Kubernetes do Azure):
Defina a assinatura do cluster:
az account set --subscription $subscriptionID
Defina as credenciais para o cluster:
az aks get-credentials --resource-group $resourceGroupName --name $kubernetesClusterName --overwrite-existing
Implante a imagem:
kubectl run $containerName --image=$registryName.azurecr.io/mdc-mock-0001:mdc-ghas-integration
Etapa 2: Criar o fator de risco de exemplo (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 como comercialmente críticos.
- No portal do Defender para Nuvem, vá para Configurações de Ambiente>Criticidade de recurso.
- No painel direito, selecione o link para abrir o Microsoft Defender.
- Selecione Criar uma nova classificação.
- Insira um nome e uma descrição.
- No construtor de consultas, selecione Recurso em nuvem. Escreva uma consulta para definir o Nome do Recurso igual ao nome do contêiner que você implantou no cluster para validação. Em seguida, 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 um tipo de ativo de K8s-container ou K8s-pod. Mesmo que o nome ainda não esteja visível, continue com a próxima etapa.
- Escolha um nível de criticidade e examine e envie sua regra de classificação.
Note
O Microsoft Defender aplica o rótulo de criticidade ao contêiner depois que ele detecta o contêiner. Esse processo pode levar até 24 horas.
Etapa 3: validar se o ambiente está pronto
A validação confirma que seu ambiente está configurado corretamente para exibir o código para recomendações de runtime e gerar resultados acionáveis.
Durante a validação, o Defender verifica o código completo para a visibilidade em tempo de execução.
- Microsoft Defender para Nuvem monitora continuamente os repositórios de código-fonte para vulnerabilidades de segurança.
- Artefatos de compilação, como imagens de contêiner, são verificados em registros de contêineres antes da implantação.
- Cargas de trabalho de runtime implantadas em clusters do Kubernetes são monitoradas para riscos de segurança.
- Defender para Nuvem correlaciona e rastreia cada artefato desde o código, passando pela construção e implantação, até o tempo de execução e de volta.
Note
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 identifica o repositório.
Vá para o Cloud Security Explorer e execute as consultas de validação descritas na lista a seguir. Essas consultas de validação testam se o Defender consegue identificar artefatos produzidos pelos seus pipelines e cargas de trabalho. Se as consultas retornarem resultados, isso indicará que a verificação e a correlação estão funcionando conforme o esperado.
Note
Se nenhum resultado for retornado, poderá indicar que os artefatos não foram gerados ainda, o escaneamento não está configurado ou as permissões não estão disponíveis.
- Valide se o Defender para Nuvem (no Registro de Contêiner do Azure) 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 se o contêiner está em execução e se o Defender para Nuvem examinou o cluster do AKS.
- Valide se os fatores de risco estão configurados corretamente no lado do Defender para Nuvem. Pesquise o nome do contêiner na página de inventário do Defender para Nuvem e você deverá vê-lo marcado como crítico.
Note
Validar a configuração dos fatores de risco só é necessária se os fatores de risco não estiverem configurados no seu ambiente.
A validação bem-sucedida garante que as etapas subsequentes, como recomendações, campanhas e geração de problemas GitHub, produzam resultados significativos.