Compartilhar via

Melhores práticas de segurança

  • Artigo

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Quando você está trabalhando com informações e dados, especialmente em uma solução baseada em nuvem como Azure DevOps Services, priorizar a segurança sempre deve ser sua principal preocupação. Embora a Microsoft mantenha a segurança da infraestrutura de nuvem subjacente, é sua responsabilidade configurar a segurança no Azure DevOps.

Embora não seja obrigatório, incorporar práticas recomendadas ao usar o Azure DevOps pode aprimorar sua experiência e torná-la mais segura. As práticas recomendadas a seguir visam manter seu ambiente de DevOps do Azure seguro:

Ambiente seguro de DevOps do Azure

Removendo usuários

  • Se sua organização usa contas MSA, remova usuários inativos diretamente da organização, pois você não tem outra maneira de impedir o acesso. Ao fazer isso, você não pode criar uma consulta para itens de trabalho atribuídos à conta de usuário removida. Para obter mais informações, consulte Excluir usuários do Azure DevOps.
  • Se sua organização estiver conectada à ID do Microsoft Entra, você poderá desabilitar ou excluir a conta de usuário do Microsoft Entra e deixar sua conta de usuário do Azure DevOps ativa. Dessa forma, você pode continuar a consultar o histórico de itens de trabalho usando sua ID de usuário do Azure DevOps.
  • Revogar PATs de usuário.
  • Revogar quaisquer permissões especiais concedidas a contas de usuário individuais.
  • Reatribua o trabalho dos usuários que você está removendo para os membros atuais da equipe.

Usar a ID do Microsoft Entra

Integre o Azure DevOps com a ID do Microsoft Entra para ter um único plano para identidade. A consistência e uma única fonte autoritativa aumentam a clareza e reduzem os riscos de segurança de erros humanos e complexidade de configuração. A chave para encerrar a governança é ter várias atribuições de função (com definições de função diferentes e escopos de recursos diferentes para os mesmos grupos do Microsoft Entra). Sem o Microsoft Entra ID, você é o único responsável por controlar o acesso da organização.

O uso do Microsoft Entra ID também permite que você acesse outros recursos de segurança, como autenticação multifator ou outras políticas de acesso condicional.

Para obter mais informações, consulte os seguintes artigos:

Examinar eventos de auditoria

Depois de ter uma organização apoiada pelo Microsoft Entra, você pode ativar a Auditoria em suas diretivas de segurança. Examine periodicamente os eventos de auditoria para monitorar e reagir a padrões de uso inesperados por administradores e outros usuários.

Proteger suas redes

Algumas maneiras de fazer isso podem incluir:

  • Configure uma lista de permissões para restringir IPs específicos.
  • Sempre use criptografia.
  • Validar certificados.
  • Implemente WAFs (firewalls de aplicativo Web) para que eles possam filtrar, monitorar e bloquear qualquer tráfego baseado na Web mal-intencionado de e para o Azure DevOps.
  • Para obter mais informações, confira estas diretrizes sobre as práticas recomendadas de gerenciamento de aplicativos

Permissões com escopo

O sistema gerencia permissões em diferentes níveis - individual, coleção, projeto e objeto - e as atribui a um ou mais grupos internos por padrão.

Permissões no nível de projeto

  • Limite o acesso a projetos e repositórios para reduzir o risco de vazamento de informações confidenciais e implantação de código inseguro na produção.
  • Use os grupos de segurança internos ou grupos de segurança personalizados para gerenciar permissões. Para obter mais informações, consulte Conceder ou restringir permissões para selecionar tarefas.
  • Desabilite "Permitir projetos públicos" nas configurações de política da sua organização para impedir que todos os usuários da organização criem um projeto público. Azure DevOps Services permite alterar a visibilidade de seus projetos de público para privado e vice-versa. Se os usuários não entraram em sua organização, eles têm acesso somente leitura aos seus projetos públicos. Se os usuários tiverem se conectado, eles poderão ter acesso a projetos privados e fazer alterações permitidas neles.
  • Não permita que os usuários criem novos projetos.

