Dela via

Översikt över åtkomstkontroll

  • Artikel

Gäller för: ✅Microsoft Fabric✅Azure Data Explorer

Åtkomstkontroll baseras på autentisering och auktorisering. Varje fråga och kommando på en Azure Data Explorer-resurs, till exempel ett kluster eller en databas, måste klara både autentiserings- och auktoriseringskontroller.

Åtkomstkontroll baseras på autentisering och auktorisering. Varje fråga och kommando på en Infrastrukturresurs, till exempel en databas, måste klara både autentiserings- och auktoriseringskontroller.

  • Authentication: Verifierar identiteten för säkerhetsobjektet som gör en begäran
  • Authorization: Verifierar att säkerhetsobjektet som gör en begäran tillåts att göra den begäran på målresursen

Autentisering

För att programmässigt autentisera måste en klient kommunicera med Microsoft Entra-ID och begära en åtkomsttoken som är specifik för Kusto-tjänsten. Sedan kan klienten använda den förvärvade åtkomsttoken som identitetsbevis när begäranden skickas till databasen.

De viktigaste autentiseringsscenarierna är följande:

  • Användarautentisering: Används för att verifiera identiteten för mänskliga användare.
  • Programautentisering: Används för att verifiera identiteten för ett program som behöver komma åt resurser utan mänsklig inblandning med hjälp av konfigurerade autentiseringsuppgifter.
  • OBO-autentisering (On-behalf-of): Tillåter att ett program byter ut en token för det programmet med en token för att få åtkomst till en Kusto-tjänst. Det här flödet måste implementeras med MSAL.
  • SPA-autentisering (Single Page Application): Tillåter att SPA-webbprogram på klientsidan loggar in användare och får token för åtkomst till databasen. Det här flödet måste implementeras med MSAL.

Not

För användar- och programautentisering rekommenderar vi att du använder Kusto-klientbibliotek. Om du behöver autentisering för OBO (On-behalf-of) eller Single-Page Application (SPA) måste du använda MSAL direkt eftersom klientbiblioteken inte stöder dessa flöden. Mer information finns i Autentisera med Microsoft Authentication Library (MSAL).

Användarautentisering

Användarautentisering sker när en användare presenterar autentiseringsuppgifter för Microsoft Entra-ID eller en identitetsprovider som federeras med Microsoft Entra-ID, till exempel Active Directory Federation Services. Användaren hämtar tillbaka en säkerhetstoken som kan visas för Azure Data Explorer-tjänsten. Azure Data Explorer avgör om token är giltig, om token utfärdas av en betrodd utfärdare och vilka säkerhetsanspråk som token innehåller.

Azure Data Explorer stöder följande metoder för användarautentisering, bland annat via Kusto-klientbibliotek:

  • Interaktiv användarautentisering med inloggning via användargränssnittet.
  • Användarautentisering med en Microsoft Entra-token utfärdad för Azure Data Explorer.
  • Användarautentisering med en Microsoft Entra-token utfärdad för en annan resurs som kan bytas ut mot en Azure Data Explorer-token med hjälp av OBO-autentisering (Å-behalf-of).

Programautentisering

Programautentisering krävs när begäranden inte är associerade med en specifik användare eller när ingen användare är tillgänglig för att ange autentiseringsuppgifter. I det här fallet autentiserar programmet till Microsoft Entra-ID eller federerad IdP genom att presentera hemlig information.

Azure Data Explorer stöder följande metoder för programautentisering, bland annat via Kusto-klientbibliotek:

  • Programautentisering med en hanterad Azure-identitet.
  • Programautentisering med ett X.509v2-certifikat installerat lokalt.
  • Programautentisering med ett X.509v2-certifikat som ges till klientbiblioteket som byteström.
  • Programautentisering med ett Microsoft Entra-program-ID och en Microsoft Entra-programnyckel. Program-ID:t och programnyckeln är som ett användarnamn och lösenord.
  • Programautentisering med en tidigare hämtad giltig Microsoft Entra-token som utfärdats till Azure Data Explorer.
  • Programautentisering med en Microsoft Entra-token utfärdad för en annan resurs som kan bytas ut mot en Azure Data Explorer-token med hjälp av OBO-autentisering (Å-behalf-of).

