Microsoft Entra-säkerhetsåtgärder för användarkonton

Användaridentitet är en av de viktigaste aspekterna för att skydda din organisation och dina data. Den här artikeln innehåller vägledning för att övervaka kontoskapande, borttagning och kontoanvändning. Den första delen beskriver hur du övervakar för ovanligt kontoskapande och borttagning. Den andra delen beskriver hur du övervakar för ovanlig kontoanvändning.

Om du ännu inte har läst översikten över Microsoft Entra-säkerhetsåtgärder rekommenderar vi att du gör det innan du fortsätter.

Den här artikeln beskriver allmänna användarkonton. För privilegierade konton, se Säkerhetsåtgärder – privilegierade konton.

Definiera en baslinje

För att identifiera avvikande beteende måste du först definiera vad normalt och förväntat beteende är. Genom att definiera vad som förväntas för din organisation kan du avgöra när ett oväntat beteende inträffar. Definitionen hjälper också till att minska brusnivån för falska positiva identifieringar vid övervakning och aviseringar.

När du har definierat vad du förväntar dig utför du baslinjeövervakning för att verifiera dina förväntningar. Med den informationen kan du övervaka loggarna för allt som ligger utanför de toleranser som du definierar.

Använd Microsoft Entra-granskningsloggar, Microsoft Entra-inloggningsloggar och katalogattribut som datakällor för konton som skapats utanför normala processer. Följande är förslag som hjälper dig att tänka på och definiera vad som är normalt för din organisation.

• Skapa användarkonto – utvärdera följande:

  • Strategi och principer för verktyg och processer som används för att skapa och hantera användarkonton. Det finns till exempel standardattribut, format som tillämpas på användarkontoattribut.

  • Godkända källor för kontoskapande. Till exempel med ursprung i Active Directory (AD), Microsoft Entra-ID eller HR-system som Workday.

  • Aviseringsstrategi för konton som skapats utanför godkända källor. Finns det en kontrollerad lista över organisationer som din organisation samarbetar med?

  • Etablering av gästkonton och aviseringsparametrar för konton som skapats utanför berättigandehantering eller andra normala processer.

  • Strategi- och aviseringsparametrar för konton som skapats, ändrats eller inaktiverats av ett konto som inte är en godkänd användaradministratör.

  • Övervaknings- och aviseringsstrategi för konton som saknar standardattribut, till exempel medarbetar-ID eller som inte följer organisationens namngivningskonventioner.

  • Strategi, principer och process för borttagning och kvarhållning av konton.

• Lokala användarkonton – utvärdera följande för konton som synkroniserats med Microsoft Entra Connect:

  • Skogar, domäner och organisationsenheter (OUs) i omfånget för synkronisering. Vilka är de godkända administratörerna som kan ändra de här inställningarna och hur ofta kontrolleras omfånget?

  • De typer av konton som synkroniseras. Till exempel användarkonton och eller tjänstkonton.

  • Processen för att skapa privilegierade lokala konton och hur synkroniseringen av den här typen av konto styrs.

  • Processen för att skapa lokala användarkonton och hur synkroniseringen av den här typen av konto hanteras.

Mer information om hur du skyddar och övervakar lokala konton finns i Skydda Microsoft 365 från lokala attacker.

• Molnanvändarkonton – utvärdera följande:

  • Processen för att etablera och hantera molnkonton direkt i Microsoft Entra-ID.

  • Processen för att fastställa vilka typer av användare som etablerats som Microsoft Entra-molnkonton. Tillåter du till exempel bara privilegierade konton eller tillåter du även användarkonton?

  • Processen för att skapa och underhålla en lista över betrodda individer och eller processer som förväntas skapa och hantera molnanvändarkonton.

  • Processen för att skapa och underhålla en aviseringsstrategi för icke-godkända molnbaserade konton.

Var du ska titta

Loggfilerna som du använder för undersökning och övervakning är:

• Microsoft Entra-granskningsloggar

