ktg-plugin-marketplace/plugins/ms-ai-architect/skills/ms-ai-engineering/references/rag-architecture/rag-security-rbac.md

RAG Security - RBAC, Filtering, and Access Control

Last updated: 2026-04 | Verified: MCP 2026-04 Status: Preview (native ACL/RBAC), GA (security filters) Category: RAG Architecture & Semantic Search

---

Introduksjon

Sikkerhet i RAG-systemer (Retrieval-Augmented Generation) er kritisk for å beskytte sensitiv informasjon og overholde compliance-krav. Denne kunnskapsreferansen dekker dokumentnivå-tilgangskontroll (document-level access control), som sikrer at brukere kun kan hente og få svar basert på dokumenter de er autorisert til å se.

Azure AI Search støtter fire hovedtilnærminger til dokumentnivå-sikkerhet: security filters (GA), POSIX-like ACL/RBAC scopes (preview), Microsoft Purview sensitivity labels (preview), og SharePoint in Microsoft 365 ACLs (preview). Disse metodene lar organisasjoner bygge RAG-løsninger som respekterer eksisterende tilgangsmodeller og sikkerhetspolicyer.

Dokumentnivå-sikkerhet er spesielt viktig for RAG-applikasjoner i offentlig sektor, der ulike brukere og grupper må ha isolert tilgang til informasjon basert på rolle, organisatorisk tilhørighet, eller sikkerhetsgradert klassifisering.

Kjernekomponenter

1. Security Filters (GA)

Security filters bruker string-sammenligning for å trimme søkeresultater basert på bruker- eller gruppeidentitet.

Egenskap	Beskrivelse
Implementasjon	OData-filter med search.in() funksjon
Autentisering	Ikke påkrevd (kun string matching)
API-kompatibilitet	Fungerer med alle versjoner/pakker
Ytelse	Subsekund responstid med search.in()
Bruksområde	Custom access models, ikke-Microsoft security frameworks

Viktige implementasjonsdetaljer:

• Felttype: Collection(Edm.String)
• Attributter: filterable: true, retrievable: false
• Filter-syntaks: group_ids/any(g:search.in(g, 'id1, id2, ...'))

2. Native ACL/RBAC Scope Permissions (Preview)

Native støtte basert på Microsoft Entra ID-brukere og grupper.

Tilnærming	Data Source	Støtte-nivå
ADLS Gen2 ACL	Azure Data Lake Storage Gen2	Dokumentnivå (filer + directories)
Azure Blob RBAC	Azure Blob Storage	Container-nivå
SharePoint ACL	SharePoint in Microsoft 365	Dokumentnivå (filer + list items)

Teknisk flyt:

1. Index-schema opprettes med permission filters (preview API)
2. Indexer eller Push API henter ACL-metadata fra data source
3. Query-tid: x-ms-query-source-authorization header inneholder Microsoft Entra token
4. Azure AI Search matcher token mot ACL-metadata i hvert dokument

3. Microsoft Purview Sensitivity Labels (Preview)

Integrerer Microsoft Information Protection-policyer i RAG-søkepipeline.

Komponent	Funksjon
Data sources	Azure Blob, ADLS Gen2, SharePoint, OneLake
Label storage	Lagret som metadata i Azure AI Search index
Enforcement	Query-tid validering mot Purview policies
Token	Microsoft Entra token via x-ms-query-source-authorization

4. Query-Time Access Enforcement

Azure AI Search utfører to-stegs sjekk ved query-tid (for ACL/RBAC-metoder):

1. Index-nivå: Validerer at applikasjonen har Search Index Data Reader rolle
2. Dokument-nivå: Matcher bruker/gruppe-token mot ACL-metadata i dokumenter

Permission sources:

Type	Kilde
userIds	oid claim fra x-ms-query-source-authorization token
groupIds	Group membership fra Microsoft Graph API
rbacScope	Storage container-permissions (Storage Blob Data Reader rolle)

