Microsoft Sovereign Cloud: velg suverenitet per workload

Microsoft la 20. oktober frem en oppdatert strategi for digital suverenitet, og mange leser Microsoft Sovereign Cloud som et valg mellom offentlig sky og eget datasenter. Slik jeg ser det, handler den om noe mer nyttig: å velge riktig kontrollnivå for hver enkelt workload. Her får du en praktisk oversikt over modellene, styringskontrollene og begrensningene som gjemmer seg i dokumentasjonen, med kommandoer du kan kjøre i tenant-en din i dag.

Ett nivå for alt fungerer sjelden

Microsofts blogginnlegg beskriver en tilnærming der kontrollen skrus opp og ned for hver arbeidsbelastning. Jeg mener det er rett retning, fordi kravene til et internt dokumentverktøy og et pasientregister sjelden er like. Cloud Adoption Framework (CAF) skiller mellom tre varianter: Sovereign Public Cloud, Sovereign Private Cloud og National Partner Cloud (NPC). Jeg forkorter de to første til Public og Private. Rammeverket sier at de fleste organisasjoner starter med Public og tar i bruk de andre først når en applikasjon har ekstra behov. Jeg vil anbefale å lese det som en prislapp også, ettersom strengere kontroll koster mer, og Private legger infrastruktur og drift på deg. Fundamentet for Public har jeg beskrevet i Hva er offentlig sky. Tabellen under er min forenklede tolkning av CAF-beslutningstreet.

Type system	Variant	Utgangspunkt
Internt verktøy uten sensitive opplysninger	Public	Vanlig ALZ
Persondata som må bli innenfor et bestemt område	Public	Lokalitet og kryptering (L1 og L2)
Informasjon som også må beskyttes mens den brukes	Public	Confidential-soner (L1 til L3)
Drift uten forbindelse til Azure	Private	Azure Local, disconnected
Nasjonale krav til lokal operatør	NPC	Bleu i Frankrike, Delos i Tyskland

Isolasjon er ikke nok

CAF understreker at begrepet er en delmengde av etterlevelse, og at det ikke oppnås gjennom isolasjon alene. Ansvarsdelingen mellom deg og Microsoft er dessuten ulik i hver variant, så jeg synes første øvelse bør være å skrive ned hvem som eier hvilken kontroll. Veien dit går i tre faser: planlegging og beredskap, arkitektur og styring, og til slutt driftsstandarder. Min erfaring er at team som hopper rett til arkitekturen, må tilbake og gjøre klassifiseringen på nytt.

Tre kontrollnivåer i policy as code

Sovereign Landing Zone (SLZ) er en egenrådig utgave av Azure Landing Zone (ALZ) med policy as code, som finnes i både Bicep og Terraform. Under management group-en Landing Zones legges tre nye grupper: Public, Confidential Corp og Confidential Online. Kontrollene deles i tre nivåer, og jeg synes inndelingen er det mest konkrete i hele pakken.

L1: datalokalitet
L2: kryptering i hvile og under overføring
L3: confidential computing, altså beskyttelse mens dataene brukes

Gruppene knyttes til nivåene slik, og jeg liker å bruke tabellen som utgangspunkt for å koble styringen til sensitivitet.

Gruppe	Kontrollnivå
Public	Grunnpolicyene fra ALZ
Online og Corp	L1 og L2
Confidential Online og Confidential Corp	L1, L2 og L3

I tillegg får SLZ en egen sikkerhetsgruppe og et eget abonnement, der Managed HSM ligger. Globale og flerregionale tjenester kan kreve dokumenterte unntak fra lokalitetskravet. Jeg foreslår å føre slike unntak i en separat logg fra dag én.

Godkjenning av fjerntilgang

Microsoft lanserer Sovereign Control Panel i public preview under Ignite, som arrangeres 17. til 20. november i San Francisco. Innlegget nevner også just-in-time-tilgang og Customer Lockbox, som krever en Azure-supportplan på minst Developer-nivå. Data Guardian går lenger: en betrodd partner i EU gir europeisk tilsyn med kvalifiserende fjerntilgang fra ingeniører hos Microsoft, og ifølge dokumentasjonen godkjennes og overvåkes tilgangen av personell bosatt i EU og EFTA. Hendelsene logges i en manipuleringssikker ledger bygget på Azure confidential ledger. Ifølge Microsoft rulles både Data Guardian og Production Touch Ledger ut gradvis i samme område, og Norge er med i EFTA. Slik jeg ser det er dette den mest relevante nyheten for norske virksomheter. Jeg anbefaler likevel å sjekke hvilke områder og tjenester som faktisk dekkes før du bygger en vurdering på det, særlig for personopplysninger. Det temaet tar jeg for meg i guiden til GDPR i norske virksomheter.

