Compartilhar via

Melhores práticas de segurança

  • Artigo

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

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

Embora não seja obrigatório, a incorporação de práticas recomendadas pode melhorar significativamente sua experiência e reforçar a segurança. As recomendações a seguir foram projetadas para ajudá-lo a manter um ambiente seguro do Azure DevOps.

Proteger seu ambiente do Azure DevOps

Empregue as seguintes práticas recomendadas para remover usuários, revisar eventos de auditoria e integrar com a ID do Microsoft Entra.

Remover usuários

  • Remover usuários inativos de contas da Microsoft (MSAs): remova diretamente usuários inativos de sua organização se estiver usando MSAs. Você não pode criar consultas para itens de trabalho atribuídos a contas MSA removidas.
  • Desabilitar ou excluir contas de usuário do Microsoft Entra: se conectado à ID do Microsoft Entra, desabilite ou exclua a conta de usuário do Microsoft Entra enquanto mantém a conta de usuário do Azure DevOps ativa. Essa ação permite que você continue consultando o histórico do item de trabalho usando sua ID de usuário do Azure DevOps.
  • Revogar PATs de usuário: revise e revogue regularmente todos os PATs de usuário existentes para garantir o gerenciamento seguro desses tokens de autenticação críticos.
  • Revogar permissões especiais concedidas a usuários individuais: Audite e revogue todas as permissões especiais concedidas a usuários individuais para garantir o alinhamento com o princípio do menor privilégio.
  • Reatribuir trabalho de usuários removidos: antes de remover usuários, reatribua seus itens de trabalho aos membros atuais da equipe para distribuir a carga com eficiência.

Usar a ID do Microsoft Entra

  • Estabeleça um sistema de identidade unificado: conecte o Azure DevOps à ID do Microsoft Entra para criar um único plano para identidade. Essa consistência reduz a confusão e minimiza os riscos de segurança causados por erros de configuração manual.
  • Implemente a governança refinada: use a ID do Microsoft Entra para atribuir diferentes funções e permissões a grupos específicos em vários escopos de recursos. Essa ação garante acesso controlado e se alinha às práticas recomendadas de segurança.
  • Aprimore os recursos de segurança: habilite outros recursos de segurança com a ID do Microsoft Entra, como:
    • Autenticação multifator (MFA): requer vários fatores, como verificação de senha e telefone, para autenticação do usuário. Políticas de acesso condicional: defina regras de acesso com base em condições como local, dispositivo ou nível de risco.

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

Examinar eventos de auditoria

Com sua organização conectada ao Microsoft Entra, execute as seguintes tarefas para aprimorar a segurança e monitorar os padrões de uso:

Proteger suas redes

As funções a seguir são maneiras eficazes de aprimorar a segurança da rede quando você está trabalhando com o Azure DevOps.

  • Configure a lista de permissões de IP: restrinja o acesso a endereços IP específicos para permitir o tráfego somente de fontes confiáveis, reduzindo a superfície de ataque.
  • Use criptografia: sempre criptografe os dados em trânsito e em repouso. Proteja os canais de comunicação usando protocolos como HTTPS.
  • Validar certificados: verifique se os certificados são válidos e emitidos por autoridades confiáveis ao estabelecer conexões.
  • Implemente firewalls de aplicativos da Web (WAFs): filtre, monitore e bloqueie o tráfego malicioso baseado na Web com WAFs para obter uma camada extra de proteção contra ataques comuns.

Para obter mais informações, consulte Práticas recomendadas de gerenciamento de aplicativos.

Permissões do escopo

O sistema lida com permissões em vários níveis — individual, coleção, projeto e objeto — e as atribui a um ou mais grupos internos por padrão. Para aumentar a segurança, execute as seguintes ações:

  • Fornecer acesso com privilégios mínimos: Dê aos usuários e serviços o acesso mínimo necessário para executar suas funções de negócios.
  • Desabilitar herança: Sempre que possível, desabilite a herança. A herança pode conceder inadvertidamente acesso ou permissões a usuários inesperados devido à sua natureza de permissão por padrão. Para obter mais informações, consulte a seção sobre herança de permissão

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

