Grupos de segurança, contas de serviço e permissões no Azure DevOps
Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server | 2019 TFS 2018
Este artigo fornece uma referência abrangente para cada usuário interno, grupo e permissão. São muitas informações que descrevem cada usuário e grupo de segurança internos, bem como cada permissão.
Para obter uma referência rápida a atribuições padrão, consulte permissões e acesso padrão. Para obter uma visão geral de como as permissões e a segurança são gerenciadas, consulte Introdução com permissões, acesso e grupos de segurança. Além dos grupos de segurança, também há funções de segurança, que fornecem permissões para áreas selecionadas.
Para saber como adicionar usuários a um grupo ou definir uma permissão específica que você pode gerenciar por meio do portal da Web, consulte os seguintes recursos:
Usuários e grupos
Wiki
DevOps
Acompanhamento de trabalho
Relatórios
Observação
As imagens que você vê no portal da Web podem ser diferentes das imagens que você vê neste tópico. Essas diferenças resultam de atualizações feitas para Azure DevOps. No entanto, a funcionalidade básica disponível para você permanece a mesma, a menos que seja explicitamente mencionada.
Contas de serviço
Há algumas contas de serviço que são geradas pelo sistema para dar suporte a operações específicas. Elas incluem as descritas na tabela a seguir. Essas contas de usuário são adicionadas no nível da organização ou da coleção.
| Nome de usuário | Descrição |
|---|---|
| Serviço de Pool de Agentes | Tem permissão para escutar a fila de mensagens para que o pool específico receba trabalho. Na maioria dos casos, você não deve ter que gerenciar membros desse grupo. O processo de registro do agente cuida dele para você. A conta de serviço especificada para o agente (normalmente Serviço de Rede) é adicionada automaticamente quando você registra o agente. Responsável por executar Azure Boards operações de leitura/gravação e atualizar itens de trabalho quando GitHub objetos são atualizados. |
| Azure Boards | Adicionado quando Azure Boards está conectado a GitHub. Você não deve ter que gerenciar membros desse grupo. Responsável por gerenciar a criação de vínculo entre GitHub e Azure Boards. |
| PipelinesSDK | Adicionado conforme necessário para dar suporte aos tokens de escopo do serviço de política Pipelines. Essa conta de usuário é semelhante às identidades do serviço de build, mas dá suporte ao bloqueio de permissões separadamente. Na prática, os tokens que envolvem essa identidade recebem permissões somente leitura para recursos de pipeline e a capacidade única de aprovar solicitações de política. Essa conta deve ser tratada da mesma forma que as identidades do serviço de build são tratadas. |
| Projectname Serviço de Build | Tem permissões para executar serviços de build para o projeto. Esse é um usuário herdado usado para builds XAML. Ele é adicionado ao Grupo de Serviços de Segurança, que é usado para armazenar usuários que receberam permissões, mas não adicionados a nenhum outro grupo de segurança. |
| Serviço de build de coleção Project | Tem permissões para executar serviços de build para a coleção. Ele é adicionado ao Grupo de Serviços de Segurança, que é usado para armazenar usuários que receberam permissões, mas não adicionados a nenhum outro grupo de segurança. |
Grupos
As permissões podem ser concedidas diretamente a um indivíduo ou a um grupo. Usar grupos torna as coisas muito mais simples. O sistema fornece vários grupos internos para essa finalidade. Esses grupos e as permissões padrão atribuídas são definidos em níveis diferentes: servidor (somente implantação local), coleção de projetos, projeto e objetos específicos. Você também pode criar seus próprios grupos e conceder a eles o conjunto específico de permissões que são apropriadas para determinadas funções em sua organização.
Observação
Todos os grupos de segurança são entidades de nível de organização, mesmo os grupos que têm permissões apenas 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 da 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 têm permissões apenas 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 da 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 têm permissões apenas 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.
Grupos no nível do servidor
Quando você instala o Servidor do Azure DevOps, o sistema cria grupos padrão que têm permissões de nível de servidor em toda a implantação. Você não pode remover ou excluir os grupos internos no nível do servidor.
Você não pode remover ou excluir os grupos de nível de servidor padrão.
Nome do grupo
Permissões
Associação
Contas de Serviço do Azure DevOps
Tem permissões de nível de serviço para a instância do servidor.
Contém a conta de serviço que foi fornecida durante a instalação
Este grupo deve conter somente contas e grupos de serviço e não contas de usuários ou grupos que contenham contas de usuários. Por padrão, esse grupo é membro dos Administradores do Team Foundation.
Se você precisar adicionar uma conta a esse grupo depois de instalar o Servidor do Azure DevOps ou o TFS, poderá fazer isso usando o utilitário TFSSecurity.exe na subpasta Ferramentas do diretório de instalação do TFS.
O comando para fazer isso é TFSSecurity /g+ "[TEAM FOUNDATION]\Team Foundation Service Accounts" n:domain\username /server:http(s)://tfsservername
Usuários válidos do Azure DevOps
Tem permissão para exibir informações no nível da instância do servidor.
Contém todos os usuários conhecidos por existirem na instância do servidor. Você não pode modificar a associação desse grupo.
Administradores do Team Foundation
Tem permissões para executar todas as operações no nível do servidor.
Grupo de administradores locais (BUILTIN\Administrators) para qualquer servidor que hospede os serviços de aplicativo do Azure DevOPs/Team Foundation.
Grupo de Contas de Serviço do Server\Team Foundation e os membros do grupo \Project Server Integration Service Accounts.
Esse grupo deve ser restrito ao menor número possível de usuários que precisam de controle administrativo total sobre operações no nível do servidor.
Observação
Se sua implantação usar o SharePoint ou o Reporting, considere adicionar os membros desse grupo aos grupos Administradores de Farm e Administradores do Conjunto de Sites no SharePoint e aos grupos de Gerenciadores de Conteúdo do Team Foundation no Reporting Services.
Nome do grupo
Permissões
Associação
Administradores do Team Foundation
Tem permissões para executar todas as operações no nível do servidor.
Grupo de administradores locais (BUILTIN\Administrators) para qualquer servidor que hospede os serviços de aplicativo do Azure DevOPs/Team Foundation.
Grupo de Contas de Serviço do Server\Team Foundation e os membros do grupo \Project Server Integration Service Accounts.
Esse grupo deve ser restrito ao menor número possível de usuários que precisam de controle administrativo total sobre operações no nível do servidor.
Observação
Se sua implantação usar o SharePoint ou o Reporting, considere adicionar os membros desse grupo aos grupos Administradores de Farm e Administradores do Conjunto de Sites no SharePoint e aos grupos de Gerenciadores de Conteúdo do Team Foundation no Reporting Services.
Contas de serviço proxy do Team Foundation
Tem permissões de nível de serviço para o Proxy do Team Foundation Server e algumas permissões de nível de serviço.
Observação
Essa conta é criada quando você instala o serviço proxy do TFS.
Este grupo deve conter somente contas e grupos de serviço e não contas de usuários ou grupos que contenham contas de usuários.
Contas do Team Foundation Service
Tem permissões de nível de serviço para a instância do servidor.
Contém a conta de serviço que foi fornecida durante a instalação
Este grupo deve conter somente contas e grupos de serviço e não contas de usuários ou grupos que contenham contas de usuários. Por padrão, esse grupo é membro dos Administradores do Team Foundation.
Se você precisar adicionar uma conta a esse grupo depois de instalar o Servidor do Azure DevOps ou o TFS, poderá fazer isso usando o utilitário TFSSecurity.exe na subpasta Ferramentas do diretório de instalação do TFS.
O comando para fazer isso é TFSSecurity /g+ "[TEAM FOUNDATION]\Team Foundation Service Accounts" n:domain\username /server:http(s)://tfsservername
Usuários Válidos do Team Foundation
Tem permissão para exibir informações no nível da instância do servidor.
Observação
Se você definir a permissão exibir informações no nível da instância como Negar ou Não definida para esse grupo, nenhum usuário poderá acessar a implantação.
Contém todos os usuários conhecidos por existirem na instância do servidor. Você não pode modificar a associação desse grupo.
Contas do Serviço de Integração do Project Server
Tem permissões de nível de serviço para as implantações do Project Server configuradas para interoperabilidade com a instância do servidor e algumas permissões de nível de serviço TFS.
Observação
Criado quando você instala a integração do Project Service.
Este grupo deve conter somente contas e grupos de serviço e não contas de usuários ou grupos que contenham contas de usuários. Por padrão, esse grupo é membro dos Administradores do Team Foundation.
Serviços de Aplicativo Web do SharePoint
Tem permissões de nível de serviço para os aplicativos Web do SharePoint configurados para uso com TFS e algumas permissões de nível de serviço para TFS.
Este grupo deve conter somente contas e grupos de serviço e não contas de usuários ou grupos que contenham contas de usuários. Ao contrário do grupo Contas de Serviço, esse grupo não é membro dos Administradores do Team Foundation.
Observação
O nome completo de cada um desses grupos é [Team Foundation]\{nome do grupo}. Portanto, o nome completo do grupo de administradores no nível do servidor é [Team Foundation]\Administradores da Team Foundation.
Grupos no nível da coleção
Quando você cria uma organização ou coleção de projetos no Azure DevOps, o sistema cria grupos de nível de coleção que têm permissões nessa coleção. Você não pode remover ou excluir os grupos internos no nível da coleção.
Observação
Para habilitar a nova interface do usuário para a Página de Configurações de Permissões de Organizações v2, consulte Habilitar recursos de visualização. A página de visualização fornece uma página de configurações de grupo que a página atual não fornece.
O nome completo de cada um desses grupos é [{nome da coleção}]\{nome do grupo}. Portanto, o nome completo do grupo de administradores da coleção padrão é [Coleção Padrão]\Administradores de Coleção de Projetos.
Nome do grupo
Permissões
Associação
Administradores da Coleção de Projetos
Tem permissões para executar todas as operações para a coleção.
Contém o grupo Administradores Locais (BUILTIN\Administrators) para o servidor em que os serviços da camada de aplicativo foram instalados. Além disso, contém os membros do grupo Contas CollectionNameService/. Esse grupo deve ser restrito ao menor número possível de usuários que precisam do controle administrativo total sobre a coleção. Para o Azure DevOps, atribua aos administradores que personalizam o acompanhamento de trabalho.
Observação
Se sua implantação usar o Reporting Services, considere adicionar os membros desse grupo aos grupos do Team Foundation Content Managers no Reporting Services.
Administradores de Compilação da Coleção do Projeto
Tem permissões para administrar recursos de build e permissões para a coleção.
Limite esse grupo ao menor número possível de usuários que precisam de controle administrativo total sobre servidores e serviços de build para essa coleção.
Contas do Build Service da Coleção do Projeto
Tem permissões para executar serviços de build para a coleção.
Limite esse grupo a contas de serviço e grupos que contêm apenas contas de serviço. Esse é um grupo herdado usado para builds XAML. Use o usuário do Project Collection Build Service ({sua organização}) para gerenciar permissões para builds atuais.
Contas de Serviço de Proxy de Coleção de Projeto
Tem permissões para executar o serviço proxy para a coleção.
Limite esse grupo a contas de serviço e grupos que contêm apenas contas de serviço.
Contas de Serviço de Coleção de Projetos
Tem permissões de nível de serviço para a coleção e para o Servidor do Azure DevOps.
Contém a conta de serviço que foi fornecida durante a instalação. Esse grupo deve conter somente contas e grupos de serviço que contenham apenas contas de serviço. Por padrão, esse grupo é membro do grupo Administradores.
Contas de Serviço de Teste de Coleção de Projeto
Tem permissões de serviço de teste para a coleção.
Limite esse grupo a contas de serviço e grupos que contêm apenas contas de serviço.
Usuários Válidos da Coleção de Projetos
Tem permissões para acessar projetos de equipe e exibir informações na coleção.
Contém todos os usuários e grupos que foram adicionados em qualquer lugar da coleção. Você não pode alterar a associação desse grupo.
Tem acesso limitado para exibir as configurações da organização e projetos diferentes dos projetos aos quais eles são adicionados especificamente. Além disso, as opções de seletor de pessoas são limitadas aos usuários e grupos que foram explicitamente adicionados ao projeto ao qual o usuário está conectado.
Adicione usuários a esse grupo quando quiser limitar sua visibilidade e acesso aos projetos aos quais você os adiciona explicitamente. Não adicione usuários a esse grupo se eles também forem adicionados ao grupo Administradores de Coleção de Projetos.
Observação
O grupo Usuários com Escopo do Projeto fica disponível com acesso restrito quando o recurso de visualização no nível da organização, a visibilidade do usuário e a colaboração com projetos específicos estiverem habilitados. Para saber mais, consulte Gerenciar sua organização, limitar a visibilidade do usuário para projetos e muito mais.
Grupo de Serviços de Segurança
Usado para armazenar usuários que receberam permissões, mas não foram adicionados a nenhum outro grupo de segurança.
Não atribua usuários a esse grupo. Se você estiver removendo usuários de todos os grupos de segurança, verifique se você precisa removê-los desse grupo.
Grupos no nível do projeto
Para cada projeto criado, o sistema cria os seguintes grupos no nível do projeto. Esses grupos recebem permissões no nível do projeto.
Observação
Para habilitar a nova interface do usuário para a página Configurações de Permissões do Projeto, consulte Habilitar recursos de visualização.
Para ver a imagem completa, clique para expandir.
Dica
O nome completo de cada um desses grupos é [{nome do projeto}]\{nome do grupo}. Por exemplo, o grupo de colaboradores de um projeto chamado "Meu Projeto" é [Meu Projeto]\Colaboradores.
Nome do grupo
Permissões
Associação
Administradores de Compilação
Tem permissões para administrar recursos de build e permissões de build para o projeto. Os membros podem gerenciar ambientes de teste, criar execuções de teste e gerenciar compilações.
Atribua aos usuários que definem e gerenciam pipelines de build.
Colaboradores
Tem permissões para contribuir totalmente com a base de código do projeto e o acompanhamento de item de trabalho. As principais permissões que eles não têm são aquelas que gerenciam ou administram recursos.
Por padrão, o grupo de equipe criado quando você cria um projeto é adicionado a esse grupo e qualquer usuário adicionado à equipe ou projeto é membro desse grupo. Além disso, qualquer equipe criada para um projeto é adicionada a esse grupo.
Leitores
Tem permissões para exibir informações do projeto, a base de código, itens de trabalho e outros artefatos, mas não modificá-los.
Atribua a membros da sua organização ou coleção quem você deseja fornecer permissões somente exibição a um projeto. Esses usuários podem exibir pendências, quadros, painéis e muito mais, mas não adicionar ou editar nada.
Tem permissões para administrar todos os aspectos das equipes e do projeto, embora não possam criar projetos de equipe.
Atribua aos usuários que gerenciam permissões de usuário, criam ou editam equipes, modificam as configurações da equipe, definem uma área de um caminho de iteração ou personalizam o acompanhamento de itens de trabalho. Os membros do grupo Administradores do Projeto recebem permissões para executar as seguintes tarefas:
- Adicionar e remover usuários da associação ao projeto
- Adicionar e remover grupos de segurança personalizados de um projeto
- Adicionar e administrar todas as equipes de projeto e recursos relacionados à equipe
- Editar ACLs de permissão no nível do projeto
- Edite assinaturas de evento (email ou SOAP) para equipes ou eventos no nível do projeto.
Usuários Válidos do Projeto
Tem permissões para acessar e exibir informações do projeto.
Contém todos os usuários e grupos que foram adicionados em qualquer lugar ao projeto. Você não pode alterar a associação desse grupo.
Observação
Recomendamos que você não altere as permissões padrão para esse grupo.
Administradores de versão
Tem permissões para gerenciar todas as operações de versão.
Atribua aos usuários que definem e gerenciam pipelines de lançamento.
Observação
O grupo Administrador de Versão é criado ao mesmo tempo em que o primeiro pipeline de lançamento é definido. Ele não é criado por padrão quando o projeto é criado.
Tem permissões para contribuir totalmente com a base de código do projeto e o acompanhamento de item de trabalho. O grupo de equipe padrão é criado quando você cria um projeto e, por padrão, é adicionado ao grupo Colaboradores do projeto. Todas as novas equipes que você criar também terão um grupo criado para elas adicionado ao grupo de contribuintes.
Adicione membros da equipe a esse grupo. Para conceder acesso para definir as configurações da equipe, adicione um membro da equipe à função de administrador da equipe.
Função de administrador de equipe
Para cada equipe que você adicionar, você pode atribuir um ou mais membros da equipe como administradores. A função de administrador de equipe não é um grupo com um conjunto de permissões definidas. Em vez disso, a função de administrador de equipe é encarregada de gerenciar ativos de equipe. Para saber mais, consulte Gerenciar equipes e configurar ferramentas de equipe. Para adicionar um usuário como administrador de equipe, consulte Adicionar um administrador de equipe.
Observação
Os Administradores de Projeto podem gerenciar todas as áreas administrativas da equipe para todas as equipes.
Permissões
O sistema gerencia permissões em diferentes níveis — servidor, coleção, projeto ou objeto — e, por padrão, as atribui a um ou mais grupos internos. Você gerencia a maioria das permissões por meio do portal da Web.
Permissões no nível de servidor
Você gerencia permissões no nível do servidor por meio do Console de Administração do Team Foundation ou da ferramenta de linha de comando TFSSecurity. Os Administradores do Team Foundation recebem todas as permissões no nível do servidor. Outros grupos no nível do servidor têm atribuições de permissão selecionadas.
Permissão
Descrição
Pode processar ou alterar as configurações do data warehouse ou do cubo de Análise do SQL Server usando o Serviço Web de Controle do Warehouse.
Permissões adicionais podem ser necessárias para processar ou recompilar totalmente o data warehouse e o cubo de análise.
Pode criar e administrar coleções.
Pode excluir uma coleção da implantação.
Observação
Excluir uma coleção não excluirá o banco de dados de coleção do SQL Server.
Pode editar permissões no nível do servidor para usuários e grupos e adicionar ou remover grupos de nível de servidor da coleção.
Observação
Editar informações no nível da instância inclui a capacidade de executar essas tarefas para todos os projetos de equipe definidos em todas as coleções definidas para a instância:
- Criar e modificar áreas e iterações
- Editar políticas de check-in
- Editar consultas de item de trabalho compartilhado
- Editar ACLs de permissão de nível de projeto e nível de coleção
- Criar e modificar listas globais
- Editar assinaturas de evento (email ou SOAP).
Quando definida por meio dos menus, a permissão editar informações no nível da instância também permite implicitamente que o usuário modifique as permissões de controle de versão. Para conceder todas essas permissões em um prompt de comando, você deve usar o tf.exe Permission comando para conceder as permissões AdminConfiguration e AdminConnections , além de GENERIC_WRITE.
Pode executar operações em nome de outros usuários ou serviços. Atribua somente a contas de serviço.
Pode disparar eventos de alerta no nível do servidor. Atribua somente a contas de serviço e membros do grupo Administradores do Team Foundation.
Pode usar todos os recursos do portal da Web local. Essa permissão foi preterida com o Azure DevOps Server 2019 e versões posteriores.
Observação
Se a permissão usar recursos completos do Acesso à Web estiver definida como Negar, o usuário só verá esses recursos permitidos para o grupo Stakeholder (consulte Alterar níveis de acesso). Uma Negação substituirá qualquer Permissão implícita, mesmo para contas que sejam membros de grupos administrativos, como Administradores do Team Foundation.
Pode exibir a associação de grupo no nível do servidor e as permissões desses usuários.
Observação
A permissão exibir informações no nível da instância também é atribuída ao grupo Usuários Válidos do Team Foundation.
Permissões no nível da organização
Você gerencia permissões no nível da organização por meio do contexto de administrador do portal da Web ou com os comandos do grupo de segurança az devops . Os Administradores de Coleção de Projetos recebem todas as permissões no nível da organização. Outros grupos no nível da organização têm atribuições de permissão selecionadas.
Observação
Para habilitar a nova interface do usuário para a Página de Configurações de Permissões de Organizações v2, consulte Habilitar recursos de visualização. A página de visualização fornece uma página de configurações de grupo que a página atual não fornece.
Permissão
Descrição
Geral
Pode alterar as configurações de rastreamento para coletar informações de diagnóstico mais detalhadas sobre os serviços Web do Azure DevOps.
Pode adicionar um projeto a uma organização ou coleção de projetos. Permissões adicionais podem ser necessárias dependendo da implantação local.
Pode excluir um projeto.
Observação
Excluir um projeto excluirá todos os dados associados ao projeto. Você não pode desfazer a exclusão de um projeto, exceto restaurando a coleção para um ponto antes de o projeto ser excluído.
Pode adicionar usuários e grupos e editar permissões no nível da organização para usuários e grupos.
Observação
Editar informações no nível da instância inclui a capacidade de executar essas tarefas para todos os projetos definidos em uma coleção:
- Adicionar e administrar equipes e todos os recursos relacionados à equipe
- Editar permissões no nível da instância para usuários e grupos na coleção
- Adicionar ou remover grupos de segurança no nível da instância da coleção
- Permite implicitamente que o usuário modifique as permissões de controle de versão
- Editar ACLs de permissão no nível do projeto e no nível da instância
- Edite assinaturas de evento (email ou SOAP) em eventos de nível de projeto ou coleção.
Quando você define Editar informações no nível da instância para Permitir, os usuários podem adicionar ou remover grupos no nível da coleção e, implicitamente, permite que esses usuários modifiquem as permissões de controle de versão.
Pode exibir permissões e associações de grupo no nível da coleção de projetos.
Observação
Se você definir a permissão de informações no nível da instância de Exibição como Negar ou Não definida para esse grupo, nenhum usuário poderá acessar projetos na organização ou na coleção de projetos.
Conta de serviço
Pode executar operações em nome de outros usuários ou serviços. Atribua essa permissão somente a contas de serviço locais.
Pode disparar eventos de alerta de projeto dentro da coleção. Atribua somente a contas de serviço.
Observação
Os usuários com essa permissão não podem remover grupos de nível de coleção internos, como Administradores de Coleção de Projetos.
Pode chamar as interfaces de programação do aplicativo de sincronização. Atribua somente a contas de serviço.
Boards
Pode modificar permissões para personalizar o acompanhamento de trabalho criando e personalizando processos herdados.
Pode criar um processo herdado usado para personalizar o acompanhamento de trabalho e os Quadros do Azure. Os usuários que receberam acesso básico e stakeholder recebem essa permissão por padrão.
Pode excluir um processo herdado usado para personalizar o acompanhamento de trabalho e os Quadros do Azure.
Pode editar um processo herdado personalizado.
Repos
Pode excluir conjuntos de prateleiras criados por outros usuários. Aplica-se quando o TFVC é usado como o controle de origem.
Pode criar e excluir workspaces para outros usuários. Aplica-se quando o TFVC é usado como o controle de origem.
Pode criar um workspace de controle de versão. Aplica-se quando o TFVC é usado como o controle de origem.
Observação
A permissão Criar um workspace é concedida a todos os usuários como parte de sua associação no grupo Usuários Válidos da Coleção de Projetos.
Pipelines
Pode modificar permissões para pipelines de build no nível da coleção de projetos ou da organização. Isso inclui:
Pode gerenciar computadores de build, agentes de build e controladores de build.
Pode reservar e alocar agentes de build. Atribuir somente a contas de serviço para serviços de build.
Pode exibir, mas não usar, controladores de build e agentes de build configurados para uma organização ou coleção de projetos.
Test Plans
Pode registrar e des registrar controladores de teste.
Pode excluir um fluxo de auditoria. Os fluxos de auditoria estão em versão prévia. Para obter detalhes, consulte Criar streaming de auditoria.
Pode adicionar um fluxo de auditoria. Os fluxos de auditoria estão em versão prévia. Para obter detalhes, consulte Criar streaming de auditoria.
Pode exibir e exportar logs de auditoria. Os logs de auditoria estão em versão prévia. Para obter detalhes, consulte Acessar, exportar e filtrar logs de auditoria.
Políticas
Pode habilitar e desabilitar políticas de conexão de aplicativo, conforme descrito nas políticas de conexão de aplicativo de alteração.
Permissões de nível de coleção
Você gerencia permissões de nível de coleção por meio do contexto de administrador do portal da Web, com os comandos do grupo de segurança az devops ou a ferramenta de linha de comando TFSSecurity. Os Administradores de Coleção de Projetos recebem todas as permissões de nível de coleção. Outros grupos no nível da coleção têm atribuições de permissão selecionadas.
Você gerencia permissões no nível da coleção por meio do contexto de administrador do portal da Web ou da ferramenta de linha de comando TFSSecurity. Os Administradores de Coleção de Projetos recebem todas as permissões de nível de coleção. Outros grupos no nível da coleção têm atribuições de permissão selecionadas.
As permissões disponíveis para o Azure DevOps Server 2019 e versões posteriores variam dependendo do modelo de processo configurado para a coleção. Para obter uma visão geral dos modelos de processo, consulte Personalizar o acompanhamento de trabalho.
Modelo de processo herdado
Modelo de processo XML local
Permissão
Descrição
Pode modificar permissões para pipelines de build no nível de coleção de projetos. Isso inclui os seguintes artefatos:
Pode modificar permissões para personalizar o acompanhamento de trabalho criando e personalizando processos herdados. Requer que a coleção seja configurada para dar suporte ao modelo de processo herdado. Consulte também:
Pode excluir conjuntos de prateleiras criados por outros usuários. Aplica-se quando o TFVC é usado como o controle de origem.
Pode criar e excluir workspaces para outros usuários. Aplica-se quando o TFVC é usado como o controle de origem.
Pode alterar as configurações de rastreamento para coletar informações de diagnóstico mais detalhadas sobre os serviços Web do Azure DevOps.
Pode criar um workspace de controle de versão. Aplica-se quando o TFVC é usado como o controle de origem. Essa permissão é concedida a todos os usuários como parte de sua associação no grupo Usuários Válidos da Coleção de Projetos.
Pode adicionar projetos a uma coleção de projetos. Permissões adicionais podem ser necessárias dependendo da implantação local.
Pode adicionar projetos a uma coleção de projetos. Permissões adicionais podem ser necessárias dependendo da implantação local.
Pode criar um processo herdado usado para personalizar o controle de trabalho e as Placas do Azure. Requer que a coleção seja configurada para dar suporte ao modelo de processo herdado.
Pode excluir um campo personalizado que foi adicionado a um processo. Para implantações locais, requer que a coleção seja configurada para dar suporte ao modelo de processo herdado.
Pode excluir um processo herdado usado para personalizar o acompanhamento de trabalho e os Quadros do Azure. Exige que a coleção seja configurada para dar suporte ao modelo de processo herdado.
Pode excluir um projeto.
Observação
Excluir um projeto exclui todos os dados associados ao projeto. Você não pode desfazer a exclusão de um projeto, exceto restaurando a coleção para um ponto antes de o projeto ser excluído.
Pode adicionar usuários e grupos e editar permissões no nível da coleção para usuários e grupos. Editar informações no nível da coleção inclui a capacidade de executar essas tarefas para todos os projetos definidos em uma coleção:
- Adicionar e administrar equipes e todos os recursos relacionados à equipe
- Editar permissões no nível da coleção para usuários e grupos na coleção
- Adicionar ou remover grupos de segurança no nível da coleção
- Permite implicitamente que o usuário modifique as permissões de controle de versão
- Editar ACLs de permissão de nível de projeto e nível de coleção
- Edite assinaturas ou alertas de evento (email ou SOAP) para equipes, projetos ou eventos de nível de coleção.
Quando você define Editar informações no nível da coleção como Permitir, os usuários podem adicionar ou remover grupos no nível da coleção e, implicitamente, permite que esses usuários modifiquem as permissões de controle de versão.
Para conceder todas essas permissões em um prompt de comando, você deve usar o
tf.exe permissioncomando para conceder as permissões AdminConfiguration e AdminConnections , além de GENERIC_WRITE.
Pode editar um processo herdado personalizado. Exige que a coleção seja configurada para dar suporte ao modelo de processo herdado.
Pode executar operações em nome de outros usuários ou serviços. Atribua essa permissão somente a contas de serviço locais.
Pode gerenciar computadores de build, agentes de build e controladores de build.
Pode baixar, criar, editar e carregar modelos de processo. Um modelo de processo define os blocos de construção do sistema de acompanhamento de itens de trabalho, bem como outros subsistemas que você acessa por meio das Placas do Azure. Exige que a coleção seja configurada para dar suporte ao modelo de processo XML on=premises.
Pode registrar e des registrar controladores de teste.
Pode disparar eventos de alerta de projeto dentro da coleção. Atribua somente a contas de serviço. Os usuários com essa permissão não podem remover grupos de nível de coleção internos, como Administradores de Coleção de Projetos.
Pode reservar e alocar agentes de build. Atribua somente a contas de serviço para serviços de build.
Pode exibir, mas não usar, controladores de build e agentes de build configurados para uma organização ou coleção de projetos.
Pode exibir permissões e associações de grupo no nível da coleção de projetos.
Pode chamar as interfaces de programação do aplicativo de sincronização. Atribua somente a contas de serviço.
Permissões no nível de projeto
Você gerencia permissões no nível do projeto por meio do contexto de administrador do portal da Web ou com os comandos do grupo de segurança az devops . Os administradores do projeto recebem todas as permissões no nível do projeto. Outros grupos no nível do projeto têm atribuições de permissão selecionadas.
Observação
Para habilitar a nova interface do usuário para a página Configurações de Permissões do Projeto, consulte Habilitar recursos de visualização.
Você gerencia permissões no nível do projeto por meio do contexto de administrador do portal da Web, com os comandos do grupo de segurança az devops ou a ferramenta de linha de comando TFSSecurity. Os administradores do projeto recebem todas as permissões no nível do projeto. Outros grupos no nível do projeto têm atribuições de permissão selecionadas.
Você gerencia permissões no nível do projeto por meio do contexto de administrador do portal da Web ou da ferramenta de linha de comando TFSSecurity. Os administradores do projeto recebem todas as permissões no nível do projeto. Outros grupos no nível do projeto têm atribuições de permissão selecionadas.
Observação
Várias permissões são concedidas aos membros do grupo Administradores do Projeto e não são exibidas dentro da interface do usuário.
Permissão
Descrição
Geral
Pode excluir um projeto de uma organização ou coleção de projetos.
Pode editar a descrição do projeto e a visibilidade dos serviços de projeto.
Pode fornecer ou editar metadados para um projeto. Por exemplo, um usuário pode fornecer informações de alto nível sobre o conteúdo de um projeto. Há suporte para a alteração de metadados por meio da API REST de definir propriedades do projeto.
Os usuários com essa permissão podem atualizar itens de trabalho sem gerar notificações. Isso é útil ao executar migrações de atualizações em massa por ferramentas e deseja ignorar a geração de notificações.
Considere conceder essa permissão a contas de serviço ou usuários que receberam as regras de bypass na permissão de atualizações de item de trabalho . Você pode definir o suppressNotifications parâmetro para true ao atualizar o trabalho por meio de Itens de Trabalho – atualizar a API REST.
Pode alterar a visibilidade do projeto de privado para público ou público para privado. Aplica-se somente ao Azure DevOps Services.
Pode exibir informações no nível do projeto, incluindo permissões e associação de grupo de informações de segurança.
Boards
Os usuários com essa permissão podem salvar um item de trabalho que ignora regras, como cópia, restrição ou regras condicionais, definidas para o tipo de item de trabalho. Cenários em que isso é útil são migrações em que você não deseja atualizar os campos por/data na importação ou quando deseja ignorar a validação de um item de trabalho.
As regras podem ser ignoradas de duas maneiras. A primeira é por meio dos Itens de Trabalho – atualizar a API REST e definir o bypassRules parâmetro como true. O segundo é por meio do modelo de objeto cliente, inicializando no modo bypassrules (inicializar WorkItemStore com WorkItemStoreFlags.BypassRules).
Quando combinado com a permissão 'Editar informações no nível do projeto', permite que os usuários alterem o processo de herança de um projeto. Para saber mais, consulte Criar e gerenciar processos herdados.
Pode adicionar marcas a um item de trabalho. Por padrão, todos os membros do grupo Colaboradores têm essa permissão.
Todos os usuários que receberam acesso ao Stakeholder para um projeto privado só poderão adicionar marcas existentes, não adicionar novas marcas, mesmo se a permissão Criar definição de marca estiver definida como Permitir. Isso faz parte das configurações de acesso do Stakeholder. Por padrão, os usuários do Azure DevOps Services concederam ao Stakeholder acesso a um projeto público.
Pode marcar itens de trabalho no projeto como excluídos. Por padrão, os usuários do Azure DevOps Services concederam ao Stakeholder acesso a um projeto público.
Pode mover um item de trabalho de um projeto para outro projeto dentro da coleção.
Pode excluir permanentemente itens de trabalho deste projeto.
Análise
Pode excluir exibições do Analytics que foram salvas na área Compartilhada.
Pode criar e modificar exibições compartilhadas do Analytics.
Pode acessar dados disponíveis no serviço de Análise. Para obter detalhes, consulte As permissões necessárias para acessar o serviço de Análise.
Test Plans
Pode adicionar e remover resultados de teste e adicionar ou modificar execuções de teste. Para saber mais, confira Control por quanto tempo manter os resultados do teste e executar testes manuais.
Pode criar e excluir configurações de teste.
Pode criar e excluir ambientes de teste.
Pode exibir planos de teste no caminho da área do projeto.
As permissões no nível do projeto disponíveis para o Azure DevOps Server 2019 e versões posteriores variam dependendo do modelo de processo usado pelo projeto. Para obter uma visão geral dos modelos de processo, consulte Personalizar o acompanhamento de trabalho.
Modelo de processo herdado
Modelo de processo XML local
Permissão
Descrição
Os usuários com essa permissão podem salvar um item de trabalho que ignora regras, como cópia, restrição ou regras condicionais, definidas para o tipo de item de trabalho. Os cenários em que isso é útil são migrações em que você não deseja atualizar os campos por/data na importação ou quando deseja ignorar a validação de um item de trabalho.
As regras podem ser ignoradas de duas maneiras. A primeira é por meio dos Itens de Trabalho – atualizar a API REST e definir o bypassRules parâmetro como true. A segunda é por meio do modelo de objeto cliente, inicializando no modo bypassrules (inicializar WorkItemStore com WorkItemStoreFlags.BypassRules).
Quando combinado com a permissão "Editar informações no nível do projeto", permite que os usuários alterem o processo de herança de um projeto. Para saber mais, consulte Criar e gerenciar processos herdados. Requer que o projeto use o modelo de processo herdado.
Pode adicionar marcas a um item de trabalho Por padrão, todos os membros do grupo Colaboradores têm essa permissão.
Observação
Todos os usuários que receberam acesso ao Stakeholder só poderão adicionar marcas existentes, não adicionar novas marcas, mesmo que a permissão Criar definição de marca esteja definida como Permitir. Isso faz parte das configurações de acesso do Stakeholder.
Embora a permissão Criar definição de marca apareça nas configurações de segurança no nível do projeto, as permissões de marcação são, na verdade, permissões de nível de coleção que têm o escopo no nível do projeto quando aparecem na interface do usuário.
Para definir o escopo de permissões de marcação para um único projeto ao usar o comando TFSSecurity , você deve fornecer o GUID para o projeto como parte da sintaxe de comando.
Caso contrário, sua alteração se aplicará a toda a coleção.
Lembre-se disso ao alterar ou definir essas permissões.
Pode adicionar e remover resultados de teste e adicionar ou modificar execuções de teste. Para saber mais, confira Control por quanto tempo manter os resultados do teste e executar testes manuais.
Pode marcar itens de trabalho no projeto como excluídos.
- Para tfs 2015.1 e versões posteriores, o grupo Colaboradores tem Excluir e restaurar itens de trabalho no nível do projeto definido como Permitir por padrão.
- Para tfs 2015 e versões anteriores, o grupo Colaboradores tem Excluir itens de trabalho neste projeto no nível do projeto definido como Não definido por padrão. Essa configuração faz com que o grupo Colaboradores herde o valor do pai mais próximo que o tenha definido explicitamente.
Pode alterar as configurações de rastreamento para coletar informações de diagnóstico mais detalhadas sobre os serviços Web do Azure DevOps.
Pode excluir exibições do Analytics que foram salvas na área Compartilhada. Requer que o projeto use o modelo de processo herdado.
Pode excluir o projeto da coleção de projetos.
Pode excluir uma execução de teste.
Pode editar permissões de nível de projeto para usuários e grupos. Essa permissão inclui a capacidade de executar essas tarefas para o projeto:
- Adicionar e administrar equipes e todos os recursos relacionados à equipe
- Editar permissões no nível do projeto para usuários e grupos no projeto
- Adicionar ou remover grupos de segurança no nível do projeto
- Editar ACLs de permissão no nível do projeto
- Editar assinaturas de evento ou alertas para equipes ou o projeto
Pode criar e modificar exibições compartilhadas do Analytics. Requer que o projeto use o modelo de processo herdado.
Pode fornecer ou editar metadados para um projeto. Por exemplo, um usuário pode fornecer informações de alto nível sobre o conteúdo de um projeto. Há suporte para a alteração de metadados por meio da API REST das propriedades do projeto Set.
Pode criar e excluir configurações de teste.
Pode criar e excluir ambientes de teste.
Pode mover um item de trabalho de um projeto para outro projeto dentro da coleção. Requer que o projeto use o modelo de processo herdado.
Pode excluir permanentemente itens de trabalho deste projeto.
Os usuários com essa permissão podem atualizar itens de trabalho sem gerar notificações. Isso é útil ao executar migrações de atualizações em massa por ferramentas e deseja ignorar a geração de notificações.
Considere conceder essa permissão a contas de serviço ou usuários que receberam as regras de bypass na permissão de atualização de item de trabalho . Você pode definir o suppressNotifications parâmetro para true ao atualizar o trabalho por meio dos Itens de Trabalho – atualizar a API REST.
Pode acessar dados disponíveis no serviço de Análise. Para obter detalhes, consulte As permissões necessárias para acessar o serviço de Análise. Requer que o projeto use o modelo de processo herdado.
Pode exibir permissões e associação de grupo no nível do projeto.
Pode exibir planos de teste no caminho da área do projeto.
Exibições de análise (nível de objeto)
Com exibições compartilhadas do Analytics, você pode conceder permissões específicas para exibir, editar ou excluir uma exibição que você criar. Você gerencia a segurança dos modos de exibição do Analytics no portal da Web.
As permissões a seguir são definidas para cada exibição de Análise compartilhada. Todos os usuários válidos recebem automaticamente todas as permissões para gerenciar exibições do Analytics. Considere conceder permissões de seleção para exibições compartilhadas específicas para outros membros da equipe ou grupo de segurança que você criar. Veja também, O que são exibições do Analytics?
Permissão
Descrição
Pode excluir a exibição de Análise compartilhada.
Pode alterar os parâmetros da exibição de Análise compartilhada.
Pode exibir e usar a exibição de Análise compartilhada do Power BI Desktop.
Dashboards (nível de objeto)
Permissões para painéis de equipe e projeto podem ser definidas individualmente. As permissões padrão para uma equipe podem ser definidas para um projeto. Você gerencia a segurança de dashboards do portal da Web.
Permissões do painel do projeto
Por padrão, o criador do painel do projeto é o proprietário do painel e concedeu todas as permissões para esse painel.
| Permissão | Descrição |
|---|---|
| Excluir painel | Pode excluir o painel do projeto. |
| Editar o painel | Pode adicionar widgets e alterar o layout do painel do projeto. |
| Gerenciar Permissões | Pode gerenciar permissões para o painel do projeto. |
As permissões para painéis de equipe podem ser definidas individualmente. As permissões padrão para uma equipe podem ser definidas para um projeto. Você gerencia a segurança de dashboards do portal da Web.
Permissões padrão do painel de equipe
Por padrão, os administradores de equipe recebem todas as permissões para seus painéis de equipe, incluindo o gerenciamento de permissões de painel padrão e individuais.
| Permissão | Descrição |
|---|---|
| Criar dashboards | Pode criar um painel de equipe. |
| Editar painéis | Pode adicionar widgets e alterar o layout de um painel de equipe. |
| Excluir painéis | Pode excluir um painel de equipe. |
Permissões individuais do painel de equipe
Os administradores de equipe podem alterar as permissões para painéis de equipe individuais alterando as duas permissões a seguir.
| Permissão | Descrição |
|---|---|
| Excluir painel | Pode excluir o painel de equipe específico. |
| Editar o painel | Pode adicionar widgets e alterar o layout do painel de equipe específico. |
Build (nível de objeto)
Você gerencia permissões de build para cada build definido no portal da Web ou usando a ferramenta de linha de comando TFSSecurity. Os Administradores de Projeto recebem todas as permissões de build e os Administradores de Build recebem a maioria dessas permissões. Você pode definir permissões de build para todas as definições de build ou para cada definição de build.
As permissões no Build seguem um modelo hierárquico. Os padrões para todas as permissões podem ser definidos no nível do projeto e podem ser substituídos em uma definição de build individual.
Para definir as permissões no nível do projeto para todas as definições de build em um projeto, escolha Segurança na barra de ações na página principal do hub builds.
Para definir ou substituir as permissões para uma definição de build específica, escolha Segurança no menu de contexto da definição de build.
As permissões a seguir são definidas no Build. Tudo isso pode ser definido em ambos os níveis.
Permissão
Descrição
Pode administrar as permissões de build para outros usuários.
Pode excluir definições de build para este projeto.
Pode excluir um build concluído. Os builds excluídos são mantidos na guia Excluídos por um período de tempo antes de serem destruídos.
Pode excluir permanentemente um build concluído.
Pode salvar quaisquer alterações em um pipeline de build, incluindo variáveis de configuração, gatilhos, repositórios e política de retenção. Disponível com o Azure DevOps Services, o Azure DevOps Server 2019 1.1 e versões posteriores.
Editar pipeline de build Pode salvar quaisquer alterações em um pipeline de build, incluindo variáveis de configuração, gatilhos, repositórios e política de retenção. Disponível com o Azure DevOps Services, o Azure DevOps Server 2019 1.1 e versões posteriores. Substitui Editar definição de build.
Editar definição de build Pode criar e modificar definições de build para este projeto.
Você desativa a herança para uma definição de build quando deseja controlar permissões para definições de build específicas.
Quando a herança está ativada, a definição de build respeita as permissões de build definidas no nível do projeto ou um grupo ou usuário. Por exemplo, um grupo personalizado do Build Managers tem permissões definidas para enfileirar manualmente um build para o projeto Fabrikam. Qualquer definição de build com herança ativada para o projeto Fabrikam permitiria que um membro do grupo Gerenciador de Build tivesse a capacidade de enfileirar manualmente um build.
No entanto, ao desativar a herança para o projeto Fabrikam, você pode definir permissões que permitem apenas que os Administradores de Projeto enfileiram manualmente um build para uma definição de build específica. Isso me permitiria definir permissões para essa definição de build especificamente.
Pode adicionar informações sobre a qualidade do build por meio do Team Explorer ou do portal da Web.
Pode adicionar ou remover qualidades de build. Aplica-se somente a builds XAML.
Pode cancelar, rerioritizar ou adiar builds enfileirados. Aplica-se somente a builds XAML.
Pode confirmar um conjunto de alterações do TFVC que afeta uma definição de build fechada sem disparar o sistema para arquivar e compilar suas alterações primeiro.
Atribua a validação de check-in de substituição por permissão de build somente para contas de serviço para serviços de build e para criar administradores responsáveis pela qualidade do código. Aplica-se a builds de check-in fechados do TFVC. Isso não se aplica a builds de PR. Para obter mais informações, consulte Check-in em uma pasta controlada por um processo de build de check-in fechado.
Pode colocar um build na fila por meio da interface para o Team Foundation Build ou em um prompt de comando. Eles também podem parar as compilações que enfileiraram.
Pode alternar o sinalizador de retenção indefinidamente em um build. Esse recurso marca um build para que o sistema não o exclua automaticamente com base em qualquer política de retenção aplicável.
Pode interromper qualquer build em andamento, incluindo builds enfileirados e iniciados por outro usuário.
Pode adicionar nós de informações de build ao sistema e também pode adicionar informações sobre a qualidade de um build. Atribuir somente a contas de serviço.
Pode exibir as definições de build que foram criadas para o projeto.
Pode exibir os builds enfileirados e concluídos para este projeto.
Repositório Git (nível de objeto)
Você gerencia a segurança de cada repositório Git ou branch do portal da Web, da ferramenta de linha de comando TF ou usando a ferramenta de linha de comando TFSSecurity. Os Administradores de Projeto recebem a maioria dessas permissões (que aparecem apenas para um projeto que foi configurado com um repositório Git). Você pode gerenciar essas permissões para todos os repositórios Git ou para um repositório Git específico.
Defina permissões em todos os repositórios Git fazendo alterações na entrada de repositórios Git de nível superior.
Repositórios individuais herdam permissões da entrada de repositórios Git de nível superior. Branches herdam permissões de atribuições feitas no nível do repositório.
Por padrão, os grupos leitores no nível do projeto têm apenas permissões de leitura.
Permissão
Descrição
Pode optar por substituir políticas de branch verificando políticas de ramificação de substituição e habilitar a mesclagem ao concluir uma PR.
Observação
Ignorar políticas ao concluir solicitações de pull e ignorar políticas ao enviar por push a substituiçãode Isenção de Imposição de Política. Aplica-se ao Azure DevOps Server 2019 e versões posteriores.
Pode enviar por push para um branch que tenha políticas de branch habilitadas. Quando um usuário com essa permissão faz um push que substituiria a política de branch, o push ignora automaticamente a política de branch sem nenhuma etapa de aceitação ou aviso.
Observação
Ignorar políticas ao concluir solicitações de pull e ignorar políticas ao enviar por push a substituiçãode Isenção de Imposição de Política. Aplica-se ao Azure DevOps Server 2019 e versões posteriores.
No nível do repositório, é possível enviar por push suas alterações para branches existentes no repositório e concluir solicitações de pull. Os usuários que não têm essa permissão, mas que têm a permissão Criar branch , podem enviar alterações por push para novas ramificações. Não substitui as restrições em vigor das políticas de branch.
No nível da ramificação, pode enviar suas alterações por push para o branch e bloquear o branch. Bloquear uma ramificação impede que novas confirmações sejam adicionadas ao branch por outras pessoas e impede que outros usuários alterem o histórico de confirmação existente.
Pode criar, comentar e votar em solicitações de pull.
Pode criar e publicar branches no repositório. A falta dessa permissão não limita os usuários de criar branches em seu repositório local; ele apenas impede que eles publiquem branches locais no servidor.
Observação
Quando um usuário cria um novo branch no servidor, ele tem permissões Contribuir, Editar Políticas, Forçar Push, Gerenciar Permissões e Remover Outras Permissões de Bloqueios para esse branch por padrão. Isso significa que os usuários podem adicionar novas confirmações ao repositório por meio de seu branch.
Pode criar novos repositórios. Essa permissão só está disponível na caixa de diálogo Segurança para o objeto de repositórios Git de nível superior.
Pode enviar marcas por push para o repositório.
Pode excluir o repositório. No nível de repositórios Git de nível superior, pode excluir qualquer repositório.
Pode editar políticas para o repositório e suas ramificações.
Pode ignorar as políticas de branch e executar as duas ações a seguir:
- Substituir políticas de branch e PRs completos que não satisfazem a política de branch
- Enviar por push diretamente para branches que têm políticas de branch definidas
Observação
Aplica-se ao TFS 2015 por meio do TFS 2018 Atualização 2. (No Azure DevOps, ele é substituído pelas duas permissões a seguir: ignorar políticas ao concluir solicitações de pull e ignorar políticas ao enviar push.
Pode forçar uma atualização para um branch, excluir um branch e modificar o histórico de confirmação de um branch. Pode excluir marcas e anotações.
Pode enviar por push e editar anotações do Git.
Pode definir permissões para o repositório.
Pode clonar, buscar, efetuar pull e explorar o conteúdo do repositório.
Pode remover bloqueios de ramificação definidos por outros usuários. Bloquear uma ramificação impede que novas confirmações sejam adicionadas ao branch por outras pessoas e impede que outros usuários alterem o histórico de confirmação existente.
Pode alterar o nome do repositório. Quando definido na entrada de repositórios Git de nível superior, pode alterar o nome de qualquer repositório.
Observação
Defina permissões em todos os repositórios Git fazendo alterações na entrada de repositórios Git de nível superior. Repositórios individuais herdam permissões da entrada de repositórios Git de nível superior. Branches herdam permissões de atribuições feitas no nível do repositório. Por padrão, os grupos leitores de nível de projeto só têm permissões de leitura.
Para gerenciar permissões de repositório git e branch, consulte Definir permissões de branch.
TFVC (nível do objeto)
Você gerencia a segurança de cada branch TFVC no portal da Web ou usando a ferramenta de linha de comando TFSSecurity. Os Administradores de Projeto recebem a maioria dessas permissões que aparecem apenas para um projeto que foi configurado para usar o Controle de Versão do Team Foundation como um sistema de controle do código-fonte. Nas permissões de controle de versão, uma negação explícita tem precedência sobre as permissões do grupo de administradores.
Essas permissões aparecem apenas para uma instalação de projeto usar o Controle de Versão do Team Foundation como o sistema de controle de origem.
Nas permissões de controle de versão, uma negação explícita tem precedência sobre as permissões do grupo de administradores.
Permissão
Descrição
Administrar rótulos
Pode editar ou excluir rótulos criados por outro usuário.
Fazer check-in
Pode fazer check-in de itens e revisar quaisquer comentários de conjunto de alterações confirmados. As alterações pendentes são confirmadas no check-in.
Observação
Considere adicionar essas permissões a quaisquer usuários ou grupos adicionados manualmente que contribuam para o desenvolvimento do projeto; todos os usuários que devem ser capazes de fazer check-in e fazer check-out de alterações, fazer uma alteração pendente em itens em uma pasta ou revisar quaisquer comentários confirmados do conjunto de alterações.
Fazer check-in de alterações de outros usuários
Pode verificar as alterações feitas por outros usuários. As alterações pendentes são confirmadas no check-in.
Check-out (até O TFS 2015)
Aguardar uma alteração em um workspace do servidor (TFS 2017 e superior)
Pode fazer check-out e fazer uma alteração pendente em itens em uma pasta. Os exemplos de alterações pendentes incluem adição, edição, renomeação, exclusão, cancelamento de exclusão, ramificação e mesclagem de um arquivo. As alterações pendentes devem ser verificadas, portanto, os usuários também precisarão da permissão check-in para compartilhar suas alterações com a equipe.
Observação
Considere adicionar essas permissões a quaisquer usuários ou grupos adicionados manualmente que contribuam para o desenvolvimento do projeto; todos os usuários que devem ser capazes de fazer check-in e fazer check-out de alterações, fazer uma alteração pendente em itens em uma pasta ou revisar quaisquer comentários confirmados do conjunto de alterações.
Rótulo
Pode rotular itens.
Pode bloquear e desbloquear pastas ou arquivos. Uma pasta ou arquivo rastreado pode ser bloqueado ou desbloqueado para negar ou restaurar os privilégios de um usuário. Os privilégios incluem fazer check-out de um item para edição em um workspace diferente ou fazer check-in em Alterações Pendentes para um item de um workspace diferente. Para obter mais informações, consulte o comando Bloquear.
Gerenciar ramificação
Pode converter qualquer pasta nesse caminho em um branch e também executar as seguintes ações em um branch: editar suas propriedades, repará-la e convertê-la em uma pasta. Os usuários que têm essa permissão só poderão ramificar esse branch se também tiverem a permissão Mesclagem para o caminho de destino. Os usuários não podem criar ramificações de uma ramificação para qual eles não têm a permissão Gerenciar ramificação.
Gerenciar permissões
Pode gerenciar as permissões de outros usuários para pastas e arquivos no controle de versão.
Observação
Considere adicionar essa permissão a quaisquer usuários ou grupos adicionados manualmente que contribuam para o desenvolvimento do projeto e que devem ser capazes de criar branches privados, a menos que o projeto esteja sob práticas de desenvolvimento mais restritivas.
Pode mesclar alterações nesse caminho.
Observação
Considere adicionar essa permissão a quaisquer usuários ou grupos adicionados manualmente que contribuam para o desenvolvimento do projeto e que devem ser capazes de mesclar arquivos de origem, a menos que o projeto esteja sob práticas de desenvolvimento mais restritivas.
Ler
Pode ler o conteúdo de um arquivo ou pasta. Se um usuário tiver permissões Ler para uma pasta, o usuário poderá ver o conteúdo da pasta e as propriedades dos arquivos nele, mesmo que o usuário não tenha permissão para abrir os arquivos.
Revisar alterações de outros usuários
Pode editar os comentários em arquivos de check-in, mesmo que outro usuário tenha verificado no arquivo.
Observação
Considere adicionar essa permissão a todos os usuários ou grupos adicionados manualmente responsáveis por supervisionar ou monitorar o projeto e que podem ou devem alterar os comentários em arquivos check-in, mesmo que outro usuário tenha verificado no arquivo.
Desfazer alterações de outros usuários Mesclar
Pode desfazer uma alteração pendente feita por outro usuário.
Observação
Considere adicionar essa permissão a todos os usuários ou grupos adicionados manualmente responsáveis por supervisionar ou monitorar o projeto e que podem ou devem alterar os comentários em arquivos check-in, mesmo que outro usuário tenha verificado no arquivo.
Desbloquear alterações de outros usuários
Pode desbloquear arquivos bloqueados por outros usuários.
Observação
Considere adicionar essa permissão a todos os usuários ou grupos adicionados manualmente responsáveis por supervisionar ou monitorar o projeto e que podem ou devem alterar os comentários em arquivos check-in, mesmo que outro usuário tenha verificado no arquivo.
Caminho da área (nível do objeto)
As permissões de caminho de área concedem ou restringem o acesso a branches da hierarquia de área e aos itens de trabalho nessas áreas. Você gerencia a segurança de cada caminho de área no portal da Web ou usando a ferramenta de linha de comando TFSSecurity. As permissões de área concedem ou restringem o acesso para criar e gerenciar caminhos de área, bem como criar e modificar itens de trabalho definidos em caminhos de área.
Os membros do grupo Administradores de Projeto recebem automaticamente permissões para gerenciar caminhos de área para um projeto. Considere conceder permissões de clientes potenciais de equipe ou administradores de equipe para criar, editar ou excluir nós de área.
Observação
Várias equipes podem contribuir para um projeto. Quando esse for o caso, você pode configurar equipes associadas a uma área. As permissões para os itens de trabalho da equipe são atribuídas atribuindo permissões à área. Há outras configurações de equipe que configuram as ferramentas de planejamento agile da equipe.
Permissão
Descrição
Pode criar nós de área. Os usuários que têm essa permissão e a permissão Editar esse nó podem mover ou reordenar quaisquer nós de área filho.
Considere adicionar essa permissão a quaisquer usuários ou grupos adicionados manualmente que possam precisar excluir, adicionar ou renomear nós de área.
Os usuários que têm essa permissão e a permissão Editar esse nó para outro nó podem excluir nós de área e reclassificar itens de trabalho existentes do nó excluído. Se o nó excluído possuir nós filho, esses nós também serão excluídos.
Observação
Considere adicionar essa permissão a quaisquer usuários ou grupos adicionados manualmente que possam precisar excluir, adicionar ou renomear nós de área.
Pode definir permissões para esse nó e renomear nós de área.
Observação
Considere adicionar essa permissão a quaisquer usuários ou grupos adicionados manualmente que possam precisar excluir, adicionar ou renomear nós de área.
Pode editar itens de trabalho neste nó de área.
Observação
Considere adicionar essa permissão a quaisquer usuários ou grupos adicionados manualmente que possam precisar editar itens de trabalho no nó da área.
Pode modificar propriedades do plano de teste, como configurações de build e teste.
Observação
Considere adicionar permissões gerenciar conjuntos de testes a quaisquer usuários ou grupos adicionados manualmente que possam precisar gerenciar planos de teste ou conjuntos de testes nesse nó de área.
Pode criar e excluir conjuntos de testes, adicionar e remover casos de teste de conjuntos de testes, alterar as configurações de teste associadas a conjuntos de testes e modificar a hierarquia do pacote (mover um conjunto de testes).
Considere adicionar permissões gerenciar conjuntos de testes a quaisquer usuários ou grupos adicionados manualmente que possam precisar gerenciar planos de teste ou conjuntos de testes nesse nó de área.
Pode exibir as configurações de segurança para este nó.
Pode exibir, mas não alterar, itens de trabalho neste nó de área.
Observação
Se você definir os itens de trabalho Exibir neste nó como Negar, o usuário não poderá ver nenhum item de trabalho neste nó de área. Uma Negação substituirá qualquer permissão implícita, mesmo para usuários que são membros de grupos administrativos.
Caminho da Iteração (nível de objeto)
As permissões de caminho de iteração concedem ou restringem o acesso para criar e gerenciar caminhos de iteração, também conhecidos como sprints.
Você gerencia a segurança de cada caminho de iteração no portal da Web ou usando a ferramenta de linha de comando TFSSecurity.
Os membros do grupo Administradores do Projeto recebem automaticamente essas permissões para cada iteração definida para um projeto. Considere conceder permissões de administradores de equipe, scrum masters ou líderes de equipe para criar, editar ou excluir nós de iteração.
Permissão
Descrição
Pode criar nós de iteração. Os usuários que têm essa permissão e a permissão Editar esse nó podem mover ou reordenar quaisquer nós de iteração filho.
Observação
Considere adicionar essa permissão a quaisquer usuários ou grupos adicionados manualmente que possam precisar excluir, adicionar ou renomear nós de iteração.
Os usuários que têm essa permissão e a permissão Editar esse nó para outro nó podem excluir nós de iteração e reclassificar itens de trabalho existentes do nó excluído. Se o nó excluído possuir nós filho, esses nós também serão excluídos.
Observação
Considere adicionar essa permissão a quaisquer usuários ou grupos adicionados manualmente que possam precisar excluir, adicionar ou renomear nós de iteração.
Pode definir permissões para esse nó e renomear nós de iteração.
Observação
Considere adicionar essa permissão a quaisquer usuários ou grupos adicionados manualmente que possam precisar excluir, adicionar ou renomear nós de iteração.
Pode exibir as configurações de segurança para esse nó.
Observação
Membros da Coleção de Projetos Usuários Válidos, Usuários Válidos do Projeto ou qualquer usuário ou grupo que tenha informações de nível de coleção de exibição ou exibir informações no nível do projeto podem exibir permissões de qualquer nó de iteração.
Pasta de consulta e consulta de item de trabalho (nível de objeto)
Você gerencia permissões de pasta de consulta e consulta por meio do portal da Web. Os Administradores de Projeto recebem todas essas permissões. Os colaboradores recebem somente permissões de leitura. Considere conceder as permissões do Contribute para usuários ou grupos que exigem a capacidade de criar e compartilhar consultas de item de trabalho para o projeto.
Considere conceder as permissões do Contribute para usuários ou grupos que exigem a capacidade de criar e compartilhar consultas de item de trabalho para o projeto. Para saber mais, consulte Definir permissões em consultas.
Observação
Para criar gráficos de consulta , você precisa de acesso básico.
Permissão
Descrição
Pode exibir e modificar essa pasta de consulta ou consulta.
Pode excluir uma pasta de consulta ou consulta e seu conteúdo.
Pode gerenciar as permissões para essa consulta ou pasta de consulta.
Pode exibir e usar a consulta ou as consultas em uma pasta, mas não pode modificar o conteúdo da pasta de consulta ou consulta.
Planos de Entrega (nível de objeto)
Você gerencia permissões de plano por meio do portal da Web. Você gerencia permissões para cada plano por meio de sua caixa de diálogo Segurança. Os Administradores do Projeto recebem todas as permissões para criar, editar e gerenciar planos. Os usuários válidos recebem permissões de Exibição (somente leitura).
Permissão
Descrição
Pode excluir o plano selecionado.
Pode editar a configuração e as configurações definidas para o plano selecionado.
Pode gerenciar as permissões para o plano selecionado.
Pode exibir as listas de planos, abrir e interagir com um plano, mas não pode modificar a configuração ou as configurações do plano.
Processo (nível de objeto)
Você pode gerenciar as permissões para cada processo herdado criado por meio do portal da Web. Você gerencia permissões para cada processo por meio de sua caixa de diálogo Segurança. Os Administradores de Coleção de Projetos recebem todas as permissões para criar, editar e gerenciar processos. Os usuários válidos recebem permissões de Exibição (somente leitura).
Permissão
Descrição
Pode definir ou alterar as permissões para um processo herdado.
Pode excluir o processo herdado.
Pode criar um processo herdado de um processo do sistema ou copiar ou modificar um processo herdado.
Marcas de item de trabalho
Você pode gerenciar permissões de marcação usando a permissão de segurança az devops ou as ferramentas de linha de comando TFSSecurity . Os colaboradores podem adicionar marcas a itens de trabalho e usá-las para filtrar rapidamente uma exibição de backlog, quadro ou resultados de consulta.
Você pode gerenciar permissões de marcação usando a ferramenta de linha de comando TFSSecurity. Os colaboradores podem adicionar marcas a itens de trabalho e usá-las para filtrar rapidamente uma exibição de backlog, quadro ou resultados de consulta.
Permissão
Descrição
Pode criar novas marcas e aplicá-las a itens de trabalho. Os usuários sem essa permissão só podem selecionar no conjunto existente de marcas para o projeto.
Observação
Por padrão, os Colaboradores recebem a permissão Criar definição de marca . Embora a permissão Criar definição de marca apareça nas configurações de segurança no nível do projeto, as permissões de marcação são, na verdade, permissões de nível de coleção que têm escopo no nível do projeto quando aparecem na interface do usuário. Para definir o escopo das permissões de marcação para um único projeto ao usar uma ferramenta de linha de comando, você deve fornecer o GUID para o projeto como parte da sintaxe de comando. Caso contrário, a alteração será aplicada a toda a coleção. Lembre-se disso ao alterar ou definir essas permissões.
Pode remover uma marca da lista de marcas disponíveis para esse projeto.
Observação
Essa permissão não aparece na interface do usuário. Ele só pode ser definido usando uma ferramenta de linha de comando. Também não há interface do usuário para excluir explicitamente uma marca. Em vez disso, quando uma marca não está em uso há três dias, o sistema a exclui automaticamente.
Pode exibir uma lista de marcas disponíveis para o item de trabalho dentro do projeto. Os usuários sem essa permissão não terão uma lista de marcas disponíveis na qual fazer escolhas no formulário de item de trabalho ou no editor de consulta.
Observação
Essa permissão não aparece na interface do usuário. Ele só pode ser definido usando uma ferramenta de linha de comando. As informações de modo de exibição no nível do projeto permitem implicitamente que os usuários exibam marcas existentes.
Pode renomear uma marca usando a API REST.
Observação
Essa permissão não aparece na interface do usuário. Ele só pode ser definido usando uma ferramenta de linha de comando.
Versão (nível do objeto)
Você gerencia permissões para cada versão definida no portal da Web. Administradores de projeto e administradores de versão recebem todas as permissões de gerenciamento de versão. Essas permissões podem ser concedidas ou negadas em um modelo hierárquico no nível do projeto, para um pipeline de lançamento específico ou para um ambiente específico em um pipeline de lançamento. Dentro dessa hierarquia, as permissões podem ser herdadas do pai ou substituídas.
Observação
O grupo do Administrador de Versão no nível do projeto é criado ao mesmo tempo em que o primeiro pipeline de lançamento é definido.
Além disso, você pode atribuir aprovadores a etapas específicas em um pipeline de lançamento para garantir que os aplicativos implantados atendam aos padrões de qualidade.
As permissões a seguir são definidas no Gerenciamento de Versão. A coluna de escopo explica se a permissão pode ser definida no projeto, no pipeline de lançamento ou no nível do ambiente.
Permissão
Descrição
Escopos
Pode alterar qualquer uma das outras permissões listadas aqui.
Project, Release pipeline, Environment
Pode criar novas versões.
Project, Release pipeline
Pode excluir pipelines de versão.
Project, Release pipeline
Pode excluir ambientes em pipelines de versão.
Project, Release pipeline, Environment
Pode excluir versões de um pipeline.
Project, Release pipeline
Pode adicionar e editar um pipeline de lançamento, incluindo variáveis de configuração, gatilhos, artefatos e política de retenção, bem como configuração em um ambiente do pipeline de lançamento. Para fazer alterações em um ambiente específico em um pipeline de lançamento, o usuário também precisa editar a permissão de ambiente de versão .
Project, Release pipeline
Pode editar ambientes em pipelines de versão. Para salvar as alterações no pipeline de lançamento, o usuário também precisa editar a permissão de pipeline de versão. Essa permissão também controla se um usuário pode editar a configuração dentro do ambiente de uma instância de versão específica. O usuário também precisa da permissão Gerenciar versões para salvar a versão modificada.
Project, Release pipeline, Environment
Pode iniciar uma implantação direta de uma versão em um ambiente. Essa permissão é apenas para implantações diretas iniciadas manualmente selecionando a ação Implantar em uma versão. Se a condição em um ambiente for definida como qualquer tipo de implantação automática, o sistema iniciará automaticamente a implantação sem verificar a permissão do usuário que criou a versão.
Project, Release pipeline, Environment
Pode adicionar ou editar aprovadores para ambientes em pipelines de versão. Essa permissão também controla se um usuário pode editar os aprovadores dentro do ambiente de uma instância de versão específica.
Project, Release pipeline, Environment
Pode editar uma configuração de versão, como estágios, aprovadores e variáveis. Para editar a configuração de um ambiente específico em uma instância de versão, o usuário também precisa editar a permissão de ambiente de versão .
Project, Release pipeline
Pode exibir pipelines de versão.
Project, Release pipeline
Pode exibir versões pertencentes a pipelines de lançamento.
Project, Release pipeline
Os valores padrão para todas essas permissões são definidos para coleções de projetos de equipe e grupos de projetos. Por exemplo, administradores de coleção de projetos, administradores de projeto e administradores de versão recebem todas as permissões acima por padrão. Os colaboradores recebem todas as permissões, exceto as permissões de administração de versão. Os leitores, por padrão, têm todas as permissões negadas, exceto versões de pipeline de versão e exibição.
Permissões de grupo de tarefas (build e versão)
Você gerencia permissões para grupos de tarefas no Hub de Compilação e Lançamento do portal da Web. Os Administradores de Projeto, Build e Versão recebem todas as permissões. As permissões do grupo de tarefas seguem um modelo hierárquico. Os padrões para todas as permissões podem ser definidos no nível do projeto e podem ser substituídos em uma definição de grupo de tarefas individual.
Você usa grupos de tarefas para encapsular uma sequência de tarefas já definidas em um build ou uma definição de versão em uma única tarefa reutilizável. Você define e gerencia grupos de tarefas na guia Grupos de tarefas do Hub de Compilação e Versão .
| Permissão | Descrição |
|---|---|
| Administrar permissões de grupo de tarefas | Pode adicionar e remover usuários ou grupos à segurança do grupo de tarefas. |
| Excluir grupo de tarefas | Pode excluir um grupo de tarefas. |
| Editar grupo de tarefas | Pode criar, modificar ou excluir um grupo de tarefas. |
Notificações ou alertas
Não há permissões de interface do usuário associadas ao gerenciamento de notificações ou alertas por email. Em vez disso, eles podem ser gerenciados usando a permissão de segurança az devops ou as ferramentas de linha de comando TFSSecurity .
Não há permissões de interface do usuário associadas ao gerenciamento de notificações ou alertas por email. Em vez disso, eles podem ser gerenciados usando a ferramenta de linha de comando TFSSecurity .
- Por padrão, os membros do grupo colaboradores no nível do projeto podem assinar alertas por conta própria.
- Membros do grupo Administradores de Coleção de Projetos ou usuários que têm as informações de nível de coleção Editar podem definir alertas nessa coleção para outras pessoas ou para uma equipe.
- Membros do grupo Administradores do Projeto ou usuários que têm as informações de nível de projeto editar podem definir alertas nesse projeto para outras pessoas ou para uma equipe.
Você pode gerenciar permissões de alerta usando o TFSSecurity.
Ação TFSSecurity
TFSSecurity Namespace
Descrição
Administradores de Coleção de Projetos &
Contas de Serviço de Coleção de Projetos
CREATE_SOAP_SUBSCRIPTION
EventSubscription
Pode criar uma assinatura de serviço Web baseada em SOAP.
✔️
GENERIC_READ
EventSubscription
Pode exibir eventos de assinatura definidos para um projeto.
✔️
GENERIC_WRITE
EventSubscription
Pode criar alertas para outros usuários ou para uma equipe.
✔️
UNSUBSCRIBE
EventSubscription
Pode cancelar a assinatura de um evento.
✔️
Artigos relacionados
- Introdução às permissões, ao acesso e aos grupos de segurança
- Ferramentas de gerenciamento de permissões e segurança
- Contas e dependências de serviço
- Adicionar usuários a uma organização (Azure DevOps Services)
- Adicionar usuários a uma equipe ou a um projeto
- Adicionar usuários a uma função de administrador
- Tornar um usuário um administrador de equipe
- Solucionar problemas de permissões