Segurança de hierarquia para controlar o acesso

O modelo de segurança da hierarquia é uma extensão dos modelos de segurança existentes que utilizam unidades de negócio, direitos de acesso, partilha e equipas. Pode ser utilizado com todos modelos de segurança restantes existentes. A segurança da hierarquia oferece um acesso mais granular aos registos de uma organização e ajuda a reduzir os custos de manutenção.

Por exemplo, em cenários complexos, pode-se começar com a criação de várias unidades de negócios e, em seguida, adicionar a segurança hierárquica. Esta segurança adicional fornece um acesso aos dados mais granulado com muito menos custos de manutenção que um grande número de unidades de negócio pode exigir.

Modelos de segurança de hierarquia de gestores e de hierarquia de postos

Dois modelos de segurança podem ser utilizados para hierarquias de gestores e a hierarquia de cargos. Com a hierarquia de gestor, um gestor deve estar na mesma unidade de negócio que o relatório, ou na unidade de negócio principal da unidade de negócio do relatório, para ter acesso aos dados do relatório. A hierarquia de posição permite o acesso aos dados através das unidades de negócio. Se for uma organização financeira, poderá preferir o modelo da hierarquia de gestor, para impedir que os gestores acedam aos dados fora das unidades de negócio. Contudo, se for uma parte de uma organização de suporte ao cliente e pretender que os gestores acedam aos incidentes de suporte processados em unidades de negócio diferentes, a hierarquia de posição poderá funcionar melhor para si.

Hierarquia de gestores

O modelo de segurança da hierarquia de gestores é baseado na cadeia de gestão ou na estrutura direta de reporte, onde a relação entre o gestor e o relatório é estabelecida através do campo Gestor na tabela de utilizador do sistema. Com este modelo de segurança, os gestores podem aceder aos dados a que os relatórios deles têm acesso. Podem executar o trabalho em nome dos subordinados diretos ou aceder às informações que necessitam de aprovação.

Para um relatório não direto na mesma cadeia de gestão, um gestor tem acesso apenas de leitura aos dados desse relatório. Para um relatório direto, o gestor tem o acesso Ler, Escrever, Anexar, AnexarA aos dados do relatório. Para ilustrar o Modelo de segurança da hierarquia de gestores, vejamos o diagrama que se segue. O CEO pode ler ou atualizar os dados do Vice-Presidente de Vendas e os dados do Vice-Presidente de Serviço. Contudo, o CEO só pode ler os dados do gestor de vendas e os dados do gestor de serviço, bem como os dados de vendas e de suporte. Pode limitar ainda mais a quantidade de dados acessíveis a um gestor com profundidade. A profundidade é utilizada para limitar a profundidade dos níveis em que um gestor tem acesso apenas de leitura aos dados dos seus relatórios. Por exemplo, se a profundidade for definida como 2, o CEO pode ver os dados do Vice-Presidente de Vendas, Vice-Presidente de Serviço e gestores de vendas e de serviço. Contudo, o CEO não vê os dados de vendas nem os dados de suporte.

É importante que note que, se um subordinado direto tiver acesso de segurança mais profundo a uma tabela que o seu gestor, o gestor poderá não conseguir ver todos os registos a que o subordinado direto tem acesso. O exemplo seguinte ilustra este ponto.

• Uma unidade de negócio tem três utilizadores: Utilizador 1 , Utilizador 2 e Utilizador 3.

• O Utilizador 2 reporta diretamente ao Utilizador 1.

• O Utilizador 1 e o Utilizador 3 têm acesso de leitura ao nível do utilizador na tabela Conta. Este nível de acesso dá aos utilizadores acesso aos registos que estes possuem, aos registos que são partilhados com o utilizador e aos registos que são partilhados com a equipa da qual o utilizador é membro.

• O Utilizador 2 tem acesso de leitura à unidade de negócio na tabela de Contas. Este acesso permite que o Utilizador 2 veja todas as contas da unidade de negócio, incluindo todas as contas propriedade do Utilizador 1 e do Utilizador 3.

• O Utilizador 1, como gestor direto do Utilizador 2, tem acesso às contas possuídas ou partilhadas pelo Utilizador 2, incluindo as contas partilhadas ou possuídas por outras equipas do Utilizador 2. No entanto, o Utilizador 1 não tem acesso às contas do Utilizador 3, mesmo que o subordinado direto possa ter acesso às contas do Utilizador 3.

