應用程式同意授與調查

  • 發行項

本文提供識別和調查應用程式同意攻擊、保護資訊，以及將進一步風險降至最低的指引。

本文包含下列章節：

  • 必要條件： 涵蓋開始調查之前，您需要完成的特定需求。 例如，應該開啟的記錄、所需的角色和許可權等等。
  • 工作流程： 顯示您應該遵循的邏輯流程，以執行此調查。
  • 檢查清單： 包含流程圖中每個步驟的工作清單。 此檢查清單在高度管制的環境中很有説明，以驗證採取的步驟，或只是作為您自己的品質網關。
  • 調查步驟： 包含此特定調查的詳細逐步指引。
  • 復原： 包含如何從非法應用程式同意授與攻擊中復原/減輕的高階步驟。
  • 參考： 包含更多閱讀和參考數據。

必要條件

以下是您應該完成的一般設定和組態，以執行應用程式同意授與的調查。 開始調查之前，請確定閱讀同意許可權類型中所述 的同意許可權類型。

客戶資料

若要開始調查程式，您需要下列數據：

  • 以全域 管理員 身分存取租使用者 - 僅限雲端帳戶（不屬於其內部部署環境的一部分）
  • 入侵指標的詳細資料（IoC）
  • 您注意到事件的日期和時間
  • 日期範圍
  • 遭入侵的帳戶數目
  • 遭入侵帳戶的名稱
  • 遭入侵帳戶的角色
  • 帳戶是否具有高度特殊許可權（GA Microsoft Exchange、SharePoint）？
  • 是否有任何與事件相關的企業應用程式？
  • 是否有任何用戶報告任何代表其要求數據許可權的應用程式？

系統需求

請確定您已完成下列安裝和設定需求：

  1. 已安裝 AzureAD PowerShell 模組。
  2. 您在文稿執行的租使用者上具有全域管理員許可權。
  3. 您在用來執行文稿的電腦上獲指派本機系統管理員角色。

注意

自 2024 年 3 月 30 日起，Azure AD 和 MSOnline PowerShell 模組已被淘汰。 若要深入了解，請閱讀淘汰更新。 在此日期之後，對這些模組的支援僅限於對 Microsoft Graph PowerShell SDK 的移轉協助和安全性修正。 淘汰的模組將繼續運作至 2025 年 3 月 30 日。

我們建議移轉至 Microsoft Graph PowerShell 以與 Microsoft Entra ID (以前稱為 Azure AD) 互動。 如需了解常見的移轉問題，請參閱移轉常見問題。 注意：MSOnline 1.0.x 版可能會在 2024 年 6 月 30 日之後發生中斷。

安裝 AzureAD 模組

使用此命令來安裝 AzureAD 模組。

Install-Module -Name AzureAD -Verbose

注意

如果系統提示您從不受信任的存放庫安裝模組，請輸入 Y ，然後按 Enter。

安裝 MSOnline PowerShell 模組

  1. 以提升的許可權執行 Windows PowerShell 應用程式（以系統管理員身分執行）。

  2. 執行此命令以允許 PowerShell 執行已簽署的腳本。

    Set-ExecutionPolicy RemoteSigned

  3. 使用此命令安裝 MSOnline 模組。

    Install-Module -Name MSOnline -Verbose

    注意

    如果系統提示您從不受信任的存放庫安裝模組，請輸入 Y ，然後按 Enter。

從 GitHub 下載 AzureADPSPermissions 腳本

  1. 將 Get-AzureADPSPermissions.ps1 腳本從 GitHub 下載到您執行腳本的資料夾。 輸出檔案 「permissions.csv」 也會寫入這個相同的資料夾。

  2. 以系統管理員身分開啟 PowerShell 實例，然後開啟您儲存腳本的資料夾。

  3. 使用 Connect-AzureAD Cmdlet 連線 目錄。 以下是範例。

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

  4. 執行此 PowerShell 命令。

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

    使用此命令中斷 AzureAD 會話的連線。

    Disconnect-AzureAD

同意是將授權授與應用程式以代表使用者存取受保護資源的程式。 系統管理員可以要求系統管理員或使用者同意允許存取其組織/個人資料。