• Inloggningsloggar

• Microsoft 365-granskningsloggar

• Azure Key Vault-loggar

• Logg över riskfyllda användare

• UserRiskEvents-logg

Från Azure Portal kan du visa Microsoft Entra-granskningsloggarna och ladda ned som kommaavgränsade värdefiler (CSV) eller JSON-filer (JavaScript Object Notation). Azure Portal har flera sätt att integrera Microsoft Entra-loggar med andra verktyg som möjliggör större automatisering av övervakning och aviseringar:

• Microsoft Sentinel – möjliggör intelligent säkerhetsanalys på företagsnivå genom att tillhandahålla siem-funktioner (säkerhetsinformation och händelsehantering).

• Sigma-regler – Sigma är en utvecklande öppen standard för att skriva regler och mallar som automatiserade hanteringsverktyg kan använda för att parsa loggfiler. Där Sigma-mallar finns för våra rekommenderade sökvillkor har vi lagt till en länk till Sigma-lagringsplatsen. Sigma-mallarna skrivs, testas och hanteras inte av Microsoft. Lagringsplatsen och mallarna skapas och samlas i stället in av den globala IT-säkerhetscommunityn.

• Azure Monitor – möjliggör automatisk övervakning och avisering av olika villkor. Kan skapa eller använda arbetsböcker för att kombinera data från olika källor.

• Azure Event Hubs integrerat med en SIEM – Microsoft Entra-loggar kan integreras med andra SIEM:er som Splunk, ArcSight, QRadar och Sumo Logic via Azure Event Hubs-integreringen.

• Microsoft Defender för molnet-appar – gör att du kan identifiera och hantera appar, styra mellan appar och resurser och kontrollera dina molnappars efterlevnad.

• Skydda arbetsbelastningsidentiteter med Microsoft Entra ID Protection – Används för att identifiera risker för arbetsbelastningsidentiteter för inloggningsbeteende och offlineindikatorer för kompromisser.

Mycket av det du kommer att övervaka och varna för är effekterna av dina principer för villkorsstyrd åtkomst. Du kan använda insikter och rapporteringsarbetsbok för villkorsstyrd åtkomst för att undersöka effekterna av en eller flera principer för villkorsstyrd åtkomst på dina inloggningar och resultatet av principer, inklusive enhetstillstånd. Med den här arbetsboken kan du visa en sammanfattning och identifiera effekterna under en viss tidsperiod. Du kan också använda arbetsboken för att undersöka inloggningar för en viss användare.

Resten av den här artikeln beskriver vad vi rekommenderar att du övervakar och aviserar på och ordnas efter typ av hot. Där det finns specifika fördefinierade lösningar länkar vi till dem eller tillhandahåller exempel som följer tabellen. Annars kan du skapa aviseringar med hjälp av föregående verktyg.

Skapa konto

Skapande av avvikande konton kan tyda på ett säkerhetsproblem. Kortlivade konton, konton som inte följer namngivningsstandarder och konton som skapats utanför normala processer bör undersökas.

Kortlivade konton

Kontoskapande och borttagning utanför normala identitetshanteringsprocesser bör övervakas i Microsoft Entra-ID. Kortlivade konton är konton som skapas och tas bort på kort tid. Den här typen av kontoskapande och snabb borttagning kan innebära att en felaktig aktör försöker undvika identifiering genom att skapa konton, använda dem och sedan ta bort kontot.

Kortlivade kontomönster kan tyda på att icke-godkända personer eller processer kan ha rätt att skapa och ta bort konton som ligger utanför etablerade processer och principer. Den här typen av beteende tar bort synliga markörer från katalogen.

Om dataspåret för att skapa och ta bort konton inte upptäcks snabbt kanske den information som krävs för att undersöka en incident inte längre finns. Till exempel kan konton tas bort och sedan rensas från papperskorgen. Granskningsloggar behålls i 30 dagar. Du kan dock exportera loggarna till Azure Monitor eller en SIEM-lösning (säkerhetsinformation och händelsehantering) för långsiktig kvarhållning.

