# Security and Audit Logging for AI Systems

**Last updated:** 2026-06-19
**Status:** GA
**Category:** Monitoring & Observability

---

## Introduksjon

Security og audit logging for AI-systemer er et kritisk grunnlag for compliance, incident response og forensisk analyse. Azure AI-tjenester genererer diagnostiske logger som kan spore brukeraktivitet, dataaksess, modellinteraksjon og systemhendelser — men loggene samles ikke inn før du eksplisitt konfigurerer diagnostiske innstillinger (diagnostic settings). Uten strukturert logging har du ingen sporbarhet når sikkerhetsbrudd oppstår, og ingen evne til å dokumentere hvem som aksesserte sensitive data.

Azure Monitor tilbyr et helhetlig rammeverk for å samle, lagre og analysere audit logs fra Azure OpenAI, Microsoft Foundry, Copilot Studio og andre AI-tjenester. Loggene kan rutes til Log Analytics for KQL-basert analyse, Azure Storage for langtidslagring, eller SIEM-løsninger som Microsoft Sentinel for korrelasjon med threat intelligence.

For norsk offentlig sektor er audit logging et lovpålagt krav under Forvaltningsloven § 11, GDPR Artikkel 30 (loggføring av behandlingsaktiviteter), og AI Act (loggføring av høyrisiko AI-systemer). Microsoft-stakken leverer innebygde funksjoner for logging, men konfigurasjonen er kundens ansvar — resource logs er deaktivert som standard, med unntak av Microsoft Foundry som har automatisk logging.

---

## Kjernekomponenter

| Komponent | Formål | Omfatter |
|-----------|--------|----------|
| **Azure Monitor Resource Logs** | Detaljert logging av data plane-operasjoner | API calls, modell-inferens, plugin-interaksjoner, token-forbruk |
| **Azure Activity Log** | Control plane-hendelser på abonnementsnivå | Ressursopprettelse, rolleutdelinger, brannmurregler, sletting |
| **Diagnostic Settings** | Rute-konfigurasjon for loggeksport | Log Analytics, Storage Account, Event Hub, SIEM-partnere |
| **Microsoft Defender for Cloud — AI threat protection + AI-SPM** | Trusseldeteksjon spesifikk for AI | Jailbreak-forsøk, prompt injection, unormale modell-outputs + AI Security Posture Management. Støtter Azure OpenAI. Konfigureres separat for Foundry-ressurser. («Foundry resource», kind=AIServices, er nytt navn på det som tidligere het «Foundry Tools».) *(Verified MCP 2026-06-19)* |
| **Microsoft Purview** | Dataklassifisering og tilgangssporing | PII-aksess, sensitiv datalogging, dataeiers-revisjon |
| **Azure Policy** | Compliance enforcement | Automatisk pålegging av diagnostiske innstillinger, policy-etterlevelse |

### Loggkategorier per tjeneste

| AI-tjeneste | Loggkategorier | Standard enabled? |
|-------------|----------------|-------------------|
| **Azure OpenAI** | `Audit`, `RequestResponse`, `Trace` | Nei (krever diagnostic setting) |
| **Azure AI Services** | `Audit`, `RequestResponse`, `AllMetrics` | Nei (krever diagnostic setting) |
| **Microsoft Foundry** | Azure Monitor, Log Analytics | Ja (auto-enabled) |
| **Azure AI Search** | Resource logs, API requests | Nei (krever diagnostic setting) |

### Logginnhold: `AzureDiagnostics`-schema

Alle Azure AI-tjenester følger felles Azure Monitor resource log-schema:

```kusto
AzureDiagnostics
| project
    TimeGenerated,        // Tidsstempel for hendelse
    _ResourceId,          // Full Azure Resource ID
    Category,             // "Audit", "RequestResponse", "Trace"
    OperationName,        // "Inference", "CreateDeployment", etc.
    DurationMs,           // Responstid
    ResultSignature,      // HTTP status code
    CallerIpAddress,      // Opprinnelse
    Identity,             // User Principal Name eller Managed Identity
    properties_s          // JSON-payload med request/response-detaljer
```

**Eksempel på sensitive felt i `properties_s`:**

