Partilhar via


Como as permissões são determinadas (Master Data Services)

Aplica-se a:SQL Server no Windows Azure SQL Managed Instance

Importante

Os Serviços de Dados Mestres (MDS) foram removidos no SQL Server 2025 (17.x). Continuamos a oferecer suporte ao MDS no SQL Server 2022 (16.x) e em versões anteriores.

No Master Data Services, a maneira mais simples de configurar a segurança é atribuir permissões de objeto de modelo a um grupo do qual o usuário é membro.

A segurança torna-se mais complexa quando:

  • As permissões para objetos de modelo e elementos da hierarquia são atribuídas.

  • O usuário pertence a grupos e a permissão é atribuída ao usuário e aos grupos.

  • O usuário pertence a grupos e a permissão é atribuída a vários grupos.

Permissões atribuídas a um único grupo ou usuário

Se você atribuir permissões a um único grupo ou usuário, as permissões serão determinadas com base no fluxo de trabalho a seguir.

mds_conc_security_no_overlap

Etapa 1: As permissões de atributo efetivas são determinadas.

A lista a seguir descreve como as permissões de atributo efetivas são determinadas:

  • As permissões atribuídas a objetos de modelo determinam quais atributos um usuário pode acessar.

  • Todos os objetos de modelo herdam automaticamente a permissão do objeto mais próximo em um nível mais alto na estrutura do modelo.

  • Todos os objetos no mesmo nível da entidade são implicitamente negados.

  • Todos os objetos em um nível mais alto recebem Leitura Inferida. Para obter mais informações sobre leitura inferida, consulte Acesso à navegação (Master Data Services).

Neste exemplo, a permissão de leitura é atribuída a uma entidade e essa permissão é herdada por seu atributo, que está em um nível inferior na estrutura do modelo. O modelo fornece leitura inferida a esta entidade e o seu atributo. A outra entidade no modelo não tem permissão explícita atribuída e não herda nenhuma permissão, por isso é implicitamente negada.

mds_conc_inheritance_model

Etapa 2: Se as permissões dos membros da hierarquia forem atribuídas, as permissões efetivas dos membros serão determinadas.

A lista a seguir descreve como as permissões efetivas de membro da hierarquia são determinadas:

  • As permissões atribuídas aos nós de hierarquia determinam quais membros um usuário pode acessar.

  • Todos os nós em uma hierarquia herdam automaticamente a permissão do objeto mais próximo em um nível mais alto na estrutura hierárquica.

  • Todos os nós no mesmo nível são implicitamente negados.

  • Quaisquer nós em níveis superiores que não têm permissões atribuídas negar-se-ão automaticamente.

Neste exemplo, a permissão de Leitura é atribuída a um nó da hierarquia e essa permissão é herdada por um nó em um nível inferior na estrutura hierárquica. A raiz não tem permissão atribuída, por isso é implicitamente negada. O outro nó na estrutura hierárquica não tem permissão explícita atribuída e não herda nenhuma permissão, por isso é implicitamente negado.

mds_conc_inheritance_hierarchy

Etapa 3: A interseção de permissões de atributo e membro é determinada.

Se as permissões de atributo efetivo forem diferentes das permissões de membro efetivo, as permissões deverão ser determinadas para cada valor de atributo individual. Para obter mais informações, consulte Permissões Sobrepostas de Modelo e Membro (Master Data Services).

Permissões atribuídas a vários grupos

Se um usuário pertencer a um ou mais grupos e as permissões forem atribuídas ao usuário e aos grupos, o fluxo de trabalho se tornará mais complexo.

mds_conc_security_group_overlap

Nesse caso, as permissões de usuário e grupo sobrepostas devem ser resolvidas antes que as permissões de objeto de modelo e membro da hierarquia possam ser comparadas. Para obter mais informações, consulte Sobreposição de permissões de usuário e grupo (Master Data Services).

Ver também

Permissões de usuário e grupo sobrepostas (Master Data Services)
Permissões sobrepostas de modelo e membro (Master Data Services)