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

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

Om du ännu inte har läst översikten Azure Active Directory säkerhetsåtgärder i Azure ADrekommenderar 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 det förväntade beteendet för din organisation kan du avgöra när ett oväntat beteende inträffar. Definitionen bidrar också till att minska brusnivån för falska positiva resultat 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 för 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 för användare – 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 att skapa konton. Till exempel med ursprung i Active Directory (AD), Azure Active Directory 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.

    • Övervakning 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 Anslut:

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

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

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

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

Mer information om att skydda och övervaka 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 etablerats 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 användarkonton i molnet.

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

Var du ska leta

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

Från Azure Portal kan du visa Azure AD-granskningsloggarna och ladda ned dem som filer med kommaavgränsade värden (CSV) eller JavaScript Object Notation (JSON). Det Azure Portal 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 funktioner för säkerhetsinformation och händelsehantering (SIEM).

  • 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 integrerasmed siem Azure AD-loggar kan integreras med andra SIEM-datorer som Splunk, ArcSight, QRadar och Sumo Logic via Azure Event Hub-integreringen.

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

Mycket av det du övervakar och varnar om är effekterna av dina principer för villkorsstyrd åtkomst. Du kan använda arbetsboken Insikter om villkorsstyrd åtkomst och rapportering för att undersöka effekterna av en eller flera principer för villkorlig åtkomst på dina inloggningar, samt resultatet av principer, inklusive enhetstillstånd. Med den här arbetsboken kan du visa en effektsammanfattning och identifiera effekten 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 varnar om och är organiserat efter typ av hot. Där det finns specifika förbyggda lösningar länkar vi till dem eller ger exempel efter tabellen. Annars kan du skapa aviseringar med hjälp av föregående verktyg.

Skapa konto

Avvikande kontoskapande kan tyda på ett äkerhetsåtgärder. Kortlivade konton, konton som inte följer namngivningsstandarder och konton som skapats utanför normala processer bör undersökas.

Kortlivade konton

Skapande och borttagning av konton utanför normala identitetshanteringsprocesser bör övervakas i Azure AD. Kortlivade konton är konton som skapas och tas bort inom ett kort tidsintervall. 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.

Kortvariga 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 dataspåret för att skapa och ta bort konton inte identifieras snabbt kanske den information som krävs för att undersöka en incident inte längre finns. Konton kan till exempel tas bort och sedan rensas från papperskorgen. Granskningsloggar sparas 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 Filter/underfilter Kommentarer
Händelser för skapande och borttagning av konton inom en nära tidsram. Högt Azure AD-granskningsloggar Aktivitet: Lägg till användare
Status = lyckades
-and-
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å mindre än 24 timmar.
Microsoft Sentinel-mall
Konton som skapas och tas bort av icke-godkända användare eller processer. Medel Azure AD-granskningsloggar Initierat av (aktör) – ANVÄNDARENs HUVUDNAMN
-and-
Aktivitet: Lägg till användare
Status = lyckades
och-eller
Aktivitet: Ta bort användare
Status = lyckades
Om aktören ä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
Target(s) = USER PRINCIPAL NAME
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.
Konton som har tilldelats en privilegierad roll. Högt Azure AD-granskningsloggar Aktivitet: Lägg till användare
Status = lyckades
-and-
Aktivitet: Ta bort användare
Status = lyckades
-and-
Aktivitet: Lägg till medlem i roll
Status = lyckades
Om kontot har tilldelats till en Azure AD-roll, Azure-roll eller privilegierat gruppmedlemskap avisering och prioriterar du undersökningen.
Microsoft Sentinel-mall

Både privilegierade och icke-privilegierade konton bör övervakas och avisering. 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 metod är att ha en namngivningsprincip för användarobjekt. 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 felaktig aktör kanske inte känner till dina namngivningsstandarder 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ändar- och eller privilegierade konton. Ett exempel:

  • UPN för administratörskonto = ADM_firstname.lastname@tenant.onmicrosoft.com

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

Användarkonton har också ofta ett attribut som identifierar en verklig användare. Till exempel EMPID = XXXNNN. Följande är förslag som hjälper dig att tänka på och definiera vad som är normalt för din organisation, samt saker att tänka på när du definierar din baslinje för loggposter där konton inte följer organisationens 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. Till exempel om du inte har ett giltigt anställnings-ID.

