Introdução às permissões, ao acesso e aos grupos de segurança

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server | 2019 TFS 2018

Quando se trata de acessar um recurso de Azure DevOps, é útil entender os conceitos principais a seguir.

  • Sobre permissões:

    • Todos os usuários adicionados a Azure DevOps são adicionados a um ou mais grupos de segurança padrão.
    • Os grupos de segurança são permissões atribuídas, que permitem ou negam o 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.
  • Sobre os níveis de acesso:

    • Todos os usuários adicionados a Azure DevOps são atribuídos a um nível de acesso, que concede ou restringe o acesso a recursos de portal da Web selecionados.
    • Há três níveis de acesso principais: Stakeholder, Basic e Basic + Test Plans.
    • O acesso de stakeholders fornece acesso gratuito a um número ilimitado de usuários para um conjunto limitado de recursos. Para obter detalhes, consulte referência rápida de acesso do Stakeholder.
  • Sobre os recursos de visualização:
    • À medida que novos recursos são introduzidos, os usuários podem habilitá-los ou desabilitá-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 Azure DevOps são adicionados ao grupo de segurança Colaboradores e recebem o nível de acesso Básico. O grupo 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 Azure Boards, Azure Repos, Azure Pipelines e Azure Artifacts. Os usuários que precisam de acesso para gerenciar Azure Test Plans precisam ter acesso básico + Test Plans ou avançado.

Os administradores devem ser adicionados ao grupo administradores de coleção Project ou administradores de Project. Os administradores gerenciam grupos de segurança e permissões do portal da Web, principalmente das configurações de Project. Os colaboradores também gerenciam permissões para objetos criados no 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 associação

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

  • Ao criar grupos de segurança personalizados nos seguintes níveis:
    • nível Project
    • 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

Dica

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 a esse nível. Para saber mais sobre permissões no nível do objeto, consulte Definir permissões no nível do objeto.

Grupos de segurança padrão

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

Project Organização ou coleção
– Criar Administradores
- Colaboradores
– administradores de Project
– Project usuários válidos
- Leitores
– Administradores de versão
- TeamName Equipe
– administradores da coleção Project
- administradores de build de coleção Project
- Project Contas de Serviço de Build de Coleção
- Project Contas de Serviço proxy de coleção
– contas de serviço de coleção de Project
– contas de serviço de teste de coleção de Project
– Project usuários válidos da coleção
– usuários do Project-Scoped
- 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 para os 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. Normalmente, você adiciona usuários ou grupos aos grupos Leitores, Colaboradores ou Administradores de Project.

Observação

A lista a seguir indica os grupos mais recentes definidos para o TFS 2017 e versões posteriores. Para versões anteriores do Azure DevOps, a lista pode ser diferente. Adicione apenas contas de serviço a Azure DevOps grupos de contas de serviço. Para entender os grupos de usuários válidos, consulte grupos de usuários válidos mais adiante neste artigo.

Nível de Project Nível de coleção
– Criar Administradores
- Colaboradores
– administradores de Project
– Project usuários válidos
- Leitores
– Administradores de versão
- TeamName Equipe
– administradores da coleção Project
- administradores de build de coleção Project
- Project Contas de Serviço de Build de Coleção
- Project Contas de Serviço proxy de coleção
– contas de serviço de coleção de Project
– contas de serviço de teste de coleção de Project
– Project usuários válidos da coleção
- Grupo de Serviços de Segurança

Dica

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 do Project. Para os usuários encarregados de gerenciar recursos de nível de organização ou coleção , como projetos, políticas, processos, políticas de retenção, pools de agente e implantação e extensões, adicione-os ao grupo administradores de coleção Project. Para saber mais, consulte Sobre configurações de usuário, equipe, projeto e nível de organização.

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

Associação, permissão e gerenciamento de nível de acesso

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

  • O gerenciamento de associações dá suporte à adição de contas e grupos de usuários 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 é alguém que pode se conectar a um projeto, coleção ou 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 build ou uma consulta compartilhada. As configurações de permissão correspondem a Permitir, Negar, Permitir Herdado, Negar Herdado e Não definir. Para saber mais sobre herança, consulte a herança de permissão e os 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 avançado).

Cada área funcional usa grupos de segurança para simplificar o gerenciamento em toda a implantação. Você adiciona usuários e grupos por meio do contexto de administração da Web. As permissões são definidas automaticamente com base no grupo de segurança ao qual você adiciona usuários ou com base 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 Azure Active Directory.

Os membros do grupo de segurança podem ser uma combinação de usuários, outros grupos e grupos do Active Directory ou um grupo de trabalho.

Você pode criar grupos locais ou grupos do Active Directory (AD) para gerenciar seus usuários.

Grupos de segurança do Active Directory e Azure Active Directory

