Azure Active Directory-säkerhetsåtgärder för användarkonton

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

Om du ännu inte har läst översikten över säkerhetsåtgärder i Azure Active Directory (Azure AD) rekommenderar vi att du gör det innan du fortsätter.

Den här artikeln beskriver allmänna användarkonton. Information om privilegierade konton finns i 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 förväntat beteende för din organisation är kan du avgöra när ett oväntat beteende inträffar. Definitionen bidrar också till att minska brusnivån för falska positiva identifieringar vid övervakning och avisering.

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 efter allt som faller utanför de toleranser som du definierar.

Använd Azure AD granskningsloggar, Azure AD 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. Finns det 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), Azure Active Directory 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 Azure AD Connect:

    • Skogar, domäner och organisationsenheter (OU) i synkroniseringsomfånget. 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 Azure AD.

    • Processen för att fastställa vilka typer av användare som etableras som Azure AD 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 personer 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:

Från Azure-Portal kan du visa Azure AD granskningsloggar och ladda ned som kommaavgränsade värdefiler (CSV) eller JSON-filer (JavaScript Object Notation). Den Azure-Portal har flera sätt att integrera Azure AD 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ökkriterier har vi lagt till en länk till Sigma-lagringsplatsen. Sigma-mallarna skrivs, testas och hanteras inte av Microsoft. I stället skapas och samlas lagringsplatsen och mallarna 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.

  • Hub eventi di Azure integrerat med en SIEM – Azure AD loggar kan integreras med andra SIEM:er som Splunk, ArcSight, QRadar och Sumo Logic via Hub eventi di Azure integrering.

  • Microsoft Defender for Cloud Apps – gör att du kan identifiera och hantera appar, styra över appar och resurser och kontrollera dina molnappars efterlevnad.

  • Skydda arbetsbelastningsidentiteter med förhandsversionen av Identity 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 insikts- och rapporteringsarbetsboken 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. Om det finns specifika färdiga 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

Avvikande kontoskapande 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 processer för identitetshantering bör övervakas i Azure AD. 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 faller utanför etablerade processer och principer. Den här typen av beteende tar bort synliga markörer från katalogen.

Om dataloggen för kontoskapande och borttagning inte identifieras 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 bevaras 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.

Vad som ska övervakas Risknivå Var Filtrera/underfilter Kommentarer
Händelser för att skapa och ta bort konton inom en nära tidsram. Högt Azure AD granskningsloggar Aktivitet: Lägg till användare
Status = lyckades
-Och-
Aktivitet: Ta bort användare
Status = lyckades
Sök efter UPN-händelser (user principal name). Leta efter konton som skapats och sedan tagits bort på under 24 timmar.
Microsoft Sentinel-mall
Konton som skapats och tagits bort av icke-godkända användare eller processer. Medel Azure AD granskningsloggar Initierad av (aktör) – ANVÄNDARENS HUVUDNAMN
-Och-
Aktivitet: Lägg till användare
Status = lyckades
och-eller
Aktivitet: Ta bort användare
Status = lyckades
Om aktörerna är icke-godkända användare konfigurerar du för att skicka en avisering.
Microsoft Sentinel-mall
Konton från icke-godkända källor. Medel Azure AD granskningsloggar Aktivitet: Lägg till användare
Status = lyckades
Mål = ANVÄNDARENS HUVUDNAMN
Om posten inte kommer från en godkänd domän eller är en känd blockerad domän konfigurerar du för att skicka en avisering.
Microsoft Sentinel-mall
Konton som tilldelats en privilegierad roll. Högt Azure AD granskningsloggar Aktivitet: Lägg till användare
Status = lyckades
-Och-
Aktivitet: Ta bort användare
Status = lyckades
-Och-
Aktivitet: Lägg till medlem i rollen
Status = lyckades
Om kontot har tilldelats en Azure AD roll, Azure-roll eller privilegierat gruppmedlemskap aviserar och prioriterar du undersökningen.
Microsoft Sentinel-mall
Sigma-regler

Både privilegierade och icke-privilegierade konton bör övervakas och aviseras. Men eftersom privilegierade konton har administratörsbehörighet 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.

En bra idé är att ha en namngivningsprincip för användarobjekt. Med en namngivningsprincip blir 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 namngivningsstandarderna och kan göra det enklare 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. Exempel:

  • Admin kontot 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.

