I augusti 2026 hittade säkerhetsföretaget Intruder att 98 procent av granskade molnkonton hade minst en felkonfigurerad identitets- och åtkomstinställning. För Azure specifikt var siffrorna ännu mer konkreta: 67 procent av kontona hade inte aktiverat nyckelrotation för lagringskonton, 66 procent tillät fortfarande åtkomst via delade nycklar i stället för Microsoft Entra ID, och 61 procent exponerade lagringskonton mot öppna nätverk. Det är inte exotiska brister. Det är standardinställningar som ingen ändrat.
Samtidigt fyllde CISA på sin KEV-katalog (Known Exploited Vulnerabilities) i rasande takt under juli och augusti. Den 18 augusti lades fyra nya sårbarheter till, bland annat en dubbelfri-bugg i Windows IKE-tjänsten (CVE-2026-33824, beskriven som wormable) och en autentiseringsbrist i Microsoft SharePoint (CVE-2026-55040) som enligt SecurityWeek utnyttjades inom några timmar efter att ett proof-of-concept publicerades. Många av dessa system pratar direkt med Azure-miljöer via hybrididentitet, service principals och lagringskonton. Om din identitetsplattform är svag spelar det ingen roll hur snabbt du patchar servern bredvid.
Den här guiden går igenom hur du härdar Azure-identitet och Azure Storage från grunden med Microsoft Entra ID, Conditional Access, Privileged Identity Management och Azure Policy. Du får 14 konkreta steg, färdiga CLI- och PowerShell-kommandon, en KQL-fråga för loggning i Sentinel, och ett komplett härdningsskript du kan köra rakt av mot en testprenumeration. Räkna med cirka 90 minuters aktiv arbetstid om du följer stegen i ordning.
Guiden riktar sig till dig som redan administrerar en Azure-prenumeration, oavsett om det är en enskild resursgrupp eller en hel tenant med flera hundra användare. Du behöver inte vara identitetsspecialist för att följa stegen, men grundläggande kunskap om Azure CLI och rollbaserad åtkomstkontroll (RBAC) gör det enklare att anpassa kommandona till din egen miljö. Varje avsnitt bygger vidare på föregående, så håll ordningen om du är ny på området. Har du redan implementerat vissa delar, exempelvis Conditional Access, går det utmärkt att hoppa direkt till de steg som saknas.
Vad är Microsoft Entra ID och varför spelar det roll för din säkerhet
Microsoft Entra ID är det namn Microsoft gett sin identitetsplattform sedan omdöpningen av Azure Active Directory. Namnbytet var inte kosmetiskt. Entra ID samlar identitetshantering, Conditional Access, Privileged Identity Management (PIM) och multifaktorautentisering under ett paraply som numera även täcker icke-Azure-resurser via Entra External ID och Entra Permissions Management. För dig som administratör betyder det att nästan varje säkerhetsbeslut i Azure numera går via samma identitetsnav, oavsett om du loggar in i portalen, kör ett CLI-kommando eller ett service principal-anrop från en pipeline.
Microsoft skriver själva i sin dokumentation att lagringskonton bör auktoriseras via Entra ID snarare än delade nycklar: “For optimal security, Microsoft recommends using Microsoft Entra ID with managed identities to authorize requests against blob, queue, and table data, whenever possible.” Rekommendationen är inte ny, men den blir mer akut i takt med att fler CVE:er kopplade till exponerade nycklar och överprivilegierade tjänstekonton dyker upp i CISA:s KEV-katalog. Grundprincipen den här guiden bygger på: identitet är den nya perimetern, och lagringskonton ska aldrig lita på en statisk nyckel när ett dynamiskt, granskningsbart Entra ID-token finns tillgängligt.
Praktiskt innebär det tre saker för resten av guiden. För det första flyttar vi autentisering från “shared key” till Entra ID-baserad RBAC. För det andra inför vi tidsbegränsad, godkänd åtkomst till privilegierade roller via PIM i stället för permanenta administratörsrättigheter. För det tredje kopplar vi ihop identitetshändelser med loggning så att avvikelser syns innan de blir en incident, inte efteråt.
Ordningen på dessa tre steg spelar roll. Många team gör misstaget att börja med loggning och larm, för att det känns tryggast, innan grundautentiseringen ens är fixad. Resultatet blir en larmbild full av brus från kända, redan identifierade svagheter, snarare än verkliga avvikelser. Stäng först hålen, sätt sedan upp bevakningen. Då blir varje larm faktiskt värt att undersöka.
Förutsättningar: verktyg, roller och versioner du behöver
Innan du börjar, se till att du har rätt verktyg installerade och rätt behörighet i prenumerationen. Guiden förutsätter att du har minst rollen Contributor på resursgruppsnivå och User Access Administrator eller Global Administrator i Entra ID för PIM-stegen. Testa gärna hela flödet i en separat testprenumeration innan du rör produktionsmiljön.
Räkna med olika tidsåtgång per steg beroende på miljöns storlek. Inventeringen i steg 1 tar några minuter oavsett antal konton, eftersom det bara är en läsoperation. Att stänga av delade nycklar och flytta appar till managed identity, steg 3 och 4, är den delen som tar längst tid i en miljö med många legacy-integrationer, ibland flera dagar utspritt över ett par veckor om ni har tiotals applikationer att migrera. Conditional Access och PIM, steg 5 och 6, går snabbt att konfigurera men bör observeras i rapportläge i minst en vecka innan de sätts skarpa.
| Verktyg | Lägsta version | Syfte i guiden |
|---|---|---|
| Azure CLI | 2.65 eller senare | Kör de flesta härdningskommandona (az storage, az role, az policy) |
| Az PowerShell-modul | 12.x eller senare | Conditional Access, PIM och Entra ID-specifika kommandon |
| Microsoft Graph PowerShell SDK | 2.2x eller senare | Läsa och skriva Conditional Access-policyer via Graph API |
| Azure-prenumeration | Pay-As-You-Go eller Enterprise Agreement | Krävs för Defender for Cloud och Azure Policy |
| Microsoft Entra ID P2 eller Microsoft 365 E5 | Aktuell licensnivå | Krävs för PIM och riskbaserad Conditional Access |
| jq | 1.7 eller senare | Tolka JSON-utdata i valideringsskripten |
Logga in innan du fortsätter:
az login --tenant "din-tenant.onmicrosoft.com"
az account set --subscription "Testprenumeration"
az account show --output tableOm kommandot ovan misslyckas med felet “AADSTS50076” behöver kontot ditt multifaktorautentisering, vilket normalt löses genom att köra az login igen i en webbläsare i stället för enhetskod-flödet.
Fundera också på vem i organisationen som ska äga det löpande arbetet efter första härdningsrundan. I mindre organisationer hamnar det ofta hos samma person som redan sköter Azure-driften, men i större bolag delas ansvaret vanligen mellan ett molnplattformsteam, som äger Azure Policy och infrastrukturkoden, och ett säkerhetsteam, som äger Conditional Access-policyer och granskning av Secure Score. Bestäm det innan ni börjar, annars riskerar härdningen att bli ett engångsprojekt som glöms bort så fort artikeln är läst.
Steg 1–2: Inventera miljön och sätt upp en granskningsroll
Steg 1: Kartlägg din identitetsyta. Innan du ändrar något behöver du veta vad som faktiskt finns. Lista alla lagringskonton, deras autentiseringsläge och vilka rolltilldelningar som pekar mot dem:
az storage account list \
--query "[].{Namn:name, ResursGrupp:resourceGroup, DeladNyckelTillåten:allowSharedKeyAccess, PublikÅtkomst:publicNetworkAccess}" \
--output tableEtt typiskt utdrag ur produktionen ser ofta ut så här, och det är precis det mönster Intruders undersökning pekade på:
Namn ResursGrupp DeladNyckelTillåten PublikÅtkomst
------------ -------------- --------------------- --------------
prodstorage1 rg-prod-app True Enabled
logsstorage2 rg-monitoring True Enabled
backupsa3 rg-backup False DisabledTvå av tre konton i exemplet tillåter fortfarande delade nycklar och publik åtkomst. Det är dem vi åtgärdar i nästa steg.
Steg 2: Skapa en dedikerad granskningsroll. Undvik att köra härdningsarbetet med ett permanent Owner-konto. Skapa i stället en anpassad roll med enbart de rättigheter som krävs för granskning och härdning, enligt principen om minsta möjliga privilegium som Microsoft själva lyfter fram i sin säkerhetsdokumentation: “Keep in mind the principle of least privilege when assigning permissions to a Microsoft Entra security principal via Azure RBAC.”
cat > security-auditor-role.json <<'EOF'
{
"Name": "Säkerhetsgranskare - Storage och Policy",
"IsCustom": true,
"Description": "Läs och härda lagringskonton samt tilldela policyer",
"Actions": [
"Microsoft.Storage/storageAccounts/read",
"Microsoft.Storage/storageAccounts/write",
"Microsoft.Authorization/policyAssignments/write",
"Microsoft.Authorization/roleAssignments/read"
],
"NotActions": [],
"AssignableScopes": ["/subscriptions/DIN-PRENUMERATIONS-ID"]
}
EOF
az role definition create --role-definition security-auditor-role.jsonSteg 3–4: Stäng av delade nycklar och tvinga Entra ID-autentisering
Steg 3: Inaktivera delad nyckel-åtkomst. Så länge ett lagringskonto tillåter "shared key"-autentisering fungerar en läckt nyckel som en permanent, ospårbar huvudnyckel. Microsofts egen rekommendation är tydlig: "Authorization with Microsoft Entra ID and managed identities provides superior security and ease of use over Shared Key authorization." Stäng av det per konto:
az storage account update \
--name prodstorage1 \
--resource-group rg-prod-app \
--allow-shared-key-access falseKör detta mot ett konto i taget, inte i en bulkoperation första gången. Applikationer som fortfarande använder anslutningssträngar med kontonyckel slutar fungera direkt, så testa i en icke-produktionsmiljö och bevaka felloggarna innan du rullar ut brett.
Steg 4: Tilldela Entra ID-roller för dataåtkomst. När delade nycklar är avstängda måste appar och användare i stället autentisera med Entra ID-identitet och få en explicit RBAC-roll för dataplanet, exempelvis Storage Blob Data Contributor:
az role assignment create \
--assignee "app-service-managed-identity-object-id" \
--role "Storage Blob Data Contributor" \
--scope "/subscriptions/DIN-ID/resourceGroups/rg-prod-app/providers/Microsoft.Storage/storageAccounts/prodstorage1"Använd i första hand en managed identity kopplad till App Service, Function App eller VM i stället för ett användarkonto. Managed identities roterar sina nycklar automatiskt och går inte att exportera, vilket eliminerar hela klassen av "läckt hemlighet i git-repo"-incidenter.
Steg 5–6: Conditional Access och Privileged Identity Management
Steg 5: Skapa en Conditional Access-policy för administratörskonton. Conditional Access utvärderar signaler som plats, enhetstillstånd och risknivå i realtid innan inloggningen godkänns. Skapa en policy som kräver multifaktorautentisering och en hanterad enhet för alla roller med administratörsbehörighet:
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"
$params = @{
DisplayName = "Kräv MFA och hanterad enhet för administratörer"
State = "enabledForReportingButNotEnforced"
Conditions = @{
Users = @{ IncludeRoles = @("62e90394-69f5-4237-9190-012177145e10") }
Applications = @{ IncludeApplications = @("All") }
}
GrantControls = @{
Operator = "AND"
BuiltInControls = @("mfa", "compliantDevice")
}
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $paramsNotera att policyn ovan startar i läget "enabledForReportingButNotEnforced" (rapportläge). Det är avsiktligt. Testa alltid en ny Conditional Access-policy i rapportläge i minst en vecka innan du sätter den till "enabled", annars riskerar du att låsa ute dig själv eller andra administratörer mitt i en arbetsdag.
Steg 6: Aktivera Privileged Identity Management för Just-In-Time-åtkomst. PIM gör att en administratörsroll är avaktiverad som standard och bara aktiveras tillfälligt, med godkännande och tidsgräns, när den faktiskt behövs. Det minskar attackytan dramatiskt jämfört med permanenta Global Administrator-tilldelningar:
Connect-MgGraph -Scopes "RoleManagement.ReadWrite.Directory"
$roleId = "62e90394-69f5-4237-9190-012177145e10" # Global Administrator
$assignment = @{
"@odata.type" = "#microsoft.graph.unifiedRoleEligibilityScheduleRequest"
Action = "AdminAssign"
Justification = "Kvartalsvis säkerhetsgranskning"
RoleDefinitionId = $roleId
PrincipalId = "objekt-id-för-administratör"
DirectoryScopeId = "/"
ScheduleInfo = @{
StartDateTime = "2026-08-29T08:00:00Z"
Expiration = @{ Type = "AfterDuration"; Duration = "PT8H" }
}
}
New-MgRoleManagementDirectoryRoleEligibilityScheduleRequest -BodyParameter $assignmentExemplet ger administratörsrollen aktiv i åtta timmar, vilket räcker för ett arbetspass, och kräver en ny begäran nästa dag. Kombinerat med Conditional Access-kravet på MFA blir en stulen lösenordshash i praktiken värdelös utan både enheten och godkännandeflödet.
När du kör kommandot ovan svarar Graph API med en bekräftelse på schemaläggningen. Ett lyckat svar ser ut ungefär så här:
Id Status RoleDefinitionId PrincipalId
---------------- -------- ------------------------------------ ------------------------------------
9f2a1c4e-8b3d-... Provisioned 62e90394-69f5-4237-9190-012177145e10 a1b2c3d4-e5f6-...Status "Provisioned" betyder att kontot nu är berättigat (eligible) men inte aktivt. Administratören måste själv aktivera rollen i Entra-portalen eller via ett eget API-anrop när den faktiskt behövs, och den aktiveringen kan i sin tur kräva ett godkännande från en utsedd godkännare om ni satt upp det i PIM-inställningarna.
Steg 7–8: Blockera publik åtkomst och rotera kvarvarande nycklar
Steg 7: Stäng publik nätverksåtkomst till lagringskonton. 61 procent av Azure-kontona i Intruders undersökning tillät fortfarande publik åtkomst till lagringskonton. Det innebär att kontot är nåbart från hela internet om inte brandväggsregler eller privata slutpunkter är konfigurerade. Byt till privat nätverksåtkomst:
az storage account update \
--name prodstorage1 \
--resource-group rg-prod-app \
--public-network-access Disabled \
--default-action Deny
az network private-endpoint create \
--name pe-prodstorage1-blob \
--resource-group rg-prod-app \
--vnet-name vnet-prod \
--subnet subnet-storage \
--private-connection-resource-id "/subscriptions/DIN-ID/resourceGroups/rg-prod-app/providers/Microsoft.Storage/storageAccounts/prodstorage1" \
--group-id blob \
--connection-name conn-prodstorage1Steg 8: Om delade nycklar fortfarande måste finnas kvar, rotera dem. I vissa äldre integrationer går det inte att stänga av delad nyckel-åtkomst omedelbart. Sätt då upp en rutin för regelbunden rotation, helst var 90:e dag, tills migreringen till Entra ID är klar:
az storage account keys renew \
--account-name logsstorage2 \
--resource-group rg-monitoring \
--key key1
az storage account keys renew \
--account-name logsstorage2 \
--resource-group rg-monitoring \
--key key2Rotera key1 och key2 vid olika tillfällen, aldrig samtidigt, så att applikationer som pekar på den ena nyckeln fortsätter fungera medan du uppdaterar konfigurationen för den andra.
Steg 9–10: Azure Policy och Microsoft Defender for Cloud
Steg 9: Förhindra att felkonfigurationen kommer tillbaka. Manuell härdning löser dagens problem men inte morgondagens nya resurs. Tilldela en inbyggd Azure Policy som nekar skapande av lagringskonton med delad nyckel-åtkomst aktiverad:
az policy assignment create \
--name "neka-delad-nyckel-storage" \
--display-name "Neka lagringskonton med delad nyckel-åtkomst" \
--policy "8c6a50c6-9ffd-4ae7-986f-5fa6111f9a54" \
--params '{"effect": {"value": "Deny"}}' \
--scope "/subscriptions/DIN-PRENUMERATIONS-ID"Steg 10: Aktivera Microsoft Defender for Cloud. Defender for Cloud ger ett kontinuerligt säkerhetsbetyg (Secure Score) och flaggar nya felkonfigurationer automatiskt. Aktivera Defender-planen för lagring och identitet:
az security pricing create --name StorageAccounts --tier Standard
az security pricing create --name Identity --tier Standard
az security auto-provisioning-setting update --name default --auto-provision onEtt Secure Score under 60 procent är ett tydligt tecken på att grundhärdningen inte är klar. Efter stegen ovan brukar de flesta miljöer landa mellan 75 och 90 procent, beroende på hur många legacy-integrationer som fortfarande kräver delade nycklar.
Steg 11–12: Logga med Sentinel och bygg ett incidentflöde kopplat till CISA KEV
Steg 11: Koppla identitetsloggar till Log Analytics. Utan loggning ser du inte om härdningen faktiskt håller. Skicka Entra ID-inloggningsloggar och Azure Activity Log till en Log Analytics-arbetsyta:
az monitor diagnostic-settings create \
--name "entra-sign-in-logs" \
--resource "/providers/Microsoft.aadiam" \
--workspace "/subscriptions/DIN-ID/resourceGroups/rg-monitoring/providers/Microsoft.OperationalInsights/workspaces/law-security" \
--logs '[{"category": "SignInLogs", "enabled": true}, {"category": "AuditLogs", "enabled": true}]'Steg 12: Skriv en KQL-fråga som hittar avvikande inloggningar. Ett bra första steg är att jaga inloggningar som klassas som riskfyllda av Entra ID Protection, eller inloggningar från länder ni normalt inte har verksamhet i:
SigninLogs
| where TimeGenerated > ago(24h)
| where RiskLevelDuringSignIn in ("medium", "high")
or Location !in ("SE", "NO", "DK", "FI")
| summarize AntalFörsök = count() by UserPrincipalName, Location, RiskLevelDuringSignIn
| order by AntalFörsök descBygg ett larm på frågan ovan och koppla det till samma "patch, then assume compromise"-tänk som präglade CISA:s KEV-uppdatering den 18 augusti. Efter att ha patchat de fyra sårbarheterna i vCenter, SharePoint, Windows IKE och macOS Screen Sharing rekommenderade säkerhetsbranschen att organisationer aktivt letar efter tecken på att ett intrång redan skett, inte bara stänger dörren. Samma logik gäller identitet: att stänga av delade nycklar räcker inte om en angripare redan hunnit skapa en bakdörr via en överprivilegierad service principal.
Steg 13–14: Validera härdningen och mät resultatet
Steg 13: Kör en valideringssvep över alla lagringskonton. Bekräfta att inga konton missades:
az storage account list --query "[].{Namn:name, DeladNyckel:allowSharedKeyAccess, Publik:publicNetworkAccess}" -o json \
| jq -r '.[] | select(.DeladNyckel==true or .Publik=="Enabled") | .Namn'Om kommandot inte returnerar något alls är alla konton i miljön härdade. Returnerar det namn, är de kvarvarande kontona din prioriterade lista för nästa körning.
Steg 14: Dokumentera och mät Secure Score över tid. Hämta det aktuella säkerhetsbetyget och spara det som baslinje inför nästa granskning:
az security secure-scores list --output tableEtt typiskt resultat direkt efter härdningen:
Name DisplayName Score.Current Score.Max
---------------- ----------------- ------------- ---------
ascScore Säkerhetspoäng 78.4 100.0Sätt ett kalenderpåminnelse att köra samma valideringssvep varje kvartal. Nya lagringskonton, nya utvecklare och nya integrationer introducerar löpande nya avvikelser, oavsett hur bra policyn är från början.
CISA KEV-sårbarheter från juli–augusti 2026 med koppling till Azure-miljöer
Tabellen nedan sammanfattar varför identitetshärdning inte är ett teoretiskt övningsprojekt. Varje rad är en sårbarhet CISA bekräftat aktivt utnyttjas, med produkter som ofta pratar direkt med Azure via hybrididentitet, agenter eller service principals.
Mönstret som går igen i listan är tydligt. Det handlar sällan om exotiska nolldagarsattacker mot själva Azure-plattformen. I stället är det angränsande system, VMware-infrastruktur, samarbetsverktyg, ML-plattformar och SD-WAN-utrustning, som fungerar som inkörsport. När de systemen faller och har en identitet med breda rättigheter kvar mot molnet, blir konsekvensen densamma som om Azure-plattformen själv hade en brist. Det är därför identitetshärdning bör prioriteras minst lika högt som traditionell patchhantering, snarare än att ses som ett separat spår.
| CVE | Produkt | CVSS | Tillagd i KEV | Relevans för Azure-miljöer |
|---|---|---|---|---|
| CVE-2026-33824 | Windows IKE Service Extension | 9,8 | 18 aug 2026 | Wormable RCE på hybrid-anslutna Windows-servrar |
| CVE-2026-55040 | Microsoft SharePoint Server | 9,1 | 18 aug 2026 | Autentiseringsbrist, exploaterad inom timmar efter PoC |
| CVE-2026-59310 | Broadcom VMware vCenter | hög | 18 aug 2026 | Kompromitterade hundratals servrar i 47 länder |
| CVE-2026-65400 | Apple macOS Screen Sharing | hög | 18 aug 2026 | Utnyttjas för att installera kryptomineringsprogram |
| CVE-2025-62593 | Ray (AI compute framework) | 8,8 / 9,4 | 17 aug 2026 | Körs ofta på Kubernetes-kluster kopplade till Azure-hemligheter |
| CVE-2026-64849 | MLflow | 9,3 | 19 aug 2026 | ML-plattform med ofta överprivilegierade tjänstekonton |
| CVE-2026-16812 | VMware VeloCloud Orchestrator | 10,0 | Slutet av juli 2026 | SD-WAN-kant mot Azure, aktivt utnyttjad |
Notera att flera av dessa produkter i sig inte är "Azure-tjänster", men i praktiken exponerar de ofta autentiseringsuppgifter, tjänstekonton eller nätverksvägar rakt in i en Azure-tenant. Ett komprometterat vCenter kan till exempel innehålla lagrade autentiseringsuppgifter för hybrididentitet. Ett MLflow-kluster kan ha en managed identity med skrivrättigheter till produktionslagring. Härdningen i den här guiden minskar skadan om en av dessa system faller, eftersom identitet med minsta privilegium och tidsbegränsad åtkomst begränsar vad en angripare faktiskt kan göra vidare.
Ett konkret exempel är CVE-2026-59310 i VMware vCenter, som redan hade kompromitterat servrar i 47 länder när CISA lade till den i KEV-katalogen. Ett typiskt vCenter i en nordisk hybridmiljö har ofta en tjänstekonto-koppling mot Entra ID för synkronisering av grupper och behörigheter. Om det kontot råkar ha en permanent, bred rolltilldelning i stället för en tidsbegränsad, avgränsad roll, blir vCenter-intrånget automatiskt en väg vidare in i molnmiljön. Det är exakt den typen av kedjereaktion PIM och Conditional Access är designade för att bryta.
Bicep-mall: automatisera härdningen som Infrastructure-as-Code
Att köra CLI-kommandon manuellt fungerar bra för en engångshärdning, men för nya lagringskonton som skapas löpande bör härdningen ligga inbyggd i infrastrukturkoden från start. Nedan är en Bicep-mall som skapar ett lagringskonto med delad nyckel-åtkomst avstängd, publik nätverksåtkomst nekad och en privat slutpunkt kopplad, redan vid provisionering:
param storageAccountName string
param location string = resourceGroup().location
param vnetId string
param subnetId string
resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
name: storageAccountName
location: location
sku: { name: 'Standard_LRS' }
kind: 'StorageV2'
properties: {
allowSharedKeyAccess: false
publicNetworkAccess: 'Disabled'
networkAcls: {
defaultAction: 'Deny'
}
minimumTlsVersion: 'TLS1_2'
}
}
resource privateEndpoint 'Microsoft.Network/privateEndpoints@2023-05-01' = {
name: 'pe-${storageAccountName}-blob'
location: location
properties: {
subnet: { id: subnetId }
privateLinkServiceConnections: [
{
name: 'conn-${storageAccountName}'
properties: {
privateLinkServiceId: storageAccount.id
groupIds: ['blob']
}
}
]
}
}Distribuera mallen med Azure CLI:
az deployment group create \
--resource-group rg-prod-app \
--template-file storage-hardened.bicep \
--parameters storageAccountName=prodstorage2 vnetId="/subscriptions/DIN-ID/.../vnet-prod" subnetId="/subscriptions/DIN-ID/.../subnet-storage"Fördelen är att varje nytt lagringskonto som skapas via den här mallen redan uppfyller kraven i steg 3 och 7, utan att någon behöver komma ihåg att köra härdningsskriptet manuellt efteråt. Lägg gärna mallen i samma repo som resten av infrastrukturkoden och kör den genom en pipeline med granskning innan den appliceras mot produktion.
Innan ni kör en Bicep-mall mot en delad miljö, validera alltid ändringen med what-if så att ni ser exakt vad som kommer skapas, ändras eller tas bort:
az deployment group what-if \
--resource-group rg-prod-app \
--template-file storage-hardened.bicep \
--parameters storageAccountName=prodstorage2 vnetId="/subscriptions/DIN-ID/.../vnet-prod" subnetId="/subscriptions/DIN-ID/.../subnet-storage"Kommandot körs utan att faktiskt ändra något och listar varje resurs som påverkas, markerad med plus för nya resurser och en ändringspil för uppdaterade egenskaper. Gör det till standardrutin i pipelinen innan varje driftsättning, oavsett hur liten ändringen verkar.
Vanliga fallgropar när du härdar Azure IAM och Storage
De flesta misslyckade härdningsförsök beror inte på tekniska hinder utan på ordningen saker görs i. Här är de fallgropar som återkommer oftast när team genomför den här typen av projekt.
- Att stänga delade nycklar utan att först kartlägga beroenden. Äldre integrationer, exempelvis Azure Data Factory-kopplingar eller tredjepartsbackup-verktyg, använder ofta fortfarande anslutningssträngar. Kartlägg alltid innan du släcker, annars stannar batch-jobb och backuper upp utan förvarning.
- Att sätta Conditional Access direkt i "enabled"-läge. Ett stavfel i villkoret kan låsa ute samtliga administratörer samtidigt. Kör alltid en vecka i rapportläge först och granska loggen för vilka inloggningar som hade blockerats.
- Att glömma break-glass-konton. Om alla administratörskonton kräver MFA och en hanterad enhet, behöver du minst två undantagna nödkonton med extremt starka lösenord förvarade offline, annars riskerar du att låsa er själva ute helt vid ett Entra ID-driftstopp eller ett problem med MFA-leverantören.
- Att rotera båda lagringsnycklarna samtidigt. Det stänger av all åtkomst momentant för alla system som fortfarande använder nycklar. Rotera key1 och key2 vid separata tillfällen, med minst några dagars mellanrum så att ni hinner verifiera att inget bröts.
- Att anta att Azure Policy med effekten "Audit" räcker. Audit-läge loggar bara avvikelsen, det stoppar inget. Byt till "Deny" när ni är säkra på att policyn inte stör legitima arbetsflöden.
- Att härda produktion före test. Alla stegen i den här guiden bör köras i en testprenumeration eller mot en enskild resursgrupp först, med minst en vecka observation innan bredare utrullning.
- Att strunta i licensläget innan PIM konfigureras. Utan Entra ID P2 eller Microsoft 365 E5 går det inte att aktivera Just-In-Time-roller alls, vilket upptäcks först mitt i utrullningen om ingen kontrollerat licensen i förväg.
Felsökning: 8 vanliga fel och hur du löser dem
Även med stegen ovan i rätt ordning stöter de flesta på minst ett av felen nedan under en härdningsomgång. Ingen av dem är allvarlig om du vet vad du letar efter, men de kan kosta timmar att felsöka blint. Spara tabellen som referens innan du kör igenom stegen på egen hand.
| Felmeddelande / Symptom | Trolig orsak | Lösning |
|---|---|---|
| AuthorizationPermissionMismatch vid blob-åtkomst | Managed identity saknar RBAC-roll på dataplanet | Tilldela Storage Blob Data Contributor eller Reader på rätt scope |
| InsufficientAccountPermissions vid --allow-shared-key-access false | Kontot du kör kommandot med saknar Contributor-rollen | Kontrollera rolltilldelning med az role assignment list |
| Applikationen slutar fungera direkt efter nyckelrotation | Konfigurationen pekar fortfarande på den gamla nyckeln | Uppdatera Key Vault-referensen eller App Setting innan nästa rotation |
| Conditional Access-policy blockerar alla, inklusive dig själv | Policyn sattes till "enabled" utan test i rapportläge | Logga in med break-glass-kontot och sätt policyn till rapportläge igen |
| PIM-aktivering nekas med "Insufficient privileges" | Kontot saknar Entra ID P2-licens | Verifiera licensnivå i Microsoft 365 admin-center |
| Privat slutpunkt får inte DNS-namnet att peka rätt | Privat DNS-zon är inte länkad till rätt virtuellt nätverk | Skapa och länka en privat DNS-zon för privatelink.blob.core.windows.net |
| Azure Policy-tilldelning triggar inte på befintliga resurser | Policyn utvärderar bara nya eller ändrade resurser som standard | Kör az policy state trigger-scan manuellt för att skanna befintliga resurser |
| KQL-frågan i Sentinel returnerar inga rader alls | Diagnostikinställningen för SignInLogs är inte aktiverad | Kontrollera med az monitor diagnostic-settings list att loggkategorin är på |
Avancerade tips för nordiska organisationer med hybridmiljöer
Många svenska och nordiska organisationer kör hybridmiljöer där lokala Active Directory-domäner synkas till Entra ID via Entra Connect. I det läget räcker det inte att härda molnsidan. En komprometterad domänkontrollant på plats kan fortfarande syncas upp och skapa eller ändra molnidentiteter. Aktivera Entra ID Protection med policyn "risky sign-ins" satt till automatisk blockering för konton som synkas från lokal AD, och separera administratörskonton för molnet helt från de som används lokalt, så kallade "cloud-only admins".
Ett annat tips: koppla ihop Azure Policy-efterlevnad med NIS2-rapporteringen om organisationen faller under lagen. Många svenska bolag med 250 eller fler anställda, eller de som klassas som väsentliga eller viktiga entiteter, måste kunna visa upp dokumenterade säkerhetsåtgärder vid en eventuell tillsyn. Ett Secure Score-diagram och en policyefterlevnadsrapport från Defender for Cloud fungerar som konkret bevis i det sammanhanget, inte bara som internt KPI.
Slutligen: sätt upp automatiserad drift genom Azure Policy i "DeployIfNotExists"-läge för nya resurser i stället för att bara neka dem. En Deny-policy stoppar en felkonfigurerad resurs, men en DeployIfNotExists-policy kan proaktivt koppla på diagnostikinställningar, privata slutpunkter eller taggning automatiskt när resursen skapas, vilket sparar avsevärd tid jämfört med manuell efterkorrigering varje kvartal.
Tänk också på kostnadsbilden. Microsoft Defender for Cloud debiteras per resurs och plan, så aktivera bara de planer ni faktiskt tänker agera på. Att slå på samtliga Defender-planer på en gång utan att ha en process för att hantera larmen leder ofta till att teamet ignorerar dem efter några veckor, vilket är sämre än att inte ha larmen alls. Börja med planerna för Storage och Identity som beskrivs i steg 10, utvärdera hur mycket tid teamet lägger på att triagera larmen under en månad, och utöka därefter stegvis till fler Defender-planer om kapaciteten finns.
För organisationer med flera prenumerationer, vanligt i större nordiska koncerner med separata miljöer för olika dotterbolag, går det att tilldela både Azure Policy och Defender-planerna på Management Group-nivå i stället för per prenumeration. Det säkerställer att en ny prenumeration som skapas nästa kvartal ärver samma härdningsbaslinje automatiskt, utan att någon behöver komma ihåg att köra igenom stegen i den här guiden manuellt varje gång.
Tänk också på loggretention. Om organisationen omfattas av NIS2 eller motsvarande nordisk cybersäkerhetslagstiftning krävs ofta att incidentrelaterade loggar går att spåra tillbaka en längre period än Log Analytics standardinställning på 30 dagar. Höj retention till minst 90 dagar för SignInLogs och AuditLogs, och exportera gärna en kopia till ett separat, skrivskyddat lagringskonto för längre arkivering. Det är billigare att göra det i förväg än att förklara för en tillsynsmyndighet varför loggarna för incidentdatumet redan rensats bort.
Komplett exempelprojekt: härdningsskript från början till slut
Nedan är ett komplett bash-skript som kedjar ihop stegen från guiden. Kör det mot en testprenumeration, granska varje rad, och anpassa resursnamnen innan du använder det i produktion.
#!/usr/bin/env bash
set -euo pipefail
SUBSCRIPTION="Testprenumeration"
RESOURCE_GROUP="rg-prod-app"
STORAGE_ACCOUNTS=("prodstorage1" "logsstorage2")
az account set --subscription "$SUBSCRIPTION"
echo "== Steg 1: Inventering =="
az storage account list \
--query "[].{Namn:name, DeladNyckel:allowSharedKeyAccess, Publik:publicNetworkAccess}" \
--output table
for ACCOUNT in "${STORAGE_ACCOUNTS[@]}"; do
echo "== Härdar $ACCOUNT =="
echo "-- Steg 3: Stänger delad nyckel-åtkomst --"
az storage account update \
--name "$ACCOUNT" \
--resource-group "$RESOURCE_GROUP" \
--allow-shared-key-access false
echo "-- Steg 7: Blockerar publik nätverksåtkomst --"
az storage account update \
--name "$ACCOUNT" \
--resource-group "$RESOURCE_GROUP" \
--public-network-access Disabled \
--default-action Deny
done
echo "== Steg 9: Tilldelar Azure Policy =="
az policy assignment create \
--name "neka-delad-nyckel-storage" \
--display-name "Neka lagringskonton med delad nyckel-åtkomst" \
--policy "8c6a50c6-9ffd-4ae7-986f-5fa6111f9a54" \
--params '{"effect": {"value": "Deny"}}' \
--scope "/subscriptions/$(az account show --query id -o tsv)"
echo "== Steg 10: Aktiverar Defender for Cloud =="
az security pricing create --name StorageAccounts --tier Standard
az security pricing create --name Identity --tier Standard
echo "== Steg 13: Validerar resultatet =="
az storage account list --query "[].{Namn:name, DeladNyckel:allowSharedKeyAccess, Publik:publicNetworkAccess}" -o json \
| jq -r '.[] | select(.DeladNyckel==true or .Publik=="Enabled") | .Namn' > kvarstaende-konton.txt
if [ -s kvarstaende-konton.txt ]; then
echo "Följande konton kräver manuell uppföljning:"
cat kvarstaende-konton.txt
else
echo "Alla lagringskonton är härdade."
fiSkriptet är medvetet återstartbart. Kör det igen efter att du lagt till nya lagringskonton så fångas de upp av samma logik, och valideringssteget i slutet fungerar som en enkel kvitto-lista för varje körning.
Så mäter du effekten efter härdningen
Effekten av det här arbetet syns bäst i tre mätpunkter över tid: Secure Score i Defender for Cloud, andelen lagringskonton med delad nyckel-åtkomst inaktiverad, och antalet permanenta (inte tidsbegränsade) administratörstilldelningar i Entra ID. Sätt upp en enkel månadsrapport som drar ut dessa tre siffror automatiskt:
echo "Secure Score:"
az security secure-scores list --query "[0].score.current" -o tsv
echo "Andel konton utan delad nyckel:"
TOTAL=$(az storage account list --query "length(@)" -o tsv)
HARDENED=$(az storage account list --query "length([?allowSharedKeyAccess==\`false\`])" -o tsv)
echo "$HARDENED av $TOTAL konton härdade"
echo "Permanenta administratörstilldelningar:"
az role assignment list --role "Global Administrator" --query "length(@)" -o tsvDe flesta team som infört den här härdningen från grunden rapporterar att antalet permanenta administratörstilldelningar går från tvåsiffrigt till enstaka inom en till två månader, i takt med att PIM tar över för de roller som bara behövs sporadiskt. Sätt gärna dessa tre mätpunkter i samma dashboard som ni redan använder för drift och tillgänglighet, så att säkerhetsläget blir lika synligt som svarstider och feltal, i stället för att bara dyka upp i en separat rapport ingen läser förrän något gått fel.
Vanliga frågor
Måste jag stänga av delade nycklar på alla lagringskonton samtidigt?
Nej. Gå igenom kontona ett i taget, börja med de som har lägst risk och minst antal beroenden. Ett konto med bara interna backuper är säkrare att börja med än ett som exponerar en publik API.
Kostar Microsoft Entra ID P2 extra utöver en vanlig Azure-prenumeration?
Ja, PIM och riskbaserad Conditional Access kräver Entra ID P2-licens eller Microsoft 365 E5, som är separata licenser från grundläggande Azure-resursanvändning. Kontrollera aktuell licensnivå i er tenant innan ni planerar utrullning.
Vad händer om jag råkar låsa ute alla administratörer med en Conditional Access-policy?
Det är precis därför break-glass-konton ska finnas. De ska vara undantagna från alla Conditional Access-policyer, ha extremt starka lösenord som inte är sparade i en delad lösenordshanterare, och övervakas separat så att varje inloggning med dem triggar en varning.
Räcker Azure Policy i "Audit"-läge som skydd?
Nej. Audit-läge upptäcker och loggar avvikelsen men stoppar inte att en felkonfigurerad resurs skapas. Använd Audit under testperioden för att se vad policyn faktiskt skulle blockera, byt sedan till Deny för permanent skydd.
Hur ofta bör jag köra valideringsskriptet i guiden?
Minst en gång per kvartal, och gärna som en schemalagd uppgift i en pipeline. Nya resurser och nya integrationer introducerar löpande nya avvikelser oavsett hur bra grundkonfigurationen är.
Påverkar den här härdningen prestanda för applikationer som använder lagringskontona?
Entra ID-baserad autentisering lägger till en tokenvalidering per anrop, men i praktiken är skillnaden marginell för de flesta arbetsbelastningar. Den större omställningen är utvecklingsarbetet att byta anslutningslogik från kontonyckel till managed identity, inte runtime-prestandan.
Fungerar guiden även för Azure Government eller andra suveräna moln?
Grundprinciperna gäller, men vissa policy-ID:n och API-slutpunkter skiljer sig mellan Azure Commercial och suveräna moln. Kontrollera alltid att policy-definitionens ID existerar i er specifika molnmiljö innan ni tilldelar den.
Kan jag använda samma härdning om jag kör en hybridmiljö med lokal Active Directory?
Ja, men behandla den lokala AD-domänen som en del av attackytan, inte som en separat värld. Se till att konton som synkas via Entra Connect har samma krav på stark autentisering som molnfödda konton, och håll cloud-only-administratörer helt separerade från konton som synkas från den lokala domänen.
Behöver jag Microsoft Sentinel, eller räcker ren Log Analytics för loggningen i guiden?
Log Analytics räcker för att lagra loggarna och köra KQL-frågorna manuellt, vilket är tillräckligt för en mindre miljö. Sentinel lägger till automatiserade spelböcker, inbyggda regler för avvikelsedetektering och en central vy för incidenthantering, vilket blir mer värt ju fler system och signaler ni behöver korrelera.
