Vue d’ensemble du contrôle d’accès

S’applique à : ✅Microsoft Fabric✅Azure Data Explorer

Le contrôle d’accès est basé sur l’authentification et l’autorisation. Chaque requête et commande sur une ressource Fabric, telle qu’une base de données, doit passer les vérifications d’authentification et d’autorisation.

• Authentification: valide l’identité du principal de sécurité effectuant une demande
• d’autorisation : valide le principal de sécurité effectuant une demande est autorisé à effectuer cette demande sur la ressource cible

Authentification

Pour s’authentifier par programmation, un client doit communiquer avec 'ID Microsoft Entra et demander un jeton d’accès spécifique au service Kusto. Ensuite, le client peut utiliser le jeton d’accès acquis comme preuve d’identité lors de l’émission de demandes à votre base de données.

Les principaux scénarios d’authentification sont les suivants :

• l’authentification utilisateur: utilisée pour vérifier l’identité des utilisateurs humains.
• l’authentification d’application: utilisée pour vérifier l’identité d’une application qui doit accéder aux ressources sans intervention humaine à l’aide des informations d’identification configurées.
• l’authentification au nom de (OBO): permet à une application d’échanger un jeton pour cette application avec un jeton pour accéder à un service Kusto. Ce flux doit être implémenté avec MSAL.
• 'authentification par application monopage (SPA): permet aux applications web SPA côté client de connecter des utilisateurs et d’obtenir des jetons pour accéder à votre base de données. Ce flux doit être implémenté avec MSAL.

Note

Pour l’authentification des utilisateurs et des applications, nous vous recommandons d’utiliser les bibliothèques clientes kusto . Si vous avez besoin de l’authentification OBO (On-behalf-of) ou Single-Page Application (SPA), vous devez utiliser MSAL directement car les bibliothèques clientes ne prennent pas en charge ces flux. Pour plus d’informations, consultez s’authentifier auprès de la bibliothèque d’authentification Microsoft (MSAL).

Authentification de l’utilisateur

L’authentification utilisateur se produit lorsqu’un utilisateur présente des informations d’identification à l’ID Microsoft Entra ou à un fournisseur d’identité qui fédère avec l’ID Microsoft Entra, tel que les services de fédération Active Directory. L’utilisateur récupère un jeton de sécurité qui peut être présenté au service Azure Data Explorer. Azure Data Explorer détermine si le jeton est valide, si le jeton est émis par un émetteur approuvé et quelles revendications de sécurité le jeton contient.

Authentification d’application

L’authentification d’application est nécessaire lorsque les demandes ne sont pas associées à un utilisateur spécifique ou lorsqu’aucun utilisateur n’est disponible pour fournir des informations d’identification. Dans ce cas, l’application s’authentifie auprès de Microsoft Entra ID ou du fournisseur d’identité fédéré en présentant des informations secrètes.

Autorisation

Avant d’effectuer une action sur une ressource, tous les utilisateurs authentifiés doivent passer une vérification d’autorisation. Le contrôle d’accès en fonction du rôle Kusto modèle est utilisé, où les principaux sont attribués à un ou plusieurs rôles de sécurité. L’autorisation est accordée tant que l’un des rôles attribués à l’utilisateur leur permet d’effectuer l’action spécifiée. Par exemple, le rôle Utilisateur de base de données accorde aux principaux de sécurité le droit de lire les données d’une base de données particulière, de créer des tables dans la base de données, etc.

L’association de principaux de sécurité aux rôles de sécurité peut être définie individuellement ou à l’aide de groupes de sécurité définis dans l’ID Microsoft Entra. Pour plus d’informations sur l’attribution de rôles de sécurité, consultez vue d’ensemble des rôles de sécurité.

Autorisation de groupe

L’autorisation peut être accordée aux groupes d’ID Microsoft Entra en affectant un ou plusieurs rôles au groupe.

Lors de la vérification de l’autorisation d’un utilisateur ou d’un principal d’application, le système recherche d’abord une attribution de rôle explicite qui autorise l’action spécifique. Si l’attribution de rôle n’existe pas, le système vérifie l’appartenance du principal dans tous les groupes qui peuvent autoriser l’action.

Si le principal est membre d’un groupe disposant d’autorisations appropriées, l’action demandée est autorisée. Sinon, l’action ne transmet pas la vérification d’autorisation et n’est pas autorisée.

Note

La vérification des appartenances aux groupes peut être gourmande en ressources. Étant donné que les appartenances aux groupes ne changent pas fréquemment, les résultats de la vérification des appartenances sont mis en cache. La durée de mise en cache varie et détermine la rapidité des modifications apportées aux appartenances aux groupes. L’ajout d’un utilisateur à un groupe peut prendre jusqu’à 30 minutes. La suppression d’un utilisateur d’un groupe peut prendre jusqu’à trois heures.

Forcer l’actualisation de l’appartenance au groupe

Les principaux peuvent forcer une actualisation des informations d’appartenance au groupe. Cette fonctionnalité est utile dans les scénarios où les services d’accès privilégié juste-à-temps (JIT), tels que Microsoft Entra Privileged Identity Management (PIM), sont utilisés pour obtenir des privilèges plus élevés sur une ressource.

Actualiser pour un groupe spécifique

Les principaux peuvent forcer une actualisation de l’appartenance au groupe pour un groupe spécifique. Toutefois, les restrictions suivantes s’appliquent :

• Une actualisation peut être demandée jusqu’à 10 fois par heure par principal.
• Le principal demandeur doit être membre du groupe au moment de la demande.

La requête génère une erreur si l’une de ces conditions n’est pas remplie.

Pour réévaluer l’appartenance du principal actuel à un groupe, exécutez la commande suivante :

.clear cluster cache groupmembership with (group='<GroupFQN>')

Utilisez le nom complet du groupe (FQN). Pour plus d’informations, consultez Référencement des principaux et groupes Microsoft Entra.

Actualiser pour d’autres principaux

Un principal privilégié peut demander une d’actualisation pour d’autres principaux. Le principal demandeur doit avoir 'accès AllDatabaseMonitor pour le service cible. Les principaux privilégiés peuvent également exécuter la commande précédente sans restrictions.

Pour actualiser l’appartenance au groupe d’un autre principal, exécutez la commande suivante :

Dans la commande suivante, remplacez <PrincipalFQN> par votre propre nom complet principal (FQN) et <GroupFQN> par votre propre nom de domaine complet de groupe. Pour plus d’informations, consultez Référencement des principaux et groupes Microsoft Entra.

.clear cluster cache groupmembership with (principal='<PrincipalFQN>', group='<GroupFQN>')

Contenu connexe

• Comprendre contrôle d’accès en fonction du rôle Kusto.
• Pour l’authentification utilisateur ou application, utilisez les bibliothèques clientes Kusto .
• Pour l’authentification OBO ou SPA, consultez Comment s’authentifier auprès de la bibliothèque d’authentification Microsoft (MSAL).
• Pour référencer des principaux et des groupes, consultez Référencement des principaux et groupes Microsoft Entra.