ms-ai-architect/skills/ms-ai-governance/references/norwegian-public-sector-governance/nsm-grunnprinsipper-ai-mapping.md
Kjell Tore Guttormsen 3a73eeafdc refactor(ms-ai-architect): R13 del 1 — nøytraliser Cosmo-personaen i ref-korpusets headinger, etter å ha rettet en gate som var målt usann to ganger
Ordre 20260912T193441Z-7358817909. Steg 1 var ikke transformen, men å rette
roadmapens R13-gate og få den ratifisert. Gaten `grep -rl "Cosmo"
skills/*/references -> 0` var usann på to uavhengige måter:

1. Ordren fanget den første: 451 av forekomstene er Azure Cosmos DB, ekte
   produktinnhold. Diskriminatoren er ikke bokstaven «s» — `Cosmos <norsk
   substantiv>` er genitiv av personaen (`### Cosmos tonalitet`), mens
   `Cosmos DB`/`CosmosClient`/`cosmos_ru` er produkt.
2. Denne økten fant den andre: 132 persona-forekomster ligger i prosa,
   tabeller, dialog-replikker og proveniens-linjer. Heading-nøytralisering
   kan ikke nå dem, så «0 persona» er uoppnåelig også under den ratifiserte
   formen. Operatøren ratifiserte alternativ A: gaten speiler formen, og de
   132 bokføres til R13b/R14.

Tre korreksjoner av premisser som sto i ordren og STATE:
  «ca 320 produkt»   -> 451 (case-sensitivt nett manglet 327 lowercase
                        TOC-ankre + 99 identifikatorer; sann nevner 1 638)
  «169 headinger»    -> 401. 169 var `^## For Cosmo`-prefikset (168) og var
                        internt inkonsistent med sin egen topp-variant (204)
  «417 matcher ingen
   populasjon»       -> 417 er cosmo-headinger utenfor kodefences; briefens
                        nevner var reell hele tiden

Fence-bevissthet er målt skadelig, ikke nødvendig: begge toggle-regler er
gale på dette korpuset (naiv toggle skjuler en ekte heading i
chain-of-thought-prompting.md, CommonMark-regelen ubalanserer
service-level-documentation-dr.md). Fence-agnostisk deteksjon finner 401
heading-linjer i nøyaktig de samme 40 variantene som fence-bevisst finner
400 i — ingen kodeblokk-linje er byte-identisk til en persona-heading. Derfor
nøkles transformen på 40 enumererte heading-tekster og ignorerer fences. En
ukjent variant kaster; en slug-kollisjon kaster. Ingenting auto-fikses.

TOC-en regenereres ikke, den rettes kirurgisk: alle 327 persona-lenker hadde
lenketekst lik én av de 40 heading-tekstene og anker lik slugify av den
(327/327, 0 avvik), så heading og TOC-entry skrives i samme operasjon og
ingen mellomtilstand etterlater en død lenke.

Ratifisert målform: `For Cosmo`, `For Cosmo Skyberg` og `For arkitekten
(Cosmo)` konvergerer på `For arkitekten`. To filer kolliderte og er adjudisert
ved å lese dem, ikke ved regel.

Verifisering (alle 7 kriterier fra ordren):
  G1 persona på heading-linjer   401 -> 0
  G2 døde fragmentlenker         1 -> 1 (pre-eksisterende, unntatt)
  G3 produkt-forekomster         451 -> 451; `Cosmos DB|Azure Cosmos` 308 = 308
  de 3 kun-produkt-filene        byte-identiske
  nettet validert begge veier    injisert persona feller G1; genitiv feller G1;
                                 produkt-heading og de 3 filene passerer
  hele diffen                    802 heading-linjer + 654 TOC-linjer, ANNET = 0
  linjeantall                    728 lagt til = 728 slettet
  suite                          1120/1120 (1097 + 23 nye)
  validate-plugin                250 PASS / 0 FAIL
  stikkprøve                     10 filer, alle 5 skills, inkl. de 3 mest
                                 produkt-tunge (26/20/19) — kun heading+TOC