Vad som ska övervakas Risknivå Var Filtrera/underfilter Kommentarer
Användarkonton som inte har definierade förväntade attribut. Låg Azure AD granskningsloggar Aktivitet: Lägg till användare
Status = lyckades
Leta efter konton med dina standardattribut, antingen null eller i fel format. Till exempel EmployeeID
Microsoft Sentinel-mall
Användarkonton som skapats med felaktigt namngivningsformat. Låg Azure AD granskningsloggar Aktivitet: Lägg till användare
Status = lyckades
Leta efter konton med ett UPN som inte följer din namngivningsprincip.
Microsoft Sentinel-mall
Privilegierade konton som inte följer namngivningsprincipen. Högt Azure Subscription (Azure-prenumeration) Lista Azure-rolltilldelningar med hjälp av Azure-Portal – Azure RBAC Lista rolltilldelningar för prenumerationer och aviseringar där inloggningsnamnet inte matchar organisationens format. Till exempel ADM_ som ett prefix.
Privilegierade konton som inte följer namngivningsprincipen. Högt Azure AD-katalog Visa Azure AD-rolltilldelningar Visa en avisering om rolltilldelningar för Azure AD roller där UPN inte matchar organisationens format. Till exempel ADM_ som ett prefix.

Mer information om parsning finns i:

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 för skadliga ändamål. 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 rättigheterna ska endast vara tillgängliga efter att ha följt ett etablerat arbetsflöde för att godkänna och hämta dessa behörigheter.

Vad du ska övervaka Risknivå Var Filter/underfilter Kommentarer
Användarkonton som skapats eller tagits bort av icke-godkända användare eller processer. Medel Azure AD granskningsloggar Aktivitet: Lägg till användare
Status = lyckades
och-eller-
Aktivitet: Ta bort användare
Status = lyckades
-Och-
Initierad av (aktör) = ANVÄNDARENS HUVUDNAMN
Avisering om konton som skapats av icke-godkända användare eller processer. Prioritera konton som skapats med utökade privilegier.
Microsoft Sentinel-mall
Användarkonton som skapats eller tagits bort från icke-godkända källor. Medel Azure AD granskningsloggar Aktivitet: Lägg till användare
Status = lyckades
\- eller -
Aktivitet: Ta bort användare
Status = lyckades
-Och-
Mål = ANVÄNDARENS HUVUDNAMN
Avisering när domänen är icke-godkänd eller känd blockerad domän.

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ändarens 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 Azure AD Sign-Ins loggar. Vi rekommenderar att du övervakar och varnar för att identifiera när mönster dyker upp. 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 Identity Protection kan du automatisera identifiering, skydd och reparation av identitetsbaserade risker. Identitetsskydd använder intelligensmatad maskininlärning och heuristiksystem 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 åtkomst ska tillåtas eller nekas eller användaren kan på ett säkert sätt självreparera från en risk. Följande Identity Protection-riskidentifieringar informerar idag om risknivåer:

Vad du ska övervaka Risknivå Var Filter/underfilter Kommentarer
Identifiering av användarrisk för läckta autentiseringsuppgifter Högt Azure AD riskidentifieringsloggar UX: Läckta autentiseringsuppgifter

API: Se resurstypen riskDetection – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection
Azure AD Hotinformation– användarriskidentifiering Högt Azure AD riskidentifieringsloggar UX: Azure AD hotinformation

API: Se resurstypen riskDetection – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection
Identifiering av anonym IP-adressinloggningsrisk Det varierar Azure AD riskidentifieringsloggar UX: Anonym IP-adress

API: Se resurstypen riskDetection – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection
Atypisk riskidentifiering för reseinloggning Det varierar Azure AD riskidentifieringsloggar UX: Atypisk resa

API: Se resurstypen riskDetection – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection
Avvikande token Det varierar Azure AD riskidentifieringsloggar UX: Avvikande token

API: Se resurstypen riskDetection – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection
Identifiering av inloggningsrisk för länkad IP-adress för skadlig kod Det varierar Azure AD riskidentifieringsloggar UX: Länkad IP-adress för skadlig kod

API: Se resurstypen riskDetection – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection
Misstänkt identifiering av webbläsarinloggningsrisk Det varierar Azure AD riskidentifieringsloggar UX: Misstänkt webbläsare

API: Se resurstypen riskDetection – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection
Okänd inloggningsegenskaper inloggningsriskidentifiering Det varierar Azure AD riskidentifieringsloggar UX: Okända inloggningsegenskaper

API: Se resurstypen riskDetection – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection
Identifiering av inloggningsrisk för skadlig IP-adress Det varierar Azure AD loggar för riskidentifiering UX: Skadlig IP-adress

API: Se resurstypen riskDetection – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection
Misstänkt inkorgsmanipuleringsregler inloggningsriskidentifiering Det varierar Azure AD loggar för riskidentifiering UX: Misstänkta regler för inkorgsmanipulering

