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 – TFS 2013

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

  • todos os usuários adicionados ao Azure DevOps normalmente são adicionados a um ou mais grupos de segurança.
  • Os grupos de segurança recebem permissões que permitem ou negam o acesso a um recurso.
  • Os membros do grupo de segurança herdam as permissões atribuídas ao grupo.
  • Cada usuário também recebe um nível de acesso que concede ou restringe o acesso para selecionar recursos do portal da Web.
  • As permissões são definidas em vários níveis para a maioria dos objetos, como repositórios, pipelines, caminhos de área e assim por diante.
  • Outras permissões são gerenciadas por meio de atribuições baseadas em função, como função de administrador de equipe, função de gerenciamento de extensão e várias funções de recurso de pipeline.
  • E, finalmente, à medida que novos recursos forem introduzidos, talvez seja necessário habilitar o sinalizador de recursos para acessá-los.

Por exemplo, os colaboradores individuais são adicionados ao grupo de segurança colaboradores, que fornece acesso de leitura e gravação a repositórios, controle de trabalho, pipelines e muito mais. Além disso, os colaboradores recebem principalmente acesso básico. se eles precisarem de acesso aos serviços de teste, eles poderão receber acesso avançado ou básico + Test Plans. As permissões podem se aplicar a um projeto ou objetos específicos no projeto, como repositórios git, branches, pipelines, caminhos de área e muito mais. Ou, eles podem se aplicar a uma organização ou coleção inteira. Cada área funcional usa grupos de segurança para simplificar o gerenciamento na implantação.

Os administradores gerenciam grupos de segurança e permissões do contexto de administração do portal da Web. Os colaboradores gerenciam permissões para objetos que eles criam ou são proprietários do portal da Web também. As permissões são definidas automaticamente com base no grupo ao qual você adiciona usuários ou com base no objeto, projeto, coleção ou nível de servidor ao qual você adiciona usuários ou grupos.

Para saber mais, examine as informações fornecidas neste artigo e os seguintes artigos:

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 atribuídos automaticamente às permissões padrão. Grupos de segurança adicionais são definidos com as seguintes ações:

  • Quando você adiciona um grupo de segurança personalizado. Você pode criar grupos de segurança personalizados nos seguintes níveis:
    • Nível de objeto, como para pipelines, repositórios, caminhos de área e muito mais
    • nível de Project
    • Nível da organização ou da coleção
    • Nível de servidor (somente local)
  • Quando você adiciona uma equipe, um grupo de segurança de equipe é criado

Azure DevOps controla o acesso por essas três áreas funcionais interconectadas:

  • O Gerenciamento de associação dá suporte à adição de grupos e contas de usuário individuais a grupos de segurança padrão. Cada grupo padrão é 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, uma coleção ou uma organização.

  • O Gerenciamento de permissões controla o acesso a tarefas funcionais específicas em diferentes níveis do sistema. Permissões de nível de objeto definem permissões em um arquivo, pasta, pipeline de compilação ou uma consulta compartilhada. As configurações de permissão correspondem a permitir, negar, permitir herdado, negação herdadae não definido. Para saber mais sobre herança, 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 fornecidos por meio do portal da Web, o aplicativo web para Azure DevOps. com base no que foi adquirido para um usuário, os administradores definem o nível de acesso do usuário para básico, básico + teste, VS Enterprise (anteriormente avançado) ou Stakeholder.

Cada área funcional usa grupos de segurança para simplificar o gerenciamento na 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 de Azure Active Directory.

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

Você pode criar grupos locais ou Active Directory (AD) para gerenciar seus usuários. Se você decidir usar grupos, verifique se a associação nesses grupos está limitada a usuários válidos. como a associação de grupo pode ser alterada por seus proprietários a qualquer momento, se esses proprietários não considerarem Azure DevOps Server acesso ao criar esses grupos, suas alterações na associação poderão causar efeitos colaterais indesejados no servidor.

A maioria dos usuários é atribuída ao grupo de colaboradores para um projeto para fornecer acesso aos recursos que eles precisam acessar. os administradores devem ser adicionados ao grupo Project administradores de coleção ou Project administradores.

Active Directory e Azure Active Directory grupos de segurança

Você pode preencher grupos de segurança adicionando usuários individuais. no entanto, para facilitar o gerenciamento, é 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 com mais eficiência em vários computadores.

Se você só precisa gerenciar um pequeno conjunto de usuários, pode ignorar esta etapa. No entanto, se você presumir 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 adicionais, precisará configurar o Azure AD para uso com o Azure DevOps para dar suporte à cobrança.

Observação

sem o Azure AD, todos os Azure DevOps usuários 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 da 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 Active Directory para uso com Azure DevOps Server, consulte os seguintes artigos:

Normalmente, você deve instalar o Active Directory antes de instalar o 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 automaticamente adicionadas a um dos grupos de usuários válidos.

  • usuários válidos da coleção de Project: todos os membros adicionados a um grupo de nível de organização.
  • Project usuários válidos: todos os membros adicionados a um grupo de nível de projeto.
  • servidor\ Azure DevOps usuários válidos: todos os membros adicionados aos grupos de nível de servidor.
  • ProjectCollectionName\ Project usuários válidos da coleção: todos os membros adicionados aos grupos de nível de coleção.
  • ProjectName\ Project usuários válidos: todos os membros adicionados aos grupos de nível de projeto.
  • Usuários válidos do Server\Team Foundation: todos os membros adicionados aos grupos de nível de servidor.
  • ProjectCollectionName\ Project usuários válidos da coleção: todos os membros adicionados aos grupos de nível de coleção.
  • ProjectName\ Project usuários válidos: todos os membros adicionados aos grupos de nível de 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 em nível de projetoe Exibir informações em nível de coleção.

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

