Undersökning av beviljande av appmedgivande

  • Artikel

Den här artikeln innehåller vägledning om hur du identifierar och undersöker appmedgivandeattacker, skyddar information och minimerar ytterligare risker.

Den här artikeln innehåller följande avsnitt:

  • Krav: Omfattar de specifika krav som du behöver slutföra innan du påbörjar undersökningen. Till exempel loggning som ska aktiveras, roller och behörigheter som krävs, bland annat.
  • Arbetsflöde: Visar det logiska flöde som du bör följa för att utföra den här undersökningen.
  • Checklista: Innehåller en lista över uppgifter för vart och ett av stegen i flödesdiagrammet. Den här checklistan kan vara till hjälp i strikt reglerade miljöer för att verifiera åtgärder som vidtagits eller helt enkelt som en kvalitetsgrind för dig själv.
  • Undersökningssteg: Innehåller en detaljerad stegvis vägledning för den här specifika undersökningen.
  • Återställning: Innehåller steg på hög nivå om hur du återställer/minimerar från en attack med otillåtet programmedgivande.
  • Referenser: Innehåller mer läs- och referensmaterial.

Förutsättningar

Här är allmänna inställningar och konfigurationer som du bör slutföra för att utföra en undersökning av bidrag för programmedgivande. Innan du påbörjar undersökningen måste du läsa om de typer av medgivandebehörigheter som beskrivs i Behörighetstyper för medgivande.

Kunddata

För att starta undersökningsprocessen behöver du följande data:

  • Åtkomst till klientorganisationen som global administratör – Endast ett molnkonto (inte en del av deras lokala miljö)
  • Information om indikatorer för kompromisser (IoCs)
  • Datum och tid när du märkte incidenten
  • Datumintervall
  • Antal komprometterade konton
  • Namn på komprometterade konton
  • Roller för det komprometterade kontot
  • Är kontona mycket privilegierade (GA Microsoft Exchange, SharePoint)?
  • Finns det några företagsprogram som är relaterade till incidenten?
  • Har några användare rapportera om program som begär behörighet till data för deras räkning?

Systemkrav

Se till att du uppfyller följande installationer och konfigurationskrav:

  1. AzureAD PowerShell-modulen är installerad.
  2. Du har globala administratörsrättigheter för klientorganisationen som skriptet körs mot.
  3. Du har tilldelats en lokal administratörsroll på den dator som du använder för att köra skripten.

Kommentar

Azure AD- och MSOnline PowerShell-moduler är inaktuella från och med den 30 mars 2024. Mer information finns i utfasningsuppdateringen. Efter det här datumet är stödet för dessa moduler begränsat till migreringshjälp till Microsoft Graph PowerShell SDK och säkerhetskorrigeringar. De inaktuella modulerna fortsätter att fungera till och med mars 30 2025.

Vi rekommenderar att du migrerar till Microsoft Graph PowerShell för att interagera med Microsoft Entra-ID (tidigare Azure AD). Vanliga migreringsfrågor finns i Vanliga frågor och svar om migrering. Obs! Versioner 1.0.x av MSOnline kan uppleva störningar efter den 30 juni 2024.

Installera AzureAD-modulen

Använd det här kommandot för att installera AzureAD-modulen.

Install-Module -Name AzureAD -Verbose

Kommentar

Om du uppmanas att installera modulerna från en obetrodd lagringsplats skriver du Y och trycker på Retur.

Installera MSOnline PowerShell-modulen

  1. Kör Windows PowerShell-appen med utökade privilegier (kör som administratör).

  2. Kör det här kommandot för att tillåta att PowerShell kör signerade skript.

    Set-ExecutionPolicy RemoteSigned

  3. Installera MSOnline-modulen med det här kommandot.

    Install-Module -Name MSOnline -Verbose

    Kommentar

    Om du uppmanas att installera modulerna från en obetrodd lagringsplats skriver du Y och trycker på Retur.

Ladda ned skriptet AzureADPSPermissions från GitHub

  1. Ladda ned skriptet Get-AzureADPSPermissions.ps1 från GitHub till en mapp som du kör skriptet från. Utdatafilen "permissions.csv" skrivs också till samma mapp.

  2. Öppna en PowerShell-instans som administratör och öppna mappen där du sparade skriptet.

  3. Anslut till din katalog med hjälp av cmdletenConnect-AzureAD. Här följer ett exempel.

    Connect-AzureAD -tenantid "2b1a14ac-2956-442f-9577-1234567890ab" -AccountId "user1@contoso.onmicrosoft.com"

  4. Kör det här PowerShell-kommandot.

    Get-AzureADPSPermissions.ps1 | Export-csv -Path "Permissions.csv" -NoTypeInformation

    Koppla från AzureAD-sessionen med det här kommandot.

    Disconnect-AzureAD