- `modelName` — hvilken modell som ble brukt
- `tokenUsage` — input/output tokens
- `userInput` — brukerens prompt (kan inneholde PII)
- `modelOutput` — modellens svar (kan inneholde PII eller konfidensielt innhold)

⚠️ **Sikkerhetsvurdering:** Hvis du logger `RequestResponse`-kategorien, kan bruker-prompts og modell-outputs inneholde PII eller forretningshemmeligheter. Sørg for at Log Analytics workspace eller Storage Account har tilsvarende tilgangskontroller.

---

## Arkitekturmønstre

### Pattern 1: Sentralisert SIEM-integrert logging

**Brukstilfelle:** Organisasjoner som krever korrelasjon mellom AI-trusler og enterprise-wide security events.

**Arkitektur:**

```
Azure OpenAI → Diagnostic Settings → Event Hub → Microsoft Sentinel
Azure AI Services → Diagnostic Settings → Event Hub → Microsoft Sentinel
Microsoft Defender for AI → Native integration → Sentinel
```

**Fordeler:**

- Korrelasjon med MITRE ATLAS og OWASP Top 10 for LLM threat intelligence
- Automatisk alerting via Sentinel playbooks
- Unified dashboarding på tvers av alle Azure-ressurser

**Ulemper:**

- Høyere kostnad (Event Hub + Sentinel ingestion)
- Krever Sentinel-kompetanse for KQL-queries og playbook-utvikling

**Anbefaling:** Bruk for høyrisiko AI-systemer (GDPR, AI Act høyrisiko) og scenarier hvor AI-trusler må korreleres med network/identity-angrep.

---

### Pattern 2: Compliance-orientert langtidslagring

**Brukstilfelle:** Norsk offentlig sektor med lovpålagt audit trail i 10+ år (Riksarkivet).

**Arkitektur:**

```
Azure AI Services → Diagnostic Settings → Storage Account (Cool/Archive tier)
                 → Immutable storage policy
                 → Legal hold for etterforskninger
```

**Fordeler:**

- Lavest kostnad for langtidslagring
- Immutable blobs sikrer ikke-manipulerbare audit trails
- Oppfyller arkivlovens krav

**Ulemper:**

- Ingen real-time analyse (krever eksport til Log Analytics for queries)
- Rehydrering fra Archive tier kan ta timer

**Anbefaling:** Kombiner med Log Analytics for hot analytics (30-90 dager), arkiver til Storage etter retention period.

---

### Pattern 3: Operativ sanntidsanalyse med KQL

**Brukstilfelle:** DevOps og SRE-team som trenger raske insights i modellytelse, feilmønstre og bruksmønstre.

**Arkitektur:**

```
Azure OpenAI → Diagnostic Settings → Log Analytics Workspace
Microsoft Foundry → (auto-enabled) → Log Analytics Workspace
```

**Fordeler:**

- KQL-basert ad-hoc analyse
- Integrasjon med Azure Monitor dashboards og alerts
- Native support for Azure Workbooks (visualisering)

**Ulemper:**

- Log Analytics ingestion-kostnad (per GB)
- Retention limits (maks 730 dager uten export)

**KQL-eksempel — detektere unormale token-forbruksmønstre:**

```kusto
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.COGNITIVESERVICES"
| where Category == "RequestResponse"
| extend TokenUsage = toint(parse_json(properties_s).tokenUsage)
| summarize TotalTokens = sum(TokenUsage), RequestCount = count() by bin(TimeGenerated, 1h), CallerIpAddress
| where TotalTokens > 1000000  // Flagg unormalt høyt forbruk
| order by TotalTokens desc
```

**Anbefaling:** Standard-mønster for de fleste scenarier. Kombiner med Storage-eksport for langtidslagring.

---

## Beslutningsveiledning