Både privilegierade och icke-privilegierade konton bör övervakas och aviseras. Men eftersom privilegierade konton har administrativa behörigheter bör de ha högre prioritet i dina processer för övervakning, avisering och svar.

Konton som inte följer namngivningsprinciper

Användarkonton som inte följer namngivningsprinciper kan ha skapats utanför organisationens principer.

Bästa praxis är att ha en namngivningsprincip för användarobjekt. Att ha en namngivningsprincip gör hanteringen enklare och ger konsekvens. Principen kan också hjälpa dig att identifiera när användare har skapats utanför godkända processer. En dålig aktör kanske inte känner till dina namngivningsstandarder och kan göra det lättare att identifiera ett konto som etablerats utanför organisationens processer.

Organisationer tenderar att ha specifika format och attribut som används för att skapa användare och eller privilegierade konton. Till exempel:

• Administratörskonto UPN = ADM_firstname.lastname@tenant.onmicrosoft.com

• ANVÄNDARKONTO UPN = Firstname.Lastname@contoso.com

Användarkonton har ofta ett attribut som identifierar en riktig användare. Till exempel EMPID = XXXNNN. Använd följande förslag för att definiera det normala för din organisation och när du definierar en baslinje för loggposter när konton inte följer din namngivningskonvention:

• Konton som inte följer namngivningskonventionen. Till exempel jämfört nnnnnnn@contoso.com med firstname.lastname@contoso.com.

• Konton som inte har standardattributen ifyllda eller som inte har rätt format. Du kan till exempel inte ha ett giltigt medarbetar-ID.

Mer information om parsning finns i:

• Microsoft Entra-granskningsloggar – Parsa textdata i Azure Monitor-loggar

• Azure-prenumerationer – Lista Azure-rolltilldelningar med Hjälp av Azure PowerShell

• Microsoft Entra-ID – Lista rolltilldelningar för Microsoft Entra

Konton som skapats utanför normala processer

Det är viktigt att ha standardprocesser för att skapa användare och privilegierade konton så att du på ett säkert sätt kan kontrollera identiteternas livscykel. Om användare etableras och avetableras utanför etablerade processer kan det medföra säkerhetsrisker. Att arbeta utanför etablerade processer kan också medföra problem med identitetshantering. Potentiella risker är:

• Användarkonton och privilegierade konton kanske inte styrs för att följa organisationens principer. Detta kan leda till en bredare attackyta på konton som inte hanteras korrekt.

• Det blir svårare att identifiera när dåliga aktörer skapar konton i skadliga syften. Genom att ha giltiga konton som skapats utanför etablerade procedurer blir det svårare att identifiera när konton skapas eller behörigheter ändras för skadliga ändamål.

Vi rekommenderar att användare och privilegierade konton endast skapas enligt organisationens principer. Ett konto bör till exempel skapas med rätt namngivningsstandarder, organisationsinformation och under omfånget för lämplig identitetsstyrning. Organisationer bör ha rigorösa kontroller för vem som har behörighet att skapa, hantera och ta bort identiteter. Roller för att skapa dessa konton bör hanteras noggrant och de rättigheter som endast är tillgängliga efter att ha följt ett etablerat arbetsflöde för att godkänna och hämta dessa behörigheter.

Ovanliga inloggningar

Det är normalt att se fel för användarautentisering. Men att se mönster eller block av fel kan vara en indikator på att något händer med en användares identitet. Till exempel under Lösenordsspray eller Brute Force-attacker, eller när ett användarkonto komprometteras. Det är viktigt att du övervakar och varnar när mönster dyker upp. På så sätt kan du skydda användaren och organisationens data.

