Microsoft Entra ID 是什麼？MFA、條件式存取與應用整合

Azure Active Directory（Azure AD）現在叫做 Microsoft Entra ID。這不是另一套要重新部署的服務，而是產品名稱變更；原有租用戶、登入網址、API、PowerShell Cmdlet、MSAL 與既有整合仍可繼續運作。若你正在查 Azure AD 驗證、MFA、SSPR 或應用程式註冊，現在應在 Microsoft Entra 系統管理中心尋找相關設定。

本文從管理者與開發者兩個角度，整理 Entra ID 的身分驗證方式、條件式存取、應用整合與工作負載身分，並說明哪些概念最容易混淆。

Azure AD 改名後，哪些事情有變？

Microsoft 將 Azure AD 更名為 Microsoft Entra ID，主要是為了凸顯多雲與多平台身分管理能力，也避免與傳統 Windows Server Active Directory 混淆。這次更名沒有要求現有客戶重新建立目錄或修改登入流程。

項目	目前名稱或狀態
Azure Active Directory	Microsoft Entra ID
Azure AD 條件式存取	Microsoft Entra 條件式存取
登入端點與 API	既有網址與整合維持相容
Windows Server AD	仍是內部部署目錄服務，不等同 Entra ID

Microsoft Entra ID 是什麼？

Entra ID 是雲端身分識別與存取管理服務，負責確認使用者、裝置、應用程式及工作負載的身分，並根據政策決定能否存取 Microsoft 365、Azure、自建應用程式或其他 SaaS 服務。

它與傳統 Active Directory Domain Services（AD DS）並不是相同產品。AD DS 常處理網域加入、群組原則、LDAP 與 Kerberos；Entra ID 則以雲端身分、OAuth 2.0、OpenID Connect、SAML、條件式存取及現代驗證為核心。混合環境可以同步或整合兩者，但不應把設定方式直接互換。

先分清楚：驗證、授權與權杖

驗證（Authentication）：確認登入者是誰，例如密碼、通行金鑰、憑證或 Microsoft Authenticator。
授權（Authorization）：確認已登入的身分可以做什麼，例如能否讀取 API、管理資源或存取特定應用程式。
ID Token：讓用戶端確認使用者已登入並取得基本身分宣告。
Access Token：讓應用程式代表使用者或工作負載存取受保護的 API。
Refresh Token：用來取得新的權杖，必須視為敏感憑證妥善保護。

Entra ID 支援哪些登入方式？

Entra ID 可支援密碼、Microsoft Authenticator、Windows Hello 企業版、通行金鑰（FIDO2）、憑證式驗證、Temporary Access Pass 等方法。實際可用範圍取決於租用戶政策、授權、裝置與使用情境。

方法	適合情境	注意事項
通行金鑰／FIDO2	抗網路釣魚的無密碼登入	需規劃註冊、備援與復原流程
Windows Hello 企業版	受管理 Windows 裝置	與裝置註冊及組織政策相關
Microsoft Authenticator	MFA、無密碼與部分 SSPR 情境	換機前要準備替代登入方法
簡訊或語音	過渡或備援情境	安全強度通常低於抗釣魚方法
Temporary Access Pass	新進人員或遺失主要憑證時的引導	應限制有效時間與用途

MFA 與 SSPR 各自解決什麼問題？

多重要素驗證（MFA）

MFA 要求使用者在登入時提供兩種以上不同類型的證明，降低單一密碼外洩造成的風險。組織不應只對少數管理員臨時開啟 MFA，而應搭配條件式存取與緊急存取帳戶，分階段測試及部署。

自助式密碼重設（SSPR）

SSPR 讓符合政策的使用者自行重設或解除鎖定帳戶，減少服務台負擔。管理者必須先啟用可用的驗證方法，使用者也要完成註冊。建議每位使用者準備多種方法，以免手機遺失或單一方法不可用時無法復原帳戶。

Microsoft 已將「驗證方法原則」列為管理驗證方式的建議路徑；舊式 MFA 與 SSPR 方法政策已不應再作為新部署的主要管理方式。

條件式存取如何保護登入？

條件式存取可以理解成「如果符合某些條件，就要求特定控制」的政策引擎。它會整合使用者或群組、裝置狀態、位置、應用程式、登入風險等訊號，再決定允許、封鎖或要求 MFA、合規裝置等控制。

政策設定錯誤可能讓管理員或整個組織無法登入。正式啟用前應先使用僅報告模式、排除緊急存取帳戶、限定測試群組，並檢查登入記錄。不要一開始就對所有人套用未測試的封鎖政策。