Utenfor scope, urørt: de 4 SKILL.md, de 23 commands, CLAUDE.md, README.md,
NOTICE.md, docs/ (alt R14).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-12 22:12:28 +02:00

27 KiB
Raw Blame History

NSM Grunnprinsipper for IKT-sikkerhet anvendt på AI

Last updated: 2026-02 Status: Gjeldende (NSM Grunnprinsipper v2.1, juni 2024) Category: Norwegian Public Sector AI Governance Type: reference Source: https://learn.microsoft.com/security/benchmark/azure/security-baselines-overview


Innhold

Introduksjon

Nasjonal sikkerhetsmyndighet (NSM) er Norges fagmyndighet for informasjons- og objektsikkerhet, og det nasjonale fagmiljøet for IKT-sikkerhet. NSMs Grunnprinsipper for IKT-sikkerhet (versjon 2.1, publisert juni 2024) omfatter 4 kategorier med 21 prinsipper og tilhørende sikkerhetstiltak.

Dette dokumentet mapper NSMs grunnprinsipper til AI-systemer, med spesielt fokus på Microsoft AI-stakken (Microsoft Foundry, Copilot Studio, M365 Copilot, Power Platform AI).

Hvorfor dette er relevant for AI-arkitekter:

  • AI-systemer introduserer nye sårbarheter (prompt injection, datainnsamling, modell-drift)
  • Offentlig sektor har strengere krav til trygghet, etterprøvbarhet og personvern
  • NSMs prinsipper gir et norsk-tilpasset rammeverk som kompletterer internasjonale standarder (NIST AI RMF, EU AI Act)

Relaterte dokumenter:

  • digdir-ai-governance.md — Digdirs AI-prinsipper og veiledere
  • eu-ai-act-norway.md — EU AI-forordningen i norsk kontekst
  • dpia-for-ai.md — Personvernkonsekvensvurdering for AI

De fire kategoriene

NSMs grunnprinsipper for IKT-sikkerhet er strukturert i fire hovedkategorier:

1. Identifisere og kartlegge

Formål: Å forstå systemene, infrastrukturen og dataene du har.

Prinsipper:

  • 1.1 Kartlegg styringsstrukturer, leveranser og understøttende systemer
  • 1.2 Kartlegg enheter og programvare
  • 1.3 Kartlegg brukere og behov for tilgang

2. Beskytte og opprettholde

Formål: Å etablere en sikker IKT-arkitektur og opprettholde beskyttelsestiltak.

Prinsipper:

  • 2.1 Ivareta sikkerhet i anskaffelses- og utviklingsprosesser
  • 2.2 Etabler en sikker IKT-arkitektur
  • 2.3 Ivareta en sikker konfigurasjon
  • 2.4 Beskytt virksomhetens nettverk
  • 2.5 Kontroller dataflyt
  • 2.6 Ha kontroll på identiteter og tilganger
  • 2.7 Beskytt data i ro og i transitt
  • 2.8 Beskytt e-post og nettleser
  • 2.9 Etabler evne til gjenoppretting av data
  • 2.10 Integrer sikkerhet i prosess for endringshåndtering

3. Oppdage

Formål: Å overvåke og identifisere sårbarheter og trusler.

Prinsipper:

  • 3.1 Oppdag og fjern kjente sårbarheter og trusler
  • 3.2 Etabler sikkerhetsovervåkning
  • 3.3 Analyser data fra sikkerhetsovervåkning
  • 3.4 Gjennomfør inntrengningstester

4. Håndtere og gjenopprette

Formål: Å respondere på og lære av sikkerhetshendelser.

Prinsipper:

  • 4.1 Forbered virksomheten på håndtering av hendelser
  • 4.2 Vurder og klassifiser hendelser
  • 4.3 Kontroller og håndter hendelser
  • 4.4 Evaluer og lær av hendelser

Mapping til AI-systemer

Hver kategori fra NSMs rammeverk krever AI-spesifikk tilpasning:

Kategori 1: Identifisere og kartlegge (AI-kontekst)

1.1 Kartlegg AI-styringsstrukturer og leveranser

