Eventos
17 de mar., 21 - 21 de mar., 10
Junte-se à série de encontros para criar soluções de IA escaláveis com base em casos de uso do mundo real com outros desenvolvedores e especialistas.
Registrar agoraNão há mais suporte para esse navegador.
Atualize o Microsoft Edge para aproveitar os recursos, o suporte técnico e as atualizações de segurança mais recentes.
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.
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.
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.
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:
Administradores do Projeto:
Atribuem as permissões para conceder ou restringir o acesso:
O usuário ou grupo tem permissão:
O usuário ou grupo não tem permissão:
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:
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.
As permissões seguem uma hierarquia, permitindo a herança direto de um nó pai ou substituindo-a.
Herança de grupo:
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:
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:
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.
É 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.
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:
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.
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.
O Azure DevOps controla o acesso por meio destas três áreas funcionais interconectadas:
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.
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.
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.
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.
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:
azure devops
comandos da CLI, os membros do projeto podem acessar os dados restritos.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.
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.
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.
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.
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.
Eventos
17 de mar., 21 - 21 de mar., 10
Junte-se à série de encontros para criar soluções de IA escaláveis com base em casos de uso do mundo real com outros desenvolvedores e especialistas.
Registrar agoraTreinamento
Certificação
Microsoft Certified: Identity and Access Administrator Associate - Certifications
Demonstrar os recursos do Microsoft Entra ID para modernizar as soluções de identidade, implementar soluções híbridas e implementar a governança de identidade.