open/ktg-plugin-marketplace
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity Actions

feat(ms-ai-architect): add plugin to open marketplace (v1.5.0 baseline)

Browse source 
Initial addition of ms-ai-architect plugin to the open-source marketplace.
Private content excluded: orchestrator/ (Linear tooling), docs/utredning/
(client investigation), generated test reports and PDF export script.
skill-gen tooling moved from orchestrator/ to scripts/skill-gen/.

Security scan: WARNING (risk 20/100) — no secrets, no injection found.
False positive fixed: added gitleaks:allow to Python variable reference
in output-validation-grounding-verification.md line 109.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Kjell Tore Guttormsen 2026-04-07 17:17:17 +02:00
commit 6a7632146e
490 changed files with 213249 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

285
plugins/ms-ai-architect/skills/ms-ai-infrastructure/references/bcdr/compliance-requirements-bcdr.md Normal file
View file

@ -0,0 +1,285 @@
# Compliance Requirements for BCDR in Norwegian Public Sector
**Last updated:** 2026-02
**Status:** GA
**Category:** Business Continuity & Disaster Recovery
---
## Introduksjon
Norske offentlige organisasjoner som bruker AI-tjenester i Azure er underlagt et komplekst regulatorisk landskap for Business Continuity and Disaster Recovery. Kravene kommer fra nasjonale lover (Forvaltningsloven, Sikkerhetsloven), EU-forordninger (GDPR, AI Act), sektorkrav (NSM, Digdir) og internasjonale standarder (ISO 22301, ISO 27001).
BCDR for AI-systemer i offentlig sektor har særlige utfordringer: data residency-krav begrenser hvilke Azure-regioner som kan brukes for DR, taushetsplikt stiller krav til kryptering og tilgangskontroll også i DR-scenarier, og Utredningsinstruksens krav til konsekvensanalyse påvirker hvordan DR-strategier velges og dokumenteres.
Denne referansen sammenfatter de viktigste regulatoriske kravene og gir praktisk veiledning for hvordan de påvirker BCDR-design for AI-løsninger i Azure.
## Forvaltningslovens krav til kontinuitet
### Relevant lovgivning
| Lov/forskrift | Krav | Påvirkning på BCDR |
|---------------|------|-------------------|
| Forvaltningsloven §11a | Forsvarlig saksbehandlingstid | AI-systemer som støtter saksbehandling må ha definert RTO |
| Forvaltningsloven §13 | Taushetsplikt | DR-data må krypteres, tilgang begrenses |
| eForvaltningsforskriften §15 | Tilgang til elektroniske tjenester | Digitale tjenester skal være tilgjengelige |
| Arkivlova §6 | Bevaring av arkivmateriale | AI-generert innhold kan være arkivverdig |
| Offentleglova §6 | Innsynskrav | AI-systemer må kunne levere data for innsyn |
### Krav til konsekvensanalyse
Utredningsinstruksen (KMD 2016) krever at statlige tiltak utredes før beslutning. For BCDR betyr dette:
```markdown
## Konsekvensutredning for BCDR-strategi
### 1. Problem og mål
- Hva er risikoen ved manglende DR for AI-systemet?
- Hva er målet med DR-strategien (RTO/RPO)?
### 2. Alternativer
| Alternativ | RTO | RPO | Årlig kostnad | Risiko |
|-----------|-----|-----|---------------|--------|
| 0: Ingen DR | N/A | N/A | 0 kr | Høy — fullstendig tjenestebortfall |
| 1: Backup & Restore | 24t | 24t | 50,000 kr | Middels — lang nedetid |
| 2: Warm Standby | 15 min | 5 min | 300,000 kr | Lav — kort nedetid |
| 3: Active-Active | ~0 | ~0 | 600,000 kr | Svært lav — nær null nedetid |
### 3. Konsekvenser
- Økonomiske: Kostnad ved nedetid vs. DR-kostnad
- Administrative: Krav til bemanning og prosedyrer
- Samfunnsmessige: Påvirkning på brukere av offentlige tjenester
### 4. Anbefaling
[Anbefalt alternativ med begrunnelse]
```
## GDPR og data residency-krav
### GDPR Artikkel 32 — Sikkerhet ved behandling
GDPR krever "evnen til å sikre vedvarende konfidensialitet, integritet, tilgjengelighet og robusthet" for behandlingssystemer. For BCDR betyr dette:
| GDPR-krav | BCDR-implikasjon | Azure-tiltak |
|-----------|-----------------|--------------|
| Art. 32(1)(b) | Tilgjengelighet og robusthet | Multi-region DR |
| Art. 32(1)(c) | Evne til å gjenopprette tilgang | Definerte RTO/RPO |
| Art. 32(1)(d) | Regelmessig testing av sikkerhetstiltak | DR-drills |
| Art. 32(2) | Risikobasert tilnærming | BIA som grunnlag for DR |
### Data Residency og geo-replikering
```markdown
## Godkjente Azure-regioner for norsk offentlig sektor
### Primærregioner (anbefalt)
- Norway East (Oslo) — Norsk datasuverenitetsregion
- Norway West (Stavanger) — Sekundær norsk region
### Sekundærregioner (DR, godkjent EU/EØS)
- Sweden Central (Gävle) — Typisk DR-region for Norway East
- North Europe (Dublin) — Alternativ EU-region
- West Europe (Amsterdam) — Alternativ EU-region
### Ikke godkjent uten tilleggsanalyse
- UK-regioner — Etter Brexit, krever separat vurdering
- US-regioner — Schrems II-problematikk
- APAC-regioner — Ikke relevant for offentlig sektor
```
### Overføringsmekanismer for DR-data
| Scenario | Overføringsmekanisme | Krav |
|----------|---------------------|------|
| Norway East → Sweden Central | EU/EØS intern | Ingen tilleggstiltak |
| Norway East → UK | SCCs + TIA | Tilleggsanalyse |
| Azure GRS (automatisk) | Avhenger av region-par | Verifiser at sekundær er EU/EØS |
| Backup til annen region | GDPR Art. 46 | Dokumentér overføringsgrunnlag |
### DPIA for BCDR
```markdown
## DPIA — BCDR-spesifikke vurderinger
### Tilgjengelighetsvurdering
- Hva er konsekvensen for registrerte ved tap av tilgang til AI-systemet?
- Kan vedtak fattes manuelt som fallback?
- Finnes det risiko for diskriminering ved degradert AI-funksjonalitet?
### Data i transit
- Er all DR-replikering kryptert (TLS 1.2+)?
- Går data gjennom tredjeland under replikering?
- Finnes det logger over alle dataoverføringer?
### Tredjepartstilgang
- Har Microsoft tilgang til data i DR-regionen?
→ Ja, men begrenset av Customer Lockbox og JIT
- Er det andre behandlere involvert i DR-prosessen?
→ Dokumentér i databehandleravtale
### Tiltak
| Risiko | Tiltak | Ansvarlig |
|--------|--------|-----------|
| Data i feil region | Verifiser GRS-konfiguration | Platform team |
| Ukryptert replikering | Enforce TLS i transit | Security team |
| Tap av tilgangskontroll | RBAC i DR-region | IAM team |
```
## NSMs sikkerhetsveiledninger for kritisk infrastruktur
### NSMs grunnprinsipper relevante for BCDR
| Prinsipp | Krav | BCDR-tiltak |
|----------|------|-------------|
| 2.1 Kartlegg leveranser, systemer og avhengigheter | Forstå AI-systemets avhengigheter | Avhengighetskartlegging for alle AI-komponenter |
| 2.2 Klassifiser virksomhetens verdier | Vurder kritikalitet av AI-data | BIA med klassifisering |
| 2.3 Risikovurder virksomhetens digitale verdier | ROS-analyse | Inkluder tilgjengelighetstrusler |
| 3.1 Beskytt virksomhetens verdier | Sikkerhet i DR-miljø | Identisk sikkerhetskonfigurasjon |
| 4.1 Logg og overvåk | Loggføring også under DR | Sentralisert logging cross-region |
| 4.3 Planlegg for å håndtere hendelser | Hendelseshåndtering | Runbooks og kommunikasjonsplaner |
### NSMs krav til beredskapsplanlegging
```markdown
## Beredskapskrav for AI-systemer (NSM)
1. **Risikovurdering (ROS)**
- Identifiser trusler mot AI-systemets tilgjengelighet
- Vurder sannsynlighet og konsekvens
- Definer akseptabelt risikonivå
2. **Beredskapsplan**
- Dokumenterte gjenopprettingsprosedyrer
- Definerte roller og ansvar
- Kommunikasjonsprosedyrer
- Eskaleringsrutiner
3. **Øvelser**
- Minimum årlig fullskala DR-øvelse
- Kvartalsvis tabletop-øvelse
- Dokumentasjon av resultater og forbedringstiltak
4. **Rapportering**
- Avviksrapportering til leder
- Sikkerhetshendelsesrapportering til NSM/NCSC
- Årlig statusrapport til ledelsen
```
## Sektorspesifikke reguleringer
### Helse (Normen)
| Krav | Beskrivelse | BCDR-implikasjon |
|------|-------------|-----------------|
| Tilgjengelighet | Kritiske systemer: 99.5% uptime | Multi-AZ minimum |
| Gjenoppretting | RTO < 4 timer for kritiske | Warm standby |
| Personvern | Helseopplysninger er sensitive | Kryptering i alle regioner |
| Logging | All tilgang til pasientdata logges | Cross-region logging |
### Finans (Finanstilsynet)
| Krav | Beskrivelse | BCDR-implikasjon |
|------|-------------|-----------------|
| IKT-forskriften §4 | Adekvat IKT-beredskap | Dokumentert DR-plan |
| IKT-forskriften §7 | Drift og overvåking | 24/7 monitoring |
| DORA (EU) | Digital Operational Resilience | Regelmessig DR-testing |
### Kommunal sektor
| Krav | Beskrivelse | BCDR-implikasjon |
|------|-------------|-----------------|
| Kommuneloven §25-1 | Internkontroll | BCDR som del av IK |
| Digitaliseringsrundskrivet | Digital tilgjengelighet | Definerte SLA |
| KS anbefalinger | IKT-sikkerhet i kommuner | Praktisk veiledning |
## Audit og dokumentasjonskrav
### Påkrevd dokumentasjon
```markdown
## BCDR Dokumentasjonspakke for Audit
### 1. Strategidokument
- [ ] BCDR-policy godkjent av ledelsen
- [ ] Kritikalitetsklassifisering av AI-systemer
- [ ] RTO/RPO-mål per system/komponent
- [ ] Valgt DR-strategi med begrunnelse
### 2. Teknisk dokumentasjon
- [ ] Arkitekturtegning med DR-konfigurasjon
- [ ] Nettverksdiagram inkl. failover-ruter
- [ ] Data flow diagram med replikering
- [ ] Konfigurasjonsdetaljer per Azure-tjeneste
### 3. Operasjonell dokumentasjon
- [ ] DR-runbooks (failover og failback)
- [ ] Eskaleringsmatrise
- [ ] Kommunikasjonsplan
- [ ] Kontaktliste (primær og backup)
### 4. Test og verifisering
- [ ] DR-testplan med frekvens og omfang
- [ ] Testrapporter fra gjennomførte DR-drills
- [ ] Avvikslogg med korrigerende tiltak
- [ ] Måloppnåelse (faktisk vs. planlagt RTO/RPO)
### 5. Compliance-dokumentasjon
- [ ] DPIA med BCDR-vurderinger
- [ ] Databehandleravtale som dekker DR
- [ ] Overføringsgrunnlag for cross-region data
- [ ] Årlig compliance-rapport
```
### Revisjons-sjekkliste
```markdown
## Årlig BCDR Revisjons-sjekkliste
### Governance
| # | Kontrollpunkt | Status | Kommentar |
|---|---------------|--------|-----------|
| 1 | BCDR-policy er oppdatert og godkjent | ☐ | |
| 2 | Roller og ansvar er dokumentert | ☐ | |
| 3 | Ledelsen er informert om DR-status | ☐ | |
### Teknisk
| # | Kontrollpunkt | Status | Kommentar |
|---|---------------|--------|-----------|
| 4 | DR-konfigurasjon matcher dokumentasjon | ☐ | |
| 5 | Replikering fungerer korrekt | ☐ | |
| 6 | Backup er verifisert | ☐ | |
| 7 | IaC-maler er oppdatert | ☐ | |
### Testing
| # | Kontrollpunkt | Status | Kommentar |
|---|---------------|--------|-----------|
| 8 | Fullskala DR-test gjennomført siste 12 mnd | ☐ | |
| 9 | RTO-mål oppnådd i test | ☐ | |
| 10 | RPO-mål oppnådd i test | ☐ | |
| 11 | Forbedringstiltak implementert | ☐ | |
### Compliance
| # | Kontrollpunkt | Status | Kommentar |
|---|---------------|--------|-----------|
| 12 | GDPR-krav ivaretatt i DR | ☐ | |
| 13 | Data residency verifisert | ☐ | |
| 14 | NSM-krav etterlevd | ☐ | |
| 15 | Sektorspesifikke krav dekket | ☐ | |
```
## Referanser
- [Azure for secure worldwide public sector cloud adoption](https://learn.microsoft.com/en-us/azure/azure-government/documentation-government-overview-wwps) — Data residency og compliance
- [Support your GDPR program with Accountability Readiness Checklists](https://learn.microsoft.com/en-us/compliance/regulatory/gdpr-arc) — GDPR compliance
- [Geographic data residency in Copilot Studio](https://learn.microsoft.com/en-us/microsoft-copilot-studio/geo-data-residency) — Data residency for Copilot
- [Recommendations for defining reliability targets](https://learn.microsoft.com/en-us/azure/well-architected/reliability/metrics) — SLO/RTO/RPO-definisjoner
- [Azure compliance offerings](https://learn.microsoft.com/en-us/azure/compliance/) — Azure compliance-dokumentasjon
- [NSM — Grunnprinsipper for IKT-sikkerhet](https://nsm.no/grunnprinsipper-ikt) — Norske sikkerhetskrav
## For Cosmo
- **Bruk denne referansen** når kunden er en norsk offentlig organisasjon og trenger veiledning om regulatoriske krav til BCDR for AI-systemer.
- Start alltid med å identifisere hvilke sektorkrav som gjelder (helse, finans, kommunal, statlig) — dette påvirker RTO/RPO-krav direkte.
- Data residency er en showstopper: ALDRI foreslå DR-regioner utenfor EU/EØS for norsk offentlig sektor uten eksplisitt juridisk vurdering.
- Påminn om at GDPR Art. 32 eksplisitt nevner tilgjengelighet — mangelfull BCDR kan være et GDPR-brudd.
- Utredningsinstruksens krav til alternativanalyse betyr at kunden bør evaluere minst 3 BCDR-alternativer med kost/nytte-vurdering.