AI-spesifikke tiltak:

  • AI-systemregister: Oppretthold en oversikt over alle AI-systemer, modeller og datakilder
  • Leverandørkartlegging: Identifiser hvem som eier AI-modellene (OpenAI, Microsoft, egenutviklet)
  • Risikokategorisering: Klassifiser AI-systemer etter EU AI Act (forbudt, høyrisiko, begrenset risiko, minimal)
  • Dataflyt-mapping: Dokumenter hvor treningsdata, inference-data og modellutsagn flyter

Microsoft-implementering:

- Azure AI Content Safety: Klassifisering av AI-innhold
- Purview AI Hub: AI-datakartlegging
- Azure Resource Graph: Oversikt over AI-ressurser
- AI Bill of Materials (AI-BOM): Sporbarhet av modellkomponenter

1.2 Kartlegg AI-enheter og programvare

AI-spesifikke tiltak:

  • Modellregister: Versjonshåndtering av AI-modeller (Azure Machine Learning Model Registry, Copilot Studio versions)
  • API-endepunkter: Kartlegg alle AI-tjenester (OpenAI API, Azure OpenAI, Copilot Studio endpoints)
  • Tredjeparts-integrasjoner: Plugins, connectors, custom agents (Copilot Studio, M365 Copilot)
  • Embeddings-komponenter: Hvilke vektormodeller brukes (text-embedding-ada-002, Cohere, custom)

Microsoft-implementering:

- Azure Machine Learning Workspace: Modellregister med versjonering
- Microsoft Foundry Model Catalog: Oversikt over tilgjengelige modeller
- Copilot Studio: Agent- og plugin-oversikt
- Power Platform: AI Builder model inventory

1.3 Kartlegg brukere og AI-tilgang

AI-spesifikke tiltak:

  • Brukerroller for AI: Hvem kan trene modeller, publisere agenter, endre prompts?
  • Prompt-tilgangskontroll: Hvem kan endre system messages og grounding data?
  • Datakilde-tilgang: Hvilke brukere får AI-systemet tilgang til data på vegne av?
  • Audit logging: Spor alle AI-interaksjoner for etterprøvbarhet

Microsoft-implementering:

- Azure RBAC: Granulære roller (AI Developer, AI User, Model Deployer)
- Entra ID: Identitetsstyring for AI-tjenester
- Copilot Studio Security Roles: Publisher, Author, Viewer
- Power Platform DLP Policies: Begrens AI-tilgang til datakilder
- Azure Monitor Logs: AI-interaksjonslogging

Kategori 2: Beskytte og opprettholde (AI-kontekst)

2.1 Ivareta sikkerhet i AI-anskaffelse og utvikling

AI-spesifikke tiltak:

  • AI-leverandørvurdering: Evaluer modelleverandørers sikkerhetspraksis (OpenAI, Microsoft, Anthropic)
  • Secure AI Development Lifecycle: Inkluder trusselmodellering, red teaming, bias-testing
  • Kontraktskrav: Klausulering rundt databehandling, modelleiersskap, tilbaketrekking
  • AI-risikovurdering: Gjennomfør ROS-analyse før AI-systemet settes i produksjon

Microsoft-implementering:

- Microsoft Foundry Safety Evaluations: Pre-deployment testing
- Microsoft Security Development Lifecycle (SDL) for AI
- Responsible AI Impact Assessment (RAIA): Built-in template
- Azure AI Content Safety: Pre-deployment red teaming

2.2 Etabler en sikker AI-arkitektur

AI-spesifikke tiltak:

  • Zero Trust for AI: Ingen AI-komponent har implisitt tillit
  • Prompt injection-forsvar: Input validation, output filtering, grounding enforcement
  • Datagrensesnitt-sikring: Private endpoints for AI-tjenester, ingen offentlig tilgang
  • Modell-isolasjon: Separate miljøer for utvikling, staging og produksjon

Microsoft-implementering:

- Azure OpenAI: Managed identity + private endpoints
- Microsoft Foundry Playgrounds: Sandboxed testing
- Copilot Studio: Data loss prevention (DLP) policies
- Azure Virtual Network Integration: AI-tjenester i VNET
- Azure Private Link for AI Services

2.3 Ivareta en sikker AI-konfigurasjon

