ms-ai-architect/skills/ms-ai-governance/references/norwegian-public-sector-governance/digdir-principle-4-trust-security.md

Digdirs arkitekturprinsipp 4: Tillit og sikkerhet

Last updated: 2026-06-19 Status: Gjeldende Category: Norwegian Public Sector AI Governance Type: reference Source: https://learn.microsoft.com/security/zero-trust/deploy/networks

---

Innhold

• Introduksjon
• Prinsippets kjerneinnhold
• Sikkerhetskrav for AI-løsninger
• Zero Trust for AI
• Beslutningsveiledning
• For arkitekten (Cosmo)
• Kilder og verifisering

Introduksjon

Tillit er fundamentet for digitaliseringen av offentlig sektor. Innbyggere, næringsliv og frivillige organisasjoner må ha tillit til at offentlige virksomheter løser sine oppgaver på en god og sikker måte. Digital sikkerhet er ikke bare en teknisk forutsetning – den er en betingelse for å opprettholde samfunnets tillit til offentlig forvaltning.

For AI-løsninger stiller dette spesielle krav. AI-systemer behandler ofte sensitive personopplysninger, tar beslutninger som påvirker enkeltmenneskers rettigheter, og opererer i en kontekst der forklarbarhet og etterprøvbarhet er lovpålagt. Manglende sikkerhet i AI-løsninger kan true både personvern, rettssikkerhet og demokratiske prosesser. Samtidig må sikkerheten balanseres mot tilgjengelighet – tjenester som er så sikre at de blir ubrukelige, svekker også tilliten.

Digdirs arkitekturprinsipp for tillit og sikkerhet bygger på en helhetlig tilnærming der teknologi, organisasjon og jus samvirker. For AI-arkitekter innebærer dette å integrere sikkerhet fra tidligste designfase (security by design), følge NSMs grunnprinsipper for IKT-sikkerhet, og anvende moderne sikkerhetskonsepter som Zero Trust – samtidig som løsningene forblir brukervennlige og tjenesteorienterte.

Prinsippets kjerneinnhold

Digdirs formulering

Digitaliseringsdirektoratet (Digdir) har definert prinsipp 7: "Sørg for tillit til oppgaveløsningen" som ett av syv nasjonale arkitekturprinsipper. Dette prinsippet er obligatorisk for statlig sektor og anbefalt for kommunesektoren.

Prinsippet innebærer at:

• Innbyggere, næringsliv og frivillige organisasjoner skal ha tillit til at offentlige virksomheter løser sine oppgaver på en god og sikker måte
• Digital sikkerhet er en forutsetning for å opprettholde tillit til offentlig sektor
• Arbeidet med informasjonssikkerhet skal være risikobasert, med fleksibilitet og rom for tilpasning til virksomhetens størrelse, egenart og risiko
• Tjenester må utvikles med innebygget personvern (privacy by design) og informasjonssikkerhet må ivaretas

Forholdet til NSM grunnprinsipper

NSMs (Nasjonal sikkerhetsmyndighet) grunnprinsipper for IKT-sikkerhet er et sett med anbefalinger som utdyper hvordan virksomheter kan sikre sine informasjonssystemer. Prinsippene er relevante for alle norske virksomheter, men hovedmålgruppen er virksomheter som forvalter kritiske samfunnsfunksjoner og/eller kritisk infrastruktur.

NSMs grunnprinsipper fokuserer på teknologiske og organisatoriske tiltak og dekker:

• Identifisering og autentisering
• Tilgangsstyring og autorisasjon
• Logging og overvåking
• Sikkerhet i utvikling og drift
• Kryptering og nettverkssikkerhet
• Beredskap og gjenoppretting

For AI-løsninger er NSMs prinsipper særlig relevante fordi de:

• Krever risikobasert tilnærming (kritisk for AI med høy påvirkning)
• Fremhever logging og sporbarhet (nødvendig for AI-transparens)
• Vektlegger sikkerhet gjennom hele systemets livssyklus (fra treningsdata til produksjon)

Tillitskjeden i digitale tjenester

Tillit i digitale offentlige tjenester bygges gjennom en kjede av tillitselementer:

1. Identitetssikkerhet – Brukeren må være trygg på at tjenesten er ekte (autentisitet) og at identiteten deres er beskyttet
2. Datasikkerhet – Personopplysninger og sensitive data må beskyttes mot innsyn, endring og tap
3. Prosesssikkerhet – Beslutninger og behandling må være korrekt, konsistent og etterprøvbar
4. Juridisk sikkerhet – Tjenesten må overholde lover og forskrifter (GDPR, Forvaltningsloven, Arkivloven)
5. Teknisk sikkerhet – Infrastruktur og kode må være robust mot angrep
6. Organisatorisk sikkerhet – Virksomheten må ha kompetanse, rutiner og styring på plass

For AI-løsninger legges det til: 7. Modellsikkerhet – AI-modellen må være beskyttet mot manipulasjon, bias og utilsiktede utfall 8. Forklarbarhet – Brukere og forvaltning må kunne forstå hvordan AI-beslutninger tas

Brytes ett ledd i kjeden, svekkes tilliten til hele tjenesten.

Sikkerhetskrav for AI-løsninger

Konfidensialitet i AI-modeller

Trusler:

• Model extraction – Angriper gjenskaper modellen gjennom mange spørringer
• Training data leakage – Modellen avslører sensitiv treningsdata (spesielt i LLM-er)
• Membership inference – Angriper kan dedusere om spesifikke data var med i treningssettet

Tiltak:

• Krypter modellvekter i hvile og transit (Azure Key Vault, Managed Identity)
• Bruk differential privacy i treningsprosessen for å beskytte individuelle datapunkter
• Begrens API-tilgang med rate limiting og anomaly detection
• Vurder federated learning for å unngå sentralisering av sensitive data
• Implementer model versioning og access control (Azure ML Model Registry)

Microsoft-implementering:

• Microsoft Foundry: Managed endpoints med Azure Private Link
• Azure OpenAI: Customer-managed keys (CMK) for data encryption
• Azure Machine Learning: Network isolation med VNet/Subnet

Integritet av treningsdata

Trusler:

• Data poisoning – Angriper injiserer skadelige data i treningssettet for å manipulere modellens oppførsel
• Label flipping – Endring av merkelapper (labels) i supervised learning-data
• Backdoor attacks – Subtile mønstre legges inn for å trigge feil output under spesifikke forhold

Tiltak:

• Valider og verifiser datakvalitet før trening (Azure Data Factory, Synapse)
• Bruk immutable storage for treningsdata (Azure Blob Storage med WORM-policy)
• Implementer data lineage tracking – dokumenter herkomst, transformasjoner og bruk
• Kjør anomaly detection på treningsdata før bruk
• Versjonskontroller datasett (Azure ML Data Assets)
• Bruk content filtering på input til modeller (Azure OpenAI Content Safety)

Microsoft-implementering:

• Azure AI Search: Indexing med role-based access control (RBAC)
• Purview: Data governance og lineage tracking
• Azure OpenAI: Innebygd content filtering (prompt shields, groundedness detection)

Tilgjengelighet av AI-tjenester

Trusler:

• Denial of Service (DoS) – Angriper overbelaster AI-endepunkter
• Model inversion – Komplekse spørringer som forbruker enorme ressurser
• Resource exhaustion – Mangel på compute eller tokens i produksjon

Tiltak:

• Implementer rate limiting og quota management (Azure API Management)
• Bruk auto-scaling med øvre grenser (Azure Container Apps, AKS)
• Aktiver Azure DDoS Protection for nettverkstrafikk
• Definer SLA-er og overvåk latency/throughput (Azure Monitor, Application Insights)
• Bruk circuit breakers for å unngå kaskadesvikt
• Implementer fallback-strategier (cached responses, degraded mode)

Microsoft-implementering:

• Azure OpenAI: Provisioned Throughput Units (PTU) for garantert kapasitet
• Microsoft Foundry: Managed endpoints med auto-scaling
• Azure Front Door: Global load balancing og DDoS-beskyttelse

Sporbarhet og logging

Krav (spesielt i offentlig sektor):

• Audit trails – Hvem gjorde hva, når, og hvorfor?
• Model provenance – Hvilken modellversjon ble brukt for en gitt beslutning?
• Data lineage – Hvilke data lå til grunn for utfallet?
• Explanation logs – Hvorfor kom modellen til denne konklusjonen?