應用程式會根據特定用戶或整個組織授與數據存取權。 攻擊者可能會誤用這些同意來取得環境的持續性並存取敏感數據。 這些類型的攻擊稱為「非法同意授與」，這些攻擊可能透過網路釣魚電子郵件、用戶帳戶透過密碼噴洒入侵，或攻擊者將應用程式註冊為合法用戶時發生。 在全域 管理員 帳戶遭到入侵的情況下，則註冊和同意授與適用於整個租使用者，而不只是針對一個使用者。

在應用程式可以存取貴組織的資料之前，使用者必須授與應用程式權限。 不同的權限允許不同的存取層級。 根據預設，所有使用者都能同意應用程式，以取得不需要系統管理員同意的權限。 例如，根據預設，使用者可以同意允許應用程式存取其信箱，但無法同意允許應用程式不受限制地讀取和寫入組織中的所有檔案。

注意

透過允許使用者授予應用程式存取資料的權限，使用者可以輕鬆獲取有用的應用程式並提高工作效率。 不過，在某些情況下，如果未仔細監視及控制，此設定可能會代表風險。

若要能夠授與 全租用戶的系統管理員同意，您必須以下列其中一項身分登入：

  • 全域管理員
  • 應用程式系統管理員
  • 雲端應用程式系統管理員
  • 管理員 istrator -表示系統管理員已提供同意（代表組織）
  • 個別使用者 - 指出使用者已授與同意，且只能存取該用戶的資訊
  • 接受的值
    • AllPrincipals - 由系統管理員同意整個租用
    • 主體 – 由個別使用者同意僅與該帳戶相關的數據

授與同意的實際用戶體驗會根據使用者租用戶上設定的原則、使用者的授權範圍（或角色）和用戶端應用程式所要求的許可權類型而有所不同。 這表示應用程式開發人員和租用戶系統管理員對同意體驗有一些控制權。 管理員 在租使用者或應用程式上設定和停用原則，以控制其租使用者的同意體驗。 應用程式開發人員可以決定要求的許可權類型，以及他們是否想要引導使用者通過使用者同意流程或系統管理員同意流程。

  • 使用者同意流程 - 當應用程式開發人員將使用者導向授權端點時，意圖只記錄目前使用者的同意。

  • 管理員 同意流程 - 當應用程式開發人員將用戶導向管理員同意端點時，意圖記錄整個租使用者的同意。 為了確保管理員同意流程正常運作，應用程式開發人員必須在應用程式指令清單的 RequiredResourceAccess 屬性中列出所有許可權。

委派的許可權與應用程式許可權

具有登入使用者的應用程式會使用委派的許可權，而且可由系統管理員或使用者套用同意。

在沒有已登入使用者的情況下執行的應用程式會使用應用程式權限。 例如，以背景服務或精靈身分執行的應用程式。 應用程式許可權只能由系統管理員同意。

如需詳細資訊，請參閱

分類具風險的許可權

系統中有數千個（至少）的許可權，無法列出或剖析所有這些許可權。 下列清單說明通常誤用的許可權，以及其他會在誤用時造成重大影響的其他人。

概括而言，Microsoft 觀察到下列「根」委派許可權（App+使用者）在同意網路釣魚攻擊中被誤用。 根等於最上層。 例如，Contacts.* 表示包含聯繫人許可權的所有委派排列：Contacts.Read、Contacts.ReadWrite、Contacts.Read.Shared 和 Contacts.ReadWrite.Shared。

  1. Mail.* （包括 Mail.Send*，但不包括 Mail.ReadBasic*）
  2. 接觸。 *
  3. Mailbox 設定.*
  4. 人員.*
  5. 檔案。*
  6. 筆記。*
  7. Directory.AccessAsUser.All
  8. User_Impersonation

上述清單中的前七個許可權適用於 Microsoft Graph 和「舊版」API 對等專案，例如 Azure Active Directory （Azure AD） Graph 和 Outlook REST。 第八個許可權適用於 Azure Resource Manager （ARM），而且對於任何公開敏感數據的 API 而言，也可能很危險，且此總管模擬範圍會公開敏感數據。

根據 Microsoft 事件回應小組的觀察，攻擊者會在同意網路釣魚攻擊的 99% 中使用前六個許可權的組合。 大多數人不會將 Mail.Read 或 Files.Read 委派版本視為高風險許可權，不過，攻擊通常是針對終端用戶的攻擊，而不是針對實際同意危險許可權的系統管理員進行魚叉式網路釣魚。 建議使用這些「重要」影響許可權層級來泡泡應用程式。 即使應用程式沒有惡意意圖，而且如果不良動作專案入侵應用程式身分識別，則整個組織可能面臨風險。