Arkitekturmønstre

Mønster 1: Security Filter Pattern (anbefalt for custom access models)

Fordeler:

• API-agnostic (fungerer på alle versjoner)
• Ingen autentiseringskrav
• Enkel å implementere
• God ytelse med search.in() funksjon

Ulemper:

• Krever manuell population av security-felt
• Ingen native integration med identity providers
• Kun string-sammenligning (ingen faktisk autentisering)

Når bruke:

• Custom access control models
• Ikke-Microsoft identity providers
• Legacy-systemer uten Entra ID
• Enklere sikkerhetskrav

Implementasjon:

// Index schema
{
  "name": "group_ids",
  "type": "Collection(Edm.String)",
  "filterable": true,
  "retrievable": false
}

// Query filter
{
  "filter": "group_ids/any(g:search.in(g, 'group1, group2, group3'))"
}

Mønster 2: Native ACL/RBAC Pattern (anbefalt for Microsoft-stack)

Fordeler:

• Native integration med Microsoft Entra ID
• Arver permissions fra data source (ADLS Gen2, SharePoint)
• Automatisk ACL-synkronisering
• Microsoft Graph integration for nested groups

Ulempler:

• Preview-funksjon (risiko for breaking changes)
• Krever preview API/SDK
• Høyere initial kompleksitet
• Avhengighet av Microsoft-økosystem

Når bruke:

• Azure-native data sources (ADLS Gen2, Blob, SharePoint)
• Eksisterende ACL-modeller som skal preserveres
• Behov for automatic permission inheritance
• Enterprise-scenarier med Entra ID

Tekniske krav:

• Preview REST API: 2025-11-01-preview
• Managed identity på Search service
• Role assignment: Storage Blob Data Reader (for ADLS Gen2/Blob)

Mønster 3: Multitenant API Layer Pattern (anbefalt for multitenancy)

Arkitektur:

User → Intelligent App → Orchestrator → API Layer → Data Stores
                ↓
          Identity Provider

API Layer ansvar:

1. Route queries til riktig tenant-store
2. Enforce custom security trimming logic
3. Bruke riktig identity for platform-basert authorization
4. Logg access for audit purposes

Fordeler:

• Encapsulation av tenant/user access logic
• Single governance point
• Enklere testing og validering
• Separasjon av concerns

Ulempler:

• Ekstra latency (ekstra hop)
• Krever custom development
• Potensielt single point of failure

Når bruke:

• Multitenant SaaS-løsninger
• Komplekse authorization rules
• Behov for audit logging
• Custom security requirements beyond platform capabilities

Beslutningsveiledning

Beslutningstabell

Scenario	Anbefalt tilnærming	Begrunnelse
Azure-native data sources med eksisterende ACLer	Native ACL/RBAC (preview)	Arver permissions automatisk, ingen manuell sync
Custom access models uten Entra ID	Security filters	API-agnostic, enkel implementasjon
Multitenant SaaS	API Layer + security filters	Full kontroll over tenant isolation
Microsoft 365-integrasjon	SharePoint ACL (preview) eller Purview labels	Native integration med M365 security
Offentlig sektor med sikkerhetsgradert info	Purview sensitivity labels + API layer	Compliance-fokusert, audit-ready
Legacy-systemer	Security filters	Ingen avhengighet av moderne identity providers

Vanlige feil

Feil	Konsekvens	Løsning
Security-felt er retrievable	Identiteter eksponeres i search results	Sett retrievable: false
Bruker equality expressions (eq) for filters	Ytelsesproblem (sekunder latency med mange grupper)	Bruk search.in() funksjon
Glemmer å sette filterable: true	Filter fungerer ikke	Oppdater index schema
Hardkoder group IDs i kode	Maintenance nightmare	Hent group membership dynamisk (Microsoft Graph)
Antar nested groups fungerer automatisk	Underautorisasjon (brukere mister tilgang)	Expand nested groups før query (Graph API)
Ignorerer ACL hierarchy (ADLS Gen2)	Feil permissions på filer	Bruk indexer med ACL support (preview API)

