Partilhar via

Melhores práticas de segurança

  • Artigo

Serviços de DevOps do Azure | 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 os Serviços de DevOps do Azure, 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 criadas para ajudá-lo a manter um ambiente de DevOps do Azure seguro.

Proteja seu ambiente de DevOps do Azure

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

Remover utilizadores

  • Remover usuários inativos de contas da Microsoft (MSAs): remova diretamente usuários inativos de sua organização se estiver usando MSAs. Não é possível criar consultas para itens de trabalho atribuídos a contas MSA removidas.
  • Desabilitar ou excluir contas de usuário do Microsoft Entra: se estiver 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 de itens de trabalho usando sua ID de usuário do Azure DevOps.
  • Revogar PATs de usuário: revise e revogue regularmente quaisquer 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 quaisquer permissões especiais concedidas a usuários individuais para garantir o alinhamento com o princípio de 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 de forma eficaz.

Usar o Microsoft Entra ID

  • Estabeleça um sistema de identidade unificado: conecte o Azure DevOps ao Microsoft Entra ID para criar um único plano para identidade. Essa consistência reduz a confusão e minimiza os riscos de segurança de erros de configuração manual.
  • Implementar governança refinada: use o Microsoft Entra ID para atribuir diferentes funções e permissões a grupos específicos em vários escopos de recursos. Esta ação garante acesso controlado e está alinhada com as melhores práticas de segurança.
  • Aprimore os recursos de segurança: habilite outros recursos de segurança com o Microsoft Entra ID, 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 localização, dispositivo ou nível de risco.

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

Rever eventos de auditoria

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

Proteja a sua rede

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

  • Configurar a lista de permissões de IP: restrinja o acesso a endereços IP específicos para permitir o tráfego apenas de fontes confiáveis, reduzindo a superfície de ataque.
  • Use criptografia: sempre criptografe dados em trânsito e em repouso. Canais de comunicação seguros usando protocolos como HTTPS.
  • Validar certificados: certifique-se de que os certificados são válidos e emitidos por autoridades confiáveis ao estabelecer conexões.
  • Implementar firewalls de aplicativos da Web (WAFs): filtre, monitore e bloqueie tráfego mal-intencionado 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 de 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: conceda aos usuários e serviços o acesso mínimo necessário para executar suas funções de negócios.
  • Desativar herança: Sempre que possível, desative a herança. A herança pode inadvertidamente conceder 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 do projeto

  • Limitar 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 grupos de segurança internos ou personalizados para gerenciar permissões.
  • Desativar "Permitir projetos públicos": nas configurações de política da sua organização, desative a opção para criar projetos públicos. Mude a visibilidade do projeto de público para privado, conforme necessário. Os usuários que não entraram 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: impeça que os usuários criem novos projetos para manter o controle sobre seu ambiente.

Acesso de convidado externo

  • Bloquear acesso de convidado externo: desative a política "Permitir que convites sejam enviados para qualquer domínio" para impedir o acesso de convidado externo se não houver necessidade comercial disso.
  • Use e-mails ou UPNs distintos: use endereços de e-mail ou nomes principais de usuário (UPNs) 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 de grupo se apliquem a esses usuários.
  • Reavalie 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 no Microsoft Entra ID que possam afetar sua organização. O Microsoft Entra ID pode levar até 24 horas para atualizar a associação a grupos dinâmicos, 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 utilizadores

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 grupos de segurança Microsoft Entra ID, Ative Directory ou Windows quando estiver gerenciando muitos usuários. Não altere as permissões padrão para o grupo Usuários Válidos do Projeto. Este 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 diferentes níveis de permissão. 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 de DevOps do Azure: Desenvolvedores e Testadores. O grupo Desenvolvedores tem a permissão para editar itens de trabalho definida como Permitir. Mas, certifique-se de que certos itens de trabalho confidenciais não sejam editados por ninguém, exceto por alguns indivíduos importantes. 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 eles tenham a permissão Permitir no grupo Desenvolvedores . Esse comportamento garante que as permissões de Negar sejam aplicadas estritamente, fornecendo um nível mais alto de segurança e controle sobre ações confidenciais em seu ambiente de DevOps do Azure.
Quando você estiver adicionando muitas equipes, considere criar um grupo personalizado de Administradores de Equipe onde você aloca um subconjunto das permissões disponíveis para Administradores de Projeto. Não altere as atribuições padrão feitas aos 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 do grupo poderá acessar qualquer projeto, coleção ou implantação em que você definiu a permissão.
Considere conceder as pastas de consulta de 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 tão pequenos quanto possível. O acesso deve ser restrito e os grupos devem ser frequentemente auditados.
Aproveite as funções internas e o padrão para Colaborador para desenvolvedores. Os administradores são atribuídos ao grupo de segurança Administrador de Projeto para permissões elevadas, permitindo que 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 Projetos , poderá modificar a configuração de sua organização ou projeto. Para aumentar a segurança desses grupos de administradores internos, considere implementar o acesso just-in-time usando um grupo de Gerenciamento de Identidade Privilegiada (PIM) do Microsoft Entra. 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 de função na ID do Microsoft Entra.
  2. Adicione seu grupo do Microsoft Entra ao grupo do Azure DevOps.

