Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
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:
- Defina um conector para a organização GitHub que planeia usar no portal Defender para a Cloud. Siga os passos em Ligue o seu ambiente de GitHub ao Microsoft Defender para a Cloud.
- Configura a varredura de código sem agente para o teu conector GitHub. Siga os passos em Configurar a análise de código sem agente (pré-visualização).
- Use um repositório privado para a integração.
- Clone o seguinte repositório para a sua organização GitHub:
- https://github.com/build25-woodgrove/mdc-customer-playbook Este repositório tem o GHAS ativado e está integrado num locatário Azure que tem o GPSC do Defender ativado.
No repositório, siga estes passos:
- Vá para Configurações.
- No painel esquerdo, selecione Segredos e variáveis > Ações. Depois seleciona o segredo do novo repositório.
- 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:
- Selecione o registo de contentores onde quer implementar.
- Em Definições, selecione Teclas de Acesso.
- 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.
- No portal Defender para a Cloud, vá a Definições do Ambiente>Criticidade de Recursos.
- No painel direito, selecione o link para abrir o Microsoft Defender.
- Selecionar Criar uma nova classificação.
- Introduza um nome e descrição.
- 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.
- 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.
- 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.