Framgång verkar säga att allt är bra. Men det kan innebära att en dålig aktör har åtkomst till en tjänst. Genom att övervaka lyckade inloggningar kan du identifiera användarkonton som får åtkomst men inte är användarkonton som ska ha åtkomst. Lyckade användarautentiseringar är normala poster i Inloggningsloggar för Microsoft Entra. Vi rekommenderar att du övervakar och varnar för att identifiera när mönster uppstår. På så sätt kan du skydda användarkonton och organisationens data.

När du utformar och operationaliserar en strategi för loggövervakning och aviseringar bör du överväga de verktyg som är tillgängliga för dig via Azure Portal. Med Microsoft Entra ID Protection kan du automatisera identifiering, skydd och reparation av identitetsbaserade risker. ID Protection använder intelligensmatad maskininlärning och heuristiska system för att identifiera risker och tilldela en riskpoäng för användare och inloggningar. Kunder kan konfigurera principer baserat på en risknivå för när de ska tillåta eller neka åtkomst eller tillåta användaren att på ett säkert sätt självreparera från en risk. Följande ID Protection-riskidentifieringar informerar idag om risknivåer:

Mer information finns i Vad är ID-skydd.

Vad du ska leta efter

Konfigurera övervakning av data i Inloggningsloggarna för Microsoft Entra för att säkerställa att aviseringar sker och följer organisationens säkerhetsprinciper. Några exempel på detta är:

• Misslyckade autentiseringar: Som människor får vi alla våra lösenord fel då och då. Många misslyckade autentiseringar kan dock tyda på att en felaktig aktör försöker få åtkomst. Attacker skiljer sig i grymhet men kan variera från några försök per timme till en mycket högre hastighet. Till exempel utnyttjar Password Spray normalt enklare lösenord mot många konton, medan Brute Force försöker många lösenord mot målkonton.

• Avbrutna autentiseringar: Ett avbrott i Microsoft Entra-ID representerar en inmatning av en process för att uppfylla autentisering, till exempel när du framtvingar en kontroll i en princip för villkorsstyrd åtkomst. Detta är en normal händelse och kan inträffa när program inte är korrekt konfigurerade. Men när du ser många avbrott för ett användarkonto kan det tyda på att något händer med det kontot.

  • Om du till exempel filtrerade på en användare i inloggningsloggar och ser en stor volym inloggningsstatus = Avbruten och villkorsstyrd åtkomst = Fel. Om du går djupare kan det i autentiseringsinformationen visa att lösenordet är korrekt, men att stark autentisering krävs. Det kan innebära att användaren inte slutför multifaktorautentisering (MFA) vilket kan tyda på att användarens lösenord har komprometterats och att den dåliga aktören inte kan uppfylla MFA.

• Smart utelåsning: Microsoft Entra ID tillhandahåller en smart utlåsningstjänst som introducerar begreppet välbekanta och icke-bekanta platser till autentiseringsprocessen. Ett användarkonto som besöker en bekant plats kan autentiseras medan en dålig aktör som inte är bekant med samma plats blockeras efter flera försök. Leta efter konton som har låsts ut och undersöka vidare.

• IP-ändringar: Det är normalt att se användare som kommer från olika IP-adresser. Men Nolltillit tillstånd litar aldrig på och verifierar alltid. Att se en stor mängd IP-adresser och misslyckade inloggningar kan vara en indikator på intrång. Leta efter ett mönster med många misslyckade autentiseringar som äger rum från flera IP-adresser. Observera att vpn-anslutningar (virtual private network) kan orsaka falska positiva identifieringar. Oavsett utmaningarna rekommenderar vi att du övervakar ip-adressändringar och om möjligt använder du Microsoft Entra ID Protection för att automatiskt identifiera och minimera dessa risker.

• Platser: I allmänhet förväntar du dig att ett användarkonto ska finnas på samma geografiska plats. Du förväntar dig också inloggningar från platser där du har anställda eller affärsrelationer. När användarkontot kommer från en annan internationell plats på kortare tid än det skulle ta att resa dit, kan det tyda på att användarkontot missbrukas. Observera att VPN:er kan orsaka falska positiva identifieringar, vi rekommenderar att du övervakar för användarkonton som loggar in från geografiskt avlägsna platser och om möjligt använder Microsoft Entra ID Protection för att automatiskt identifiera och minimera dessa risker.