Røde flagg

⚠️ Du bør vurdere alternativ hvis:

• Du ikke kan bruke preview-APIer i produksjon
• Du trenger document-level security men mangler identity management
• Du planlegger å eksponere RAG-endepunkt uten autentisering
• Du har > 1000 grupper per bruker (ytelsesutfordringer)
• Du trenger real-time ACL-synkronisering (preview har refresh-latency)

Integrasjon med Microsoft-stakken

Azure AI Search + Azure OpenAI On Your Data

Dokument-level access control:

1. Konfigurer security filters i Azure AI Search index
2. Azure OpenAI On Your Data bruker filters automatisk
3. Pass user token via filter parameter i API request

{
  "dataSources": [{
    "type": "AzureCognitiveSearch",
    "parameters": {
      "endpoint": "<search-endpoint>",
      "indexName": "<index-name>",
      "filter": "group_ids/any(g:search.in(g, 'user-groups'))"
    }
  }]
}

Entra ID Integration

Komponent	Rolle
Authentication	User identity via OAuth 2.0 / OpenID Connect
Authorization	Group membership via Microsoft Graph API
Token	JWT token i x-ms-query-source-authorization header
Nested groups	Automatic expansion via Graph API (for ACL patterns)

Supported group types (SharePoint ACL preview):

• Microsoft Entra security groups ✅
• Microsoft 365 groups ✅
• Mail-enabled security groups ✅
• SharePoint groups ❌ (ikke støttet i preview)

Microsoft Graph API

Hent group membership:

GET https://graph.microsoft.com/v1.0/me/memberOf
Authorization: Bearer <user-token>

Response:

{
  "value": [
    { "id": "group-id-1", "displayName": "HR Team" },
    { "id": "group-id-2", "displayName": "Finance Team" }
  ]
}

Copilot Studio + Power Platform

Power Platform DLP + RAG:

• Power Automate kan hente group membership fra Graph API
• Pass group IDs til Azure AI Search via connector
• Enforce additional DLP policies på retrieved content

Copilot Studio custom data sources:

• Bruk security filters i Azure AI Search data source configuration
• User context automatisk tilgjengelig i Copilot Studio flows
• Map user identity til Azure AI Search filter expression

Offentlig sektor (Norge)

GDPR + Datasuverenitet

Krav	Implementasjon
Data residency	Azure AI Search i Norway East/West regions
Audit logging	Azure Monitor + Log Analytics for alle search queries
Data minimization	Security filter fields må være retrievable: false
Right to be forgotten	Document delete via Azure AI Search APIs
Consent management	Integrer consent-status i security filter logic

Schrems II + Cloud Act

Anbefalinger:

• Bruk Azure Confidential Computing for sensitive RAG workloads
• Customer-managed keys (CMK) for encryption at rest
• Private endpoints for network isolation
• Avoid cross-region data transfer (keep data in Norway regions)

AI Act (EU)

High-risk AI system requirements:

• Human oversight: Implementer HITL (Human In The Loop) for RAG-svar på kritiske beslutninger
• Transparency: Logg hvilke dokumenter som ble retrieved og brukt i svar
• Accuracy: Test security filters med adversarial scenarios (authorization bypass attempts)
• Documentation: Vedlikehold ADR for security architecture decisions

Forvaltningsloven + Offentleglova

Lov	Relevant for RAG
Forvaltningsloven § 18	Taushetsplikt → dokumentnivå-sikkerhet obligatorisk
Offentleglova § 3	Innsynsrett → audit trail for access requests
Sikkerhetsloven	Sikkerhetsgradert informasjon → Purview sensitivity labels + DLP

Sikkerhetsgradert informasjon:

• Ugradert: Standard security filters
• Begrenset/Konfidensielt: Native ACL/RBAC + CMK
• Hemmelig/Strengt hemmelig: Ikke i Azure (krever on-premises eller Secure Cloud)

Datasuverenitet

Anbefalt stack for offentlig sektor:

• Azure AI Search (Norway East/West)
• Azure OpenAI (Sweden Central med data residency commitment)
• Private endpoint for all connections
• Managed identity (unngå API keys)
• Customer Lockbox enabled (Microsoft support-tilgang)

Kostnad og lisensiering

Prismodell-oversikt

Komponent	Kostnadsfaktor
Azure AI Search	Tier-basert (Basic, Standard, Storage Optimized)
Security filters	Ingen ekstra kostnad (inkludert i search cost)
Native ACL/RBAC	Graph API calls (per 1000 requests) + search cost
Purview labels	Microsoft Purview lisensiering (per user)
SharePoint ACL	SharePoint lisensiering (M365 E3/E5)

Estimert ekstra kostnad (preview features)

Native ACL/RBAC:

• Graph API: ~$0.0004 per request (group membership lookup)
• Antatt 1 lookup per query → $0.40 per 1000 queries
• Caching kan redusere Graph API calls betydelig

Purview sensitivity labels:

• Purview Information Protection: Inkludert i M365 E5 Compliance
• Uten E5: ca. $5-$12 per user/måned

Optimaliseringstips

1. Cache group membership: Reduser Graph API calls med Redis/Azure Cache
2. Bruk group-based access: Unngå per-user ACLs (dårlig ytelse)
3. Security filter over native ACL: For high-volume scenarios (lavere latency)
4. Batch ACL refresh: Ikke sync ACLs på hver indexing-operasjon
5. Monitor query latency: Preview features kan ha variabel ytelse

For arkitekten (Cosmo)

Spørsmål å stille kunden

1. Identity & Access:

   • Har dere Microsoft Entra ID (Azure AD)? Eller annen identity provider?
   • Hvordan håndteres brukergrupper i dag? (flat structure, nested groups?)
   • Finnes det eksisterende ACLer på data sources (SharePoint, ADLS Gen2)?

2. Compliance & Regulering:

   • Er dataene sikkerhetsgradert (Ugradert/Begrenset/Konfidensielt/Hemmelig)?
   • Hvilke compliance-krav gjelder? (GDPR, AI Act, Forvaltningsloven)
   • Trenger dere audit logging av alle search queries?

3. Teknisk modenhet:

   • Kan dere bruke preview-APIer i produksjon? (SLA, support-risiko)
   • Har dere eksisterende Azure-infrastruktur? (VNet, Private endpoints)
   • Hvilken CI/CD-modell brukes? (Terraform, Bicep, ARM templates)

4. Skalerbarhet:

   • Forventet antall brukere? Queries per sekund?
   • Hvor mange grupper per bruker i gjennomsnitt?
   • Endres ACLer ofte? (real-time sync vs. batch refresh)

5. Datakilder:

   • Hvor ligger dataene i dag? (SharePoint, ADLS Gen2, Blob, on-premises?)
   • Finnes det sensitivity labels allerede? (Microsoft Purview)
   • Kreves cross-source access control? (data fra flere systemer)

6. Risk appetite:

   • Hva er konsekvensen av data leakage? (Kritisk, Høy, Medium, Lav)
   • Akseptabelt med preview features? Eller kun GA-funksjonalitet?
   • Hvor mye custom development kan teamet håndtere?

7. Integration:

   • Skal RAG-løsningen integreres med eksisterende apps? (M365 Copilot, Power Platform)
   • Trenger dere API layer for egen orchestration? (custom logic)
   • Multitenant-behov? (delt infrastruktur for flere organisasjoner)

