Microsoft stengte døren for TLS 1.0 og TLS 1.1 i Azure Blob Storage 3. februar 2026. Klienter som fortsatt forsøker å koble til med de gamle protokollene, får rett og slett avslag på håndtrykket. Samtidig har Microsoft Entra ID-basert SFTP-tilgang blitt allment tilgjengelig, prefiksbegrenset SAS har nådd generell tilgjengelighet i alle regioner, og Defender for Storage kan nå skanne enkeltblober i stedet for hele kontoer. Endringene kommer tett, og mange team i Norge og resten av Norden sitter fortsatt med lagringskontoer konfigurert etter gamle standarder. Denne guiden tar deg gjennom 12 konkrete steg for å sikre Azure Blob Storage fra bunnen, med kommandoer du kan kjøre i dag, en komplett Terraform-modul du kan gjenbruke, og en feilsøkingsseksjon for når ting ikke går som planlagt. Vi dekker også hvordan tilgangsnivåer, compliance-krav og kostnad henger sammen med sikkerhetsvalgene dine, siden en billig, men usikret konfigurasjon ofte ender opp som den dyreste løsningen etter et brudd.

Forutsetninger: dette trenger du før du starter

Før du går i gang med Azure Blob Storage sikkerhet, bør du ha følgende på plass. Ingen av verktøyene krever eksotiske lisenser, men noen krever riktig rolletildeling i Entra ID.

  • Et aktivt Azure-abonnement med rettigheter til å opprette ressursgrupper og lagringskontoer (rollen Contributor eller høyere)
  • Azure CLI installert i nyeste versjon, testet på macOS, Linux og Windows
  • Terraform installert i nyeste versjon, samt azurerm-provider i nyeste versjon, dersom du vil bruke infrastruktur-som-kode-delen
  • En Entra ID-tenant der du har rettigheter til å tildele roller (User Access Administrator eller Global Administrator)
  • Grunnleggende kjennskap til JSON, YAML og kommandolinjen
  • Eventuelt en Azure Key Vault-instans hvis du skal bruke kundeadministrerte krypteringsnøkler

Sjekk også at kontoen din ikke er en eldre “BlobStorage”-kontotype. Microsoft stanser muligheten til å opprette nye kontoer av denne typen i september 2026, og gjenværende klassiske kontoer migreres automatisk til General Purpose v2 etter 13. oktober 2026. Har du eldre kontoer i drift, planlegg migreringen selv i stedet for å la den skje automatisk. Offisiell dokumentasjon for sikkerhetsanbefalinger for Blob Storage er et godt referansepunkt å ha åpent i en fane mens du jobber.

Steg 1: Opprett en lagringskonto med sikre standardinnstillinger

Start aldri med standardkommandoen og juster i etterkant. Sett de kritiske bryterne allerede ved opprettelse, slik at kontoen aldri eksisterer i en usikret tilstand, selv ikke i noen sekunder.

az group create --name rg-blob-sikkerhet --location norwayeast

az storage account create \
  --name stsikkerblob2026 \
  --resource-group rg-blob-sikkerhet \
  --location norwayeast \
  --sku Standard_GRS \
  --kind StorageV2 \
  --https-only true \
  --min-tls-version TLS1_2 \
  --allow-blob-public-access false \
  --allow-shared-key-access false \
  --default-action Deny

Legg merke til --allow-shared-key-access false. Den bryteren tvinger all datatilgang gjennom Entra ID i stedet for de klassiske kontonøklene, noe som eliminerer en hel kategori lekkasjer der en nøkkel havner i et Git-repo eller en loggfil. Kjører du kommandoen riktig, får du et JSON-svar som bekrefter innstillingene:

{
  "allowBlobPublicAccess": false,
  "allowSharedKeyAccess": false,
  "minimumTlsVersion": "TLS1_2",
  "provisioningState": "Succeeded",
  "publicNetworkAccess": "Enabled"
}

Region-valget norwayeast er relevant for norske virksomheter med krav til datalagring innenfor landegrensen, men vurder alltid egne compliance-krav før du låser regionen. Velg replikeringsnivå bevisst også. Standard_GRS (geo-redundant lagring) gir deg en sekundær kopi i en annen Azure-region, noe som beskytter mot regionale utfall, men vær oppmerksom på at sekundærkopien da havner utenfor Norge dersom du bruker parregionen til Norway East. Har du strenge krav til datalokasjon, vurder Standard_ZRS (sonevis redundans) i stedet, som holder alle kopiene innenfor samme region fordelt på flere tilgjengelighetssoner.

Steg 2: Tving frem TLS 1.2 og fjern gamle protokoller for godt

Har du eksisterende kontoer opprettet før februar 2026, sjekk dem eksplisitt. Den gamle fristen for TLS-pensjonering ble utsatt to ganger (fra 1. november 2024, deretter til 1. november 2025), men Microsoft har vært tydelig på at det ikke blir flere utsettelser etter 3. februar 2026. Fra den datoen feiler ethvert klientkall som forhandler TLS 1.0 eller 1.1, uansett kontoinnstillinger.

# Sjekk gjeldende TLS-krav på en eksisterende konto
az storage account show \
  --name stsikkerblob2026 \
  --resource-group rg-blob-sikkerhet \
  --query minimumTlsVersion

