Sdílet prostřednictvím

Šetření udělení souhlasu s aplikací

  • Článek

Tento článek obsahuje pokyny k identifikaci a zkoumání útoků na vyjádření souhlasu aplikace, ochraně informací a minimalizaci dalších rizik.

Tento článek obsahuje následující části:

  • Požadavky: Řeší konkrétní požadavky, které je potřeba dokončit před zahájením šetření. Protokolování, které by mělo být zapnuté, role a oprávnění se vyžadují mimo jiné.
  • Pracovní postup: Zobrazuje logický tok, podle kterého byste měli provést toto šetření.
  • Kontrolní seznam: Obsahuje seznam úkolů pro každý z kroků v vývojovém diagramu. Tento kontrolní seznam může být užitečný v vysoce regulovaných prostředích k ověření provedených kroků nebo jednoduše jako brána kvality pro sebe.
  • Kroky šetření: Obsahuje podrobné pokyny pro toto konkrétní šetření.
  • Obnovení: Obsahuje základní kroky, jak obnovit nebo zmírnit útoky na udělení souhlasu s neoprávněným aplikacím.
  • Odkazy: Obsahuje další materiály pro čtení a referenční materiály.

Požadavky

Tady jsou obecná nastavení a konfigurace, které byste měli dokončit při vyšetřování udělení souhlasu aplikace. Před zahájením šetření se ujistěte, že si přečtěte o typech oprávnění souhlasu vysvětlených v typech oprávnění souhlasu.

Data zákazníka

Pokud chcete zahájit proces šetření, potřebujete následující data:

  • Podrobnosti ukazatelů ohrožení zabezpečení (IoCS)
  • Datum a čas, kdy jste si všimli incidentu
  • Rozsah kalendářních dat
  • Počet ohrožených účtů
  • Název ohrožených účtů
  • Role ohroženého účtu
  • Jsou účty vysoce privilegované (GA Microsoft Exchange, SharePoint)?
  • Souvisí s incidentem nějaká podniková aplikace?
  • Nahlásili uživatelé nějaké aplikace, které požadovaly oprávnění k datům jejich jménem?

Systémové požadavky

Ujistěte se, že splňujete následující požadavky na instalaci a konfiguraci:

  • Nainstaluje se modul AzureAD PowerShell.
  • Máte oprávnění globálního správce tenanta, pro kterého se skript spouští.
  • Máte přiřazenou roli místního správce v počítači, který používáte ke spuštění skriptů.

Poznámka:

Moduly Azure AD a MSOnline PowerShell jsou od 30. března 2024 zastaralé. Další informace najdete v aktualizaci vyřazení. Po tomto datu je podpora těchto modulů omezená na pomoc s migrací na sadu Microsoft Graph PowerShell SDK a opravy zabezpečení. Zastaralé moduly budou dál fungovat až do 30. března 2025.

Doporučujeme migrovat na Microsoft Graph PowerShell , abyste mohli pracovat s Microsoft Entra ID (dříve Azure AD). Běžné dotazy k migraci najdete v nejčastějších dotazech k migraci. Poznámka: Verze 1.0.x msOnline mohou dojít k přerušení po 30. červnu 2024.

Instalace modulu AzureAD

Pomocí tohoto příkazu nainstalujte modul AzureAD.

Install-Module -Name AzureAD -Verbose

Poznámka:

Pokud se zobrazí výzva k instalaci modulů z nedůvěryhodného úložiště, zadejte Y a stiskněte Enter.

Instalace modulu MSOnline PowerShellu

  1. Spusťte aplikaci Windows PowerShell se zvýšenými oprávněními (spusťte ho jako správce).

  2. Spuštěním tohoto příkazu povolte PowerShellu spouštění podepsaných skriptů.

    Set-ExecutionPolicy RemoteSigned

  3. Pomocí tohoto příkazu nainstalujte modul MSOnline.

    Install-Module -Name MSOnline -Verbose

    Poznámka:

    Pokud se zobrazí výzva k instalaci modulů z nedůvěryhodného úložiště, zadejte Y a stiskněte Enter.

