Ler em inglês

Compartilhar via


Sobre as permissões e os grupos de segurança

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

Neste artigo, descubra o que são as permissões e os níveis de acesso via herança, grupos de segurança, funções e outros 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.

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 principais de acesso: Stakeholder, Basic e Basic + Test Plans. Use o nível de acesso do Stakeholder para usuários que não precisam de acesso pago. Não use o acesso de Stakeholder como um substituto para permissões mais limitadas, pois os usuários com uma assinatura do Visual Studio ou uma licença do GitHub Enterprise são promovidos automaticamente ao se identificarem. Para mais informações, veja Referência rápida de acesso das partes interessadas.

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. Os grupos de segurança recebem permissões que permitem ou negam acesso aos recursos ou às tarefas.

  • Os membros herdam as permissões atribuídas aos seus respectivos grupos de segurança.
  • As permissões são definidas em níveis diferentes: organização, coleção, projeto ou objeto.
  • Algumas permissões são gerenciadas usando-se 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:

  • Têm a autoridade mais alta dentro de uma organização ou coleção de projetos.
  • Executam todas as operações em toda a coleção.
  • Gerenciam as configurações, as políticas e os processos da organização.
  • Criam e gerenciam todos os projetos e extensões.

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 aos usuários a permissão para executar tarefas específicas e não é herdada da associação ao grupo.
Permitir (herdada) Concede aos membros do grupo a permissão para executar tarefas específicas.
Permitir (sistema) Concede a permissão que tem precedência em relação às permissões do usuário. Não editável e armazenada em um banco de dados de configurações, invisível para os usuários.
Negar Restringe explicitamente a permissão para os usuários executarem tarefas específicas e não é herdada 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 as tarefas que exijam essa permissão, mesmo que ele pertença a um grupo que tenha essa permissão definida como Permitir.
Negar (herdada) Restringe a permissão para os membros do grupo executarem tarefas específicas. Substitui uma permissão Permitir explícita.
Negar (sistema) Restringe a permissão que tem precedência em relação às permissões do usuário. Não editável e armazenada em um banco de dados de configurações, invisível para os usuários.
Não definida Nega implicitamente a permissão de executar tarefas que exigem essa permissão aos usuários, mas permite a associação em um grupo que tenha essa permissão definida para ter 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 elas forem negadas em outro grupo. Os seguintes exemplos 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 exclusão de item de trabalho ou gerenciamento de pipelines, ser membro do grupo Administradores de Coleção de Projetos não substitui a permissão Negar definida em outro lugar.
  • Se um usuário tiver a permissão negada para excluir itens de trabalho em um projeto específico, ele não poderá excluir os itens de trabalho, mesmo que esteja associado ao grupo Administradores de Coleção de Projetos. Da mesma forma, se forem negadas as permissões de pipeline, ele não poderá gerenciar nem executar pipelines, apesar de ter uma função administrativa.

Aviso

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

Herança de permissões

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

Herança de grupo:

  • Os usuários herdam as permissões dos grupos aos quais pertencem.
  • Se um usuário tiver uma permissão Permitir diretamente ou por meio da associação de grupo, mas também tiver uma permissão Negar devido à associação a outro grupo, a permissão Negar terá precedência.
  • Os membros dos grupos Administradores de Coleção de Projetos ou Administradores do Team Foundation retêm a maioria das permissões aceitas, 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:

As permissões no nível do objeto, atribuídas a nós como áreas, iterações, pastas de controle de versão e pastas de consulta de itens de trabalho, são herdadas ao longo da hierarquia.

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

  • As permissões explícitas sempre têm precedência em relação às herdadas.
  • 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 um subnó, 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. Caso haja permissões conflitantes, a permissão mais específica tem a precedência.

Exemplo:

  • Negar explicitamente na "área-1" (nó pai).
  • Permitir explicitamente para "area-1/sub-area-1" (nó filho).
  • Nesse caso, o usuário recebe uma permissão Permitir para a "area-1/sub-area-1", substituindo a permissão Negar herdada do nó pai.

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

