Configurar a segurança hierárquica para o acesso granular aos dados
Nota
Se tiver ativado o modo Interface Unificada apenas, antes de utilizar os procedimentos apresentados neste artigo, faça o seguinte:
- Selecione Definições (
) na barra de navegação. - Selecione Definições Avançadas.
O modelo de segurança da hierarquia é uma extensão os modelos de segurança existentes de Dynamics 365 Customer Engagement (on-premises) que utilize unidades de negócio, direitos de acesso, partilhar, e equipas. Pode ser utilizado em conjunção 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. Isto conseguirá o acesso aos dados mais granulado com menos distante custos de manutenção que um grande número de unidades de negócio pode fazer.
Modelos de segurança de hierarquia de gestores e hierarquia de posições
Dois modelos de segurança podem ser utilizados para hierarquias, a hierarquia do e a hierarquia de posição. 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 de relatório. A hierarquia de posição permite o acesso aos dados através das unidades de negócio. Se for financeiras de uma organização, poderá preferir o modelo da hierarquia de gestor, impedir aos dados dos gestores de acesso fora das unidades de negócio. Contudo, se for uma parte de uma organização de suporte ao cliente e pretender os gestores aceder às caixas de serviço 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 do gestor é baseada nas de gestão ou a estrutura direta do relatório, no gestor de relação e os relatórios estão estabelecidas utilizando o campo do na entidade utilizador de sistema. Com este modelo de segurança, os gestores podem aceder aos dados que os relatórios têm acesso. Pode executar o trabalho em nome da sua relatórios ou informações direta de acesso que necessita aprovação.
Nota
Com o modelo de segurança da hierarquia de gestor, 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.
Além do modelo de segurança da hierarquia de gestor, um gestor tem de ter pelo menos o nível de utilizador ler o privilégio sobre uma entidade, ver os dados dos relatórios. Por exemplo, se um gestor não tem acesso de leitura à entidade incidente, o gestor não conseguirá ver os incidentes que os relatórios têm acesso.
Para um relatório não direto na mesma cadeia de gestão do gestor, um gestor tem o acesso só de leitura aos dados do relatório não direto. Para um relatório direto, o gestor tem acesso Ler, Escrever, Acrescentar, AcrescentarA aos dados do relatório. Para ilustrar o modelo de segurança da hierarquia de gestor, vamos ver o diagrama em. 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 dados do gestor de Vendas e dados do gestor de serviço, bem como os dados de Vendas e do suporte. Pode mais limitar 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 é definido como 2, o CEO pode ver os dados do Vice-Presidente de Vendas, Vice-Presidente de serviço e gestores de Vendas e serviço. Contudo, o CEO não veja os dados de Vendas ou de suporte os dados.
É importante que note que, se um relatório direto tiver acesso de segurança mais profundo para uma entidade que o seu gestor, o gestor poderá não conseguir ver todos os registos a que o relatório 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 de utilizador sobre a entidade 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 de Unidade de Negócio sobre a entidade Conta. Isto 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 com o Utilizador 2 e a quaisquer contas partilhadas ou possuídas por uma equipa de que o Utilizador 2 seja membro. No entanto, o Utilizador 1 não tem acesso às contas do Utilizador 3, mesmo que o seu reporte direto possa ter acesso às contas do Utilizador 3.
Hierarquia de posições
A hierarquia de posição não é baseada na estrutura direta de relatório, tais como a hierarquia de gestor. Um utilizador não tem de ser um gestor real de outro utilizador para aceder aos dados de utilizador. Enquanto administrador, é mais posições definirá de tarefa a organização e arranjá-las-á na hierarquia de posição. Em seguida, adicionar utilizadores a um cargo determinada como, ou, também vamos dizemos “,” atribua 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, escreveram, leiam, atualizaram adicionaram de acesso, acrescentar a nos dados de posições mais base 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 de caminho do predecessor direto, vamos ver o diagrama em. Posição do gestor de Vendas tem acesso a dados de Vendas, entanto, não tem acesso a dados de suporte, no caminho do predecessor diferente. O mesmo se aplica a cargo do gestor de serviço. Não tem acesso a dados de Vendas, no caminho de Vendas. Como na hierarquia de gestor, pode limitar a quantidade de dados acedidos por uma posições mais altas com “profundidade”. A profundidade limitará o número de níveis profundamente um cargo mais alta tenham um acesso só de leitura, os dados de posições mais base no caminho do predecessor direto. Por exemplo, se a profundidade é definido como 3, posição de CEO pode ver os dados qualquer forma de base do Vice-Presidente de Vendas e de Vice-Presidente de posições de serviço, a posições de Vendas e do suporte.
Nota
Com a segurança da hierarquia de posições, um utilizador numa posição mais elevada tem acesso aos registos possuídos por um utilizador de posição mais baixa 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 posição, os utilizadores do têm de nível superior fazer com pelo menos o nível de utilizador ler o privilégio sobre uma entidade ver os registos que os utilizadores na base posições mais tenham acesso. Por exemplo, se um utilizador num nível mais elevado não tiver acesso de leitura à entidade Incidente, esse utilizador não poderá ver os incidentes aos quais os utilizadores em posições mais baixas têm acesso.
Configurar segurança de hierarquia
Para configurar a segurança de hierarquia, tem de ter um direito de acesso de Administrador.
A segurança da hierarquia é desativado por predefinição. Para ativar:
Aceda a Definições>Segurança.
Escolha Hierarquia de segurança e selecione Ativar Modelação de Hierarquias.
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.
Depois de ativada a modelação de hierarquia, selecione o modelo específico Hierarquia do gestor seleccionar ou Hierarquia personalizada de posição. Todas as entidades de sistema são ativados para o entanto para fora caixa de segurança da hierarquia, mas, pode excluir seletivas entidades da hierarquia. Apresentação de Hierarquia de segurança mostrado abaixo:
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 Customer Engagement não como Administrador, que consegue ver todas as contas, mas como Vice-Presidente de Vendas, só poderá ver as contas ativas dos utilizadores mostrados no retângulo vermelho, tal como ilustrado abaixo:
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.
Configurar hierarquias de gestor e posição
A hierarquia do gestor é criada utilizar facilmente a relação do registo de utilizador no sistema. Utilizar o campo de pesquisa de data (ParentsystemuserID) para especificar o gestor do utilizador. Se já criou a hierarquia de posição, pode também etiquetar o utilizador com um cargo específico na hierarquia de posição. O seguinte exemplo, ao representante de vendas é o diretor de vendas na hierarquia do e também tem a cargo de Vendas na hierarquia de posição:
Para adicionar um utilizador específico numa posição na hierarquia de posição, utilizar o campo de denomina-se De pesquisa no formulário de registo de utilizador, como apresentado em:
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 a posição no formulário de registo do utilizador, na barra de nav, escolha Mais (…) e escolha uma posição diferente, conforme mostrado abaixo:
Para criar uma hierarquia de Posições:
Aceda a Definições>Segurança.
Escolha 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. Segue-se a instância da hierarquia de posição com as posições ativas.
O exemplo de utilizadores ativados com as posições correspondentes é mostrado abaixo:
Considerações de desempenho
Para aumentar o desempenho, recomendamos:
Mantenha a segurança da hierarquia de 50 utilizadores ou menor numa data/cargo. A hierarquia pode ter mais de 50 utilizadores numa data/cargo, mas pode utilizar a definição da profundidade para reduzir o número de níveis de acesso só de leitura a este limite e o número de utilizadores de um gestor no/de 50 utilizadores ou menos.
Utilize modelos de segurança da hierarquia em conjunção com outros modelos de segurança existentes para vários cenários mais complexas. 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
Conceitos de segurança para o Microsoft Dynamics 365 for Customer Engagement
Consultar e visualizar dados hierárquicos