Vad som ska övervakas Risknivå Var Filter/underfilter Kommentarer
Användarkonton som inte har förväntade attribut definierade. Låg Azure AD-granskningsloggar Aktivitet: Lägg till användare
Status = lyckades
Leta efter konton med standardattributen null eller i fel format. Till exempel EmployeeID
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.
Privilegierade konton som inte följer namngivningsprincipen. Högt Azure Subscription (Azure-prenumeration) Lista azure-rolltilldelningar med hjälp Azure Portal – Azure RBAC Lista rolltilldelningar för prenumerationer och aviseringar där inloggningsnamnet inte matchar organisationens format. Du kan till ADM_ som ett prefix.
Privilegierade konton som inte följer namngivningsprincipen. Högt Azure AD-katalog Visa Azure AD-rolltilldelningar Visa en lista över rolltilldelningar för Azure AD-roller där UPN inte matchar organisationens format. Du kan till 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 styra livscykeln för identiteter. Om användare etableras och avetablerats utanför etablerade processer kan det leda till säkerhetsrisker. Att använda utanför etablerade processer kan också leda till problem med identitetshantering. Potentiella risker är:

  • Användar- och privilegierade konton kanske inte styrs av organisationens principer. Detta kan leda till en bredare angreppsyta på konton som inte hanteras korrekt.

  • Det blir svårare att identifiera när obehöriga 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 som har ändrats för skadliga ändamål.

Vi rekommenderar att användarkonton 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 vara nära hanterade och de rättigheter som endast är tillgängliga efter att ha följt ett etablerat arbetsflöde för att godkänna och erhålla dessa behörigheter.

Vad som ska övervakas 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
-and-
Initierad av (aktör) = USER PRINCIPAL NAME
Avisering för konton som skapats av icke-godkända användare eller processer. Prioritera konton som skapats med förhöjd behörighet.
Azure 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
-and-
Target(s) = USER PRINCIPAL NAME
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 felblock kan vara en indikator på att något händer med en användares identitet. Det kan till exempel vara Lösenordsattack 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 felaktig aktör har åtkomst till en tjänst. Genom att övervaka lyckade inloggningar kan du identifiera användarkonton som får åtkomst men som 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 avisering 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 intelligent 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 att användaren på ett säkert sätt kan åtgärda sig själv från en risk. Följande Identity Protection-riskidentifieringar informerar om risknivåer i dag:

Vad som ska övervakas Risknivå Var Filter/underfilter Kommentarer
Läckta autentiseringsuppgifter riskidentifiering för användare Högt Azure AD-riskidentifieringsloggar UX: Läckta autentiseringsuppgifter

API: Se riskDetection-resurstyp – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection
Identifiering av användarrisk i Azure AD Threat Intelligence Högt Azure AD-riskidentifieringsloggar UX: Azure AD-hotinformation

API: Se riskDetection-resurstyp – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection
Anonym IP-adress inloggningsriskidentifiering Det varierar Azure AD-riskidentifieringsloggar UX: Anonym IP-adress

API: Se riskDetection-resurstyp – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection
Ovanlig resa inloggningsriskidentifiering Det varierar Azure AD-riskidentifieringsloggar UX: Ovanlig resa

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

API: Se riskDetection-resurstyp – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection
IP-adress länkad till skadlig kod inloggningsriskidentifiering Det varierar Azure AD-riskidentifieringsloggar UX: IP-adress länkad till skadlig kod

API: Se riskDetection-resurstyp – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection
Riskidentifiering för misstänkt webbläsar inloggning Det varierar Azure AD-riskidentifieringsloggar UX: Misstänkt webbläsare

API: Se riskDetection-resurstyp – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection
Okänd inloggningsegenskaper för riskidentifiering vid inloggning Det varierar Azure AD-riskidentifieringsloggar UX: Obekanta inloggningsegenskaper

API: Se riskDetection-resurstyp – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection
Skadlig IP-adress inloggningsriskidentifiering Det varierar Azure AD-riskidentifieringsloggar UX: Skadlig IP-adress

API: Se riskDetection-resurstyp – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection
Misstänkta regler för inkorgsmanipulering inloggningsriskidentifiering Det varierar Azure AD-riskidentifieringsloggar UX: Misstänkta regler för inkorgsmanipulering

API: Se riskDetection-resurstyp – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection
Riskidentifiering för inloggning med lösenordsigenkänning Högt Azure AD-riskidentifieringsloggar UX: Lösenordsattack

