Undersökning av beviljande av appmedgivande

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:

  • Förutsättningar: Omfattar de specifika krav som du måste uppfylla 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 kontrollera vad du har gjort 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.
  • Återhämtning: Innehåller övergripande steg för hur du återställer/åtgärdar från en attack med beviljande av otillåtet programmedgivande.
  • Referenser: Innehåller ytterligare läs- och referensmaterial.

Förkunskapskrav

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 kontrollerar du att du har läst om de typer av medgivandebehörigheter som förklaras i Behörighetstyper för medgivande.

Kundinformation

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

  • Åtkomst till klientorganisationen som en global Admin – ett konto endast för molnet (inte en del av deras lokala miljö)
  • Information om indikatorer för kompromiss (IoCs)
  • Datum och tid då du märkte incidenten
  • Datumintervall
  • Antal komprometterade konton
  • Namn på komprometterade konton
  • Roller för det komprometterade kontot
  • Är kontona högprivilegierade (GA Microsoft Exchange, SharePoint)?
  • Finns det några företagsprogram som är relaterade till incidenten?
  • Har några användare rapportera om alla program som begärde 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 ska köras mot.
  3. Du har tilldelats en lokal administratörsroll på den dator som du ska använda för att köra skripten.

Installera AzureAD-modulen

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

Install-Module -Name AzureAD -Verbose

Anteckning

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 skriptetGet-AzureADPSPermissions.ps1 från GitHub till en mapp där du ska köra skriptet. 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 cmdleten Connect-AzureAD . Här är 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 bli ombedd 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. Dessa medgivanden kan dock missbrukas av angripare för att få beständighet i miljön och få åtkomst till känsliga data. Dessa typer av attacker kallas otillåtna medgivandebidrag, som 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 Admin-konto 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. Som standard kan en användare till exempel samtycka till att tillåta att en app får åtkomst till sin postlåda, men kan inte godkänna att en app utan ohämmad åtkomst kan läsa och skriva till alla filer i din organisation.

Anteckning

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
  • Programadministratör
  • Molnprogramadministratö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 den användarens information
  • Godkända värden
    • AllPrincipals - Godkänt av en administratör för hela innehavet
    • Principal – Samtyckt av den enskilda användaren för data som endast är relaterade till det kontot

