減少權限過多的應用程式和其所具備的特權

作為一名旨在設計並實作遵循 零信任指導原則的應用程式的開發者，你希望 以最少權限提升應用程式安全性。 降低應用程式的攻擊面及安全漏洞的影響是非常重要的。

在本文中，您將了解為什麼應用程式不應該請求超過所需權限。 你學會了「 過度特權」這個詞。 你會發現限制應用程式權限、管理存取並提升安全性的建議與最佳實務。

什麼是過度特權？

當應用程式請求或接收超過其正常運作所需的權限時，就會發生過度權限。 請參考本文剩餘部分未使用及可減少權限的範例，增進你對過度特權的理解。

未使用的權限

在這個未使用的鑰匙範例中，想像有三扇上鎖的門（藍色、黃色和綠色），如下圖所示。

你的資產就在門後。 你有三把鑰匙（藍色、黃色和綠色）可以打開對應的門。 例如，藍色鑰匙可以打開藍色的門。 當你只需要進入黃色門時，你只需要攜帶黃色鑰匙。

為了最好地保護你的資產，你只會在需要時攜帶鑰匙，並將未使用的鑰匙放在安全的地方。

可約化權限

化簡鍵的範例比未使用鍵的範例更複雜，我們現在加入兩個特殊鍵，如下圖所示。

第一把黑鑰匙是通行鑰匙，可以打開所有門。 第二把黑鑰匙可以打開黃色和綠色的門。 當你只需要進入黃色和綠色的門時，你只需要攜帶第二把黑色鑰匙。 你把通行鑰匙和冗餘的綠色鑰匙放在安全的地方。

在 Microsoft 身份平台上，金鑰是存取權限。 作為鑰匙持有者，你和你的資源都是應用程式。 如果你了解攜帶不必要金鑰的風險，你也知道你的應用程式可能擁有不必要的權限。

許可缺口與風險

門與鑰匙如何幫助理解過度特權的形成？ 為什麼你的應用程式可能擁有執行任務的正確權限，卻仍然被過度特權？ 讓我們看看下圖中可能導致差異的權限落差。

X 軸代表 時間 ，Y 軸代表 權限。 在開始計量時間時，你申請並獲得應用程式的使用許可。 隨著業務成長與變化，你會新增權限以支援需求，授權的斜率也會增加。 當你忘記移除不必要的權限（例如應用程式沒有崩潰）時， 所使用的權限 可能會低於 已授權 權限，導致權限 缺口。

以下是關於 Microsoft 身份平台的有趣觀察。

• 我們在 Microsoft Graph 中擁有超過 4,000 個 API。
• Microsoft 身份平台上共有超過 200 項 Microsoft Graph 權限。
• 開發者能存取廣泛的資料，並能對應用程式請求的權限套用細緻度。
• 在我們的調查中，我們發現應用程式在情境中僅充分利用 10% 的權限。

仔細思考你的應用程式需要哪些權限。 注意權限缺口，並定期檢查申請權限。

安全因過度特權而受損

讓我們以一個例子深入探討許可缺口所帶來的風險。 這種妥協情境包含兩個角色：IT 管理員與開發人員。

• IT 管理員：Jeff 是租戶管理員，負責確保 Microsoft Entra ID 中的應用程式值得信賴且安全。 Jeff 的工作之一是授權應用程式開發者所需的權限。
• 開發者：Kelly 是一位使用 Microsoft 身份平台並擁有應用程式的開發者。 Kelly 的工作是確保應用程式擁有執行所需任務的正確權限。

以下常見的過度權限安全入侵情境通常分為四個階段。

1. 開發者開始設定應用程式並新增所需權限。
2. IT 管理員會審查所需權限並給予同意。
3. 惡意行為者開始破解使用者憑證，並成功駭入使用者身份。
4. 如果使用者擁有多個應用程式，他們也會擁有過多權限。 惡意行為者能迅速利用授權的令牌來取得敏感資料。

權限過高的應用程式

當一個實體請求或獲得超過所需權限時，它就會被過度特權支配。 Microsoft 身份平台中過度 特權的應用程式 定義為 任何擁有未使用或可簡化權限的應用程式。