API: Se resurstypen riskDetection – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection
Inloggningsriskidentifiering för lösenordsspray Högt Azure AD loggar för riskidentifiering UX: Lösenordsspray

API: Se resurstypen riskDetection – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection
Riskidentifiering för omöjlig reseinloggning Det varierar Azure AD loggar för riskidentifiering UX: Omöjlig resa

API: Se resurstypen riskDetection – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection
Ny riskidentifiering för landinloggning Det varierar Azure AD loggar för riskidentifiering UX: Nytt land

API: Se resurstypen riskDetection – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection
Aktivitet från identifiering av anonym IP-adressinloggningsrisk Det varierar Azure AD loggar för riskidentifiering UX: Aktivitet från anonym IP-adress

API: Se resurstypen riskDetection – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection
Misstänkt vidarebefordran av inloggningsriskidentifiering i inkorgen Det varierar Azure AD loggar för riskidentifiering UX: Misstänkt vidarebefordran av inkorgar

API: Se resurstypen riskDetection – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection
Azure AD inloggningsriskidentifiering för hotinformation Högt Azure AD loggar för riskidentifiering UX: Azure AD hotinformation
API: Se resurstypen riskDetection – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection

Mer information finns i Vad är identitetsskydd?

Vad du ska söka efter

Konfigurera övervakning av data i loggarna för Azure AD inloggningar 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 dålig aktör försöker få åtkomst. Attacker skiljer sig åt i grymhet men kan variera från några försök per timme till en mycket högre frekvens. Till exempel använder Password Spray vanligtvis 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 Azure AD representerar en inmatning av en process för att uppfylla autentisering, till exempel när du framtvingar en kontroll i en CA-princip. 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. Detta 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 felaktiga aktören inte kan uppfylla MFA.
  • Smart utelåsning: Azure AD tillhandahåller en smart utlåsningstjänst som introducerar begreppet välbekanta och icke-bekanta platser i 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ök ytterligare.

  • IP-ändringar: Det är normalt att se användare som kommer från olika IP-adresser. Men Confiança zero 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 från flera IP-adresser. Observera att VPN-anslutningar (virtuellt privat nätverk) kan orsaka falska positiva identifieringar. Oavsett utmaningar rekommenderar vi att du övervakar ip-adressändringar och om möjligt använder du Azure AD Identity 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 Azure AD Identity 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 Azure AD klientorganisationen. Specifik vägledning för privilegierade konton finns i Säkerhetsåtgärder – privilegierade konton.

Identifiera

Du använder Azure Identity Protection och Azure AD inloggningsloggar för att identifiera hot som indikeras av ovanliga inloggningsegenskaper. Information om Identity Protection finns i Vad är identitetsskydd. Du kan också replikera data till Azure Monitor eller en SIEM för övervaknings- och aviseringsändamål. Om du vill definiera det normala för din miljö och ange en baslinje ska du bestämma:

  • parametrarna 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 supportavdelningen eller utför en lösenordsåterställning via självbetjäning.

  • hur många misslyckade försök du vill tillåta före aviseringar och om det kommer att vara annorlunda för användarkonton och privilegierade konton.

  • hur många MFA-försök du vill tillåta innan aviseringar och om det kommer att vara 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 för din organisation.

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

  • om det finns grupper av användare som förblir stillastående inom en nätverksplats eller ett land.

  • 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 fastställa scenarier som du vill övervaka och varna för och finjustera aviseringarna.

  • Behöver du övervaka och avisera om Identity Protection har konfigurerats?

  • Tillämpas strängare villkor på privilegierade konton som du kan använda för att övervaka och avisera om? Du kan till exempel bara använda privilegierade konton från betrodda IP-adresser.

  • Är baslinjerna som du anger för aggressiva? Om du har för många aviseringar kan aviseringar ignoreras eller missas.

Konfigurera Identity Protection för att säkerställa att skydd finns på plats som stöder dina principer för säkerhetsbaslinjer. Till exempel blockera användare om risken = hög. Den här risknivån indikerar med hög grad av förtroende för att ett användarkonto har komprometterats. Mer information om hur du konfigurerar principer för inloggningsrisker och principer för användarrisker finns i Identity Protection-principer. Mer information om hur du konfigurerar villkorlig åtkomst finns i Villkorsstyrd åtkomst: Inloggningsriskbaserad villkorlig åtkomst.

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

Övervaka externa användarinloggningar

