Introdução às permissões e acesso

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

Neste artigo, saiba como você pode gerenciar níveis de acesso e permissões por meio de herança, grupos de segurança, funções e muito mais no Azure DevOps. Comece entendendo os seguintes conceitos-chave.

• Sobre as permissões:

  • Todos os usuários adicionados ao Azure DevOps são adicionados a um ou mais grupos de segurança padrão.
  • Os grupos de segurança recebem permissões, que permitemou 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 recursos de pipeline.
  • Os administradores podem definir grupos de segurança personalizados para gerenciar permissões para diferentes áreas funcionais.

• Sobre os níveis de acesso:

  • Todos os usuários adicionados ao Azure DevOps são atribuídos a 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 obter mais informações, veja Referência rápida sobre o acesso de Interveniente.

• Sobre os recursos de visualização:
  • À medida que novos recursos são introduzidos, os usuários podem ativá-los ou desativá-los por meio de recursos de visualização para acessá-los.
  • Um pequeno subconjunto de novos recursos é gerenciado no nível da organização e habilitado ou desabilitado pelos proprietários da organização.

Por exemplo, 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 de Colaboradores fornece acesso de leitura e gravação a repositórios, acompanhamento de trabalho, pipelines e muito mais. O acesso básico fornece acesso a todos os recursos e tarefas para usar os Painéis do Azure, os repositórios do Azure, os Pipelines do Azure e os Artefatos do Azure. Os usuários que precisam de acesso para gerenciar os Planos de Teste do Azure precisam receber Planos de Teste Básicos + ou Avançados.

Os administradores devem ser adicionados ao grupo Administradores da Coleção de Projetos ou Administradores de Projetos. Os administradores gerenciam grupos de segurança e permissões a partir do portal da Web, principalmente a partir das configurações do Project. Os colaboradores também gerenciam permissões para objetos criados a partir do portal da Web.

Para obter uma visão geral das permissões padrão, consulte Referência rápida de permissões padrão.

Grupos de segurança e 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, aos quais são atribuídas 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 de 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 é possível 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

Os seguintes grupos de segurança 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 - Colaboradores - Administradores de Projetos - Utilizadores Válidos do Projeto - Leitores - Administradores de Lançamento - Equipa TeamName	- Administradores de Coleções de Projetos - Administradores de construção de coleção de projetos - Coleção de Projetos Build Service Accounts - Contas de Serviço de Proxy de Coleta de Projetos - Contas de 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 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 de organização ou de nível de 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 nível de usuário, equipe, projeto e organização.

Para obter uma descrição de cada grupo e de cada permissão, consulte Referência de permissões e grupos, Grupos.

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:

• A gestão de associação suporta a adição de contas e grupos de utilizadores individuais a grupos de segurança predefinidos. Cada grupo predefinido está associado a um conjunto de permissões predefinidas. Todos os usuários adicionados a qualquer grupo de segurança são adicionados ao grupo Usuários Válidos. Um utilizador válido é alguém que pode ligar-se a um projeto, coleção ou organização.

• A gestão 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 consulta compartilhada. As configurações de permissão correspondem a Permitir, Negar, Permitir herdado, Negar herdado, Permitir sistema, Negar sistema e Não definir. Para obter mais informações, consulte Herança de permissão e grupos de segurança mais adiante neste artigo.

• O gerenciamento de nível de acesso controla o acesso aos recursos do portal da Web. Com base no que foi comprado 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 utiliza grupos de segurança para simplificar a gestão na implementação. Pode adicionar utilizadores e grupos através do contexto de administração 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 utilizadores, outros grupos e grupos do Microsoft Entra.

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

Você pode preencher grupos de segurança adicionando usuários individuais. No entanto, para facilitar o gerenciamento, é mais fácil preencher esses grupos usando a ID do Microsoft Entra para Serviços de DevOps do Azure e Ative Directory (AD) ou grupos de usuários do Windows para o Servidor de DevOps do Azure. Esse método permite que você gerencie a associação ao grupo e as permissões de forma mais eficiente em vários computadores.