Stažení skriptu AzureADPSPermissions z GitHubu

  1. Stáhněte si skript Get-AzureADPSPermissions.ps1 z GitHubu do složky, ze které skript spustíte. Výstupní soubor "permissions.csv" je také zapsán do této stejné složky.

  2. Otevřete instanci PowerShellu jako správce a otevřete složku, do které jste skript uložili.

  3. Připojte se k adresáři pomocí rutiny Connect-AzureAD . Následuje příklad.

    Connect-AzureAD -tenantid "aaaabbbb-0000-cccc-1111-dddd2222eeee" -AccountId "user1@contoso.onmicrosoft.com"

  4. Spusťte tento příkaz PowerShellu.

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

    Odpojte relaci AzureAD pomocí tohoto příkazu.

    Disconnect-AzureAD

Souhlas je proces udělení autorizace aplikaci pro přístup k chráněným prostředkům jménem uživatele. Správce nebo uživatel může být požádán o souhlas s povolením přístupu k jejich organizaci nebo individuálním datům.

Aplikace má udělený přístup k datům na základě konkrétního uživatele nebo celé organizace. Útočníci můžou tyto souhlasy zneužít, aby získali trvalost prostředí a přistupovali k citlivým datům. Tyto typy útoků se označují jako neoprávněné udělení souhlasu, ke kterému může dojít prostřednictvím phishingového e-mailu, ohrožení uživatelského účtu prostřednictvím útoku password spray nebo když útočník zaregistruje aplikaci jako legitimního uživatele. Ve scénářích, kdy dojde k ohrožení zabezpečení účtu správce, se registrace a udělení souhlasu vztahují pro celého tenanta, a ne jenom pro jednoho uživatele.

Aby mohla aplikace získat přístup k datům vaší organizace, musí jí k tomu uživatel udělit oprávnění. Různá oprávnění umožňují různé úrovně přístupu. Ve výchozím nastavení můžou všichni uživatelé udělit aplikacím souhlas s oprávněními, která nevyžadují souhlas správce. Ve výchozím nastavení může uživatel například udělit souhlas s povolením přístupu aplikace ke své poštovní schránce, ale nemůže udělit souhlas s povolením nefetterovaného přístupu aplikace ke čtení a zápisu do všech souborů ve vaší organizaci.

Poznámka:

Díky tomu, že uživatelům umožníte udělit aplikacím přístup k datům, můžou uživatelé snadno získat užitečné aplikace a být produktivní. V některých situacích ale tato konfigurace může představovat riziko, pokud není monitorovaná a řízená pečlivě.

Abyste mohli udělit souhlas správce v rámci celého tenanta, musíte se přihlásit alespoň jednou z následujících rolí:

  • Správce aplikace
  • Správce cloudové aplikace
  • Správce – označuje, že souhlas poskytl správce (jménem organizace).
  • Individuální uživatel – označuje, že uživatel udělil souhlas a má přístup pouze k informacím daného uživatele.
  • Přijaté hodnoty
    • AllPrincipals – odsouhlasený správcem pro celý tenant
    • Objekt zabezpečení – odsouhlasený individuálním uživatelem pouze pro data související s tímto účtem

Skutečné uživatelské prostředí udělení souhlasu se liší v závislosti na zásadách nastavených v tenantovi uživatele, rozsahu autority (nebo role) uživatele a typu oprávnění požadovaných klientskou aplikací. To znamená, že vývojáři aplikací a správci tenantů mají určitou kontrolu nad prostředím souhlasu. Správci mají flexibilitu nastavení a deaktivace zásad v tenantovi nebo aplikaci, aby mohli řídit prostředí souhlasu ve svém tenantovi. Vývojáři aplikací můžou určovat, jaké typy oprávnění jsou požadovány, a pokud chtějí uživatele vést tokem souhlasu uživatele nebo tokem souhlasu správce.

  • Tok souhlasu uživatele – Když vývojář aplikace nasměruje uživatele na koncový bod autorizace se záměrem zaznamenat souhlas pouze pro aktuálního uživatele.

  • Tok souhlasu správce – Když vývojář aplikace nasměruje uživatele na koncový bod souhlasu správce se záměrem zaznamenat souhlas pro celého tenanta. Aby tok souhlasu správce fungoval správně, musí vývojáři aplikací v manifestu aplikace vypsat všechna oprávnění ve vlastnosti RequiredResourceAccess .