Tiltak:

• Logg alle API-kall til AI-tjenester (Azure Monitor, Application Insights)
• Lagre request/response pairs med metadata (timestamp, user ID, model version)
• Bruk correlation IDs for å spore transaksjoner på tvers av systemer
• Implementer immutable audit logs (Azure Event Hubs, Log Analytics)
• Integrer med Microsoft Sentinel for SIEM og threat detection
• Opprett dashboards for compliance-rapportering (Power BI, Azure Workbooks)

Spesielt for offentlig sektor:

• Logging må være arkivvennlig (Noark5-kompatibel ved arkivpliktige vedtak)
• Oppbevaringstid må følge Arkivloven og forskrifter
• Personopplysninger i logger må behandles i henhold til GDPR (pseudonymisering, sletting)

Microsoft-implementering:

• Azure OpenAI: Diagnostikk-logging til Log Analytics
• Microsoft Foundry: Model monitoring med data drift detection
• Purview: Compliance-rapportering og data governance

Zero Trust for AI

Prinsippene anvendt på AI

Zero Trust er en sikkerhetsstrategi som antar at brudd allerede har skjedd og verifiserer hver forespørsel som om den kom fra et ukontrollert nettverk. Regjeringen har gjennom stortingsmeldingen "Nasjonal kontroll og digital motstandskrift for å ivareta nasjonal sikkerhet – Så åpent som mulig, så sikkert som nødvendig" satt fokus på Zero Trust-modellen.

Zero Trust bygger på tre kjerneprinsipper:

1. "Never trust, always verify" – Aldri stol på, alltid verifiser
2. Least privilege access – Minste nødvendige tilgang (Just-In-Time, Just-Enough-Access)
3. Assume breach – Anta at brudd har skjedd; minimer skadeomfang

For AI-løsninger betyr dette:

1. Verify explicitly (verifiser eksplisitt)

• Autentiser og autoriser hver tilgang til AI-modeller og data basert på brukeridentitet, enhetshelse, lokasjon og risikosignaler
• Bruk Conditional Access for AI-endepunkter (krever f.eks. MFA for høy-risiko inferens)
• Valider input til modeller før prosessering (prompt injection-forsvar)

2. Use least privilege access (minste privilegium)

• Begrens tilgang til treningsdata, modeller og inferens-APIer via RBAC (Role-Based Access Control)
• Bruk Managed Identities for tjeneste-til-tjeneste-autentisering (ingen hardkodede nøkler)
• Implementer Just-In-Time (JIT) admin-tilgang for modelltrening og deployment
• Segmenter AI-workloads i egne VNets/subnets med mikrosegmentering

3. Assume breach (anta brudd)

• Krypter data i hvile og transit (TLS 1.3, customer-managed keys)
• Overvåk kontinuerlig for anomalier (uvanlige API-kall, data exfiltration)
• Implementer network segmentation for å hindre lateral movement
• Bruk immutable backups av modeller og data for gjenoppretting

Microsoft Zero Trust-modellen (Verified MCP 2026-04)

Oppdaterte Zero Trust-ressurser fra Microsoft:

• Ny adopsjonsramme: Zero Trust adoption framework (business-outcome fokusert implementering)
• Azure IaaS-spesifikk veiledning: Apply Zero Trust principles to Azure IaaS overview
• Nettverksfokus: Kryptering av all nettverkstrafikk, mikrosegmentering med NSG og Azure Firewall, avvikle legacy VPN til fordel for identitetsbaserte tilnærminger
• Confidential computing: For høysensitiv AI-workload — beskytter data under prosessering
• Ressursbeskyttelse mot destruktive angrep: Resource locks, immutable backups, geo-replication

Microsoft har utviklet en omfattende Zero Trust-arkitektur som dekker seks pilarer:

Pilar	Relevans for AI-arkitekter
Identities	Microsoft Entra ID for bruker/tjeneste-autentisering; Conditional Access for risiko-basert tilgang til AI-tjenester
Devices	Intune for enhetsstyring; kun managed devices får tilgang til sensitive AI-endepunkter
Applications	Defender for Cloud Apps overvåker AI-API-bruk; App-level RBAC for modeller
Data	Information Protection for klassifisering og kryptering av treningsdata; Purview for data governance
Infrastructure	Defender for Cloud for sikkerhetsstyring av Azure-ressurser; network micro-segmentation
Networks	Azure Firewall, Private Link, DDoS Protection; ingen implicit trust i nettverkssegmenter

AI-spesifikke Zero Trust-tiltak i Microsoft-stacken:

• Azure OpenAI: Managed Identity-autentisering, VNET-injection, Private Endpoints
• Azure AI Search: RBAC på index-nivå, network isolation, CMK-kryptering
• Azure Machine Learning: VNET-isolerte workspaces, Managed Identity for compute, private endpoints for model serving
• Copilot Studio: Data Loss Prevention (DLP), Conditional Access, audit logging

Implementering i Azure

Steg 1: Identitetsstyring

• Bruk Microsoft Entra ID som identitetsleverandør for alle AI-tjenester
• Aktiver Conditional Access med politikker basert på:
  • Brukerrisiko (Entra ID Protection)
  • Enhetsstatus (Intune compliance)
  • Lokasjon (geografisk/IP-basert)
  • Applikasjonssensitivitet (AI-modeller med PII krever MFA)

Steg 2: Nettverkssegmentering

• Opprett dedikerte VNets for AI-workloads (trening, inferens, data)
• Bruk Azure Firewall eller Network Security Groups (NSGs) for mikrosegmentering
• Aktiver Private Link for Azure OpenAI, AI Search, Storage Accounts
• Implementer hub-and-spoke-topologi med sentralisert sikkerhetskontroll

Steg 3: Datakryptering

• Bruk customer-managed keys (CMK) via Azure Key Vault for:
  • Azure Storage (treningsdata)
  • Azure OpenAI (fine-tuned modeller)
  • Azure AI Search (indexer)
• Aktiver TLS 1.3 for all data i transit
• Implementer double encryption for ekstra sensitive datasett

Steg 4: Kontinuerlig overvåking

• Integrer AI-tjenester med Microsoft Sentinel (SIEM/SOAR)
• Aktiver Defender for Cloud for posture management
• Bruk Network Watcher Traffic Analytics for nettverkssynlighet
• Implementer AI-drevet anomaly detection (Defender XDR)

Steg 5: Automatisert respons

• Opprett Logic Apps/playbooks for å automatisk:
  • Blokkere ondsinnede IP-er i Azure Firewall
  • Isolere kompromitterte enheter (Defender for Endpoint)
  • Eskalere høy-risiko AI-inferenser til security team
  • Oppdatere NSG-regler ved mistenkelig trafikk

Eksempel på Zero Trust-arkitektur for Azure OpenAI:

User (Entra ID + Conditional Access)
  ↓ (MFA, device compliance, location check)
Azure Front Door (DDoS, WAF)
  ↓ (Private Link)
Azure OpenAI (VNet-injected, Managed Identity)
  ↓ (RBAC, Private Endpoint)
Azure AI Search (CMK-encrypted index)
  ↓ (Managed Identity)
Azure Storage (WORM-enabled treningsdata)
  ↓
Microsoft Sentinel (logging, threat detection)

Beslutningsveiledning

Når skal jeg anvende Zero Trust-prinsipper for AI?

Scenario	Zero Trust nødvendig?	Rasjonale
AI-modell bruker personopplysninger (helseopplysninger, økonomi, personnummer)	JA	GDPR art. 32 krever tekniske tiltak; Zero Trust oppfyller "tilstrekkelig sikkerhet"
AI-modell tar automatiserte beslutninger med rettslig virkning (f.eks. tildeling av ytelser)	JA	GDPR art. 22 og Forvaltningsloven krever sporbarhet og rettssikkerhet
AI-tjeneste er eksponert eksternt (API, web app)	JA	Angrepsflate mot internett; implicit trust er høyrisiko
AI-workload kjører i multi-tenant-miljø (delte ressurser)	JA	Risiko for data leakage mellom tenants
Intern AI-tool for ikke-kritiske oppgaver (f.eks. meeting summaries)	Delvis	Start med Managed Identity og RBAC; full Zero Trust hvis data-klassifisering øker
Eksperimentell AI-modell i sandkasse-miljø (isolert, ingen produksjonsdata)	Delvis	Implementer basis-sikkerhet (Managed Identity, network isolation); full Zero Trust ved produksjonssetting

