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 Anslut:
Skogar, domäner och organisationsenheter (OUs) i omfånget för synkronisering. Vem ä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:
Från Azure-portalen kan du visa Microsoft Entra-granskningsloggarna och ladda ned som kommaavgränsade värdefiler (CSV) eller JSON-filer (JavaScript Object Notation). Azure-portalen 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 Identity Protection Preview – 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.
| Vad du ska övervaka | Risknivå | Där | Filtrera/underfilter | Kommentar |
|---|---|---|---|---|
| Händelser för att skapa och ta bort konton inom en nära tidsram. | Högst | Microsoft Entra-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. | Medium | Microsoft Entra-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. | Medium | Microsoft Entra-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ögst | Microsoft Entra-granskningsloggar | Aktivitet: Lägg till användare Status = lyckades -och- Aktivitet: Ta bort användare Status = lyckades -och- Aktivitet: Lägga till medlem i rollen Status = lyckades |
Om kontot har tilldelats en Microsoft Entra-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 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.commedfirstname.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 du ska övervaka | Risknivå | Där | Filtrera/underfilter | Kommentar |
|---|---|---|---|---|
| Användarkonton som inte har definierade förväntade attribut. | Lägst | Microsoft Entra-granskningsloggar | Aktivitet: Lägg till användare Status = lyckades |
Leta efter konton med standardattributen null eller i fel format. Till exempel EmployeeID Microsoft Sentinel-mall |
| Användarkonton som skapats med felaktigt namngivningsformat. | Lägst | Microsoft Entra-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ögst | Azure-prenumeration | Visa en lista över Azure-rolltilldelningar med hjälp av Azure-portalen – 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ögst | Microsoft Entra-katalog | Visa en lista över rolltilldelningar i Microsoft Entra | Visa en avisering om rolltilldelningar för Microsoft Entra-roller där UPN inte matchar organisationens format. Till exempel ADM_ som ett prefix. |
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.
| Vad du ska övervaka | Risknivå | Där | Filtrera/underfilter | Kommentar |
|---|---|---|---|---|
| Användarkonton som skapats eller tagits bort av icke-godkända användare eller processer. | Medium | Microsoft Entra-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. | Medium | Microsoft Entra-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ä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 vilka verktyg som är tillgängliga via Azure-portalen. Med Identity Protection kan du automatisera identifiering, skydd och reparation av identitetsbaserade risker. Identitetsskydd använder intelligensmatade maskininlärnings- 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 Identity Protection-riskidentifieringar informerar idag om risknivåer:
| Vad du ska övervaka | Risknivå | Där | Filtrera/underfilter | Kommentar |
|---|---|---|---|---|
| Identifiering av användarrisk för läckta autentiseringsuppgifter | Högst | Microsoft Entra-riskidentifieringsloggar | UX: Läckta autentiseringsuppgifter API: Se resurstypen riskDetection – Microsoft Graph |
Se Vad är risk? Microsoft Entra ID Protection Sigma-regler |
| Användarriskidentifiering för Microsoft Entra Threat Intelligence | Högst | Microsoft Entra-riskidentifieringsloggar | UX: Microsoft Entra threat intelligence API: Se resurstypen riskDetection – Microsoft Graph |
Se Vad är risk? Microsoft Entra ID Protection Sigma-regler |
| Identifiering av anonym IP-adressinloggningsrisk | Det varierar | Microsoft Entra-riskidentifieringsloggar | UX: Anonym IP-adress API: Se resurstypen riskDetection – Microsoft Graph |
Se Vad är risk? Microsoft Entra ID Protection Sigma-regler |
| Atypisk riskidentifiering för reseinloggning | Det varierar | Microsoft Entra-riskidentifieringsloggar | UX: Atypisk resa API: Se resurstypen riskDetection – Microsoft Graph |
Se Vad är risk? Microsoft Entra ID Protection Sigma-regler |
| Avvikande token | Det varierar | Microsoft Entra-riskidentifieringsloggar | UX: Avvikande token API: Se resurstypen riskDetection – Microsoft Graph |
Se Vad är risk? Microsoft Entra ID Protection Sigma-regler |
| Identifiering av skadlig kod för länkad IP-adress för inloggningsrisk | Det varierar | Microsoft Entra-riskidentifieringsloggar | UX: Länkad IP-adress för skadlig kod API: Se resurstypen riskDetection – Microsoft Graph |
Se Vad är risk? Microsoft Entra ID Protection Sigma-regler |
| Misstänkt identifiering av webbläsarinloggningsrisk | Det varierar | Microsoft Entra-riskidentifieringsloggar | UX: Misstänkt webbläsare API: Se resurstypen riskDetection – Microsoft Graph |
Se Vad är risk? Microsoft Entra ID Protection Sigma-regler |
| Okända inloggningsegenskaper inloggningsriskidentifiering | Det varierar | Microsoft Entra-riskidentifieringsloggar | UX: Okända inloggningsegenskaper API: Se resurstypen riskDetection – Microsoft Graph |
Se Vad är risk? Microsoft Entra ID Protection Sigma-regler |
| Identifiering av skadlig IP-adressinloggningsrisk | Det varierar | Microsoft Entra-riskidentifieringsloggar | UX: Skadlig IP-adress API: Se resurstypen riskDetection – Microsoft Graph |
Se Vad är risk? Microsoft Entra ID Protection Sigma-regler |
| Misstänkt identifiering av inkorgsmanipuleringsregler för inloggningsrisk | Det varierar | Microsoft Entra-riskidentifieringsloggar | UX: Misstänkta regler för inkorgsmanipulering API: Se resurstypen riskDetection – Microsoft Graph |
Se Vad är risk? Microsoft Entra ID Protection Sigma-regler |
| Inloggningsriskidentifiering för lösenordsspray | Högst | Microsoft Entra-riskidentifieringsloggar | UX: Lösenordsspray API: Se resurstypen riskDetection – Microsoft Graph |
Se Vad är risk? Microsoft Entra ID Protection Sigma-regler |
| Riskidentifiering av omöjlig reseinloggning | Det varierar | Microsoft Entra-riskidentifieringsloggar | UX: Omöjlig resa API: Se resurstypen riskDetection – Microsoft Graph |
Se Vad är risk? Microsoft Entra ID Protection Sigma-regler |
| Ny identifiering av inloggningsrisk för land/region | Det varierar | Microsoft Entra-riskidentifieringsloggar | UX: Nytt land/region API: Se resurstypen riskDetection – Microsoft Graph |
Se Vad är risk? Microsoft Entra ID Protection Sigma-regler |
| Aktivitet från identifiering av anonym IP-adressinloggningsrisk | Det varierar | Microsoft Entra-riskidentifieringsloggar | UX: Aktivitet från anonym IP-adress API: Se resurstypen riskDetection – Microsoft Graph |
Se Vad är risk? Microsoft Entra ID Protection Sigma-regler |
| Misstänkt vidarebefordran av inloggningsriskidentifiering i inkorgen | Det varierar | Microsoft Entra-riskidentifieringsloggar | UX: Misstänkt vidarebefordran av inkorgen API: Se resurstypen riskDetection – Microsoft Graph |
Se Vad är risk? Microsoft Entra ID Protection Sigma-regler |
| Inloggningsriskidentifiering för Microsoft Entra-hotinformation | Högst | Microsoft Entra-riskidentifieringsloggar | UX: Microsoft Entra threat intelligence API: Se resurstypen riskDetection – Microsoft Graph |
Se Vad är risk? Microsoft Entra ID Protection Sigma-regler |
Mer information finns i Vad är identitetsskydd.
Vad du ska söka 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.
Identifiera
Du använder Microsoft Entra ID Protection och Inloggningsloggarna för Microsoft Entra för att identifiera hot som indikeras av ovanliga inloggningsegenskaper. Information om Identity Protection finns på Vad är identitetsskydd. 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 avisera om Identity 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 Identity 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 Identitetsskyddsprinciper. Mer information om hur du konfigurerar villkorlig åtkomst finns i Villkorlig å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å | Där | Filtrera/underfilter | Kommentar |
|---|---|---|---|---|
| Användare som autentiserar till andra Microsoft Entra-klienter. | Lägst | Inloggningslogg för Microsoft Entra | Status = lyckades Resursklient-ID != Hemklient-ID |
Identifierar när en användare har autentiserats till en annan Microsoft Entra-klientorganisation med en identitet i organisationens klientorganisation. Avisering om Resource TenantID inte är lika med hemklient-ID Microsoft Sentinel-mall Sigma-regler |
| Användartillståndet har ändrats från gäst till medlem | Medium | Microsoft Entra-granskningsloggar | Aktivitet: Uppdatera användare Kategori: UserManagement UserType har ändrats från gäst till medlem |
Övervaka och varna vid ändring av användartyp från Gäst till Medlem. Var det här väntat? Microsoft Sentinel-mall Sigma-regler |
| Gästanvändare som bjuds in till klientorganisationen av icke-godkända inbjudna | Medium | Microsoft Entra-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 för misslyckade ovanliga inloggningar
| Vad du ska övervaka | Risknivå | Där | Filtrera/underfilter | Kommentar |
|---|---|---|---|---|
| Misslyckade inloggningsförsök. | Medel – om isolerad incident Hög – om många konton har samma mönster eller VIP. |
Inloggningslogg för Microsoft Entra | 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 att falska aviseringar genereras. Microsoft Sentinel-mall Sigma-regler |
| Smarta utelåsningshändelser. | Medel – om isolerad incident Hög – om många konton har samma mönster eller VIP. |
Inloggningslogg för Microsoft Entra | 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 att falska aviseringar genereras. Microsoft Sentinel-mall Sigma-regler |
| Avbryter | Medel – om isolerad incident Hög – om många konton har samma mönster eller VIP. |
Inloggningslogg för Microsoft Entra | 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, ExternalSecurityChallenge – Den externa säkerhetsutmaningen uppfylldes inte -eller- 53003 och felorsak = blockerad av villkorlig åtkomst |
Övervaka och avisera om avbrott. Definiera ett baslinjetröskelvärde och övervaka och justera sedan för att anpassa organisationens beteenden och begränsa att falska aviseringar genereras. Microsoft Sentinel-mall Sigma-regler |
Följande listas i prioritetsordning baserat på effekten och allvarlighetsgraden för posterna.
| Vad du ska övervaka | Risknivå | Där | Filtrera/underfilter | Kommentar |
|---|---|---|---|---|
| Bedrägeriaviseringar för multifaktorautentisering (MFA). | Högst | Inloggningslogg för Microsoft Entra | Status = misslyckades -och- Information = MFA nekad |
Övervaka och avisera om en post. Microsoft Sentinel-mall Sigma-regler |
| Misslyckade autentiseringar från länder/regioner som du inte använder. | Medium | Inloggningslogg för Microsoft Entra | Plats = <ej godkänd plats> | Övervaka och avisera om poster. Microsoft Sentinel-mall Sigma-regler |
| Misslyckade autentiseringar för äldre protokoll eller protokoll som inte används. | Medium | Inloggningslogg för Microsoft Entra | Status = fel -och- Klientapp = Andra klienter, POP, IMAP, MAPI, SMTP, ActiveSync |
Övervaka och avisera om poster. Microsoft Sentinel-mall Sigma-regler |
| Fel som blockeras av villkorlig åtkomst. | Medium | Inloggningslogg för Microsoft Entra | Felkod = 53003 -och- Felorsak = blockerad av villkorlig åtkomst |
Övervaka och avisera om poster. Microsoft Sentinel-mall Sigma-regler |
| Ökade misslyckade autentiseringar av någon typ. | Medium | Inloggningslogg för Microsoft Entra | Samla in ökningar av fel över hela linjen. Det vill:s felsumma för i dag är >10 % samma dag, föregående vecka. | Om du inte har ett angivet tröskelvärde övervakar och varnar du om felen ökar med 10 % eller högre. Microsoft Sentinel-mall |
| Autentisering sker vid tidpunkter och dagar i veckan när länder/regioner inte utför normala affärsåtgärder. | Lägst | Inloggningslogg för Microsoft Entra | Samla in interaktiv autentisering som inträffar utanför normala driftdagar\tid. Status = lyckades -och- Plats = <plats> -och- Dag\Tid = <inte normal arbetstid> |
Övervaka och avisera om poster. Microsoft Sentinel-mall |
| Kontot har inaktiverats/blockerats för inloggningar | Lägst | Inloggningslogg för Microsoft Entra | 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 avisera om den här aktiviteten. Microsoft Sentinel-mall Sigma-regler |
Övervakning för lyckade ovanliga inloggningar
| Vad du ska övervaka | Risknivå | Där | Filtrera/underfilter | Kommentar |
|---|---|---|---|---|
| Autentisering av privilegierade konton utanför förväntade kontroller. | Högst | Inloggningslogg för Microsoft Entra | Status = lyckades -och- UserPricipalName = <Administratörskonto> -och- Plats = <ej godkänd plats> -och- IP-adress = <ej godkänd IP-adress> Enhetsinformation= <ej godkänd webbläsare, operativsystem> |
Övervaka och avisera 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ägst | Inloggningslogg för Microsoft Entra | Status = lyckades Autentiseringskrav = Enfaktorsautentisering |
Övervaka regelbundet och se till att beteendet förväntas. Sigma-regler |
| Identifiera privilegierade konton som inte har registrerats för MFA. | Högst | Azure Graph API | Fråga efter IsMFARegistered eq false för administratörskonton. Lista credentialUserRegistrationDetails – Betaversionen av Microsoft Graph |
Granska och undersöka för att avgöra om det är avsiktligt eller ett förbiseende. |
| Lyckade autentiseringar från länder/regioner som din organisation inte fungerar utifrån. | Medium | Inloggningslogg för Microsoft Entra | Status = lyckades Plats = <ej godkänt land/region> |
Övervaka och varna för poster som inte är lika med de stadsnamn som du anger. Sigma-regler |
| Lyckad autentisering, session blockerad av villkorsstyrd åtkomst. | Medium | Inloggningslogg för Microsoft Entra | Status = lyckades -och- felkod = 53003 – Felorsak, blockerad av villkorlig åtkomst |
Övervaka och undersöka när autentiseringen lyckas, men sessionen blockeras av villkorlig åtkomst. Microsoft Sentinel-mall Sigma-regler |
| Lyckad autentisering när du har inaktiverat äldre autentisering. | Medium | Inloggningslogg för Microsoft Entra | status = lyckades -och- Klientapp = Andra klienter, POP, IMAP, MAPI, SMTP, ActiveSync |
Om din organisation har inaktiverat äldre autentisering övervakar och aviserar du när den äldre autentiseringen har slutfö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. Dessutom kan du granska för lyckad autentisering ökar eller vid oväntade tidpunkter, baserat på platsen.
| Vad du ska övervaka | Risknivå | Där | Filtrera/underfilter | Kommentar |
|---|---|---|---|---|
| Autentiseringar till MBI- och HBI-program med hjälp av enfaktorautentisering. | Lägst | Inloggningslogg för Microsoft Entra | status = lyckades -och- Program-ID = <HBI-app> -och- Autentiseringskrav = enfaktorautentisering. |
Granska och verifiera att den här konfigurationen är avsiktlig. Sigma-regler |
| Autentiseringar vid dagar och tider på veckan eller året som länder/regioner inte utför normala affärsåtgärder. | Lägst | Inloggningslogg för Microsoft Entra | Samla in interaktiv autentisering som inträffar utanför normala driftdagar\tid. Status = lyckades Plats = <plats> Datum\Tid = <inte normal arbetstid> |
Övervaka och varna för autentiseringsdagar och tider på veckan eller året som länder/regioner inte utför normala affärsåtgärder. Sigma-regler |
| Mätbar ökning av lyckade inloggningar. | Lägst | Inloggningslogg för Microsoft Entra | Samla in ökningar av lyckad autentisering över hela linjen. Det vill:s resultatsummor för idag är >10 % samma dag, föregående vecka. | Om du inte har ett angivet tröskelvärde övervakar och varnar du om lyckade autentiseringar ökar med 10 % eller högre. Microsoft Sentinel-mall Sigma-regler |
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