Medgivande är processen att bevilja auktorisering till ett program för att få åtkomst till skyddade resurser för användarnas räkning. En administratör eller användare kan uppmanas att ge sitt medgivande för att tillåta åtkomst till organisationens/enskilda data.

Ett program beviljas åtkomst till data baserat på en viss användare eller för hela organisationen. Angripare kan missbruka dessa medgivanden för att få beständighet i miljön och få åtkomst till känsliga data. Dessa typer av attacker kallas otillåtna medgivandebidrag, vilket kan ske via ett nätfiskemeddelande, ett användarkonto som komprometteras via lösenordsspray eller när en angripare registrerar ett program som en legitim användare. I scenarier där ett globalt administratörskonto komprometteras är beviljandet av registrering och medgivande för hela klientorganisationen och inte bara för en användare.

Innan ett program kan komma åt organisationens data måste en användare ge programmet behörighet för detta. Olika behörigheter tillåter olika åtkomstnivåer. Som standard tillåts alla användare att godkänna program för behörigheter som inte kräver administratörsmedgivande. En användare kan till exempel som standard samtycka till att tillåta att en app får åtkomst till sin postlåda, men kan inte samtycka till att tillåta oinskränkt åtkomst för en app att läsa och skriva till alla filer i organisationen.

Kommentar

Genom att tillåta användare att ge appar åtkomst till data kan användarna enkelt skaffa användbara program och vara produktiva. I vissa situationer kan dock den här konfigurationen utgöra en risk om den inte övervakas och kontrolleras noggrant.

För att kunna bevilja administratörsmedgivande för hela klientorganisationen måste du logga in som något av följande:

  • Global administratör
  • Appadministratör
  • Molnappadministratör
  • Administratör – anger att medgivandet har tillhandahållits av administratören (för organisationens räkning)
  • Enskild användare – Anger att medgivandet har beviljats av användaren och endast har åtkomst till användarens information
  • Godkända värden
    • AllPrincipals – Medgivande av en administratör för hela innehavarorganisationen
    • Principal – Medgivande av den enskilda användaren för data som endast är relaterade till det kontot

Den faktiska användarupplevelsen av att bevilja medgivande skiljer sig beroende på de principer som angetts för användarens klientorganisation, användarens behörighetsområde (eller roll) och vilken typ av behörigheter som begärs av klientprogrammet. Det innebär att programutvecklare och klientadministratörer har viss kontroll över medgivandeupplevelsen. Administratörer har flexibiliteten att ange och inaktivera principer för en klientorganisation eller app för att kontrollera medgivandeupplevelsen i klientorganisationen. Programutvecklare kan bestämma vilka typer av behörigheter som begärs och om de vill vägleda användare genom flödet för användarmedgivande eller flödet för administratörsmedgivande.

  • Flöde för användarmedgivande – När en programutvecklare dirigerar användare till auktoriseringsslutpunkten med avsikten att registrera medgivande för endast den aktuella användaren.

  • Flöde för administratörsmedgivande – När en programutvecklare dirigerar användare till slutpunkten för administratörsmedgivande med avsikt att registrera medgivande för hela klientorganisationen. För att säkerställa att administratörsmedgivandeflödet fungerar korrekt måste programutvecklare visa alla behörigheter i egenskapen RequiredResourceAccess i programmanifestet.

Delegerade behörigheter jämfört med programbehörigheter

Delegerade behörigheter används av appar som har en inloggad användare närvarande och kan få medgivanden tillämpade av administratören eller användaren.

Programbehörigheter används av appar som körs utan någon inloggad användare. Till exempel appar som körs som bakgrundstjänster eller daemoner. Programbehörigheter kan endast godkännas av en administratör.

Mer information finns i:

Klassificera riskfyllda behörigheter

Det finns tusentals (minst) behörigheter i systemet och det går inte att lista ut eller parsa alla dessa. I följande lista behandlas behörigheter som ofta missbrukas och andra som skulle skapa katastrofala effekter om de missbrukas.

