As permissAi??es determinam que tasks os usuA?rios podem e nA?o podem fazer. Para os usuA?rios terem acesso aos recursos do Team Foundation Server(TFS), vocA? precisa adiciona-los a um Team Project ou TFS Group. O TFS oferece diversos grupos prAi??-configurados, em vA?rios nAi??veis que ajudam vocA? no trabalho de gerenciar usuA?rios e permissAi??es. Nesse artigo vamos tratar dos nAi??veis de Collections e Object and Projects apenas, por serem os nAi??veis mais prA?ximos do dia-a-dia de gerentes de projeto e desenvolvedores. Apenas para conhecimento, segue abaixo um quadro resumo que demonstra os grupos e os nAi??veis de permissA?o destes.
Grupos de nAi??vel Collection
Por padrA?o, os seguintes grupos existem no nAi??vel collection quando vocA? configura uma collection:
| Group name (prefix: TeamProjectCollectionName\) | Group-level permissions | Account assignments |
|---|---|---|
| Project Collection Administrators | Pode executar qualquer operaAi??A?o sobre um project collection | ContAi??m o grupo de administradores locais (BUILTIN\Administrators) para o servidor onde o TFS foi instalado. TambAi??m os membros do grupo TeamProjectCollectionName\Service Accounts.Esse grupo deve ser restrito ao menor nA?mero de pessoas possAi??vel |
| Project Collection Valid Users | O membros desse grupo possuem acesso ao TFS.
Nota:Ai??Se vocA? definir a permissA?o View Collection-Level Information para Deny ou Not Set para esse grupo, nenhum usuA?rio poderA? acessar essa coleAi??A?o. |
Esse grupo automaticamente contAi??m todos os usuA?rios que foram adicionados ao TFS em algum momento. VocA? nA?o pode modificar os membros desse grupo. |
| Project Collection Service Accounts | Esse grupo possui permissAi??es de nAi??vel de serviAi??o ao TFS.Ai?? | Por padrA?o, esse grupo contem as contas de serviAi??o providas durante a instalaAi??A?o. Esse grupo deve conter apenas contas de serviAi??o e nA?o contas de usuA?rios ou grupos que contenham contas de usuA?rios. Por padrA?o esse grupo Ai?? membro do TeamAi??Foundation Administrators eAi??Team Foundation Service Accounts. |
| Project Collection Build Administrators | Pode administrar recursos de build e permissAi??es para a coleAi??A?o | Limite esse grupo ao menor nA?mero possAi??vel de pessoas que necessitam de total controle sobre os servidores de build e serviAi??os para esta coleAi??A?o |
| Project Collection Build Service Accounts | ContAi??m as permissAi??es necessA?rias para executar serviAi??os de build para a coleAi??A?o. | Limite esse grupo a contas de serviAi??o e grupos que contenham apenas contas de serviAi??o |
| Project Collection Proxy Service Accounts | Possui permissAi??es para executar serviAi??os de proxy para coleAi??A?o | Limite esse grupo a contas de serviAi??o e grupos que contenham apenas contas de serviAi??o |
| Project Collection Test Service Accounts | Possui permisAi??es para executar serviAi??os de teste para a coleAi??A?o | Limite esse grupo a contas de serviAi??o e grupos que contenham apenas contas de serviAi??o |
Grupos de NAi??vel de Projeto
Por padrA?o, os seguintes grupos existem quando vocA? criar um Team Project. Estas permissAi??es pertencem a o escopo do nAi??vel de projeto.
| Nome do Grupo (prefix: ProjectName\) | Nivel de permissAi??es do Grupo | Account assignments |
|---|---|---|
| Project Administrators | Pode administrar todos os aspectos do Project Team, mas nA?o pode criar projetos | Essa permissA?o deve ser concedida aos usuA?rios que irA?o gerenciar permissAi??es de usuA?rios, criar teams, definir A?reas e iteration paths, ou customizar o rastreamento de work items./td> |
| Build administrators | Pode administrar recursos e permissAi??es de build para o projeto. Os membros desse grupo podem gerenciar ambientes de teste, criar execuAi??Ai??es de teste e gerenciar builds. | |
| Contributors | Possui total acesso ao cA?digo do projeto e rastreamento de work items. Tem acesso limitado a work item queries, build, e funcionalidades de teste. | Por padrA?o, o team group criardo ao criar um team project Ai?? adicionado a esse grupo, e qualquer membro que vocA? adicione ao team serA? um membro desse grupo. |
| Readers | Podem visualizar o projeto mas nA?o modifica-lo. | Astil para stakeholders que querem acompanhar o progresso do projeto. |
| TeamName | Herda as mesmas pemissAi??es do grupo contributors. |
Lado a lado com os grupos de nAi??vel de projeto, hA? tambAi??m dois grupos de nAi??vel collection que aparece em todos os projetos criados no TFS.
- TeamProjectCollectionName \Project Collection Administrators: VocA? nA?o pode modificar as permissAi??es desse grupo.
- TeamProjectCollectionName \Project Collection Build Service Accounts: NA?o remova ou configure a permissA?o View project-level information para Deny para esse grupo
Allow, Deny, Not Set e outros nAi??veis de permissA?o
TFS adota o modelo de seguranAi??a least-permissive. Isso significa que se a mesma permissA?o for configurada com Allow para um grupo e Deny para um outro grupo que o usuA?rio pertenAi??a, Deny terA? precedA?ncia sobre Allow e o usuA?rio nA?o terA? acesso. Existe algumas exceAi??Ai??es a essa regra para os usuA?rios que pertencem aos grupos Project Collection Administrator e Team Foundation Server Administrator.
VocA? pode especificar dois estados de permissAi??es explAi??citos: Deny e Allow. E hA? tambAi??m trA?s outros estados: Inherited Allow, Inherited Deny e Not Set. Not Set Ai?? um estado Deny implAi??cito.
- Allow: Concede explicitamente aos usuA?rios executar tarefas associadas a permissA?o especAi??fica. Allow Ai?? normalmente herdado do grupo que o usuA?rio pertence. Para executar uma tarefa, a permissA?o a esta deve ser Allow ou Inherited Allow
- Deny: Evita explicitamente que os usuA?rio tenha acesso a determinado recurso. Assim como Allow, Deny Ai?? normalemente herdado do grupo.
- Inherited allow/Inherited deny: Concede ou impede o acesso a determinado recurso ao usuA?rio, baseado nas permissAi??es de grupo deste.
- Not Set:Evita implicitamente que o usuA?rios acessem um determinado recurso.
PrA?ticas recomendadas
- Utilize grupos do windows quando estiver gerenciando muitos usuA?rios
- Considere conceder permissAi??es Contribute a usuA?rios e grupos que necessitam da habilidade de criar e compartilhar work item queries para o projeto.
- Ao adicionar muitos teams, considere um grupo de administradores de times ao TFS. Onde vocA? pode alocar ou criar um subconjunto de permissAi??es disponAi??veis ao grupo Project Admnistrators
- Ao criar novos teams, considere que permissAi??es vocA? quer atribuir a team leads, scrum masters, e outros membros que necessitam criar e modificar area paths, iteration paths, e queries
O que nA?o fazer
- NA?o adicione contas que pertencam ao grupo Project Administrators ao Grupo Readers. Isso farA? com que o status deny seja atribuAi??do a diversas permissAi??es
- NA?o modifique as definiAi??Ai??es standard feitas para o grupo valid users. Negar permissAi??es para um desses grupos faz com que nenhum usuA?rio consiga mais acessar team project, collection ou o deployment, dependendo do grupo que vocA? atribuir Deny
- NA?o atribua permissAi??es assinaladas como ‘Assing only to service accounts’ para contas de usuA?rios