Permissões no nível de projeto

  • Limite o acesso a projetos e repositórios: reduza o risco de vazamento de informações confidenciais e implantação de código inseguro, limitando o acesso a projetos e repositórios. Use permissões de gerenciamento de grupos de segurança internos ou personalizados.
  • Desabilite "Permitir projetos públicos": nas configurações de política da sua organização, desabilite a opção de criar projetos públicos. Alterne a visibilidade do projeto de público para privado, conforme necessário. Os usuários que não fizeram login têm acesso somente leitura a projetos públicos, enquanto os usuários conectados podem ter acesso a projetos privados e fazer alterações permitidas.
  • Restringir a criação de projetos: impedir que os usuários criem novos projetos para manter o controle sobre seu ambiente.

Acesso de convidado externo

  • Bloquear o acesso de convidados externos: desative a política "Permitir que convites sejam enviados para qualquer domínio" para impedir o acesso de convidados externos se não houver necessidade de negócios.
  • Use emails ou UPNs distintos: use endereços de email ou UPNs (nomes principais de usuário) diferentes para contas pessoais e comerciais para eliminar a ambiguidade entre contas pessoais e relacionadas ao trabalho.
  • Agrupar usuários convidados externos: coloque todos os usuários convidados externos em um único grupo do Microsoft Entra e gerencie as permissões para esse grupo adequadamente. Remova as atribuições diretas para garantir que as regras do grupo se apliquem a esses usuários.
  • Reavalie as regras regularmente: revise regularmente as regras na guia Regras de grupo da página Usuários. Considere quaisquer alterações de associação de grupo na ID do Microsoft Entra que possam afetar sua organização. A ID do Microsoft Entra pode levar até 24 horas para atualizar a associação dinâmica de grupo, e as regras são reavaliadas automaticamente a cada 24 horas e sempre que uma regra de grupo é alterada.

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

A tabela a seguir mostra recomendações para atribuir permissões a grupos de segurança e grupos de usuários.

Fazer Não
Use a ID do Microsoft Entra, o Active Directory ou os grupos de segurança do Windows ao gerenciar 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. Para obter mais informações, consulte Grupos de usuários válidos.
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 certos casos, um nível de permissão Negar pode substituir um nível de permissão Permitir . Por exemplo, imagine que você tenha dois grupos de segurança em seu projeto do Azure DevOps: Desenvolvedores e Testadores. O grupo Desenvolvedores tem permissão para editar itens de trabalho definidos como Permitir. No entanto, certifique-se de que determinados itens de trabalho confidenciais não sejam editados por ninguém, exceto alguns indivíduos-chave. Para fazer isso, crie um novo grupo de segurança chamado Editores de Itens Confidenciais e defina a permissão para editar itens de trabalho como Negar para este grupo. Se um usuário for membro do grupo Desenvolvedores e do grupo Editores de Itens Confidenciais, a permissão Negar do grupo Editores de Itens Confidenciais terá precedência sobre a permissão Permitir do grupo Desenvolvedores. Como resultado, esse usuário não pode editar os itens de trabalho confidenciais, mesmo que tenha a permissão Permitir no grupo Desenvolvedores . Esse comportamento garante que as permissões de negação sejam impostas estritamente, fornecendo um nível mais alto de segurança e controle sobre ações confidenciais em seu ambiente do Azure DevOps.
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 anotadas como Atribuir apenas 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.

Acesso just-in-time para grupos de administradores

Se você tiver acesso de Administrador de Coleção de Projetos e Administrador de Projeto , poderá modificar a configuração de sua organização ou projeto. Para aprimorar a segurança desses grupos de administradores internos, considere implementar o acesso just-in-time usando um grupo do Microsoft Entra Privileged Identity Management (PIM). Essa abordagem permite que você conceda permissões elevadas somente quando necessário, reduzindo o risco associado ao acesso permanente.

Configurar o acesso

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

Observação

Ao configurar o acesso just-in-time usando um grupo do Microsoft Entra Privileged Identity Management (PIM), certifique-se de que qualquer usuário com acesso elevado também mantenha o acesso padrão à organização. Dessa forma, eles podem visualizar as páginas necessárias e atualizar suas permissões conforme necessário.

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 a desativação do acesso ao grupo PIM.