如需最高風險影響許可權，請從這裡開始：

  • 適用時，所有上述許可權的應用程式許可權 （AppOnly/AppRole） 版本

委派和 AppOnly 版本的下列許可權：

  • 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
  • 允許寫入存取權的所有其他 AppOnly 許可權

如需最低風險影響許可權清單，請從這裡開始：

  • User.Read
  • User.ReadBasic.All
  • Open_id
  • Email
  • 設定檔
  • Offline_access （只有在與這個「最低風險」清單的其他許可權配對時）

檢視權限

  1. 若要檢視許可權，請瀏覽至企業應用程式中的 [ 註冊 ] 畫面。

    檢視許可權

  2. 選取 [ 檢視 API 許可權]。

    apipermissions

  3. 選取 [新增許可權 ]，並顯示下列畫面。

    api

  4. 選取 [Microsoft Graph ] 以檢視不同類型的許可權。

    許可權類型

  5. 選取已註冊應用程式使用的許可權類型： 委派的許可權 或 應用程式許可權。 在上圖中， 已選取 [應用程式許可權 ]。

  6. 您可以搜尋其中一個高風險影響許可權，例如 EduRoster。

    examplepermission

  7. 選取 [EduRoster ]，然後展開許可權。

    埃杜羅斯特

  8. 您現在可以指派或檢閱這些許可權。

    如需詳細資訊， 請取得圖形許可權。

工作流程

[應用程式同意授與調查工作流程]

您也可以：

  • 將應用程式同意授與和其他事件回應劇本工作流程下載為 PDF。
  • 下載應用程式同意授與和其他事件回應劇本工作流程作為 Visio 檔案。

檢查清單

使用此檢查清單來執行應用程式同意授與驗證。

  • 需求

    請確定您可以存取租用戶作為全域 管理員。這是僅限雲端的帳戶，不屬於內部部署環境的一部分。

  • 入侵指標 （IoC）

    檢查下列入侵指標 （IoC）：

    • 您何時注意到這一事件？
    • 事件的日期範圍（目標職位還有多遠？
    • 遭入侵的帳戶數目
    • 遭入侵帳戶的名稱
    • 遭入侵帳戶的角色
    • 遭入侵的帳戶是否具有高度特殊許可權、標準用戶或組合

  • 角色

    您必須使用這些角色來指派：

    • 租用戶上執行腳本的全域管理員許可權
    • 在您執行文本的電腦上本機 管理員 istrator 角色

  • PowerShell 組態

    使用下列步驟設定 PowerShell 環境：

    1. 安裝 Azure AD PowerShell 模組。
    2. 使用提升的許可權執行 Windows PowerShell 應用程式。 （以系統管理員身分執行）。
    3. 設定 PowerShell 以執行已簽署的腳本。
    4. 下載 Get-AzureADPSPermissions.ps1 腳本。

  • 調查觸發程式

    • 帳戶入侵
    • 在租使用者上修改的應用程式同意設定
    • 偵測到「有風險的應用程式」的警示/稽核事件狀態原因
    • 注意到奇怪的應用程式

您也可以將應用程式同意授與和其他事件劇本檢查清單下載為 Excel 檔案。

調查步驟

您可以使用下列兩種方法來調查應用程式同意授與：

  • Azure 入口網站
  • PowerShell 指令碼

注意

使用 Azure 入口網站 只允許您查看過去 90 天的 管理員 同意授與，因此，我們建議只使用 PowerShell 腳本方法來減少攻擊者註冊調查步驟。

方法 1 – 使用 Azure 入口網站

您可以使用 Microsoft Entra 系統管理中心來尋找個別使用者已授與許可權的應用程式。

  1. 以系統管理員身分登入 Azure 入口網站。
  2. 選取 Microsoft Entra 識別符 圖示。
  3. 選取使用者。
  4. 選取您要檢閱的使用者。
  5. 選取應用程式。
  6. 您可以看到指派給使用者的應用程式清單，以及這些應用程式具有哪些許可權。

方法 2 - 使用 PowerShell

有數種 PowerShell 工具可用來調查非法同意授與，例如：

