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 artigo lista as recomendações que pode encontrar no Microsoft Defender para a Cloud se ligar um ambiente Azure DevOps, GitHub ou GitLab usando a página de definições do Ambiente.
As recomendações que aparecem em seu ambiente são baseadas nos recursos que você está protegendo e em sua configuração personalizada. Pode ver as recomendações no portal que se aplicam aos seus recursos.
Para saber sobre as ações que pode tomar em resposta a estas recomendações, consulte as recomendações Remediate em Defender para a Cloud.
Saiba mais sobre os benefícios e funcionalidades de segurança do DevOps .
As recomendações DevOps não afetam a tua pontuação segura. Para decidir quais as recomendações a resolver primeiro, analise a gravidade de cada recomendação e o seu potencial impacto na sua pontuação de segurança.
Azure DevOps recomendações
Os repositórios Azure DevOps devem ter o GitHub Advanced Security for Azure DevOps (GHAzDO) ativado
Descrição: A segurança DevOps no Defender para a Cloud utiliza uma consola central para capacitar as equipas de segurança a capacidade de proteger aplicações e recursos do código para a cloud através do Azure DevOps. Com a habilitação dos repositórios GitHub Advanced Security for Azure DevOps (GHAzDO), incluindo o GitHub Advanced Security for Azure DevOps, obtém descobertas sobre segredos, dependências e vulnerabilidades de código nos seus repositórios Azure DevOps em Microsoft Defender para a Cloud.
Gravidade: Alta
Os repositórios Azure DevOps devem ter as descobertas secretas de análise resolvidas
Descrição: Segredos foram encontrados em repositórios de código. Remediar imediatamente para evitar uma violação de segurança. Segredos encontrados em repositórios podem ser divulgados ou descobertos por adversários, levando ao comprometimento de uma aplicação ou serviço. A ferramenta de análise de credenciais DevOps da Microsoft Security apenas digitaliza as builds em que está configurada para correr. Portanto, os resultados podem não refletir o status completo dos segredos em seus repositórios.
Gravidade: Alta
Os repositórios do Azure DevOps devem ter as conclusões da análise de código resolvidas
Descrição: Foram encontradas vulnerabilidades em repositórios de código. Para melhorar a postura de segurança dos repositórios, é altamente recomendável corrigir essas vulnerabilidades.
Gravidade: Média
Os repositórios Azure DevOps devem ter resolvidas as conclusões da análise de vulnerabilidades de dependência
Descrição: Vulnerabilidades de dependência encontradas em repositórios de código. Para melhorar a postura de segurança dos repositórios, é altamente recomendável corrigir essas vulnerabilidades.
Gravidade: Média
Os repositórios Azure DevOps devem ter infraestrutura à medida que as conclusões da análise de código são resolvidas
Descrição: Problemas de configuração de segurança da infraestrutura como código encontrados em repositórios. Os problemas foram detetados em ficheiros modelo. Para melhorar a postura de segurança dos recursos de nuvem relacionados, é altamente recomendável corrigir esses problemas.
Gravidade: Média
Os pipelines Azure DevOps não deveriam ter segredos disponíveis para builds de forks
Descrição: Em repositórios públicos, é possível que pessoas de fora da organização criem forks e executem builds no repositório forkado. Nesse caso, se esta configuração estiver ativada, os externos podem aceder a segredos de pipeline de construção que deveriam ser internos.
Gravidade: Alta
As conexões de serviço Azure DevOps não devem conceder acesso a todos os pipelines
Descrição: As ligações de serviço são usadas para criar ligações do Azure Pipelines para serviços externos e remotos para executar tarefas num trabalho. As permissões do pipeline controlam quais os pipelines autorizados a usar a ligação de serviço. Para suportar a segurança das operações do oleoduto, as ligações de serviço não devem ter acesso a todos os pipelines YAML. Isto ajuda a manter o princípio do menor privilégio porque uma vulnerabilidade em componentes usados por um pipeline pode ser usada por um atacante para atacar outros pipelines com acesso a recursos críticos.
Gravidade: Alta
Os ficheiros seguros do Azure DevOps não devem conceder acesso a todos os pipelines
Descrição: Ficheiros seguros dão aos programadores uma forma de armazenar ficheiros que podem ser partilhados entre pipelines. Estes ficheiros são normalmente usados para armazenar segredos como certificados de assinatura e chaves SSH. Se um ficheiro seguro receber acesso a todos os pipelines YAML, um utilizador não autorizado pode roubar informação dos ficheiros seguros construindo um pipeline YAML e acedendo ao ficheiro seguro.
Gravidade: Alta
Grupos de variáveis do Azure DevOps com variáveis secretas não devem conceder acesso a todos os pipelines
Descrição: Os grupos de variáveis armazenam valores e segredos que poderá querer que sejam passados para um pipeline YAML ou disponibilizados em múltiplos pipelines. Pode partilhar e usar grupos de variáveis em múltiplos pipelines no mesmo projeto. Se um grupo de variáveis contendo segredos for marcado como acessível a todos os pipelines YAML, então um atacante pode explorar os ativos envolvendo as variáveis secretas criando um novo pipeline.
Gravidade: Alta
As conexões de serviço Azure DevOps Classic Azure não devem ser usadas para aceder a uma subscrição
Descrição: Use o tipo de ligações de serviço Azure Resource Manager (ARM) em vez das ligações de serviço Azure Classic para se ligar às subscrições do Azure. O modelo ARM oferece múltiplas melhorias de segurança, incluindo controlo de acesso mais forte, auditoria melhorada, implementação/governança baseada em ARM, acesso a identidades geridas e ao cofre de chaves para segredos, autenticação baseada em permissões Entra e suporte para etiquetas e grupos de recursos para uma gestão simplificada.
Gravidade: Média
(Pré-visualização) Os repositórios do Azure DevOps devem ter as conclusões dos testes de segurança da API resolvidas
Descrição: Vulnerabilidades de segurança de API encontradas em repositórios de código. Para melhorar a postura de segurança dos repositórios, é altamente recomendável corrigir essas vulnerabilidades.
Gravidade: Média
(Pré-visualização) Os repositórios Azure DevOps devem exigir pelo menos aprovação de dois revisores para os push de código
Descrição: Para evitar que alterações não intencionais ou maliciosas sejam diretamente comprometidas, é importante implementar políticas de proteção para o branch padrão nos repositórios Azure DevOps. Recomendamos exigir que pelo menos dois revisores de código aprovem pull requests antes de o código ser fundido com o branch padrão. Ao exigir aprovação de um número mínimo de dois revisores, pode reduzir o risco de modificações não autorizadas, que podem levar a instabilidade do sistema ou vulnerabilidades de segurança.
Esta recomendação é fornecida na postura fundamental de segurança do Defender para a Cloud, caso tenha ligado o Azure DevOps ao Defender para a Cloud.
Gravidade: Alta
(Pré-visualização) Os repositórios Azure DevOps não devem permitir que os requerentes aprovem os seus próprios Pull Requests
Descrição: Para evitar que alterações não intencionais ou maliciosas sejam diretamente comprometidas, é importante implementar políticas de proteção para o branch padrão nos repositórios Azure DevOps. Recomendamos proibir os criadores de pull requests de aprovarem as suas próprias submissões para garantir que cada alteração seja reconhecida objetivamente por alguém que não seja o autor. Ao fazer isto, pode reduzir o risco de modificações não autorizadas, que podem levar a instabilidade do sistema ou vulnerabilidades de segurança.
Esta recomendação é fornecida na postura fundamental de segurança do Defender para a Cloud, caso tenha ligado o Azure DevOps ao Defender para a Cloud.
Gravidade: Alta
(Pré-visualização) Os projetos Azure DevOps devem ter a criação de pipelines clássicos desativada
Descrição: Desativar a criação de pipelines clássicos de build e release evita uma preocupação de segurança que decorrente do YAML e dos pipelines classic partilharem os mesmos recursos, por exemplo, as mesmas ligações de serviço. Potenciais atacantes podem aproveitar pipelines clássicos para criar processos que eludem os mecanismos de defesa típicos configurados em torno dos pipelines YAML modernos.
Gravidade: Alta
Recomendações do GitHub
As organizações do GitHub não devem tornar os segredos de ação acessíveis a todos os repositórios
Descrição: Para segredos usados nos fluxos de trabalho do GitHub Action que são armazenados ao nível da organização do GitHub, pode usar políticas de acesso para controlar quais repositórios podem usar segredos organizacionais. Os segredos ao nível da organização permitem-lhe partilhar segredos entre múltiplos repositórios. Isto reduz a necessidade de criar segredos duplicados. No entanto, uma vez que um segredo é tornado acessível a um repositório, qualquer pessoa com acesso de escrita no repositório pode aceder ao segredo a partir de qualquer branch num fluxo de trabalho. Para reduzir a superfície de ataque, certifique-se de que o segredo é acessível apenas a partir de repositórios selecionados.
Esta recomendação é fornecida na postura fundamental de segurança do Defender para a Cloud, caso tenha ligado o Azure DevOps ao Defender para a Cloud.
Gravidade: Alta
Os repositórios do GitHub devem ter a varredura secreta ativada
Description: GitHub analisa repositórios à procura de tipos conhecidos de segredos, para evitar o uso fraudulento de segredos que tenham sido acidentalmente enviados para repositórios. A varredura de segredos irá analisar todo o histórico Git em todos os ramos presentes no repositório do GitHub à procura de quaisquer segredos. Exemplos de segredos são tokens e chaves privadas que um provedor de serviços pode emitir para autenticação. Se um segredo for verificado em um repositório, qualquer pessoa que tenha acesso de leitura ao repositório poderá usá-lo para acessar o serviço externo com esses privilégios. Os segredos devem ser armazenados em um local dedicado e seguro fora do repositório do projeto.
Gravidade: Alta
Os repositórios do GitHub devem ter a análise de código ativada
Description: GitHub utiliza varredura de código para analisar o código e encontrar vulnerabilidades e erros de segurança no código. A verificação de código pode ser usada para localizar, triar e priorizar correções para problemas existentes em seu código. A verificação de código também pode impedir que os desenvolvedores introduzam novos problemas. As verificações podem ser agendadas para dias e horários específicos, ou podem ser acionadas quando ocorre um evento específico no repositório, como um push. Se a análise de código encontrar uma potencial vulnerabilidade ou erro no código, o GitHub apresenta um alerta no repositório. Uma vulnerabilidade é um problema no código de um projeto que pode ser explorado para danificar a confidencialidade, integridade ou disponibilidade do projeto.
Gravidade: Média
Os repositórios do GitHub devem ter a análise do Dependabot ativada
Description: GitHub envia alertas do Dependabot quando deteta vulnerabilidades em dependências de código que afetam repositórios. Uma vulnerabilidade é um problema no código de um projeto que pode ser explorado para danificar a confidencialidade, integridade ou disponibilidade do projeto ou de outros projetos que usam seu código. As vulnerabilidades variam em tipo, gravidade e método de ataque. Quando o código depende de um pacote que tem uma vulnerabilidade de segurança, essa dependência vulnerável pode causar uma série de problemas.
Gravidade: Média
Os repositórios do GitHub deveriam ter resolvido os resultados de análise secreta
Descrição: Segredos encontrados em repositórios de código. Esta situação deve ser corrigida imediatamente para evitar uma violação da segurança. Segredos encontrados em repositórios podem ser vazados ou descobertos por adversários, levando ao comprometimento de um aplicativo ou serviço.
Gravidade: Alta
Os repositórios do GitHub devem ter as conclusões da análise de código resolvidas
Descrição: Vulnerabilidades encontradas em repositórios de código. Para melhorar a postura de segurança dos repositórios, é altamente recomendável corrigir essas vulnerabilidades.
Gravidade: Média
Os repositórios do GitHub devem ter resolvidas as conclusões da análise de vulnerabilidades de dependências
Descrição: Os repositórios do GitHub devem ter resolvido os resultados da análise de vulnerabilidades de dependências.
Gravidade: Média
Os repositórios do GitHub devem ter infraestrutura à medida que as conclusões de análise de código resolvem
Descrição: Problemas de configuração de segurança de infraestrutura como código foram encontrados em repositórios. Os problemas foram detetados em ficheiros modelo. Para melhorar a postura de segurança dos recursos de nuvem relacionados, é altamente recomendável corrigir esses problemas.
Gravidade: Média
Os repositórios do GitHub devem ter políticas de proteção para branch padrão ativadas
Descrição: O branch padrão do repositório deve ser protegido através de políticas de proteção de branch para evitar que alterações não intencionais/maliciosas sejam diretamente comprometidas no repositório.
Gravidade: Alta
Os repositórios do GitHub deveriam ter os push forçados para o branch padrão desativados
Descrição: Como o branch padrão é normalmente usado para deployment e outras atividades privilegiadas, quaisquer alterações devem ser abordadas com cautela. Ativar forças push pode introduzir alterações não intencionais ou maliciosas ao ramo predefinido.
Gravidade: Média
As organizações do GitHub devem ter ativada a proteção contra push por varredura secreta
Descrição: A Proteção Push bloqueia commits que contenham segredos, prevenindo assim a exposição acidental de segredos. Para evitar o risco de exposição de credenciais, a Proteção Push deve ser ativada automaticamente para todos os repositórios com digitalização secreta.
Gravidade: Alta
Os repositórios do GitHub não devem usar runners auto-hospedados
Descrição: Self-Hosted Os Runners em GitHub não têm garantias de funcionamento em máquinas virtuais limpas e efémeras e podem ser persistentemente comprometidos por código não confiável num fluxo de trabalho. Assim, Self-Hosted Runners não devem ser utilizados para fluxos de trabalho de ações.
Gravidade: Alta
As organizações do GitHub devem ter as permissões de fluxo de trabalho de ações definidas para apenas leitura
Descrição: Por defeito, os fluxos de trabalho de Ação devem receber permissões apenas de leitura para evitar que utilizadores maliciosos explorem fluxos de trabalho sobre-autorizados para aceder e manipular recursos.
Gravidade: Alta
As organizações GitHub devem ter mais do que uma pessoa com permissões de administrador
Descrição: Ter pelo menos dois administradores reduz o risco de perder o acesso de administrador. Isto é útil em situações de contas de quebra-vidro.
Gravidade: Alta
As organizações do GitHub devem ter permissões base definidas como sem permissões ou leitura
Descrição: As permissões base devem ser definidas como zero ou lidas para que uma organização siga o princípio do privilégio mínimo e evite acessos desnecessários.
Gravidade: Alta
(Pré-visualização) Os repositórios do GitHub devem ter conclusões resolvidas dos testes de segurança da API
Descrição: Foram encontradas vulnerabilidades de segurança de API em repositórios de código. Para melhorar a postura de segurança dos repositórios, é altamente recomendável corrigir essas vulnerabilidades.
Gravidade: Média
(Pré-visualização) As organizações do GitHub não devem tornar os segredos de ação acessíveis a todos os repositórios
Descrição: Para segredos usados nos fluxos de trabalho do GitHub Action que são armazenados ao nível da organização do GitHub, pode usar políticas de acesso para controlar quais repositórios podem usar segredos da organização. Os segredos ao nível da organização permitem partilhar segredos entre múltiplos repositórios, reduzindo a necessidade de criar segredos duplicados. No entanto, quando um segredo é tornado acessível a um repositório, qualquer pessoa com acesso de escrita no repositório pode aceder ao segredo a partir de qualquer branch num fluxo de trabalho. Para reduzir a superfície de ataque, certifique-se de que o segredo é acessível apenas a partir de repositórios selecionados.
Gravidade: Alta
(Pré-visualização) As organizações do GitHub devem bloquear sugestões do sugestões do Copilot que correspondam ao código público
Descrição: Ativar o filtro do GitHub Copilot para bloquear sugestões de código que correspondam ao código público no GitHub melhora a segurança e a conformidade legal. Previne a incorporação não intencional de código público ou de código aberto, reduzindo o risco de problemas legais e garantindo o cumprimento dos termos de licenciamento. Além disso, ajuda a evitar a introdução de potenciais vulnerabilidades de código público nos projetos da organização, mantendo assim uma qualidade e segurança superiores do código. Quando o filtro está ativado, o GitHub Copilot verifica as sugestões de código com o seu código envolvente de cerca de 150 caracteres contra código público no GitHub. Se houver uma correspondência ou quase, a sugestão não será mostrada.
Gravidade: Alta
(Pré-visualização) As organizações do GitHub devem impor autenticação multifator para colaboradores externos
Descrição: A aplicação da autenticação multifator para colaboradores externos numa organização GitHub é uma medida de segurança que exige que os colaboradores utilizem uma forma adicional de identificação além da palavra-passe para aceder aos repositórios e recursos da organização. Isto reforça a segurança ao proteger contra acessos não autorizados, mesmo que uma palavra-passe seja comprometida, e ajuda a garantir a conformidade com os padrões do setor. Envolve informar os colaboradores sobre a necessidade e prestar apoio para a transição, reduzindo, em última análise, o risco de violações de dados.
Gravidade: Alta
(Pré-visualização) Os repositórios do GitHub devem exigir aprovação mínima de dois revisores para os push de código
Descrição: Para evitar que alterações não intencionais ou maliciosas sejam diretamente comprometidas, é importante implementar políticas de proteção para o ramo padrão nos repositórios do GitHub. Recomendamos exigir que pelo menos dois revisores de código aprovem pull requests antes de o código ser fundido com o branch padrão. Ao exigir aprovação de um número mínimo de dois revisores, pode reduzir o risco de modificações não autorizadas, que podem levar a instabilidade do sistema ou vulnerabilidades de segurança.
Gravidade: Alta
Recomendações do GitLab
Os projetos do GitLab devem ter descobertos de análise secreta resolvidos
Descrição: Segredos foram encontrados em repositórios de código. Esta situação deve ser corrigida imediatamente para evitar uma violação da segurança. Segredos encontrados em repositórios podem ser vazados ou descobertos por adversários, levando ao comprometimento de um aplicativo ou serviço.
Gravidade: Alta
Os projetos no GitLab devem ter conclusões de análise de código resolvidas
Descrição: Foram encontradas vulnerabilidades em repositórios de código. Para melhorar a postura de segurança dos repositórios, é altamente recomendável corrigir essas vulnerabilidades.
Gravidade: Média
Os projetos no GitLab devem ter as conclusões de análise de vulnerabilidades de dependência resolvidas
Descrição: Os repositórios do GitHub devem ter resolvido os resultados da análise de vulnerabilidades de dependências.
Gravidade: Média
Os projetos do GitLab devem ter infraestrutura à medida que as conclusões de análise de código são resolvidas
Descrição: Problemas de configuração de segurança de infraestrutura como código foram encontrados em repositórios. Os problemas apresentados foram detetados em ficheiros modelo. Para melhorar a postura de segurança dos recursos de nuvem relacionados, é altamente recomendável corrigir esses problemas.
Gravidade: Média
Recomendações de segurança DevOps obsoletas
Os repositórios de código devem ter as descobertas de varredura de código resolvidas
Descrição: A segurança DevOps no Defender para a Cloud encontrou vulnerabilidades em repositórios de código. Para melhorar a postura de segurança dos repositórios, é altamente recomendável corrigir essas vulnerabilidades. (Nenhuma política relacionada)
Gravidade: Média
Os repositórios de código devem ter as descobertas de varredura secretas resolvidas
Descrição: A segurança DevOps no Defender para a Cloud encontrou um segredo nos repositórios de código. Esta situação deve ser corrigida imediatamente para evitar uma violação da segurança. Segredos encontrados em repositórios podem ser vazados ou descobertos por adversários, levando ao comprometimento de um aplicativo ou serviço. Para Azure DevOps, a ferramenta Microsoft Security DevOps CredScan apenas analisa as versões em que foi configurada para correr. Portanto, os resultados podem não refletir o status completo dos segredos em seus repositórios. (Nenhuma política relacionada)
Gravidade: Alta
Os repositórios de código devem ter as descobertas de varredura do Dependabot resolvidas
Descrição: A segurança DevOps no Defender para a Cloud encontrou vulnerabilidades em repositórios de código. Para melhorar a postura de segurança dos repositórios, é altamente recomendável corrigir essas vulnerabilidades. (Nenhuma política relacionada)
Gravidade: Média
Os repositórios de código devem ter infraestrutura à medida que os resultados da varredura de código forem resolvidos
Descrição: A segurança DevOps no Defender para a Cloud encontrou problemas de configuração de segurança de infraestrutura como código nos repositórios. Os problemas apresentados foram detetados em ficheiros modelo. Para melhorar a postura de segurança dos recursos de nuvem relacionados, é altamente recomendável corrigir esses problemas. (Nenhuma política relacionada)
Gravidade: Média
Os repositórios do GitHub devem ter a análise de código ativada
Description: GitHub utiliza varredura de código para analisar o código e encontrar vulnerabilidades e erros de segurança no código. A verificação de código pode ser usada para localizar, triar e priorizar correções para problemas existentes em seu código. A verificação de código também pode impedir que os desenvolvedores introduzam novos problemas. As verificações podem ser agendadas para dias e horários específicos, ou podem ser acionadas quando ocorre um evento específico no repositório, como um push. Se a análise de código encontrar uma potencial vulnerabilidade ou erro no código, o GitHub apresenta um alerta no repositório. Uma vulnerabilidade é um problema no código de um projeto que pode ser explorado para danificar a confidencialidade, integridade ou disponibilidade do projeto. (Nenhuma política relacionada)
Gravidade: Média
Os repositórios do GitHub devem ter a varredura secreta ativada
Description: GitHub analisa repositórios à procura de tipos conhecidos de segredos, para evitar o uso fraudulento de segredos que tenham sido acidentalmente enviados para repositórios. A varredura de segredos irá analisar todo o histórico Git em todos os ramos presentes no repositório do GitHub à procura de quaisquer segredos. Exemplos de segredos são tokens e chaves privadas que um provedor de serviços pode emitir para autenticação. Se um segredo for verificado em um repositório, qualquer pessoa que tenha acesso de leitura ao repositório poderá usá-lo para acessar o serviço externo com esses privilégios. Os segredos devem ser armazenados em um local dedicado e seguro fora do repositório do projeto. (Nenhuma política relacionada)
Gravidade: Alta
Os repositórios do GitHub devem ter a análise do Dependabot ativada
Description: GitHub envia alertas do Dependabot quando deteta vulnerabilidades em dependências de código que afetam repositórios. Uma vulnerabilidade é um problema no código de um projeto que pode ser explorado para danificar a confidencialidade, integridade ou disponibilidade do projeto ou de outros projetos que usam seu código. As vulnerabilidades variam em tipo, gravidade e método de ataque. Quando o código depende de um pacote que tem uma vulnerabilidade de segurança, essa dependência vulnerável pode causar uma série de problemas. (Nenhuma política relacionada)
Gravidade: Média