På hög nivå har Microsoft observerat att följande "rot"-delegerade (App+User)-behörigheter missbrukas vid nätfiskeattacker med medgivande. Roten motsvarar den översta nivån. Kontakter.* innebär till exempel att inkludera alla delegerade permutationer av behörigheter för kontakter: Contacts.Read, Contacts.ReadWrite, Contacts.Read.Shared och Contacts.ReadWrite.Shared.

  1. Mail.* (inklusive Mail.Send*, men inte Mail.ReadBasic*)
  2. Kontakter. *
  3. Postlåda Inställningar.*
  4. Personer.*
  5. Filer.*
  6. Anteckningar.*
  7. Directory.AccessAsUser.All
  8. User_Impersonation

De första sju behörigheterna i listan ovan gäller för Microsoft Graph och "äldre" API-motsvarigheter, till exempel Azure Active Directory (Azure AD) Graph och Outlook REST. Den åttonde behörigheten är för Azure Resource Manager (ARM) och kan också vara farlig för alla API:er som exponerar känsliga data med det här generella personifieringsomfånget.

Baserat på Microsoft Incident Response-teamets observationer använder angripare en kombination av de sex första behörigheterna i 99 % av nätfiskeattackerna med medgivande. De flesta tänker inte på den delegerade versionen av Mail.Read eller Files.Read som en högriskbehörighet, men attackerna är i allmänhet utbredda attacker riktade mot slutanvändare, snarare än spear phishing mot administratörer som faktiskt kan samtycka till de farliga behörigheterna. Vi rekommenderar att du bubblar appar med dessa "kritiska" effektbehörigheter. Även om programmen inte har skadliga avsikter, och om en dålig aktör skulle kompromettera appidentiteten, kan hela organisationen vara i fara.

För behörigheter med störst riskpåverkan börjar du här:

  • Programbehörighetsversioner (AppOnly/AppRole) av alla ovanstående behörigheter, i förekommande fall

Delegerade och AppOnly-versioner av följande behörigheter:

  • Application.ReadWrite.All
  • Directory.ReadWrite.All
  • Domain.ReadWrite.All*
  • EduRoster.ReadWrite.All*
  • Group.ReadWrite.All
  • Member.Read.Hidden*
  • RoleManagement.ReadWrite.Directory
  • User.ReadWrite.All*
  • User.ManageCreds.All
  • Alla andra AppOnly-behörigheter som tillåter skrivåtkomst

Börja här för listan med behörigheter med lägst riskpåverkan:

  • User.Read
  • User.ReadBasic.All
  • Open_id
  • E-post
  • Profil
  • Offline_access (endast om de är kopplade till andra behörigheter i listan med "lägsta risk")

Visa behörigheter

  1. Om du vill visa behörigheterna går du till skärmen Registrering i företagsprogrammet.

    visa behörigheter

  2. Välj Visa API-behörigheter.

    apipermissioner

  3. Välj Lägg till en behörighet så visas följande skärm.

    api

  4. Välj Microsoft Graph för att visa de olika typerna av behörigheter.

    typer av behörigheter

  5. Välj den typ av behörigheter som det registrerade programmet använder: Delegeradebehörigheter eller Programbehörigheter. I bilden ovan är programbehörigheter valda.

  6. Du kan söka efter någon av behörigheterna för högriskpåverkan, till exempel EduRoster.

    examplepermission

  7. Välj EduRoster och expandera behörigheterna.

    eduroster

  8. Du kan nu tilldela eller granska dessa behörigheter.

    Mer information finns i Graph-behörigheter.

Arbetsflöde

[Arbetsflöde för att bevilja appmedgivande för undersökning]

Du kan även:

  • Ladda ned beviljandet av appmedgivande och andra arbetsflöden för incidenthanteringsspelböcker som PDF.
  • Ladda ned appmedgivandet och andra arbetsflöden för incidenthanteringsspelböcker som en Visio-fil.

Checklista

