Overzicht van toegangsbeheer

Toegangsbeheer voor Azure Data Explorer is gebaseerd op verificatie en autorisatie. Elke query en opdracht voor een Azure Data Explorer-resource, zoals een cluster of database, moet zowel verificatie- als autorisatiecontroles doorstaan.

• Verificatie: Controleert de identiteit van de beveiligingsprincipal die een aanvraag indient
• Autorisatie: valideert de beveiligingsprincipal die een aanvraag indient, die aanvraag mag doen op de doelresource

Verificatie

Als u programmatisch wilt verifiëren met uw cluster, moet een client communiceren met Microsoft Entra ID en een toegangstoken aanvragen dat specifiek is voor Azure Data Explorer. Vervolgens kan de client het verkregen toegangstoken gebruiken als bewijs van identiteit bij het uitgeven van aanvragen aan uw cluster.

De belangrijkste verificatiescenario's zijn als volgt:

• Gebruikersverificatie: wordt gebruikt om de identiteit van menselijke gebruikers te verifiëren.
• Toepassingsverificatie: wordt gebruikt om de identiteit te verifiëren van een toepassing die toegang moet hebben tot resources zonder menselijke tussenkomst met behulp van geconfigureerde referenties.
• On-behalf-of (OBO) verificatie: hiermee kan een toepassing een token uitwisselen voor deze toepassing met een token voor toegang tot een Kusto-service. Deze stroom moet worden geïmplementeerd met MSAL.
• Verificatie van toepassing met één pagina (SPA): hiermee kunnen webtoepassingen met beveiligd-WACHTWOORDVERIFICATIE aan clientzijde gebruikers aanmelden en tokens ophalen voor toegang tot uw cluster. Deze stroom moet worden geïmplementeerd met MSAL.

Notitie

Voor gebruikers- en toepassingsverificatie raden we u aan de Kusto-clientbibliotheken te gebruiken. Als u verificatie namens (OBO) of Single-Page Application (SPA) nodig hebt, moet u MSAL rechtstreeks gebruiken, omdat deze stromen niet worden ondersteund door de clientbibliotheken. Zie Verifiëren met Microsoft Authentication Library (MSAL) voor meer informatie.

Gebruikersverificatie

Gebruikersverificatie vindt plaats wanneer een gebruiker referenties presenteert aan Microsoft Entra ID of een id-provider die federeert met Microsoft Entra ID, zoals Active Directory Federation Services. De gebruiker krijgt een beveiligingstoken terug dat kan worden gepresenteerd aan de Azure Data Explorer-service. Azure Data Explorer bepaalt of het token geldig is, of het token is uitgegeven door een vertrouwde verlener en welke beveiligingsclaims het token bevat.

Azure Data Explorer ondersteunt de volgende methoden voor gebruikersverificatie, waaronder via de Kusto-clientbibliotheken:

• Interactieve gebruikersverificatie met aanmelding via de gebruikersinterface.
• Gebruikersverificatie met een Microsoft Entra-token dat is uitgegeven voor Azure Data Explorer.
• Gebruikersverificatie met een Microsoft Entra token dat is uitgegeven voor een andere resource die kan worden uitgewisseld voor een Azure Data Explorer-token met behulp van OBO-verificatie (On-behalf-of).

Toepassingsverificatie

Toepassingsverificatie is vereist wanneer aanvragen niet zijn gekoppeld aan een specifieke gebruiker of wanneer er geen gebruiker beschikbaar is om referenties op te geven. In dit geval wordt de toepassing geverifieerd bij Microsoft Entra ID of de federatieve IdP door geheime informatie te presenteren.

Azure Data Explorer ondersteunt de volgende methoden voor toepassingsverificatie, inclusief via de Kusto-clientbibliotheken:

• Toepassingsverificatie met een door Azure beheerde identiteit.
• Toepassingsverificatie met een X.509v2-certificaat dat lokaal is geïnstalleerd.
• Toepassingsverificatie met een X.509v2-certificaat dat als bytestroom aan de clientbibliotheek wordt gegeven.
• Toepassingsverificatie met een Microsoft Entra toepassings-id en een Microsoft Entra toepassingssleutel. De toepassings-id en toepassingssleutel zijn als een gebruikersnaam en wachtwoord.
• Toepassingsverificatie met een eerder verkregen geldig Microsoft Entra-token dat is uitgegeven aan Azure Data Explorer.
• Toepassingsverificatie met een Microsoft Entra token dat is uitgegeven voor een andere resource die kan worden uitgewisseld voor een Azure Data Explorer-token met behulp van OBO-verificatie (On-behalf-of).

Autorisatie

Voordat u een actie uitvoert op een Azure Data Explorer-resource, moeten alle geverifieerde gebruikers slagen voor een autorisatiecontrole. Azure Data Explorer maakt gebruik van het op rollen gebaseerde toegangsbeheermodel van Kusto, waarbij principals worden toegewezen aan een of meer beveiligingsrollen. Autorisatie wordt verleend zolang een van de rollen die aan de gebruiker zijn toegewezen de opgegeven actie kan uitvoeren. De rol Databasegebruiker verleent beveiligingsprincipals bijvoorbeeld het recht om de gegevens van een bepaalde database te lezen, tabellen in de database te maken en meer.

De koppeling van beveiligingsprincipals aan beveiligingsrollen kan afzonderlijk worden gedefinieerd of met behulp van beveiligingsgroepen die zijn gedefinieerd in Microsoft Entra ID. Zie Overzicht van beveiligingsrollen voor meer informatie over het toewijzen van beveiligingsrollen.

Groepsautorisatie

Autorisatie kan worden verleend aan Microsoft Entra ID groepen door een of meer rollen toe te wijzen aan de groep.

Wanneer de autorisatie van een gebruiker of toepassings-principal is gecontroleerd, controleert het systeem eerst op een expliciete roltoewijzing die de specifieke actie toelaat. Als een dergelijke roltoewijzing niet bestaat, analyseert het systeem vervolgens het lidmaatschap van de principal in alle groepen die de actie mogelijk kunnen autoriseren. Als wordt bevestigd dat de principal lid is van een van deze groepen, wordt de aangevraagde actie toegestaan. Als de principal geen lid is van dergelijke groepen, komt de actie niet door de autorisatiecontrole en is de actie niet toegestaan.

Notitie

Het controleren van groepslidmaatschappen kan resource-intensief zijn. Omdat groepslidmaatschappen niet vaak worden gewijzigd, worden de resultaten van lidmaatschapscontroles in de cache opgeslagen. De duur van de cache varieert en wordt beïnvloed door factoren zoals het lidmaatschapsresultaat (of de principal een lid is of niet), het type principal (gebruiker of toepassing), onder andere. De maximale cacheduur kan maximaal drie uur duren, terwijl de minimale duur 30 minuten is.

Gerelateerde inhoud

• Inzicht in Op rollen gebaseerd toegangsbeheer van Kusto.
• Gebruik de Kusto-clientbibliotheken voor gebruikers- of toepassingsverificatie.
• Zie Verificatie met Microsoft Authentication Library (MSAL) voor OBO- of SPA-verificatie.