Compartilhar via

Recomendações de segurança para recursos de DevOps

  • Artigo

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

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

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

Conteúdo relacionado