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 o acesso aos registos granulado mais de uma organização e ajuda-o a sugestão os custos de manutenção.
Por exemplo, em cenários complexas, pode começar com a criação das unidades de negócio e adicionar a segurança da hierarquia. 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 hierarquia de cargos
Dois modelos de segurança podem ser utilizados para hierarquias de gestores e a hierarquia de cargos. Com a hierarquia de gestor, um gestor de estar na mesma unidade de negócio que o relatório, ou a 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.
Nota
Quando o modelo de segurança da hierarquia fornecer um determinado nível de acesso a dados, gerir acesso pode ser obtido a outros formulários de segurança, tal como o direito de acesso.
Hierarquia de gestores
O modelo de segurança da hierarquia de gestores é baseado na cadeia de gestão ou na estrutura direta de reporte, no gestor de relação e os relatórios estão estabelecidas utilizando o campo Gestor na tabela de utilizador de 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.
Nota
Com o modelo de segurança da hierarquia de gestores, um gestor tem acesso aos registos propriedade do utilizador ou equipa por um utilizador que seja membro de, e os registos que foram partilhados diretamente ao utilizador ou equipa um utilizador que seja membro de. Quando um registo é partilhado por um utilizador que está fora da cadeia de gestão para um utilizador de relatório direto com acesso só de leitura, o gestor do relatório direto só tem acesso só de leitura ao registo partilhado.
Quando ativou a opção Registar a propriedade entre unidades de negócio, os gestores podem ter relatórios diretos de diferentes unidades de negócio. Pode utilizar as seguintes definições de base de dados de ambiente para remover a restrição da unidade de negócio.
ManagersMustBeInSameOrParentBusinessUnitAsReports
predefinição = verdadeiro
Pode defini-lo como falso, e a unidade de negócio do gestor não precisa de ser igual à unidade de negócio do relatório direto.
Além do modelo de segurança da hierarquia de gestores, um gestor tem de ter pelo menos o nível de utilizador ler o privilégio sobre uma tabela para ver os dados dos relatórios. Por exemplo, se um gestor não tem acesso de Leitura à tabela Caso, o gestor não consegue ver os casos a que os relatórios têm acesso.
Para um subordinado não direto na mesma cadeia de gestão do gestor, um gestor tem o acesso só de leitura aos dados do subordinado não direto. 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 o Vice-Presidente de Vendas e dados do Vice-Presidente de dados 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 acedidos por um gestor com profundidade. A profundidade é utilizada para limitar o número de níveis profundamente um gestor tem acesso de leitura aos dados dos 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 veja 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 de nível do utilizador sobre a tabela Conta. Este nível de acesso dá aos utilizadors acesso aos registos que estes possuem, aos registos partilhados com o utilizador e registos objetos partilhados com a equipa de que o utilizador é membro.
O Utilizador 2 tem acesso de leitura à unidade de negócio sobre a tabela Conta. 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, adicionar utilizadores a um cargo determinado ou, como também dizemos, etiquetar um utilizador com um cargo específico. Pode ser um utilizador com apenas com uma posição numa hierarquia, determinada entanto, um cargo pode ser utilizada para vários utilizadores. Os utilizadores em posições mais altas na hierarquia tenham acesso aos dados dos utilizadores em posições mais base, o caminho do predecessor direto. As altas posições mais simples tenham acesso para Ler, Escrever, Anexar e AnexarA aos dados de posições mais baixas no caminho do predecessor direto. As posições mais elevadas não diretas têm acesso só de leitura aos dados das posições mais abaixo no caminho do predecessor direto.
Para ilustrar o conceito do caminho de predecessor direto, vejamos o diagrama que se segue. O cargo de gestor de vendas tem acesso a dados de vendas, no entanto, não tem acesso a dados de suporte, que estão no caminho do predecessor 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 por uma cargos mais altos com profundidade. A profundidade limita o número de níveis de profundidade a que um cargo mais alto tem acesso só de leitura, aos dados de cargos mais baixos no caminho do predecessor direto. Por exemplo, se a profundidade for definida como 3, o cargo de CEO pode ver os dados até aos cargos de Vice-Presidente de Vendas e de Vice-Presidente de Serviço, para os cargos de vendas e de suporte.
Nota
Com a segurança da hierarquia de cargos, um utilizador num cargo mais elevado tem acesso aos registos detidos por um utilizador de cargo mais baixo ou pela equipa a que o utilizador pertence e aos registos indiretamente partilhados com o utilizador ou a equipa de que este seja membro.
Além do modelo de segurança da hierarquia de cargos, os utilizadores num nível superior têm de ter, pelo menos, o privilégio de leitura ao nível do utilizador numa tabela para ver os registos a que os cargos mais baixos têm acesso. Por exemplo, se um utilizador num nível mais elevado não tiver acesso de leitura à tabela Caso, esse utilizador não poderá ver os casos aos quais os utilizadores em cargos mais baixos têm acesso.
Configurar segurança de 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 é desativado por predefinição. Para ativar a segurança da hierarquia, complete os passos que se seguem.
Selecione um ambiente e aceda a Definições>Utilizadores + Permissões>Segurança da hierarquia.
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.
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
Quando, a segurança da hierarquia conceder acesso do Vice-Presidente de Vendas aos registos em retângulo vermelho, acesso adicional pode estar disponível com base no direito de acesso que o Vice-Presidente de Vendas tem.
Por predefinição, a secção Gestão da Tabela da Hierarquia, todas as tabelas de sistema estão ativadas para a segurança da hierarquia. Para excluir uma tabela específica do modelo da hierarquia, desmarque a marca de verificação junto do nome da tabela e guarde as alterações.
Importante
- Esta é uma funcionalidade de pré-visualização.
- As caraterísticas de pré-visualização não se destinam à produção e poderão ter caraterísticas restritas. Estas caraterísticas estão disponíveis antes do lançamento oficial, para que os clientes possam ter acesso antecipado e enviar comentários.
Configurar hierarquias de gestor e posição
A hierarquia de gestores é criada facilmente utilizando a relação de gestores no registo de utilizador no sistema. Utilizar o campo de pesquisa de data (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.
Importante
Para adicionar um utilizador numa posição ou alterar a cargo do utilizador, tem de ter o privilégio de Atribuir a cargo de um 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:
Selecione um ambiente e aceda a Definições>Utilizadores + Permissões>Posições.
Para cada cargo, indicar um cargo, nome do principal de posição, e descrição. Adicionar utilizadores a esta cargo utilizando o campo de pesquisa Utilizadores nesta cargodenomina-se. 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.
Incluir ou excluir registos pertencentes ao subordinado direto com o estado de utilizador desativado
Os gestores podem ver os registos do subordinado direto do estado desativado para ambientes em que a segurança da hierarquia está ativa após 31 de janeiro de 2024. Para outros ambientes, os registos do subordinado direto do estado desativado não são incluídos na vista do gestor.
Para incluir registos do subordinado direto do estado desativado:
- Instale a ferramenta OrganizationSettingsEditor.
- Atualize a definição AuthorizationEnableHSMForDisabledUsers como verdadeira.
- Desative a Modelação de hierarquias.
- Volte a ativar.
Para excluir registos do subordinado direto do estado desativado:
- Instale a ferramenta OrganizationSettingsEditor.
- Atualize a definição AuthorizationEnableHSMForDisabledUsers como falsa.
- Desative a Modelação de hierarquias.
- Volte a ativar.
Nota
- 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 tempo limite persistir, envie um pedido de suporte para pedir assistência.
- Os registos do subordinado direto do estado desativado são incluídos se estes 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 de 50 utilizadores ou menos sob um gestor ou cargo. A hierarquia pode ter mais de 50 utilizadores para um gestor ou posição, mas pode utilizar a definição Profundidade para reduzir o número de níveis de acesso só de leitura e o número de utilizadores para um gestor ou posição de 50 utilizadores ou menos.
Utilize modelos de segurança da hierarquia com outros modelos de segurança existentes para cenários mais complexos. Evite criar uma grande quantidade de unidades de negócio, em vez deste, criar menos unidades de negócio e adicionar a segurança da hierarquia.
Consulte também
Segurança no Microsoft Dataverse
Consultar e visualizar dados hierárquicos