PowerShell 是最簡單的工具，不需要您在租用中修改任何專案。 我們將根據非法同意授權攻擊的公開文件進行調查。

執行 Get-AzureADPSPermissions.ps1，將租使用者中所有使用者的所有 OAuth 同意授與和 OAuth 應用程式導出至 .csv 檔案。 請參閱必要條件一節，以下載並執行Get-AzureADPSPermissions腳本。

  1. 以系統管理員身分開啟 PowerShell 實例，然後開啟您儲存腳本的資料夾。

  2. 使用下列 連線-AzureAD 命令，連線 至您的目錄。 以下是範例。

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

  3. 執行此 PowerShell 命令。

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

  4. 腳本完成之後，建議您使用此命令中斷 Microsoft Entra 會話的連線。

     Disconnect-AzureAD

    注意

    視設定的大小和許可權以及連線而定，腳本可能需要數小時才能完成。

  5. 腳本會建立名為 Permissions.csv 的檔案。

  6. 開啟檔案、篩選或將數據格式化為數據表，然後儲存為 .xlxs 檔案（用於篩選）。

    輸出 的數據 行標頭會顯示在此影像中。

    數據行標頭的範例

  7. 在 ConsentType 資料行 （G） 中，搜尋 AllPrinciples 值。 AllPrincipals 許可權可讓用戶端應用程式存取租用中每個人的內容。 原生 Microsoft 365 應用程式需要此許可權才能正常運作。 應仔細檢閱具有此許可權的每個非 Microsoft 應用程式。

  8. 在 [ 許可權] 資料 行 （F）中，檢閱每個委派應用程式擁有的許可權。 尋找 讀取 和 寫入 許可權或 *。所有 許可權，並仔細檢閱這些許可權，因為它們可能不適合。 許可權數據行 F 的範例

    注意

    檢閱已授與同意的特定使用者。 如果高調或高影響使用者授與不當同意，您應該進一步調查。

  9. 在 ClientDisplayName 資料行 （C）中，尋找看似可疑的應用程式，例如：

    • 名稱拼錯的應用程式 拼錯名稱的範例

    • 不尋常的或平淡的名稱 不尋常的名稱範例

    • 駭客聽起來的名字。 您必須仔細檢閱這些名稱。 駭客名稱的範例

範例輸出： AllPrincipals 和 read write all。 應用程式可能沒有任何可疑專案，例如平淡的名稱，而且正在使用 MS 圖形。 不過，請執行研究並判斷應用程式在租用戶中擁有的實際許可權，如此範例所示。

AllPrincipals ConsentType 的應用程式範例

以下是檢閱資訊安全策略 （ISP） 調查的一些實用秘訣：

  1. ReplyURL/RedirectURL
    • 尋找可疑的URL
  2. URL 是否裝載在可疑網域上？
    • 是否遭到入侵？
    • 網域最近是否已註冊？
    • 這是暫存網域嗎？
  3. 應用程式註冊中是否有服務/服務合約連結？
  4. 內容是否是唯一且專屬於應用程式/發行者？
  5. 新建立或遭入侵的租使用者是否已註冊應用程式（例如，由有風險的用戶註冊應用程式）？

攻擊技術

雖然 每個攻擊通常會有所不同，但核心攻擊技術如下：

  • 攻擊者向 OAuth 2.0 提供者註冊應用程式，例如 Microsoft Entra ID。

  • 應用程式是以看似合法的方式進行設定。 例如，攻擊者可能會使用相同的生態系統中可用的熱門產品名稱。

  • 攻擊者可以直接從使用者取得連結，這些連結可能透過傳統電子郵件型網路釣魚、入侵非惡意網站或透過其他技術來完成。

  • 用戶選取連結，並顯示正宗同意提示，要求他們授與惡意應用程式數據的許可權。

  • 如果使用者選取 [接受]，則會授與應用程式存取敏感數據的許可權。

  • 應用程式會取得授權碼，其會兌換存取令牌，以及可能重新整理令牌。

  • 存取令牌是用來代表用戶進行 API 呼叫。

  • 如果使用者接受，攻擊者就可以存取使用者的郵件、轉寄規則、檔案、聯繫人、筆記、配置檔和其他敏感數據和資源。

    許可權要求的範例

