Sobre permissões e grupos de segurança

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

Neste artigo, saiba mais sobre níveis de acesso e permissões por herança, grupos de segurança, funções e muito mais no Azure DevOps.

Obtenha uma visão geral das permissões padrão em Referência rápida de permissões padrão. Para obter uma descrição de cada grupo de segurança padrão, consulte Grupos de segurança, contas de serviço e referência de permissões.

Níveis de acesso

Todos os usuários adicionados ao Azure DevOps recebem um nível de acesso, que concede ou restringe o acesso a recursos selecionados do portal da Web.

Existem três níveis principais de acesso: Stakeholder, Basic e Basic + Test Plans. O acesso das partes interessadas fornece acesso gratuito a um número ilimitado de usuários a um conjunto limitado de recursos. Para mais informações, veja Referência rápida de acesso das partes interessadas.

Para dar a um usuário acesso ao gerenciamento de portfólio Agile ou aos recursos de gerenciamento de caso de teste, altere os níveis de acesso, não as permissões. Saiba mais em Sobre nível de acesso.

Permissões

Todos os usuários adicionados ao Azure DevOps são adicionados a um ou mais grupos de segurança padrão. Aos grupos de segurança são atribuídas permissões, que permitem ou negam acesso a um recurso ou tarefa.

• Os membros de um grupo de segurança herdam as permissões atribuídas ao grupo.
• As permissões são definidas em diferentes níveis: organização/coleção, projeto ou objeto.
• Outras permissões são gerenciadas por meio de atribuições baseadas em função, como administrador de equipe, gerenciamento de extensão e várias funções de recurso de pipeline.
• Os administradores podem definir grupos de segurança personalizados para gerenciar permissões para diferentes áreas funcionais.

Quando se trata de gerenciar permissões no Azure DevOps, há dois grupos principais envolvidos: Administradores de Coleção de Projetos e Administradores de Projetos. Vamos por partes:

Administradores da coleção de projetos:

• Esses indivíduos têm o mais alto nível de autoridade dentro de uma organização ou coleção de projetos.
• Eles podem executar todas as operações para toda a coleção.
• Suas responsabilidades incluem o gerenciamento de configurações, políticas e processos para a organização.
• Além disso, eles podem criar e gerenciar todos os projetos e extensões dentro da organização.

Administradores de Projetos:

• Os administradores de projeto operam no nível do projeto.
• Eles gerenciam grupos de segurança e permissões principalmente a partir das configurações do Project do portal da Web.
• Os colaboradores, por outro lado, manipulam permissões para objetos específicos que criam dentro do projeto.

Estados de permissão

Você pode atribuir permissões das seguintes maneiras, concedendo ou restringindo o acesso conforme indicado.

O usuário ou grupo tem permissões para executar uma tarefa:

• Permitir
• Permitir (herdado)
• Permitir (sistema)

O usuário ou grupo não tem permissão para executar uma tarefa:

• Deny
• Negar (herdado)
• Negar (sistema)
• Não definido

Estado de permissão	Descrição
Permitir	Concede explicitamente aos usuários a execução de tarefas específicas e não é herdado da associação ao grupo.
Permitir (herdado)	Concede aos membros do grupo a execução de tarefas específicas.
Permitir (sistema)	Concede permissão que tem precedência antes das permissões do usuário. Não editável e armazenado em um banco de dados de configuração, invisível para os usuários.
Deny	Restringe explicitamente os usuários de executar tarefas específicas e não é herdado da associação ao grupo. Para a maioria dos grupos e quase todas as permissões, Negar substitui Permitir. Se um usuário pertencer a dois grupos e um deles tiver uma permissão específica definida como Negar, esse usuário não poderá executar tarefas que exijam essa permissão, mesmo que pertença a um grupo que tenha essa permissão definida como Permitir.
Negar (herdado)	Restringe os membros do grupo de executar tarefas específicas. Substitui um Permitir explícito.
Negar (sistema)	Restringe a permissão que tem precedência antes das permissões do usuário. Não editável e armazenado em um banco de dados de configuração, invisível para os usuários.
Não definido	Implicitamente nega aos usuários a capacidade de executar tarefas que exigem essa permissão, mas permite que a associação a um grupo que tenha essa permissão tenha precedência, também conhecida como Permitir (herdado) ou Negar (herdado).