Vad du ska övervaka Risknivå Var Filter/underfilter Kommentarer
Användare som autentiserar till andra Azure AD klienter. Låg Azure AD inloggningslogg Status = lyckades
Resource tenantID != Home Tenant ID
Identifierar när en användare har autentiserats till en annan Azure AD klientorganisation med en identitet i organisationens klientorganisation.
Avisering om Resource TenantID inte är lika med ID för hemklientorganisation
Microsoft Sentinel-mall
Sigma-regler
Användartillståndet har ändrats från gäst till medlem Medel Azure AD granskningsloggar Aktivitet: Uppdatera användare
Kategori: UserManagement
UserType har ändrats från gäst till medlem
Övervaka och avisera om ändring av användartyp från Gäst till Medlem. Förväntades detta?
Microsoft Sentinel-mall
Sigma-regler
Gästanvändare som bjudits in till klientorganisationen av icke-godkända inbjudna Medel Azure AD granskningsloggar Aktivitet: Bjud in extern användare
Kategori: UserManagement
Initierad av (aktör): Användarens huvudnamn
Övervaka och varna icke-godkända aktörer som bjuder in externa användare.
Microsoft Sentinel-mall
Sigma-regler

Övervakning av misslyckade ovanliga inloggningar

Vad du ska övervaka Risknivå Var Filter/underfilter Kommentarer
Misslyckade inloggningsförsök. Medel – om isolerad incident
Hög – om många konton har samma mönster eller en VIP.
Azure AD inloggningslogg Status = misslyckades
-Och-
Inloggningsfelkod 50126 –
Det gick inte att verifiera autentiseringsuppgifterna på grund av ogiltigt användarnamn eller lösenord.
Definiera ett baslinjetröskelvärde och övervaka och justera sedan för att anpassa organisationens beteenden och begränsa falska aviseringar från att genereras.
Microsoft Sentinel-mall
Sigma-regler
Smarta utlåsningshändelser. Medel – om isolerad incident
Hög – om många konton har samma mönster eller en VIP.
Azure AD inloggningslogg Status = misslyckades
-Och-
Inloggningsfelkod = 50053 – IdsLocked
Definiera ett baslinjetröskelvärde och övervaka och justera sedan för att anpassa organisationens beteenden och begränsa falska aviseringar från att genereras.
Microsoft Sentinel-mall
Sigma-regler
Avbryter Medel – om isolerad incident
Hög – om många konton har samma mönster eller en VIP.
Azure AD inloggningslogg 500121 misslyckades autentiseringen under stark autentiseringsbegäran.
\- eller -
50097, Enhetsautentisering krävs eller 50074, stark autentisering krävs.
\- eller -
50155, DeviceAuthenticationFailed
\- eller -
50158, ExternalSecurityChallenge – Den externa säkerhetsutmaningen uppfylldes inte
\- eller -
53003 och Felorsak = blockerad av CA
Övervaka och avisera om avbrott.
Definiera ett baslinjetröskelvärde och övervaka och justera sedan för att anpassa organisationens beteenden och begränsa falska aviseringar från att genereras.
Microsoft Sentinel-mall
Sigma-regler

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

Vad du ska övervaka Risknivå Var Filter/underfilter Kommentarer
MFA-bedrägeriaviseringar (Multi-Factor Authentication). Högt Azure AD inloggningslogg Status = misslyckades
-Och-
Information = MFA nekad
Övervaka och avisera om alla inmatningar.
Microsoft Sentinel-mall
Sigma-regler
Misslyckade autentiseringar från länder som du inte använder. Medel Azure AD inloggningslogg Plats = <ej godkänd plats> Övervaka och varna för alla poster.
Microsoft Sentinel-mall
Sigma-regler
Misslyckade autentiseringar för äldre protokoll eller protokoll som inte används. Medel Azure AD inloggningslogg Status = fel
-Och-
Klientapp = Andra klienter, POP, IMAP, MAPI, SMTP, ActiveSync
Övervaka och varna för alla poster.
Microsoft Sentinel-mall
Sigma-regler
Fel som blockerats av ca. Medel Azure AD inloggningslogg Felkod = 53003
-Och-
Felorsak = blockerad av CA
Övervaka och varna för alla poster.
Microsoft Sentinel-mall
Sigma-regler
Ökade misslyckade autentiseringar av alla typer. Medel Azure AD inloggningslogg Samla in ökningar av fel över hela linjen. Det vill säger att den totala felsumman för idag är >10 % samma dag, föregående vecka. Om du inte har ett angivet tröskelvärde övervakar och aviserar du om felen ökar med 10 % eller högre.
Microsoft Sentinel-mall
Autentisering sker vid tidpunkter och dagar i veckan när länder inte utför normal affärsverksamhet. Låg Azure AD inloggningslogg Samla in interaktiv autentisering som inträffar utanför normal driftsdagar\tid.
Status = lyckades
-Och-
Plats = <plats>
-Och-
Dag\Tid = <inte normal arbetstid>
Övervaka och varna för alla poster.
Microsoft Sentinel-mall
Kontot har inaktiverats/blockerats för inloggningar Låg Azure AD inloggningslogg Status = Fel
-Och-
felkod = 50057, användarkontot är inaktiverat.
Detta kan tyda på att någon försöker få åtkomst till ett konto när de har lämnat en organisation. Även om kontot är blockerat är det viktigt att logga och varna om den här aktiviteten.
Microsoft Sentinel-mall
Sigma-regler