# Tving TLS 1.2 hvis kontoen fortsatt tillater eldre versjoner
az storage account update \
  --name stsikkerblob2026 \
  --resource-group rg-blob-sikkerhet \
  --min-tls-version TLS1_2

Endringen gjelder ikke bare Blob Storage. Den samme kontoinnstillingen styrer også Files, Queues og Tables, så en oppdatering her rydder opp i hele lagringskontoen samtidig. Har du eldre .NET-, Java- eller Python-klienter som fortsatt bruker gamle SSL/TLS-biblioteker, må disse oppgraderes før kuttet, ellers stopper integrasjonen helt. Se Microsofts egen veiledning for å konfigurere minimum TLS-versjon for detaljer om hvordan du identifiserer klienter som fortsatt bruker utdaterte protokoller.

Steg 3: Sett opp Entra ID RBAC i stedet for kontonøkler

Med delt nøkkeltilgang deaktivert (fra steg 1) må all tilgang gå gjennom rollebasert tilgangskontroll. Tildel roller på riktig nivå, aldri bredere enn nødvendig. En utvikler som bare skal lese data, trenger ikke skriverettigheter på hele kontoen.

# Tildel lese- og skriverettigheter til en spesifikk container
az role assignment create \
  --assignee "[email protected]" \
  --role "Storage Blob Data Contributor" \
  --scope "/subscriptions//resourceGroups/rg-blob-sikkerhet/providers/Microsoft.Storage/storageAccounts/stsikkerblob2026/blobServices/default/containers/kundedata"

# Kun lesetilgang for en tjenestekonto
az role assignment create \
  --assignee "" \
  --role "Storage Blob Data Reader" \
  --scope "/subscriptions//resourceGroups/rg-blob-sikkerhet/providers/Microsoft.Storage/storageAccounts/stsikkerblob2026"

Bruk Managed Identity for applikasjoner som kjører i Azure, fremfor tjenesteprinsipaler med lagrede hemmeligheter. Da trenger appen aldri å håndtere et passord eller en nøkkel i det hele tatt, Azure håndterer rotasjonen internt. For team med mange midlertidige oppgaver, som en konsulent som trenger tilgang i to uker, bør du kombinere RBAC med Privileged Identity Management (PIM). Da får personen kun aktiv tilgang når den faktisk trengs, og rollen utløper automatisk uten at noen må huske å fjerne den manuelt i etterkant.

Steg 4: Bruk prefiksbegrenset User Delegation SAS

Noen ganger trenger eksterne parter midlertidig tilgang, og da er en delt tilgangssignatur (SAS) riktig verktøy. Prefiksbegrenset tilgang for User Delegation SAS er nå generelt tilgjengelig i alle Azure-regioner for både Blob Storage og Data Lake Storage. Det betyr at du kan begrense en SAS-token til objekter under en gitt bane i stedet for å gi tilgang til hele containeren.

# Generer en tidsbegrenset SAS-token basert på Entra ID-identitet, ikke kontonøkkel
az storage blob generate-sas \
  --account-name stsikkerblob2026 \
  --container-name kundedata \
  --name "rapporter/2026/q1-rapport.pdf" \
  --auth-mode login \
  --as-user \
  --permissions r \
  --expiry 2026-10-01T00:00:00Z \
  --https-only

Merk --auth-mode login --as-user. Dette genererer en User Delegation SAS signert med Entra ID-legitimasjon fremfor en kontonøkkel, som betyr at tokenet kan trekkes tilbake ved å fjerne brukerens rolletildeling, uten å måtte rotere hele kontoens nøkler. Sett alltid en kort utløpstid, helst under 24 timer for eksterne mottakere. Skal tokenet distribueres automatisk, for eksempel fra et rapporteringssystem som sender lenker til kunder, bygg genereringen inn i selve applikasjonslogikken slik at hvert token er unikt for mottakeren og aldri gjenbrukes på tvers av flere personer.

Steg 5: Konfigurer private endepunkter og nettverksregler

Offentlig nettverkstilgang bør være unntaket, ikke standarden. Et privat endepunkt plasserer lagringskontoen inne i ditt eget virtuelle nettverk, slik at trafikken aldri forlater Azure-ryggraden.

az network private-endpoint create \
  --name pe-blob-sikkerhet \
  --resource-group rg-blob-sikkerhet \
  --vnet-name vnet-produksjon \
  --subnet subnet-lagring \
  --private-connection-resource-id "/subscriptions//resourceGroups/rg-blob-sikkerhet/providers/Microsoft.Storage/storageAccounts/stsikkerblob2026" \
  --group-id blob \
  --connection-name pe-blob-tilkobling

az storage account update \
  --name stsikkerblob2026 \
  --resource-group rg-blob-sikkerhet \
  --public-network-access Disabled

Husk å opprette en privat DNS-sone (privatelink.blob.core.windows.net) og koble den til det virtuelle nettverket. Uten riktig DNS-oppløsning vil klienter fortsatt forsøke å nå kontoen via det offentlige endepunktet og feile, selv om det private endepunktet er korrekt konfigurert. Vurder også å legge en nettverkssikkerhetsgruppe (NSG) på subnettet der det private endepunktet ligger, med regler som kun tillater trafikk fra kjente applikasjonssubnett. Et privat endepunkt fjerner eksponeringen mot internett, men det stopper ikke lateral bevegelse fra en kompromittert maskin et annet sted i samme virtuelle nettverk.