讓我們以 Microsoft Graph 作為 Microsoft 身份平台的一部分，以實際例子來更了解未使用的權限與可簡化權限。

未使用的權限是指你的應用程式獲得的權限對想要的任務來說並非必要的。 舉例來說，你正在打造一個行事曆應用程式。 你的行事曆應用程式會 Files.ReadWrite.All 請求並獲得許可。 你的應用程式沒有整合任何檔案的 API。 因此，您的應用程式擁有未使用的 Files.ReadWrite.All 權限。

可約化許可則較難發現。 當你的應用程式權限不多，但擁有較低權限的替代方案，能提供足夠存取權限完成所需任務時，就會發生這種情況。 以行事曆應用程式為例，你的應用程式請求 Files.ReadWrite.All 並獲得權限。 不過，它只需要讀取已登入使用者 OneDrive 的檔案，且不需要建立新檔案或修改現有檔案。 在這種情況下，你的應用程式只部分利用 Files.ReadWrite.All ，所以你需要降級到 Files.Read.All。

減少過度特權情境的建議

安全是一段旅程，而非終點。 安全生命週期分為三個明確階段：

• 預防
• Auditing
• Remediation

下圖說明了減少過度特權情境的建議。

• 預防：當你建置應用程式時，請充分了解應用程式需要呼叫的 API 權限。 只要求啟用你情境所需的部分。 Microsoft Graph 文件提供了關於各端點的權限，從最低權限到最高權限的清晰參考。 在決定需要哪些權限時，務必注意過高權限的情況。
• 審計：您和 IT 管理員應定期檢視現有應用程式先前授予的權限。
• 修復：如果你或 IT 管理員發現生態系中有過度特權的應用程式，請停止請求該權限的代幣。 IT 管理員應該撤銷已授權的同意。 此步驟通常需要更改程式碼。

維持最小權限的最佳實務

維持應用程式最小權限權限的兩大主要誘因是推動應用程式採用，以及阻止這種擴散。

• 透過打造一個值得信賴的應用程式，避免過度請求權限，推動用戶採用。 限制應用程式的權限至完成任務所需。 這種做法能降低攻擊的潛在範圍，並提升用戶對應用程式的採用率。 在審查應用程式申請的權限及決定是否授予應用程式權限時，請更加仔細審查。
• 透過確保惡意行為者無法利用過度權限來進一步存取，來阻止傳播。 當你建立一個要求不必要權限的應用程式時，獲得批准或完全拒絕的機率最低。 控制損害的最佳方法是防止惡意行為者獲得更高權限，從而擴大攻擊範圍。 例如，如果你的應用程式只需要 User.ReadBasic.All 讀取使用者基本資訊，那麼你的 OneDrive、Outlook、Teams 以及任何機密資料在應用程式被入侵時都是安全的。

下一步

• 取得存取資源的授權 可協助您瞭解如何在取得應用程式的資源訪問許可權時，最好確保零信任。
• 使用零信任身分識別方法來建置應用程式 ，提供許可權和存取最佳做法的概觀。
• 客製化令牌 描述您可以在 Microsoft Entra 令牌中接收的資訊。 它說明如何自訂權杖以提高靈活性和控制力，同時以最低權限提高應用程式零信任安全性。
• 在令牌 中設定群組宣告和應用程式角色會示範如何使用應用程式角色定義來設定應用程式，並將安全組指派給應用程式角色。 這些方法有助於提高靈活性和控制力，同時以最低權限提高應用程式零信任安全性。
• 在您的應用程式中實現零信任準備：為最小特權設計 有助於您利用 Microsoft 身分識別平台的最小特權存取原則設計應用程式。
• 以最小權限原則提升應用程式安全性 ，有助於降低應用程式的攻擊面，以及若安全漏洞發生於Microsoft身份平台整合應用中時的影響（爆炸半徑）。
• Graph Explorer 與 Microsoft Graph 權限參考 協助你選擇 Microsoft Graph API 呼叫以啟用應用程式情境，並從權限最低到最高找到相應權限。