För det här riskområdet rekommenderar vi att du övervakar standardanvändarkonton och privilegierade konton men prioriterar undersökningar av privilegierade konton. Privilegierade konton är de viktigaste kontona i alla Microsoft Entra-klienter. Specifik vägledning för privilegierade konton finns i Säkerhetsåtgärder – privilegierade konton.

Så här identifierar du

Du använder Microsoft Entra ID Protection och Inloggningsloggarna för Microsoft Entra för att identifiera hot som indikeras av ovanliga inloggningsegenskaper. Mer information finns i artikeln Vad är ID-skydd. Du kan också replikera data till Azure Monitor eller en SIEM i övervaknings- och aviseringssyfte. Om du vill definiera det normala för din miljö och ange en baslinje fastställer du:

• de parametrar som du anser vara normala för din användarbas.

• det genomsnittliga antalet försök av ett lösenord över en tid innan användaren anropar serviceavdelningen eller utför en lösenordsåterställning via självbetjäning.

• hur många misslyckade försök du vill tillåta innan du aviserar och om det blir annorlunda för användarkonton och privilegierade konton.

• hur många MFA-försök du vill tillåta innan aviseringar och om det blir annorlunda för användarkonton och privilegierade konton.

• om äldre autentisering är aktiverat och din översikt för att avbryta användningen.

• de kända utgående IP-adresserna är till för din organisation.

• de länder/regioner som användarna arbetar från.

• om det finns grupper av användare som förblir stationära inom en nätverksplats eller ett land/en region.

• Identifiera andra indikatorer för ovanliga inloggningar som är specifika för din organisation. Till exempel dagar eller tider på veckan eller året som din organisation inte fungerar.

När du har omfånget vad som är normalt för kontona i din miljö bör du överväga följande lista för att avgöra scenarier som du vill övervaka och varna på och finjustera aviseringarna.

• Behöver du övervaka och varna om Microsoft Entra ID Protection har konfigurerats?

• Finns det strängare villkor som tillämpas på privilegierade konton som du kan använda för att övervaka och avisera om? Att kräva privilegierade konton används till exempel endast från betrodda IP-adresser.

• Är baslinjerna som du anger för aggressiva? För många aviseringar kan leda till att aviseringar ignoreras eller missas.

Konfigurera ID Protection för att säkerställa att skyddet finns på plats som stöder dina säkerhetsbaslinjeprinciper. Till exempel blockera användare om risken = hög. Den här risknivån indikerar med hög grad av förtroende att ett användarkonto har komprometterats. Mer information om hur du konfigurerar principer för inloggningsrisker och användarriskprinciper finns i ID-skyddsprinciper.

Följande listas i prioritetsordning baserat på effekten och allvarlighetsgraden för posterna.

Övervaka externa användarinloggningar

Övervakning för misslyckade ovanliga inloggningar

Följande listas i prioritetsordning baserat på effekten och allvarlighetsgraden för posterna.

Övervakning för lyckade ovanliga inloggningar

Vi rekommenderar att du regelbundet granskar autentiseringar till MBI-program (Medium Business Impact) och HBI-program (High Business Impact) där endast enfaktorautentisering krävs. För var och en vill du avgöra om enfaktorautentisering förväntades eller inte. Dessutom kan du granska för lyckad autentisering ökar eller vid oväntade tidpunkter, baserat på platsen.

Nästa steg

Se följande artiklar i guiden för säkerhetsåtgärder:

Översikt över Microsoft Entra-säkerhetsåtgärder

Säkerhetsåtgärder för konsumentkonton

Säkerhetsåtgärder för privilegierade konton

Säkerhetsåtgärder för Privileged Identity Management

Säkerhetsåtgärder för program

Säkerhetsåtgärder för enheter

Säkerhetsåtgärder för infrastruktur