開發者如何把應用程式接到 Entra ID？

要讓 Web、SPA、行動應用程式、桌面程式或 API 使用 Microsoft 身分識別平台，通常先在 Entra 系統管理中心建立「應用程式註冊」。你會取得應用程式（用戶端）識別碼，並設定重新導向 URI、支援的帳戶類型與所需 API 權限。

Microsoft 身分識別平台以 OAuth 2.0 與 OpenID Connect 為基礎。一般登入使用 OIDC；呼叫 API 則由 OAuth 2.0 授權流程取得 Access Token。實作時應優先使用 Microsoft Authentication Library（MSAL）或受支援的框架，不要自行拼接完整驗證流程或手寫權杖驗證。

常見整合步驟

決定是單一租用戶、多租用戶，還是也允許個人 Microsoft 帳戶。
建立應用程式註冊並記錄 Client ID 與 Tenant ID。
為實際環境設定精確的 Redirect URI，不使用過寬的萬用網址。
依最小權限原則設定委派權限或應用程式權限。
使用 MSAL 完成登入與權杖取得。
在伺服器端驗證權杖的簽章、簽發者、對象與有效期限。
分離開發、測試與正式環境的應用程式註冊與憑證。

App Service 與 Azure Functions 可以少寫一些驗證程式嗎？

Azure App Service 與 Azure Functions 提供內建驗證與授權功能，常被稱為 Easy Auth。它可以在要求進入應用程式前處理身分提供者登入、權杖驗證、工作階段及身分標頭，適合需要快速加入登入保護的 Web 應用程式或 API。

但內建驗證不等於完整的業務授權。你的應用程式仍可能需要根據角色、群組、權限或資源擁有者作出存取決策。網站與 API 對未驗證要求的處理方式也不同：網站常用重新導向，API 通常應回傳 401，而不是把所有情境都套用同一設定。

服務對服務存取，為什麼應優先考慮受控識別？

Azure 資源的受控識別（Managed Identity）能讓虛擬機器、App Service、Functions 或其他支援的工作負載取得 Entra 權杖，而不必在程式碼或設定檔保存密碼、存取金鑰與用戶端秘密。存取下游服務時，再透過 Azure RBAC 或服務本身的權限模型授權。

系統指派身分與資源共用生命週期；使用者指派身分則是獨立資源，可配置給多個工作負載。選擇時要考慮生命週期、權限邊界、重複使用與部署流程，而不是只看哪一種建立最快。

Entra ID 導入檢查清單

盤點使用者、裝置、應用程式與非人類工作負載身分。
建立至少兩個受嚴格保護的緊急存取帳戶。
將驗證方法集中到 Authentication methods policy 管理。
優先規劃抗網路釣魚的通行金鑰、FIDO2 或 Windows Hello。
先以測試群組與僅報告模式驗證條件式存取。
為 SSPR 準備兩種以上可行的復原方法。
應用程式權限遵循最小權限，定期移除不用的同意與憑證。
Azure 工作負載優先使用受控識別，避免長期秘密寫入程式碼。
持續檢查登入記錄、風險事件與稽核記錄。

常見問題

Azure AD 停用了嗎？

沒有。Azure AD 是 Microsoft Entra ID 的舊名稱；既有部署與整合仍可運作。文件、入口網站和產品介面會逐步使用新名稱。

Entra ID 等同 Windows Server Active Directory 嗎？

不等同。兩者可在混合身分架構中協作，但通訊協定、管理模式與使用場景不同。Entra ID 不是把網域控制站直接搬到雲端。

啟用 MFA 就不需要條件式存取嗎？

兩者角色不同。MFA 是驗證控制；條件式存取則根據登入情境決定何時要求 MFA、合規裝置或封鎖存取。成熟部署通常會搭配使用。

應用程式可以把 Client Secret 放在原始碼嗎？

不建議。優先使用受控識別或工作負載身分同盟；若情境確實需要秘密或憑證，也應存放在安全的祕密管理服務並規劃輪替，不能提交到版本控制。

總結

理解 Microsoft Entra ID 的關鍵不是記住所有選單，而是把「誰正在存取、要存取什麼、根據哪些訊號、需要哪些控制」分開思考。管理端可從驗證方法、MFA、SSPR 與條件式存取建立基礎；開發端則應正確使用應用程式註冊、OAuth 2.0、OpenID Connect、MSAL 與受控識別，避免自行處理不必要的驗證細節與長期秘密。