Övervakning av lyckade ovanliga inloggningar

Vad som ska övervakas Risknivå Var Filtrera/underfilter Kommentarer
Autentiseringar av privilegierade konton utanför förväntade kontroller. Högt Azure AD inloggningslogg Status = lyckades
-Och-
UserPricipalName = <Admin konto>
-Och-
Plats = <ej godkänd plats>
-Och-
IP-adress = <ej godkänd IP-adress>
Enhetsinformation= <ej godkänd webbläsare, operativsystem>
Övervaka och varna om lyckad autentisering för privilegierade konton utanför förväntade kontroller. Tre vanliga kontroller visas.
Microsoft Sentinel-mall
Sigma-regler
När endast enfaktorautentisering krävs. Låg Azure AD inloggningslogg Status = lyckades
Autentiseringskrav = Enfaktorautentisering
Övervaka regelbundet och se till att beteendet förväntas.
Microsoft Sentinel-mall

Sigma-regler
Identifiera privilegierade konton som inte har registrerats för MFA. Högt Azure Graph API Fråga efter IsMFARegistered eq false för administratörskonton.
Lista credentialUserRegistrationDetails – Microsoft Graph beta
Granska och undersöka för att avgöra om det är avsiktligt eller ett förbiseende.
Lyckade autentiseringar från länder som din organisation inte fungerar i. Medel Azure AD inloggningslogg Status = lyckades
Plats = <land som inte godkänts>
Övervaka och varna för poster som inte är lika med de ortsnamn som du anger.
Sigma-regler
Lyckad autentisering, session blockerad av CA. Medel Azure AD inloggningslogg Status = lyckades
-Och-
felkod = 53003 – Felorsak, blockerad av CA
Övervaka och undersöka när autentiseringen lyckas, men sessionen blockeras av certifikatutfärdaren.
Microsoft Sentinel-mall

Sigma-regler
Lyckad autentisering när du har inaktiverat äldre autentisering. Medel Azure AD inloggningslogg status = lyckades
-Och-
Klientapp = Andra klienter, POP, IMAP, MAPI, SMTP, ActiveSync
Om din organisation har inaktiverat äldre autentisering övervakar och aviserar du när en lyckad äldre autentisering har utförts.
Microsoft Sentinel-mall

Sigma-regler

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. Granska dessutom för lyckad autentisering ökar eller vid oväntade tidpunkter, baserat på platsen.

Vad som ska övervakas Risknivå Var Filtrera/underfilter Kommentarer
Autentiseringar till MBI- och HBI-program med hjälp av enfaktorautentisering. Låg Azure AD inloggningslogg status = lyckades
-Och-
Program-ID = <HBI-app>
-Och-
Autentiseringskrav = enfaktorautentisering.
Granska och verifiera att den här konfigurationen är avsiktlig.
Microsoft Sentinel-mall

Sigma-regler
Autentiseringar vid dagar och tider på veckan eller året som länder inte utför normal affärsverksamhet. Låg Azure AD inloggningslogg Samla in interaktiv autentisering som inträffar utanför normal driftsdagar\tid.
Status = lyckades
Plats = <plats>
Datum\Tid = <inte normal arbetstid>
Övervaka och varna för autentiseringar dagar och tider på veckan eller året som länder inte utför normal affärsverksamhet.
Microsoft Sentinel-mall

Sigma-regler
Mätbar ökning av lyckade inloggningar. Låg Azure AD inloggningslogg Samla in ökningar av lyckad autentisering över hela linjen. Det vill säger att totalsummorna för dagens resultat är >10 % samma dag, föregående vecka. Om du inte har ett angivet tröskelvärde övervakar och aviserar du om lyckade autentiseringar ökar med 10 % eller högre.
Microsoft Sentinel-mall

Sigma-regler

Nästa steg

Se de här artiklarna i guiden om säkerhetsåtgärder:

översikt över Azure AD 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