Nota

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 o acesso

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

Nota

Os usuários têm acesso elevado no Azure DevOps por até 1 hora depois que o acesso ao grupo PIM é desativado.

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.
  • Identificar e desativar contas de serviço não utilizadas: analise 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 início de sessão interativos para contas de serviço.
  • Usar identidades separadas para leitores de relatórios: 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 evitar acessos desnecessários.
  • Usar contas locais para instalações de grupo de trabalho: ao instalar componentes em um grupo de trabalho, use contas locais para contas de usuário. Evite contas de domínio nesse 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 as compilações. Restrinja 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 de conexão de serviço comuns.

Conexões de serviço de escopo

  • Conexões de serviço de escopo: 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 contribuidor em toda a assinatura do Azure.
  • Usar federação de identidade de carga de trabalho: autentique-se com recursos do Azure usando o OpenID Connect (OIDC) sem segredos. Crie federação de identidade de carga de trabalho automática ou manualmente se você tiver a função Proprietário para sua assinatura do Azure, não estiver se conectando a ambientes do Azure Stack ou do Azure US Government e todas as tarefas de extensões do Marketplace usadas oferecerem suporte a ela.
  • Grupos de recursos de escopo: verifique se os grupos de recursos contêm apenas as máquinas virtuais (VMs) ou os recursos necessários para o processo de compilação.
  • Evite conexões de serviço clássicas: opte por conexões de serviço modernas do Azure Resource Manager em vez de conexões clássicas, que não têm opções de escopo.
  • Use contas de serviço de equipe específicas para finalidade: autentique conexões de serviço usando contas de serviço de equipe específicas para fins específicos para manter a segurança e o controle.

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

Escolher o método de autenticação certo

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

Considere as 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 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 o Azure DevOps. Útil para aplicações que necessitam de acesso e controlo específicos.
  • Usar identidades gerenciadas: semelhante à entidade de serviço de um aplicativo. Forneça identidades para recursos do Azure. Permita que os serviços que suportam a autenticação do Microsoft Entra partilhem credenciais. O Azure lida com o gerenciamento e a rotação de credenciais automaticamente. Ideal para uma gestão perfeita dos detalhes de início de sessão.

Use PATs com moderação

  • Escopo de PATs para funções específicas: atribua aos 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 compilações e versões: os PATs não devem ter permissões de gravação ou gerenciamento em compilações, 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 validade e mantenha os PATs secretos: sempre defina uma data de validade para PATs. Reveja-os e renove-os regularmente, conforme necessário. Trate os PATs tão críticos quanto as senhas, mantendo-os confidenciais e evitando compartilhamento público ou codificação no código do aplicativo.
  • Evite codificar PATs no código do aplicativo: em vez de incorporar PATs diretamente em seu código, use arquivos de configuração seguros ou variáveis de ambiente para armazenar e recuperar PATs dinamicamente. dinamicamente.
  • Auditar e revogar PATs não utilizados regularmente: os administradores devem revisar periodicamente todos os PATs usando as APIs REST. Revogar quaisquer PATs que não sejam mais necessários ou não atendam aos critérios recomendados.

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

