Sobre permissões e grupos de segurança

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

Neste artigo, aprende sobre níveis de acesso e permissões através 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 mais informações, consulte Descrição geral de Segurança.

Sugestão

Pode usar IA para ajudar com tarefas do Azure DevOps. Consulte Habilitar assistência de IA com Azure DevOps MCP Server para começar.

Níveis de acesso

Todos os usuários do Azure DevOps têm um nível de acesso, que concede ou restringe o acesso a recursos específicos do portal da Web. Existem três níveis principais de acesso: Stakeholder, Basic e Basic + Test Plans. Para dar a um usuário acesso aos recursos de gerenciamento de portfólio Agile ou gerenciamento de casos de teste, altere os níveis de acesso, não as permissões. Para obter mais informações, consulte Sobre níveis de acesso.

Permissões

Todos os usuários no Azure DevOps pertencem a um ou mais grupos de segurança padrão. Atribuir permissões a grupos de segurança que permitam ou neguem o acesso a funcionalidades ou tarefas.

• Os membros herdam as permissões atribuídas ao seu grupo de segurança.
• Defina permissões em diferentes níveis: organização/coleção, projeto ou objeto.
• Gerencie algumas permissões por meio de atribuições baseadas em funções (por exemplo, administrador de equipa, gestão de extensões ou funções de recursos de pipeline).
• Os administradores podem definir grupos de segurança personalizados para gerenciar permissões para diferentes áreas funcionais.

O gerenciamento de permissões no Azure DevOps envolve dois grupos principais: Administradores de Coleção de Projetos e Administradores de Projeto.

Administradores da coleção de projetos:

• Possuir a mais alta autoridade dentro de uma organização ou coleção de projetos.
• Execute todas as operações para toda a coleção.
• Gerencie configurações, políticas e processos para a organização.
• Crie e gerencie todos os projetos e extensões.

Administradores de Projeto:

• Operar ao nível do projeto.
• Gerencie grupos de segurança e permissões a partir das configurações do Project no portal da Web.
• Manipule permissões para objetos específicos que os colaboradores criam dentro do projeto.

Estados de autorização

Atribua permissões para conceder ou restringir acesso:

O usuário ou grupo tem permissão:

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

O usuário ou grupo não tem permissão:

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

Estado de permissão	Descrição
Permitir	Concede explicitamente aos utilizadores a capacidade de realizar tarefas específicas, e não é herdado da pertença ao grupo.
Permitir (herdado)	Concede aos membros do grupo a capacidade de realizar tarefas específicas.
Permitir (sistema)	Concede permissões que têm precedência sobre as permissões dos utilizadores. 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 as permissões que têm precedência sobre as permissões dos utilizadores. 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).

Os membros dos grupos Administradores de Coleção de Projetos ou Administradores do Team Foundation sempre podem receber permissões, mesmo se negadas em outro grupo. Os exemplos a seguir explicam melhor esse cenário:

• Um usuário ainda pode acessar as configurações do projeto ou gerenciar usuários. No entanto, para tarefas como eliminação de item de trabalho ou gestão de pipeline, ser membro do grupo de Administradores de Coleção de Projetos não substitui as permissões negadas definidas noutra parte.
• Se for negada a um usuário permissão para excluir itens de trabalho em um projeto específico, ele não poderá excluir itens de trabalho, mesmo que faça parte do grupo Administradores de Coleção de Projetos. Da mesma forma, se as permissões de pipeline forem negadas, não poderão gerir ou executar pipelines, apesar de terem uma função administrativa.

Aviso

Quando modificas uma permissão para um grupo, isso afeta todos os utilizadores desse grupo. Mesmo uma única alteração de permissão pode afetar centenas de utilizadores, por isso considere os potenciais efeitos antes de fazer qualquer ajuste.

Herança de permissões

As permissões seguem uma hierarquia, o que significa que pode herdar permissões de um nó pai ou sobrepô-las.

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 da associação ao grupo, mas também tiver uma permissão Negar por meio de outro grupo, a permissão Negar terá precedência.
• 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 (exceto para operações de item de trabalho).

Herança no nível do objeto:

Atribuem-se permissões a nível de objeto a nós, como áreas, iterações, pastas de controlo de versões e pastas de consulta de itens de trabalho. Estas permissões são herdadas para baixo na hierarquia.

Regras de herança e especificidade de permissão:

• As permissões explícitas sempre têm precedência sobre as herdadas.
• As permissões definidas num nó de nível superior são herdadas por todos os subnodos, a menos que sejam explicitamente substituídas.
• Se uma permissão não for explicitamente permitida ou negada para um subnódo, ela herdará a permissão de seu pai.
• Se uma permissão for explicitamente definida para um subnó, a permissão do progenitor não é herdada, independentemente de ser permitida ou recusada.

Especificidade:

Na hierarquia de objetos, a especificidade supera a herança. A permissão mais específica tem precedência se existirem permissões conflitantes.

Exemplo:

• Explicitamente negar em area-1 (nó pai).
• Explicitamente Permitir para area-1/sub-area-1 (nó filho).
• Neste caso, o utilizador recebe uma permissão de Permitir em area-1/sub-area-1, anulando o Negar herdado do nó pai.

Para perceber porque é que uma permissão é herdada, faça uma pausa sobre uma definição de permissão e depois selecione Porquê? Para abrir uma página de Segurança , consulte Ver permissões.

Nota

Para habilitar a página de visualização das configurações de Permissões do Projeto, consulte como Habilitar funcionalidades 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

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

Grupos de segurança e membros

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