Acesso de convidado externo

  • Bloqueie totalmente o acesso de convidado externo desabilitando a política "Permitir que convites sejam enviados para qualquer domínio". É uma boa idéia fazê-lo se não houver necessidade de negócios para isso.
  • Use um upn (nome upn) de email ou entidade de usuário diferente para suas contas pessoais e comerciais, mesmo que seja permitido. Essa ação elimina o desafio de desambiguar entre suas contas corporativas e pessoais quando o email/UPN é o mesmo.
  • Coloque todos os usuários convidados externos em um único grupo do Microsoft Entra e gerencie as permissões desse grupo adequadamente. Você pode gerenciar e auditar facilmente dessa forma.
    • Remova atribuições diretas para que as regras de grupo se apliquem a esses usuários. Para obter mais informações, consulte Adicionar uma regra de grupo para atribuir níveis de acesso.
    • Reavaliar regras regularmente na guia Regras de grupo da página Usuários. Esclareça se alguma alteração de associação de grupo na ID do Microsoft Entra pode afetar sua organização. O Microsoft Entra ID pode levar até 24 horas para atualizar a associação dinâmica ao grupo. A cada 24 horas e sempre que uma regra de grupo é alterada, as regras são reavaliadas automaticamente no sistema.
  • Para obter mais informações, consulte Convidados B2B na ID do Microsoft Entra.

Gerenciar grupos de segurança

Segurança e grupos de usuários

Confira as recomendações a seguir para atribuir permissões a grupos de segurança e grupos de usuários.

Fazer Não
Use o Microsoft Entra ID, o Active Directory ou os grupos de segurança do Windows quando estiver gerenciando muitos usuários. Não altere as permissões padrão para o grupo Usuários Válidos do Projeto . Esse grupo pode acessar e exibir informações do projeto.
Ao adicionar equipes, considere quais permissões você deseja atribuir aos membros da equipe que precisam criar e modificar caminhos de área, caminhos de iteração e consultas. Não adicione usuários a vários grupos de segurança que contenham níveis de permissão diferentes. Em determinados casos, um nível de permissão Negar pode substituir um nível de permissão Permitir .
Ao adicionar muitas equipes, considere criar um grupo personalizado administradores de equipe em que você aloca um subconjunto das permissões disponíveis para administradores de projeto. Não altere as atribuições padrão feitas para os grupos Usuários Válidos do Projeto . Se você remover ou definir Exibir informações no nível da instância como Negar para um dos grupos Usuários Válidos do Projeto , nenhum usuário no grupo poderá acessar qualquer projeto, coleção ou implantação em que você defina a permissão.
Considere conceder às pastas de consulta do item de trabalho permissão contribuir para usuários ou grupos que exigem a capacidade de criar e compartilhar consultas de item de trabalho para o projeto. Não atribua permissões que são indicadas como Atribuir somente a contas de serviço a contas de usuário.
Mantenha os grupos o menor possível. O acesso deve ser restrito e os grupos devem ser auditados com frequência.
Aproveite as funções internas e o padrão de colaborador para os desenvolvedores. Os administradores são atribuídos ao grupo de segurança administrador de projeto para permissões elevadas, permitindo que eles configurem permissões de segurança.

Para obter mais informações, consulte Grupos de usuários válidos.

Acesso just-in-time para grupos de administradores

Você pode alterar a configuração de sua organização ou projeto se tiver acesso de Administrador de Coleção de Projetos e Administrador de Projeto . Para proteger o acesso a esses grupos de administradores internos, exija acesso just-in-time usando um grupo do Microsoft Entra Privileged Identity Management (PIM).

Configurar o acesso

  1. Crie um grupo atribuível por função na ID do Microsoft Entra.
  2. Adicione seu grupo do Microsoft Entra ao grupo de DevOps do Azure.

Observação

Certifique-se de que qualquer usuário com acesso elevado usando um grupo PIM também tenha acesso padrão à organização, para que possa exibir a página para atualizar suas permissões.

Usar acesso

  1. Ative seu acesso.
  2. Atualize suas permissões no Azure DevOps.
  3. Execute a ação que requer acesso de administrador.

Observação

Os usuários têm acesso elevado no Azure DevOps por até 1 hora após o acesso ao grupo PIM ser desativado.