AI-spesifikke tiltak:

  • System message hardening: Unngå prompt injeksjon via "jailbreak"-teknikker
  • Temperature/top-p tuning: Kontroller AI-kreativitet for å redusere hallusinasjoner
  • Content filtering policies: Aktiver Azure AI Content Safety for input/output
  • Grounding enforcement: Bruk data_sources i Azure OpenAI for faktatroskhet

Microsoft-implementering:

- Azure OpenAI Content Filters: Konfigurer terskelverdier for hate/violence/sexual/self-harm
- Copilot Studio: Topic-level security settings
- Prompt Shields (Microsoft Foundry): Forsvar mot jailbreak og indirect attacks
- Azure Policy for AI: Enforce security baselines

2.4 Beskytt AI-nettverkskommunikasjon

AI-spesifikke tiltak:

  • Private endpoints: All AI-trafikk går via Azure backbone, aldri public internet
  • API Management: Rate limiting, IP whitelisting, OAuth enforcement
  • Trafikkanalyse: Overvåk unormal API-bruk (token-spiking, rask repetering)

Microsoft-implementering:

- Azure Private Link for Azure OpenAI
- Azure API Management: AI gateway med rate limiting
- Azure Firewall: Blokkering av ukjente AI-endepunkter
- Network Security Groups (NSG): Granulær trafikkkontroll

2.5 Kontroller AI-dataflyt

AI-spesifikke tiltak:

  • Input sanitization: Fjern persondata før prompts sendes til modellen
  • Output validation: Filtrer sensitive opplysninger fra AI-responser
  • Data residency: Bekreft at data forblir i Norge/EU (Azure OpenAI geo-pinning)
  • Treningsdata-isolasjon: Microsoft har commitment til ikke å bruke kundedata for treningsformål

Microsoft-implementering:

- Azure OpenAI Data Residency: EU-region for data processing
- Azure AI Content Safety: PII-detection og redaksjon
- Purview Data Loss Prevention: Blokkering av sensitiv data i AI-prompts
- Microsoft Privacy Commitments: No customer data training

2.6 Ha kontroll på AI-identiteter og tilganger

AI-spesifikke tiltak:

  • Managed Identity for AI: All AI-tilgang via Azure Managed Identities (ingen API-nøkler)
  • Least privilege for AI agents: Copilot Studio-agenter får kun tilgang til nødvendige datakilder
  • MFA for AI-administratorer: Krev multifaktorautentisering for prompt-redigering
  • Conditional Access: Blokkér AI-tilgang fra ukjente lokasjoner

Microsoft-implementering:

- Azure Managed Identity: AI-tjenester autentiserer uten secrets
- Entra ID Conditional Access: Geografiske og enhetsbaserte begrensninger
- Privileged Identity Management (PIM): Just-in-time tilgang til AI-ressurser
- Copilot Studio Authentication: Entra ID, OAuth, manual configuration

2.7 Beskytt AI-data i ro og i transitt

AI-spesifikke tiltak:

  • Kryptering av prompts: TLS 1.2+ for all AI-kommunikasjon
  • Kryptering av vektordatabaser: Azure AI Search med customer-managed keys (CMK)
  • Modellkryptering: Azure Machine Learning models lagret kryptert
  • Backup-sikring: Krypterte backups av Copilot Studio-konfigurasjon og konversasjonshistorikk

Microsoft-implementering:

- Azure OpenAI: TLS 1.2 enforced, encryption at rest with Microsoft/customer-managed keys
- Azure AI Search: CMK for vector stores
- Azure Blob Storage (for training data): Encryption at rest + soft delete
- Azure Key Vault: Sentralisert nøkkelhåndtering

2.8 Beskytt AI i e-post og nettleser

AI-spesifikke tiltak:

  • M365 Copilot sikring: Aktiver Defender for Office 365 for å blokkere phishing-baserte prompt attacks
  • Browser-basert AI-tilgang: Edge Enterprise Mode for Copilot-tilgang
  • Content Security Policy: Blokkér tredjepartsscripts som kan lekke AI-prompts

Microsoft-implementering:

- Microsoft Defender for Office 365: AI-basert phishing-deteksjon
- Microsoft Edge Enterprise: Managed Copilot access
- Conditional Access: Blokkér AI-tilgang fra usikre nettlesere

2.9 Etabler gjenopprettingsevne for AI-data

AI-spesifikke tiltak:

  • Modellversjonering: Mulighet til å rulle tilbake til tidligere AI-modeller
  • Prompt-versjonering: Git-basert versjonsstyring av system messages
  • Backup av vektordata: Azure AI Search har geo-redundante backups
  • Konversasjonshistorikk: Mulighet til å gjenopprette Copilot-dialoger etter incident

Microsoft-implementering:

- Azure Machine Learning: Model versioning + rollback
- Git integration i Microsoft Foundry: Versjonskontroll for prompts
- Azure AI Search: Geo-redundant backup
- Copilot Studio: Export/import av bot-konfigurasjon
- Azure Backup for AI workloads

2.10 Integrer sikkerhet i AI-endringsrutiner

AI-spesifikke tiltak:

  • Prompt change management: Alle prompt-endringer krever review og testing
  • Model deployment gating: CI/CD-pipelines med security gates før produksjonssetting
  • Rollback-plan: Automatisk tilbakerulling ved detektert modell-drift eller bias

Microsoft-implementering:

- Azure DevOps Pipelines: AI model deployment med security approvals
- Azure Machine Learning Endpoints: Blue-green deployment for modeller
- Microsoft Foundry Evaluations: Pre-deployment testing av prompts
- Copilot Studio Version Control: Rollback til tidligere agentversjoner

Kategori 3: Oppdage (AI-kontekst)

3.1 Oppdag og fjern AI-sårbarheter og trusler

AI-spesifikke tiltak:

  • Prompt injection-deteksjon: Overvåk innkommende prompts for jailbreak-forsøk
  • Modell-drift-deteksjon: Identifiser når AI-ytelse forverres over tid
  • Hallucination monitoring: Track fact-grounding accuracy
  • Dependency scanning: Overvåk sårbarheter i AI-biblioteker (LangChain, Semantic Kernel)

Microsoft-implementering:

- Azure AI Content Safety: Real-time jailbreak detection
- Azure Monitor Application Insights: Modell-ytelsesovervåkning
- Prompt Shields (Microsoft Foundry): Indirect attack detection
- Microsoft Defender for Cloud: Sårbarhetsscanning av AI-miljøer

3.2 Etabler AI-sikkerhetsovervåkning

AI-spesifikke tiltak:

  • Token-forbruksovervåkning: Identifiser unormal API-bruk (DDoS-angrep mot AI)
  • Sensitive data leakage monitoring: Overvåk om AI eksponerer persondata
  • User behavior analytics: Oppdagelse av innsidertrusler via AI-brukerlogger
  • Model drift alerting: Varsling når modellens confidence scores faller

Microsoft-implementering:

- Azure Monitor for AI: Logging av alle AI-requests/responses
- Azure Sentinel: SIEM for AI-sikkerhetshendelser
- Purview Audit Logs: Sporing av AI-dataaksess
- Copilot Studio Analytics: Konversasjonsovervåkning
- Power BI dashboards: Real-time AI-sikkerhetsmetrikker

3.3 Analyser data fra AI-sikkerhetsovervåkning

AI-spesifikke tiltak:

  • Anomaly detection: Bruk Azure Machine Learning til å oppdage uvanlige AI-mønstre
  • Threat intelligence integration: Korrelasjoner mellom AI-angrep og kjente trusselaktører
  • Bias drift analysis: Periodisk analyse av om AI-modellen viser diskriminerende atferd

Microsoft-implementering:

- Azure Sentinel AI-powered threat detection
- Azure Machine Learning Anomaly Detector: AI-basert overvåkning av AI-systemer
- Responsible AI Dashboard: Bias/fairness metrics over tid
- Azure Log Analytics: KQL-queries for AI-sikkerhetsanalyse

3.4 Gjennomfør AI-penetrasjonstester