Steg 6: Lås brannmuren med IP-regler og tjenesteendepunkter

Har du klienter som ikke kan gå gjennom et privat endepunkt, for eksempel en lokal CI/CD-runner, kan du kombinere nettverksregler med private endepunkter. Standardhandlingen skal alltid være å nekte, og du åpner deretter kun for spesifikke kilder.

az storage account network-rule add \
  --account-name stsikkerblob2026 \
  --resource-group rg-blob-sikkerhet \
  --ip-address 203.0.113.42

az storage account network-rule add \
  --account-name stsikkerblob2026 \
  --resource-group rg-blob-sikkerhet \
  --vnet-name vnet-produksjon \
  --subnet subnet-cicd

Unngå å legge inn brede CIDR-blokker “midlertidig” for å teste noe raskt. Det er nettopp den typen midlertidige regler som blir liggende i måneder og som dukker opp som funn i neste sikkerhetsrevisjon. Sett heller opp en fast rutine der nettverksreglene gjennomgås kvartalsvis, og fjern regler som ikke lenger har en tydelig eier. Bruk tagger på hver regel, eller før en enkel liste i et delt dokument, slik at du om seks måneder faktisk husker hvorfor en gitt IP-adresse fikk tilgang i utgangspunktet.

Steg 7: Aktiver Microsoft Defender for Storage

Defender for Storage har fått flere nye funksjoner gjennom 2026. På-forespørsel-skanning for skadevare kan nå målrettes mot spesifikke blober, filer, containere og filandeler i stedet for å skanne hele kontoen, noe som gjør skanningen langt mer presis og kostnadseffektiv. Automatisert skadevaresanering er nå generelt tilgjengelig, i likhet med på-forespørsel-skanning for Azure Files.

az security pricing create \
  --name StorageAccounts \
  --tier Standard

az security pricing show --name StorageAccounts

Etter aktivering begynner Defender å analysere opplastingsmønstre, tilgangsanomali og potensielt ondsinnet innhold. Følg med på hva som er nytt via Defender for Clouds oppdateringslogg, siden funksjonsettet har endret seg raskt gjennom hele 2026. Standardplanen dekker hele lagringskontoen, mens den nye på-forespørsel-skanningen lar deg begrense skanningsomfanget til spesifikke prefikser. For en konto med flere containere av ulik sensitivitet, gir dette mulighet til å prioritere skanning av containere med kundedata fremfor midlertidige loggfiler, uten å måtte velge mellom full skanning eller ingen skanning i det hele tatt.

Steg 8: Sett opp automatisert respons på skadevarefunn

Deteksjon uten respons hjelper lite klokken tre om natten. Koble Defender for Storage til en Logic App eller Azure Function som automatisk flytter mistenkelige blober til en karantenecontainer og varsler sikkerhetsteamet.

az storage container create \
  --name karantene \
  --account-name stsikkerblob2026 \
  --public-access off

# Eksempel: flytt en blob til karantene når Defender flagger et funn
az storage blob copy start \
  --account-name stsikkerblob2026 \
  --destination-container karantene \
  --destination-blob "$(basename $BLOB_STI)" \
  --source-uri "$BLOB_STI"

Test alltid automatiseringen mot en testkonto først. En feilkonfigurert regel som flytter alle blober til karantene, kan stanse en produksjonsapplikasjon like effektivt som et reelt angrep. Bygg inn en manuell godkjenning for de mest kritiske containerne, slik at automatiseringen varsler og foreslår handling fremfor å utføre den permanent slettende operasjonen uten et menneske involvert. Det koster deg noen minutter ekstra responstid, men det er billigere enn å gjenopprette en produksjonscontainer fra backup fordi automatiseringen tolket et falskt positivt funn feil.

Steg 9: Aktiver immutability-policyer for uforanderlig lagring

For revisjonslogger, finansielle data eller andre poster som juridisk må forbli uendret, gir uforanderlighetspolicyer (WORM, write once read many) en garanti som selv en kontoadministrator ikke kan omgå innenfor policyens levetid.

az storage container immutability-policy create \
  --account-name stsikkerblob2026 \
  --container-name revisjonslogg \
  --period 365 \
  --allow-protected-append-writes true

az storage container immutability-policy lock \
  --account-name stsikkerblob2026 \
  --container-name revisjonslogg

Vær bevisst på at lock-kommandoen er permanent innenfor perioden. Test policyen grundig på en ikke-produktiv container først, siden en låst policy ikke kan reverseres, kun forlenges. For norske virksomheter i finans, helse eller offentlig sektor er dette ofte et krav fra revisor eller tilsynsmyndighet, ikke bare en teknisk finesse. Dokumenter hvilke containere som har uforanderlighetspolicyer, og hvorfor, slik at neste revisjon går raskt i stedet for å bli en detektivjobb.

Juridisk hold som supplement

I tillegg til tidsbaserte policyer kan du sette juridisk hold (legal hold) på en container når data er relevant for en pågående sak. I motsetning til en tidsbasert policy fjernes et juridisk hold manuelt når behovet opphører, og det kan kombineres med tidsbasert uforanderlighet for maksimal beskyttelse.