Em alguns casos, os membros dos grupos Administradores de Coleção de Projetos ou Administradores do Team Foundation sempre podem obter a permissão, mesmo que lhes seja negada essa permissão em um grupo diferente. Em outros casos, como exclusão de item de trabalho ou pipelines, ser membro do grupo Administradores de Coleção de Projetos não ignora as permissões Negar definidas em outro lugar.

Aviso

Quando você modifica uma permissão para um grupo, ela afeta todos os usuários desse grupo. Mesmo uma única alteração de permissão pode afetar centenas de usuários, por isso é crucial considerar os efeitos potenciais antes de fazer qualquer ajuste.

Herança de permissões

As permissões seguem uma hierarquia, permitindo a herança de um pai ou substituindo.

• Herança de grupo: os usuários herdam permissões dos grupos aos quais pertencem. Se um usuário tiver uma permissão Permitir diretamente ou por meio de associação a grupo, mas também tiver uma permissão Negar por meio de outro grupo, a permissão Negar terá precedência. No entanto, os membros de Administradores de Coleção de Projetos ou Administradores do Team Foundation retêm a maioria das permissões permitidas, mesmo que pertençam a outros grupos que negam essas permissões (exceto para operações de item de trabalho).
• Herança em nível de objeto: as permissões de nível de objeto (atribuídas a nós como áreas, iterações, pastas de controle de versão e pastas de consulta de item de trabalho) são herdadas na hierarquia.

Por exemplo, vamos detalhar as regras de especificidade e herança de permissões e lembre-se, as permissões explícitas sempre têm precedência sobre as herdadas:

• Quando as permissões de um usuário são definidas em um nó de nível superior (área-1), essas permissões são herdadas por todos os subnós (área-1/subárea-1), a menos que sejam explicitamente substituídas.
• Se uma permissão não for explicitamente permitida ou negada para um subnó, ela herdará a permissão de seu pai.
• No entanto, se uma permissão for explicitamente definida para um subnó (área-1/subárea-1), a permissão do pai não será herdada, independentemente de ser permitida ou negada. Especificidade:
• Na hierarquia de objetos, a especificidade supera a herança. Isso significa que, se houver permissões conflitantes, a permissão mais específica terá precedência.
• Por exemplo, considere um usuário:
  • Negar explicitamente em 'area-1' (nó pai).
  • Permitir explicitamente 'area-1/sub-area-1' (nó filho).
• Nesse caso, o usuário recebe um Permitir em 'area-1/sub-area-1', substituindo o Deny herdado do nó pai.

Para entender por que uma permissão é herdada, você pode pausar sobre uma configuração de permissão e escolher Por quê? Para abrir uma página Segurança , consulte Exibir permissões.

Observação

Para habilitar a página de visualização da página de configurações de Permissões do Projeto, consulte Habilitar recursos de visualização.

Página Visualização

Uma nova caixa de diálogo é aberta mostrando as informações de herança dessa permissão.

Página atual

Uma nova janela mostra as informações de herança dessa permissão.

Grupos de segurança e associação

Os grupos de segurança atribuem permissões específicas aos seus membros.

Com a criação de uma organização, coleção ou projeto, o Azure DevOps cria um conjunto de grupos de segurança padrão, que recebem automaticamente permissões padrão. Mais grupos de segurança são definidos com as seguintes ações:

• Quando você cria grupos de segurança personalizados nos seguintes níveis:
  • Nível do projeto
  • Nível da organização ou coleção
  • Nível do servidor (somente local)
• Quando você adiciona uma equipe, um grupo de segurança de equipe é criado

Não é possível criar um grupo de segurança no nível do objeto, mas você pode atribuir um grupo personalizado a um nível de objeto e atribuir permissões a esse nível. Para obter mais informações, consulte Definir permissões no nível do objeto.

Grupos de segurança padrão