Delegovaná oprávnění vs. oprávnění aplikace

Delegovaná oprávnění používají aplikace, které mají přihlášeného uživatele a mohou mít souhlasy, které použil správce nebo uživatel.

Oprávnění aplikace používají aplikace, ve kterých není přihlášený uživatel. Příkladem jsou aplikace, které běží jako služby na pozadí nebo procesy démon. Oprávnění aplikace může udělit souhlas pouze správce.

Další informace naleznete v tématu:

Klasifikace rizikových oprávnění

V systému jsou tisíce (alespoň) oprávnění a není možné je vypsat nebo analyzovat. Následující seznam se zabývá běžně zneužitím oprávnění a dalšími uživateli, kteří by v případě zneužití vytvořili katastrofický dopad.

Na vysoké úrovni microsoft zaznamenal následující delegovaná oprávnění root (App+User), která se zneužívají při útokech phishing s souhlasem. Kořen se rovná nejvyšší úrovni. Například Kontakty.* znamená zahrnout všechny delegovaná permutace oprávnění Kontakty: Contacts.Read, Contacts.ReadWrite, Contacts.Read.Shared a Contacts.ReadWrite.Shared.

  1. Mail.* (včetně mail.Send*, ale ne Mail.ReadBasic*)
  2. Kontakty. *
  3. MailboxSettings.*
  4. Lid.*
  5. Soubory.*
  6. Poznámky.*
  7. Directory.AccessAsUser.All
  8. User_Impersonation

První sedm oprávnění v předchozím seznamu jsou určená pro Microsoft Graph a starší ekvivalenty rozhraní API, jako je Azure Active Directory (Azure AD) Graph a Outlook REST. Osmé oprávnění je pro Azure Resource Manager (ARM) a také může být nebezpečné pro jakékoli rozhraní API, které zveřejňuje citlivá data s tímto rozsahem zosobnění.

Na základě pozorování týmu reakce na incidenty Microsoftu útočníci používají kombinaci prvních šesti oprávnění v 99 % útoků phishing s souhlasem. Většina lidí nemyslí na delegovanou verzi Mail.Read nebo Files.Read jako vysoce rizikové oprávnění, ale útoky jsou obecně rozšířené a cílí na koncové uživatele, a ne spear phishing proti správcům, kteří mohou skutečně souhlasit s nebezpečnými oprávněními. Doporučujeme používat bublinové aplikace s těmito "kritickou" úrovní oprávnění dopadu. I když aplikace nemají škodlivý záměr a pokud by špatný aktér mohl ohrozit identitu aplikace, může být ohrožená celá vaše organizace.

Pro oprávnění s nejvyšším dopadem na riziko začněte tady:

  • Verze oprávnění aplikace (AppOnly/AppRole) všech výše uvedených oprávnění, pokud je to možné

Delegovaná verze a verze AppOnly následujících oprávnění:

  • 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
  • Všechna ostatní oprávnění AppOnly, která umožňují přístup k zápisu

Seznam oprávnění s nejnižším dopadem na rizika začněte tady:

  • User.Read
  • User.ReadBasic.All
  • Open_id
  • Poslat e-mail
  • Profil
  • Offline_access (pouze pokud je spárováno s dalšími oprávněními v tomto seznamu nejnižších rizik)

Zobrazení oprávnění

  1. Pokud chcete zobrazit oprávnění, přejděte v podnikové aplikaci na obrazovku Registrace .

    Snímek obrazovky znázorňuje, jak zobrazit různá oprávnění

  2. Vyberte Zobrazit oprávnění rozhraní API.

    Snímek obrazovky znázorňuje, jak zobrazit a přidat oprávnění rozhraní API

  3. Vyberte Přidat oprávnění a zobrazí se následující obrazovka.

    Snímek obrazovky s požadavkem na oprávnění rozhraní API

  4. Výběrem Microsoft Graphu zobrazíte různé typy oprávnění.

    Snímek obrazovky s různými typy oprávnění rozhraní API

  5. Vyberte typ oprávnění, která zaregistrovaná aplikace používá: Delegovaná oprávnění nebo oprávnění aplikace. Na obrázku výše je vybrána oprávnění aplikace.

  6. Můžete vyhledat jedno z vysoce rizikových oprávnění, jako je EduRoster.

    Snímek obrazovky s ukázkovým požadavkem na oprávnění rozhraní API

  7. Vyberte EduRoster a rozbalte oprávnění.

    Snímek obrazovky s položkou oprávnění rozhraní API s popisem

  8. Teď můžete tato oprávnění přiřadit nebo zkontrolovat.

    Další informace najdete v tématu Oprávnění graphu.