AI-spesifikke tiltak:

  • Red teaming for AI: Simuler prompt injection, jailbreak, data exfiltration
  • Adversarial testing: Test modellens robusthet mot adversarial inputs
  • Plugin security testing: Sikkerhetsgranskning av Copilot Studio plugins
  • OWASP LLM Top 10 testing: Systematisk testing mot kjente AI-sårbarheter

Microsoft-implementering:

- Azure AI Red Team (Microsoft Research): Professional red teaming services
- Microsoft Foundry Safety Evaluations: Adversarial testing toolkit
- PyRIT (Python Risk Identification Toolkit): Open-source AI red teaming
- Microsoft Security Response Center (MSRC): Rapportering av AI-sårbarheter

Kategori 4: Håndtere og gjenopprette (AI-kontekst)

4.1 Forbered virksomheten på AI-hendelser

AI-spesifikke tiltak:

  • AI incident response plan: Dokumentert prosess for håndtering av AI-sikkerhetshendelser
  • Roller og ansvar: Hvem har myndighet til å deaktivere AI-systemer?
  • Kommunikasjonsplan: Hvordan varsles brukere ved AI-datalekkasje?
  • Juridisk beredskap: Konsekvenser av AI Act-brudd, GDPR-krav

Microsoft-implementering:

- Azure Security Incident Response playbooks
- Microsoft Incident Response: Professional incident handling for AI breaches
- Azure Service Health: Status notifications for AI service disruptions
- Compliance Manager: AI Act readiness assessment

4.2 Vurder og klassifiser AI-hendelser

AI-spesifikke tiltak:

  • Hendelseskategorier: Prompt injection, data leakage, bias incident, hallucination harm
  • Alvorlighetsgradering: Lav (engangs hallusinasjon), Medium (bias-drift), Høy (PII-lekkasje), Kritisk (jailbreak-kompromittering)
  • GDPR-varsling: Krav til melding til Datatilsynet innen 72 timer ved databrudd

Microsoft-implementering:

- Azure Sentinel Incident Severity Classification
- Microsoft Purview Data Breach Notification workflows
- Azure AI Content Safety Incident Logs: Structured severity tagging

4.3 Kontroller og håndter AI-hendelser

AI-spesifikke tiltak:

  • Immediate containment: Deaktiver kompromittert AI-modell eller agent
  • Forensics: Analyser AI-logger for å identifisere omfanget av dataeksponering
  • Remediation: Oppdater system messages, aktiver strengere content filters
  • User notification: Informer berørte brukere hvis persondata er lekket

Microsoft-implementering:

- Azure OpenAI Deployment deactivation: Umiddelbar shutdown
- Azure Monitor Logs: Forensisk analyse av AI-hendelser
- Copilot Studio: Emergency agent disable
- Microsoft Incident Response Retainer: Professional incident handling

4.4 Evaluer og lær av AI-hendelser

AI-spesifikke tiltak:

  • Post-incident review: Hva var root cause? (Prompt design, architecture flaw, user error?)
  • Lessons learned documentation: Oppdater AI-sikkerhetsprosedyrer
  • Model retraining: Hvis bias ble oppdaget, revurder treningsdata
  • Policy updates: Oppdater DLP-policies, content filters, eller access controls

Microsoft-implementering:

- Microsoft Foundry Evaluation Reports: Post-incident model analysis
- Azure DevOps Retrospectives: Incident review tracking
- Responsible AI Impact Assessment updates: Incorporate learnings
- Azure Policy revisions: Codify security improvements

Microsoft Azure-tjenester som dekker NSMs prinsipper

Følgende tabell mapper hver av NSMs 21 prinsipper til konkrete Microsoft Azure AI-tjenester:

NSM-prinsipp Microsoft Azure-tjeneste Hvordan det dekker prinsippet
1.1 Kartlegg styringsstrukturer Azure Purview AI Hub, Azure Resource Graph AI-systemregister og datakatalogleveranse
1.2 Kartlegg enheter og programvare Azure Machine Learning Model Registry, Microsoft Foundry Modellversjonering, API-inventar
1.3 Kartlegg brukere og tilgang Entra ID, Azure RBAC, Azure Monitor Logs Identitetsstyring og audit logging
2.1 Sikkerhet i anskaffelse Responsible AI Impact Assessment, SDL for AI AI-leverandørvurdering og secure development
2.2 Sikker arkitektur Azure OpenAI Private Endpoints, VNET integration Zero Trust for AI
2.3 Sikker konfigurasjon Azure AI Content Safety, Prompt Shields Content filtering og jailbreak-forsvar
2.4 Beskytt nettverk Azure Private Link, Azure API Management Private AI-endepunkter og API gateway
2.5 Kontroller dataflyt Azure AI Content Safety PII detection, Purview DLP Data residency og PII-filtrering
2.6 Identiteter og tilganger Azure Managed Identity, Entra ID Conditional Access Managed Identity for AI, MFA enforcement
2.7 Beskytt data Azure OpenAI encryption at rest/transit, Azure Key Vault TLS 1.2+, customer-managed keys
2.8 E-post og nettleser Microsoft Defender for Office 365, Edge Enterprise AI-basert phishing-forsvar
2.9 Gjenoppretting Azure Backup, Azure Machine Learning versioning Modellversjonering og geo-redundant backup
2.10 Endringshåndtering Azure DevOps Pipelines, Microsoft Foundry Evaluations CI/CD med security gates
3.1 Oppdag sårbarheter Azure AI Content Safety, Prompt Shields Jailbreak og prompt injection-deteksjon
3.2 Sikkerhetsovervåkning Azure Monitor, Azure Sentinel, Application Insights Real-time AI-logging og SIEM
3.3 Analyser overvåkningsdata Azure Sentinel, Azure Machine Learning Anomaly Detector AI-basert anomali-deteksjon
3.4 Penetrasjonstester Azure AI Red Team, PyRIT, Safety Evaluations Red teaming og adversarial testing
4.1 Forbered hendelseshåndtering Azure Security Incident Response, Service Health AI incident response playbooks
4.2 Klassifiser hendelser Azure Sentinel Incident Severity, Purview Breach Workflows GDPR-varsling og alvorlighetsgradering
4.3 Håndter hendelser Azure OpenAI deployment shutdown, Incident Response Retainer Immediate containment og forensics
4.4 Lær av hendelser Microsoft Foundry Evaluation Reports, Azure DevOps Retrospectives Post-incident review og policy updates

Sjekkliste for AI-prosjekter

Bruk denne sjekklisten for å verifisere at AI-systemet oppfyller NSMs grunnprinsipper:

Identifisere og kartlegge

  • Alle AI-systemer er registrert i et sentralt AI-register
  • Risikoklassifisering etter EU AI Act er gjennomført (forbudt/høyrisiko/begrenset/minimal)
  • Leverandørkjeden for AI-modeller er dokumentert (OpenAI, Microsoft, custom)
  • Alle datakilder for AI (treningsdata, grounding data) er kartlagt
  • Brukere og roller med tilgang til AI-systemer er identifisert
  • Audit logging er aktivert for alle AI-interaksjoner

Beskytte og opprettholde

  • ROS-analyse for AI-systemet er gjennomført og godkjent
  • Trusselmodellering inkluderer AI-spesifikke trusler (prompt injection, jailbreak, bias)
  • Private endpoints er konfigurert for Azure OpenAI (ingen public internet access)
  • Azure AI Content Safety er aktivert (input/output filtering)
  • Prompt Shields er aktivert (jailbreak og indirect attack forsvar)
  • Managed Identity brukes for AI-autentisering (ingen API-nøkler i kode)
  • Customer-managed keys (CMK) brukes for kryptering av vektordata (Azure AI Search)
  • Data residency er verifisert (Norge/EU-region for Azure OpenAI)
  • Microsoft har bekreftet at kundedata ikke brukes til treningsformål
  • Backup og gjenopprettingsprosedyrer for AI-modeller og prompts er på plass

Oppdage

  • Azure Monitor logging er konfigurert for alle AI-tjenester
  • Azure Sentinel har AI-spesifikke deteksjonsregler (unormal token-bruk, PII-lekkasje)
  • Modell-drift-overvåkning er etablert (accuracy, confidence scores)
  • Bias-overvåkning er implementert (Responsible AI Dashboard)
  • Red teaming for AI er gjennomført (PyRIT eller Azure AI Red Team)
  • OWASP LLM Top 10 testing er utført