Você pode popular grupos de segurança adicionando usuários individuais. No entanto, para facilitar o gerenciamento, será mais fácil se você preencher esses grupos usando Azure Active Directory (Azure AD) para Azure DevOps Services e Active Directory (AD) ou Windows grupos de usuários para Azure DevOps Server. Esse método permite que você gerencie a associação de grupo e as permissões de forma mais eficiente em vários computadores.

Se você precisar gerenciar apenas um pequeno conjunto de usuários, poderá ignorar essa etapa. No entanto, se você prever que sua organização pode crescer, talvez você queira configurar o AD ou o Azure AD. Além disso, se você planeja pagar por serviços extras, precisará configurar o Azure AD para uso com Azure DevOps para dar suporte à cobrança.

Observação

Sem o Azure AD, todos os usuários 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 Azure Active Directory para uso com Azure DevOps Services, consulte Conexão sua organização para Azure Active Directory.

Observação

Quando sua organização está conectada a Azure Active Directory, há várias políticas de organização que você pode habilitar ou desabilitar para proteger sua organização. Para saber mais, consulte Sobre segurança, autenticação e autorização, políticas de segurança.

Para gerenciar o acesso organizacional com o Azure AD, consulte os seguintes artigos:

Para configurar o Active Directory para uso com Azure DevOps Server, consulte os seguintes artigos:

Normalmente, você deve instalar o Active Directory antes de instalar Azure DevOps Server.

Grupos de usuários 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.

  • Project Collection Valid Users: todos os membros adicionados a um grupo no nível da organização.
  • Project Usuários Válidos: todos os membros adicionados a um grupo no nível do projeto.
  • Servidor\Azure DevOps Usuários Válidos: todos os membros adicionados a grupos no nível do servidor.
  • ProjectCollectionName\Project Collection Valid Users: todos os membros adicionados a grupos no nível da coleção.
  • ProjectName\Project Usuários Válidos: todos os membros adicionados a grupos no nível do projeto.
  • Server\Team Foundation Valid Users: todos os membros adicionados a grupos no nível do servidor.
  • ProjectCollectionName\Project Collection Valid Users: todos os membros adicionados a grupos no nível da coleção.
  • ProjectName\Project Usuários Válidos: todos os membros adicionados a grupos 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 build, exibir informações no nível do projeto e exibir informações no nível da coleção.

Isso significa que 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ó de caminho da área.

Se você remover ou negar a permissão de informações no 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 definido.

grupo de usuários com escopo Project

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. Isso inclui a exibição de lista de usuários, lista de projetos, detalhes de cobrança, dados de uso e muito mais acessados por meio da Organização Configurações.

Para restringir usuários selecionados, como Stakeholders, Azure Active Directory usuários convidados ou membros de um grupo de segurança específico, você pode habilitar o recurso de visualização de projetos específicos para a organização. Depois que isso estiver habilitado, qualquer usuário ou grupo adicionado ao grupo usuários com escopo Project, será impedido de acessar as páginas do Configurações da Organização, exceto para Visão Geral e Projetos; e ficam restritos a acessar apenas os projetos aos quais foram adicionados.

Para habilitar esse recurso, consulte Gerenciar ou habilitar recursos.

Observação

Todos os grupos de segurança são entidades de nível de organização, mesmo os grupos que só têm permissões para um projeto específico. No portal da Web, a visibilidade de alguns grupos de segurança pode ser limitada com base nas permissões do usuário. No entanto, você pode descobrir os nomes de todos os grupos em uma organização usando a ferramenta de CLI devops do azure ou nossas APIs REST. Para saber mais, consulte Adicionar e gerenciar grupos de segurança.

Observação

Todos os grupos de segurança são entidades de nível de coleção, mesmo os grupos que só têm permissões para um projeto específico. No portal da Web, a visibilidade de alguns grupos de segurança pode ser limitada com base nas permissões do usuário. No entanto, você pode descobrir os nomes de todos os grupos em uma organização usando a ferramenta de CLI devops do azure ou nossas APIs REST. Para saber mais, consulte Adicionar e gerenciar grupos de segurança.

Observação

Todos os grupos de segurança são entidades de nível de coleção, mesmo os grupos que só têm permissões para um projeto específico. No portal da Web, a visibilidade de alguns grupos de segurança pode ser limitada com base nas permissões do usuário. No entanto, você pode descobrir os nomes de todos os grupos em uma organização usando as APIs REST. Para saber mais, 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 e dependem de licenças de usuário; as permissões controlam a capacidade de um usuário de se conectar a Azure DevOps e usar recursos em Azure DevOps. Se você estiver tentando dar a alguém acesso aos recursos de gerenciamento de portfólio do Agile ou de gerenciamento de casos de teste, você desejará alterar os níveis de acesso, não as permissões.

Definir o nível de acesso para usuários ou grupos não lhes 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. Você faz isso certificando-se de que eles foram 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.

Conceptual image mapping default security groups to permission levels, cloud

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 de objeto, projeto e coleção. Você só pode definir grupos de segurança no nível do servidor para permissões no nível do servidor.

Conceptual image mapping default security groups to permission levels, on-premises