8. Performance & Cost:

   • Hva er akseptabel latency for search queries? (subsekund, < 1 sek, < 5 sek)
   • Budsjett for Azure AI Search? (Basic: ~$75/måned, Standard S1: ~$250/måned)
   • Kan dere akseptere Graph API-kostnader for ACL enforcement?

Fallgruver per modenhetsnivå

Beginner (Proof of Concept / Pilot)

Vanlige feil:

• Bruker equality expressions for security filters (ytelsesproblem)
• Glemmer å sette retrievable: false på security-felt
• Hardkoder group IDs i stedet for dynamisk henting
• Ignorerer nested groups (underautorisasjon)

Anbefaling:

• Start med security filters (GA, enklest)
• Test med < 100 users og < 10 groups
• Bruk Azure AI Search Basic tier for kostnadsreduksjon
• Mock group membership (ingen Graph API-avhengighet)

Intermediate (Production-ready MVP)

Vanlige feil:

• Antar preview-APIer er production-ready (breaking changes-risiko)
• Mangler caching av group membership (unødvendig Graph API-trafikk)
• Ingen audit logging av access attempts (compliance-gap)
• Glemmer å teste authorization bypass scenarios

Anbefaling:

• Implementer API layer for access control logic
• Bruk Azure Monitor + Log Analytics for audit trail
• Cache group membership i Redis (TTL: 15-30 min)
• Kjør penetration testing på security filters
• Bruk managed identity (unngå API keys)

Advanced (Enterprise-scale)

Vanlige feil:

• Over-engineering med native ACL når security filters holder
• Kompleks multitenant-arkitektur uten klare tenant boundaries
• Mangel på disaster recovery plan for ACL-data
• Ingen performance benchmarking av query latency med filters

Anbefaling:

• Kombiner security filters med native ACL (hybrid approach)
• Implementer geo-redundant Azure AI Search for HA
• Bruk Application Insights for distributed tracing
• Automatiser ACL-refresh med Azure Functions (scheduled triggers)
• Dokumenter security architecture i ADR (Architecture Decision Records)

Anbefalinger per modenhetsnivå

Nivå	Sikkerhetstilnærming	Rationale
Beginner	Security filters (GA)	Enklest, ingen preview-risiko, lavest kostnad
Intermediate	Security filters + Graph API	Dynamisk group membership, bedre maintainability
Advanced	Native ACL/RBAC (preview) + API layer	Automatic permission inheritance, enterprise-ready

Kilder og verifisering

Microsoft Learn-dokumentasjon (Verified via MCP)

1. Document-level access control overview

   • URL: https://learn.microsoft.com/en-us/azure/search/search-document-level-access-overview
   • Confidence: Verified (MCP-fetch 2026-02)
   • Dekning: Alle fire patterns (security filters, ACL/RBAC, Purview, SharePoint)

2. Security filters for trimming results

   • URL: https://learn.microsoft.com/en-us/azure/search/search-security-trimming-for-azure-search
   • Confidence: Verified (MCP-fetch 2026-02)
   • Dekning: search.in() funksjon, index schema, query syntax

3. Query-time ACL and RBAC enforcement

   • URL: https://learn.microsoft.com/en-us/azure/search/search-query-access-control-rbac-enforcement
   • Confidence: Verified (MCP-search 2026-02)
   • Dekning: Preview API, permission filter workflow, Graph API integration

4. Use ADLS Gen2 indexer for ACL ingestion

   • URL: https://learn.microsoft.com/en-us/azure/search/search-indexer-access-control-lists-and-role-based-access
   • Confidence: Verified (MCP-search 2026-02)
   • Dekning: Hierarchical permissions, POSIX-like ACLs, indexer configuration

5. Azure OpenAI On Your Data - Document-level access control

   • URL: https://learn.microsoft.com/en-us/azure/ai-foundry/openai/how-to/on-your-data-configuration#document-level-access-control
   • Confidence: Verified (MCP-search 2026-02)
   • Dekning: RAG integration, filter parameter, group_ids field mapping