A maioria dos usuários do Azure DevOps é adicionada ao grupo de segurança Colaboradores e recebe o nível de acesso Básico. O grupo Colaboradores fornece acesso de leitura e gravação a repositórios, controle de trabalho, pipelines e muito mais. O acesso básico fornece acesso a todos os recursos e tarefas para usar o Azure Boards, o Azure Repos, o Azure Pipelines e o Azure Artifacts. Os usuários que precisam de acesso para gerenciar os Planos de Teste do Azure precisam receber acesso Básico + Planos de Teste ou Avançado .

Os grupos de segurança a seguir são definidos por padrão para cada projeto e organização. Normalmente, você adiciona usuários ou grupos aos grupos Leitores, Colaboradores ou Administradores de Projeto.

Project	Organização ou Coleção
- Administradores de Build -Contribuintes - Administradores de Projetos - Usuários válidos do projeto -Leitores - Administradores de Versões - Equipe TeamName	- Administradores de Coleção de Projetos - Administradores de Build de Coleção de Projetos - Contas de Serviço de Construção de Coleção de Projetos - Contas de Serviço de Proxy de Coleta de Projetos - Contas do Serviço de Cobrança de Projetos - Contas de Serviço de Teste de Coleta de Projetos - Coleção de Projetos Usuários Válidos - Usuários com escopo de projeto - Grupo de Serviços de Segurança

Para obter uma descrição de cada um desses grupos, consulte Grupos de segurança, contas de serviço e permissões. Para obter atribuições de permissão padrão feitas aos grupos de segurança padrão mais comuns, consulte Permissões e acesso padrão.

Para usuários encarregados de gerenciar recursos no nível do projeto, como equipes, caminhos de área e iteração, repositórios, ganchos de serviço e pontos de extremidade de serviço, adicione-os ao grupo Administradores de Projeto .

Para usuários encarregados de gerenciar recursos no nível da organização ou da coleção — como projetos, políticas, processos, políticas de retenção, pools de agentes e implantação e extensões — adicione-os ao grupo Administradores de Coleção de Projetos . Para obter mais informações, consulte Sobre configurações de usuário, equipe, projeto e nível de organização.

Gerenciamento de associação, permissão e nível de acesso

O Azure DevOps controla o acesso por meio dessas três áreas funcionais interconectadas:

• O gerenciamento de associações permite adicionar contas de usuário e grupos individuais a grupos de segurança padrão. Cada grupo padrão está associado a um conjunto de permissões padrão. Todos os usuários adicionados a qualquer grupo de segurança são adicionados ao grupo Usuários Válidos. Um usuário válido pode ser conectar a um projeto, uma coleção ou uma organização.
• O gerenciamento de permissões controla o acesso a tarefas funcionais específicas em diferentes níveis do sistema. As permissões no nível do objeto definem permissões em um arquivo, pasta, pipeline de compilação ou uma consulta compartilhada. As configurações de permissão correspondem a Permitir, Negar, Permitir herdado, Negar herdado, Permitir sistema, Negar sistema e Não definir.
• O gerenciamento de nível de acesso controla o acesso aos recursos do portal da Web. Com base na compra para um usuário, os administradores definem o nível de acesso do usuário como Stakeholder, Basic, Basic + Test ou Visual Studio Enterprise (anteriormente Advanced).

Cada área funcional usa os grupos de segurança para simplificar o gerenciamento de toda a implantação. Você pode adicionar usuários e grupos por meio do contexto de administração na Web. As permissões são definidas automaticamente com base no grupo de segurança ao qual você adiciona usuários. Ou as permissões são obtidas com base no objeto, projeto, coleção ou nível de servidor ao qual você adiciona grupos.

Os membros do grupo de segurança podem ser uma combinação de usuários, outros grupos e grupos do Microsoft Entra.

Grupos de segurança do Active Directory e do Microsoft Entra

Você pode preencher grupos de segurança adicionando usuários individuais. Mas, para facilitar o gerenciamento, é mais eficiente preencher esses grupos usando a ID do Microsoft Entra para Serviços de DevOps do Azure e grupos de usuários do Active Directory (AD) ou do Windows para o Servidor de DevOps do Azure. Essa abordagem permite que você gerencie a associação e as permissões de grupo com mais eficiência em vários computadores.