Beslutningstabell: Valg av sikkerhetstiltak

Krav	Tiltak	Microsoft-tjeneste
Beskytte treningsdata mot uautorisert tilgang	RBAC + Private Link + CMK	Azure Storage + Key Vault
Forhindre model extraction	Rate limiting + anomaly detection	Azure API Management + Defender for Cloud
Sikre API-autentisering	Managed Identity + Conditional Access	Entra ID + Azure OpenAI
Logge AI-beslutninger for etterprøvbarhet	Audit logging + immutable storage	Log Analytics + Event Hubs
Beskytte mot prompt injection	Input validation + content filtering	Azure OpenAI Content Safety
Hindre data leakage i LLM-svar	Groundedness detection + PII redaction	Azure OpenAI (prompt shields) + Purview
Opprettholde tilgjengelighet under angrep	DDoS Protection + auto-scaling	Azure Front Door + PTU (OpenAI)
Overvåke og respondere på trusler	SIEM + automated playbooks	Microsoft Sentinel + Logic Apps

Vanlige feil å unngå

Feil 1: "AI-modellen kjører i Azure, så den er automatisk sikker"

• Realitet: Azure tilbyr sikkerhetsfunksjoner, men du må aktivere og konfigurere dem (shared responsibility model)
• Løsning: Bruk Defender for Cloud til å identifisere sikkerhetsgap; følg Azure Security Benchmark

Feil 2: "Vi trenger ikke logging fordi modellen bare gir anbefalinger, ikke beslutninger"

• Realitet: Offentlig sektor har loggeplikt for alle automatiserte prosesser som påvirker saksbehandling (Forvaltningsloven § 11)
• Løsning: Implementer audit logging selv for advisory AI; vurder arkivplikt med jurist

Feil 3: "Vi bruker API-nøkler for autentisering – det er trygt nok"

• Realitet: API-nøkler i kode/config er en topp-10 sikkerhetsrisiko; kan lekke via GitHub, logs, etc.
• Løsning: Bytt til Managed Identity; roter eksisterende nøkler via Key Vault

Feil 4: "Vi kjører AI-modell og database i samme VNet, så nettverkssikkerhet er god"

• Realitet: Flat nettverksarkitektur tillater lateral movement ved brudd
• Løsning: Implementer mikrosegmentering med NSGs; least privilege network access

Feil 5: "Zero Trust er for komplisert for vår lille virksomhet"

• Realitet: Zero Trust skalerer; start med grunnleggende tiltak (Managed Identity, RBAC, MFA)
• Løsning: Bruk Microsoft Security Copilot til å identifisere quick wins; implementer inkrementelt

Feil 6: "Vi trenger ikke å kryptere data fordi vi har godt nettverk-perimeter"

• Realitet: Perimeter-basert sikkerhet er foreldet; brudd skjer innenfor nettverket
• Løsning: Krypter data i hvile (CMK) og transit (TLS 1.3); anta at nettverket er kompromittert

For arkitekten (Cosmo)

Når du designer AI-løsninger for norsk offentlig sektor, bruk disse spørsmålene for å vurdere tillit og sikkerhet:

Identitet og tilgangsstyring

1. Hvordan autentiseres brukere og tjenester? (API-nøkler, Managed Identity, Entra ID?)
2. Bruker løsningen Conditional Access for risiko-basert tilgang? (Hvilket risikonivå kreves for MFA?)
3. Er RBAC implementert med least privilege? (Hvem har tilgang til treningsdata, modeller, logs?)
4. Hvordan roteres og lagres hemmeligheter? (Key Vault, auto-rotation?)

Datasikkerhet

5. Hvor lagres treningsdata, og hvordan beskyttes de? (Kryptering i hvile? WORM-enabled?)
6. Inneholder treningsdata personopplysninger? (Hvis ja: DPIA gjennomført? Behandlingsgrunnlag?)
7. Hvordan sikres data lineage og provenance? (Purview, Azure ML Data Assets?)
8. Er det implementert tiltak mot data poisoning? (Validering, versjonskontroll, anomaly detection?)