Se você só tem que gerenciar um pequeno conjunto de usuários, então você pode pular esta etapa. No entanto, se você prevê que sua organização pode crescer, convém configurar o Ative Directory ou o Microsoft Entra ID. Além disso, se você planeja pagar por serviços extras, precisará configurar a ID do Microsoft Entra para uso com o Azure DevOps para dar suporte à cobrança.

Nota

Sem o Microsoft Entra ID, 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, precisará configurar 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, há muitas políticas da organização que você pode habilitar ou desabilitar para proteger sua organização. Para obter mais informações, consulte Sobre segurança, autenticação e autorização, Políticas de segurança.

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

• Adicionar ou eliminar utilizadores através do 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. Se você quiser atualizar sua associação ao Microsoft Entra e permissões herdadas no Azure DevOps, saia e entre novamente ou acione uma atualização para reavaliar sua permissão.

Grupos de utilizadores válidos

Quando você adiciona contas de usuários diretamente a um grupo de segurança, elas são adicionadas automaticamente a um dos 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.

As permissões padrão atribuídas a esses grupos são limitadas principalmente ao acesso de leitura, como Exibir recursos de compilação, Exibir informações no nível do projeto e Exibir informações no nível da coleção.

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

Se você remover ou negar a permissão Exibir informações no nível da 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 Usuários com escopo do 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 lista de usuários, lista de projetos, detalhes de cobrança, dados de uso e muito mais que é acessado por meio das configurações da organização.

Importante

• As funcionalidades de visibilidade limitada descritas nesta secção aplicam-se apenas às interações através do portal Web. Com as APIs REST ou azure devops os 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 pesquisar usuários com o seletor de pessoas. Quando o recurso de visualização está 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 selecionados, como Stakeholders, usuários convidados do Microsoft Entra ou membros de um grupo de segurança específico, você pode habilitar o recurso Limitar a visibilidade e a colaboração do usuário a projetos específicos da organização. Uma vez habilitado, qualquer usuário ou grupo adicionado ao grupo Usuários com Escopo do Projeto fica impedido de acessar as páginas de configurações da Organização, exceto Visão Geral e Projetos, e está restrito a acessar apenas os projetos aos quais foram adicionados.

Aviso

Quando o recurso de visualização 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 podem pesquisar usuários que foram adicionados à organização por meio da associação ao grupo Microsoft Entra, em vez de por meio de um convite explícito de usuário. Este é um comportamento inesperado e uma resolução está sendo trabalhada. Para resolver automaticamente esse problema, desative o recurso de visualização Limitar a visibilidade e a colaboração do usuário a projetos específicos para a organização.

Para obter mais informações, consulte Gerenciar recursos de visualização.

Nota

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.

Níveis de acesso

Os níveis de acesso controlam quais recursos são visíveis para os usuários no portal da Web. O acesso depende das licenças de utilizador.

Se você quiser dar a um usuário acesso ao gerenciamento de portfólio Agile ou aos recursos de gerenciamento de casos de teste, altere os níveis de acesso, não as permissões.

Definir o nível de acesso para usuários ou grupos não fornece acesso a um projeto ou ao portal da Web. Somente usuários ou grupos adicionados a uma equipe ou grupo de segurança podem se conectar a um projeto e ao portal da Web. Verifique se os usuários têm as permissões e o nível de acesso de que precisam. Para isso, certifique-se de que eles sejam adicionados ao projeto ou a uma equipe.

Permissões

Conforme mostrado na imagem a seguir, 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 organização.

Para obter uma descrição de cada grupo de segurança padrão, consulte Grupos de segurança, contas de serviço e permissões.

Estados de permissão

Uma permissão pode ter as seguintes atribuições. Concedem ou restringem 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	Description
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 tarefa de executar tarefas específicas.
Permitir (sistema)	Concede permissão que tem precedência antes das permissões de 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 (herdada) ou Negar (herdada).

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ê altera uma permissão para um grupo, ela altera essa permissão para todos os usuários que são membros desse grupo. Dependendo do tamanho do grupo, você pode afetar a capacidade de centenas de usuários de fazer seus trabalhos alterando apenas uma permissão. Portanto, certifique-se de entender os efeitos potenciais antes de fazer uma alteração.

