減少過度許可權的許可權和應用程式

身為開發人員，旨在設計和實作遵循 零信任 指導原則的應用程式，您想要以最低許可權提高應用程式安全性。 您必須減少應用程式的受攻擊面，以及安全性缺口的影響。

在本文中，您將瞭解應用程式為何不應該要求比所需的更多許可權。 您瞭解過度許可權的詞彙，並探索限制應用程式許可權來管理存取權並改善安全性的建議和最佳做法。

什麼是過度許可權？

當應用程式要求或收到的許可權超過它正常運作所需的許可權時，就會發生過度許可權 。 使用本文其餘部分未使用和減少許可權的範例，改善您對過度許可權的瞭解。

未使用的許可權

針對這個未使用的按鍵範例，假設有三扇鎖門（藍色、黃色和綠色），如下圖所示。

您的資產位於門後方。 您有三個鑰匙（藍色、黃色和綠色），可讓您打開對應的門。 例如，藍色鍵可以開啟藍色門。 當您只需要存取黃色門時，您只會攜帶黃色鑰匙。

為了最妥善地保護您的資產，您只需在需要時攜帶所需的密鑰，並將未使用的密鑰保留在安全的位置。

可減少的許可權

可減少的索引鍵範例比我們現在新增兩個特殊索引鍵的未使用密鑰範例更為複雜，如下圖所示。

第一個黑色鑰匙是一個傳遞鍵，可以打開所有門。 第二個黑色鑰匙可以打開黃色和綠色門。 當您只需要存取黃色和綠色門時，您只會攜帶第二個黑色鑰匙。 您可以使用備援的綠色金鑰，將傳遞金鑰保留在安全的位置。

在 Microsoft 身分識別世界中，金鑰是訪問許可權。 您的資源和您是金鑰持有者，都是應用程式。 如果您了解攜帶不必要密鑰的風險，您就會知道應用程式具有不必要的許可權風險。

許可權差距和風險

門和鑰匙如何協助瞭解過度許可權的發生方式？ 為什麼您的應用程式具有執行工作的正確許可權，但仍過度許可權？ 讓我們看看可能導致下圖中差異的許可權差距。

X 軸代表 Time ，而 Y 軸代表 Permissions。 在測量 時間開始時，您要求並接收應用程式的許可權。 隨著企業隨著時間的成長和變更，您可以新增新的許可權以支援您的需求，以及授與許可權的斜率增加。 當您忘記移除不必要的許可權時，[使用的許可權] 可能會低於 [授與的許可權] （例如，如果應用程式未中斷），而導致許可權差距。

以下是 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。

建議 以減少過度許可權的案例

安全性是旅程，而不是目的地。 安全性生命週期有三個不同的階段：

• 防止
• 稽核
• 補救

下圖說明減少超特殊許可權案例的建議。

• 防止：建置應用程式時，您應該完全瞭解應用程式需要進行之 API 呼叫所需的許可權，並只要求啟用案例所需的內容。 Microsoft Graph 檔對於所有端點具有最低許可權許可權的明確參考。 當您判斷您需要的許可權時，請留意過度許可權的案例。
• 稽核：您和IT系統管理員應該定期檢閱現有應用程式先前授與的許可權。
• 補救：如果您或IT系統管理員注意到生態系統中的過度許可權應用程式，您應該停止要求過度許可權許可權的令牌。 IT 系統管理員應該撤銷已授與的同意。 此步驟通常需要變更程序代碼。

維護最低許可權許可權的最佳做法

在您的應用程式中維護最低許可權許可權的兩個主要獎勵是推動應用程式採用和停止傳播。

• 為可避免過多許可權要求的客戶建置值得信任的應用程式，以推動採用。 將應用程式許可權限為僅需要完成其工作的許可權。 這種做法可減少攻擊的潛在爆破半徑，並增加客戶對應用程式的採用。 檢閱應用程式要求的許可權，並決定是否授與應用程式許可權時，請套用更多審查。
• 藉由確保攻擊者無法使用過多的許可權來取得進一步的存取權，藉此停止傳播。 當您建立要求不必要許可權的應用程式時，最不可能收到核准或完全拒絕。 控制損害的最佳方式是防止攻擊者獲得提高的許可權，進而增加入侵範圍。 例如，如果您的應用程式只需要 User.ReadBasic.All 讀取使用者基本資訊，則如果應用程式遭到入侵，您的 OneDrive、Outlook、Teams 和任何機密數據都安全。

下一步

• 取得存取資源的授權可協助您瞭解如何在取得應用程式的資源訪問許可權時，最好確保 零信任。
• 使用身分識別 零信任 方法來建置應用程式，提供許可權和存取最佳做法的概觀。
• 自定義令牌 描述您可以在 Microsoft Entra 令牌中接收的資訊。 它說明如何自定義令牌，以改善彈性和控制，同時提高應用程式零信任安全性與最低許可權。
• 在令牌 中設定群組宣告和應用程式角色會示範如何使用應用程式角色定義來設定應用程式，並將安全組指派給應用程式角色。 這些方法有助於改善彈性和控制，同時以最低許可權增加應用程式零信任安全性。
• 在應用程式中達成 零信任 整備：設計最低許可權可協助您使用具有 Microsoft 身分識別平台 最低特殊許可權存取原則來設計應用程式。
• 使用最低許可權原則增加應用程式安全性，可協助您減少應用程式的受攻擊面，以及在 Microsoft 身分識別平台整合式應用程式中發生安全性缺口的影響（爆破半徑）。
• Graph 總 管和 Microsoft Graph 許可權參考 可協助您選取 Microsoft Graph API 呼叫，以啟用您的應用程式案例，並從最低許可權到最特殊許可權尋找對應的許可權。