Använd den här checklistan för att utföra validering av beviljande av programmedgivande.

  • Krav

    Kontrollera att du har åtkomst till klientorganisationen som global administratör. Det här är ett molnbaserat konto och ingår inte i din lokala miljö.

  • Indikatorer för kompromiss (IoC)

    Kontrollera följande indikatorer för kompromiss (IoC):

    • När märkte du incidenten?
    • Datumintervall för incidenten (hur långt till vänster är målposten?)
    • Antal komprometterade konton
    • Namn på komprometterade konton
    • Roller för de komprometterade kontona
    • Är de komprometterade kontona mycket privilegierade, en standardanvändare eller en kombination

  • Roller

    Du måste tilldelas följande roller:

    • Global administratörsbehörighet för klientorganisationen för att köra skriptet
    • Lokal administratörsroll på den dator som du kör skriptet från

  • PowerShell-konfiguration

    Konfigurera PowerShell-miljön med följande steg:

    1. Installera Azure AD PowerShell-modulen.
    2. Kör Windows PowerShell-appen med utökade privilegier. (Kör som administratör).
    3. Konfigurera PowerShell för att köra signerade skript.
    4. Ladda ned skriptet Get-AzureADPSPermissions.ps1 .

  • Undersökningsutlösare

    • Kontokompromiss
    • Inställningar för appmedgivande som ändrats för klientorganisationen
    • Orsak till aviserings-/granskningshändelsestatus "riskfyllt program" har identifierats
    • Märkte udda program

Du kan också ladda ned beviljandet av appmedgivande och andra checklistor för incidentspelböcker som en Excel-fil.

Undersökningssteg

Du kan använda följande två metoder för att undersöka bidrag för programmedgivande:

  • Azure Portal
  • PowerShell-skript

Kommentar

Med Hjälp av Azure-portalen kan du bara se bidrag för administratörsmedgivande under de senaste 90 dagarna, och baserat på detta rekommenderar vi att du använder PowerShell-skriptmetoden endast för att minska undersökningsstegen för angripareregister.

Metod 1 – Använda Azure-portalen

Du kan använda administrationscentret för Microsoft Entra för att hitta program som enskilda användare har beviljat behörigheter.

  1. Logga in på Azure-portalen som administratör.
  2. Välj microsoft entra-ID-ikonen.
  3. Välj Användare.
  4. Välj den användare som du vill granska.
  5. Välj ansökning.
  6. Du kan se listan över appar som har tilldelats användaren och vilka behörigheter dessa program har.

Metod 2 – Använda PowerShell

Det finns flera PowerShell-verktyg som du kan använda för att undersöka otillåtna medgivandebidrag, till exempel:

PowerShell är det enklaste verktyget och kräver inte att du ändrar något i innehavare. Vi ska basera vår undersökning på den offentliga dokumentationen från attacken med illegalt medgivande.

Kör Get-AzureADPSPermissions.ps1för att exportera alla OAuth-medgivande och OAuth-appar för alla användare i din innehavarorganisation till en .csv fil. Se avsnittet Förutsättningar för att ladda ned och köra skriptet Get-AzureADPSPermissions .

  1. Öppna en PowerShell-instans som administratör och öppna mappen där du sparade skriptet.

  2. Anslut till din katalog med hjälp av följande Anslut AzureAD-kommando. Här följer ett exempel.

    Connect-AzureAD -tenantid "2b1a14ac-2956-442f-9577-1234567890ab" -AccountId "user1@contoso.onmicrosoft.com"

  3. Kör det här PowerShell-kommandot.

    Get-AzureADPSPermissions.ps1 | Export-csv c:\temp\consentgrants\Permissions.csv -NoTypeInformation

  4. När skriptet är klart rekommenderar vi att du kopplar från Microsoft Entra-sessionen med det här kommandot.

     Disconnect-AzureAD

    Kommentar

    Skriptet kan ta timmar att slutföra, beroende på storleken och behörigheterna som har konfigurerats samt anslutningen.

  5. Skriptet skapar en fil med namnet Permissions.csv.

  6. Öppna filen, filtrera eller formatera data i en tabell och spara som en .xlxs-fil (för filtrering).

    Kolumnrubrikerna för utdata visas i den här bilden.

    Exempel på kolumnrubriker

  7. I kolumnen ConsentType (G) söker du efter värdet AllPrinciples. Med AllPrincipals-behörigheten kan klientprogrammet komma åt allas innehåll i innehavet. Inbyggda Microsoft 365-program behöver den här behörigheten för att fungera korrekt. Alla program som inte kommer från Microsoft med den här behörigheten bör granskas noggrant.

  8. I kolumnen Behörighet (F) granskar du de behörigheter som varje delegerat program har. Leta efter läs- och skrivbehörighet eller *. All behörighet och granska dessa behörigheter noggrant eftersom de kanske inte är lämpliga. Exempel på behörighetskolumn F

    Kommentar

    Granska de specifika användare som har medgivanden beviljade. Om användare med hög profil eller hög påverkan får olämpliga medgivanden beviljade bör du undersöka saken ytterligare.

  9. I kolumnen ClientDisplayName (C) letar du efter appar som verkar misstänkta, till exempel:

    • Appar med felstavade namn Exempel på ett felstavat namn

    • Ovanliga eller intetsägande namn Exempel på ett ovanligt namn

    • Hacker-klingande namn. Du måste granska dessa namn noggrant. Exempel på ett hackernamn

