Share via

Serviço de direitos

  • Artigo

O gerenciamento de acesso é uma função crítica para qualquer serviço ou recurso. O serviço de direitos permite controlar quem pode usar sua instância do Gerenciador de Dados do Azure para Energia, o que eles podem ver ou alterar e quais serviços ou dados podem ser usados.

Estrutura e nomenclatura de grupos do OSDU

O serviço de direitos do Gerenciador de Dados do Azure para Energia permite que você crie grupos e gerencie associações dos grupos. Um grupo de direitos define permissões em serviços ou fontes de dados para uma partição de dados específica na sua instância do Gerenciador de Dados do Azure para Energia. Os usuários adicionados a um grupo específico obtêm as permissões associadas. Todos os identificadores de grupo (emails) são do formulário {groupType}.{serviceName|resourceName}.{permission}@{partition}.{domain}.

Diferentes grupos e direitos de usuário associados devem ser definidos para cada nova partição de dados, mesmo na mesma instância do Gerenciador de Dados do Azure para Energia.

Tipos de grupos do OSDU

O serviço de autorização permite três casos de uso para autorização:

Grupos de dados

  • Os grupos de dados são usados para habilitar a autorização de dados.
  • Os grupos de dados começam com a palavra "dados", como data.welldb.viewers e data.welldb.owners.
  • Os usuários individuais são adicionados aos grupos de dados, que são adicionados na ACL de registros de dados individuais para habilitar o acesso do viewer e owner dos dados após eles serem carregados no sistema.
  • Para upload os dados, você precisa ter direitos de vários serviços do OSDU, que são usados durante o processo de ingestão. A combinação de serviços do OSDU depende do método de ingestão. Por exemplo, para ingestão de manifesto, confira Conceitos de ingestão baseados em manifesto para compreender os serviços do OSDU usados pelas APIs. O usuário não precisa fazer parte da ACL para carregar os dados.

Grupos de serviços

  • Os grupos de serviços são usados para habilitar a autorização para serviços.
  • Os grupos de serviço começam com a palavra "serviço", como service.storage.user e service.storage.admin.
  • Os grupos de serviços são predefinidos quando os serviços do OSDU são provisionados em cada partição de dados da instância do Gerenciador de Dados do Azure para Energia.
  • Esses grupos habilitam o acesso do viewer, editor e admin para chamar as APIs do OSDU correspondentes aos serviços do OSDU.

Grupos de usuários

  • Os grupos de usuários são usados para agrupamento hierárquico de grupos de usuários e serviços.
  • Os grupos de serviços começam com a palavra "usuários", como users.datalake.viewers e users.datalake.editors.

Hierarquia aninhada

  • Se user_1 fizer parte de um data_group_1 e data_group_1 for adicionado como membro ao user_group_1, o código do OSDU verificará a associação aninhada e autorizará user_1 a acessar os direitos de user_group_1. Isso é explicado na API de Verificação de Direitos do OSDU e na API de Recuperação de Grupo do OSDU.

  • Você pode adicionar usuários individuais a um user group. O user group é adicionado a um data group. O grupo de dados é adicionado à ACL do registro de dados. Ele habilita a abstração para os grupos de dados porque os usuários individuais não precisam ser adicionados um por um ao grupo de dados. Em vez disso, você pode adicionar usuários ao user group. Em seguida, você pode usar o user group repetidamente para vários data groups. A estrutura aninhada ajuda a fornecer escalabilidade para gerenciar associações no OSDU.

Grupos padrão

  • Alguns grupos do OSDU são criados por padrão quando uma partição de dados é provisionada.
  • Os grupos de dados de data.default.viewers e data.default.owners são criados por padrão.
  • Os grupos de serviços para exibir, editar e administrar cada serviço, como service.entitlement.admin e service.legal.editor são criados por padrão.
  • Os grupos de usuários de users, users.datalake.viewers, users.datalake.editors, users.datalake.admins, users.datalake.ops e users.data.root são criados por padrão.
  • O gráfico de grupos e membros padrão em grupos de direitos do OSDU inicializados mostra os grupos de cabeçalhos de coluna como membros do cabeçalhos de linha. Por exemplo, o grupo users é membro de data.default.viewers e data.default.owners por padrão. users.datalake.admins e users.datalake.ops são membros do grupo service.entitlement.admin.
  • A entidade de serviço ou o client-id ou o app-id é o proprietário padrão de todos os grupos.