Conceptual image of security groups and permission levels, TFS-2018 and earlier versions

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

Há cinco atribuições possíveis feitas em uma permissão. Eles concedem ou restringem o acesso, conforme indicado.

  • O usuário ou grupo tem permissões para executar uma tarefa:
    • Permitir
    • Permissão herdada
  • O usuário ou grupo não tem permissão para executar uma tarefa:
    • Deny
    • Negação herdada
    • Não definido

Aqui está o que você precisa saber sobre as configurações de permissão:

  • Permitir ou negar concede explicitamente ou restringe os usuários de executar tarefas específicas e geralmente são herdados da associação de grupo.

  • Não definido nega implicitamente aos usuários a capacidade de executar tarefas que exigem essa permissão, mas permite que a associação em um grupo que tenha essa permissão definida para ter precedência, também conhecida como Permitir (herdada) ou Permitir Herdado e Negar (herdado) ou Negar Herdado.

  • Para a maioria dos grupos e quase todas as permissões, Deny substitui Allow. Se um usuário pertence a dois grupos e um deles tem uma permissão específica definida para Negar, esse usuário não poderá executar tarefas que exigem essa permissão, mesmo que pertença a um grupo que tenha essa permissão definida como Permitir.

    Em alguns casos, os membros dos Project Administradores de Coleção ou grupos de Administradores da Team Foundation podem sempre obter a permissão mesmo se tiverem essa permissão negada em um grupo diferente. Em outros casos, como exclusão de item de trabalho ou pipelines, ser membro de administradores de coleção de projetos não ignora permissões de negação definidas em outro lugar.

  • Alterar uma permissão para um grupo altera essa permissão para todos os usuários que são membros desse grupo. Em outras palavras, alterando uma permissão, dependendo do tamanho do grupo, você pode afetar a capacidade de centenas de usuários realizarem seus trabalhos. Portanto, certifique-se de que entendeu o possível impacto antes de fazer uma mudança.

Herança de permissão 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, membros do grupo Colaboradores ou Project grupo Administradores recebem as permissões definidas como Permitidas para esses grupos.

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

  • Os usuários herdam permissões dos grupos aos quais pertencem. Quando uma permissão é permitida para um usuário diretamente ou por meio da associação em um grupo que tem essa permissão e é negada, diretamente ou por meio da associação ao grupo, a permissão é negada.

    Membros de Project Administradores de Coleção 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. As permissões de operação do item de trabalho são a exceção a essa regra.

  • As permissões no nível do 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 area-1 em são herdadas, area-1/sub-area-1se 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 definida explicitamente. Por fim, na hierarquia de objetos, a especificidade supera a herança. Por exemplo, um usuário cujas permissões são definidas explicitamente como Negar em 'área-1', mas também estão explicitamente definidas como Permitir 'area-1/sub-area-1' receberá, em última análise, uma Permissão em 'área-1/sub-área-1'.

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

Observação

Para habilitar a nova interface do usuário para a página Configurações permissões de Project, consulte Habilitar recursos de visualização.

Permissions dialog, preview page, Why link annotated.

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

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

Ao atribuir permissões

O que fazer:

  • Use Azure Active Directory, Active Directory ou Windows grupos de segurança ao gerenciar muitos usuários.
  • Ao adicionar equipes, considere quais permissões você deseja atribuir a líderes de equipe, scrum masters e outros membros da equipe que talvez precisem criar e modificar caminhos de área, caminhos de iteração e consultas.
  • Ao adicionar muitas equipes, considere a criação de um grupo personalizado administradores de equipe em que você aloca um subconjunto das permissões disponíveis para Project Administradores.
  • Considere conceder às 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.

O que não fazer:

  • Não adicione usuários a vários grupos de segurança que contenham níveis de permissão diferentes. Em determinados casos, um nível de permissão Deny pode substituir um nível de permissão Permitir .
  • Não altere as atribuições padrão feitas para os grupos de usuários válidos. Se você remover ou definir a permissão de informações no nível da instância de Exibição como Negar para um dos grupos usuários válidos, nenhum usuário no grupo poderá acessar o projeto, a coleção ou a implantação, dependendo do grupo definido.
  • Não atribua permissões que são anotadas como "Atribuir somente 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 principais funções e links para saber mais.

  • Funções de segurança de artefato ou feed de pacote: as funções dão 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 Manager podem instalar extensões e responder a solicitações para que as extensões sejam 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.

    Observação

    Os membros dos Project Administradores ou Project grupos administradores de coleção podem gerenciar todas as ferramentas de equipe para todas as equipes.

Versão prévia dos recursos

O acesso à seleção, novos recursos são controlados por sinalizadores de recursos. Periodicamente, Azure DevOps Services apresenta novos recursos colocando-os atrás de um sinalizador de recurso. Os recursos de visualização podem ser habilitados ou desabilitados por membros do projeto ou proprietários da organização. Para saber mais, consulte Gerenciar ou habilitar recursos.

Próximas etapas