Workflow

[Vývojový diagram pracovního postupu udělení souhlasu aplikace]

Můžete také:

  • Stáhněte si pracovní postupy pro udělení souhlasu aplikace a další pracovní postupy playbooku reakce na incidenty jako PDF.
  • Stáhněte si pracovní postupy udělení souhlasu aplikace a další pracovní postupy playbooku reakce na incidenty jako soubor Visia.

Kontrolní seznam

Pomocí tohoto kontrolního seznamu můžete provést ověření udělení souhlasu aplikace.

  • Indikátory ohrožení zabezpečení (IoC)

    Zkontrolujte následující indikátory ohrožení zabezpečení (IoC):

    • Kdy jste si všimli incidentu?
    • Rozsah dat incidentu (jak daleko je cíl post?)
    • Počet ohrožených účtů
    • Názvy ohrožených účtů
    • Role ohrožených účtů
    • Jsou ohrožené účty vysoce privilegované, standardní uživatel nebo kombinace.

  • Role

    Musíte být přiřazeni těmito rolemi:

    • Role místního správce v počítači, ze kterého skript spouštíte

  • Konfigurace PowerShell

    Nakonfigurujte prostředí PowerShellu pomocí těchto kroků:

    1. Nainstalujte modul Azure AD PowerShell.
    2. Spusťte aplikaci Windows PowerShell se zvýšenými oprávněními. (Spustit jako správce).
    3. Nakonfigurujte PowerShell pro spouštění podepsaných skriptů.
    4. Stáhněte si skript Get-AzureADPSPermissions.ps1.

  • Triggery šetření

    • Ohrožení zabezpečení účtu
    • Nastavení souhlasu aplikace změněné v tenantovi
    • Zjistil se důvod stavu události výstrahy nebo auditu "riziková aplikace".
    • Všimli jsme si lichých aplikací

Jako excelový soubor si také můžete stáhnout kontrolní seznamy k udělení souhlasu s aplikací a další kontrolní seznamy playbooků incidentů.

Postup prověřování

K prozkoumání udělení souhlasu s aplikací můžete použít následující dvě metody:

  • portál Azure
  • Skript PowerShellu

Poznámka:

Použití webu Azure Portal umožňuje zobrazit jenom udělení souhlasu správce za posledních 90 dnů a na základě toho doporučujeme použít metodu skriptu PowerShellu pouze k omezení kroků pro šetření útočníka.

Metoda 1 – Použití webu Azure Portal

Centrum pro správu Microsoft Entra můžete použít k vyhledání aplikací, které jednotliví uživatelé udělili oprávnění.

  1. Přihlaste se k Azure Portal jako správce.
  2. Vyberte ikonu Microsoft Entra ID.
  3. Vyberte položku Uživatelé.
  4. Vyberte uživatele, kterého chcete zkontrolovat.
  5. Vyberte Přihlášky.
  6. Zobrazí se seznam aplikací, které jsou přiřazené uživateli a jaká oprávnění tyto aplikace mají.

Metoda 2 – Použití PowerShellu

Existuje několik nástrojů PowerShellu, které můžete použít k prošetření neoprávněných udělení souhlasu, například:

PowerShell je nejjednodušší nástroj, který nevyžaduje, abyste nic v tenantovi upravili. Budeme založit vyšetřování na veřejné dokumentaci z neoprávněného útoku grantu souhlasu.

