ms-ai-architect/skills/ms-ai-engineering/references/rag-architecture/rag-security-rbac.md

# RAG Security - RBAC, Filtering, and Access Control

**Last updated:** 2026-06-19 | Verified: MCP 2026-06-19
**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:**
```json
// 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: `2026-05-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

```json
{
  "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:**
```http
GET https://graph.microsoft.com/v1.0/me/memberOf
Authorization: Bearer <user-token>
```

**Response:**
```json
{
  "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/foundry-classic/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/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-06-19 (via microsoft-learn MCP server)

**Preview API-versjon:** 2026-05-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.