Exempel på utdata: AllPrincipals och läs skriva alla. Program kanske inte har något misstänkt som intetsägande namn och använder MS Graph. Utför dock forskning och fastställa syftet med programmen och de faktiska behörigheter som programmen har i klientorganisationen, som du ser i det här exemplet.

Exempel på program med AllPrincipals ConsentType

Här följer några användbara tips för att granska undersökningar av informationssäkerhetsprinciper (ISP):

  1. ReplyURL/RedirectURL
    • Leta efter misstänkta URL:er
  2. Finns URL:en på en misstänkt domän?
    • Är det komprometterat?
    • Har domänen nyligen registrerats?
    • Är det en tillfällig domän?
  3. Finns det en länk till tjänst-/tjänstavtalslänken i appregistreringen?
  4. Är innehållet unikt och specifikt för programmet/utgivaren?
  5. Är klientorganisationen som registrerade programmet antingen nyligen skapat eller komprometterat (till exempel är appen registrerad av en riskanvändare)?

Attacktekniker

Även om varje attack tenderar att variera, är de viktigaste attackteknikerna:

  • En angripare registrerar en app med en OAuth 2.0-provider, till exempel Microsoft Entra-ID.

  • Appen konfigureras på ett sätt som gör att den verkar legitim. Angripare kan till exempel använda namnet på en populär produkt som är tillgänglig i samma ekosystem.

  • Angriparen får en länk direkt från användare, vilket kan göras via konventionell e-postbaserad nätfiske, genom att kompromettera en icke-skadlig webbplats eller genom andra tekniker.

  • Användaren väljer länken och visas en fråga om autentiskt medgivande som ber dem att bevilja skadlig app behörighet till data.

  • Om en användare väljer "Acceptera" ger de appen behörighet att komma åt känsliga data.

  • Appen hämtar en auktoriseringskod som den löser in mot en åtkomsttoken och potentiellt en uppdateringstoken.

  • Åtkomsttoken används för att göra API-anrop åt användaren.

  • Om användaren accepterar kan angriparen få åtkomst till användarens e-post, vidarebefordringsregler, filer, kontakter, anteckningar, profil och andra känsliga data och resurser.

    Exempel på behörighetsbegäran

Hitta tecken på en attack

  1. Öppna Säkerhets- och efterlevnadscentret.

  2. Gå till Sök och välj Granskningsloggsökning.

  3. Sök (alla aktiviteter och alla användare) och ange startdatum och slutdatum (om det behövs) och välj sedan Sök.

    Exempel på en granskningsloggsökning

  4. Välj Filtrera resultat och i fältet Aktivitet anger du Medgivande till program.

    Exempel på filtrering av en granskningsloggsökning

  5. Om du har aktivitet under medgivande att bevilja fortsätter du enligt anvisningarna nedan.

  6. Välj resultatet för att se information om aktiviteten. Välj Mer information för att få information om aktiviteten.

  7. Kontrollera om IsAdminContent är inställt på "True".

    Kommentar

    Den här processen kan ta från 30 minuter upp till 24 timmar innan motsvarande granskningsloggpost visas i sökresultaten när en händelse inträffar.

    Hur länge en granskningspost behålls och kan sökas i granskningsloggen beror på din Microsoft 365-prenumeration, och specifikt vilken typ av licens som har tilldelats till en viss användare. Om det här värdet är sant anger det att någon med global administratörsåtkomst kan ha beviljat bred åtkomst till data. Om detta är oväntat bör du vidta omedelbara åtgärder för att bekräfta en attack.

Hur bekräftar jag en attack?

Om du har en eller flera instanser av IOCs som tidigare angavs måste du göra ytterligare undersökning för att bekräfta att attacken inträffade.

Inventera appar med åtkomst i din organisation