Spuštěním příkazu Get-AzureADPSPermissions.ps1vyexportujte všechny souhlasy OAuth a aplikace OAuth pro všechny uživatele ve vaší tenantské architektuce do souboru .csv . Informace o stažení a spuštění Get-AzureADPSPermissions skriptu najdete v části Požadavky.

  1. Otevřete instanci PowerShellu jako správce a otevřete složku, do které jste skript uložili.

  2. Připojte se k adresáři pomocí následujícího příkazu Connect-AzureAD . Následuje příklad.

    Connect-AzureAD -tenantid "aaaabbbb-0000-cccc-1111-dddd2222eeee" -AccountId "user1@contoso.onmicrosoft.com"

  3. Spusťte tento příkaz PowerShellu.

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

  4. Po dokončení skriptu se doporučuje odpojit relaci Microsoft Entra tímto příkazem.

     Disconnect-AzureAD

    Poznámka:

    Dokončení skriptu může trvat hodiny v závislosti na velikosti a oprávněních nakonfigurovaných i připojení.

  5. Skript vytvoří soubor s názvem Permissions.csv.

  6. Otevřete soubor a pak data vyfiltrujte nebo naformátujte do tabulky a uložte ho .xlxs jako soubor.

    Záhlaví sloupců pro výstup se zobrazí na tomto obrázku.

    Snímek obrazovky se záhlavími excelových sloupců

  7. Ve sloupci ConsentType (G) vyhledejte hodnotu AllPrinciples. Oprávnění AllPrincipals umožňuje klientské aplikaci přístup k obsahu všech klientů v tenantovi. Nativní aplikace Microsoftu 365 potřebují toto oprávnění, aby fungovaly správně. Všechny aplikace jiné společnosti než Microsoft s tímto oprávněním by se měly pečlivě kontrolovat.

  8. Ve sloupci Oprávnění (F) zkontrolujte oprávnění, která má každá delegovaná aplikace. Vyhledejte oprávnění ke čtení a zápisu nebo *. Všechna oprávnění a pečlivě zkontrolujte tato oprávnění, protože nemusí být vhodná. Snímek obrazovky s oprávněními aplikace ve sloupci F

    Poznámka:

    Zkontrolujte konkrétní uživatele, kteří mají udělené souhlasy. Pokud mají uživatelé s vysokým profilem nebo vysokým dopadem udělené nevhodné souhlasy, měli byste prozkoumat další šetření.

  9. Ve sloupci ClientDisplayName (C) vyhledejte aplikace, které vypadají podezřele, například:

    • Aplikace s chybně napsanými názvy Snímek obrazovky s příkladem chybně napsaného názvu

    • Neobvyklé názvy nebo názvy názvových hran Snímek obrazovky s příkladem neobvyklého názvu

    • Hacker-zní jména. Tyto názvy je nutné pečlivě zkontrolovat. Snímek obrazovky s příkladem názvu hackera

Příklad výstupu: AllPrincipals a read write all. Aplikace nemusí mít nic podezřelého, jako jsou názvy výchozích, a používají ms graph. Proveďte ale průzkum a určete účel aplikací a skutečná oprávnění, která aplikace mají v tenantovi, jak je znázorněno v tomto příkladu.

Snímek obrazovky s příkladem aplikací s typem ConsentType AllPrincipals

Tady je několik užitečných tipů ke kontrole šetření zásad zabezpečení informací (ISP):

  • ReplyURL/RedirectURL
    • Vyhledání podezřelých adres URL
  • Je adresa URL hostovaná v podezřelé doméně?
    • Je to ohrožené?
    • Je doména nedávno zaregistrovaná?
    • Jedná se o dočasnou doménu?
  • Existují v registraci aplikace odkaz na podmínky smlouvy o službách nebo službách?
  • Jsou obsah jedinečný a specifický pro aplikaci nebo vydavatele?
  • Je tenant, který aplikaci zaregistroval buď nově vytvořenou, nebo ohroženou (například je aplikace zaregistrovaná rizikovým uživatelem)?

Techniky útoku