Observação

Para habilitar a página da versão preliminar Configurações de permissões do projeto, consulte Habilitar versão prévia dos recursos.

Captura de tela que mostra a caixa de diálogo Permissões, a página da versão preliminar, o link anotado

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

A interface do usuário da versão preliminar da página Configurações de permissões do projeto não está disponível no Azure DevOps Server 2020 e versões anteriores.

Associação e grupos de segurança

Os grupos de segurança atribuem permissões específicas a 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 se cria 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)
  • Quando se adiciona uma equipe, um grupo de segurança de equipe é criado

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 Basic. 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 necessitam de acesso para gerenciar o recurso Azure Test Plans precisam receber acesso Basic + Test Plans de Teste ou Advanced.

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
Equipe - TeamName
- 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
Equipe - TeamName
- 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

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

Para os usuários encarregados de gerenciar os recursos no nível da organização ou da coleção, como os projetos, as políticas, os processos, as políticas de retenção, os pools de agentes, as implantações e as 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ções, permissões e níveis de acesso

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

  • O 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.
  • 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.
  • O Gerenciamento de nível de acesso controla o acesso aos recursos do portal da Web. Com base no que foi adquirido para um usuário, os administradores podem definir o nível de acesso do usuário como Stakeholder, Basic, Basic + Test ou Visual Studio Enterprise (anteriormente conhecido como 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 de acordo com o grupo de segurança ao qual você adiciona usuários. As permissões são obtidas de acordo com o 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:

O Azure DevOps registra as alterações foram feitas em um grupo do Microsoft Entra dentro de uma hora a partir dessa alteração no Microsoft Entra ID. Todas as permissões herdadas via 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:

Instale o Active Directory antes de instalar o Azure DevOps Server.

Grupos de usuários válidos

Quando você adiciona as contas dos usuários diretamente em um grupo de segurança, elas também são adicionadas automaticamente a um dos grupos de usuários válidos abaixo.

  • 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.

Todos os usuários que você adicionar a um projeto podem exibir os objetos em outros projetos dentro de uma coleção. Para restringir o acesso de 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 do nível da instância para um dos grupos de Usuários Válidos, nenhum membro do grupo poderá acessar o projeto, a coleção ou a implantação, dependendo do grupo que você tiver definido.

Grupo de usuários do 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 a lista de usuários, a lista de projetos, os detalhes de cobrança, os 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 a versão prévia do recurso Limitar a visibilidade e a colaboração do usuário a projetos específicos da organização. Depois de habilitado, o usuário ou grupo adicionado ao grupo Usuários do Escopo do Projeto não poderá acessar as páginas das Configurações da organização, exceto por aquelas da visão geral e dos projetos. Além disso, eles só terão acesso aos projetos aos quais forem adicionados.

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. Com as APIs REST ou azure devops comandos 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 mais informações, consulte Gerenciar versão prévia dos recursos.

Observação

Os grupos de segurança são gerenciados no nível da organização, mesmo que sejam usados em 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 CLI do Azure DevOps ou nossas 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 em 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 CLI do Azure DevOps ou nossas 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 em 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 as APIs REST. Para obter mais informações, consulte Adicionar e gerenciar grupos de segurança.

Permissões baseadas em função

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

Para obter mais informações, consulte Sobre as 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 aos objetos, aos projetos e à organização.

Mapeamento de imagem conceitual dos grupos de segurança padrão para os níveis de permissão, nuvem

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.

Mapeamento de imagem conceitual dos grupos de segurança padrão para os níveis de permissão, estrutura local

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

Versão prévia dos recursos

Os sinalizadores de recursos controlam o acesso aos 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 habilitar ou desabilitar a versão prévia dos recursos Para obter mais informações, consulte Gerenciar ou habilitar recursos.

Próximas etapas

Observação: O autor criou este artigo com a ajuda da IA. Saiba mais