Microsoft Entra ID 中應用程式屬性的安全性最佳做法

在 Microsoft Entra ID 中註冊應用程式時，安全性是一項重要概念並是組織中商務用途的重要部分。 應用程式的任何設定錯誤都會導致停機或入侵。 取決於新增至應用程式的權限，可能會對整個組織造成影響。

由於安全應用程式對組織而言至關重要，因此因安全性問題對應用程式造成的任何停機都可能會影響企業或企業所依賴的某些重要服務。 因此，請務必配置時間和資源，以確保應用程式一律會維持良好的安全狀態。 對應用程式進行定期安全性和健康狀態評量，如同您對程式碼進行安全性威脅模型評量一樣審慎。 如需更廣泛的組織安全性觀點，請參閱安全性開發週期 (SDL) (英文)。

本文說明下列應用程式屬性和案例的安全性最佳做法：

• 身分類型
• 憑據
• 重新導向 URL
• 隱含流程組態
• 應用程式識別碼 URI （也稱為識別碼 URI）
• 存取令牌版本
• 應用程式範例鎖定
• 應用程式擁有權

身分類型

您可能在這裡瞭解 Microsoft Entra 應用程式 的安全性最佳做法，也稱為應用程式註冊或應用程式物件。 不過，還有另一種身分識別類型可用來存取受 Entra 保護的資源，稱為 Azure 資源的受控識別。

根據預設，Azure 受控識別是安全的，不需要持續維護或額外負荷。 如果以下所有條件都符合，請考慮使用受管理的身分，而不是 Microsoft Entra 應用程式作為您的應用程式身分識別。

• 服務會在 Azure 雲端中執行
• 應用程式不需要登入使用者
• 應用程式不需要作為令牌流程中的資源（不是 Web API）
• 應用程式不需要在多個租戶中運行

本文的其餘部分涵蓋 Entra 應用程式註冊屬性的安全性最佳做法。

認證（包括憑證和秘密）

認證是應用程式作為機密用戶端時的重要部分。 在 Azure 入口網站中應用程式的 [ 憑證和秘密 ] 頁面底下，可以新增或移除認證。

請考慮下列與憑證和秘密相關的指引：

• 盡可能使用 受控識別 作為認證。 強烈建議這麼做，因為受控識別既是最安全的選項，也不需要任何進行中的認證管理。 請遵循 此指引 ，將受控識別設定為認證。 不過，只有在應用程式用於 Azure 上的服務時，才能使用此選項。
• 如果使用中的服務未在 Azure 上執行，但在提供自動化認證管理的另一個平台上執行，請考慮 使用來自該平臺的身分識別作為認證。 例如， GitHub 動作工作流程可以設定為認證，而不需要管理及保護 GitHub 動作管線的認證。 請謹慎使用此方法，並只設定您信任之平臺的同盟認證。 應用程式只和設定為認證的身分識別平台一樣安全。
• 如果無法使用受控識別或其他安全的外部識別提供者，請使用 憑證認證。 請勿使用密碼認證，也稱為 秘密。 雖然使用密碼密碼作為認證很方便，但密碼認證通常管理錯誤，而且很容易遭到入侵。
• 如果必須使用憑證而非受控識別，請將該憑證儲存在安全的密鑰保存庫中，例如 Azure Key Vault。
• 如果必須使用憑證而非受控識別，請使用來自受信任證書頒發機構單位 （CA） 的憑證，而不是自我簽署憑證。 設定政策以確保憑證來自可靠的簽發者。 不過，如果無法使用受信任的CA，自我簽署憑證仍優先於密碼。
• 設定 應用程式管理原則 ，藉由限制其存留期或完全封鎖其使用，以控管秘密的使用。
• 如果應用程式只作為公用或已安裝的用戶端使用（例如，安裝在用戶電腦上的行動或傳統型應用程式），請確定應用程式對象上沒有指定的認證。
• 檢閱應用程式中使用的認證，以了解有效使用時間及其到期日。 應用程式上未使用的認證可能導致安全性缺口。 經常變換認證，且不會跨應用程式共用認證。 請勿在一個應用程式上有多個認證。
• 監視生產管線，防止將任何種類的認證認可至程式碼存放庫。 認證掃描器是一種靜態分析工具，可用於偵測原始程式碼中的認證 (以及其他敏感性內容) 並建置輸出。

重新導向 URL

務必將應用程式的重新導向 URI 保持最新狀態。 在 Azure 入口網站中應用程式的 [驗證] 下，必須選取應用程式的平台，接著便可以定義 [重新導向 URI] 屬性。

請考慮下列重新導向 URI 的指引：

• 維護所有 URI 的擁有權。 任何一個重新導向 URI 擁有權中的疏失都可能導致應用程式遭到入侵。
• 確定所有 DNS 記錄都會針對變更，定期進行更新及監視。
• 請勿使用萬用字元回覆 URL 或不安全的 URI 配置，例如 http 或 URN。
• 將清單保持精簡。 修剪任何不必要的 URI。 如果可行，請將 URL 從 Http 更新為 Https。

隱含流程組態

之前需要「隱含流程」的案例現在可以使用「驗證碼流程」，以降低與誤用隱含流程相關聯的入侵風險。 在 Azure 入口網站中應用程式的 [驗證] 下，必須選取應用程式的平台，接著便可以適當設定 [存取權杖 (用於隱含流程)] 屬性。

請考慮下列與隱含流程相關的指引：

• 了解是否需要隱含流程。 除非明確要求，否則請勿使用隱含流程。
• 如果應用程式已設定為使用隱含流程以接收存取權杖，但未主動使用這些權杖，請關閉設定以避免誤用。
• 針對有效的隱含流程案例，使用個別的應用程式。

應用程式 ID URI（也稱為識別碼 URI）