Steg 10: Krypter data med kundeadministrerte nøkler

All data i Blob Storage krypteres automatisk i hvile med Microsoft-administrerte nøkler, men mange virksomheter med strenge compliance-krav vil ha full kontroll over nøkkelrotasjon og tilbakekalling. Da bruker du kundeadministrerte nøkler (CMK) i Azure Key Vault.

az storage account update \
  --name stsikkerblob2026 \
  --resource-group rg-blob-sikkerhet \
  --encryption-key-source Microsoft.Keyvault \
  --encryption-key-vault "https://kv-sikkerhet.vault.azure.net" \
  --encryption-key-name blob-krypteringsnokkel \
  --encryption-key-version ""

Tom versjonsstreng betyr at kontoen automatisk henter nyeste nøkkelversjon, noe som gjør rotasjon enklere. Gi lagringskontoens Managed Identity Key Vault Crypto Service Encryption User-rollen på hvelvet, ellers feiler krypteringsoppsettet med en tilgangsfeil.

Steg 11: Sett opp Entra ID-basert SFTP-tilgang

Entra ID-basert tilgang til Blob Storage over SFTP er nå generelt tilgjengelig i alle regioner. Det betyr at eksterne partnere kan koble til via SFTP med sin egen Entra ID-identitet, inkludert gjestebrukere via Entra External Identities, uten at du trenger å opprette og vedlikeholde lokale SFTP-brukernavn manuelt.

az storage account update \
  --name stsikkerblob2026 \
  --resource-group rg-blob-sikkerhet \
  --enable-sftp true

az storage account local-user create \
  --account-name stsikkerblob2026 \
  --resource-group rg-blob-sikkerhet \
  --user-name partner-sftp \
  --home-directory kundedata \
  --permission-scope permissions=rl service=blob resource-name=kundedata

Den generelt tilgjengelige versjonen støtter nå Azure RBAC, attributtbasert tilgangskontroll (ABAC) og storage-ACL-er samtidig for SFTP, og en tidligere feil som forårsaket tidsavbrudd ved kombinasjon av ABAC og rollen Storage Blob Data Owner er rettet. Bruk Entra-basert SFTP fremfor lokale brukere overalt hvor partnerens organisasjon støtter det, siden du da får enkel pålogging, MFA og betinget tilgang gratis.

Steg 12: Overvåk, logg og varsle med Azure Monitor

Konfigurasjon uten overvåking er en falsk trygghet. Send diagnostikklogger fra lagringskontoen til en Log Analytics-arbeidsområde, og bygg varsler på mistenkelige mønstre, som et plutselig hopp i mislykkede autentiseringsforsøk.

az monitor diagnostic-settings create \
  --name diag-blob-sikkerhet \
  --resource "/subscriptions//resourceGroups/rg-blob-sikkerhet/providers/Microsoft.Storage/storageAccounts/stsikkerblob2026/blobServices/default" \
  --workspace "/subscriptions//resourceGroups/rg-blob-sikkerhet/providers/Microsoft.OperationalInsights/workspaces/log-sikkerhet" \
  --logs '[{"category":"StorageRead","enabled":true},{"category":"StorageWrite","enabled":true},{"category":"StorageDelete","enabled":true}]' \
  --metrics '[{"category":"Transaction","enabled":true}]'

Sett opp en varselregel som trigges på mange StorageDelete-hendelser innenfor kort tid. Det fanger opp både feilkonfigurerte opprydningsjobber og faktiske utpressingsangrep der en angriper sletter data etter å ha eksfiltrert det. Vurder også å eksportere de samme loggene til en sentral SIEM-løsning dersom sikkerhetsteamet allerede overvåker andre systemer der, i stedet for å bygge en egen, isolert varslingsprosess bare for denne ene lagringskontoen. Konsistens på tvers av systemene gjør det langt raskere å koble sammen hendelser som henger sammen på tvers av flere tjenester.

Tilgangsnivåer og hvordan de påvirker sikkerheten

Blob Storage tilbyr fire tilgangsnivåer: hot, cool, cold og archive. Valget påvirker ikke bare pris, men også hvor raskt du kan reagere på et sikkerhetsfunn. Data i archive-nivået må rehydreres før det i det hele tatt kan leses, noe som kan ta timer. Det er upraktisk for aktive revisjonslogger, men gir samtidig et ekstra lag med friksjon mot rask masseeksfiltrering, siden en angriper ikke bare kan laste ned store mengder arkiverte data momentant.

En vanlig feil er å legge sensitive, aktivt brukte data i cold eller archive for å spare penger, for så å oppdage at responstiden ved et hendelsessøk blir uakseptabel. Legg heller livssyklusregler som automatisk flytter data til billigere nivåer basert på alder, mens data som er under 90 dager gammel og fortsatt kan være relevant for en pågående hendelse, blir liggende i hot eller cool. Husk at sikkerhetskontrollene fra tidligere steg, som Entra ID RBAC, privat endepunkt og kryptering med kundeadministrert nøkkel, gjelder uavhengig av hvilket tilgangsnivå dataene ligger på. Å flytte data til archive endrer ikke hvem som har tilgang, det endrer bare hvor raskt de kan hente det ut.