Modellsikkerhet

9. Hvordan beskyttes modellen mot extraction/inversion-angrep? (Rate limiting, differential privacy?)
10. Er fine-tuned modeller kryptert med customer-managed keys? (CMK via Key Vault?)
11. Hvordan oppdages og håndteres model drift? (Azure Monitor, Responsible AI Dashboard?)
12. Er det implementert fallback-strategi ved modellsvikt? (Cached responses, manual override?)

Nettverks- og infrastruktursikkerhet

13. Er AI-workloads nettverksisolerte? (VNet, Private Link, NSGs?)
14. Bruker løsningen hub-and-spoke-topologi? (Sentralisert firewall/sikkerhetskontroll?)
15. Er DDoS Protection aktivert? (Azure Front Door, Azure DDoS Protection?)
16. Hvordan håndteres lateral movement ved brudd? (Mikrosegmentering, Zero Trust-nettverk?)

Logging og sporbarhet

17. Logges alle AI-inferenser med tilstrekkelig metadata? (User ID, timestamp, model version, input/output?)
18. Er audit logs immutable og arkivvennlige? (Event Hubs, Noark5-integrasjon?)
19. Hvor lenge lagres logger? (Oppfyller Arkivloven og GDPR?)
20. Er logging integrert med SIEM for threat detection? (Microsoft Sentinel, Defender XDR?)

Overvåking og respons

21. Hvilke sikkerhetsindikatorer overvåkes? (Anomalier i API-bruk, data exfiltration, prompt injection-forsøk?)
22. Er det definert playbooks for automatisert respons? (Logic Apps, Sentinel playbooks?)
23. Hvordan testes beredskap for AI-sikkerhetsbrudd? (Red team-øvelser, penetrasjonstesting?)
24. Hvem varsles ved sikkerhetshendelser? (Security Operations Center, dataansvarlig, Datatilsynet?)

Compliance og governance

25. Er det gjennomført DPIA for AI-løsningen? (Vurdert risiko for personvern?)
26. Overholder løsningen NSMs grunnprinsipper? (Hvilke prinsipper er implementert?)
27. Er det utarbeidet ROS-analyse? (Risiko- og sårbarhetsanalyse?)
28. Hvordan dokumenteres sikkerhetsarkitekturen? (ADR-er, arkitekturdiagrammer?)

Zero Trust-modenhet

29. Hvilken Zero Trust-modenhet har løsningen? (Tradisjonell, avansert, optimal?)
30. Hvilke av de tre Zero Trust-prinsippene er implementert? (Verify explicitly, least privilege, assume breach?)
31. Er det identifisert legacy-komponenter som må fasøes ut? (VPN, statiske firewalls, hardkodede nøkler?)
32. Hvordan måles og forbedres Zero Trust-modenhet over tid? (Security scorecard, kontinuerlig forbedring?)

Kilder og verifisering

Norske myndigheter

• Digdir: Overordnede arkitekturprinsipper
• Digdir: Felles sikkerhet i forvaltningen
• Digdir: NSMs grunnprinsipper
• NSM: Grunnprinsipper for IKT-sikkerhet
• NSM: Grunnprinsipper for IKT-sikkerhet v2.1 (PDF)
• Helsedirektoratet: Zero Trust-modellen – et paradigmeskifte innen digital sikkerhet?
• Regjeringen: Én digital offentlig sektor

Microsoft dokumentasjon

• Microsoft Security: Zero Trust
• Microsoft Learn: Zero Trust security in Azure (Verified MCP 2026-04)
• Microsoft Learn: Secure networks with SASE, Zero Trust, and AI
• Microsoft Learn: Innovate and automate using AI services (security)
• Microsoft Learn: Zero Trust partner kit resources

Norske konsulentselskap (kontekstualisering)

• PwC: Sikkerhetsarkitektur og Zero Trust-strategi
• PwC: Zero Trust-arkitektur: gjør det skyen din sikrere?
• Avoki: Implementere Zero Trust-arkitektur
• Serit: Zero Trust: En fremtidsrettet tilnærming til IT-sikkerhet

Sist verifisert: 2026-06-19