I když se každý útok obvykle liší, základní techniky útoku jsou:

  • Útočník zaregistruje aplikaci u poskytovatele OAuth 2.0, například ID Microsoft Entra.

  • Aplikace se konfigurují tak, aby vypadaly jako legitimní. Útočníci můžou například použít název oblíbeného produktu dostupného ve stejném ekosystému.

  • Útočník získá odkaz přímo od uživatelů, které se můžou provádět prostřednictvím konvenčního útoku phishing založeného na e-mailu, a to ohrožením nemalického webu nebo jinými technikami.

  • Uživatel vybere odkaz a zobrazí se ověřovací výzva k vyjádření souhlasu s žádostí o udělení oprávnění k datům škodlivé aplikace.

  • Pokud uživatel vybere možnost Přijmout, udělí aplikaci oprávnění pro přístup k citlivým datům.

  • Aplikace získá autorizační kód, který uplatní pro přístupový token a potenciálně obnovovací token.

  • Přístupový token se používá k volání rozhraní API jménem uživatele.

  • Pokud uživatel přijme přístup, může útočník získat přístup k e-mailům uživatele, pravidlům předávání, souborům, kontaktům, poznámkám, profilu a dalším citlivým datům a prostředkům.

    Snímek obrazovky s příkladem žádosti o oprávnění

Nalezení známek útoku

  1. Na portálu Microsoft 365 Defender na adrese https://security.microsoft.compřejděte na Audit. Nebo přejděte přímo na stránku Audit , použijte https://security.microsoft.com/auditlogsearch.

  2. Na stránce Audit vyhledejte všechny aktivity a všechny uživatele, v případě potřeby zadejte počáteční a koncové datum a pak vyberte Hledat.

    Snímek obrazovky s příkladem prohledávání protokolu auditování

  3. Vyberte Filtr výsledků a v poli Aktivita zadejte souhlas s aplikací.

    Snímek obrazovky s příkladem filtrování prohledávání protokolu auditování

  4. Pokud máte v rámci souhlasu s udělením aktivity, pokračujte dalším krokem.

  5. Výběrem výsledku zobrazíte podrobnosti o aktivitě. Výběrem možnosti Další informace získáte podrobnosti o aktivitě.

  6. Zkontrolujte, jestli je vlastnost IsAdminContent nastavená na Hodnotu True.

    Poznámka:

    Tento proces může trvat až 30 minut až 24 hodin, než se odpovídající položka protokolu auditu zobrazí ve výsledcích hledání po výskytu události.

    Rozsah doby, po kterou se záznam auditu uchovává a je prohledávatelný v protokolu auditu, závisí na vašem předplatném Microsoftu 365 a konkrétně na typu licence, která je přiřazená konkrétnímu uživateli. Pokud je tato hodnota pravdivá, znamená to, že někdo mohl udělit široký přístup k datům. Pokud je to neočekávané, proveďte okamžité kroky k potvrzení útoku.

Jak potvrdit útok?

Pokud máte jednu nebo více instancí dříve uvedených ioC, musíte provést další šetření, abyste kladně potvrdili, že k útoku došlo.

Inventarizace aplikací s přístupem ve vaší organizaci

Aplikace můžete inventarizovat pro své uživatele pomocí Centra pro správu Microsoft Entra, PowerShellu nebo můžete své uživatele jednotlivě vytvořit výčet přístupu k aplikacím.

  • K inventarizaci aplikací a jejich oprávnění použijte Centrum pro správu Microsoft Entra. Tato metoda je důkladná, ale můžete zkontrolovat pouze jednoho uživatele najednou, což může být časově náročné, pokud potřebujete zkontrolovat oprávnění několika uživatelů.
  • Pomocí PowerShellu můžete inventarizovat aplikace a jejich oprávnění. Tato metoda je nejrychlejší a nejpodrobnější, s nejmenší režií.
  • Povzbuďte uživatele, aby jednotlivě zkontrolovali své aplikace a oprávnění a nahlásili výsledky zpět správcům pro nápravu.

Inventarizační aplikace přiřazené uživatelům

Pomocí Centra pro správu Microsoft Entra můžete zobrazit seznam aplikací, kterým jednotliví uživatelé udělili oprávnění.

  1. Přihlaste se k webu Azure Portal s právy správce.
  2. Vyberte ikonu Microsoft Entra ID.
  3. Vyberte položku Uživatelé.
  4. Vyberte uživatele, kterého chcete zkontrolovat.
  5. Vyberte Přihlášky.

Zobrazí se seznam aplikací přiřazených uživateli a oprávnění udělená těmto aplikacím.

Určení rozsahu útoku