az storage account management-policy create \
  --account-name stsikkerblob2026 \
  --resource-group rg-blob-sikkerhet \
  --policy '{
    "rules": [{
      "name": "flytt-gamle-logger",
      "type": "Lifecycle",
      "definition": {
        "filters": {"blobTypes": ["blockBlob"], "prefixMatch": ["revisjonslogg/"]},
        "actions": {
          "baseBlob": {
            "tierToCool": {"daysAfterModificationGreaterThan": 90},
            "tierToArchive": {"daysAfterModificationGreaterThan": 365}
          }
        }
      }
    }]
  }'

GDPR, datasuverenitet og krav til norske virksomheter

For virksomheter som opererer i Norge og resten av Norden, handler Blob Storage-sikkerhet like mye om regeletterlevelse som om tekniske kontroller. GDPR krever at du kan dokumentere hvor persondata lagres, hvem som har tilgang, og hvordan du sletter data på forespørsel. Regionvalget fra steg 1 er derfor ikke bare et ytelsesspørsmål, det er en del av dokumentasjonen du må kunne fremvise ved en revisjon.

NIS2-direktivet, som er innført i norsk rett gjennom digitalsikkerhetsloven, stiller strengere krav til hendelsesrapportering for virksomheter i kritiske sektorer. Har lagringskontoen din data som faller inn under denne loven, blir Steg 12 (overvåking og varsling) ikke lenger valgfritt. Du må kunne vise at du oppdager og rapporterer hendelser innenfor lovpålagte frister, noe som i praksis betyr at diagnostikkloggene må rute til et sted der noen faktisk følger med, ikke bare et Log Analytics-arbeidsområde ingen sjekker.

Bruk gjerne “purge protection” på Key Vault-en som holder krypteringsnøklene fra steg 10, slik at en sletteforespørsel for persondata kan gjennomføres kontrollert, uten risiko for at noen ved en feil sletter selve krypteringsnøkkelen og dermed gjør all data utilgjengelig i stedet for bare den ene brukerens data.

Etter Schrems II-dommen er det også et poeng å vite hvor Microsoft selv kan flytte eller replikere data på tvers av landegrenser i sin egen infrastruktur, ikke bare hvor du selv har valgt region. Les gjennom Microsofts databehandleravtale og eventuelle EU Data Boundary-forpliktelser for tjenesten, og dokumenter vurderingen internt, slik at svaret ligger klart neste gang en kunde eller et tilsyn spør om hvor dataene faktisk befinner seg.

Komplett fungerende prosjekt: Terraform-modul for sikker Blob Storage

Under følger en samlet Terraform-modul som kombinerer alle stegene over: sikker lagringskonto, tvunget TLS 1.2, deaktiverte kontonøkler, privat endepunkt, Defender for Storage og diagnostikklogging. Bruk denne som utgangspunkt for produksjonsmiljøet ditt, og tilpass navn og verdier.

resource "azurerm_resource_group" "sikkerhet" {
  name     = "rg-blob-sikkerhet"
  location = "Norway East"
}

resource "azurerm_storage_account" "blob" {
  name                            = "stsikkerblob2026"
  resource_group_name             = azurerm_resource_group.sikkerhet.name
  location                        = azurerm_resource_group.sikkerhet.location
  account_tier                    = "Standard"
  account_replication_type        = "GRS"
  account_kind                    = "StorageV2"
  min_tls_version                 = "TLS1_2"
  https_traffic_only_enabled      = true
  allow_nested_items_to_be_public = false
  shared_access_key_enabled       = false
  public_network_access_enabled   = false

  network_rules {
    default_action = "Deny"
    bypass         = ["AzureServices"]
  }

  identity {
    type = "SystemAssigned"
  }
}

resource "azurerm_private_endpoint" "blob" {
  name                = "pe-blob-sikkerhet"
  location            = azurerm_resource_group.sikkerhet.location
  resource_group_name = azurerm_resource_group.sikkerhet.name
  subnet_id            = var.subnet_id

  private_service_connection {
    name                           = "pe-blob-tilkobling"
    private_connection_resource_id = azurerm_storage_account.blob.id
    subresource_names              = ["blob"]
    is_manual_connection            = false
  }
}

resource "azurerm_security_center_subscription_pricing" "storage" {
  tier          = "Standard"
  resource_type = "StorageAccounts"
}

resource "azurerm_monitor_diagnostic_setting" "blob" {
  name                       = "diag-blob-sikkerhet"
  target_resource_id         = "${azurerm_storage_account.blob.id}/blobServices/default"
  log_analytics_workspace_id = var.log_analytics_workspace_id

  enabled_log {
    category = "StorageWrite"
  }

  metric {
    category = "Transaction"
    enabled  = true
  }
}

Kjør terraform plan før terraform apply og les gjennom hele endringslisten. Legg spesielt merke til at public_network_access_enabled = false vil bryte eksisterende integrasjoner som fortsatt bruker det offentlige endepunktet, så koordiner utrullingen med et vedlikeholdsvindu.

Tilpass modulen til eget miljø