應用程式的 [應用程式識別碼 URI] 屬性會指定用來識別 Web API 的全域唯一 URI。 這是用於要求 Microsoft Entra 的範圍值的前綴詞。 這也是 v1.0 存取令牌中觀眾（aud）宣告的值。 對於多租使用者應用程式，此值也必須是全域唯一的。 也稱為 識別碼 URI。 在 Azure 入口網站中應用程式的 [公開 API] 下，即可定義 [應用程式識別碼 URI] 屬性。

定義應用程式識別碼 URI 的最佳做法會根據應用程式是否發出 v1.0 或 v2.0 存取令牌而變更。 如果您不確定某個應用程式是否發行了 v1.0 存取權杖，請檢查該應用程式的 requestedAccessTokenVersion的 。 null 或 1 值表示應用程式會收到 v1.0 存取令牌。 2 值表示應用程式會收到 v2.0 存取令牌。

針對發行 v1.0 存取令牌的應用程式，應該只使用預設 URI。 預設 URI 為 api://<appId>，api://<tenantId>/<appId>。 - 設定nonDefaultUriAddition應用程式管理原則中的限制，以針對組織中應用程式的未來更新強制執行此最佳做法。

針對發行 v2.0 存取令牌的應用程式，在定義應用程式識別碼 URI 時，請使用下列指導方針：

• 建議使用 api 或 https URI 配置。 以支援的格式設定屬性，以避免組織中發生 URI 衝突。 請勿使用萬用字元。
• 使用您組織的已驗證網域。
• 在組織中保留 URI 的詳細目錄，有助於維護安全性。

支援下列 API 和以 HTTP 配置為基礎的應用程式識別碼 URI 格式。 將預留位置值取代為下表清單中所述的項目。

• <appId>：應用程式物件的應用程式識別碼 (appId) 屬性。
• <string>：主機或 API 路徑線段的字串值。
• <tenantId>：Azure 所產生的 GUID，用來代表 Azure 內的租用戶。
• <tenantInitialDomain> - <tenantInitialDomain>.onmicrosoft.com，其中 <tenantInitialDomain> 是租用戶建立者在建立租用戶時指定的初始網域名稱。
• <verifiedCustomDomain>：為 Microsoft Entra 租用戶設定的已驗證自訂網域。

存取令牌版本

本節僅適用於資源應用程式，意即那些在存取令牌中充當接收者或對象的應用程式。 資源應用程式通常是 Web API。 如果應用程式只做為用戶端（這表示它會取得令牌以傳送至 Microsoft Graph 等資源），則本節不適用。

已設定自定義 標識碼 URI 的資源應用程式應該使用 v2.0 存取令牌格式。 若要檢查應用程式是否應該使用 v2.0 存取令牌，請查看 identifierUris 應用程式的應用程式 註冊指令清單頁面中 的屬性。

如果設定的值未符合api://{appId}或api://{tenantId}/{appId}的格式，則應用程式應該使用 v2.0 存取令牌。

若要升級至 v2.0 存取令牌，請先確定應用程式可以處理 v2.0 令牌宣告。 然後，使用指令清單編輯器來更新應用程式的存取令牌版本。

更新應用程式設定以使用 v2.0 令牌之後，請確保應用程式的受眾驗證邏輯已修改為 只 接受其 appId。

應用程式實例屬性鎖定

當應用程式將服務主體布建至租使用者時，租用戶系統管理員可以自定義該服務主體。不論該租使用者是應用程式的主租用戶還是外部租使用者，都是如此。 這些自定義功能可以允許應用程式擁有者未預期的修改，而導致安全性風險。 例如，認證可以新增至服務主體，即使認證通常應該由應用程式開發人員和擁有者擁有和控制。

為了降低此風險，應用程式應該 設定應用程式實例鎖定。 設定應用程式實例鎖定時，請一律鎖定每個可用的敏感性屬性。 設定此屬性對於多租戶應用程式特別重要，也就是指在多個租戶或組織中使用的應用程式，但所有應用程式都應該設定此屬性。

權限

您的應用程式可能需要獲得存取受保護資源或 API 的許可權。 要求許可權時，請一律確定下列事項：

• 遵循 最低必要權限 原則。 只要求授與執行應用程式所需動作所需的最寬鬆存取權的許可權。 如果呼叫 Microsoft Graph，請使用 API 檔 來識別指定 API 呼叫的最低寬鬆許可權。 定期檢閱應用程式的許可權，以檢查是否有較不具特殊許可權的選項可用。 如果應用程式不再需要許可權，請將其移除。
• 盡可能使用 委派的存取權 ，而不是 僅限應用程式存取。
• 檢閱 許可權和同意 檔，以確保您了解許可權基本概念。

應用程式擁有權設定

擁有者可以管理已註冊應用程式的所有層面。 請務必定期檢閱組織中所有應用程式的擁有權。 如需詳細資訊，請參閱Microsoft Entra 存取權檢閱 (部分機器翻譯)。 在 Azure 入口網站中應用程式的 [擁有者] 下，即可管理應用程式的擁有者。

請考慮下列與指定應用程式擁有者相關的指引：

• 應用程式擁有權應保留給組織內最低限度的人員。
• 系統管理員應每隔幾個月檢閱一次擁有者清單，以確保擁有者仍屬於組織的一部分且仍應擁有應用程式。

檢查Entra的建議

Microsoft Entra 建議功能可協助您監視租用戶的狀態，因此您不必這麼做。 這些建議可協助您確保租用戶處於安全且狀況良好的狀態，同時協助您將 Microsoft Entra ID 中可用功能的價值最大化。 定期檢閱與應用程式屬性或應用程式設定相關的任何作用中Microsoft Entra 建議，讓您的應用程式生態系統保持良好狀態。