Po dokončení inventarizace přístupu k aplikaci zkontrolujte protokol auditu a určete úplný rozsah porušení zabezpečení. Vyhledejte ovlivněné uživatele, časové rámce, které měla neoprávněná aplikace přístup k vaší organizaci, a oprávnění, která aplikace měla. Protokol auditu můžete prohledávat v Portál dodržování předpisů Microsoft Purview zabezpečení Microsoftu 365.

Důležité

Pokud se auditování nepovolilo před možným útokem, nebudete moct prozkoumat, protože data auditování nejsou dostupná.

Jak zabránit útokům a zmírnit rizika?

Pokud má vaše organizace příslušnou licenci:

  • Používejte více funkcí auditování aplikací OAuth v Programu Microsoft Defender for Cloud Apps.
  • Pomocí sešitů Azure Monitoru můžete monitorovat oprávnění a aktivitu související se souhlasem. Sešit Přehledy souhlasu poskytuje zobrazení aplikací podle počtu neúspěšných žádostí o souhlas. To může být užitečné při určování priorit aplikací pro správce, aby mohli kontrolovat a rozhodnout, jestli jim udělíte souhlas správce.

Po identifikaci aplikace s neoprávněnými oprávněními okamžitě zakažte aplikaci podle pokynů v části Zakázat aplikaci. Pak kontaktujte podpora Microsoftu a nahlašte škodlivou aplikaci.

Jakmile je aplikace zakázaná v Microsoft Entra, nemůže získat nové tokeny pro přístup k datům a ostatní uživatelé se nemůžou přihlásit ani udělit souhlas s aplikací.

Poznámka:

Pokud máte podezření, že jste ve vaší organizaci narazili na škodlivou aplikaci, je lepší ji zakázat, než ji odstranit. Pokud aplikaci odstraníte, může se později vrátit, pokud jiný uživatel udělí souhlas. Místo toho zakažte aplikaci, abyste se ujistili, že se později nemůže vrátit.

Postup ochrany organizace

Existují různé typy útoků na vyjádření souhlasu. Tato doporučená obrana zmírní všechny typy útoků, zejména útok phishing souhlasu, kdy útočníci ošidí uživatele, aby udělili škodlivé aplikaci přístup k citlivým datům nebo jiným prostředkům. Místo pokusu o krádež hesla uživatele hledá útočník oprávnění pro aplikaci řízenou útočníkem pro přístup k cenným datům.

Pokud chcete zabránit útokům na vyjádření souhlasu, aby ovlivnily ID Microsoft Entra a Office 365, podívejte se na následující doporučení:

Nastavení zásad

  • Toto nastavení má vliv na uživatele a nemusí být použitelné pro prostředí. Pokud povolíte jakékoli souhlasy, ujistěte se, že správci žádosti schválí.

  • Povolení souhlasů pro aplikace od ověřených vydavatelů a konkrétních typů oprávnění klasifikovaných jako nízký dopad

    Poznámka:

    Výše uvedená doporučení se navrhují na základě nejvhodnějších a nejbezpečnějších konfigurací. Vzhledem k tomu, že zabezpečení je jemné vyvážení mezi funkcemi a operacemi, nejbezpečnější konfigurace můžou správcům způsobit větší režii. Je to rozhodnutí, které je nejlepší udělat po konzultaci se správci.

    Konfigurace souhlasu s krokem založeným na riziku – Povoleno ve výchozím nastavení, pokud je povolený souhlas uživatele s udělením

  • Souhlas založený na rizikových krocích pomáhá snížit riziko ohrožení uživatelů škodlivých aplikací, které dělají neoprávněné žádosti o souhlas. Pokud Microsoft zjistí rizikovou žádost o souhlas koncového uživatele, vyžaduje žádost místo toho "krok nahoru" k vyjádření souhlasu správce. Tato funkce je ve výchozím nastavení povolená, ale výsledkem je změna chování pouze při povolení souhlasu koncového uživatele.

  • Po zjištění rizikové žádosti o souhlas se zobrazí výzva k vyjádření souhlasu se zprávou, že je potřeba schválení správcem. Pokud je pracovní postup žádosti o souhlas správce povolený, může uživatel odeslat žádost správci, aby ji mohl dále zkontrolovat přímo z výzvy k vyjádření souhlasu. Pokud je tato možnost povolená, zobrazí se následující zpráva:

    AADSTS90094: <clientAppDisplayName> potřebuje oprávnění pro přístup k prostředkům ve vaší organizaci, které může udělit jenom správce. Než ji budete moct používat, požádejte správce, aby udělil oprávnění této aplikaci. V tomto případě se událost auditu zaprotokoluje také s typem aktivity "ApplicationManagement" typu "Souhlas s aplikací" a důvod stavu "Zjištěna riziková aplikace".