EKM i Managed HSM har en pris

Ekstern nøkkelhåndtering (EKM) i Managed HSM er, slik både Microsoft-bloggen og Learn skriver det, generelt tilgjengelig, mens Private Link-integrasjonen ennå ikke er GA. Microsoft omtaler EKM som en siste utvei og ikke en generell oppgradering, og etter min mening er det den viktigste nyansen i hele kunngjøringen. Begrensningene er tydelige:

Ingen ende-til-ende-SLA for EKM-proxyen eller den eksterne HSM-en, og du må regne med ekstra ventetid
Geo-replikering og backup/restore støttes ikke
Secure Key Release og diskkryptering for confidential VM-er som må ha det, støttes ikke

Støttede leverandører er Entrust, Eviden, Fortanix, Futurex, Securosys, Thales og Utimaco. Funksjonen må registreres per abonnement, og jeg foreslår å gjøre det i et testabonnement først. Gjenta den siste kommandoen til tilstanden viser Registered.

az feature register --namespace Microsoft.KeyVault --name MHSM_EKM --subscription "$SUBSCRIPTION_ID"
az feature show --namespace Microsoft.KeyVault --name MHSM_EKM --subscription "$SUBSCRIPTION_ID" --query properties.state --output tsv

Siden om EKM i Sovereign Public Cloud omtaler fortsatt funksjonen som forhåndsvisning. Jeg anbefaler å bekrefte status mot Managed HSM-siden og blogginnlegget før du lover noe til compliance-teamet.

Azure Local: privat sky uten nettforbindelse

Private bygger på Azure Local, der du kjører VM-er eller AKS Arc på maskinvare du eier. Microsoft lister mange nyheter, og jeg liker å sortere dem etter modenhet:

SQL Server på Azure Local: GA
DocumentDB, Blob Storage og overgangen fra tilkoblet til frakoblet modus: public preview
GitHub Enterprise Local: GA på konferansen, med GitHub Copilot mot lokalt hostede modeller
Foundry Local: GA på konferansen, for både tilkoblet og frakoblet modus
Microsoft 365 Local: forhåndsvisning for godkjente kunder
Confidential VM-er: GA etter Microsoft-bloggen, men dokumentasjonssiden har fortsatt (preview) i tittelen

Den siste linjen er grunnen til at jeg vil anbefale å følge Learn til sidene stemmer overens. Disconnected operations har dessuten tydelige krav: en kvalifisert avtale (MOSA gjelder ikke), supportplan på Standard eller høyere, et dokumentert forretningsbehov, egen driftsorganisasjon eller en samarbeidspartner, Premier Solutions-maskinvare og en dedikert klynge for administrasjon. Forhåndskvalifiseringen besvares innen ti virkedager. Det overrasker meg ikke at dette passer for et fåtall systemer. Azure Local har månedlige releaser, som jeg har gått gjennom i sjekklisten for oppgradering av Azure Local, så oppdateringsrutinen må være på plass fra start.

Kartlegg utgangspunktet med Resource Graph

Før du velger modell trenger du et bilde av hvor ressursene ligger i dag. Jeg pleier å starte med Azure Resource Graph, fordi spørringene går på tvers av abonnementene du har tilgang til.

Den første spørringen teller ressurser per region, og den andre lister Managed HSM-er med region og ressursgruppe. Min erfaring er at spredningen i regioner avgjør hvor mye arbeid L1 blir.

az extension add --name resource-graph
az graph query --graph-query "Resources | summarize antall = count() by location | order by antall desc"
az graph query --graph-query "Resources | where type =~ 'microsoft.keyvault/managedhsms' | project name, location, resourceGroup"

Slik ville jeg startet

Klassifiser systemene etter datasensitivitet og behov for datalokalitet.
Start med Public, og dokumenter hvorfor en arbeidsbelastning krever mer.
Kartlegg regioner og Managed HSM-er med Resource Graph.
Følg Ignite 17. til 20. november for status på funksjonene som ikke er GA ennå.

Jeg mener valgene blir lettere å forsvare når hver beslutning har en skriftlig begrunnelse. Trenger du hjelp til å plassere systemene dine i passende modell? Ta kontakt på kontakt@jas-azure.com, så ser vi på det sammen.