API: Se riskDetection-resurstyp – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection
Omöjlig resa inloggningsriskidentifiering Det varierar Azure AD-riskidentifieringsloggar UX: Omöjlig resa

API: Se riskDetection-resurstyp – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection
Nytt land inloggningsriskidentifiering Det varierar Azure AD-riskidentifieringsloggar UX: Nytt land

API: Se riskDetection-resurstyp – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection
Aktivitet från anonym IP-adress inloggningsriskidentifiering Det varierar Azure AD-riskidentifieringsloggar UX: Aktivitet från Anonym IP-adress

API: Se riskDetection-resurstyp – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection
Misstänkt vidarebefordring i inkorgen inloggningsriskidentifiering Det varierar Azure AD-riskidentifieringsloggar UX: Misstänkt vidarebefordring i inkorgen

API: Se riskDetection-resurstyp – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection
Azure AD-hotinformation inloggningsriskidentifiering Högt Azure AD-riskidentifieringsloggar UX: Azure AD-hotinformation
API: Se riskDetection-resurstyp – Microsoft Graph
Se Vad är risk? Azure AD Identity Protection

Mer information finns i Vad är Identity Protection?

Vad du bör leta efter

Konfigurera övervakning av data i inloggningsloggarna för Azure AD 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 höggradighet, men kan variera från några försök per timme till en mycket högre frekvens. Lösenordsdutjämning använder till exempel normalt enklare lösenord mot många konton, medan Brute Force försöker använda många lösenord mot målkonton.

  • Avbruten autentisering:Ett avbrott i Azure AD representerar en injection av ytterligare en process för att uppfylla autentisering, till exempel vid framtvingande av en kontroll i en CA-princip. Detta är en normal händelse och kan inträffa när program inte har konfigurerats korrekt. 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 har filtrerat på en användare i inloggningsloggar och ser en stor mängd inloggningsstatus = Avbruten och Villkorlig åtkomst = Fel. Genom att gå djupare kan det i autentiseringsinformationen visas 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 skadade aktören inte kan uppfylla MFA.
  • Smart utelåsning:Azure AD tillhandahåller en tjänst för smart utelåsning som introducerar begreppet välbekanta och icke-bekanta platser i autentiseringsprocessen. Ett användarkonto som besöker en bekant plats kan autentiseras korrekt medan en obehörig 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 vidare.

  • IP-ändringar:Det är normalt att se användare som kommer från olika IP-adresser. Tillstånden Noll förtroende dock aldrig lita på och verifiera alltid. Att se en stor mängd IP-adresser och misslyckade inloggningar kan vara en indikation på intrång. Leta efter ett mönster för många misslyckade autentiseringar som sker från flera IP-adresser. Observera att VPN-anslutningar (virtuellt privat nätverk) kan orsaka falska positiva resultat. Oavsett utmaningarna rekommenderar vi att du övervakar ändringar i IP-adresser och om möjligt använder du Azure AD Identity Protection att automatiskt identifiera och minimera dessa risker.

  • Platser:Vanligtvis 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 användarkonton som loggar in från geografiskt avlägsna platser och om det är möjligt använder du 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 både vanliga användarkonton och privilegierade konton men prioriterar undersökningar av privilegierade konton. Privilegierade konton är de viktigaste kontona i alla Azure AD-klienter. Specifika riktlinjer för privilegierade konton finns i Säkerhetsåtgärder – privilegierade konton.

Identifiera

Du använder Azure Identity Protection och Azure AD-inloggningsloggarna för att identifiera hot som anges av ovanliga inloggningsegenskaper. Information om Identity Protection finns på Vad är Identity Protection. Du kan också replikera data till Azure Monitor eller en SIEM för övervakning och avisering. Fastställ följande för att definiera det normala för din miljö och för att ange en baslinje:

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

  • det genomsnittliga antalet försök med 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 aviseringen och om det skiljer sig för användarkonton och privilegierade konton.

  • hur många MFA-försök du vill tillåta före avisering, och om det skiljer sig för användarkonton och privilegierade konton.

  • om äldre autentisering har aktiverats och din översikt för kvarvarande användning.

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

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

  • om det finns grupper av användare som är stationära inom en nätverksplats eller ett land.

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