Contas de serviço de escopo

  • Verifique se as contas de serviço não têm direitos de entrada interativos.
  • Restrinja os privilégios da conta de serviço ao mínimo necessário.
  • Use uma identidade diferente para a conta de leitor de relatório, se você usar contas de domínio para suas contas de serviço. Para obter mais informações, consulte Contas de serviço e dependências.
  • Use contas locais para contas de usuário, se você estiver instalando um componente em um grupo de trabalho. Para obter mais informações, consulte Requisitos da conta de serviço.
  • Use conexões de serviço quando possível. As conexões de serviço fornecem um mecanismo seguro para se conectar a serviços variados sem a necessidade de passar variáveis secretas para o build diretamente. – Restrinja essas conexões ao local específico em que elas devem ser usadas e nada mais.
  • Monitore a atividade da conta de serviço e crie o streaming de auditoria. A auditoria permite detectar e reagir a entradas e atividades suspeitas.
  • Para obter mais informações, consulte Tipos comuns de conexão de serviço.

Conexões de serviço de escopo

  • Escopo do Azure Resource Manager e outras conexões de serviço, somente para os recursos e grupos aos quais eles precisam de acesso. As conexões de serviço não devem ter direitos amplos de contribuidor em toda a assinatura do Azure.
  • Use a federação de identidades de carga de trabalho para suas conexões de serviço do Azure Resource Manager (ARM). A federação de identidades de carga de trabalho permite que você crie conexões de serviço sem segredo no Azure Pipelines para o Azure.
  • Não conceda aos usuários direitos genéricos ou amplos de contribuidor na assinatura do Azure.
  • Não use conexões de serviço clássicas do Azure, pois não há como definir o escopo das permissões.
  • Verifique se o grupo de recursos contém apenas Máquinas Virtuais (VMs) ou recursos aos quais o build precisa de acesso.
  • Use uma conta de serviço de equipe específica de finalidade para autenticar uma conexão de serviço.
  • Para obter mais informações, consulte Tipos comuns de conexão de serviço.

Escolher o método de autenticação correto

Selecione seus métodos de autenticação nas seguintes fontes:

Considerar entidades de serviço

Explore alternativas como entidades de serviço e identidades gerenciadas que permitem que você use tokens do Microsoft Entra para acessar recursos de DevOps do Azure. Esses tokens têm menos risco quando vazados em comparação com PATs e contêm benefícios como gerenciamento fácil de credenciais.

Usar PATs com moderação

Se possível, recomendamos sempre usar serviços de identidade para autenticação em vez de chaves criptográficas, pois gerenciar chaves com segurança com o código do aplicativo é desafiador e pode levar a erros como publicar acidentalmente chaves de acesso confidenciais em repositórios de código público como o GitHub. No entanto, se você precisar usar PATs (tokens de acesso pessoal), considere as seguintes diretrizes:

  • Os PATs sempre devem ter escopo para funções específicas.

  • Os PATs não devem fornecer acesso global a várias organizações.

  • Os PATs não devem conceder permissões de gravação ou gerenciamento em builds ou versões.

  • Os PATs devem ter uma data de validade e ser mantidos em segredo, pois são tão críticos quanto senhas.

  • Os PATs nunca devem ser codificados no código do aplicativo, mesmo que seja tentador fazer isso para simplificar o código.

  • Os administradores devem auditar regularmente todos os PATs usando as APIs REST e revogar os que não atendem aos critérios acima.

  • Mantenha seus PATs em segredo. Seus tokens são tão críticos quanto senhas.

  • Armazene seus tokens em um local seguro.

  • Não embuta tokens em código em aplicativos. Pode ser tentador simplificar o código para obter um token por um longo período de tempo e armazená-lo em seu aplicativo, mas não faça isso.

  • Dê aos tokens uma data de validade.

  • Para obter mais informações, marcar os seguintes artigos:

Proteger o Azure Artifacts

Proteger Azure Boards

Proteger o Azure Pipelines

