Recomendações de segurança para recursos de DevOps
Este artigo lista as recomendações que você poderá ver no Microsoft Defender para Nuvem se conectar um ambiente do Azure DevOps, GitHub ou GitLab usando a página Configuraçõ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.
Para saber mais sobre as ações que você pode tomar em resposta a essas recomendações, consulte Corrigir recomendações no Defender para Nuvem.
Saiba mais sobre os benefícios e recursos do segurança do DevOps.
As recomendações de DevOps não afetam sua classificação de segurança. Para decidir quais recomendações resolver primeiro, observe a gravidade de cada recomendação e seu impacto potencial em sua classificação de segurança.
Recomendações do Azure DevOps
Os repositórios do Azure DevOps devem ter o GitHub Advanced Security para Azure DevOps (GHAzDO) habilitado
Descrição: a segurança do DevOps no Defender para Nuvem usa um console central para capacitar as equipes de segurança com a capacidade de proteger aplicativos e recursos do código para a nuvem no Azure DevOps. Com a habilitação dos repositórios do GitHub Advanced Security for Azure DevOps (GHAzDO), incluindo o GitHub Advanced Security for Azure DevOps, você obtém descobertas sobre segredos, dependências e vulnerabilidades de código em seus repositórios do Azure DevOps exibidos no Microsoft Defender para Nuvem.
Gravidade: Alta
Os repositórios do Azure DevOps devem ter os resultados da verificação de segredo resolvidos
Descrição: foram encontrados segredos em repositórios de código. Corrija imediatamente para evitar uma violação de segurança. Os segredos encontrados nos repositórios podem vazar ou ser descobertos por adversários, levando ao comprometimento de um aplicativo ou serviço. A ferramenta de verificação de credenciais do Microsoft Security DevOps verifica apenas as compilações nas quais está configurada para execução. Portanto, os resultados podem não refletir o status completo dos segredos nos seus repositórios.
Gravidade: Alta
Os repositórios do Azure DevOps devem ter os resultados da verificação de código resolvidos
Descrição: foram encontradas vulnerabilidades em repositórios de código. Para aprimorar a postura de segurança dos repositórios, é altamente recomendável corrigir essas vulnerabilidades.
Gravidade: Média
Os repositórios do Azure DevOps devem ter os resultados da verificação de vulnerabilidade de dependência resolvidos
Descrição: vulnerabilidades de dependência encontradas em repositórios de código. Para aprimorar a postura de segurança dos repositórios, é altamente recomendável corrigir essas vulnerabilidades.
Gravidade: Média
Os repositórios do Azure DevOps devem ter a infraestrutura como os resultados da verificação de código resolvidos
Descrição: problemas de configuração de segurança de infraestrutura como código encontrados em repositórios. Os problemas foram detectados em arquivos de modelo. Para aprimorar a postura de segurança dos recursos relacionados a nuvem, é altamente recomendável corrigir esses problemas.
Gravidade: Média
Os pipelines do Azure DevOps não devem ter segredos disponíveis para builds de bifurcações
Descrição: em repositórios públicos, é possível que pessoas de fora da organização criem bifurcações e executem compilações no repositório bifurcado. Nesse caso, se essa configuração estiver habilitada, os usuários externos poderão obter acesso aos segredos do pipeline de build que deveriam ser internos.
Gravidade: Alta
As conexões de serviço do Azure DevOps não devem conceder acesso a todos os pipelines
Descrição: as conexões de serviço são usadas para criar conexões do Azure Pipelines com serviços externos e remotos para executar tarefas em um trabalho. As permissões de pipeline controlam os pipelines que estão autorizados a usar a conexão de serviço. Para dar suporte à segurança das operações de pipeline, as conexões de serviço não devem receber acesso a todos os pipelines YAML. Isso ajuda a manter o princípio do privilégio mínimo, pois uma vulnerabilidade nos componentes usados por um pipeline pode ser usada por um invasor para atacar outros pipelines com acesso a recursos críticos.
Gravidade: Alta
Os arquivos seguros do Azure DevOps não devem conceder acesso a todos os pipelines
Descrição: os arquivos seguros oferecem aos desenvolvedores uma maneira de armazenar arquivos que podem ser compartilhados entre pipelines. Normalmente, esses arquivos são usados para armazenar segredos, como certificados de autenticação e chaves SSH. Se um arquivo seguro receber acesso a todos os pipelines YAML, um usuário não autorizado poderá roubar informações dos arquivos seguros criando um pipeline YAML e acessando o arquivo seguro.
Gravidade: Alta
Os 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 talvez você queira que sejam passados para um pipeline YAML ou disponibilizados em vários pipelines. Você pode compartilhar e usar grupos de variáveis em vários pipelines no mesmo projeto. Se um grupo de variáveis que contém segredos for marcado como acessível a todos os pipelines YAML, um invasor poderá explorar os ativos que envolvem as variáveis secretas criando um pipeline.
Gravidade: Alta
As conexões de serviço do Azure Clássico do Azure DevOps não devem ser usadas para acessar uma assinatura
Descrição: use o tipo de conexões de serviço do ARM (Azure Resource Manager) em vez de conexões de serviço clássico do Azure para se conectar a assinaturas do Azure. O modelo do ARM oferece vários aprimoramentos de segurança, incluindo controle de acesso mais forte, auditoria aprimorada, implantação/governança baseada em ARM, acesso a identidades gerenciadas e cofre de chaves para segredos, autenticação baseada nas Permissões do Entra e suporte a marcas e grupos de recursos, permitindo o gerenciamento simplificado.
Gravidade: Média
(Versão prévia) Azure DevOps repositórios devem ter as descobertas de teste de segurança de API resolvidas
Descrição: vulnerabilidades de segurança de API encontradas em repositórios de código. Para aprimorar a postura de segurança dos repositórios, é altamente recomendável corrigir essas vulnerabilidades.
Gravidade: Média
(Versão prévia) Os repositórios do Azure DevOps devem exigir no mínimo a aprovação de dois revisores para pushes de código
Descrição: para impedir que alterações não intencionais ou mal-intencionadas sejam confirmadas diretamente, é importante implementar políticas de proteção para o branch padrão em repositórios do Azure DevOps. É recomendável exigir que pelo menos dois revisores de código aprovem solicitações de pull antes que o código seja mesclado com o branch padrão. Ao exigir a aprovação de um número mínimo de dois revisores, você pode reduzir o risco de modificações não autorizadas, o que pode levar à instabilidade do sistema ou vulnerabilidades de segurança.
Essa recomendação é fornecida na postura de segurança básica do Defender para Nuvem, se você tiver conectado o Azure DevOps ao Defender para Nuvem.
Gravidade: Alta
(Versão prévia) Os repositórios do Azure DevOps não devem permitir que os solicitantes aprovem suas próprias solicitações de pull
Descrição: para impedir que alterações não intencionais ou mal-intencionadas sejam confirmadas diretamente, é importante implementar políticas de proteção para o branch padrão em repositórios do Azure DevOps. Recomendamos proibir os criadores de pull request de aprovar seus próprios envios para garantir que todas as alterações sejam submetidas a uma revisão objetiva por alguém que não seja o autor. Ao fazer isso, você pode reduzir o risco de modificações não autorizadas, o que pode levar à instabilidade do sistema ou vulnerabilidades de segurança.
Essa recomendação é fornecida na postura de segurança básica do Defender para Nuvem, se você tiver conectado o Azure DevOps ao Defender para Nuvem.
Gravidade: Alta
(Versão prévia) Os projetos do Azure DevOps devem ter a criação de pipelines clássicos desabilitada
Descrição: desabilitar a criação de pipelines clássicos de build e lançamento evita uma preocupação de segurança decorrente de pipelines YAML e clássicos que compartilham os mesmos recursos, por exemplo, as mesmas conexões de serviço. Os invasores em potencial podem aproveitar os pipelines clássicos para criar processos que evitam 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 em fluxos de trabalho do GitHub Action armazenados no nível da organização do GitHub, você pode usar políticas de acesso para controlar quais repositórios podem usar segredos organizacionais. Os segredos em nível de organização permitem que você compartilhe segredos entre vários repositórios. Isso reduz a necessidade de criar segredos duplicados. No entanto, depois que um segredo é disponibilizado para um repositório, qualquer pessoa com acesso de gravação no repositório pode acessar o segredo de qualquer branch em um fluxo de trabalho. Para reduzir a superfície de ataque, certifique-se de que o segredo esteja acessível somente a partir de repositórios selecionados.
Essa recomendação é fornecida na postura de segurança básica do Defender para Nuvem, se você tiver conectado o Azure DevOps ao Defender para Nuvem.
Gravidade: Alta
Os repositórios do GitHub devem ter a verificação de segredos habilitada
Descrição: o GitHub verifica repositórios em busca de tipos conhecidos de segredos, para evitar o uso fraudulento de segredos que foram acidentalmente confirmados em repositórios. A verificação de segredos examina automaticamente todo o histórico do Git em todos os branches presentes no seu repositório do GitHub em busca de segredos. Exemplos de segredos são tokens e chaves privadas que um provedor de serviços pode emitir para autenticação. Se um segredo é colocado em um repositório, qualquer pessoa que tenha acesso de leitura ao repositório pode usar o segredo 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 verificação de código habilitada
Descrição: o GitHub usa a varredura de código para analisar o código a fim de encontrar vulnerabilidades de segurança e erros no código. A verificação de código pode ser usada para localizar, fazer triagem e priorizar correções para problemas existentes no seu código. A verificação de código também pode impedir que os desenvolvedores introduzam novos problemas. As verificações podem ser programadas 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 verificação de código localiza uma possível vulnerabilidade ou um possível erro no código, o GitHub mostra um alerta no repositório. Uma vulnerabilidade é um problema no código de um projeto que pode ser explorado para corromper a confidencialidade, a integridade ou a disponibilidade do projeto.
Gravidade: Média
Os repositórios do GitHub devem ter a verificação do Dependabot habilitada
Descrição: o GitHub envia alertas do Dependabot quando detecta vulnerabilidades em dependências de código que afetam repositórios. Uma vulnerabilidade é um problema no código de um projeto que poderia ser explorada para corromper a confidencialidade, a integridade ou a disponibilidade do projeto ou de outros projetos que usam o código. As vulnerabilidades variam de 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 devem ter os resultados da verificação de segredo resolvidos
Descrição: segredos encontrados em repositórios de código. Isso deve ser corrigido imediatamente para evitar uma violação de segurança. Os segredos encontrados nos repositórios podem ser vazados ou descobertos por adversários, levando a um comprometimento de um aplicativo ou um serviço.
Gravidade: Alta
Os repositórios GitHub devem ter os resultados da verificação de código resolvidos
Descrição: vulnerabilidades encontradas em repositórios de código. Para aprimorar a postura de segurança dos repositórios, é altamente recomendável corrigir essas vulnerabilidades.
Gravidade: Média
Os repositórios do GitHub devem ter os resultados da verificação de vulnerabilidade de dependência resolvidos
Descrição: os repositórios do GitHub devem ter as descobertas de verificação de vulnerabilidades de dependência resolvidas.
Gravidade: Média
Os repositórios do GitHub devem ter a infraestrutura como os resultados da verificação de código resolvidos
Descrição: foram encontrados problemas de configuração de segurança de infraestrutura como código em repositórios. Os problemas foram detectados em arquivos de modelo. Para aprimorar a postura de segurança dos recursos relacionados a nuvem, é altamente recomendável corrigir esses problemas.
Gravidade: Média
Os repositórios GitHub devem ter as políticas de proteção para a ramificação padrão habilitadas
Descrição: o branch padrão do repositório deve ser protegido por meio de políticas de proteção de branch para impedir que alterações não intencionais/mal-intencionadas sejam confirmadas diretamente no repositório.
Gravidade: Alta
Os repositórios do GitHub devem ter os pushs forçados para a ramificação padrão desabilitados
Descrição: como o branch padrão normalmente é usado para implantação e outras atividades privilegiadas, todas as alterações nele devem ser abordadas com cuidado. Habilitar pushes forçados pode introduzir alterações não intencionais ou mal-intencionadas ao branch padrão.
Gravidade: Média
As organizações do GitHub devem ter a proteção de push de verificação de segredos habilitada
Descrição: a Proteção contra Push bloqueará confirmações que contenham segredos, evitando assim a exposição acidental de segredos. Para evitar o risco de exposição de credenciais, a proteção contra push deve ser habilitada automaticamente em cada repositório habilitado para a verificação de segredos.
Gravidade: Alta
Os repositórios GitHub não devem usar executores auto-hospedados
Descrição: os executores auto-hospedados no GitHub não têm garantias de operação em máquinas virtuais limpas efêmeras e podem ser comprometidos persistentemente por código não confiável em um fluxo de trabalho. Dessa forma, os executores auto-hospedados 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 como somente leitura
Descrição: por padrão, os fluxos de trabalho de ação devem receber permissões somente leitura para impedir que usuários mal-intencionados explorem fluxos de trabalho com permissão excessiva para acessar e adulterar recursos.
Gravidade: Alta
As organizações do GitHub devem ter mais de uma pessoa com permissões de administrador
Descrição: ter pelo menos dois administradores reduz o risco de perder o acesso de administrador. Isso é útil no caso de cenários de contas de emergência.
Gravidade: Alta
As organizações do GitHub devem ter permissões básicas definidas como sem permissões ou leitura
Descrição: as permissões básicas devem ser definidas como nenhuma ou lidas para que uma organização siga o princípio do menor privilégio e evite acesso desnecessário.
Gravidade: Alta
(Versão prévia) Os repositórios do GitHub devem ter os resultados dos testes de segurança da API resolvidos
Descrição: vulnerabilidades de segurança de API foram encontradas em repositórios de código. Para aprimorar a postura de segurança dos repositórios, é altamente recomendável corrigir essas vulnerabilidades.
Gravidade: Média
(Versão prévia) 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 em fluxos de trabalho do GitHub Action armazenados no nível da organização do GitHub, você pode usar políticas de acesso para controlar quais repositórios podem usar segredos da organização. Os segredos no nível da organização permitem que você compartilhe segredos entre vários repositórios, reduzindo a necessidade de criar segredos duplicados. No entanto, quando um segredo é disponibilizado para um repositório, qualquer pessoa com acesso de gravação no repositório pode acessar o segredo de qualquer branch em um fluxo de trabalho. Para reduzir a superfície de ataque, certifique-se de que o segredo esteja acessível somente a partir de repositórios selecionados.
Gravidade: Alta
(Versão prévia) As organizações do GitHub devem bloquear as sugestões do Copilot que correspondem ao código público
Descrição: habilitar o filtro do GitHub Copilot para bloquear sugestões de código que correspondam ao código público no GitHub aumenta a segurança e a conformidade legal. Ele evita a incorporação não intencional de código público ou aberto, reduzindo o risco de problemas legais e garantindo a adesão aos termos de licenciamento. Além disso, ajuda a evitar a introdução de possíveis vulnerabilidades de código público nos projetos da organização, mantendo assim maior qualidade e segurança do código. Quando o filtro está habilitado, o GitHub Copilot verifica as sugestões de código com o código ao redor de cerca de 150 caracteres em relação ao código público no GitHub. Se houver correspondência ou quase correspondência, a sugestão não será exibida.
Gravidade: Alta
(Versão prévia) As organizações do GitHub devem impor a autenticação multifator para colaboradores externos
Descrição: a aplicação da autenticação multifator para colaboradores externos em uma organização do GitHub é uma medida de segurança que exige que os colaboradores usem uma forma adicional de identificação além da senha para acessar os repositórios e recursos da organização. Isso aumenta a segurança, protegendo contra acesso não autorizado, mesmo que uma senha seja comprometida, e ajuda a garantir a conformidade com os padrões do setor. Envolve informar os colaboradores sobre o requisito e fornecer suporte para a transição, reduzindo o risco de violações de dados.
Gravidade: Alta
(Versão prévia) Os repositórios do GitHub devem exigir a aprovação mínima de dois revisores para pushes de código
Descrição: para impedir que alterações não intencionais ou mal-intencionadas sejam confirmadas diretamente, é importante implementar políticas de proteção para o branch padrão nos repositórios do GitHub. É recomendável exigir que pelo menos dois revisores de código aprovem solicitações de pull antes que o código seja mesclado com o branch padrão. Ao exigir a aprovação de um número mínimo de dois revisores, você pode reduzir o risco de modificações não autorizadas, o que pode levar à instabilidade do sistema ou vulnerabilidades de segurança.
Gravidade: Alta
Recomendações do GitLab
Os projetos no GitLab devem ter as descobertas de verificação de segredos resolvidas.
Descrição: foram encontrados segredos em repositórios de código. Isso deve ser corrigido imediatamente para evitar uma violação de segurança. Os segredos encontrados nos repositórios podem ser vazados ou descobertos por adversários, levando a um comprometimento de um aplicativo ou um serviço.
Gravidade: Alta
Os projetos do GitLab devem ter as descobertas de verificação de código resolvidas
Descrição: foram encontradas vulnerabilidades em repositórios de código. Para aprimorar a postura de segurança dos repositórios, é altamente recomendável corrigir essas vulnerabilidades.
Gravidade: Média
Os projetos do GitLab devem ter os resultados da verificação de vulnerabilidade de dependência resolvidos
Descrição: os repositórios do GitHub devem ter as descobertas de verificação de vulnerabilidades de dependência resolvidas.
Gravidade: Média
Os projetos do GitLab devem ter a infraestrutura como os resultados da verificação de código resolvidos
Descrição: foram encontrados problemas de configuração de segurança de infraestrutura como código em repositórios. Os problemas mostrados foram detectados em arquivos de modelo. Para aprimorar a postura de segurança dos recursos relacionados a nuvem, é altamente recomendável corrigir esses problemas.
Gravidade: Média
Recomendações de segurança de DevOps preteridas
As descobertas de verificação de código dos repositórios de código devem ser resolvidas
Descrição: a segurança do DevOps no Defender para Nuvem encontrou vulnerabilidades em repositórios de código. Para aprimorar a postura de segurança dos repositórios, é altamente recomendável corrigir essas vulnerabilidades. (Não há política relacionada)
Gravidade: Média
As descobertas de verificação de segredo dos repositórios de código devem ser resolvidas
Descrição: a segurança do DevOps no Defender para Nuvem encontrou um segredo nos repositórios de código. Isso deve ser corrigido imediatamente para evitar uma violação de segurança. Os segredos encontrados nos repositórios podem ser vazados ou descobertos por adversários, levando a um comprometimento de um aplicativo ou um serviço. Para o Azure DevOps, a ferramenta CredScan do DevOps de Segurança da Microsoft verifica apenas builds nos quais ela foi configurada para ser executada. Portanto, os resultados podem não refletir o status completo dos segredos nos seus repositórios. (Não há política relacionada)
Gravidade: Alta
As descobertas de verificação de Dependabot dos repositórios de código devem ser resolvidas
Descrição: a segurança do DevOps no Defender para Nuvem encontrou vulnerabilidades em repositórios de código. Para aprimorar a postura de segurança dos repositórios, é altamente recomendável corrigir essas vulnerabilidades. (Não há política relacionada)
Gravidade: Média
As descobertas de verificação de infraestrutura como código dos repositórios de código devem ser resolvidas
Descrição: a segurança do DevOps no Defender para Nuvem encontrou problemas de configuração de segurança de infraestrutura como código em repositórios. Os problemas mostrados foram detectados em arquivos de modelo. Para aprimorar a postura de segurança dos recursos relacionados a nuvem, é altamente recomendável corrigir esses problemas. (Não há política relacionada)
Gravidade: Média
Os repositórios do GitHub devem ter a verificação de código habilitada
Descrição: o GitHub usa a varredura de código para analisar o código a fim de encontrar vulnerabilidades de segurança e erros no código. A verificação de código pode ser usada para localizar, fazer triagem e priorizar correções para problemas existentes no seu código. A verificação de código também pode impedir que os desenvolvedores introduzam novos problemas. As verificações podem ser programadas 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 verificação de código localiza uma possível vulnerabilidade ou um possível erro no código, o GitHub mostra um alerta no repositório. Uma vulnerabilidade é um problema no código de um projeto que pode ser explorado para corromper a confidencialidade, a integridade ou a disponibilidade do projeto. (Não há política relacionada)
Gravidade: Média
Os repositórios do GitHub devem ter a verificação de segredos habilitada
Descrição: o GitHub verifica repositórios em busca de tipos conhecidos de segredos, para evitar o uso fraudulento de segredos que foram acidentalmente confirmados em repositórios. A verificação de segredos examina automaticamente todo o histórico do Git em todos os branches presentes no seu repositório do GitHub em busca de segredos. Exemplos de segredos são tokens e chaves privadas que um provedor de serviços pode emitir para autenticação. Se um segredo é colocado em um repositório, qualquer pessoa que tenha acesso de leitura ao repositório pode usar o segredo 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. (Não há política relacionada)
Gravidade: Alta
Os repositórios do GitHub devem ter a verificação do Dependabot habilitada
Descrição: o GitHub envia alertas do Dependabot quando detecta vulnerabilidades em dependências de código que afetam repositórios. Uma vulnerabilidade é um problema no código de um projeto que poderia ser explorada para corromper a confidencialidade, a integridade ou a disponibilidade do projeto ou de outros projetos que usam o código. As vulnerabilidades variam de 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. (Não há política relacionada)
Gravidade: Média