Herança de permissões e grupos de segurança

Algumas permissões são gerenciadas por meio de uma hierarquia. Dentro dessa hierarquia, as permissões podem ser herdadas do pai ou substituídas. Os grupos de segurança atribuem um conjunto de permissões a esses membros do grupo. Por exemplo, os membros do grupo Colaboradores ou do grupo Administradores de Projeto recebem as permissões definidas como Permitidas para esses grupos.

Se uma permissão não for diretamente permitida ou negada para um usuário, ela poderá ser herdada das seguintes maneiras.

• Os usuários herdam permissões dos grupos aos quais pertencem. Quando um usuário tem uma permissão Permitir associação direta ou de grupo, uma permissão Negar associação direta ou de grupo a substitui.

  Membros de Administradores de Coleção de Projetos ou Administradores de Team Foundation mantêm a maioria das permissões permitidas, mesmo que pertençam a outros grupos que negam essas permissões. As permissões de operação de item de trabalho são a exceção a esta regra.

• As permissões de nível de objeto atribuídas para nós de uma hierarquia - áreas, iterações, pastas de controle de versão, pastas de consulta de item de trabalho - são herdadas na hierarquia. Ou seja, as permissões de um usuário definidas como area-1 herdadas pelo area-1/sub-area-1, se a mesma permissão não for explicitamente permitida ou negada para area-1/sub-area-1. Se uma permissão for definida explicitamente para um objeto, como area-1/sub-area-1, o nó pai não será herdado, independentemente de ser negado ou permitido. Se não estiver definido, as permissões para esse nó serão herdadas do ancestral mais próximo que tem a permissão explicitamente definida. Por fim, na hierarquia de objetos, a especificidade supera a herança. Por exemplo, um usuário cujas permissões estão explicitamente definidas como Negar em 'área-1', mas também estão explicitamente definidas como Permitir para 'área-1/sub-área-1' recebe uma Permissão em 'área-1/sub-área-1'.

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

Nota

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 de pré-visualização

É aberta uma nova caixa de diálogo que mostra as informações de herança dessa permissão.

Página atual

É aberta uma nova janela que mostra as informações de herança dessa permissão.

Práticas recomendadas para permissões

Fazer:

• Use grupos de segurança do Microsoft Entra ID, Ative Directory ou Windows ao gerenciar muitos usuários.
• Ao adicionar uma equipe, considere quais permissões você 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 criar um grupo personalizado de Administradores de Equipe onde você pode alocar um subconjunto das permissões disponíveis para Administradores de Projeto.
• 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:

• 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 nos 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 Usuários Válidos, nenhum usuário do grupo poderá acessar o projeto, a coleção ou a implantação, dependendo do grupo definido.
• Não atribua permissões anotadas como "Atribuir apenas a contas de serviço" a contas de usuário.

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 uma ou mais permissões. Aqui estão as funções principais e links para mais informações.

• Funções de segurança de artefato ou feed de pacote: as funções suportam vários níveis de permissão para editar e gerenciar feeds de pacotes.
• Função de gerente de extensão do Marketplace: os membros da função de gerente 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 no nível do projeto e no nível da coleção.
• Função de administrador de equipe Os administradores de equipe são capazes de gerenciar todas as ferramentas de equipe.

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.

Funcionalidades de pré-visualização

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 ativar ou desativar os recursos de visualização. Para obter mais informações, consulte Gerenciar ou habilitar recursos.

Próximos passos

Permissões e acesso padrão

Artigos relacionados

• Solucionar problemas de acesso e permissão
• Sobre segurança, autenticação e autorização
• O que é o Microsoft Entra ID?
• Introdução ao Microsoft Entra ID
• Referência de permissões e grupos
• Ferramentas de segurança e gestão de permissões
• Adicionar usuários a uma organização
• Adicionar e gerenciar grupos de segurança
• Gerenciar tokens, namespaces, permissões
• Como funciona a faturação
• Configurar a cobrança para pagar usuários, pipelines e testes de carga baseados em nuvem no Azure DevOps