Modulen over antar at du allerede har et virtuelt nettverk og et Log Analytics-arbeidsområde, referert via var.subnet_id og var.log_analytics_workspace_id. Legg disse i en variables.tf-fil sammen med et tilhørende outputs.tf som eksponerer lagringskontoens ressurs-ID, slik at andre moduler i infrastrukturen kan referere til den uten hardkodede navn. Skal modulen brukes på tvers av flere miljøer, som test, staging og produksjon, bør navnet på lagringskontoen genereres dynamisk, siden Azure krever globalt unike kontonavn og et hardkodet navn som stsikkerblob2026 vil kollidere ved andre gangs utrulling.

Vanlige feil og fallgruver

De fleste sikkerhetshullene i Blob Storage-oppsett kommer ikke fra avanserte angrep, men fra samme håndfull konfigurasjonsfeil som gjentar seg på tvers av virksomheter. Kjenner du igjen ett eller flere av punktene under fra egen drift, er det verdt å sette av en time til opprydning før neste sikkerhetsgjennomgang.

  • Glemmer å deaktivere offentlig blob-tilgang etter opprettelse. Standardverdien har historisk vært mer åpen enn folk tror, og en container satt til offentlig lesing blir stående synlig for hele internett.
  • Bruker delte kontonøkler i produksjonskode. En nøkkel som havner i et offentlig Git-repo eller en delt konfigurasjonsfil, gir full lese- og skrivetilgang til hele kontoen inntil den roteres manuelt.
  • Genererer SAS-tokens uten utløpsdato eller med for vide tillatelser. En SAS med skrive- og slette-rettigheter og ingen utløpstid er funksjonelt identisk med en lekket hovednøkkel.
  • Overser DNS-oppsettet for private endepunkter. Uten korrekt privat DNS-sone fortsetter klienter å slå opp det offentlige endepunktet, og du tror feilaktig at trafikken går privat.
  • Ignorerer varsler fra Defender for Storage fordi kostnadsbildet virker uklart. Den nye på-forespørsel-skanningen lar deg begrense omfanget til kritiske containere, noe som gjør kostnaden langt mer forutsigbar enn full kontoskanning.
  • Utsetter migreringen bort fra klassiske BlobStorage-kontoer. Etter 13. oktober 2026 migreres gjenværende kontoer automatisk, og en ukontrollert migrering midt i en driftsperiode er sjelden ønskelig.
  • Setter for lang eller ingen utløpstid på Entra ID-rolletildelinger. En konsulent eller ekstern part som fikk midlertidig tilgang for et prosjekt, blir stående med aktive rettigheter lenge etter at prosjektet er avsluttet, med mindre tilgangen er tidsbegrenset eller regelmessig gjennomgått.
  • Stoler blindt på automatisk migrering uten å teste den selv. Automatisk konvertering fra klassisk BlobStorage til General Purpose v2 fungerer i de fleste tilfeller, men enkelte funksjoner og priser kan endre seg, og det er billigere å oppdage det i test enn i produksjon.

Feilsøking: 8 vanlige problemer og løsninger

Under følger de problemene som oftest dukker opp når team strammer inn sikkerheten på en eksisterende Blob Storage-konto. De fleste av dem oppstår rett etter at en tidligere åpen konfigurasjon strammes inn, når klienter og integrasjoner som var avhengige av den gamle, mer permissive oppførselen plutselig begynner å feile.

ProblemSannsynlig årsakLøsning
403 Forbidden ved tilgang gjennom klientDelt nøkkeltilgang er deaktivert, men klienten bruker fortsatt en kontonøkkelBytt klienten til Entra ID-autentisering med DefaultAzureCredential eller tilsvarende
TLS-håndtrykk feiler heltKlient eller bibliotek forhandler fortsatt TLS 1.0/1.1Oppgrader klientbiblioteket og tving TLS 1.2 i applikasjonskoden
Privat endepunkt konfigurert, men trafikk går fortsatt offentligManglende eller feil privat DNS-sone-koblingVerifiser at privatelink.blob.core.windows.net peker til riktig privat IP
SAS-token avvises med 403Tokenet er utløpt eller signert med feil nøkkelversjonGenerer nytt token med –auth-mode login og kontroller klokkeskjevhet mellom klient og server
Defender for Storage genererer ingen varslerPlanen er ikke aktivert på riktig ressurstype, eller skanning er begrenset til feil prefiksKontroller az security pricing show og skanningsomfanget i Defender-portalen
Kryptering med kundeadministrert nøkkel feiler ved oppsettManglende rolletildeling mellom lagringskontoens identitet og Key VaultTildel Key Vault Crypto Service Encryption User til kontoens Managed Identity
Immutability-policy kan ikke låsesContaineren inneholder blober som brøt policyens append-only-reglerFjern eller flytt blober som strider mot policyen før du kjører lock-kommandoen
SFTP-pålogging med Entra ID feiler med tidsavbruddEldre versjon av ABAC-integrasjonen kombinert med Storage Blob Data Owner-rollenOppgrader til nyeste GA-versjon av funksjonen, som løser denne kjente inkonsistensen

Autentiseringsmetoder: hva bør du velge?

Ikke alle autentiseringsmetoder passer til alle scenarioer. Tabellen under oppsummerer når du bør bruke hva.