Tillstånd

Innan du utför en åtgärd på en resurs måste alla autentiserade användare klara en auktoriseringskontroll. Den kusto-rollbaserad åtkomstkontroll modellen används, där huvudnamn tillskrivas en eller flera säkerhetsroller. Auktorisering beviljas så länge en av de roller som tilldelats användaren tillåter att de utför den angivna åtgärden. Rollen Databasanvändare ger till exempel säkerhetsobjekt rätt att läsa data för en viss databas, skapa tabeller i databasen med mera.

Associationen mellan säkerhetsobjekt och säkerhetsroller kan definieras individuellt eller med hjälp av säkerhetsgrupper som definieras i Microsoft Entra-ID. Mer information om hur du tilldelar säkerhetsroller finns i Översikt över säkerhetsroller.

Gruppauktorisering

Auktorisering kan beviljas till Microsoft Entra-ID-grupper genom att tilldela en eller flera roller till gruppen.

När du kontrollerar auktoriseringen för en användare eller programmets huvudnamn letar systemet först efter en explicit rolltilldelning som tillåter den specifika åtgärden. Om rolltilldelningen inte finns kontrollerar systemet huvudkontots medlemskap i alla grupper som kan auktorisera åtgärden.

Om huvudkontot är medlem i en grupp med lämpliga behörigheter godkänns den begärda åtgärden. Annars godkänns inte auktoriseringskontrollen och tillåts inte.

Not

Kontrollen av gruppmedlemskap kan vara resursintensiv. Eftersom gruppmedlemskap inte ändras ofta cachelagras resultatet av medlemskapskontrollen. Cachelagringstiden varierar och avgör hur snabbt ändringar av gruppmedlemskap uppdateras. Det kan ta upp till 30 minuter att lägga till en användare i en grupp. Det kan ta upp till tre timmar att ta bort en användare från en grupp.

Framtvinga uppdatering av gruppmedlemskap

Huvudnamn kan tvinga fram en uppdatering av information om gruppmedlemskap. Den här funktionen är användbar i scenarier där jit-privilegierade åtkomsttjänster (just-in-time), till exempel Microsoft Entra Privileged Identity Management (PIM), används för att få högre behörighet för en resurs.

Uppdatera för en specifik grupp

Huvudnamn kan tvinga fram en uppdatering av gruppmedlemskap för en viss grupp. Följande begränsningar gäller dock:

  • En uppdatering kan begäras upp till 10 gånger per timme per huvudnamn.
  • Det begärande huvudkontot måste vara medlem i gruppen vid tidpunkten för begäran.

Begäran resulterar i ett fel om något av dessa villkor inte uppfylls.

Kör följande kommando för att omvärdera det aktuella huvudkontots medlemskap i en grupp:

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

Använd gruppens fullständigt kvalificerade namn (FQN). Mer information finns i Referera till Microsoft Entra-huvudnamn och -grupper.

Uppdatera för andra huvudnamn

Ett privilegierat huvudnamn kan begära en uppdatering för andra huvudnamn. Det begärande huvudkontot måste ha AllDatabaseMonitor åtkomst för måltjänsten. Privilegierade huvudnamn kan också köra föregående kommando utan begränsningar.

Om du vill uppdatera ett annat huvudnamns gruppmedlemskap kör du följande kommando:

I följande kommando ersätter du <PrincipalFQN> med ditt eget fullständigt kvalificerade huvudnamn (FQN) och <GroupFQN> med ditt eget grupp-FQN. Mer information finns i Referera till Microsoft Entra-huvudnamn och -grupper.

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

Relaterat innehåll