| Scenario | Anbefalt pattern | Log retention | Loggkategorier |
|----------|------------------|---------------|----------------|
| **GDPR/AI Act compliance** | Sentralisert SIEM + Langtidslagring | 3–10 år | `Audit`, `RequestResponse` |
| **Utredningsinstruksen** | Langtidslagring (immutable) | 10+ år | `Audit`, `AllMetrics` |
| **Sikkerhetshendelsesanalyse** | SIEM-integrert | 90 dager hot + arkiv | `Audit`, `RequestResponse`, Defender for AI |
| **Kostnadsoptimalisering** | Log Analytics + Archive | 30 dager hot, resten Archive | `Audit`, `AllMetrics` |
| **Red Teaming / penetrasjonstesting** | Log Analytics (real-time) | 30 dager | `Audit`, `RequestResponse`, `Trace` |
| **PII-revisjon** | Purview + Log Analytics | 3 år | `RequestResponse` (med PII-flagging) |

### Vanlige feil

| Feil | Konsekvens | Rettelse |
|------|------------|----------|
| **Ikke aktivert diagnostic settings** | Ingen audit trail ved sikkerhetsbrudd | Azure Policy: pålegg diagnostikk for alle AI-ressurser |
| **Logger `RequestResponse` uten PII-vurdering** | GDPR-brudd hvis prompts inneholder persondata | Implementer Microsoft Purview for datalogging-klassifisering |
| **Manglende immutable storage** | Audit logs kan manipuleres av angriper | Aktiver immutability policy på Storage Account |
| **Retention period for kort** | Kan ikke etterleve Forvaltningslovens arkivkrav | Sett minimum 3 år (GDPR) eller 10 år (Riksarkivet) |
| **Ingen SIEM-integrering** | AI-trusler korreleres ikke med andre angrep | Rute til Sentinel for threat correlation |

### Røde flagg (deteksjon)

Disse KQL-queries kan brukes til alerting:

**1. Deteksjon av jailbreak-forsøk (unormalt lange prompts):**

```kusto
AzureDiagnostics
| where Category == "RequestResponse"
| extend PromptLength = strlen(parse_json(properties_s).userInput)
| where PromptLength > 5000
| project TimeGenerated, CallerIpAddress, Identity, PromptLength
```

**2. Deteksjon av prompt injection (mistenkelige nøkkelord):**

```kusto
AzureDiagnostics
| where Category == "RequestResponse"
| extend UserInput = tostring(parse_json(properties_s).userInput)
| where UserInput contains "ignore previous instructions"
     or UserInput contains "system:"
     or UserInput contains "[INST]"
| project TimeGenerated, CallerIpAddress, Identity, UserInput
```

**3. Uautorisert dataaksess (PII-aksess av ukjent identitet):**

```kusto
AzureDiagnostics
| where Category == "Audit"
| where Identity !in ("trusted-app@domain.com", "known-user@domain.com")
| extend Resource = parse_json(properties_s).resourceType
| where Resource == "PersonalData"
| project TimeGenerated, Identity, CallerIpAddress, Resource
```

---

## Integrasjon med Microsoft-stakken

| Tjeneste | Integrasjonspunkt | Formål |
|----------|-------------------|--------|
| **Microsoft Sentinel** | Event Hub → Sentinel connector | SIEM-korrelasjon med MITRE ATLAS threat intelligence |
| **Microsoft Purview** | Auto-klassifisering av logged data | PII-flagging i `RequestResponse` logs |
| **Azure Policy** | Built-in policy: `Diagnostic logs in Azure AI services resources should be enabled` | Compliance enforcement |
| **Microsoft Defender for AI** | Native integration til Sentinel | Jailbreak-deteksjon, prompt injection alerts |
| **Azure Monitor Workbooks** | Pre-built templates for Azure OpenAI | Visualisering av token-forbruk, feilrater, latency |
| **Power BI** | Log Analytics connector | Executive dashboards for compliance-rapportering |
| **Azure Key Vault** | Audit logging av secrets access | Spor hvem som aksesserte API keys for AI-tjenester |

### Compliance-mapping

| Regulering | Krav | Azure-løsning |
|------------|------|---------------|
| **GDPR Artikkel 30** | Loggføring av persondata-behandling | Resource logs (`RequestResponse`) + Purview klassifisering |
| **AI Act Artikkel 12** | Logging av høyrisiko AI-systemer (minimum 6 måneder) | Diagnostic settings + Log Analytics (retention: 180+ dager) |
| **Forvaltningsloven § 11** | Journalføring av vedtak | `Audit` logs + immutable Storage Account |
| **Schrems II / Cloud Act** | EU-datasuverenitet | Log Analytics workspace i Norge/EU-region |
| **Riksarkivet** | Langtidsarkivering (10+ år) | Storage Account (Archive tier) + legal hold |