MetodeSikkerhetsnivåTypisk bruksområdeRotasjon/utløp
Delt kontonøkkel (Access Key)Lavt, full kontotilgang ved lekkasjeBør unngås i produksjon, kun legacy-verktøyManuell rotasjon, ingen automatisk utløp
Klassisk SAS (kontonøkkelbasert)Middels, begrenset omfang men vanskelig å tilbakekalle enkeltvisKortvarig ekstern deling uten Entra ID-tilgangFast utløpstid, men krever full nøkkelrotasjon for å sperre
User Delegation SAS med prefiksHøyt, bundet til Entra ID-identitet og valgfri banebegrensningEkstern partnertilgang til en spesifikk mappeFast utløpstid, kan sperres ved å fjerne rolletildeling
Entra ID RBACHøyt, full sporbarhet og betinget tilgangInterne applikasjoner og brukereStyres av Entra ID-livssyklus og betinget tilgang
Entra ID-basert SFTPHøyt, samme identitetsmodell som RBACPartnere som krever SFTP-protokollStyres av Entra ID-livssyklus, ingen lokale passord

Tommelfingerregelen er enkel. Er brukeren eller applikasjonen internt i organisasjonen, bruk Entra ID RBAC. Er mottakeren ekstern og trenger midlertidig tilgang til en spesifikk mappe, bruk en prefiksbegrenset User Delegation SAS. Kontonøkler bør kun forekomme i systemer som verken støtter Entra ID eller SAS, og selv da bør nøkkelen roteres på en fast tidsplan, aldri ligge urørt i årevis slik man ofte ser i eldre integrasjoner.

Viktige datoer for Azure Storage-sikkerhet i 2026

Flere platformendringer treffer Blob Storage-brukere gjennom hele 2026. Planlegg rundt disse datoene fremfor å bli overrasket av dem. Sett dem gjerne inn i teamets egen driftskalender med en påminnelse fire til seks uker i forkant, slik at eventuelle klientoppgraderinger eller SPN-endringer rekker å bli testet før fristen faktisk treffer produksjonsmiljøet.

DatoEndringKonsekvens
3. februar 2026TLS 1.0 og 1.1 pensjonert, TLS 1.2 er nytt minimumskravKlienter med gamle TLS-biblioteker mister tilgang umiddelbart
April 2026 (Windows-oppdatering)Kerberos-kryptering kan påvirkes tidlig for kontoer med egendefinert SPNKontoer med egen DNS-suffiks bør verifisere Kerberos-oppsettet før sommeren
Juli 2026 (Windows Server-oppdatering)Standard Kerberos-kryptering i AD DS endres fra RC4 til AES-256Kan påvirke autentisering i hybride Azure Files/AD-oppsett
September 2026Microsoft stanser oppretting av nye klassiske BlobStorage-kontoerNye kontoer må opprettes som General Purpose v2
13. oktober 2026Gjenværende klassiske BlobStorage-kontoer migreres automatisk til GPv2Ukontrollert migrering kan påvirke funksjonalitet, planlegg selv i forkant

Avanserte tips for produksjonsmiljøer

Når grunnoppsettet er på plass, er det disse detaljene som skiller et solid produksjonsmiljø fra et som bare består en enkel sjekkliste. De fleste av tipsene under koster lite å innføre, men gjør stor forskjell den dagen noe faktisk går galt.

  • Bruk Azure Policy til å håndheve innstillinger som min-tls-version og allow-blob-public-access på tvers av hele abonnementet, slik at ingen ny konto kan opprettes utenfor standarden.
  • Aktiver klientsidedataintegritet med CRC64-NVME, som nå er generelt tilgjengelig i de nyeste Azure Blob SDK-ene for .NET, C++ og JavaScript, for å verifisere data ende til ende utover den serverbaserte integritetssjekken.
  • Sett opp Customer Lockbox slik at Microsoft-support må be om eksplisitt godkjenning før de får tilgang til dataene dine ved feilsøking.
  • Automatiser rotasjon av SAS-tokens og kundeadministrerte nøkler med Azure Key Vault sine innebygde rotasjonspolicyer, fremfor manuelle årlige gjennomganger.
  • Følg Defender-sikkerhetspoengsummen (Secure Score) i Defender for Cloud som en kontinuerlig indikator, ikke bare som en engangssjekk ved oppsett. En synkende poengsum over tid er ofte det første tegnet på at noen har opprettet en ny konto eller endret en innstilling utenfor den godkjente prosessen.
  • Gjennomfør en enkel katastrofeøvelse minst én gang i året, der teamet praktisk gjenoppretter en container fra geo-redundant lagring eller en backup. En gjenopprettingsplan som aldri er testet, er i realiteten en antakelse, ikke en plan.
  • Les gjennom Microsofts Well-Architected-veiledning for Blob Storage for arkitekturmønstre utover det denne guiden dekker, spesielt rundt kostnadsoptimalisering og skalering.

Husk også at sikkerhet i skylagring ikke er unikt for Azure. Mange av prinsippene, som minste privilegium, kortvarige tilgangstokens og aktiv overvåking, går igjen i OWASPs generelle anbefalinger for de vanligste sikkerhetsrisikoene, og det er verdt å sjekke egen konfigurasjon opp mot den listen med jevne mellomrom.