尋找攻擊的跡象

  1. 開啟 [安全性與合規性中心]。

  2. 流覽至 [ 搜尋 ]，然後選取 [ 稽核記錄搜尋]。

  3. 搜尋 （所有活動和所有使用者）並輸入開始日期和結束日期（如有需要），然後選取 [ 搜尋]。

    稽核記錄搜尋的範例

  4. 選取 [ 篩選結果] ，然後在 [ 活動 ] 字段中輸入 [同意 應用程式]。

    篩選稽核記錄搜尋的範例

  5. 如果您有同意授與的活動，請依照下列指示繼續進行。

  6. 選取結果以查看活動的詳細數據。 選取 [詳細資訊 ] 以取得活動的詳細數據。

  7. 檢查Is 管理員 Content 是否設定為 『True』。

    注意

    此程式可能需要 30 分鐘到 24 小時的時間，對應的稽核記錄專案才會在事件發生后顯示在搜尋結果中。

    稽核記錄會保留並可在稽核記錄中搜尋的時間範圍取決於您的 Microsoft 365 訂閱，特別是指派給特定使用者的授權類型。 如果此值為 true，表示具有 Global 管理員 istrator 存取權的人員可能已授與數據的廣泛存取權。 如果這是非預期的，請立即採取步驟來確認攻擊。

如何確認攻擊？

如果您有一或多個先前列出的 IOC 實例，您必須進行進一步調查，以積極確認發生攻擊。

清查組織中具有存取權的應用程式

您可以使用 Microsoft Entra 系統管理中心、PowerShell 來清查使用者的應用程式，或讓使用者個別列舉其應用程式存取權。

  • 使用 Microsoft Entra 系統管理中心來清查應用程式及其許可權。 這個方法是徹底的，但您一次只能檢查一個使用者，如果您必須檢查數個用戶的許可權，這很耗時。
  • 使用 PowerShell 清查應用程式及其許可權。 此方法是最快速且最徹底的，且額外負荷最少。
  • 鼓勵使用者個別檢查其應用程式和許可權，並將結果回報給系統管理員以進行補救。

指派給使用者的清查應用程式

您可以使用 Microsoft Entra 系統管理中心來查看個別使用者已授與許可權的應用程式清單。

  1. 使用系統管理許可權登入 Azure 入口網站 。
  2. 選取 Microsoft Entra 識別符 圖示。
  3. 選取使用者。
  4. 選取您要檢閱的使用者。
  5. 選取應用程式。

您可以看到指派給使用者的應用程式清單，以及授與這些應用程式的許可權。

判斷攻擊的範圍

完成清查應用程式存取之後，請檢閱稽核記錄，以判斷缺口的完整範圍。 搜尋受影響的使用者、非法應用程式可存取您組織的時間範圍，以及應用程式擁有的許可權。 您可以在 Microsoft 365 安全性與合規性中心搜尋稽核記錄。

重要： 如果在可能的攻擊之前未啟用稽核，您將 無法 調查，因為無法使用稽核數據。

如何防止攻擊並降低風險？

  • 定期 稽核應用程式 並授與貴組織中的許可權，以確保沒有任何不必要或可疑的應用程式已獲授與數據的存取權。

  • 檢閱、偵測及補救 Office 365 中的非法同意授權，以取得更多最佳做法，並防範要求 OAuth 同意的可疑應用程式。

如果您的組織擁有適當的授權：

  • 在 適用於雲端的 Microsoft Defender Apps 中使用更多 OAuth 應用程式稽核功能。
  • 使用 Azure 監視器活頁簿 來監視許可權和同意相關活動。 Consent Insights 活頁簿會依失敗的同意要求數目提供應用程式的檢視。 這有助於排定應用程式優先順序，讓系統管理員檢閱及決定是否要授與系統管理員同意。

識別具有非法許可權的應用程式之後， 請依照停用應用程式 中的 指示立即停用應用程式。 然後，請連絡 Microsoft 支援服務 報告惡意應用程式。

當您的 Microsoft Entra 租使用者中停用應用程式之後，就無法取得存取數據的新令牌，而其他使用者將無法登入或授與應用程式同意。

注意

如果您懷疑自己在組織中遇到惡意應用程式，最好將其停用，而不是刪除它。 如果您只刪除應用程式，則如果其他使用者授與同意，則稍後可能會傳回該應用程式。 相反地，請停用應用程式，以確保稍後無法返回。

保護組織的步驟