Políticas

  • Exigir pelo menos um revisor fora do solicitante original. O aprovador compartilha a copropriação das alterações e deve ser responsabilizado igualmente por qualquer impacto potencial.
  • Exigir que o build de CI seja aprovado. Esse requisito é útil para estabelecer a qualidade do código de linha de base, por meio de linting de código, testes de unidade e verificações de segurança, como varreduras de vírus e credenciais.
  • Verifique se o solicitante de pull original não pode aprovar a alteração.
  • Não permitir a conclusão de uma PR (Solicitação de Pull), mesmo que alguns revisores votem para aguardar ou rejeitar.
  • Redefinir votos do revisor de código quando as alterações recentes forem enviadas por push.
  • Bloqueie os pipelines de lançamento executando-os apenas em branches de produção específicos.
  • Habilite "Impor configurável no tempo de fila para variáveis" nas configurações de pipeline da sua organização.
  • Não permita "Permitir que os usuários substituam esse valor ao executar esse pipeline", para variáveis definidas no editor.

Agentes

  • Conceda permissões ao menor número possível de contas.
  • Tenha o firewall mais restritivo que deixa seus agentes utilizáveis.
  • Atualize pools regularmente para garantir que a frota de build não esteja executando código vulnerável que um ator mal-intencionado possa explorar.
  • Use um pool de agentes separado para artefatos de build que são enviados ou implantados para produção.
  • Segmente o pool "confidencial" de pools sem sentido e permita apenas o uso de credenciais em definições de build bloqueadas para esse pool.

Definições

  • Gerenciar definições de pipeline com YAML (mais uma linguagem de marcação). YAML é o método preferencial para gerenciar definições de pipeline, pois fornece rastreabilidade para alterações e pode seguir as diretrizes de aprovação.
  • Proteger a definição de pipeline Editar acesso ao número mínimo de contas.

Entrada

  • Inclua verificações de integridade para variáveis em scripts de build. Uma sanidade marcar pode atenuar um ataque de injeção de comando por meio das variáveis configuráveis.
  • Defina o mínimo possível de variáveis de build como "Configurável no momento do lançamento".

Tarefas

  • Evite recursos buscados remotamente, mas, se necessário, use controle de versão e verificação de hash.
  • Não registre segredos.
  • Não armazene segredos em variáveis de pipeline. Usar o Azure Key Vault. Examine regularmente seus pipelines de build para garantir que os segredos não estejam sendo armazenados em variáveis de pipeline de build.
  • Não permita que os usuários executem builds em branches arbitrários ou marcas em pipelines críticos de segurança.
  • Desabilite a herança no pipeline, pois as permissões herdadas são amplas e não refletem com precisão suas necessidades de permissões.
  • Limite escopos de autorização de trabalho em todos os casos.

Repositórios e branches

  • Defina a política "Exigir um número mínimo de revisores", como ativada, para que cada solicitação de pull seja revisada por pelo menos dois aprovadores.
  • Configure políticas de segurança específicas para cada repositório ou branch, em vez de todo o projeto. As políticas de segurança reduzem o risco, impõem padrões de gerenciamento de alterações e melhoram a qualidade do código da sua equipe.
  • Armazene segredos de produção em um Cofre de Chaves separado e garanta que o acesso só seja concedido com base na necessidade de conhecimento para manter as compilações de não produção separadas.
  • Não misture ambientes de teste com produção, incluindo o uso de credenciais.
  • Desabilite a bifurcação. Quanto mais forks houver, mais difícil será controlar a segurança de cada bifurcação. Além disso, um usuário pode bifurcar facilmente uma cópia de um repositório para sua própria conta privada.
  • Não forneça segredos para compilações de bifurcação.
  • Considere disparar manualmente builds de bifurcação.
  • Use agentes hospedados pela Microsoft para builds de bifurcação.
  • Para o Git, marcar suas definições de build de produção no repositório git do projeto, para que possam ser verificadas quanto a credenciais.
  • Configure uma verificação de controle de ramificação para que somente os pipelines em execução no contexto da production ramificação possam usar o prod-connection.
  • Para obter mais informações, consulte Outras considerações de segurança.

Proteger Azure Repos

Proteger Azure Test Plans

Proteger integrações do GitHub

  • Desabilite a autenticação baseada em PAT (Token de Acesso Pessoal) para que o fluxo OAuth seja usado com a conexão de serviço do GitHub.
  • Nunca autentique conexões de serviço do GitHub como uma identidade que seja um administrador ou proprietário de nenhum repositório.
  • Nunca use um GITHub PAT de escopo completo (Token de Acesso Pessoal) para autenticar conexões de serviço do GitHub.
  • Não use uma conta pessoal do GitHub como uma conexão de serviço com o Azure DevOps.