6. Security in Azure AI Search

   • URL: https://learn.microsoft.com/en-us/azure/search/search-security-overview
   • Confidence: Verified (MCP-search 2026-02)
   • Dekning: Authorization, row-level security, RBAC roles

7. Design secure multitenant RAG inferencing solution

   • URL: https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/secure-multitenant-rag
   • Confidence: Verified (MCP-search 2026-02)
   • Dekning: Multitenant patterns, API layer architecture, filtering strategies

8. Retrieval-augmented Generation (RAG) in Azure AI Search

   • URL: https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview
   • Confidence: Verified (MCP-search 2026-02)
   • Dekning: RAG challenges, security & governance

9. Retrieval augmented generation (RAG) and indexes (AI Foundry)

   • URL: https://learn.microsoft.com/en-us/azure/ai-foundry/concepts/retrieval-augmented-generation?view=foundry-classic
   • Confidence: Verified (MCP-search 2026-02)
   • Dekning: Security considerations, access control at retrieval time

10. RAG LLM evaluation - Responsible AI & security

    • URL: https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/rag/rag-llm-evaluation-phase#responsible-ai,-content-safety,-and-security-evaluation
    • Confidence: Verified (MCP-search 2026-02)
    • Dekning: Content safety, privacy, adversarial threats

Code samples (Verified via MCP)

11. Security filter query example (C#)
    • URL: https://learn.microsoft.com/en-us/azure/search/search-security-trimming-for-azure-search#apply-the-security-filter-in-the-query
    • Confidence: Verified (MCP code sample search 2026-02)
    • Language: HTTP / C#
    • Dekning: search.in() filter syntax

Konfidensnivå per seksjon

Seksjon	Confidence	Kilde
Kjernekomponenter	Verified	MCP docs (1, 2, 3, 4)
Arkitekturmønstre	Verified	MCP docs (1, 2, 7)
Beslutningsveiledning	Baseline	Modellkunnskap + MCP context
Microsoft-stack integrasjon	Verified	MCP docs (5, 9)
Offentlig sektor (Norge)	Baseline	Modellkunnskap (GDPR, AI Act, norsk lov)
Kostnad og lisensiering	Baseline	Estimater basert på Azure pricing (ikke direkte MCP-verified)
For arkitekten (Cosmo)	Baseline	Best practices + erfaring

---

Sist verifisert mot Microsoft Learn: 2026-02-03 (via microsoft-learn MCP server)

Preview API-versjon: 2025-11-01-preview (ACL/RBAC, Purview labels, SharePoint ACL)

GA features: Security filters (alle API-versjoner)

Note: Preview features kan endre seg. Konsulter alltid nyeste dokumentasjon før produksjon.

Dokumentnivå-tilgangskontroll — oppdatering 2026-04

4 tilnærminger (oppdatert):

Tilnærming	Status	Beskrivelse
Security filters	GA	String-sammenligning med search.in() — API-agnostisk
POSIX-like ACL/RBAC scopes	Preview	Microsoft Entra ID-autentisering mot dokument-ACLer (ADLS Gen2)
Microsoft Purview sensitivity labels	Preview	Entra-token + Purview policy enforced ved query-tid
SharePoint M365 ACLs	Preview	SharePoint-tilganger ekstraheres av indexer og håndheves ved søk

ADLS Gen2 ACL/RBAC (preview):

• RBAC: container-nivå (grov tilgangskontroll for alle dokumenter i container)
• ACL: fil/mappe-nivå (finkornet per-dokument tilgangskontroll)
• ABAC: ikke støttet i Azure AI Search
• Tilgangsevaluering: RBAC sjekkes først, deretter ACL. Tilgang gis om én av dem tillater det
• Permissions synkroniseres ved: første full indexer-kjøring, nye dokumenter, eller manuell trigger via /resync (preview)

Query-enforcement: x-ms-query-source-authorization-header med Entra-token aktiverer automatisk trimming.