Contas de serviço de escopo

  • Crie contas de serviço de finalidade única: cada serviço deve ter sua conta dedicada para minimizar o risco. Evite usar contas de usuário regulares como contas de serviço.
  • Siga as convenções de nomenclatura e documentação: use nomes claros e descritivos para contas de serviço e documente sua finalidade e serviços associados.
  • Identifique e desabilite contas de serviço não utilizadas: revise e identifique regularmente as contas que não estão mais em uso. Desative as contas não utilizadas antes de considerar a exclusão.
  • Restringir privilégios: limite os privilégios da conta de serviço ao mínimo necessário. Evite direitos de entrada interativos para contas de serviço.
  • Use identidades separadas para leitores de relatório: se estiver usando contas de domínio para contas de serviço, use uma identidade diferente para leitores de relatório para isolar permissões e impedir acesso desnecessário.
  • Usar contas locais para instalações de grupos de trabalho: Ao instalar componentes em um grupo de trabalho, use contas locais para contas de usuário. Evite contas de domínio neste cenário.
  • Aproveite as conexões de serviço: use conexões de serviço sempre que possível para se conectar com segurança aos serviços sem passar variáveis secretas diretamente para builds. Restrinja as conexões a casos de uso específicos.
  • Monitorar a atividade da conta de serviço: implemente a auditoria e crie fluxos de auditoria para monitorar a atividade da conta de serviço.

Para obter mais informações, consulte Tipos comuns de conexão de serviço.

Conexões de serviço de escopo

  • Escopo de conexões de serviço: limite o acesso definindo o escopo de suas conexões de serviço do Azure Resource Manager para recursos e grupos específicos. Evite conceder amplos direitos de colaborador em toda a assinatura do Azure.
  • Usar federação de identidade de carga de trabalho: autentique com recursos do Azure usando o OpenID Connect (OIDC) sem segredos. Crie a federação de identidades de carga de trabalho automática ou manualmente se você tiver a função de Proprietário para sua assinatura do Azure, não estiver se conectando a ambientes do Azure Stack ou do Azure US Government e se todas as tarefas de extensões do Marketplace que você usa derem suporte a ela.
  • Grupos de recursos de escopo: verifique se os grupos de recursos contêm apenas as VMs (Máquinas Virtuais) ou os recursos necessários para o processo de build.
  • Evite conexões de serviço clássicas: opte por conexões de serviço modernas do Azure Resource Manager em vez da clássica, que não têm opções de escopo.
  • Use contas de serviço de equipe específicas para fins específicos: autentique conexões de serviço usando contas de serviço de equipe específicas para manter a segurança e o controle.

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:

  • Usar entidades de serviço: represente objetos de segurança em um aplicativo do Microsoft Entra. Defina o que um aplicativo pode fazer em um determinado locatário. Configure durante o registro do aplicativo no portal do Azure. Configure para acessar recursos do Azure, incluindo Azure DevOps. Útil para aplicativos que precisam de acesso e controle específicos.
  • Usar identidades gerenciadas: semelhante à entidade de serviço de um aplicativo. Forneça identidades para recursos do Azure. Permitir que os serviços que dão suporte à autenticação do Microsoft Entra compartilhem credenciais. O Azure lida com o gerenciamento e a rotação de credenciais automaticamente. Ideal para gerenciamento contínuo de detalhes de login.

Usar PATs com moderação

  • Definir o escopo de PATs para funções específicas: atribua PATs apenas as permissões necessárias para tarefas específicas. Evite conceder acesso global a várias organizações ou repositórios para minimizar o risco de uso indevido acidental.
  • Evite permissões de gravação ou gerenciamento em builds e versões: os PATs não devem ter permissões de gravação ou gerenciamento em builds, versões ou outros recursos críticos. Restringir essas permissões ajuda a evitar ações não intencionais que podem afetar seus pipelines ou implantações.
  • Defina datas de expiração e mantenha os PATs em segredo: Sempre defina uma data de expiração para os PATs. Revise-os e renove-os regularmente conforme necessário. Trate os PATs tão críticos quanto as senhas, mantendo-os confidenciais e evitando o compartilhamento público ou a codificação no código do aplicativo.
  • Evite codificar PATs no código do aplicativo: em vez de inserir PATs diretamente em seu código, use arquivos de configuração seguros ou variáveis de ambiente para armazenar e recuperar PATs dinamicamente. dinamicamente.
  • Audite e revogue PATs não utilizados regularmente: os administradores devem revisar periodicamente todos os PATs usando as APIs REST. Revogue todos os PATs que não são mais necessários ou não atendem aos critérios recomendados.

