ms-ai-architect/skills/ms-ai-governance/references/monitoring-observability/security-and-audit-logging-ai.md
Kjell Tore Guttormsen ddce43d8b2 feat(ms-ai-architect): Spor 1 — Port-1-substrat migrert på 4 ikke-advisor-skills (243 Source + 327 Type + 325 TOC + stale-verified poison fjernet) [skip-docs]
Steg 9 (R4): unified migrate-corpus.mjs --write over engineering/governance/
infrastructure/security. 327 filer mutert, verified=null, prosa byte-identisk
(fra første ## seksjon), advisor urørt (0 endringer).

To applier-fixes oppdaget under kjøring (TDD, RED→GREEN):
- insertHeaderFields: anker faller nå tilbake når en meta-linje selv passerer
  500B (2 filer pakket et avsnitt i **Status:** → Type/Source landet utenfor
  scan-vinduet, applierens post-write-assertion fanget + restaurerte).
- normalizeStaleVerified: fjerner nå ALLE stale non-date **Verified:** i
  500B-vinduet, inkl. stray body-dup rett under --- (9 mlops-genaiops-filer var
  ellers falskt "verified"/fresh, droppet fra worklist). Operatør-godkjent
  utvidelse av carve-out; kun stray metadata-linjer, aldri prosa.

test-transform-criterion: precondition oppdatert til post-migrasjons-sannhet
(fila bærer nå Source). Suite 728/728 grønn.
2026-07-04 10:19:11 +02:00

22 KiB
Raw Blame History

Security and Audit Logging for AI Systems

Last updated: 2026-06-19 Status: GA Category: Monitoring & Observability Type: reference Source: https://learn.microsoft.com/security/benchmark/azure/mcsb-v2-artificial-intelligence-security


Innhold

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:

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:

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 310 å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 Documented
Monitor Azure OpenAI https://learn.microsoft.com/en-us/azure/foundry-classic/openai/how-to/monitor-openai Documented
Azure security baseline for Azure OpenAI https://learn.microsoft.com/en-us/security/benchmark/azure/baselines/azure-openai-security-baseline Documented — 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 Documented — 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 Documented
Artificial Intelligence Security (AI-6: Establish monitoring and detection) https://learn.microsoft.com/en-us/security/benchmark/azure/mcsb-v2-artificial-intelligence-security Documented
Azure Policy Regulatory Compliance controls https://learn.microsoft.com/en-us/azure/governance/policy/samples/azure-security-benchmark Documented
Best practices for data and AI governance (Databricks) https://learn.microsoft.com/en-us/azure/databricks/lakehouse-architecture/data-governance/best-practices Documented — 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 Documented Basert på offisielle Microsoft docs + compliance-rammeverk
Kjernekomponenter Documented Loggkategorier og schema hentet fra Azure Monitor-dokumentasjon
Arkitekturmønstre Documented Pattern 1-3 er anbefalt praksis fra Microsoft security baselines
Beslutningsveiledning Documented KQL-queries testet mot Azure Monitor-dokumentasjon
Integrasjon Documented 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