Hierarquia de posições

A hierarquia de posição não é baseada na estrutura de subordinação direta, como a hierarquia de gestores. Um utilizador não tem de ser um gestor real de outro utilizador para aceder aos dados de utilizador. Enquanto administrador, define vários cargos de tarefa na organização e ordena-as na hierarquia de cargos. Em seguida, adiciona utilizadores a um determinado cargo ou, como também dizemos, etiqueta um utilizador com um cargo específico. Um utilizador pode ser etiquetado apenas com uma posição numa dada hierarquia; no entanto, um cargo pode ser utilizado para vários utilizadores. Os utilizadores em posições mais altas na hierarquia têm acesso aos dados dos utilizadores em posições mais baixas, no caminho do antecessor direto. As posições superiores diretas têm acesso para Ler, Escrever, Anexar e Anexar a aos dados de posições inferiores no caminho do antecessor direto. As posições hierárquicas superiores não diretas têm acesso só de leitura aos dados das posições mais abaixo no caminho do antecessor direto.

Para ilustrar o conceito do caminho de predecessor direto, vejamos o diagrama que se segue. A posição de gestor de vendas tem acesso aos dados de vendas; no entanto, não tem acesso aos dados de suporte, que estão num caminho superior diferente. O mesmo se aplica ao cargo de gestor de serviço. Não tem acesso aos dados de vendas, que estão no caminho de vendas. Como na hierarquia de gestores, pode limitar a quantidade de dados acedidos pelos cargos mais altos ao utilizar profundidade. A profundidade limita o número de níveis até ao qual um cargo de nível superior tem acesso só de leitura aos dados de cargos de níveis inferiores no caminho ancestral direto. Por exemplo, se a profundidade for definida como 3, o cargo de CEO pode ver os dados desde os cargos de Vice-presidente de Vendas e Vice-presidente de Serviço até aos cargos de vendas e de suporte.

Configurar a segurança da hierarquia

Para configurar a segurança da hierarquia, certifique-se de que tem a permissão de Administrador de Sistema para atualizar a definição.

• Siga os passos indicados em Ver o seu perfil de utilizador.
• Não tem as permissões corretas? Contacte o administrador de sistema.

A segurança da hierarquia é desativada por predefinição. Para ativar a segurança da hierarquia, complete os passos que se seguem.

1. Inicie sessão no centro de administração Power Platform como administrador (administrador Dynamics 365 ou administrador Microsoft Power Platform).

2. No painel de navegação, selecione Gerenciar.

3. No painel Gerir, selecione Ambientes e, em seguida, selecione um ambiente da lista.

4. Vá para Configurações>Usuários + Segurança da hierarquia de permissões>.

5. Sob Modelo da Hierarquia, selecione Ativar o Modelo da Hierarquia de Gestores ou Ativar o Modelo da Hierarquia de Cargos, dependendo dos seus requisitos.

   Importante

   Para efetuar alterações em Hierarquia de segurança, tem de ter o privilégio de Alterar definições de segurança da hierarquia.

   Na área Gestão da Tabela de Hierarquia, todas as tabelas de sistema são ativadas para segurança de hierarquia por predefinição, mas pode excluir tabelas seletivas da hierarquia. Para excluir tabelas específicas do modelo da hierarquia, desmarque as caixas de verificação das tabelas que pretende excluir e guarde as alterações.

   

6. Configure a Profundidade para um valor pretendido para limitar o número de níveis de profundidade a que um gestor tem acesso só de leitura aos dados dos relatórios.

   Por exemplo, se a profundidade for igual a 2, um gestor só podem aceder às suas próprias contas e às contas de relatórios com profundidade de dois níveis. No nosso exemplo, se iniciar sessão nas aplicações de interação com os clientes como Vice-Presidente de Vendas não administrador, só verá as contas ativas dos utilizadores conforme mostrado:

   

   Nota

   A segurança da hierarquia concede ao Vice-Presidente de Vendas acesso aos registos no retângulo vermelho; um acesso adicional pode estar disponível com base na função de segurança que o Vice-Presidente de Vendas possui.

Configurar hierarquias de gestão e de posição