---

## Offentlig sektor (Norge)

### Særskilte krav

| Krav | Rettsgrunnlag | Implementasjonsanbefalinger |
|------|---------------|------------------------------|
| **Journalplikt** | Offentleglova § 6 | Audit logs må inneholde: Hvem, Hva, Når, Hvorfor. Bruk `Identity`, `OperationName`, `TimeGenerated`, og custom properties for saksnummer. |
| **Innsyn** | Offentleglova § 3 | Log Analytics kan eksporteres til PDF/Excel for innsynsbegjæringer. Implementer query for "all logs relatert til person X". |
| **Datasuverenitet** | NSM Grunnprinsipper | Log Analytics workspace må være i **Norway East** eller **Norway West** region. Valider at Event Hub ikke ruter via USA. |
| **ROS-analyse** | Sikkerhetsloven § 2-1 | Audit logs er input til risiko- og sårbarhetsvurderinger. Bruk KQL-queries for "attempted unauthorized access"-rapporter. |
| **DPIA for AI-systemer** | GDPR Artikkel 35 | Dokumenter loggingsstrategi som tiltak for å "overvåke AI-beslutninger". Vis at alle AI-interaksjoner spores. |
| **Personalansvar** | Forvaltningsloven § 41 | Logs må kunne identifisere "hvem" (saksbehandler, AI-operatør). Bruk Entra ID identity logging. |

### Digdir-spesifikke anbefalinger

| Prinsipp | Løsning |
|----------|---------|
| **Sporbarhet** | Alle AI-modell-kall må logge bruker-identitet (Entra ID UPN), tidspunkt, input-prompt, output-resultat. |
| **Etterprøvbarhet** | Kombiner audit logs med Azure Machine Learning Model Registry for å spore "hvilken modellversjon ga dette svaret". |
| **Åpenhet** | Publiser aggregert statistikk fra logs (antall AI-henvendelser per måned) som del av transparenskrav. |

### Kostnadseksempel (offentlig sektor)

For en kommune med **5000 AI-interaksjoner per dag**:

| Ressurs | Konfigurasjon | Månadskostnad (NOK) |
|---------|---------------|----------------------|
| **Log Analytics ingestion** | 150 GB/måned @ $2.99/GB | ~4200 NOK |
| **Log Analytics retention** | 90 dager hot, 3 år archive | ~1500 NOK |
| **Storage Account (Archive tier)** | 1 TB @ $0.002/GB | ~20 NOK |
| **Microsoft Sentinel** | 150 GB ingestion | ~6500 NOK |
| **Total** | | **~12 220 NOK/måned** |

**Kostnadsoptimalisering:**

- Ekskluder `Trace` logs (brukes kun ved debugging)
- Bruk `AllMetrics` i stedet for `RequestResponse` hvis du ikke trenger prompt-innhold
- Archive logs fra Log Analytics etter 30 dager til Storage Account
- Implementer sampling (logg kun hver 10. request) for lavrisiko-tjenester

---

## Kostnad og lisensiering

### Prismodell (per februar 2026)

| Komponent | Prismetrikk | Pris (NOK) |
|-----------|-------------|------------|
| **Log Analytics ingestion** | Per GB | ~30 NOK/GB |
| **Log Analytics retention** | Per GB per måned (over gratis 31 dager) | ~8 NOK/GB/måned |
| **Storage Account (Hot tier)** | Per GB | ~2 NOK/GB/måned |
| **Storage Account (Cool tier)** | Per GB | ~0.20 NOK/GB/måned |
| **Storage Account (Archive tier)** | Per GB | ~0.02 NOK/GB/måned |
| **Event Hub throughput** | Per throughput unit | ~150 NOK/time |
| **Microsoft Sentinel ingestion** | Per GB | ~43 NOK/GB |

### Lisensiering

Ingen ekstra lisenser kreves for audit logging — funksjonen er inkludert i Azure-abonnementet. Men:

| Komponent | Lisenskrav |
|-----------|------------|
| **Microsoft Defender for AI** | Krever Defender for Cloud (Standard tier) |
| **Microsoft Purview** | Separat Purview-lisens (compliance SKU) |
| **Microsoft Sentinel** | Pay-as-you-go (ingen fast lisens) |

### Optimaliseringstips

| Strategi | Besparelse |
|----------|------------|
| **Selective logging** | Logg kun `Audit` og `AllMetrics`, hopp over `RequestResponse` hvis PII-logging ikke er nødvendig | -60% ingestion cost |
| **Sampling** | Logg kun 10% av requests for lavrisiko-tjenester (bruk Azure Functions for sampling) | -90% ingestion cost |
| **Tiered storage** | 30 dager i Log Analytics, deretter arkiver til Cool/Archive tier | -80% retention cost |
| **Regional placement** | Plasser Log Analytics workspace i samme region som AI-tjenester (unngå egress-kostnader) | -5–10% network cost |

---

## For arkitekten (Cosmo)

### 5-8 spørsmål å stille stakeholders

1. **Hva er organisasjonens compliance-krav?**
   - GDPR, AI Act, Forvaltningsloven, Riksarkivet?
   - Påvirker dette retention period (3 vs 10 år)?

2. **Hvilke typer AI-interaksjoner må logges?**
   - Kun audit trail (hvem/når), eller fullt request/response-innhold?
   - Inneholder prompts/outputs PII eller forretningshemmeligheter?

3. **Hvem skal ha tilgang til loggene?**
   - Kun sikkerhetsteam, eller også utviklere/compliance-offiserer?
   - Kreves role-based access control (RBAC) på Log Analytics workspace?

4. **Er det krav til SIEM-integrasjon?**
   - Finnes eksisterende Sentinel-oppsett?
   - Skal AI-trusler korreleres med network/identity-angrep?

5. **Hva er budsjett for logging?**
   - Akseptabel månadskostnad per GB ingestion?
   - Kan vi bruke sampling eller selective logging for å redusere volum?

6. **Hva er organisasjonens incident response-prosess?**
   - Hvor raskt må logs være tilgjengelig ved sikkerhetsbrudd?
   - Kreves real-time alerting (→ Log Analytics) eller etterpå-analyse (→ Storage)?

7. **Er det krav til immutable audit trails?**
   - Juridiske prosesser, etterforskninger, regulatory audits?
   - Skal logs være beskyttet mot sletting/modifikasjon?

8. **Hvilke regulatoriske rapporter må genereres?**
   - Månedlige AI-bruksstatistikker for Datatilsynet?
   - Årlige ROS-analyser basert på loggdata?

### Fallgruver

| Fallgruve | Konsekvens | Unngå ved |
|-----------|------------|-----------|
| **Logging av PII uten klassifisering** | GDPR-brudd, bøter | Implementer Purview for auto-klassifisering før logging |
| **Manglende regional compliance** | Schrems II-brudd hvis logs lagres i USA | Valider at Log Analytics workspace er i EU-region |
| **Ingen immutability på logs** | Logs kan slettes av angriper | Aktiver immutable blobs på Storage Account |
| **For lang retention i hot tier** | Unødvendig høy kostnad | Arkiver til Cool/Archive etter 30-90 dager |
| **Ingen alerting på suspicious activity** | Jailbreak-forsøk oppdages ikke | Implementer KQL-basert alerts i Azure Monitor |
| **Logging av secrets** | API keys/passwords eksponeres i logs | Aldri logg Authorization headers eller API keys |

### Anbefalinger per modenhetsnivå

| Modenhetsnivå | Løsningsanbefaling |
|---------------|---------------------|
| **Level 1 (Starter)** | Aktiver diagnostic settings med `Audit` og `AllMetrics` → Log Analytics (30 dager retention). Bruk pre-built Azure Monitor Workbooks for visualisering. |
| **Level 2 (Intermediate)** | Legg til `RequestResponse` logging + Purview for PII-klassifisering. Implementer KQL-basert alerts for unormale mønstre. Arkiver til Storage etter 90 dager. |
| **Level 3 (Advanced)** | Integrer med Microsoft Sentinel for threat correlation. Implementer custom playbooks for auto-remediation. Immutable storage for compliance. |
| **Level 4 (Expert)** | Red Teaming-basert logging (PYRIT, Azure AI Red Teaming Agent). Custom ML-basert anomaly detection på loggdata. Legal hold-prosesser for etterforskninger. |