Quando cria uma organização, coleção ou projeto, o Azure DevOps cria um conjunto de grupos de segurança predefinidos e atribui automaticamente permissões predefinidas a esses grupos. Define mais grupos de segurança usando as seguintes ações:

• Criação de 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)
• Adicionar uma equipa, que cria um grupo de segurança de equipa

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

A maioria dos utilizadores do Azure DevOps é adicionada ao grupo de segurança Contributors 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 utilizadores que necessitam de acesso para gerir Planos de Teste Azure necessitam de Planos Básicos + Testes ou Acesso Avançado .

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.

Projeto

Organização ou Coleção

- Administradores de Build - Colaboradores - Administradores de Projetos - Utilizadores Válidos do Projeto - Leitores - Administradores de Lançamento - TeamName Equipa

- Administradores de Coleções de Projetos - Administradores de construção de coleção de projetos - Contas de Serviço de Compilação da Coleção de Projetos - Contas de Serviço de Proxy para Coleção de Projetos - Contas de Serviço de Cobrança de Projetos - Contas de Serviço de Teste de Coleta de Projetos - Utilizadores Válidos da Coleção de Projetos - 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 informações sobre as atribuições de permissões padrão feitas aos grupos de segurança padrão mais comuns, veja Permissões e acesso padrão.

Adicione utilizadores que gerem funcionalidades a nível de projeto ao grupo de Administradores de Projeto . Estas funcionalidades incluem equipas, caminhos de área e caminhos de iteração, repositórios, ganchos de serviço e endpoints de serviço.

Adicione utilizadores que gerem funcionalidades ao nível da organização ou da coleção ao grupo de Administradores da Coleção do Projeto . Estas funcionalidades incluem projetos, políticas, processos, políticas de retenção, pools de agentes e de implementação, e extensões. Para obter mais informações, consulte Sobre configurações de nível de usuário, equipe, projeto e 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:

• 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 definições de permissão correspondem a Permitir, Negar, Permitir herdado, Negar herdado, Permitir de sistema, Negar de sistema e Não definido.
• O gerenciamento de nível de acesso controla o acesso aos recursos do portal da Web. Com base no que é comprado para o utilizador, os administradores definem o nível de acesso do utilizador para 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 baseiam-se no objeto, projeto, coleção ou nível de servidor ao qual adicionas 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. Mas, para facilitar o gerenciamento, é mais eficiente preencher esses grupos usando o Microsoft Entra ID para Serviços de DevOps do Azure e grupos de usuários do Ative 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 do grupo de forma mais eficaz em vários computadores.

Se você só precisa gerenciar um pequeno conjunto de usuários, você pode pular esta etapa. Mas, se você prevê que sua organização pode crescer, considere configurar o Ative 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.

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, 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 melhorar a segurança e simplificar o acesso aos aplicativos. Para obter mais informações, consulte Sobre segurança, 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 regista alterações feitas a um grupo Microsoft Entra dentro de uma hora após essa alteração no Microsoft Entra ID. Quaisquer permissões herdadas via pertença ao grupo são atualizadas. Para 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 adiciona contas de utilizador diretamente a um grupo de segurança, os utilizadores passam automaticamente a fazer parte de um dos seguintes grupos de utilizadores 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 fornecem principalmente 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. Para restringir o acesso de visualização, pode definir restrições através do nó do caminho da área. Se remover ou negar a permissão de informação ao nível da Vista para um dos grupos de Utilizadores Válidos, nenhum membro do grupo pode aceder ao projeto, coleção ou implementação, dependendo do grupo que definir.

Grupo de utilizadores com âmbito de projeto

Por padrão, os utilizadores que adicionar a uma organização podem ver todas as informações e definiçõ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.

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 o recurso Limitar a visibilidade e a colaboração do usuário para projetos específicos da organização. Uma vez ativado, qualquer utilizador ou grupo que adicione ao grupo de Utilizadores com âmbito de Projeto não pode aceder às páginas de definições da Organização , exceto para Visão Geral e Projetos. Eles só têm acesso aos projetos aos quais os adicionas.

Aviso

Considere as seguintes limitações ao usar esse recurso de visualização:

• 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 no grupo limitado só podem selecionar usuários que são explicitamente adicionados ao Azure DevOps e não usuários que têm acesso por meio da associação ao grupo Microsoft Entra.
• 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.

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

Nota

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 estar ocultos no portal da Web. Para exibir todos os nomes de grupo em uma organização, você pode usar a ferramenta CLI do Azure DevOps ou 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 papéis, atribui-se contas de utilizador ou grupos de segurança a uma função, e cada função tem uma ou mais permissões. Os seguintes recursos suportam permissões baseadas em funções:

• Funções de segurança de artefactos ou fluxos de pacotes
• Função de Gestor de Extensão do Marketplace
• Funções de segurança em pipelines
• 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 a objetos, projetos e à organização.

Mapeamento conceitual de grupos de segurança por defeito para níveis de permissões, nuvem.

Os membros dos grupos de Administradores de Projetos ou Administradores de Colecções de Projetos gerem todas as ferramentas de equipa para todas as equipas.

Funcionalidades de pré-visualização

Os sinalizadores de recursos controlam o acesso a novos recursos. O Azure DevOps apresenta periodicamente novos recursos por trá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óximo passo

Permissões e acesso padrão

Conteúdo relacionado

• Solucionar problemas de acesso e permissão
• Saiba mais sobre segurança, autenticação e autorização
• Permissões de referência e grupos
• Adicionar e gerenciar grupos de segurança