Se você precisar gerenciar apenas um pequeno conjunto de usuários, poderá ignorar esta etapa. Mas, se você antecipar que sua organização pode crescer, considere configurar o Active Directory ou o Microsoft Entra ID. Além disso, se você planeja usar serviços extras, é essencial configurar a ID do Microsoft Entra para uso com o Azure DevOps para dar suporte à cobrança.

Observação

Sem a ID do Microsoft Entra, todos os usuários do Azure DevOps devem entrar usando contas da Microsoft e você deve gerenciar o acesso à conta por contas de usuário individuais. Mesmo que você gerencie o acesso à conta usando contas da Microsoft, configure uma assinatura do Azure para gerenciar a cobrança.

Para configurar a ID do Microsoft Entra para uso com os Serviços de DevOps do Azure, consulte Conectar sua organização à ID do Microsoft Entra.

Quando sua organização está conectada ao Microsoft Entra ID, você pode definir e gerenciar várias políticas da organização para aprimorar a segurança e simplificar o acesso aos aplicativos. Para obter mais informações, consulte Sobre segurança, Diretivas de segurança.

Para gerenciar o acesso organizacional com o Microsoft Entra ID, consulte os seguintes artigos:

• Adicionar ou excluir usuários usando o Microsoft Entra ID
• Solucionar problemas de acesso com o Microsoft Entra ID

O Azure DevOps registra as alterações feitas em um grupo do Microsoft Entra dentro de uma hora após essa alteração na ID do Microsoft Entra. Todas as permissões herdadas por meio da associação ao grupo são atualizadas. Para atualizar sua associação ao Microsoft Entra e as permissões herdadas no Azure DevOps, saia e entre novamente ou acione uma atualização para reavaliar sua permissão.

Grupos de usuários válidos

Quando você adiciona contas de usuários diretamente a um grupo de segurança, eles são adicionados automaticamente a um dos seguintes grupos de usuários válidos.

• Usuários válidos da coleção de projetos: todos os membros adicionados a um grupo de nível de organização.
• Usuários válidos do projeto: todos os membros adicionados a um grupo de nível de projeto.

As permissões padrão atribuídas a esses grupos fornecem principalmente acesso de leitura, como Exibir recursos de compilação, Exibir informações em nível de projeto e Exibir informações em nível de coleção.

Todos os usuários que você adiciona a um projeto podem exibir os objetos em outros projetos dentro de uma coleção. Para restringir o acesso à exibição, você pode definir restrições por meio do nó do caminho da área.

Se você remover ou negar a permissão Exibir informações em nível de instância para um dos grupos Usuários Válidos, nenhum membro do grupo poderá acessar o projeto, a coleção ou a implantação, dependendo do grupo definido.

Grupo de usuários com escopo de projeto

Por padrão, os usuários adicionados a uma organização podem exibir todas as informações e configurações da organização e do projeto. Essas configurações incluem a lista de usuários, a lista de projetos, detalhes de cobrança, dados de uso e muito mais, que você pode acessar por meio das configurações da organização.

Importante

• Os recursos de visibilidade limitados descritos nesta seção se aplicam apenas a interações por meio do portal da Web. Com as APIs REST ou azure devops comandos da CLI, os membros do projeto podem acessar os dados restritos.
• Os usuários convidados que são membros do grupo limitado com acesso padrão no Microsoft Entra ID não podem procurar usuários com o seletor de pessoas. Quando o recurso de visualização é desativado para a organização ou quando os usuários convidados não são membros do grupo limitado, os usuários convidados podem pesquisar todos os usuários do Microsoft Entra, conforme o esperado.

Para restringir usuários específicos, como Partes Interessadas, usuários convidados do Microsoft Entra ou membros de um grupo de segurança específico, você pode habilitar o recurso Limitar visibilidade e colaboração do usuário a projetos específicos para a organização. Uma vez habilitado, qualquer usuário ou grupo adicionado ao grupo Usuários com escopo do Projeto é impedido de acessar as páginas de configurações da Organização, exceto Visão Geral e Projetos. Além disso, eles só têm acesso aos projetos aos quais são adicionados.

