Š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, abyste provedli šetření 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:

  • Přístup k tenantovi jako globální Správa – účet jen pro cloud (nikoli součást místního prostředí)
  • 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ázvy 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 všichni uživatelé sestavu o aplikacích, 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:

  1. Nainstaluje se modul AzureAD PowerShell.
  2. Máte oprávnění globálního správce tenanta, pro kterého se skript spouští.
  3. 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řipojení do adresáře pomocí rutinyConnect-AzureAD. Následuje příklad.

    Connect-AzureAD -tenantid "2b1a14ac-2956-442f-9577-1234567890ab" -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í globálního Správa účtu, 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ě.

Pokud chcete udělit souhlas správce v rámci celého tenanta, musíte se přihlásit jako jeden z následujících způsobů:

  • Globální správce
  • Správce aplikace
  • Správce cloudové aplikace
  • Správa istrator - 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áva 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.

  • Správa tok souhlasu – 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. Poštovní schránka Nastavení.*
  4. Lidé.*
  5. Soubory.*
  6. Poznámky.*
  7. Directory.AccessAsUser.All
  8. User_Impersonation

Prvních sedm oprávnění v seznamu výše 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í si nemyslí na delegovanou verzi Mail.Read nebo Files.Read jako vysoce rizikové oprávnění, ale útoky jsou obecně rozšířené útoky zaměřené na koncové uživatele, nikoli 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 .

    zobrazit oprávnění

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

    apipermissions

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

    api

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

    typy oprávnění

  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.

    příkladpermission

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

    eduroster

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

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

Workflow

[Pracovní postup prošetření 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.

  • Požadavky

    Ujistěte se, že máte přístup k tenantovi jako globální Správa. Jedná se o výhradně cloudový účet, který není součástí vašeho místního prostředí.

  • 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:

    • Oprávnění globálního správce tenanta ke spuštění skriptu
    • Místní role Správa istrator na 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 pouze Správa udělení souhlasu za posledních 90 dnů a na základě toho doporučujeme použít metodu skriptu PowerShellu pouze ke snížení počtu 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 a nevyžaduje, abyste v tenantské tenantě nic změnili. Budeme založit vyšetřování na veřejné dokumentaci z útoku Na nelegální udělení 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řipojení do adresáře pomocí následujícího příkazu Připojení-AzureAD. Následuje příklad.

    Connect-AzureAD -tenantid "2b1a14ac-2956-442f-9577-1234567890ab" -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, vyfiltrujte nebo naformátujte data do tabulky a uložte je jako soubor .xlxs (pro filtrování).

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

    Příklad záhlaví 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á. Příklad sloupce Oprávnění 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 Příklad chybně napsaného názvu

    • Neobvyklé názvy nebo názvy názvových hran Příklad neobvyklého názvu

    • Hacker-zní jména. Tyto názvy je nutné pečlivě zkontrolovat. Příklad 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.

Příklad aplikací s typem ConsentType AllPrincipals

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

  1. ReplyURL/RedirectURL
    • Vyhledání podezřelých adres URL
  2. 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?
  3. Existují v registraci aplikace odkaz na podmínky smlouvy o službách nebo službách?
  4. Jsou obsah jedinečný a specifický pro aplikaci nebo vydavatele?
  5. 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 je nakonfigurovaná tak, aby vypadala 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, tím, že naruší web, který není zlými úmysly, nebo prostřednictvím jiných technik.

  • 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.

    Příklad žádosti o oprávnění

Nalezení známek útoku

  1. Otevřete Centrum zabezpečení a dodržování předpisů.

  2. Přejděte do vyhledávání a vyberte hledání v protokolu auditování.

  3. Vyhledejte (všechny aktivity a všichni uživatelé) a zadejte počáteční a koncové datum (v případě potřeby) a pak vyberte Hledat.

    Příklad prohledávání protokolu auditování

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

    Příklad filtrování prohledávání protokolu auditování

  5. Pokud máte v rámci souhlasu s udělením aktivity, pokračujte podle pokynů níže.

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

  7. Zkontrolujte, jestli je hodnota Is Správa Content 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 s globálním Správa astratorem 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 vstupně-výstupních operací, 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 Centru zabezpečení a dodržování předpisů Microsoftu 365.

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

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

  • Pravidelně auditujte aplikace a udělujte oprávnění ve vaší organizaci, abyste zajistili, že k datům nebyl udělen žádný neoprávněný nebo podezřelý přístup.

  • V Office 365 zkontrolujte, zjistěte a opravte neoprávněné udělení souhlasu, kde najdete další osvědčené postupy a ochranu před podezřelými aplikacemi, které požadují souhlas OAuth.

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 s Přehledy souhlasem 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 ve vašem tenantovi Microsoft Entra zakázaná, nemůže získat nové tokeny pro přístup k datům a ostatní uživatelé se nebudou moct k aplikaci přihlásit ani udělit souhlas.

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, ale pokud postupujete podle těchto doporučených obran, což zmírní všechny typy útoků, zejména útok phishing souhlasu, kde ú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í.

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.

Reference

Zdroj obsahu pro tento článek je následující:

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