Descrição geral do controlo de acesso

  • Artigo

O controlo de acesso Data Explorer do Azure baseia-se na autenticação e autorização. Cada consulta e comando num recurso de Data Explorer do Azure, como um cluster ou uma base de dados, têm de transmitir verificações de autenticação e autorização.

  • Autenticação: valida a identidade do principal de segurança que faz um pedido
  • Autorização: Valida se o principal de segurança que faz um pedido é autorizado a fazer esse pedido no recurso de destino

Autenticação

Para autenticar programaticamente com o cluster, um cliente tem de comunicar com Microsoft Entra ID e pedir um token de acesso específico ao Azure Data Explorer. Em seguida, o cliente pode utilizar o token de acesso adquirido como prova de identidade ao emitir pedidos para o cluster.

Os principais cenários de autenticação são os seguintes:

  • Autenticação do utilizador: utilizada para verificar a identidade dos utilizadores humanos.
  • Autenticação da aplicação: utilizada para verificar a identidade de uma aplicação que precisa de aceder a recursos sem intervenção humana através de credenciais configuradas.
  • Autenticação em nome do (OBO): permite que uma aplicação troque um token para essa aplicação com um token para aceder a um serviço Kusto. Este fluxo tem de ser implementado com o MSAL.
  • Autenticação da aplicação de página única (SPA): permite que as aplicações Web SPA do lado do cliente iniciem sessão de utilizadores e obtenham tokens para aceder ao cluster. Este fluxo tem de ser implementado com o MSAL.

Nota

Para autenticação de utilizadores e aplicações, recomendamos que utilize as bibliotecas de cliente Kusto. Se precisar de autenticação Em nome do (OBO) ou da Aplicação Single-Page (SPA), terá de utilizar o MSAL diretamente, uma vez que estes fluxos não são suportados pelas bibliotecas de cliente. Para obter mais informações, veja Autenticar com a Biblioteca de Autenticação da Microsoft (MSAL).

Autenticação de utilizador

A autenticação do utilizador ocorre quando um utilizador apresenta credenciais para Microsoft Entra ID ou um fornecedor de identidade que federa com Microsoft Entra ID, como Serviços de Federação do Active Directory (AD FS). O utilizador obtém um token de segurança que pode ser apresentado ao serviço Data Explorer do Azure. O Azure Data Explorer determina se o token é válido, se o token é emitido por um emissor fidedigno e que afirmações de segurança o token contém.

O Azure Data Explorer suporta os seguintes métodos de autenticação de utilizador, incluindo através das bibliotecas de cliente Kusto:

  • Autenticação interativa do utilizador com início de sessão através da interface de utilizador.
  • Autenticação de utilizador com um token de Microsoft Entra emitido para o Azure Data Explorer.
  • Autenticação de utilizador com um token de Microsoft Entra emitido para outro recurso que pode ser trocado por um token de Data Explorer do Azure com a autenticação Em nome de (OBO).

Autenticação de aplicação

A autenticação da aplicação é necessária quando os pedidos não estão associados a um utilizador específico ou quando nenhum utilizador está disponível para fornecer credenciais. Neste caso, a aplicação autentica-se no Microsoft Entra ID ou no IdP federado ao apresentar informações secretas.

O Azure Data Explorer suporta os seguintes métodos de autenticação de aplicações, incluindo através das bibliotecas de cliente Kusto:

  • Autenticação de aplicações com uma identidade gerida do Azure.
  • Autenticação de aplicações com um certificado X.509v2 instalado localmente.
  • Autenticação de aplicações com um certificado X.509v2 atribuído à biblioteca de cliente como um fluxo de bytes.
  • Autenticação de aplicações com um ID de aplicação Microsoft Entra e uma chave de aplicação Microsoft Entra. O ID da aplicação e a chave da aplicação são como um nome de utilizador e palavra-passe.
  • Autenticação de aplicações com um token de Microsoft Entra válido obtido anteriormente, emitido para o Azure Data Explorer.
  • Autenticação de aplicações com um token de Microsoft Entra emitido para outro recurso que pode ser trocado por um token de Data Explorer do Azure com a autenticação Em nome de (OBO).

Autorização

Antes de realizar uma ação num recurso do Azure Data Explorer, todos os utilizadores autenticados têm de passar uma verificação de autorização. O Azure Data Explorer utiliza o modelo de controlo de acesso baseado em funções kusto, onde os principais são atribuídos a uma ou mais funções de segurança. A autorização é concedida desde que uma das funções atribuídas ao utilizador lhes permita executar a ação especificada. Por exemplo, a função Utilizador da Base de Dados concede aos principais de segurança o direito de ler os dados de uma base de dados específica, criar tabelas na base de dados e muito mais.

A associação de principais de segurança a funções de segurança pode ser definida individualmente ou através de grupos de segurança definidos no Microsoft Entra ID. Para obter mais informações sobre como atribuir funções de segurança, veja Descrição geral das funções de segurança.

Autorização de grupo

A autorização pode ser concedida a grupos de Microsoft Entra ID ao atribuir uma ou mais funções ao grupo.

Quando a autorização de um utilizador ou principal de aplicação é verificada, o sistema verifica primeiro se existe uma atribuição de função explícita que permita a ação específica. Se não existir essa atribuição de função, o sistema analisará a associação do principal em todos os grupos que possam potencialmente autorizar a ação. Se o principal for confirmado como membro de qualquer um destes grupos, a ação pedida é autorizada. Caso contrário, se o principal não for membro de tais grupos, a ação não passa na verificação de autorização e a ação não é permitida.

Nota

A verificação das associações a grupos pode ser intensiva em termos de recursos. Uma vez que as associações a grupos não mudam frequentemente, os resultados das verificações de associação são colocados em cache. A duração da colocação em cache varia e é influenciada por fatores como o resultado da associação (quer o principal seja membro ou não), o tipo de principal (utilizador ou aplicação), entre outros. A duração máxima da colocação em cache pode estender-se até três horas, enquanto a duração mínima é de 30 minutos.

Conteúdo relacionado