När du har omfångsbestämt vad normalt är för kontotyperna i din miljö kan du överväga följande för att avgöra vilka scenarier du vill övervaka och avisera om samt för att finjustera aviseringen.

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

  • Tillämpas det striktare villkor för privilegierade konton som du kan använda för att övervaka och avisering på? Till exempel kan krav på privilegierade konton endast användas 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äkerhetsbaslinje. Till exempel blockera användare om risk = hög. Den här risknivån anger med hög grad av konfidens att ett användarkonto har komprometterats. Mer information om hur du ställer in inloggningsriskprinciper och riskprinciper för användare finns i Identity Protection-principer. Mer information om hur du ställer in villkorlig åtkomst finns i Villkorsstyrd åtkomst: Riskbaserad villkorlig åtkomst för inloggning.

Följande visas i prioritetsordning baserat på posterna effekt och allvarlighetsgrad.

Övervakning av misslyckade ovanliga inloggningar

Vad som ska övervakas Risknivå Var Filter/underfilter Kommentarer
Misslyckade inloggningsförsök. Medel – om en isolerad incident
Hög – om ett antal konton har samma mönster eller en VIP.
Inloggningslogg för Azure AD Status = misslyckades
-and-
Inloggningsfelkod 50126 –
Fel vid validering av autentiseringsuppgifter på grund av ogiltigt användarnamn eller lösenord.
Definiera ett tröskelvärde för baslinjen och övervaka och justera sedan för att anpassa organisationens beteenden och begränsa falska aviseringar från att genereras.
Azure Sentinel mall
Smarta utlåsningshändelser. Medel – om en isolerad incident
Hög – om ett antal konton har samma mönster eller en VIP.
Inloggningslogg för Azure AD Status = misslyckades
-and-
Felkod för inloggning = 50053 – IdsLocked
Definiera ett tröskelvärde för baslinjen och övervaka och justera sedan för att anpassa organisationens beteenden och begränsa falska aviseringar från att genereras.
Azure Sentinel mall
Avbryter Medel – om en isolerad incident
Hög – om ett antal konton har samma mönster eller en VIP.
Inloggningslogg för Azure AD 500121 misslyckades autentiseringen under begäran om stark autentisering.
\- eller -
50097, Enhetsautentisering krävs eller 50074, stark autentisering krävs.
\- eller -
50155, DeviceAuthenticationFailed
\- eller -
50158, ExternalSecurityCgyge – Den externa säkerhetsutmaningen var inte uppfylld
\- eller -
53003 och Felorsak = blockerad av CERTIFIKATUTFÄRDARE
Övervaka och varna vid avbrott.
Definiera ett tröskelvärde för baslinjen och övervaka och justera sedan för att anpassa organisationens beteenden och begränsa falska aviseringar från att genereras.
Azure Sentinel mall

Följande visas i prioritetsordning baserat på posterna effekt och allvarlighetsgrad.

Vad som ska övervakas Risknivå Var Filter/underfilter Kommentarer
Bedrägeriaviseringar med multifaktorautentisering (MFA). Högt Inloggningslogg för Azure AD Status = misslyckades
-and-
Information = MFA nekad
Övervaka och avisering för alla inmatningar.
Azure Sentinel mall
Misslyckade autentiseringar från länder som du inte arbetar utanför. Medel Inloggningslogg för Azure AD Plats = < ej godkänd plats> Övervaka och varna för alla poster.
Misslyckade autentiseringar för äldre protokoll eller protokoll som inte används . Medel Inloggningslogg för Azure AD Status = fel
-and-
Klientapp = Andra klienter, POP, IMAP, MAPI, SMTP, ActiveSync
Övervaka och varna för alla poster.
Azure Sentinel mall
Fel som blockerats av certifikatutfärdaren. Medel Inloggningslogg för Azure AD Felkod = 53003
-and-
Felorsak = blockeras av certifikatutfärdaren
Övervaka och varna för alla poster.
Azure Sentinel mall
Ökad misslyckade autentiseringar av valfri typ. Medel Inloggningslogg för Azure AD Samla in ökningar av fel över hela linjen. Det vill säga att det totala antalet fel för i dag > är 10 % samma dag som föregående vecka. Om du inte har ett fast tröskelvärde kan du övervaka och varna om felen ökar med 10 % eller mer.
Azure Sentinel mall
Autentisering sker vid tider och dagar i veckan när länder inte utför normal verksamhet. Låg Inloggningslogg för Azure AD Samla in interaktiv autentisering som sker utanför normala driftdagar\tid.
Status = lyckades
-and-
Plats = < plats>
-and-
Day\Time = < inte normal arbetstid>
Övervaka och varna för alla poster.
Azure Sentinel mall
Kontot är inaktiverat/blockerat för inloggningar Låg Inloggningslogg för Azure AD Status = Fel
-and-
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 fortfarande viktigt att logga och avisering om den här aktiviteten.
Azure Sentinel mall

