Permissionamento & Direitos Efetivos no Project Online

Olá pessoal –

Do ponto de vista de segurança, é muito comum que as empresas limitem algumas permissões dos usuários que utilizam o Project Online para gerenciar os seus projetos. Um dos principais objetivos de restringir algumas permissões está associado à governança e conformidade, pois deve-se evitar que os usuários, por desconhecimento ou de maneira deliberada, executem algumas ações que não fazem parte da sua rotina de trabalho com a plataforma PPM.

Um exemplo clássico é a exclusão de projetos: por padrão, o Project Online permite que os gerentes de projeto possam excluir os projetos dos quais forem proprietários. Para evitar que esse tipo de ação seja tomada, muitas empresas decidem remover a permissão dos gerentes de projeto, deixando esta ação a cargo de administradores ou super-users (normalmente, membros do PMO com maiores privilégios na plataforma).

No Project Online, caso a sua empresa esteja utilizando o modo de permissão Project Server, os grupos de segurança irão possuir três possíveis opções de permissionamento: 1) Permitir, 2) Negar e 3) Não permitir. Permitir significa que as permissões foram concedidas ao grupo, de modo que seus membros poderão executar as ações associadas à permissão; Negar significa que, de maneira explícita, qualquer ação associada à permissão está proibida; a opção Não permitir acontece quando uma permissão não está concedida e nem negada explicitamente.

As configurações de segurança em vigor na sua empresa devem ser estudadas e bem planejadas para que os usuários possam ter acesso a todas funcionalidades inerentes ao seu trabalho, ao mesmo tempo que estejam dentro dos padrões de segurança, conformidade e governança estabelecidos. Recentemente tive uma experiência interessante com um cliente, a qual gostaria de compartilhar nesse post.

Havia um grupo de usuários que eram Administradores do Project Online, ao mesmo tempo em que também estavam inseridos no grupo Gerentes de Projeto. Uma das regras de negócio em vigor na organização determinava que os gerentes de projeto não poderiam salvar as Linhas de Base, uma vez que esta ação seria uma responsabilidade do time de PMO. Para aplicar tal configuração, a permissão ‘Salvar Linha de Base Protegida’ foi negada para o grupo gerentes de projeto. Pois bem, o que aconteceu em seguida foi que qualquer usuário que fizesse a tentativa de salvar uma Linha de Base seria impedido, mesmo que fosse membro do grupo de Administradores, os quais possuíam a permissão. Mas, então, qual a razão para este comportamento?

O que aconteceu nesse caso está relacionado à natureza da opção de negar explicitamente uma permissão: caso uma permissão seja explicitamente negada, ela irá se sobrepor à permissão Permitir, independentemente de o usuário possuir a permissão em outro grupo. Por este motivo, a utilização da opção Negar é recomendada apenas em cenários muito específicos, quando como desejamos limitar as permissões de usuários externos que possuem acesso ao ambiente da nossa organização.

Ok, mas o que os direitos efetivos tem a ver com isso?

Os direitos efetivos são uma excelente ferramenta para que seja possível entender as permissões que foram concedidas ou negadas a um determinado usuário. Pegando o gancho no caso anterior: você acabou de assumir a administração do Project Online em uma determinada empresa, e alguns usuários estão reportando que não possuem as devidas permissões para executar suas atividades. Você não tem o histórico do ambiente, e não sabe quais configurações e parametrizações de segurança foram feitas... então, como é possível descobrir a causa-raiz do problema?

Para isso, você pode navegar à página de Configurações do PWA e então clicar em Gerenciar Usuários. Em seguida, selecione o usuário que está reportando o problema e clique em Verifique os Direitos Efetivos:

Você poderá então navegar entre as permissões globais e os diferentes tipos de objeto de segurança (projetos, recursos e modos de exibição) para entender as permissões concedidas e negadas para o usuário, assim como o contexto na qual elas acontecem. Perceba que, neste exemplo, o usuário Arthur Mamede está com a permissão ‘Gerenciar Check-Ins’ negada no contexto do grupo de segurança Gerentes de projeto:

Alterando o tipo de permissão para o contexto dos projetos, é possível identificar que o mesmo usuário está com a permissão ‘Salvar Linha de Base Protegida’ para o projeto ‘Bay Plaza’, no contexto do grupo de segurança Gerentes de projeto:

Utilizando os direitos efetivos para identificar as restrições existentes irá ajudá-lo a entender o contexto das configurações de segurança em vigor na sua organização, de modo que você poderá elaborar um plano de reestruturação para sua melhor adequação às necessidades e parâmetros de segurança, conformidade e governança.

Por hoje, vou ficando por aqui. Espero que o post seja útil!

Um forte abraço!