Læsetid i minutter: 3
Hvordan kommer det til at påvirke min tenant?
Hvis du allerede følger ”best practice” og kræver MFA med enten Conditional Access-politikker eller igennem ”Security Defaults” for alle brugerkonti, der prøver at tilgå “All cloud resources”, eller bare “Microsoft Admin portals” og “Windows Azure Service Management API”, så vil du ikke bemærke effekten af denne ændring.
Men hvis din virksomhed for eksempel bruger Azure CLI eller Azure PowerShell-scripts med hardcoded brugerkonti logins, vil de blive blokeret fra at køre, da de ikke kan udføre MFA. Service Principals og Managed Identities er ikke påvirket af denne ændring og vil fortsætte med at køre som normalt.
Hvordan tjekker jeg hvilke konti, der er påvirket af dette?
Den nemmeste og mest simple måde at tjekke, om der er brugerkonti, der logger på via Azure PowerShell og Azure CLI uden at udføre MFA, er at tjekke sign-in logs.
Nedenfor er en vejledning til at tjekke de default sign-in logs, der gemmes én måned tilbage for alle brugere via Entra admin-portalen, og hvordan du det med fordel kan mitigere problemet ved brugen af Managed Identities.
Bemærk at, afhængigt af din opsætning kan der være konti, der kun bruges få gange om året, og som derfor ikke vises i loggen. Derfor er det vigtigt at eksportere sign-in logs og andre vigtige logs til en sikker lagringsløsning og opbevare dem i mere end 30 dage.
- Log ind på Microsoft Entra admin center og gå ind på Users > All users > Sign-in logs og skift ”Date” til “Last 1 month”
- Tryk på Download knappen og vælg “Download CSV” og så tryk Download på “InteractiveSignIns_...” og “NonInteractiveSingIns_...”
- Når du har downloadet CSV-filerne, importer dem ind i en Excel tabel og filtrér dem på ”Application ID” for:
04b07795-8ddb-461a-bbee-02f9e1bf7b46 (Azure CLI)
og
1950a258-227b-4e31-a9cf-717495945fc2 (Azure Powershell)
Nu har du sign-in logs for alle brugerkonti, der bruger de påvirkede apps. - Du kan nu gå til kolonnen “Authentication requirement” og filtrér den til “Single-factor authentication”
Så står du tilbage med en liste af standard brugerkonti, der ikke udfører MFA, når de logger på via de påvirkede apps. I det her eksempel er der en bruger ”nomfauser@mj-tech.dk” som logger på via Azure Powershell (Az-modulet) ”non-interactively” i vores test tenant.
Hvordan mitigerer jeg dette?
I stedet for at bruge standardbrugerkonti til at køre automatiske scripts, så anbefales det at benytte Service Principals eller Managed Identities til alle ikke-menneskelige login. Ideelt set bør Service Principals bruge certifikatautentificering eller secrets, der er gemt sikkert i en Azure Key Vault for eksempel.
Managed Identities kan logge ind uden at bruge secrets eller certifikater, hvis de logger på Azure-ressourcer såsom Automation Accounts, Logic Apps, Azure Virtual Machines og mange andre.
I dette eksempel bruges brugerkontoen “nomfauser@mj-tech.dk” til en Azure Automation Account Runbook. Nedenunder viser jeg, hvordan den kan konverteres til en mere sikker ”System Assigned Managed Identity” i stedet.
- Først gå til den specifikke Automation Account også Account Settings > Identity
- Tryk på “On” på Status indstillingen og bagefter “Save”, så vil du kunne se Object ID på Automation Account’ens Managed Identity.
- Giv den Managed Identity de nødvendige rettigheder, og husk at følge best practices og “principal of least privilege”.
Efter at man har givet de nødvendige rettigheder til den Managed Identity, så kan vi ændre det PowerShell script der bliver brugt af den gældende Runbook til at bruge den nye Managed Identity i stedet for brugerkontoen.
Forneden kan man se det usikre hardcoded bruger login, som scriptet lige nu bruger. - Ændre scriptet til at logge på via den Managed Identity vi lige har lavet ved at bruge “Connect-AzAccount -Identity”.
Og det var det. Nu bruger den Automation Account en Managed Identity i stedet for en usikker brugerkonto.
Hvis man ikke har nok tid eller ressourcer til at skifte alle påvirkede brugerkonti til Service Principals eller Managed Identities, så har man muligheden for at udskyde den obligatoriske MFA indtil den 30. september 2025 via dette link: https://aka.ms/managemfaforazure
Har du brug for hjælp til at sikre dine Microsoft 365-tjenester?
Husk at følge best practices, når det kommer til at opbevare Service Principal secrets sikkert og at følge “principal of least privilege”.
Hvis din organisation har brug for hjælp til at sikre jeres Microsoft 365 tjenester, Entra ID tenant eller Azure-ressourcer, kan I få både sikkerhedsvurderinger og hærdning hos vores Cyber Security. For yderligere information, læs mere på https://itm8.dk/cyber-security/identificer og https://itm8.dk/cyber-security/beskyt.