Du kan inventera appar för dina användare med hjälp av administrationscentret för Microsoft Entra, PowerShell eller låta användarna räkna upp sin programåtkomst individuellt.

  • Använd administrationscentret för Microsoft Entra för att inventera program och deras behörigheter. Den här metoden är grundlig, men du kan bara kontrollera en användare i taget, vilket kan vara tidskrävande om du måste kontrollera behörigheterna för flera användare.
  • Använd PowerShell för att inventera program och deras behörigheter. Den här metoden är den snabbaste och mest grundliga, med minst omkostnader.
  • Uppmuntra användarna att individuellt kontrollera sina appar och behörigheter och rapportera resultaten tillbaka till administratörerna för reparation.

Inventeringsappar som tilldelats användare

Du kan använda administrationscentret för Microsoft Entra för att se listan över appar som enskilda användare har beviljat behörigheter till.

  1. Logga in på Azure-portalen med administrativa rättigheter.
  2. Välj microsoft entra-ID-ikonen.
  3. Välj Användare.
  4. Välj den användare som du vill granska.
  5. Välj ansökning.

Du kan se listan över appar som har tilldelats användaren och de behörigheter som beviljats till dessa appar.

Fastställa omfattningen av attacken

När du har slutfört inventeringen av programåtkomsten granskar du granskningsloggen för att fastställa hela omfattningen av överträdelsen. Sök efter berörda användare, tidsramarna som det olagliga programmet hade åtkomst till din organisation och de behörigheter som appen hade. Du kan söka i granskningsloggen i Microsoft 365 Security & Compliance Center.

Viktigt: Om granskning inte var aktiverat före den möjliga attacken kan du inte undersöka det eftersom granskningsdata inte är tillgängliga.

Hur förhindrar du attacker och minimerar risker?

Om din organisation har rätt licens:

  • Använd fler granskningsfunktioner för OAuth-program i Microsoft Defender för molnet Appar.
  • Använd Azure Monitor-arbetsböcker för att övervaka behörigheter och medgivanderelaterad aktivitet. Consent Insights-arbetsboken ger en vy över appar efter antal misslyckade begäranden om medgivande. Detta kan vara användbart för att prioritera program som administratörer kan granska och besluta om de ska beviljas administratörsmedgivande.

När du har identifierat ett program med otillåtna behörigheter inaktiverar du omedelbart programmet genom att följa anvisningarna i Inaktivera ett program. Kontakta sedan Microsoft Support för att rapportera det skadliga programmet.

När ett program har inaktiverats i din Microsoft Entra-klientorganisation kan det inte hämta nya token för att komma åt data, och andra användare kommer inte att kunna logga in på eller bevilja medgivande till appen.

Kommentar

Om du misstänker att du har stött på ett skadligt program i din organisation är det bättre att inaktivera det än att ta bort det. Om du bara tar bort programmet kan det returneras senare om en annan användare beviljar medgivande. Inaktivera i stället programmet för att se till att det inte kan komma tillbaka senare.

Steg för att skydda din organisation

Det finns olika typer av medgivandeattacker, men om du följer dessa rekommenderade skydd, som minimerar alla typer av attacker, särskilt medgivandefiske, där angripare lurar användare att bevilja en skadlig app åtkomst till känsliga data eller andra resurser. I stället för att försöka stjäla användarens lösenord söker en angripare behörighet för en angripare kontrollerad app för att få åtkomst till värdefulla data.

Information om hur du förhindrar att medgivandeattacker påverkar Microsoft Entra-ID och Office 365 finns i följande rekommendationer:

Ange principer

  • Den här inställningen har användarkonsekvenser och kanske inte gäller för en miljö. Om du ska tillåta eventuella medgivanden ska du se till att administratörerna godkänner begäranden.

  • Tillåt endast medgivanden för program från verifierade utgivare och specifika typer av behörigheter som klassificeras som låg påverkan.

    Kommentar

    Ovanstående rekommendationer föreslås baserat på de mest idealiska och säkra konfigurationerna. Men eftersom säkerheten är en bra balans mellan funktioner och åtgärder kan de säkraste konfigurationerna orsaka mer omkostnader för administratörer. Det är ett beslut som bäst fattas efter samråd med dina administratörer.

    Konfigurera riskbaserat step-up-medgivande – Aktiverad som standard om användarens medgivande till bidrag är aktiverat

  • Riskbaserat stegvisa medgivande hjälper till att minska användarnas exponering för skadliga appar som gör begäranden om olagligt medgivande. Om Microsoft identifierar en riskfylld begäran om slutanvändarmedgivande kräver begäran en "step-up" för administratörsmedgivande i stället. Den här funktionen är aktiverad som standard, men det resulterar bara i en beteendeförändring när slutanvändares medgivande är aktiverat.

  • När en begäran om riskfyllt medgivande identifieras visar medgivandeprompten ett meddelande som anger att administratörsgodkännande krävs. Om arbetsflödet för begäran om administratörsmedgivande är aktiverat kan användaren skicka begäran till administratören för ytterligare granskning direkt från medgivandeprompten. Om det är aktiverat visas följande meddelande:

    AADSTS90094: <clientAppDisplayName> behöver behörighet att komma åt resurser i din organisation som endast en administratör kan bevilja. Be en administratör att bevilja behörighet till den här appen innan du kan använda den. I det här fallet loggas även en granskningshändelse med en kategori av aktivitetstypen "ApplicationManagement" för "Medgivande till program" och statusorsaken till "Riskfyllt program har identifierats".

Kommentar

Alla uppgifter som kräver administratörens godkännande har driftkostnader. "Inställningar för medgivande och behörigheter, användarmedgivande" finns för närvarande i förhandsversion . När den är redo för allmän tillgänglighet (GA) bör funktionen "Tillåt användarmedgivande från verifierade utgivare, för valda behörigheter" minska administratörernas omkostnader och rekommenderas för de flesta organisationer.

Samtycke

Utbilda dina programutvecklare om att följa ekosystemet för betrodda appar. För att hjälpa utvecklare att skapa högkvalitativa och säkra integreringar presenterar vi även en offentlig förhandsversion av integrationsassistenten i Microsoft Entra-appregistreringar.

  • Integration Assistant analyserar din appregistrering och jämför den med en uppsättning rekommenderade rekommenderade säkerhetsmetoder.
  • Integrationsassistenten visar bästa praxis som är relevanta under varje fas i integreringens livscykel – från utveckling hela vägen till övervakning – och säkerställer att varje steg är korrekt konfigurerat.
  • Det gör ditt jobb enklare, oavsett om du integrerar din första app eller om du är expert på att förbättra dina kunskaper.

Utbilda din organisation om medgivandetaktik (nätfisketaktik, administratörs- och användarmedgivanden ):

  • Sök efter dålig stavning och grammatik. Om ett e-postmeddelande eller programmets medgivandeskärm har stavnings- och grammatiska fel är det sannolikt ett misstänkt program.
  • Håll ett vakande öga på appnamn och domän-URL:er. Angripare gillar att förfalska appnamn som gör att det verkar komma från legitima program eller företag men driver dig att samtycka till en skadlig app.
  • Se till att du känner igen appens namn och domän-URL innan du godkänner ett program.

Höja upp och tillåta åtkomst till appar som du litar på

  • Främja användningen av program som har verifierats av utgivare. Verifiering av utgivare hjälper administratörer och slutanvändare att förstå programutvecklares äkthet. Över 660 program av 390 utgivare har verifierats hittills.
  • Konfigurera principer för programmedgivande genom att tillåta användare att endast samtycka till specifika program som du litar på, till exempel program som utvecklats av din organisation eller från verifierade utgivare.
  • Utbilda din organisation om hur vårt ramverk för behörigheter och medgivande fungerar.
  • Förstå de data och behörigheter som ett program ber om och förstår hur behörigheter och medgivande fungerar på vår plattform.
  • Se till att administratörerna vet hur de hanterar och utvärderar begäranden om medgivande.

Granska appar och medgivandebehörigheter i din organisation för att säkerställa att program som används endast har åtkomst till de data de behöver och följer principerna om lägsta behörighet.

Åtgärder

  • Utbilda kunden och ge medvetenhet och utbildning om att skydda bidrag för programmedgivande
  • Skärpa processen för beviljande av programmedgivande med organisationsprinciper och tekniska kontroller
  • Konfigurera Skapa schema för att granska medgivandeprogram
  • Du kan använda PowerShell för att inaktivera misstänkta eller skadliga appar genom att inaktivera appen

Referenser

Källan till innehållet för den här artikeln är följande:

Ytterligare spelböcker för incidenthantering

Granska vägledningen för att identifiera och undersöka dessa ytterligare typer av attacker:

Incidenthanteringsresurser