Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
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.
Para obter recomendações de desempenho para grandes organizações, consulte Recomendações de desempenho das permissões.
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:
- Ter permissões administrativas amplas dentro de uma organização ou coleção de projetos.
- Gerencie configurações, políticas e processos para a organização.
- Criar e gerir projetos.
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 a permissão ao utilizador ou grupo selecionado no âmbito atual. |
| Permitir (herdado) | Concede a permissão através do âmbito dos pais ou da filiação a um grupo. |
| Permitir (sistema) | Atribui uma permissão que o Azure DevOps administra. Não podes editar permissões do sistema. |
| Deny | Nega explicitamente a permissão ao utilizador ou grupo selecionado no âmbito atual. |
| Negar (herdado) | Nega a permissão através de um âmbito parental ou de pertença a um grupo. |
| Negar (sistema) | Nega uma permissão que o Azure DevOps administra. Não podes editar permissões do sistema. |
| Não definido | Nem concede nem nega a autorização no âmbito atual. Outras atribuições aplicáveis determinam a permissão efetiva. |
O Azure DevOps calcula permissões efetivas a partir de atribuições diretas, pertenças a grupos e atribuições herdadas. Quando combina atribuições no mesmo âmbito, o Negado geralmente tem prioridade sobre o Permitir. Numa hierarquia de objetos, uma atribuição explícita a um objeto filho pode substituir o valor herdado do seu pai pela mesma identidade.
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 utilizadores recebem as permissões combinadas dos grupos a que pertencem.
- No mesmo âmbito, um Negado de um grupo geralmente tem precedência sobre um Permitir de outro grupo.
- Not set não concede nem nega uma permissão e não anula uma tarefa de outro grupo.
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 hierarquia de objetos:
- 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 uma identidade num subnó, o valor herdado do pai para essa identidade não se aplica ao subnó.
- Após resolver a hierarquia de objetos, o Azure DevOps combina as atribuições diretas e de grupo aplicáveis. Uma Negação de outro grupo ao nível do âmbito resultante pode ainda ter precedência sobre uma Permissão.
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, selecione Porquê? para essa permissão. Para abrir uma página de Segurança , consulte Ver permissões.
É aberta uma nova caixa de diálogo que mostra as informações de herança dessa permissão.
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 do Azure necessitam de Basic + Test Plans ou de um benefício de subscrição Visual Studio aplicável.
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.
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 - 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 - Grupo de Serviços de Segurança |
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 na licença e no papel do utilizador, os administradores atribuem Stakeholder, Basic, Basic + Planos de Teste, ou um nível de acesso de subscrição Visual Studio aplicável.
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.
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 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 através da 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.
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 Active Directory.
Instale o Ative Directory antes de instalar o Azure DevOps Server.
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.
- Servidor\Azure DevOps Usuários Válidos: Todos os membros adicionados a grupos no nível do servidor.
- ProjectCollectionName\Utilizadores Válidos da Coleção de Projetos: 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.
Para aceder aos recursos do projeto, o utilizador precisa de Visualizar informação ao nível do projeto e quaisquer permissões necessárias para o recurso específico. As permissões de caminho de área controlam o acesso a itens de trabalho e artefactos de teste dentro de um projeto; não controlam se um utilizador pode aceder ao projeto. Não alteres as permissões padrão para um grupo de Utilizadores Válidos. Negar a um destes grupos Ver informações ao nível do projeto, Ver informações ao nível da coleção ou Ver informações ao nível da instância pode impedir todos os respetivos membros de aceder ao âmbito correspondente.
Grupo de utilizadores com âmbito de projeto
Por predefinição, os utilizadores que adicionar a uma organização podem ver informações sobre a organização e os projetos, mesmo fora dos projetos de que são membros.
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. Quando ativa esta funcionalidade, os utilizadores e grupos do grupo Project-Scoped Utilizadores só podem aceder aos projetos aos quais os adiciona explicitamente. A funcionalidade também limita o respetivo acesso às definições da organização e às identidades nos seletores de pessoas.
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. Ao usar as APIs REST ou
az devopscomandos CLI, os membros do projeto podem aceder aos 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 passos de configuração e limitações, consulte Limitar a visibilidade do utilizador.
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.
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 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.
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 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
As funcionalidades de pré-visualização proporcionam acesso antecipado à funcionalidade antes de esta se tornar geralmente disponível. Os utilizadores podem gerir funcionalidades de pré-visualização oferecidas ao nível do utilizador. Os membros do grupo Project Collection Administrators podem gerir funcionalidades de pré-visualização ao nível da organização no Azure DevOps Services e funcionalidades de pré-visualização ao nível da coleção no Azure DevOps Server. Para obter mais informações, consulte Gerenciar ou habilitar recursos.