Se você remover ou negar a permissão Exibir informações em nível de instância para um dos grupos de usuários válidos, nenhum membro do grupo será capaz de acessar o projeto, a coleção ou a implantação, dependendo do grupo definido.

grupo de usuários com escopo de Project

Por padrão, os usuários adicionados a uma organização podem exibir todas as informações e configurações do projeto e da organização. isso inclui a exibição da lista de usuários, da lista de projetos, dos detalhes de cobrança, dos dados de uso e de mais acessados por meio da organização Configurações.

para restringir os usuários selecionados, como as partes interessadas, Azure Active Directory usuários convidados ou membros de um grupo de segurança específico, você pode habilitar o recurso limitar a visibilidade do usuário para projetos para a organização. uma vez habilitado, qualquer usuário ou grupo adicionado ao grupo de usuários com escopo de Project , é restrito de acessar as páginas de Configurações da organização , exceto para visão geral e projetos; e são restritos a acessar somente os projetos aos quais eles 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, até mesmo os grupos que só têm permissões para um projeto específico. No portal da Web, os usuários sem acesso a um projeto não podem ver esses grupos que têm permissões somente para um projeto específico. No entanto, você pode descobrir os nomes de todos os grupos em uma organização usando a ferramenta CLI do Azure DevOps ou nossas APIs REST. Para saber mais, confira 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 das licenças de usuário; as permissões controlam a capacidade de um usuário de se conectar Azure DevOps e usar recursos em Azure DevOps. Se você estiver tentando dar a alguém acesso aos recursos de gerenciamento de portfólio Agile ou gerenciamento de caso 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. Certifique-se de que os usuários tenham as permissões e o nível de acesso necessários. Faça isso fazendo com que eles são adicionados ao projeto ou a uma equipe.

Permissões

Conforme mostrado na imagem a seguir, os grupos de segurança definidos no projeto e no nível da coleção podem ser atribuídos às 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 projeto e no nível da coleção podem ser atribuídos às 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 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 a uma permissão. Eles concedem ou restringem o acesso conforme indicado.

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

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

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

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

  • Para a maioria dos grupos e quase todas as permissões, As substituições negar permitem. 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 exigem essa permissão mesmo que ele pertença a um grupo que tenha essa permissão definida como Permitir.

    Em alguns casos, os membros dos grupos administradores Project coleção ou administradores do Team Foundation sempre poderão obter a permissão, mesmo se essa permissão for negada em um grupo diferente. Em outros casos, como exclusão de item de trabalho ou pipelines, ser um membro dos administradores da 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ídos. Os grupos de segurança atribuem um conjunto de permissões aos membros do grupo. Por exemplo, os membros do grupo Colaboradores ou Project administradores são atribuídos às permissões definidas como Permitidos 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 ela é negada, diretamente ou por meio da associação de grupo, a permissão é negada.

    Os membros Project administradores de coleção ou administradores do Team Foundation retêm a maioria das permissões permitidas, mesmo que eles pertençam a outros grupos que negam essas permissões. Permissões de operação de item de trabalho são a exceção a essa regra.

  • As permissões no nível do objeto atribuídas a nós de uma hierarquia – áreas, ieraçõ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 em serão herdadas por , se a mesma permissão não for explicitamente permitida ou area-1area-1/sub-area-1 negada para area-1/sub-area-1 . Se uma permissão for definida explicitamente para um objeto, como , o nó pai não será herdado, independentemente de ser area-1/sub-area-1 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 é herança. Por exemplo, um usuário cujas permissões são definidas explicitamente como Negar em 'área-1', mas também são definidas explicitamente como Permitir para 'area-1/sub-area-1', em última análise, receberão uma Permissão em 'area-1/sub-area-1'.

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

Observação

Para habilitar a nova interface do usuário para a Project de Configurações, consulte Habilitar versão prévia dos recursos.

Permissions dialog, preview page, Why link annotated.

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

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

Ao atribuir permissões

Faça:

  • 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 leads de equipe, mestres de scrum 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 criar um grupo personalizado de Administradores de Equipe em que você aloca um subconjunto das permissões disponíveis para Project Administradores.
  • Considere conceder as pastas de consulta do item de trabalho Permissão de contribuição 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 atribua uma permissão Negar ao grupo Project administradores da coleção ou Project administradores em qualquer nível
  • Não adicione usuários a vários grupos de segurança que contêm diferentes níveis de permissão. Em determinados 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 aos grupos de 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 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 notadas 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, as contas de usuário são atribuídas a uma função, com cada função atribuída a uma ou mais permissões. Aqui estão as principais funções e links para saber mais.

Sinalizadores de recurso

Acesso para selecionar, 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 em uma versão prévia privada exigem que o proprietário da organização solicite que o recurso seja ligado. Outros recursos podem ser introduzidos como um recurso de visualização que os usuários gerais podem habilitar ou desabilitar.

Para saber mais, confira Gerenciar ou habilitar recursos.

Próximas etapas