Övervakning av lyckade ovanliga inloggningar

Vad som ska övervakas Risknivå Var Filter/underfilter Kommentarer
Autentiseringar av privilegierade konton utanför förväntade kontroller. Högt Inloggningslogg för Azure AD Status = lyckades
-and-
UserPricipalName = < Administratörskonto>
-and-
Plats = < ej godkänd plats>
-and-
IP-adress < = ej godkänd IP>
Enhetsinformation = < ej godkänd webbläsare, operativsystem>
Övervaka och varna vid lyckad autentisering för privilegierade konton utanför förväntade kontroller. Tre vanliga kontroller visas.
När endast enfaktorautentisering krävs. Låg Inloggningslogg för Azure AD Status = lyckades
Autentiseringskrav = Enkelfaktorautentisering
Övervaka detta regelbundet och se till att detta är det förväntade beteendet.
Azure Sentinel mall
Identifiera privilegierade konton som inte har registrerats för MFA. Högt API för Azure Graph 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 om det finns ett tillsynsansvar.
Lyckade autentiseringar från länder som din organisation inte fungerar från. Medel Inloggningslogg för Azure AD Status = lyckades
Plats = < ej godkänt land>
Övervaka och varna för poster som inte är lika med de ortnamn som du anger.
Lyckad autentisering, session blockerad av certifikatutfärdare. Medel Inloggningslogg för Azure AD Status = lyckades
-and-
felkod = 53003 – felorsak, blockerad av certifikatutfärdare
Övervaka och undersöka när autentiseringen lyckas, men sessionen blockeras av certifikatutfärdaren.
Azure Sentinel mall
Lyckad autentisering när du har inaktiverat äldre autentisering. Medel Inloggningslogg för Azure AD status = lyckades
-and-
Klientapp = Andra klienter, POP, IMAP, MAPI, SMTP, ActiveSync
Om din organisation har inaktiverat äldre autentisering bör du övervaka och varna när en äldre autentisering har lyckats.
Azure Sentinel mall

Vi rekommenderar regelbundet att du granskar autentiseringar till MBI-program (medium business impact) och HBI-program (High Business Impact) där endast enfaktorautentisering krävs. För varje vill du avgöra om enkelfaktorautentisering förväntades eller inte. Granska även lyckade autentiseringsökningar eller vid oväntade tidpunkter baserat på platsen.

Vad som ska övervakas Risknivå Var Filter/underfilter Kommentarer
Autentiseringar till MBI- och HBI-program med hjälp av enfaktorautentisering. Låg Inloggningslogg för Azure AD status = lyckades
-and-
Program-ID = < HBI-app>
-and-
Autentiseringskrav = enkelfaktorautentisering.
Granska och verifiera att konfigurationen är avsiktlig.
Azure Sentinel mall
Autentiseringar vid dagar och tidpunkter i veckan eller året som länder inte utför normal verksamhet. Låg Inloggningslogg för Azure AD Samla in interaktiv autentisering som sker utanför normala driftdagar\tid.
Status = lyckades
Plats = < plats>
Date\Time = < inte normal arbetstid>
Övervaka och avisera om autentiseringsdagar och tider i veckan eller året som länder inte utför normal verksamhet.
Azure Sentinel mall
Mätbar ökning av lyckade inloggningar. Låg Inloggningslogg för Azure AD Infångade ökningar av lyckade autentiseringar över hela linjen. Det vill säga att de totala framgångarna för i dag > är 10 % samma dag som föregående vecka. Om du inte har ett fast tröskelvärde kan du övervaka och varna om lyckade autentiseringar ökar med 10 % eller mer.
Azure Sentinel mall

Nästa steg

Se dessa artiklar i handboken för säkerhetsåtgärder:

Översikt över Azure AD-säkerhetsåtgärder

Säkerhetsåtgärder för användarkonton

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