Proteger artefatos do Azure

Proteja os painéis do Azure

Proteja os Pipelines do Azure

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 partilha a copropriedade das alterações e a responsabilidade por quaisquer efeitos potenciais.
  • Exigir que a compilação de CI seja aprovada: estabeleça uma linha de base para a qualidade do código, exigindo que a compilação de Integração Contínua (CI) passe antes de mesclar uma RP. As verificações de CI incluem revestimento de código, testes de unidade e verificações de segurança.
  • Não permitir autoaprovação: impeça que o solicitante de RP original 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 de RP com votos de "esperar" ou "rejeitar": Impedir a conclusão de RP mesmo que alguns revisores votem para esperar ou rejeitar, incentivando a abordagem de todos os comentários antes da fusão.
  • Redefinir os votos dos revisores nas alterações: redefina os votos dos revisores quando as alterações recentes forem enviadas por push para a RP para garantir que os revisores reavaliem o código atualizado.
  • Bloquear pipelines de liberação: limite os pipelines de liberação a ramificações específicas (geralmente de produção ou principais) para evitar implantações acidentais de outras ramificações.
  • 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 evitar 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 permitir substituições de usuário para manter a consistência e evitar alterações não intencionais.

Agentes

  • Conceder permissões com moderação: limite as permissões ao menor conjunto necessário de contas para reduzir a superfície de ataque.
  • Configurar 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 artefatos de produção usando um pool de agentes distinto, evitando implantações acidentais de ramificações que não sejam de produção.
  • Pools sensíveis ao segmento: crie pools separados para cargas de trabalho confidenciais e não confidenciais. Permita 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 aderência à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 ao mínimo necessário 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 valores de entrada e impeça comandos não intencionais ou mal-intencionados.
  • Limite as variáveis de construção "configuráveis no momento da liberação": minimize o número de variáveis de compilação configuráveis no momento da liberação para reduzir a superfície de ataque e simplificar o gerenciamento de configuração.

Tarefas

  • Evite recursos buscados remotamente: sempre que possível, evite buscar recursos de URLs externas durante o processo de compilação. Se forem necessários recursos remotos, use o controle de versão e a verificação de hash para garantir a integridade.
  • Evite registrar segredos: nunca registre informações confidenciais, como segredos ou credenciais, em seus logs de compilação 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.
  • Restringir a execução de compilações contra ramificações ou tags arbitrárias: para pipelines críticos de segurança, limite os usuários de executar compilações em qualquer ramificação ou marca. Defina ramificações ou tags autorizadas específicas para evitar execuções acidentais ou não autorizadas.
  • Desabilitar a 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 com 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 sucursais

  • Exija um número mínimo de revisores: habilite a política para garantir que cada solicitação pull receba avaliações de pelo menos dois aprovadores, promovendo uma revisão completa do código e a prestação de contas.
  • Configurar políticas de segurança específicas do repositório: adapte as políticas de segurança a cada repositório ou ramificação 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 Cofre de Chaves do Azure e limite o acesso a uma base de necessidade de conhecimento para manter a separação de compilações que não sejam de produção.
  • Separe os 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 que não sejam de produção.
  • Desativar bifurcação: desativar 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 construções fork: evite compartilhar segredos com construções bifurcadas para mantê-las confidenciais e não expostas a forks.
  • Considere acionar manualmente compilações de bifurcação: acione manualmente compilações para bifurcações em vez de permitir que gatilhos automáticos forneçam um melhor controle sobre as verificações de segurança.
  • Use agentes hospedados pela Microsoft para compilações fork: use agentes hospedados pela Microsoft para compilações bifurcadas à medida que são mantidas e seguras.
  • 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 seu 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 o Azure Repos

Planos de teste seguros do Azure

Integrações seguras 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 quaisquer repositórios. Limite as permissões ao nível necessário.
  • Evite PATs do GitHub de escopo completo: evite usar uma PAT do GitHub 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.