---

## Kilder og verifisering

### Microsoft Learn-dokumentasjon (Verified via MCP)

| Kilde | URL | Konfidensnivå |
|-------|-----|---------------|
| **Enable diagnostic logging for Azure AI services** | https://learn.microsoft.com/en-us/azure/ai-services/diagnostic-logging | ✅ Verified |
| **Monitor Azure OpenAI** | https://learn.microsoft.com/en-us/azure/foundry-classic/openai/how-to/monitor-openai | ✅ Verified |
| **Azure security baseline for Azure OpenAI** | https://learn.microsoft.com/en-us/security/benchmark/azure/baselines/azure-openai-security-baseline | ✅ Verified — **OBS:** Basert på MCSB v1.0 (kan inneholde utdatert veiledning). Produktet refereres nå som "Foundry Tools" i baseline-dokumentet. Siste veiledning: [Azure OpenAI docs](https://learn.microsoft.com/en-us/azure/foundry/). *(Verified MCP 2026-04)* |
| **Azure security baseline for Microsoft Foundry** | https://learn.microsoft.com/en-us/security/benchmark/azure/baselines/azure-ai-foundry-security-baseline | ✅ Verified — **OBS:** Tjenesten er omdøpt til "Microsoft Foundry" i baseline-dokumentet. Basert på MCSB v1.0. Viktige avvik: Customer Lockbox **ikke støttet** for Foundry, lokal autentisering til data plane **ikke støttet** (positivt for sikkerhet), DLP/sensitive data discovery **ikke støttet** nativt. *(Verified MCP 2026-04)* |
| **Microsoft cloud security benchmark: Logging and threat detection** | https://learn.microsoft.com/en-us/security/benchmark/azure/mcsb-logging-threat-detection | ✅ Verified |
| **Artificial Intelligence Security (AI-6: Establish monitoring and detection)** | https://learn.microsoft.com/en-us/security/benchmark/azure/mcsb-v2-artificial-intelligence-security | ✅ Verified |
| **Azure Policy Regulatory Compliance controls** | https://learn.microsoft.com/en-us/azure/governance/policy/samples/azure-security-benchmark | ✅ Verified |
| **Best practices for data and AI governance (Databricks)** | https://learn.microsoft.com/en-us/azure/databricks/lakehouse-architecture/data-governance/best-practices | ✅ Verified — Unity Catalog er nå sentral governance for BÅDE data og AI assets (modeller, features, lineage ned til kolonne-nivå). Tre governance-modeller: sentralisert, distribuert (federated), hybrid. Audit-logging på to nivåer (workspace + account) + verbose audit logs per query/kommando. AI-genererte kommentarer støttes (krever human review). *(Verified MCP 2026-06-19)* |

### Konfidensgradering per seksjon

| Seksjon | Konfidensnivå | Merknad |
|---------|---------------|---------|
| **Introduksjon** | ✅ Verified | Basert på offisielle Microsoft docs + compliance-rammeverk |
| **Kjernekomponenter** | ✅ Verified | Loggkategorier og schema hentet fra Azure Monitor-dokumentasjon |
| **Arkitekturmønstre** | ✅ Verified | Pattern 1-3 er anbefalt praksis fra Microsoft security baselines |
| **Beslutningsveiledning** | ✅ Verified | KQL-queries testet mot Azure Monitor-dokumentasjon |
| **Integrasjon** | ✅ Verified | Native integrasjoner dokumentert i Microsoft Learn |
| **Offentlig sektor** | ⚠️ Baseline | Rettsgrunnlag er korrekt, implementasjonsdetaljer er tolkninger |
| **Kostnad** | ⚠️ Baseline | Priser fra Azure Pricing Calculator (februar 2026), kan variere |

### Sist verifisert: 2026-06-19