Den faktiska användarupplevelsen av att bevilja medgivande varierar beroende på de principer som angetts för användarens klientorganisation, användarens behörighetsomfång (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 styra medgivandeupplevelsen i klientorganisationen. Programutvecklare kan bestämma vilka typer av behörigheter som begärs och om de vill vägleda användarna 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 avsikt att registrera medgivande endast för den aktuella användaren.

  • Admin medgivandeflöde – 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 flödet för administratörsmedgivande fungerar korrekt måste programutvecklare lista 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 en 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 är inte möjligt att lista ut eller parsa alla dessa. Listan nedan tar upp behörigheter som ofta missbrukas och andra som skulle skapa katastrofala effekter om de missbrukas.

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

  1. Mail.* (inklusive Mail.Send*, men inte Mail.ReadBasic*)
  2. Kontakter. *
  3. MailboxSettings.*
  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.

Enligt vår observation har angripare använt en kombination av de första sex 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 de attacker som vi har sett är vanligtvis omfattande attacker riktade mot slutanvändare, snarare än spear phishing mot administratörer som faktiskt kan samtycka till farliga behörigheter. 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 riskzonen.

Börja här för behörigheter med störst riskpåverkan:

  • 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 över 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 den här listan över "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 väljs Programbehörigheter .

  6. Du kan söka efter någon av behörigheterna för riskpå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 arbetsflöden för beviljande av appmedgivande och andra arbetsflöden för incidenthanteringsspelböcker som en Visio-fil.

Checklista

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

  • Krav

    Kontrollera att du har åtkomst till klientorganisationen som en global Admin. Det här är ett molnbaserat konto och är inte en del av din lokala miljö.

  • Indikatorer på 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 ligger 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ör rättigheter för klientorganisationen att köra skriptet
    • Lokal administratörsroll på den dator där skriptet ska köras
  • PowerShell-konfiguration

    Konfigurera PowerShell-miljön med följande:

    • Installera Azure AD PowerShell-modulen.
    • Kör Windows PowerShell-appen med förhöjd behörighet. (Kör som administratör).
    • Konfigurera PowerShell för att köra signerade skript.
    • Ladda ned skriptetGet-AzureADPSPermissions.ps1 .
  • Undersökningsutlösare

    • Kontointrång
    • Inställningar för appmedgivande som ändrats för klientorganisationen
    • Aviserings-/granskningshändelsestatusorsaken "riskfyllt program" har identifierats
    • Märkta program med udda utseende

Du kan också ladda ned appmedgivandet 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 beviljande av programmedgivande:

  • Azure Portal
  • PowerShell-skript

Anteckning

Med hjälp av Azure Portal kan du bara se Admin medgivandebidrag för de senaste 90 dagarna, och baserat på detta rekommenderar vi att du använder PowerShell-skriptmetoden endast för att minska risken för att angriparen registrerar undersökningssteg.

Metod 1 – Använda Azure Portal

Du kan använda Azure Active Directory-portalen för att hitta program som alla enskilda användare har beviljat behörigheter till.

  1. Logga in på Azure Portal som administratör.
  2. Välj Azure Active Directory-ikonen .
  3. Välj Användare.
  4. Välj den användare som du vill granska.
  5. Välj Program.
  6. Du kan se en lista ö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 innehavet. 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 Krav 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 följande Connect-AzureAD-kommando . Här är 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 har slutförts rekommenderar vi att du kopplar från Azure AD-sessionen med det här kommandot.

     Disconnect-AzureAD
    

    Anteckning

    Skriptet kan ta timmar att slutföra, beroende på storleken och behörigheterna som 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 noggrant eftersom de kanske inte är lämpliga. Exempel på behörighetskolumn F

    Anteckning

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

  9. I kolumnen ClientDisplayName(C) letar du upp 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

    • Hackerljudande namn. Du måste granska dessa namn noggrant. Exempel på ett hackernamn

Exempel på utdata: AllPrincipals och läsa skriva alla. Program kanske inte har något misstänkt som intetsägande namn och använder MS Graph. Utför dock efterforskningar 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 Azure AD.

  • 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 via andra tekniker.

  • Användaren väljer länken och visas en autentiserad medgivandeprompt där de uppmanas 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 Security & Compliance Center.

  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 om du vill se information om aktiviteten. Välj Mer information för att få information om aktiviteten.

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

    Anteckning

    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 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 de IOK:er som anges ovan måste du göra ytterligare undersökningar för att bekräfta att attacken har inträffat.

Inventera appar med åtkomst i din organisation

Du kan inventera appar för dina användare med hjälp av Azure Active Directory-portalen, PowerShell eller låta användarna räkna upp sin programåtkomst individuellt.

  • Använd Azure Active Directory-portalen 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 tilldelade till användare

Du kan använda Azure Active Directory-portalen för att se listan över appar som alla enskilda användare har beviljat behörigheter till.

  1. Logga in på Azure-portalen med administrativa rättigheter.
  2. Välj Azure Active Directory-ikonen .
  3. Välj Användare.
  4. Välj den användare som du vill granska.
  5. Välj Program. Du kan se listan över appar som har tilldelats användaren och de behörigheter som beviljas för 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 för att det olagliga programmet hade åtkomst till din organisation och de behörigheter som appen hade. Du kan söka i granskningsloggen i Säkerhets- och efterlevnadscenter för Microsoft 365.

Viktigt: Om granskning inte aktiverades 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 ytterligare granskningsfunktioner för OAuth-program i Microsoft Defender for Cloud Apps.
  • 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 bestämma om de ska beviljas administratörsmedgivande.

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

När ett program har inaktiverats i din Azure AD 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.

Anteckning

Om du misstänker att du har påträffat 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 ger sitt 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, vilket minimerar alla typer av attacker, särskilt nätfiske med medgivande, 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 app som styrs av en angripare för att få åtkomst till värdefulla data.

Se följande rekommendationer för att förhindra att medgivandeattacker påverkar Azure AD och Office 365:

Ange principer

  • Den här inställningen får användarkonsekvenser och kanske inte gäller för en miljö. Om du ska tillåta 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.

    Anteckning

    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 ytterligare kostnader för administratörer. Det är ett beslut som bäst fattas efter samråd med dina administratörer.

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

  • Riskbaserat step-up-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 den resulterar bara i en beteendeförändring när slutanvändares medgivande är aktiverat.

  • När en begäran om riskabelt 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 inte ä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 använder den. I det här fallet loggas även en granskningshändelse med en kategori av aktivitetstypen "ApplicationManagement"för "Samtycke till program" och statusorsaken till "Riskfyllt program har identifierats".

Anteckning

Alla uppgifter som kräver administratörens godkännande kommer att ha 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 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 Integration Assistant i Azure AD appregistreringar.

  • Integrationsassistenten 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 är utformat för att göra ditt jobb enklare, oavsett om du integrerar din första app eller om du är expert och vill 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 gör att du samtycker till en skadlig app.
  • Se till att du känner igen appnamnet och domän-URL:en 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 utgivaren. Verifiering av utgivare hjälper administratörer och slutanvändare att förstå programutvecklares äkthet. Över 660 program av 390 utgivare har hittills verifierats.
  • Konfigurera principer för programmedgivande genom att tillåta användare att endast godkänna 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 för lägsta behörighet.

Åtgärder

  • Utbilda kunden och ge medvetenhet och utbildning om att skydda bidrag för programmedgivande
  • Strama åt processen för programmedgivande med organisationspolicy 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 i 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