A hierarquia de gestores é criada facilmente utilizando a relação de gestores no registo de utilizador no sistema. Você utiliza o campo de pesquisa (ParentsystemuserID) para especificar o gestor do utilizador. Se criou a hierarquia de posição, pode também etiquetar o utilizador com um cargo específico na hierarquia de posição. No exemplo que se segue, o representante de vendas reporta ao gestor de vendas na hierarquia de gestores e também tem o cargo de vendas na hierarquia de cargos:

Para adicionar um utilizador específico numa hierarquia de cargos, utilize o campo de procura denominado Cargo no formulário de registo do utilizador.

Para alterar o cargo no formulário de registo do utilizador, na barra de navegação, escolha Mais (…) e escolha outro cargo.

Para criar uma hierarquia de cargos:

1. Selecione um ambiente e aceda a Definições>Utilizadores + Permissões>Posições.

   Para cada cargo, indicar o nome do cargo, o superior do cargo, e a descrição. Adicionar utilizadores a esta posição utilizando o campo de pesquisa Utilizadores nesta posição. A imagem seguinte é um exemplo da hierarquia de cargos com os cargos ativos.

   

   O exemplo de utilizadores ativados com as posições correspondentes é mostrado na imagem que se segue.

   

Editar e atualizar vários níveis de registros para subordinados diretos

Por padrão, os gerentes podem atualizar registros para seus subordinados diretos e registros para indivíduos que se reportam a seus subordinados diretos. Essencialmente, você pode atualizar registros com três níveis de profundidade. Você pode alterar a configuração padrão concluindo as etapas a seguir.

1. Instale a ferramenta OrganizationSettingsEditor.
2. Edite a definição HierarchyLevelForHierarchyFeature.
3. Insira o número de profundidade de nível direto. Por exemplo, digite 5.
4. Selecione Atualizar.

Incluir ou excluir registos pertencentes ao subordinado direto com um estado de utilizador desativado

Os gestores poderão ver os registos dos subordinados diretos com estado desativado em ambientes com a segurança hierárquica habilitada, após 31 de janeiro de 2024. Para outros ambientes, os registos de subordinados diretos com estado desativado não são incluídos na vista do gestor.

Para incluir registos de estados de inatividade de subordinados diretos:

1. Instale a ferramenta OrganizationSettingsEditor.
2. Atualize a definição AuthorizationEnableHSMForDisabledUsers para true.
3. Desative a Modelação de hierarquias.
4. Volte a ativar.

Para excluir registos de relatórios diretos com estado desativado:

1. Instale a ferramenta OrganizationSettingsEditor.
2. Atualize a definição AuthorizationEnableHSMForDisabledUsers para false.
3. Desative a Modelação de hierarquias.
4. Volte a ativar.

• Quando desativa e volta a ativar a modelação da hierarquia, a atualização poderá demorar algum tempo, uma vez que o sistema necessita de recalcular o acesso ao registo do gestor.
• Se vir um tempo limite, reduza o número de tabelas na lista Gestão de Tabelas de Hierarquia para incluir apenas tabelas que precisam de ser vistas pelo gestor. Se o timeout persistir, submeta um ticket de suporte para pedir assistência.
• Os registos de subordinados diretos com estado desativado são incluídos se esses registos forem partilhados com outro subordinado direto que esteja ativo. Pode excluir estes registos removendo a partilha.

Considerações de desempenho

Para aumentar o desempenho, recomendamos:

• Mantenha a segurança da hierarquia para 50 utilizadores ou menos sob a gestão de um gestor ou cargo específico. A sua hierarquia pode ter mais de 50 utilizadores sob um gestor ou posição, mas pode utilizar a definição Profundidade para reduzir o número de níveis com acesso apenas de leitura e, com isso, limitar o número efetivo de utilizadores sob um gestor ou posição a 50 utilizadores ou menos.

• Use modelos de segurança de hierarquia com outros modelos de segurança existentes para cenários mais complexos. Evite criar um grande número de unidades de negócios. Em vez disso, crie menos unidades de negócios e adicione segurança hierárquica.

• Mantenha o número HierarchyLevelForHierarchyFeature no seu nível mais baixo de profundidade direta, conforme exigido pelas suas necessidades empresariais para permitir aos gestores atualizar os registos dos seus relatórios diretos.

Veja também

segurança em Microsoft Dataverse
Consultar e visualizar dados hierárquicos