Recomendações de segurança para recursos de DevOps
Este artigo lista as recomendações que você pode ver no Microsoft Defender for Cloud se você conectar um ambiente do Azure DevOps, GitHub ou GitLab usando a página Configurações de 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 for Cloud.
Saiba mais sobre os benefícios e recursos de segurança do DevOps.
As recomendações de DevOps não afetam sua pontuação segura. Para decidir quais recomendações resolver primeiro, observe a gravidade de cada recomendação e seu impacto potencial na sua pontuação segura.
Recomendações do Azure DevOps
Os repositórios do Azure DevOps devem ter o GitHub Advanced Security for Azure DevOps (GHAzDO) habilitado
Descrição: A segurança de DevOps no Defender for Cloud usa um console central para capacitar as equipes de segurança com a capacidade de proteger aplicativos e recursos de código para nuvem no Azure DevOps. Com a ativação dos repositórios 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 de DevOps do Azure surgidos no Microsoft Defender for Cloud.
Gravidade: Alta
Os repositórios do Azure DevOps devem ter descobertas de verificação secretas resolvidas
Descrição: Foram encontrados segredos em repositórios de código. Corrija imediatamente para evitar uma violação de segurança. Segredos encontrados em 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 ser executada. Portanto, os resultados podem não refletir o status completo dos segredos em seus repositórios.
Gravidade: Alta
Os repositórios de DevOps do Azure devem ter as descobertas de verificação de código resolvidas
Descrição: Foram encontradas vulnerabilidades nos 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 Azure DevOps devem ter as descobertas de verificação de vulnerabilidade de dependência resolvidas
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 de DevOps do Azure devem ter infraestrutura conforme as descobertas de verificação de código resolvidas
Descrição: Infraestrutura como problemas de configuração de segurança de código encontrados em repositórios. Os problemas foram detetados em arquivos de modelo. Para melhorar a postura de segurança dos recursos de nuvem relacionados, é altamente recomendável corrigir esses problemas.
Gravidade: Média
Os pipelines do Azure DevOps não devem ter segredos disponíveis para compilações de forks
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, pessoas externas poderão obter acesso para construir segredos de pipeline 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 para serviços externos e remotos para executar tarefas em um trabalho. As permissões de pipeline controlam quais pipelines 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 ter acesso a todos os pipelines YAML. Isso ajuda a manter o princípio do menor privilégio porque 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. Esses arquivos são normalmente usados para armazenar segredos, como certificados de assinatura e chaves SSH. Se um arquivo seguro tiver 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 você pode querer 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 contendo segredos estiver marcado como acessível a todos os pipelines YAML, um invasor poderá explorar os ativos que envolvem as variáveis secretas criando um novo pipeline.
Gravidade: Alta
Azure DevOps Classic As conexões de serviço do Azure não devem ser usadas para acessar uma assinatura
Descrição: use o tipo de conexões de serviço do Azure Resource Manager (ARM) em vez de conexões de serviço do Azure Classic para se conectar a assinaturas do Azure. O modelo 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 em permissões Entra e suporte a tags e grupos de recursos para gerenciamento simplificado.
Gravidade: Média
(Pré-visualização) Os repositórios do Azure DevOps devem ter as descobertas de testes de segurança da API resolvidas
Descrição: vulnerabilidades de segurança da 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 de DevOps do Azure devem exigir aprovação mínima de dois revisores para envio por push de código
Descrição: para evitar que alterações não intencionais ou maliciosas sejam confirmadas diretamente, é importante implementar políticas de proteção para a ramificação padrão nos repositórios de DevOps do Azure. Recomendamos exigir que pelo menos dois revisores de código aprovem solicitações pull antes que o código seja mesclado com a ramificação 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, que podem levar à instabilidade do sistema ou vulnerabilidades de segurança.
Essa recomendação é fornecida na postura de segurança básica do Defender for Cloud, se você tiver conectado o Azure DevOps ao Defender for Cloud.
Gravidade: Alta
(Pré-visualização) Os repositórios de DevOps do Azure não devem permitir que os solicitantes aprovem suas próprias solicitações pull
Descrição: para evitar que alterações não intencionais ou maliciosas sejam confirmadas diretamente, é importante implementar políticas de proteção para a ramificação padrão nos repositórios de DevOps do Azure. Recomendamos proibir os criadores de pull request de aprovar seus próprios envios para garantir que cada alteração passe por 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 for Cloud, se você tiver conectado o Azure DevOps ao Defender for Cloud.
Gravidade: Alta
(Pré-visualização) Os projetos do Azure DevOps devem ter a criação de pipelines clássicos desabilitada
Descrição: A desativação da criação de pipelines clássicos de compilação e liberação evita uma preocupação de segurança decorrente do YAML e de pipelines clássicos que compartilham os mesmos recursos, por exemplo, as mesmas conexões de serviço. Atacantes em potencial podem aproveitar pipelines clássicos para criar processos que escapam dos mecanismos de defesa típicos configurados em torno de 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 de ação do GitHub 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 ao nível da organização permitem-lhe partilhar segredos entre vários repositórios. Isso 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 gravação no repositório pode acessar o segredo de qualquer ramificação em um fluxo de trabalho. Para reduzir a superfície de ataque, certifique-se de que o segredo está acessível apenas a partir de repositórios selecionados.
Essa recomendação é fornecida na postura de segurança básica do Defender for Cloud, se você tiver conectado o Azure DevOps ao Defender for Cloud.
Gravidade: Alta
Os repositórios do GitHub devem ter a verificação secreta ativada
Descrição: O GitHub verifica os repositórios em busca de tipos conhecidos de segredos, para evitar o uso fraudulento de segredos que foram acidentalmente cometidos em repositórios. A verificação secreta verificará todo o histórico do Git em todas as ramificações presentes no repositório GitHub em busca 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 verificação de código habilitada
Descrição: O GitHub usa a verificação 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, 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 verificação de código encontrar uma vulnerabilidade ou erro potencial no código, o GitHub exibirá 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 verificação Dependabot ativada
Descrição: O GitHub envia alertas do Dependabot quando deteta vulnerabilidades nas dependências de código que afetam os 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 devem ter as descobertas de varredura secretas resolvidas
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 descobertas de varredura 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 as descobertas de verificação de vulnerabilidade de dependência resolvidas
Descrição: Os repositórios do GitHub devem ter as descobertas de verificação de vulnerabilidade de dependência resolvidas.
Gravidade: Média
Os repositórios do GitHub devem ter infraestrutura conforme as descobertas de varredura de código resolvidas
Descrição: Problemas de configuração de segurança de infraestrutura como código foram encontrados em repositórios. Os problemas foram detetados em arquivos de 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 ramificação padrão habilitadas
Descrição: A ramificação padrão do repositório deve ser protegida por meio de políticas de proteção de ramificação para evitar que alterações não intencionais/maliciosas sejam confirmadas diretamente no repositório.
Gravidade: Alta
Os repositórios do GitHub devem ter pushes de força para ramificação padrão desabilitados
Descrição: Como a ramificação padrão é normalmente usada para implantação e outras atividades privilegiadas, quaisquer alterações nela devem ser abordadas com cuidado. Habilitar pushes de força pode introduzir alterações não intencionais ou maliciosas na ramificação padrão.
Gravidade: Média
As organizações do GitHub devem ter a proteção por push de varredura secreta habilitada
Descrição: A Proteção 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 por push deve ser ativada automaticamente para cada repositório habilitado para verificação secreta.
Gravidade: Alta
Os repositórios do GitHub não devem usar corredores auto-hospedados
Descrição: Os corredores auto-hospedados no GitHub não têm garantias de operação em máquinas virtuais limpas efêmeras e podem ser persistentemente comprometidos por código não confiável em um fluxo de trabalho. Como tal, os Self-Hosted Runners não devem ser utilizados para fluxos de trabalho de ação.
Gravidade: Alta
As organizações do GitHub devem ter 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 conta quebra-vidro.
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 de menor privilégio e evite acessos desnecessários.
Gravidade: Alta
(Pré-visualização) Os repositórios do GitHub devem ter as descobertas de testes de segurança da API resolvidas
Descrição: foram encontradas vulnerabilidades de segurança da 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 em fluxos de trabalho de Ação do GitHub 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 ao nível da organização permitem-lhe partilhar 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 ramificação em um fluxo de trabalho. Para reduzir a superfície de ataque, certifique-se de que o segredo está acessível apenas a partir de repositórios selecionados.
Gravidade: Alta
(Pré-visualização) As organizações do GitHub devem bloquear as sugestões do Copilot que correspondam ao código público
Descrição: Habilitar o filtro do GitHub Copilot para bloquear sugestões de código correspondentes ao código público no GitHub aumenta a segurança e a conformidade legal. Evita a incorporação não intencional de código público ou de fonte aberta, 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 potenciais 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á ativado, o GitHub Copilot verifica as sugestões de código com seu código circundante de cerca de 150 caracteres em relação ao código público no GitHub. Se houver uma correspondência ou quase correspondência, a sugestão não será mostrada.
Gravidade: Alta
(Pré-visualização) As organizações do GitHub devem impor a autenticação multifator para colaboradores externos
Descrição: Impor a autenticação multifator para colaboradores externos em uma organização GitHub é uma medida de segurança que exige que os colaboradores usem uma forma adicional de identificação além de sua senha para acessar os repositórios e recursos da organização. Isso aumenta a segurança, protegendo contra acesso não autorizado, mesmo se uma senha for 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
(Pré-visualização) Os repositórios do GitHub devem exigir aprovação mínima de dois revisores para envio de código
Descrição: para evitar que alterações não intencionais ou maliciosas sejam confirmadas diretamente, é importante implementar políticas de proteção para a ramificação padrão nos repositórios do GitHub. Recomendamos exigir que pelo menos dois revisores de código aprovem solicitações pull antes que o código seja mesclado com a ramificação 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, que podem levar à instabilidade do sistema ou vulnerabilidades de segurança.
Gravidade: Alta
Recomendações do GitLab
Projetos do GitLab devem ter descobertas de varredura secretas resolvidas
Descrição: Foram encontrados segredos 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 do GitLab devem ter as descobertas de varredura de código resolvidas
Descrição: Foram encontradas vulnerabilidades nos 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 do GitLab devem ter as descobertas de verificação de vulnerabilidade de dependência resolvidas
Descrição: Os repositórios do GitHub devem ter as descobertas de verificação de vulnerabilidade de dependência resolvidas.
Gravidade: Média
Os projetos do GitLab devem ter infraestrutura à medida que as descobertas de varredura de código forem resolvidas
Descrição: Problemas de configuração de segurança de infraestrutura como código foram encontrados em repositórios. Os problemas mostrados foram detetados em arquivos de 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 de DevOps preteridas
Os repositórios de código devem ter as descobertas de varredura de código resolvidas
Descrição: A segurança de DevOps no Defender for 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 de DevOps no Defender for 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 o Azure DevOps, a ferramenta Microsoft Security DevOps CredScan verifica apenas as compilações nas quais foi configurada para ser executada. 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 de DevOps no Defender for 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 de DevOps no Defender for Cloud encontrou problemas de configuração de segurança de código em repositórios. Os problemas mostrados foram detetados em arquivos de 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 verificação de código habilitada
Descrição: O GitHub usa a verificação 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, 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 verificação de código encontrar uma vulnerabilidade ou erro potencial no código, o GitHub exibirá 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 verificação secreta ativada
Descrição: O GitHub verifica os repositórios em busca de tipos conhecidos de segredos, para evitar o uso fraudulento de segredos que foram acidentalmente cometidos em repositórios. A verificação secreta verificará todo o histórico do Git em todas as ramificações presentes no repositório GitHub em busca 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 verificação Dependabot ativada
Descrição: O GitHub envia alertas do Dependabot quando deteta vulnerabilidades nas dependências de código que afetam os 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