Behörighetsstyrd AI med Microsoft Entra ID – så fungerar åtkomsten
Så används Entra ID, grupper och roller för att styra åtkomst till AI-plattform, funktioner och datakällor enligt principen om minsta behörighet.
Alex Rivera
Founder
Enkel inloggning (SSO) visar vem användaren är. Det avgör inte automatiskt vad en AI-lösning får visa eller göra. För företagsanvändning behövs en behörighetsmodell som kopplar identitet till funktion, datakälla och handling.
Microsoft Entra ID kan användas för inloggning, grupper, roller och livscykel. Plattformen behöver sedan omsätta identiteten i konkreta åtkomstbeslut före varje informationshämtning och verktygsanrop.
Tre nivåer av åtkomst
Plattformsnivå
Får personen logga in och använda tjänsten?
Funktionsnivå
Får personen använda en viss assistent, agent, modell eller administrativ funktion?
Datanivå
Får personen hämta information från den aktuella källan, mappen eller dokumentet?
En fjärde nivå blir viktig för agenter: handlingsnivå. Får användaren eller tjänsterollen skapa, ändra, skicka eller radera information i ett anslutet system?
Inloggning visar vem användaren är. Behörighetsmodellen avgör vad lösningen får visa och göra.
Identitet via Microsoft Entra ID
När användaren loggar in utfärdar Entra ID en token med information om identitet och tillåtna anspråk. Applikationen validerar tokens och använder identiteten för vidare beslut.
Enkel inloggning (SSO) minskar behovet av separata lösenord och gör det möjligt att tillämpa organisationens autentiseringskrav, exempelvis multifaktor och villkorad åtkomst. Det förenklar också avregistrering när en anställning avslutas.
Plattformen ska inte lita på uppgifter som användaren själv skriver i en prompt. Identitet och roller ska komma från betrodd autentisering och kontrolleras på serversidan.
Grupper och roller
Entra-grupper kan representera organisatorisk tillhörighet, projekt eller åtkomstpaket. Applikationsroller beskriver vad användaren får göra i plattformen. Microsoft dokumenterar hur rollbaserad åtkomst används för att tilldela behörighet efter arbetsuppgift.[1]
Undvik en enda bred ”AI-användare”-grupp. Skapa i stället roller som speglar ansvar, till exempel användare, assistentskapare, granskare och administratör. Separera innehållsadministration från säkerhetsadministration där det är möjligt.
Gruppmedlemskap kan bli komplext. Dokumentera ägare, syfte, godkännande och granskningsintervall. Dynamiska grupper kan minska manuellt arbete men måste testas så att attribut inte ger oavsiktlig åtkomst.
Dokument- och källnivå
En säker kunskapschatt ska söka endast i material som användaren får läsa. Det kan göras genom separata index, metadatafilter eller kontroll mot källsystemet vid hämtning.
Behörighetsinformationen måste följa dokumentet genom bearbetning och indexering. Om ett dokument flyttas eller dess åtkomst ändras behöver indexet uppdateras. Gamla textavsnitt får inte ligga kvar med tidigare rättigheter.
Testa med flera profiler som ställer samma fråga. En HR-medarbetare, chef och extern konsult kan behöva få olika källunderlag eller inget svar alls.
Principen om minsta behörighet
Varje användare, tjänst och integration ska ha minsta åtkomst som behövs för uppgiften. En agent som endast ska skapa ett utkast behöver inte rätt att skicka det. En connector som läser en dokumentyta behöver inte skriva tillbaka.
Använd separata tekniska identiteter för separata funktioner och undvik gemensamma hemligheter med bred åtkomst. Rotera autentiseringsuppgifter och logga privilegierade handlingar.
Rollbaserad åtkomst räcker inte alltid. Kontext som dokumentklass, ärendets tillhörighet eller tid kan kräva attribut- eller policybaserade beslut. Arkitekturen bör kunna kombinera flera signaler utan att göra modellen själv ansvarig för behörigheten.
Vad händer när en användare byter roll?
Joiner-mover-leaver-processen ska omfatta AI-lösningen. När en person byter avdelning ska gamla grupper tas bort och nya tilldelas efter godkännande. När personen slutar ska sessioner, tokens och lokala rättigheter återkallas.
Tänk även på tillfälliga projekt, konsulter och gäster. Sätt slutdatum och återkommande attestering. Ett vanligt säkerhetsproblem är inte den ursprungliga tilldelningen utan behörigheter som aldrig tas bort.
Loggning och uppföljning
Logga åtkomstbeslut på en nivå som möjliggör felsökning och revision: användaridentitet, roll, begärd funktion, tillåten källa och resultat. Undvik att logga mer känsligt innehåll än vad syftet kräver.
Administrativa ändringar bör ha högre spårbarhet. Vem lade till en datakälla, ändrade en roll eller gav agenten ett nytt verktyg? Larm kan behövas vid ovanliga mönster, upprepade nekanden eller stor export.
Genomför periodiska behörighetsgranskningar tillsammans med informationsägare. Säkerhetsteamet kan kontrollera modellen, men verksamheten vet vilka personer som faktiskt behöver innehållet.
Exempel på behörighetsmodell
En kommunövergripande plattform kan ha gemensam inloggning men separata assistenter. Alla medarbetare får använda ett allmänt skrivstöd. Endast HR-gruppen får använda HR-assistenten. Chefer får läsa vissa styrande dokument men inte individärenden. Plattformens administratör kan konfigurera modellen utan att automatiskt få läsa alla dokument.
Detta kräver att plattformsroll och informationsåtkomst hålls isär. Administratör är inte samma sak som informationsägare.
Kontrollpunkter
Federerad inloggning och multifaktor där risk kräver det.
Namngivna ägare för grupper och roller.
Minsta behörighet per funktion och integration.
Behörighetsfilter före informationshämtning och modell.
Synkronisering när dokument eller grupper förändras.
Separata privilegier för administration och innehåll.
Livscykel för anställda, konsulter och gäster.
Loggning av nekanden och administrativa ändringar.
Regelbunden attestering av åtkomst.
Nödprocess för omedelbar återkallelse.
Källor
Microsoft, Microsoft Entra role-based access control:
https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/Microsoft, Custom roles:
https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/custom-overviewNIST, AI Risk Management Framework:
https://www.nist.gov/itl/ai-risk-management-framework