Poznámka:

Všechny úlohy, které vyžadují schválení správcem, mají provozní režii. Nastavení souhlasu a souhlasu uživatele je aktuálně ve verzi Preview. Jakmile je tato funkce připravená na obecnou dostupnost (GA), měla by funkce Povolit souhlas uživatele od ověřených vydavatelů snížit režijní náklady správců a doporučuje se pro většinu organizací.

Snímek obrazovky s příkladem oprávnění souhlasu

Informujte vývojáře aplikací, aby sledovali důvěryhodný ekosystém aplikací. Abychom vývojářům pomohli vytvářet vysoce kvalitní a zabezpečené integrace, oznamujeme také verzi Public Preview pomocníka pro integraci v registracích aplikací Microsoft Entra.

  • Pomocník s integrací analyzuje registraci aplikace a testuje ji podle sady doporučených osvědčených postupů zabezpečení.
  • Pomocník s integrací zvýrazňuje osvědčené postupy, které jsou relevantní během každé fáze životního cyklu vaší integrace – od vývoje až po monitorování – a zajišťuje správnou konfiguraci každé fáze.
  • Usnadňuje práci bez ohledu na to, jestli integrujete svou první aplikaci, nebo jste odborník, který se snaží zlepšit své dovednosti.

Informujte svou organizaci o taktikách souhlasu (phishingová taktika, souhlas správce a uživatele):

  • Zkontrolujte špatnou kontrolu pravopisu a gramatiky. Pokud e-mailová zpráva nebo obrazovka souhlasu aplikace obsahuje pravopisné a gramatické chyby, pravděpodobně se jedná o podezřelou aplikaci.
  • Sledujte názvy aplikací a adresy URL domén. Útočníci chtějí falšovat názvy aplikací, které zdají, že pocházejí z legitimních aplikací nebo společností, ale umožňují vám souhlas se zlými úmysly.
  • Před vyjádřením souhlasu s aplikací nezapomeňte rozpoznat název aplikace a adresu URL domény.

Zvýšení úrovně a povolení přístupu k aplikacím, kterým důvěřujete

  • Zvýšení úrovně používání aplikací ověřených vydavatelem Ověření vydavatele pomáhá správcům a koncovým uživatelům pochopit pravost vývojářů aplikací. Doposud bylo ověřeno více než 660 aplikací od 390 vydavatelů.
  • Nakonfigurujte zásady souhlasu aplikací tím, že uživatelům umožníte pouze souhlas s konkrétními aplikacemi, kterým důvěřujete, například aplikacím vyvinutým vaší organizací nebo ověřeným vydavatelům.
  • Informujte svou organizaci o tom, jak naše oprávnění a architektura souhlasu funguje.
  • Seznamte se s daty a oprávněními, o které aplikace žádá, a zjistěte, jak fungují oprávnění a souhlas v rámci naší platformy.
  • Zajistěte, aby správci věděli, jak spravovat a vyhodnocovat žádosti o souhlas.

Auditujte aplikace a udělená oprávnění ve vaší organizaci, abyste zajistili, že aplikace, které používají, přistupují jenom k datům, která potřebují, a dodržují zásady nejnižších oprávnění.

Omezení rizik

  • Informujte zákazníka a poskytněte povědomí a školení o zabezpečení udělení souhlasu s aplikacemi.
  • Upřísnění procesu udělování souhlasu s aplikací pomocí zásad organizace a technických kontrol
  • Nastavení plánu vytvoření pro kontrolu odsouhlasených aplikací
  • Pomocí PowerShellu můžete zakázat podezřelé nebo škodlivé aplikace zakázáním aplikace.

Související obsah

Další playbooky reakce na incidenty

Projděte si pokyny k identifikaci a prošetřování těchto dalších typů útoků:

Zdroje informací o reakcích na incidenty