Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Serviços Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022
Neste artigo, você aprenderá sobre os níveis de acesso e permissões por meio de herança, grupos de segurança, funções e muito mais no Azure DevOps.
Para obter uma visão geral das permissões padrão, consulte Referência rápida de permissões padrão.
Para obter mais informações, confira Visão geral de segurança.
Para obter orientações de desempenho para grandes organizações, consulte Recomendações de desempenho para permissões.
Dica
Você pode usar a IA para ajudar nas tarefas do Azure DevOps. Confira Habilitar a assistência de IA com o Servidor MCP do Azure DevOps para começar.
Níveis de acesso
Todos os usuários do Azure DevOps têm um nível de acesso, que lhes concede ou restringe o acesso a recursos específicos do portal da Web. Existem três níveis de acesso principais: Stakeholder, Basic e Basic + Test Plans. Para dar acesso aos recursos de gerenciamento do portfólio Agile ou gerenciamento de casos de teste a um usuário, altere os níveis de acesso, em vez das permissões. Para obter mais informações, consulte Sobre os níveis de acesso.
Permissões
Todos os usuários no Azure DevOps pertencem a um ou mais grupos de segurança padrão. Atribua permissões a grupos de segurança que permitem ou negam acesso a recursos ou tarefas.
- Os membros herdam as permissões atribuídas aos seus respectivos grupos de segurança.
- Defina permissões em diferentes níveis: organização/coleção, projeto ou objeto.
- Gerencie algumas permissões usando atribuições baseadas em função (por exemplo, administrador de equipe, gerenciamento de extensões ou funções de recurso de pipeline).
- Os administradores podem definir grupos personalizados de segurança a fim de gerenciar as permissões para áreas funcionais diferentes.
O gerenciamento de permissões no Azure DevOps abrange dois grupos principais: Administradores de Coleção de Projetos e Administradores de Projeto.
Administradores da Coleção de Projetos:
- Tenha amplas permissões administrativas em uma organização ou coleção de projetos.
- Gerenciam as configurações, as políticas e os processos da organização.
- Criar e gerenciar projetos.
Administradores do Projeto:
- Operam no nível do projeto.
- Gerenciam os grupos de segurança e as permissões nas configurações do Projeto no portal da Web.
- Manipular permissões para objetos específicos que os colaboradores criam dentro do projeto.
Estados de permissão
Atribuem as permissões para conceder ou restringir o acesso:
O usuário ou grupo tem permissão:
- Permitir
- Permitir (herdada)
- Permitir (sistema)
O usuário ou grupo não tem permissão:
- Negar
- Negar (herdada)
- Negar (sistema)
- Não definida
| Estado da permissão | Descrição |
|---|---|
| Permitir | Concede explicitamente a permissão ao usuário ou grupo selecionado no escopo atual. |
| Permitir (herdada) | Concede a permissão por meio de um escopo pai ou associação de grupo. |
| Permitir (sistema) | Concede uma permissão que o Azure DevOps gerencia. Você não pode editar permissões do sistema. |
| Negar | Nega explicitamente a permissão para o usuário ou grupo selecionado no escopo atual. |
| Negar (herdada) | Nega a permissão por meio de um escopo pai ou associação de grupo. |
| Negar (sistema) | Nega uma permissão que Azure DevOps gerencia. Você não pode editar permissões do sistema. |
| Não definida | Não concede nem nega a permissão no escopo atual. Outras atribuições aplicáveis determinam a permissão efetiva. |
Azure DevOps calcula as permissões efetivas com base em atribuições diretas, participações em grupos e atribuições herdadas. Quando combina atribuições no mesmo escopo, Negar geralmente tem precedência sobre Permitir. Em uma hierarquia de objetos, uma atribuição explícita em um objeto filho pode substituir o valor herdado de seu pai pela mesma identidade.
Aviso
Quando você modifica uma permissão para um grupo, ela afeta todos os usuários desse grupo. Até mesmo uma única alteração de permissão pode afetar centenas de usuários, portanto, considere os efeitos potenciais antes de fazer qualquer ajuste.
Herança de permissões
As permissões seguem uma hierarquia, ou seja, você pode herdá-las de um nó pai ou substituí-las.
Herança de grupo:
- Os usuários recebem as permissões combinadas dos grupos aos quais pertencem.
- No mesmo escopo, uma negação de um grupo geralmente tem precedência sobre um Allow de outro grupo.
- Não definido não concede ou nega uma permissão e não substitui uma atribuição de outro grupo.
Herança no nível do objeto:
Você atribui permissões no nível do objeto a nodes como áreas, iterações, pastas de controle de versão e pastas de consultas de itens de trabalho. Essas permissões são herdadas na hierarquia.
Regras de hierarquia de objetos:
- As permissões definidas em um nó de nível superior são herdadas por todos os subnós, a menos que explicitamente substituídas.
- Se uma permissão não for explicitamente permitida nem negada para um subnó, ela herdará a permissão de seu pai.
- Se uma permissão for definida explicitamente para uma identidade em um subnodo, o valor herdado do pai para essa identidade não se aplicará ao subnodo.
- Depois de resolver a hierarquia de objetos, Azure DevOps combina as atribuições diretas e de grupo aplicáveis. Uma Negação de outro grupo no escopo resultante ainda pode ter precedência sobre uma Permissão.
Exemplo:
-
Negue explicitamente em
area-1(nó pai). - Permitir explicitamente
area-1/sub-area-1(nó filho). - Nesse caso, o usuário recebe um Allow em
area-1/sub-area-1, substituindo o valor Deny herdado do nó pai.
Para entender por que uma permissão é herdada, selecione Por quê? para essa permissão. Para abrir uma página de segurança , consulte Permissões de exibição.
É aberta uma nova caixa de diálogo que mostra as informações de herança dessa permissão.
Uma nova janela mostra as informações de herança dessa permissão.
Associação e grupos de segurança
Os grupos de segurança atribuem permissões específicas a seus membros.
Quando você cria uma organização, coleção ou projeto, o Azure DevOps cria um conjunto de grupos de segurança padrão e atribui automaticamente permissões padrão a esses grupos. Você define mais grupos de segurança usando as seguintes ações:
- Criando grupos de segurança personalizados nos seguintes níveis:
- Nível do projeto
- Nível da organização ou coleção
- Nível de servidor (somente local)
- Adicionando uma equipe, que cria um grupo de segurança de equipe
Você não pode criar um grupo de segurança no nível do objeto, mas pode atribuir um grupo personalizado a um nível de objeto e atribuir permissões àquele nível. Para obter mais informações, consulte Definir permissões no nível do projeto.
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, rastreamento de trabalho, pipelines e muito mais. O acesso Basic 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 Azure Test Plans exigem Planos Básicos + de Teste ou um benefício de assinatura Visual Studio aplicável.
Os grupos de segurança a seguir são definidos por padrão para cada projeto e organização. Em geral, você adiciona usuários ou grupos aos grupos Leitores, Colaboradores ou Administradores de Projeto.
| Project | Organização ou coleção |
|---|---|
| - Administradores de Build - Colaboradores - Administradores do Projeto - Usuários Válidos do Projeto - Leitores - Administradores de Versão - TeamName Equipe |
- Administradores da Coleção de Projetos - Administradores de Build da Coleção de Projetos - Contas de Serviço de Build da Coleção de Projetos - Contas de Serviço de Proxy da Coleção de Projetos - Contas de Serviço da Coleção de Projetos - Contas de Serviço de Teste da Coleção de Projeto - Usuários Válidos da Coleção de Projetos - Usuários com Escopo do 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 conhecer as atribuições de permissão padrão feitas aos grupos de segurança padrão mais comuns, consulte Permissões e acesso padrão.
Os grupos de segurança a seguir são definidos por padrão para cada projeto e coleção de projetos. Em geral, você adiciona usuários ou grupos aos grupos Leitores, Colaboradores ou Administradores de Projeto.
Adicione apenas as contas de serviço aos grupos de contas de serviço do Azure DevOps. Para entender os grupos de usuários válidos, consulte Grupos de usuários válidos mais adiante neste artigo.
| Nível de projeto | Nível da coleção |
|---|---|
| - Administradores de Build - Colaboradores - Administradores do Projeto - Usuários Válidos do Projeto - Leitores - Administradores de Versão - TeamName Equipe |
- Administradores da Coleção de Projetos - Administradores de Build da Coleção de Projetos - Contas de Serviço de Build da Coleção de Projetos - Contas de Serviço de Proxy da Coleção de Projetos - Contas de Serviço da Coleção de Projetos - Contas de Serviço de Teste da Coleção de Projeto - Usuários Válidos da Coleção de Projetos - Grupo de Serviços de Segurança |
Adicione usuários que gerenciam recursos no nível do projeto ao grupo Administradores do Projeto . Esses recursos incluem equipes, caminhos de área e iteração, repositórios, hooks de serviço e pontos de extremidade de serviços.
Adicione usuários que gerenciam recursos de nível de coleção ou de organização ao grupo Administradores de Coleção de Projetos . Esses recursos incluem projetos, políticas, processos, políticas de retenção, pools de agentes e de implantação, e extensões. Para obter mais informações, consulte Sobre configurações de usuário, equipe, projeto e nível de organização.
Gerenciamento de associações, permissões e níveis de acesso
O Azure DevOps controla o acesso por meio destas três áreas funcionais interconectadas:
- Gerenciamento de associações apoia a adição de contas de usuário individuais e grupos 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 um grupo de segurança também 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.
- Gerenciamento de permissões controla o acesso a tarefas funcionais específicas em níveis diferentes do sistema. As permissões no nível de objeto definem as permissões em um arquivo, uma pasta, um pipeline de build ou uma consulta compartilhada. As configurações de permissão correspondem a Permitir, Negar, Permitir (herdada), Negar (herdada), Permitir (sistema), Negar (sistema) e Não definida.
- Gerenciamento de nível de acesso controla o acesso aos recursos do portal da Web. Com base no licenciamento e na função do usuário, os administradores atribuem Stakeholder, Basic, Basic + Test Plans ou um nível de acesso de assinatura Visual Studio aplicável.
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 de acordo com o grupo de segurança ao qual você adiciona usuários. Ou as permissões são baseadas no nível de objeto, projeto, coleção ou 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.
Os membros do grupo de segurança podem constituir uma combinação de usuários, outros grupos, grupos do Azure Active Directory ou de um Grupo de trabalho.
Você pode criar grupos locais ou grupos do Active Directory (AD) para gerenciar os usuários.
Grupos de segurança do Microsoft Entra e do Active Directory
Você pode adicionar usuários individuais preenchendo os grupos de segurança. Contudo, para facilitar o gerenciamento, é mais eficiente preencher esses grupos usando o Microsoft Entra ID para o Azure DevOps Services e o Active Directory (AD) ou grupos de usuários do Windows para o Azure DevOps Server. Essa abordagem permite que você gerencie a associação e as permissões do grupo de forma mais eficiente em vários computadores.
Se você precisar gerenciar apenas um pequeno grupo de usuários, poderá ignorar essa etapa. Contudo, se você estiver prevendo um crescimento em sua organização, considere configurar o Active Directory ou o Microsoft Entra ID. Além disso, caso você esteja planejando usar os serviços extras, é essencial configurar o Microsoft Entra ID para uso com o Azure DevOps a fim de dar suporte à cobrança.
Observação
Sem o Microsoft Entra ID, todos os usuários do Azure DevOps devem entrar usando as contas Microsoft, e você deve gerenciar o acesso à conta de acordo com as contas de usuário individuais. Mesmo que você gerencie o acesso à conta usando as contas Microsoft, configure uma assinatura do Azure para gerenciar a cobrança.
Para configurar o Microsoft Entra ID para usar com o Azure DevOps Services, consulte Conectar sua organização ao Microsoft Entra ID.
Quando sua organização está conectada ao Microsoft Entra ID, você pode definir e gerenciar várias políticas da organização a fim de aprimorar a segurança e simplificar o acesso aos aplicativos. Para obter mais informações, consulte Sobre as políticas 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 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 de grupo são atualizadas. Para atualizar as permissões herdadas e a associação do Microsoft Entra no Azure DevOps, saia e entre novamente ou dispare uma atualização para reavaliar sua permissão.
Para configurar o Active Directory a fim de usá-lo com o Azure DevOps Server, consulte os seguintes artigos:
- Instalar o recurso Active Directory Domain Services (nível 100)
- Introdução ao recurso Active Directory Domain Services.
Instale o Active Directory antes de instalar o Azure DevOps Server.
Grupos de usuários válidos
Quando você adiciona contas de usuário diretamente a um grupo de segurança, os usuários se tornam automaticamente parte de 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 no nível da organização.
- Usuários Válidos do Projeto: todos os membros adicionados a um grupo no nível do projeto.
- Servidor\Usuários Válidos do Azure DevOps: todos os membros adicionados aos grupos do nível do servidor.
- ProjectCollectionName\Usuários Válidos da Coleção de Projetos: todos os membros adicionados aos grupos do nível da coleção.
- ProjectName\Usuários Válidos do Projeto: todos os membros adicionados aos grupos do nível do projeto.
As permissões padrão atribuídas a esses grupos fornecem principalmente acesso de leitura, como Exibir recursos de build, Exibir informações no nível do projeto e Exibir informações no nível da coleção.
Para acessar os recursos do projeto, um usuário precisa exibir informações no nível do projeto e todas as permissões necessárias para o recurso específico. Permissões de caminho de área controlam o acesso aos itens de trabalho e artefatos de teste dentro de um projeto; elas não controlam se um usuário pode acessar um projeto. Não altere as permissões padrão para um grupo de Usuários Válidos. Negar a exibição de informações no nível do projeto, exibir informações no nível da coleção ou exibir informações no nível da instância para um desses grupos pode bloquear todos os seus membros do escopo correspondente.
Grupo de usuários do escopo do projeto
Por padrão, os usuários que você adiciona a uma organização podem exibir informações de organização e projeto além dos projetos dos quais eles são membros.
Para restringir usuários específicos, como Stakeholders, usuários convidados do Microsoft Entra ou membros de um grupo de segurança específico, você pode habilitar a versão prévia do recurso Limitar a visibilidade e a colaboração do usuário a projetos específicos da organização. Quando você habilita esse recurso, usuários e grupos no grupo Project-Scoped Usuários podem acessar apenas os projetos aos quais você os adiciona explicitamente. O recurso também limita o acesso dessas pessoas às configurações e identidades da organização nos seletores de pessoas.
Aviso
Considere as seguintes limitações ao usar este recurso de visualização:
- Os recursos de visibilidade limitados descritos nesta seção se aplicam apenas a interações por meio do portal da Web. Usando as APIs REST ou
az devopscomandos da CLI, os membros do projeto podem acessar os dados restritos. - Os usuários do grupo limitado só podem selecionar usuários que são adicionados explicitamente ao Azure DevOps e não aos usuários que têm acesso por meio da associação de grupo do Microsoft Entra.
- 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.
Para obter etapas e limitações de instalação, consulte Limitar a visibilidade do usuário.
Observação
Os grupos de segurança são gerenciados no nível da organização, mesmo que sejam usados para projetos específicos. Dependendo das permissões do usuário, alguns grupos podem ficar ocultos no portal da Web. Para exibir todos os nomes de grupo em uma organização, você pode usar a ferramenta da CLI do Azure DevOps ou as APIs REST. Para obter mais informações, consulte Adicionar e gerenciar grupos de segurança.
Observação
Os grupos de segurança são gerenciados no nível da coleção, mesmo que sejam usados para projetos específicos. Dependendo das permissões do usuário, alguns grupos podem ficar ocultos no portal da Web. Para exibir todos os nomes de grupo em uma coleção, você pode usar a ferramenta da CLI do Azure DevOps ou as 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 e cada função tem uma ou mais permissões. Os recursos a seguir dão suporte a permissões baseadas em função:
- Funções de segurança de feed de pacotes ou do Artifact
- Função de gerente de extensões do Marketplace
- Funções de segurança de pipeline
- Função de administrador da equipe
Para obter mais informações, consulte Sobre funções de segurança de pipeline.
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 aos objetos, aos projetos e à organização.
A imagem a seguir ilustra como os grupos de segurança definidos no nível do projeto e da coleção podem ser atribuídos a permissões atribuídas no nível do objeto, do projeto e da coleção. Você só pode definir grupos de segurança do nível do servidor para as permissões do nível do servidor.
Membros dos grupos Administradores de Projetos ou Administradores de Coleção de Projetos gerenciam todas as ferramentas de equipe para todas as equipes.
Versão prévia dos recursos
Os recursos de visualização fornecem acesso antecipado à funcionalidade antes que ela fique disponível em geral. Os usuários podem gerenciar recursos de visualização oferecidos no nível do usuário. Os membros do grupo administradores de coleção Project podem gerenciar recursos de visualização no nível da organização em Azure DevOps Services e recursos de visualização no nível da coleção em Azure DevOps Server. Para obter mais informações, consulte Gerenciar ou habilitar recursos.