Peculiaridade do grupo users@

  • Há uma exceção a esta regra de nomenclatura de grupo para o grupo “usuários”. Ele é criado quando uma nova partição de dados é provisionada e seu nome segue o padrão users@{partition}.{domain}.
  • Ele tem a lista de todos os usuários com qualquer tipo de acesso em uma partição de dados específica. Antes de adicionar um novo usuário a qualquer grupo de direitos, você também precisará adicionar o novo usuário ao grupo users@{partition}.{domain}.

Peculiaridade do grupo users.data.root@

  • O grupo de direitos users.data.root é o membro padrão de todos os grupos de dados quando os grupos são criados. Se você tentar remover users.data.root de qualquer grupo de dados, receberá um erro, pois essa associação é imposta pelo OSDU.
  • users.data.root torna-se automaticamente o proprietário padrão e permanente de todos os registros de dados quando os registros são criados no sistema, conforme explicado na API de validação de acesso do proprietário do OSDU e na API de verificação de raiz de dados de usuários do OSDU. Como resultado, independentemente da associação do usuário ao OSDU, o sistema verifica se o usuário é "DataManager", ou seja, parte do grupo data.root, para conceder acesso ao registro de dados.
  • A associação padrão em users.data.root é somente o app-id usado para configurar a instância. Você pode adicionar outros usuários explicitamente a esse grupo para dar a eles acesso padrão aos registros de dados.

Como exemplo no cenário,

  • Um data_record_1 tem 2 ACLs: ACL_1 e ACL_2.
  • User_1 é membro do ACL_1 e users.data.root.

Agora, se você remover o user_1 do ACL_1, o user_1 ainda terá acesso ao data_record_1 por meio do grupo users.data.root.

E se ACL_1 e ACL_2 forem removidos do data_record_1, users.data.root continuarão a ter acesso de proprietário dos dados. Isso evita que o registro de dados se torne órfão.

OID desconhecida

Você verá uma OID desconhecida em todos os grupos de OSDU adicionados por padrão, essa OID refere-se a uma ID de instância interna do Gerenciador de Dados do Azure para Energia usada na comunicação do sistema com o sistema. Essa OID é criada exclusivamente para cada instância.

Usuários

Para cada grupo do OSDU, você pode adicionar um usuário como PROPRIETÁRIO ou MEMBRO:

  • Se você for PROPRIETÁRIO de um grupo do OSDU, poderá adicionar ou remover os membros desse grupo ou excluir o grupo.
  • Se você for MEMBRO de um grupo do OSDU, poderá exibir, editar ou excluir o serviço ou os dados dependendo do escopo do grupo do OSDU. Por exemplo, se você for MEMBRO do grupo OSDU service.legal.editor, poderá chamar as APIs para alterar o serviço jurídico.

Observação

Não exclua o PROPRIETÁRIO de um grupo, a menos que haja outro PROPRIETÁRIO para gerenciar os usuários.

APIs de direito

Para obter uma lista completa de pontos de extremidade da API de Direitos, confira Serviço de direitos do OSDU. Algumas ilustrações de como usar as APIs de Direitos estão disponíveis em Gerenciar usuários.

Observação

A documentação do OSDU refere-se aos pontos de extremidade v1, mas os scripts observados nesta documentação referem-se aos pontos de extremidade v2, que funcionam e foram validados com sucesso.

OSDU® é uma marca registrada do The Open Group.

Próximas etapas

Para a próxima etapa, confira:

Também pode ingerir dados na sua instância do Gerenciador de Dados do Azure para Energia: