Melhores práticas de segurança

  • Artigo

Serviços de DevOps do Azure | Azure DevOps Server 2022 - Azure DevOps Server 2019

Quando você está trabalhando com informações e dados, particularmente em uma solução baseada em nuvem como os Serviços de DevOps do Azure, priorizar a segurança deve ser sempre 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. Compilamos as seguintes práticas recomendadas que visam manter seu ambiente de DevOps do Azure seguro:

Ambiente seguro do Azure DevOps

Remover utilizadores

  • Se sua organização usa contas MSA, remova os usuários inativos diretamente da organização, pois você não tem outra maneira de impedir o acesso. Ao fazer isso, não é possível 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.
  • Revogue quaisquer permissões especiais que possam ter sido concedidas a contas de utilizador individuais.
  • Reatribua o trabalho dos usuários que você está removendo aos membros atuais da equipe.

Usar o Microsoft Entra ID

Integre o Azure DevOps com o Microsoft Entra ID para ter um único plano de identidade. A consistência e uma única fonte autorizada aumentam a clareza e reduzem os riscos de segurança decorrentes de erros humanos e da complexidade da 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 que podem estar em inglês:

Rever eventos de auditoria

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

Proteja a sua rede

Algumas maneiras de fazer isso podem incluir:

  • Configure uma lista de permissões para restringir IPs específicos.
  • Utilize sempre encriptação.
  • Valide certificados.
  • Implemente firewalls de aplicativos Web (WAFs), para que eles possam filtrar, monitorar e bloquear qualquer tráfego mal-intencionado baseado na Web de e para o Azure DevOps.
  • Para obter mais informações, consulte este guia sobre 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 do 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.
  • Desative "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. Os Serviços de DevOps do Azure permitem que você altere a visibilidade de seus projetos de público para privado e vice-versa. Se os usuários não tiverem entrado em sua organização, eles terão acesso somente leitura aos seus projetos públicos. Se os usuários tiverem entrado, eles poderão ter acesso a projetos privados e fazer quaisquer alterações permitidas neles.
  • Não permita que os usuários criem novos projetos.

Acesso de convidado externo

  • Bloqueie totalmente o acesso de convidados externos desativando a política "Permitir que convites sejam enviados para qualquer domínio". É uma boa ideia fazê-lo se não houver necessidade comercial disso.
  • Use um e-mail ou nome principal de usuário (UPN) diferente para suas contas pessoais e comerciais, mesmo que isso seja permitido. Esta ação elimina o desafio de desambiguar entre as suas contas empresariais e pessoais quando o e-mail/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 facilmente gerenciar e auditar dessa maneira.
    • Remova as 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.
    • Reavalie as regras regularmente na guia Regras de grupo da página Usuários. Esclareça se quaisquer alterações de associação de grupo na ID do Microsoft Entra podem afetar sua organização. O Microsoft Entra ID pode levar até 24 horas para atualizar a associação ao grupo dinâmico. A cada 24 horas e sempre que uma regra de grupo muda, as regras são automaticamente reavaliadas 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 utilizadores

Consulte as recomendações a seguir 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.
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.
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.

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 Projetos . Para proteger o acesso a esses grupos de administradores internos, exija acesso just-in-time usando um grupo Microsoft Entra Privileged Identity Management (PIM).

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

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 visualizar a página para atualizar suas permissões.

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

  • Certifique-se de que as contas de serviço não têm direitos de início de sessão interativos.
  • Restrinja os privilégios da conta de serviço ao mínimo necessário.
  • Use uma identidade diferente para a conta do leitor de relatórios, 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 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 sempre que 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 diretamente para a compilação. - Restrinja essas conexões ao local específico em que devem ser usadas e nada mais.
  • Monitore a atividade da conta de serviço e crie fluxo de auditoria. A auditoria permite-lhe detetar e reagir a entradas e atividades suspeitas.
  • Para obter mais informações, consulte Tipos de conexão de serviço comuns.

Conexões de serviço de escopo

  • Escopo do Gerenciador de Recursos do Azure e outras conexões de serviço, somente para os recursos e grupos aos quais eles precisam acessar. As conexões de serviço não devem ter amplos direitos de contribuidor em toda a assinatura do Azure.
  • Use a federação de identidade 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 criar conexões de serviço sem segredos no Azure Pipelines to Azure.
  • Não conceda aos usuários direitos de contribuidor genéricos ou amplos na assinatura do Azure.
  • Não use conexões de serviço do Azure Classic, 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 a compilação precisa acessar.
  • Use uma conta de serviço de equipe específica para autenticar uma conexão de serviço.
  • 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 que permitem que você use tokens do Microsoft Entra para acessar recursos do Azure DevOps. Esses tokens apresentam menos risco quando vazados em comparação com PATs e contêm benefícios como fácil gerenciamento de credenciais.

Use PATs com moderação

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

  • Os PATs devem sempre ter um 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 compilações ou versões.

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

  • Os PATs nunca devem ser codificados no código do aplicativo, mesmo que seja tentador fazê-lo 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 os seus PATs em segredo. Seus tokens são tão críticos quanto as senhas.

  • Guarde os seus tokens num local seguro.

  • Não codifice tokens 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 mais informações, consulte os seguintes artigos:

Proteger artefatos do Azure

Proteja os painéis do Azure

Proteja os Pipelines do Azure

Políticas

  • Exija pelo menos um revisor fora do solicitante original. O aprovador partilha a copropriedade das alterações e deve ser igualmente responsabilizado por qualquer impacto potencial.
  • Exigir que a compilação de CI seja aprovada. Esse requisito é útil para estabelecer a qualidade do código de linha de base, por meio de revestimento de código, testes de unidade e verificações de segurança, como verificações de vírus e credenciais.
  • Certifique-se de que o solicitante pull original não possa aprovar a alteração.
  • Não permitir a conclusão de um PR (Pull Request), mesmo que alguns revisores votem para esperar ou rejeitar.
  • Redefina os votos do revisor de código quando as alterações recentes forem enviadas por push.
  • Bloqueie pipelines de liberação executando-os apenas em ramificações de produção específicas.
  • 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 este 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 compilação não esteja executando código vulnerável que um ator mal-intencionado pode explorar.
  • Use um pool de agentes separado para criar artefatos que são enviados ou implantados na produção.
  • Segmente o pool "sensível" de pools não confidenciais e permita apenas o uso de credenciais em definições de compilação bloqueadas para esse pool.

Definições

  • Gerencie definições de pipeline com YAML (Yet Another Markup Language). O YAML é o método preferido para gerenciar definições de pipeline, pois fornece rastreabilidade para alterações e pode seguir diretrizes de aprovação.
  • Proteger a definição de pipeline Edite o acesso ao número mínimo de contas.

Entrada

  • Inclua verificações de sanidade para variáveis em scripts de construção. Uma verificação de sanidade pode mitigar um ataque de injeção de comando através das variáveis configuráveis.
  • Defina o menor número possível de variáveis de compilação como "Configurável no momento do lançamento".

Tarefas

  • Evite recursos obtidos 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, use o Azure Key Vault. Analise regularmente seus pipelines de compilação para garantir que segredos não estejam sendo armazenados em variáveis de pipeline de compilação.
  • Não permita que os usuários executem compilações em ramificações arbitrárias ou tags em pipelines críticos de segurança.
  • Desative 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 os escopos de autorização de trabalho em todos os casos.

Repositórios e sucursais

  • Defina a política "Exigir um número mínimo de revisores" como ativada, para que cada solicitação pull seja revisada por pelo menos dois aprovadores.
  • Configure políticas de segurança específicas para cada repositório ou ramificação, em vez de todo o projeto. As políticas de segurança reduzem os riscos, 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 seja concedido apenas com base na necessidade de conhecimento para manter as compilações que não são de produção separadas.
  • Não misture ambientes de teste com produção, incluindo o uso de credenciais.
  • Desative a bifurcação. Quanto mais garfos houver, mais difícil será acompanhar a segurança de cada garfo. Além disso, um usuário pode facilmente bifurcar uma cópia de um repositório para sua própria conta privada.
  • Não forneça segredos para construções de bifurcação.
  • Considere acionar manualmente construções de bifurcação.
  • Use agentes hospedados pela Microsoft para compilações fork.
  • Para o Git, verifique suas definições de compilação de produção no repositório git do projeto, para que elas possam ser verificadas em busca de credenciais.
  • Configure uma verificação de controle de ramificação para que somente 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 o Azure Repos

Planos de teste seguros do Azure

Integrações seguras do GitHub

  • Desative a autenticação baseada em Personal Access Token (PAT), para que o fluxo OAuth seja usado com a conexão de serviço GitHub.
  • Nunca autentique conexões de serviço do GitHub como uma identidade que seja um administrador ou proprietário de quaisquer repositórios.
  • Nunca use um PAT (Personal Access Token) de escopo completo do GitHub 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.