Para obter mais informações, consulte Gerenciar PATs com políticas - para administradores e Usar PATs.

Proteger o Azure Artifacts

Proteger Azure Boards

Proteger o Azure Pipelines

Políticas

  • Exigir revisores externos: certifique-se de pelo menos um revisor fora do solicitante original para um processo de revisão completo. O aprovador compartilha a copropriedade das alterações e a responsabilidade por quaisquer efeitos potenciais.
  • Exigir que o build de CI seja aprovado: estabeleça uma linha de base para a qualidade do código exigindo que o build de CI (Integração Contínua) seja aprovado antes de mesclar uma PR. As verificações de CI incluem linting de código, testes de unidade e verificações de segurança.
  • Não permitir a autoaprovação: impeça que o solicitante original da PR aprove suas próprias alterações para garantir um processo de revisão imparcial e evitar conflitos de interesse.
  • Não permitir a conclusão da PR com votos de "esperar" ou "rejeitar": Evite a conclusão da PR mesmo que alguns revisores votem para aguardar ou rejeitar, incentivando a abordagem de todos os comentários antes da mesclagem.
  • Redefinir votos do revisor em alterações: redefina os votos do revisor quando as alterações recentes forem enviadas por push para a PR para garantir que os revisores reavaliem o código atualizado.
  • Bloquear pipelines de lançamento: limite os pipelines de lançamento a branches específicos (geralmente produção ou principal) para evitar implantações acidentais de outros branches.
  • Impor variáveis configuráveis no momento da fila: habilite a opção "Impor configurável no tempo da fila" para variáveis de pipeline para impedir que os usuários substituam valores de variáveis durante a execução do pipeline.
  • Não permitir substituições de variáveis no editor: para variáveis definidas no editor de pipeline, não permita substituições de usuário para manter a consistência e evitar alterações não intencionais.

Agentes

  • Conceda permissões com moderação: limite as permissões ao menor conjunto necessário de contas para reduzir a superfície de ataque.
  • Configure firewalls restritivos para agentes: configure firewalls para serem o mais restritivos possível e, ao mesmo tempo, permitir que os agentes funcionem, equilibrando segurança e usabilidade.
  • Atualize regularmente os pools de agentes: mantenha sua frota de agentes atualizada atualizando regularmente os agentes para garantir que o código vulnerável não esteja em execução, reduzindo o risco de exploração.
  • Use um pool de agentes separado para artefatos de produção: isole os artefatos de produção usando um pool de agentes distinto, evitando implantações acidentais de ramificações que não são de produção.
  • Agrupar pools sensíveis ao segmento: crie pools separados para cargas de trabalho confidenciais e não confidenciais. Permitir apenas credenciais em definições de compilação associadas ao pool apropriado.

Definições

  • Use YAML para definições de pipeline: defina pipelines usando YAML (Yet Another Markup Language) para melhor rastreabilidade e adesão às diretrizes de aprovação e práticas de controle de versão.
  • Restringir o acesso de edição às definições de pipeline: limite o acesso à edição de definições de pipeline às contas mínimas necessárias para reduzir o risco de alterações acidentais ou não autorizadas.

Entrada

  • Inclua verificações de variáveis em scripts de compilação: implemente verificações em seus scripts de compilação para mitigar possíveis ataques de injeção de comando por meio de variáveis configuráveis. Valide os valores de entrada e evite comandos não intencionais ou mal-intencionados.
  • Limite as variáveis de compilação "configuráveis no momento da versão": minimize o número de variáveis de compilação configuráveis no momento da versão para reduzir a superfície de ataque e simplificar o gerenciamento da configuração.

