ms-ai-architect/skills/ms-ai-governance/references/monitoring-observability/security-and-audit-logging-ai.md

Security and Audit Logging for AI Systems

Last updated: 2026-05 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, Azure AI 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 Azure AI 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 AI Services	Trusseldeteksjon spesifikk for AI	Jailbreak-forsøk, prompt injection, unormale modell-outputs. Støtter Azure OpenAI (via Foundry Tools). Konfigureres separat for Foundry-ressurser. (Verified MCP 2026-04)
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)
Azure AI 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:

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
Azure AI 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:

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):

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):

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):

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
Sampling	Logg kun 10% av requests for lavrisiko-tjenester (bruk Azure Functions for sampling)
Tiered storage	30 dager i Log Analytics, deretter arkiver til Cool/Archive tier
Regional placement	Plasser Log Analytics workspace i samme region som AI-tjenester (unngå egress-kostnader)

---

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/ai-foundry/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. (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). Tre governance-modeller: sentralisert, distribuert (federated), hybrid. AI-genererte kommentarer støttes (krever human review). (Verified MCP 2026-04)

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-04