有各種同意攻擊類型，但如果您遵循這些建議的防禦，可減輕所有類型的攻擊，特別是同意網路釣魚，攻擊者會誘使用戶授與惡意應用程式對敏感數據或其他資源的存取權。 攻擊者不會嘗試竊取使用者的密碼，而是尋求攻擊者控制應用程式存取寶貴數據的許可權。

若要協助防止同意攻擊影響 Microsoft Entra ID 和 Office 365，請參閱下列建議：

設定原則

  • 此設定具有使用者含意，且可能不適用於環境。 如果您要允許任何同意，請確定系統管理員核准要求。

  • 只允許來自已驗證發行者的應用程式同意，以及分類為低影響的特定許可權類型。

    注意

    根據最理想的安全設定，建議上述建議。 不過，由於安全性在功能和作業之間是一個精細的平衡，因此最安全的設定可能會對系統管理員造成更多額外負荷。 這是與系統管理員諮詢后做出的最佳決策。

    設定風險型逐步同意 - 啟用使用者同意授與時默認啟用

  • 風險型升級同意有助減少使用者接觸提出不當要求的惡意應用程式。 如果 Microsoft 偵測到有風險的終端使用者同意要求，要求會改為要求管理員同意的「逐步執行」。 此功能預設為啟用，但只有在啟用使用者同意時，才會造成行為變更。

  • 偵測到有風險的同意要求時，同意提示會顯示訊息，指出需要管理員核准。 如果已啟用管理員同意要求工作流程，使用者可以直接從同意提示將要求傳送給系統管理員，以便進一步檢閱。 如果已啟用，會顯示下列訊息：

    AADSTS90094： <clientAppDisplayName> 需要許可權，才能存取組織中只有系統管理員可以授與的資源。 請先要求系統管理員授與此應用程式的許可權，才能使用它。 在此情況下，稽核事件也會記錄為「同意應用程式」的「ApplicationManagement」活動類型類別，以及「偵測到具風險的應用程式」狀態原因。

注意

任何需要系統管理員核准的工作都有作業額外負荷。 「同意和許可權、使用者同意設定」目前處於預覽狀態。 一旦準備好正式運作（GA），「允許已驗證的發行者同意，針對選取的許可權」功能，應該會減少系統管理員的額外負荷，而且建議大多數組織使用。

同意

教育您的應用程式開發人員遵循值得信任的應用程式生態系統。 為了協助開發人員建置高品質且安全的整合，我們也宣佈 公開預覽 Microsoft Entra 應用程式註冊中的 Integration Assistant。

  • Integration Assistant 會分析您的應用程式註冊，並針對一組建議的安全性最佳做法進行基準檢驗。
  • 整合小幫手會強調整合生命週期中每個階段相關的最佳做法，從開發到監視，並確保每個階段都已正確設定。
  • 無論您要整合第一個應用程式，還是想要改善技能的專家，它都會讓您的工作變得更容易。

教育貴組織同意策略（網路釣魚策略、系統管理員和使用者同意 ）：

  • 檢查拼字和文法不佳。 如果電子郵件訊息或應用程式的同意畫面有拼字和文法錯誤，可能是可疑的應用程式。
  • 請留意應用程式名稱和網域URL。 攻擊者喜歡詐騙應用程式名稱，使其似乎來自合法應用程式或公司，但會促使您同意惡意應用程式。
  • 在同意應用程式之前，請務必先辨識應用程式名稱和網域URL。

升級並允許存取您信任的應用程式

  • 升級發行者驗證的應用程式使用。 發行者驗證可協助系統管理員和使用者瞭解應用程式開發人員的真實性。 到目前為止，超過 660 個應用程式由 390 個發行者驗證。
  • 設定應用程式同意原則，方法是允許使用者只同意您信任的特定應用程式，例如由組織開發的應用程式，或從已驗證的發行者開發的應用程式。
  • 教育貴組織關於我們的許可權和同意 架構的運作方式。
  • 瞭解應用程式要求的數據和許可權，並瞭解許可權和同意在我們的平台中運作的方式。
  • 請確定系統管理員知道如何管理和評估同意要求。

稽核您組織中的應用程式和同意的許可權，以確保使用的應用程式只會存取所需的數據，並遵守最低許可權的原則。

風險降低

參考資料

本文的內容來源如下：

其他事件回應劇本

檢查識別和調查這些額外攻擊類型的指引：

事件回應資源