Tarefas

  • Evite recursos buscados remotamente: sempre que possível, evite buscar recursos de URLs externas durante o processo de compilação. Se recursos remotos forem necessários, use controle de versão e verificação de hash para garantir a integridade.
  • Evite registrar segredos: nunca registre informações confidenciais, como segredos ou credenciais, em seus logs de build para evitar exposição não intencional e comprometimento da segurança.
  • Use o Azure Key Vault para segredos: em vez de armazenar segredos diretamente em variáveis de pipeline, use o Azure Key Vault para gerenciar e recuperar segredos com segurança.
  • Restrinja a execução de builds em branches ou tags arbitrários: para pipelines críticos de segurança, limite os usuários de executar builds em qualquer branch ou tag. Defina ramificações ou tags autorizadas específicas para evitar execuções acidentais ou não autorizadas.
  • Desabilitar herança para permissões de pipeline: as permissões herdadas podem ser excessivamente amplas e podem não refletir com precisão suas necessidades. Desative a herança e defina permissões explicitamente para se alinhar aos seus requisitos de segurança.
  • Limitar escopos de autorização de trabalho: sempre restrinja os escopos de autorização de trabalho ao mínimo necessário. Ajuste as permissões com base nas tarefas específicas executadas por cada trabalho.

Repositórios e branches

  • Exigir um número mínimo de revisores: habilite a política para garantir que cada solicitação de pull receba revisões de pelo menos dois aprovadores, promovendo a revisão completa do código e a responsabilidade.
  • Configure políticas de segurança específicas do repositório: adapte as políticas de segurança a cada repositório ou branch em vez de políticas em todo o projeto para reduzir riscos, impor padrões de gerenciamento de alterações e melhorar a qualidade do código.
  • Isolar segredos de produção em um cofre de chaves separado: armazene segredos de produção separadamente em um Azure Key Vault e limite o acesso a uma base de conhecimento necessário para manter a separação de builds de não produção.
  • Separe ambientes de teste da produção: evite misturar ambientes de teste com produção para garantir que credenciais e segredos não sejam usados em contextos de não produção.
  • Desativar bifurcação: Desabilitar a bifurcação ajuda a gerenciar a segurança, evitando a proliferação de bifurcações, facilitando o rastreamento da segurança em todas as cópias.
  • Evite fornecer segredos para compilações de bifurcação: evite compartilhar segredos com compilações bifurcadas para mantê-los confidenciais e não expostos a bifurcações.
  • Considere disparar manualmente builds de bifurcação: dispare manualmente builds para bifurcações em vez de permitir que gatilhos automáticos forneçam melhor controle sobre as verificações de segurança.
  • Usar agentes hospedados pela Microsoft para builds de bifurcação: use agentes hospedados pela Microsoft para builds bifurcados à medida que eles são mantidos e seguros.
  • Verificar definições de compilação de produção em repositórios Git: verifique regularmente as definições de compilação de produção armazenadas no repositório Git do projeto em busca de credenciais ou informações confidenciais.
  • Configurar verificações de controle de ramificação para contexto de produção: configure verificações de controle de ramificação para restringir o uso de conexões confidenciais (por exemplo, prod-connection) a pipelines em execução no contexto da ramificação de produção, garantindo a autorização adequada e evitando o uso indevido acidental.

Para obter mais informações, consulte Outras considerações de segurança.

Proteger Azure Repos

Proteger Azure Test Plans

Proteger integrações do GitHub

  • Use o fluxo OAuth em vez de PATs: desative a autenticação baseada em PAT para conexões de serviço GitHub e opte pelo fluxo OAuth para melhor segurança e integração.
  • Evite identidades de administrador ou proprietário: nunca autentique conexões de serviço do GitHub usando uma identidade que seja um administrador ou proprietário de qualquer repositório. Limite as permissões ao nível necessário.
  • Evite GitHub PATs de escopo completo: evite usar um GitHub PAT de escopo completo para autenticar conexões de serviço. Use tokens com as permissões mínimas necessárias.
  • Evite contas pessoais do GitHub como conexões de serviço: não use contas pessoais do GitHub como conexões de serviço no Azure DevOps. Em vez disso, crie contas de serviço dedicadas ou use contas no nível da organização.