Aviso

Quando o recurso Limitar a visibilidade e a colaboração do usuário a projetos específicos está habilitado para a organização, os usuários com escopo de projeto não conseguem pesquisar usuários que foram adicionados à organização por meio da associação ao grupo do Microsoft Entra, em vez de por meio de um convite explícito do usuário. Esse é um comportamento inesperado e uma resolução está sendo trabalhada. Para resolver esse problema automaticamente, desabilite o recurso Limitar visibilidade e colaboração do usuário à versão prévia de projetos específicos para a organização.

Para obter mais informações, consulte Gerenciar recursos de versão prévia.

Observação

Os grupos de segurança pertencem ao nível da organização, mesmo que acessem apenas um projeto específico. Alguns grupos podem estar ocultos no portal da Web, dependendo das permissões do usuário. Você pode encontrar todos os nomes de grupo em uma organização com a ferramenta azure devops CLI ou nossas APIs REST. Para obter mais informações, consulte Adicionar e gerenciar grupos de segurança.

Permissões baseadas em função

Com permissões baseadas em função, você atribui contas de usuário ou grupos de segurança a uma função, com cada função atribuída a uma ou mais permissões. Aqui estão as principais funções e links para mais informações.

• Funções de segurança de feed de pacote ou artefato: as funções oferecem suporte a vários níveis de permissão para editar e gerenciar feeds de pacotes.
• Função Gerenciador de extensões do Marketplace: os membros da função Gerenciador podem instalar extensões e responder a solicitações de extensões a serem instaladas.
• Funções de segurança de pipeline: várias funções são usadas para gerenciar recursos de biblioteca, recursos de pipeline em nível de projeto e recursos de pipeline em nível de coleção.
• Função de administrador de equipe Os administradores de equipe podem gerenciar todas as ferramentas de equipe.

Para obter mais informações, consulte Sobre funções de segurança.

A imagem a seguir ilustra como os grupos de segurança definidos no nível do projeto e da coleção podem atribuir permissões a objetos, projetos e à organização.

Os membros dos grupos Administradores de Projeto ou Administradores de Coleção de Projetos podem gerenciar todas as ferramentas de equipe para todas as equipes.

Melhores práticas para permissões

O que fazer:

• Use o Microsoft Entra ID, Active Directory ou grupos de segurança do Windows ao gerenciar muitos usuários.
• Ao adicionar uma equipe, considere quais permissões deseja atribuir a líderes de equipe, scrum masters e outros membros da equipe. Considere quem cria e modifica caminhos de área, caminhos de iteração e consultas.
• Ao adicionar muitas equipes, considere a criação de um grupo personalizado de Administradores de Equipe onde você possa alocar um subconjunto das permissões disponíveis para Administradores de Projeto.
• Considere conceder às pastas de consulta de item de trabalho a permissão Contribuir para usuários ou grupos que exigem a capacidade de criar e compartilhar consultas de item de trabalho para o projeto.

O que não fazer:

• Não adicione usuários a vários grupos de segurança, que contêm 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 .
• Não altere as atribuições padrão feitas aos grupos Usuários Válidos. Se você remover ou definir a permissão Exibir informações no nível da instância como Negar para um dos grupos de usuários válidos, nenhum usuário do grupo poderá acessar o projeto, a coleção ou a implantação, de acordo com o grupo definido.
• Não atribua permissões indicadas como “Atribuir somente a contas de serviço” a contas de usuário.

Recursos de versão preliminar

Os sinalizadores de recursos controlam o acesso para selecionar novos recursos. Periodicamente, o Azure DevOps introduz novos recursos colocando-os atrás de um sinalizador de recurso. Os membros do projeto e os proprietários da organização podem habilitar ou desabilitar os recursos de visualização. Para obter mais informações, consulte Gerenciar ou habilitar recursos.

Próximas etapas

Acesso e permissões padrão

Artigos relacionados

• Solucionar problemas de acesso e permissão
• Sobre segurança, autenticação e autorização
• Referência de permissões e grupos
• Ferramentas de gerenciamento de permissões e segurança
• Adicionar e gerenciar grupos de segurança