Microsoft har i august 2026 gjort noe selskapet ikke har gjort før: gitt containerklynger på Amazon og Google akkurat samme sikkerhetsdekning som Azure-egne klynger får. Oppdateringen av Microsoft Defender for Cloud, publisert i utgivelsesnotatene 18. august 2026, utvider sårbarhetsskanning av Kubernetes-noder og kjøretidsoppdagede containerbilder til Amazon EKS og Google GKE. Microsoft omtaler dette som paritet med eksisterende AKS-funksjonalitet. For IT- og sikkerhetsansvarlige i Norge og Norden, hvor de fleste mellomstore og store virksomheter i dag kjører arbeidslaster på minst to skyer samtidig, er dette mer enn en teknisk fotnote. Det er et signal om hvor hele markedet for skysikkerhet er på vei.
Hva Microsoft faktisk annonserte i august 2026
Kjernen i oppdateringen er enkel å beskrive, men stor i praksis. Defender for Cloud skanner nå Kubernetes-noder for sårbarheter på Amazon EKS og Google GKE på samme måte som på Azure Kubernetes Service. I tillegg er vurdering av kjøretidsoppdagede containerbilder utvidet til de samme to plattformene, ifølge Microsofts offisielle utgivelsesnotater. Før dette måtte team som kjørte klynger på flere skyer, stykke sammen sikkerhetsbildet manuelt ved å kombinere Defender for Azure, GuardDuty for AWS og Security Command Center for Google Cloud.
Microsofts kundenyhetsbrev for august 2026 lister flere funksjoner som samtidig gikk til generell tilgjengelighet: containernivå-anbefalinger for feilkonfigurasjon i Kubernetes, anbefalinger om å oppgradere AKS-versjon, og sårbarhetsvurdering for kjøretidsoppdagede containerbilder på både EKS og GKE. Alt dette samler seg i ett og samme oppsett i portalen, uansett hvilken sky klyngen faktisk kjører på.
Det viktigste ordet i annonseringen er paritet. Microsoft sier ikke at AWS- og Google-klynger får en forenklet versjon av sikkerhetsverktøyet. De sier klyngene får det samme verktøyet, med samme dybde, som Azures egne klynger allerede hadde. Det er en påstand som vil bli testet raskt av sikkerhetsteam som migrerer over de kommende månedene.
Fra Azure-only til ekte multisky-dekning: en kort historikk
Dette er ikke Microsofts første forsøk på å bryte ut av Azure-boblen. Ifølge Microsofts eget arkiv over utgivelsesnotater ble native multisky-tilkoblinger for AWS og GCP generelt tilgjengelig allerede i mars 2022, uten ekstra kostnad. Det ga Defender for Cloud et første grep om ressurser utenfor Azure, men dekningen var i praksis grunnere enn på hjemmebane.
Neste steg kom i februar 2024, da Microsoft rullet ut Defender CSPM sin kontekstuelle sikkerhetsgraf og angrepsbaneanalyse med støtte for GCP-ressurser, denne gangen med fakturering knyttet til bruken. Det ga bedre oversikt over hvordan feilkonfigurasjoner i én sky kunne kjede seg sammen til reelle angrepsveier, men fortsatt uten den dype containerinnsikten som AKS-brukere hadde.
August 2026-oppdateringen lukker det siste og mest tekniske gapet: selve container- og Kubernetes-laget. Sett i sammenheng er dette den tredje store etappen i en fireårig reise fra et Azure-sentrisk verktøy til noe som ligner mer på en reell multisky-sikkerhetsplattform. Konkurrenter som Wiz, Palo Alto Networks og CrowdStrike har bygget hele forretningsmodellen sin på nettopp denne multisky-tanken fra dag én, så Microsofts vei har vært en innhenting like mye som en innovasjon.
| Tidspunkt | Hva som skjedde | Betydning |
|---|---|---|
| Mars 2022 | Native multisky-tilkoblinger for AWS og GCP, generelt tilgjengelig | Første reelle steg utenfor Azure, kostnadsfritt |
| Februar 2024 | Defender CSPM kontekstuell graf og angrepsbaneanalyse for GCP | Bedre oversikt på tvers av skyer, nå med fakturering |
| 6. august 2026 | Skanning av spesifikke blober, filer, containere og fildelinger | Bredere skadevare-skanning i forhåndsvisning |
| 18. august 2026 | Sårbarhetsvurdering for containernoder og kjøretidsbilder på EKS og GKE | Full paritet med AKS oppnådd |
| 18. august 2026 | Oppdagelse og holdning for serverløse containere generelt tilgjengelig | Dekker også ECS Fargate, Container Apps og Container Instances |
Slik fungerer sårbarhetsskanning på Amazon EKS og Google GKE
Rent teknisk krever den nye dekningen at AWS- og GCP-kontoer allerede er koblet til Defender for Cloud gjennom multisky-connectorne fra 2022. Når klyngen er registrert, begynner Defender å skanne Kubernetes-vertsnoder for kjente sårbarheter på samme måte som på en AKS-node, altså agentløst og uten at teamet må installere noe ekstra i selve klyngen for grunnleggende dekning.
Den andre delen, vurdering av kjøretidsoppdagede containerbilder, er mer interessant fordi den fanger opp bilder som faktisk kjører i klyngen akkurat nå, ikke bare det som ligger i et register. Det betyr at et sårbart bilde som ble dratt inn via en tredjeparts Helm-chart eller en glemt sidecar, dukker opp i Defender-oversikten uansett om det opprinnelig ble skannet før utrulling eller ikke. For team som drifter blandede EKS- og AKS-miljøer parallelt, betyr dette at de for første gang kan se begge miljøene i samme dashbord, med samme alvorlighetsgradering og samme anbefalte tiltak.
Det er verdt å presisere at dette ikke erstatter cloud-native alternativer som Amazon GuardDuty eller Google Security Command Center. Disse verktøyene fortsetter å eksistere side om side, og mange virksomheter vil trolig kjøre begge deler i en overgangsperiode mens de vurderer om Defender for Cloud dekker nok til å konsolidere verktøykassen.
Serverløse containere får også dekning
Minst like viktig som Kubernetes-nyheten er at oppdagelse og sikkerhetsholdning for serverløse containerarbeidslaster nå er generelt tilgjengelig. Dette dekker Azure Container Apps, Azure Container Instances og Amazon ECS på AWS Fargate, ifølge de samme utgivelsesnotatene fra Microsoft.
Serverløse containere har lenge vært et blindpunkt for tradisjonelle sikkerhetsverktøy fordi det ikke finnes en fast vert å installere agenter på, og fordi arbeidslastene kan skaleres opp og ned på sekunder. Ved å knytte oppdagelse direkte til kontrollplanet i stedet for til enkeltnoder, kan Defender for Cloud nå se disse arbeidslastene uten å kreve endringer i selve applikasjonskoden. For virksomheter som har flyttet mer av arbeidslasten sin til Fargate eller Container Apps nettopp for å slippe driftsbyrden med Kubernetes, tetter dette et hull som har eksistert lenge.
Hvorfor Microsoft gjør dette nå: markedet for skysikkerhet eksploderer
Tidspunktet er ikke tilfeldig. Ifølge en Gartner-basert markedsanalyse publisert av Windsor Drake i andre kvartal 2026, var markedet for Cloud Security Posture Management (CSPM) verdt 4,7 milliarder dollar i 2025, med en prognose om å nå 16,2 milliarder dollar innen 2030. Det bredere markedet for skysikkerhet, som inkluderer CSPM sammen med beslektede kategorier som arbeidslastbeskyttelse og identitetsstyring i skyen, ventes å nå 32,4 milliarder dollar innen 2029 ifølge samme kilde.
Denne veksten drives i stor grad av konsolidering. Begrepet CNAPP, Cloud-Native Application Protection Platform, har blitt bransjens svar på at virksomheter er lei av å kjøpe fem forskjellige punktløsninger som ikke snakker sammen. CrowdStrikes 2026-rapport fra Frost & Sullivan beskriver denne konsolideringstrenden som en overgang der leverandører samler posisjon-styring, arbeidslastbeskyttelse, identitetsstyring, dataeksponering og applikasjonssikkerhet i én konsoll. Microsofts august-oppdatering er i praksis Redmonds svar på det samme presset: hvis kundene uansett vil ha ett verktøy for alle skyer, må Defender for Cloud faktisk dekke alle skyer like godt.
| Nøkkeltall | Verdi | Kilde |
|---|---|---|
| CSPM-markedet i 2025 | 4,7 milliarder dollar | Gartner, via Windsor Drake Q2 2026 |
| CSPM-markedet, prognose 2030 | 16,2 milliarder dollar | Gartner, via Windsor Drake Q2 2026 |
| Samlet skysikkerhetsmarked, prognose 2029 | 32,4 milliarder dollar | Windsor Drake Q2 2026 |
| Prisma Cloud CSPM-modul, årlig | fra ca. 18 000 dollar | Modern Data Tools prisguide 2026 |
| Prisma Cloud full CNAPP-pakke, årlig | fra ca. 45 000 dollar | Modern Data Tools prisguide 2026 |
Konkurrentene: GuardDuty, Security Command Center, Prisma Cloud og CrowdStrike
Amazon GuardDuty er fortsatt det mest brukte alternativet for team som primært lever på AWS. Ifølge Amazons offisielle prisside, oppdatert i august 2026, faktureres EKS-revisjonslogganalyse per million hendelser i måneden, med volumrabatt, mens sanntidsovervåking av arbeidslaster prises etter antall og størrelse på beskyttede vCPU-er. Modellen er skreddersydd for AWS-økosystemet, men gir mindre naturlig oversikt hvis samme organisasjon også drifter GKE eller AKS.
Google Security Command Center følger et lignende mønster på egen sky. Ifølge Googles prisside koster beskyttelse av GKE Autopilot-klynger rundt 0,0057 til 0,0071 dollar per 1000 timer, avhengig av tjenestenivå, mens andre Google-tjenester som Compute Engine og BigQuery prises separat. Også her er styrken dyp integrasjon med egen sky, og svakheten er at bildet stopper ved skyens grense.
Palo Alto Networks Prisma Cloud og CrowdStrike Falcon Cloud Security representerer den andre skolen: uavhengige plattformer bygget fra bunnen av for å dekke flere skyer samtidig. Prisma Cloud selger CSPM-modulen separat fra rundt 18 000 dollar i året, mens hele CNAPP-pakken med arbeidslastbeskyttelse, identitetsstyring og kodesikkerhet starter på rundt 45 000 dollar årlig. CrowdStrike markedsfører Falcon Cloud Security som et CNAPP bygget for å stoppe brudd, og samler posisjonstyring, arbeidslastbeskyttelse, identitetsstyring, dataeksponering, applikasjonssikkerhet og AI-sikkerhet i samme konsoll knyttet til Falcon-agenten.
| Plattform | Skydekning | Prismodell | Containersikkerhet |
|---|---|---|---|
| Microsoft Defender for Cloud | Azure, AWS, GCP (full paritet fra aug. 2026) | Del av Azure-forbruk / per ressurs | AKS, EKS og GKE med agentløs sårbarhetsskanning |
| Amazon GuardDuty | Primært AWS (EKS) | Per million revisjonshendelser + per vCPU kjøretid | EKS-revisjonslogger og kjøretidsovervåking |
| Google Security Command Center | Primært GCP (GKE) | 0,0057-0,0071 dollar per 1000 timer (GKE Autopilot) | GKE-holdning og trusseldeteksjon |
| Palo Alto Prisma Cloud | Multisky (AWS, Azure, GCP) | Fra 18 000 dollar/år (CSPM), fra 45 000 dollar/år (full CNAPP) | CSPM, arbeidslastbeskyttelse, identitet og kode i én pakke |
| CrowdStrike Falcon Cloud Security | Multisky og hybrid | Enterprise-avtale, ikke offentliggjort listepris | Agentbasert og agentløs, sanntids trusseldeteksjon |
Hva det koster å sikre en Kubernetes-klynge i flere skyer
Et konkret AWS-eksempel fra GuardDutys egen prisside viser hvordan kostnadene kan se ut i praksis: 100 millioner EKS-revisjonshendelser i det første prissjiktet, til 1,60 dollar per million, gir en regning på 160 dollar i måneden for det scenarioet alene. Legg til kjøretidsovervåking priset per vCPU, og en mellomstor klynge kan fort koste noen hundre dollar i måneden bare i sikkerhetstelemetri, før man i det hele tatt har lagt til Security Command Center for GKE-delen av miljøet eller en tredjeparts CNAPP.
Poenget med Defenders utvidelse er nettopp å kutte denne typen dobbeltbetaling og dobbeltarbeid. Hvis ett abonnement kan dekke AKS, EKS og GKE med samme dybde, slipper sikkerhetsteamet å forhandle, fakturere og korrelere varsler fra tre forskjellige konsoller. For virksomheter med begrensede sikkerhetsressurser, som er normen snarere enn unntaket i norsk offentlig sektor og i mellomstore norske teknologiselskaper, er denne konsolideringsgevinsten ofte viktigere enn selve listeprisen.
Konsekvenser for norske og nordiske skyteam
Norske virksomheter har i økende grad landet på en multisky-strategi, gjerne med Azure som hovedplattform for identitet og produktivitet, og med enkelte arbeidslaster liggende på AWS eller Google Cloud av historiske eller tekniske årsaker. Det gjør nettopp denne typen paritet svært relevant lokalt: et sikkerhetsteam som allerede lener seg på Microsofts skyøkosystem for identitetsstyring og overvåking, kan nå utvide samme arbeidsflyt til containerklynger som tilfeldigvis kjører på en annen sky, uten å måtte lære seg et helt nytt verktøy fra bunnen.
Samtidig finnes det ingen offentlig tilgjengelig, norsk- eller nordisk-spesifikk statistikk over hvor stor andel av lokale virksomheter som faktisk har aktivert multisky-tilkoblingene i Defender for Cloud i dag. Det som derimot er tydelig fra det globale bildet, er at etterspørselen etter nettopp denne typen samlet oversikt vokser raskere enn markedet for skysikkerhet generelt, ettersom stadig flere organisasjoner går fra å teste flere skyer til å drifte dem i produksjon samtidig.
Restrisiko: det Defender for Cloud fortsatt ikke løser
Paritet med AKS er ikke det samme som å være best i klassen på tvers av alle skyer. Verktøyet er fortsatt en Microsoft-styrt tjeneste, noe som betyr at nye AWS- eller GCP-spesifikke tjenester historisk sett har fått Defender-støtte senere enn de har fått støtte i sine egne native verktøy. GuardDuty og Security Command Center vil trolig fortsette å ligge i forkant på funksjoner som er unike for henholdsvis AWS og Google Cloud, rett og slett fordi de er bygget av samme selskap som bygger selve skyplattformen.
Det er heller ingen garanti for at paritet betyr identisk deteksjonskvalitet. Sårbarhetsdatabaser, skanningsfrekvens og hvor raskt nye CVE-er legges inn i motoren kan fortsatt variere mellom skyene selv om funksjonslisten ser lik ut på papiret. Sikkerhetsteam bør derfor kjøre en periode med parallell validering, der de sammenligner funn fra Defender for Cloud med funn fra det native verktøyet på samme sky, før de eventuelt faser ut det ene.
Konkurranseanalysen: hvem vinner kampen om multisky-sikkerhet
Sett under ett splitter markedet seg nå i to leire. Hyperscalerne, Microsoft først og fremst siden AWS og Google fortsatt prioriterer egne skyer tyngst, prøver å bruke bredden i sine plattformer som konkurransefortrinn: én faktura, én identitetsmodell, én konsoll. Uavhengige CNAPP-leverandører som Prisma Cloud, CrowdStrike og Wiz konkurrerer i stedet på dybde og skynøytralitet, og argumenterer for at et verktøy bygget av en tredjepart har mindre insentiv til å favorisere én sky over en annen.
Microsofts fordel er distribusjon. Svært mange virksomheter har allerede en Microsoft-lisens som inkluderer Defender-familien i en eller annen form, noe som gjør terskelen for å slå på multisky-dekningen lav. Ulempen er at virksomheter som bevisst har valgt en flerskystrategi nettopp for å unngå leverandørlåsing, kan være skeptiske til å legge sikkerhetsovervåkingen sin i hendene på samme leverandør som eier én av skyene de prøver å diversifisere bort fra.
Fem spådommer for containersikkerhet fremover
Basert på utviklingen så langt i 2026 peker flere trender fremover mot hvordan multisky-sikkerhet vil se ut om ett til to år.
- Google og AWS vil trolig svare med egne, dypere multisky-utvidelser av Security Command Center og GuardDuty innen 2027, for ikke å tape terreng til Microsoft på egne kunders sekundære skyer.
- CNAPP-konsolideringen fortsetter, og flere mindre, spesialiserte sikkerhetsverktøy vil bli kjøpt opp eller fases ut til fordel for samlede plattformer, i tråd med veksten mot et marked på 32,4 milliarder dollar innen 2029.
- AI-drevet risikoprioritering, det CrowdStrike kaller AI-SPM, blir en standard komponent i CNAPP-pakker snarere enn en tilleggsfunksjon, ettersom leverandørene kappes om å redusere antall varsler sikkerhetsteam faktisk må håndtere manuelt.
- Prispresset mellom hyperscaler-native verktøy og uavhengige CNAPP-leverandører vil øke, siden Microsofts konsoliderte tilbud gjør det vanskeligere for konkurrentene å forsvare separate lisenser for hver sky.
- Nordiske virksomheter med krav til datasuverenitet og revisjonsspor vil i økende grad etterspørre dokumentasjon på nøyaktig hvilke data som flyter mellom skyene når multisky-sikkerhetsverktøy kobles sammen, som en direkte konsekvens av at slike integrasjoner blir mer utbredt.
Hva IT- og sikkerhetsansvarlige bør gjøre nå
For team som allerede har koblet AWS og GCP til Defender for Cloud gjennom multisky-connectorne, er den nye containerdekningen i praksis en gratis oppgradering som slår seg på automatisk. Det første steget bør derfor være å bekrefte at connectorne faktisk er aktive og korrekt konfigurert, og deretter sjekke Kubernetes-holdningssiden i portalen for å se om EKS- og GKE-klynger nå dukker opp med samme detaljnivå som AKS.
For team som ennå ikke bruker Defender for Cloud utenfor Azure, er dette et naturlig tidspunkt å evaluere konsolidering opp mot dagens kombinasjon av GuardDuty, Security Command Center og eventuelle tredjepartsverktøy. Den viktigste vurderingen bør ikke være listepris alene, men hvor mye tid sikkerhetsteamet i dag bruker på å korrelere varsler manuelt mellom flere konsoller, siden det er nettopp den kostnaden konsolidering er ment å fjerne.
Kodeeksempel: sjekk om en EKS-klynge er koblet til Defender for Cloud
Etter at multisky-connectoren er konfigurert, kan et sikkerhetsteam bruke Azure CLI til raskt å bekrefte at en gitt AWS-konto med EKS-klynger faktisk er registrert og under overvåking.
az security connector list \
--query "[?environmentName=='AWS'].{Navn:name, Konto:hierarchyIdentifier, Status:offerings[0].nativeCloudConnection.enabled}" \
--output tableKommandoen lister opp alle AWS-tilkoblinger i abonnementet, sammen med AWS-kontonummeret og om den native skytilkoblingen er aktivert. Dukker en EKS-klynges vertskonto opp her med status “true”, betyr det at klyngen allerede mottar den nye sårbarhetsskanningen uten videre konfigurasjon.
Ofte stilte spørsmål om Defender for Cloud og multisky-sikkerhet
Er den nye EKS- og GKE-dekningen i Defender for Cloud gratis?
Selve multisky-tilkoblingene har vært kostnadsfrie siden mars 2022, men mange av de dypere funksjonene, som Defender CSPM og Defender for Containers, krever et betalt plantilvalg. Sjekk gjeldende prisside hos Microsoft for nøyaktige satser før utrulling i produksjon.
Erstatter dette behovet for GuardDuty eller Security Command Center?
Ikke nødvendigvis. Mange virksomheter kjører flere verktøy parallelt i en overgangsperiode, og de native verktøyene kan fortsatt ha funksjoner Defender ikke dekker fullt ut på hver enkelt sky.
Må klyngen konfigureres på nytt for å få den nye skanningen?
Nei, hvis multisky-connectoren allerede er aktivert, aktiveres den nye sårbarhetsskanningen på EKS- og GKE-noder automatisk som en del av oppdateringen fra august 2026.
Dekker oppdateringen også serverløse containere som Fargate?
Ja. Oppdagelse og sikkerhetsholdning for serverløse containere, inkludert Amazon ECS på AWS Fargate og Azure Container Apps, ble generelt tilgjengelig samtidig med Kubernetes-utvidelsen.
Hvor mye koster det å sikre en multisky Kubernetes-klynge med konkurrerende verktøy?
Som eksempel viser Amazons egen prisside at 100 millioner EKS-revisjonshendelser alene kan koste rundt 240 dollar i måneden i GuardDuty, før kjøretidsovervåking og eventuelle tredjepartsverktøy legges til.
Hvorfor tok det så lang tid for Microsoft å nå denne pariteten?
Utviklingen har gått stegvis siden 2022, med multisky-tilkoblinger først, kontekstuell sikkerhetsgraf i 2024, og containernivå-paritet først i august 2026. Hvert steg har krevd egen ingeniørinnsats for å tilpasse Azure-baserte skannemotorer til AWS- og GCP-spesifikk infrastruktur.
Er dette relevant for mindre norske selskaper, eller bare for store konsern?
Konsolideringsgevinsten er ofte størst for mindre team med begrensede sikkerhetsressurser, siden de har minst kapasitet til å drifte flere separate sikkerhetskonsoller parallelt.
Hva bør et sikkerhetsteam gjøre først etter denne oppdateringen?
Bekreft at eksisterende AWS- og GCP-connectorer er aktive, sammenlign deretter funn fra Defender for Cloud med det native verktøyet på samme sky over en periode, før eventuell konsolidering av verktøykassen.
