Sobre permissões e grupos de segurança
Serviços de DevOps do Azure | Azure DevOps Server 2022 - Azure DevOps Server 2019
Neste artigo, saiba mais sobre níveis de acesso e permissões por meio 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 obter mais informações, consulte Práticas recomendadas de segurança.
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. 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.
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. Os grupos de segurança recebem permissões atribuídas que permitem ou negam acesso a recursos ou tarefas.
- Os membros herdam as permissões atribuídas ao seu grupo de segurança.
- As permissões são definidas em diferentes níveis: organização/coleção, projeto ou objeto.
- Algumas permissões são gerenciadas por meio de atribuições baseadas em função (por exemplo, administrador de equipe, gerenciamento de extensão ou funções de recursos de pipeline).
- Os administradores podem definir grupos de segurança personalizados para gerenciar permissões para diferentes áreas funcionais.
Para obter mais informações, consulte Práticas recomendadas de segurança, Segurança e grupos de usuários.
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.
- Os colaboradores manipulam permissões para objetos específicos que 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 | 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). |
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 exclusão de item de trabalho ou gerenciamento de pipeline, ser membro do grupo Administradores de Coleção de Projetos não substitui as permissões Negar definidas em outro lugar.
- 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, eles não poderão gerenciar ou executar pipelines apesar de sua função administrativa.
Aviso
Quando você modifica uma permissão para um grupo, ela afeta todos os usuários desse grupo. Mesmo uma única alteração de permissão pode afetar centenas de usuários, por isso é crucial considerar os efeitos potenciais antes de fazer qualquer ajuste.
Herança de permissões
As permissões seguem uma hierarquia, permitindo a herança de um nó pai ou substituindo-o.
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:
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 item de trabalho, são herdadas 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 em um nó de nível superior são herdadas por todos os subnós, a menos que sejam explicitamente substituídas.
- Se uma permissão não for explicitamente permitida ou 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. A permissão mais específica tem precedência se existirem permissões conflitantes.
Exemplo:
- Negar explicitamente em 'area-1' (nó pai).
- Permitir explicitamente 'área-1/sub-área-1' (nó filho).
- Nesse caso, o usuário recebe uma opção Permitir em 'área-1/sub-área-1', substituindo a Negação herdada do nó pai.
Para entender por que uma permissão é herdada, você pode pausar sobre uma configuração de permissão e selecionar 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.
É aberta uma nova caixa de diálogo que mostra as informações de herança dessa permissão.
A interface do usuário de visualização para a página de configurações de Permissões do Projeto não está disponível para o Azure DevOps Server 2020 e versões anteriores.
Grupos de segurança e membros
Os grupos de segurança atribuem permissões específicas aos 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, 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
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 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.
Os seguintes grupos de segurança 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 Projeto.
Adicione apenas contas de serviço a grupos de contas de serviço do Azure DevOps. Para entender grupos de usuários válidos, consulte Grupos de usuários válidos mais adiante neste artigo.
| Nível do projeto | Nível de recolha |
|---|---|
| - 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 - Grupo de Serviços de Segurança |
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.
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.
- O gerenciamento de nível de acesso controla o acesso aos recursos do portal da Web. Com base na compra 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.
Os membros do grupo de segurança podem ser uma combinação de usuários, outros grupos e grupos do Ative Directory ou um grupo de trabalho.
Você pode criar grupos locais ou grupos do Ative Directory (AD) para gerenciar seus usuários.
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 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. 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.
Para configurar o Ative Directory para uso com o Azure DevOps Server, consulte os seguintes artigos:
- Instalar os Serviços de Domínio Ative Directory (Nível 100)
- Introdução aos Serviços de Domínio Ative Directory.
Instale o Ative Directory antes de instalar o Azure DevOps Server.
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 seguintes 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.
- 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 de nível de coleção.
- ProjectName\Project Valid Users: Todos os membros adicionados a grupos 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 ao modo 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 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 de 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 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.
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 devopsos 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 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 habilitado, qualquer usuário ou grupo adicionado ao grupo Usuários com escopo do projeto é impedido de acessar as páginas de configurações da organização, exceto Visão geral e Projetos. Além disso, eles só têm acesso aos projetos aos quais são adicionados.
Aviso
Habilitar o recurso de visualização Limitar a visibilidade e a colaboração do usuário a projetos específicos impede que os usuários com escopo de projeto pesquisem usuários adicionados à organização por meio da associação ao grupo do Microsoft Entra, em vez de por meio de um convite explícito do usuário. Este é um comportamento inesperado, e uma resolução está em andamento. Para resolver 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 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 nossas APIs REST. Para obter mais informações, consulte Adicionar e gerenciar grupos de segurança.
Nota
Os grupos de segurança são gerenciados no nível da coleçã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 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.
Nota
Os grupos de segurança são gerenciados no nível da coleçã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 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 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.
Para obter mais informações, consulte Sobre 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 a objetos, projetos e à organização.
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 às permissões atribuídas no nível do 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.
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 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.