Et siste poeng: sårbarheter dukker ikke alltid opp i selve plattformen. CVE-2026-50173 beskriver en autentiseringsfeil i tredjepartsverktøyet Flow-Like, der en feiljustert Azure-legitimasjonsleverandør kunne gi tilgang utover det filrettighetene tilsa i selvhostede oppsett. Feilen er patchet i versjon 1.0.4, men den er et godt eksempel på at ethvert verktøy som bruker dine Azure-legitimasjoner, må holdes oppdatert like strengt som selve Blob Storage-kontoen. Før en enkel oversikt over hvilke tredjepartsverktøy, CI/CD-pipeliner og skript som har lese- eller skrivetilgang til lagringskontoen din, og sjekk den listen mot leverandørenes sikkerhetsvarsler jevnlig, ikke bare når Azure selv publiserer en oppdatering.

Sjekkliste før du går i produksjon

Bruk listen under som en siste gjennomgang før du erklærer lagringskontoen produksjonsklar. Hvert punkt kan verifiseres med en enkelt CLI-kommando, så det tar deg under ti minutter å gå gjennom hele oppsettet.

  1. Delt nøkkeltilgang er deaktivert (allowSharedKeyAccess: false)
  2. Minimum TLS-versjon er satt til 1.2 eller høyere på alle lagringskontoer
  3. Entra ID-roller er tildelt på riktig nivå, ingen bruker har bredere tilgang enn nødvendig
  4. Eventuelle SAS-tokens er prefiksbegrenset, tidsbegrenset og generert med --auth-mode login
  5. Offentlig nettverkstilgang er deaktivert, og private endepunkter er koblet til riktig privat DNS-sone
  6. Nettverksregler følger nekt-som-standard, med kun eksplisitt godkjente unntak
  7. Microsoft Defender for Storage er aktivert, og skanningsomfanget dekker de riktige containerne
  8. Automatisert respons på skadevarefunn er testet mot en ikke-produktiv konto
  9. Immutability-policyer eller juridisk hold er satt på containere med revisjons- eller compliance-krav
  10. Kryptering med kundeadministrert nøkkel er verifisert, og Key Vault-tilgangen er korrekt tildelt
  11. Diagnostikklogger sendes til Log Analytics, og minst én varselregel er aktiv
  12. Eldre BlobStorage-kontotyper er identifisert og har en migreringsplan før oktober 2026

Ofte stilte spørsmål

Må jeg deaktivere delt nøkkeltilgang på alle kontoer?
Nei, men det anbefales sterkt for produksjonsmiljøer. Enkelte eldre verktøy og migreringsjobber støtter fortsatt bare kontonøkler, og da må du vurdere risikoen opp mot funksjonaliteten før du deaktiverer.

Hva skjer med applikasjoner som fortsatt bruker TLS 1.1 etter 3. februar 2026?
Tilkoblingen feiler på TLS-håndtrykket. Det finnes ingen unntaksmekanisme eller overgangsperiode per konto, så disse applikasjonene må oppgraderes før datoen, ikke etter.

Er prefiksbegrenset SAS forskjellig fra vanlig containerbasert SAS?
Ja. En vanlig SAS gir tilgang til hele containeren, mens en prefiksbegrenset User Delegation SAS begrenser tilgangen til objekter under en spesifikk bane, noe som gir langt finere kontroll over hva en ekstern part faktisk kan se.

Koster Defender for Storage ekstra for hver blob som skannes?
Defender for Storage prises basert på volum og omfang av skanningen. Den nye muligheten til å målrette skanning mot spesifikke blober, containere eller filandeler gjør det mulig å begrense kostnaden til det som faktisk trenger beskyttelse, i stedet for å betale for full kontoskanning.

Kan jeg bruke både tidsbasert immutability-policy og juridisk hold samtidig?
Ja, de to mekanismene fungerer uavhengig av hverandre og kan kombineres. Et juridisk hold fjernes manuelt, mens en tidsbasert policy utløper automatisk eller forblir låst til perioden er over.

Hva skjer med eldre “BlobStorage”-kontoer jeg ikke migrerer selv?
Microsoft migrerer dem automatisk til General Purpose v2 etter 13. oktober 2026. Automatisk migrering fungerer i de fleste tilfeller, men det er tryggere å teste migreringen selv i forkant enn å la den skje uovervåket i produksjon.

Må jeg bruke Terraform, eller holder Azure CLI?
Begge fungerer. Azure CLI er raskere for enkeltstående endringer og feilsøking, mens Terraform gir deg sporbar, versjonskontrollert infrastruktur som er lettere å gjenskape identisk på tvers av miljøer. Mange team bruker CLI-kommandoene fra denne guiden til å teste et konsept raskt, og porterer deretter det bekreftede oppsettet til Terraform-modulen før det rulles ut i produksjon.

Er Entra ID-basert SFTP-tilgang tilgjengelig i alle Azure-regioner?
Ja, funksjonen er generelt tilgjengelig i alle regioner, og støtter nå både Azure RBAC, attributtbasert tilgangskontroll og storage-ACL-er for SFTP-pålogging med Entra ID-identitet.

Påvirker Kerberos-endringen i juli 2026 alle Blob Storage-kontoer?
Endringen gjelder primært hybride oppsett som bruker Azure Files sammen med Active Directory Domain Services. Rene Blob Storage-kontoer uten Kerberos-autentisering påvirkes ikke direkte, men har du en lagringskonto med egendefinert DNS-suffiks eller egendefinert Kerberos-SPN, bør du verifisere oppsettet før april 2026-oppdateringen ruller ut.