Håndtere og gjenopprette

  • AI incident response plan er dokumentert og kjent i organisasjonen
  • Roller og ansvar for AI-hendelser er tildelt (hvem kan deaktivere AI-systemer?)
  • GDPR-varslingsprosedyre er på plass (72-timers krav)
  • Post-incident review-rutiner er etablert
  • Kommunikasjonsplan for AI-datalekkasje er godkjent

For arkitekten

Bruk disse spørsmålene i konsultasjonsfasen:

  1. Har virksomheten et AI-systemregister, og er det oppdatert?

    • Hvis nei: Start med å kartlegge alle AI-systemer (prinsipp 1.1)
    • Hvis ja: Verifiser at Microsoft Foundry-prosjekter er inkludert
  2. Er AI-systemet klassifisert etter EU AI Act, og hvilke NSM-tiltak følger av den klassifiseringen?

    • Høyrisiko-AI (f.eks. rekruttering, kredittvurdering) krever ekstra dokumentasjon og menneskeovervåkning
    • Minimal risiko kan ha enklere sikkerhetskrav
  3. Har virksomheten gjennomført ROS-analyse for AI-systemet, inkludert prompt injection og bias-risiko?

    • Hvis nei: Bruk security-assessment-agent fra AI Architect-pluginen
    • Hvis ja: Verifiser at NSMs prinsipper 2.1 og 3.1 er dekket
  4. Er private endpoints konfigurert for Azure OpenAI, og er public access deaktivert?

    • Dette dekker NSM-prinsipp 2.4 (Beskytt nettverk)
    • Verifiser med: az cognitiveservices account show --name <name> --resource-group <rg> --query "publicNetworkAccess"
  5. Brukes Azure AI Content Safety og Prompt Shields for input/output-filtrering?

    • Dette dekker NSM-prinsipp 2.3 (Sikker konfigurasjon) og 3.1 (Oppdag sårbarheter)
    • Sjekk at content filters er satt til minst Medium-nivå
  6. Er data residency verifisert til Norge/EU, og har virksomheten bekreftelse fra Microsoft om at kundedata ikke brukes til treningsformål?

    • Dette dekker NSM-prinsipp 2.5 (Kontroller dataflyt)
    • Azure OpenAI kan geo-pinnes til Sverige, Norge (via Sweden) eller andre EU-regioner
  7. Er audit logging aktivert for alle AI-interaksjoner, og sendes logger til Azure Sentinel for SIEM-analyse?

    • Dette dekker NSM-prinsipp 3.2 (Sikkerhetsovervåkning)
    • Verifiser at Azure Monitor diagnostic settings er aktivert
  8. Har virksomheten en AI incident response plan, og er det klart hvem som har myndighet til å deaktivere AI-systemer ved sikkerhetshendelser?

    • Dette dekker NSM-prinsipp 4.1 (Forbered hendelseshåndtering)
    • Foreslå Azure Security Incident Response playbooks hvis manglende

Kilder og verifisering

Primærkilder:

Microsoft-dokumentasjon:

Verifisering:

  • NSMs grunnprinsipper v2.1 er den nyeste versjonen (per februar 2026)
  • Microsoft cloud security benchmark v1.0 er gjeldende standard (v3.0 er også tilgjengelig for nyere baselines)
  • Azure AI Content Safety og Prompt Shields er produksjonsklare tjenester (GA-status)
  • Private Link for Azure OpenAI er generelt tilgjengelig i alle Azure-regioner

Relaterte norske rammeverk:

  • Digdirs AI-prinsipper for offentlig sektor (digdir-ai-governance.md)
  • Personopplysningsloven og DPIA-krav (dpia-for-ai.md)
  • Utredningsinstruksen for AI-beslutningsstøtte (utredningsinstruksen-ai.md)
  • EU AI-forordningen (AI Act) i norsk kontekst (eu-ai-act-norway.md)

Sist gjennomgått: 2026-02 Neste revisjon: 2026-08 (eller ved nye versjoner av NSMs grunnprinsipper)