規劃 Microsoft Entra 已驗證的識別碼驗證解決方案
Microsoft 的 Microsoft Entra 驗證識別碼 (Microsoft Entra VC) 服務可讓您信任使用者身分識別的證明，而不需要擴展信任界限。 使用 Microsoft Entra VC，您會建立帳戶或與另一個識別提供者建立同盟。 解決方案使用可驗認證來實作驗證交換時，可讓應用程式要求未繫結至特定網域的認證。 這種方法可讓您更輕鬆地大規模要求和驗證認證。
如果您尚未這麼做，則建議您檢閱 Microsoft Entra 已驗證的識別碼架構概觀。 您也可以檢閱規劃 Microsoft Entra 驗證識別碼核發解決方案。
本指南的涵蓋範圍
此內容涵蓋使用 Microsoft 產品和服務規劃可驗認證之驗證解決方案的技術層面。 解決方案會與信任系統相互作用，其中目前支援 DID Web。 DID Web 是集中式公開金鑰基礎結構。
不屬於驗證解決方案的支援技術則不在涵蓋範圍內。 例如，可驗認證驗證解決方案中會使用網站，但不會詳細討論如何規劃網站部署。
當您規劃驗證解決方案時，必須考慮要新增或修改哪些商務功能。 您也必須考慮可以重複使用哪些 IT 功能，以及必須新增哪些功能才能建立解決方案。 另請考慮必須為涉及商務程序的人員，以及為解決方案終端使用者和員工的支援人員提供哪些訓練。 這些文章都不在此內容的涵蓋範圍內。 建議您檢閱 Microsoft Azure Well-Architected Framework，以取得涵蓋這些文章的資訊。
解決方案的組成部分
在規劃驗證解決方案的過程中，您必須啟用驗證器、主體和簽發者之間的互動。 在本文中，會交替使用「信賴憑證者」與「驗證器」這兩個詞彙。 下圖顯示驗證架構的元件。
Microsoft Entra 已驗證的識別碼服務
在驗證器解決方案的內容中，Microsoft Entra 已驗證的識別碼服務是解決方案的 Microsoft 元件與信任系統之間的介面。 此服務會將金鑰組佈建至 Key Vault，以及佈建分散式識別碼 (DID)。
Microsoft Entra 租使用者
此服務需要 Microsoft Entra 租用戶，以針對屬於解決方案一部分的 Azure 資源，提供身分識別與存取權管理 (IAM) 控制平面。 每個 Microsoft Entra 租用戶都會使用多租用戶 Microsoft Entra 驗證識別碼服務，並且核發可代表驗證器的單一 DID 文件。 如果您有多個信賴憑證者使用您的驗證服務，則全部都會使用相同的驗證器 DID。 驗證器 DID 會提供公開金鑰的指標，讓主體和簽發者驗證來自信賴憑證者的訊息。
Azure Key Vault
Azure Key Vault 服務會儲存您的驗證器金鑰，而此金鑰是在您啟用 Microsoft Entra 已驗證的識別碼核發服務時產生。 此金鑰是用來提供訊息安全性。 每個驗證器都有一組用於簽署、更新和復原 VC 的金鑰。 每次您提供驗證要求服務時，就會使用此金鑰組。 Microsoft 金鑰組目前使用橢圓曲線密碼編譯 (ECC) SECP256k1。 我們正在探索更廣泛 DID 社群未來將採用的其他密碼編譯簽章架構。
要求服務 API
應用程式開發介面 (API) 為開發人員提供一種方法，可將解決方案元件之間的互動抽象化，以執行驗證作業。
信任系統
Microsoft Entra 驗證識別碼目前支援 DID Web 作為信任系統，其中 DID 文件託管於簽發者 Web 伺服器上。
Microsoft Authenticator 應用程式
Microsoft Authenticator 是行動應用程式。 Authenticator 會協調使用者、Microsoft Entra 驗證識別碼服務和用來發出 VC 的合約之間的互動。 作用為數位錢包，VC 持有者可以將其 VC (包括 VC 主體的私密金鑰) 儲存在其中。 Authenticator 也是用來出示 VC 以進行驗證的機制。
信賴憑證者 (RP)
Web 前端
信賴憑證者 Web 前端使用要求服務 API 來驗證 VC，做法是產生深層連結或 QR 代碼，以供主體的電子錢包使用。 視案例而定，前端可以是可公開存取或內部網站，以實現需要驗證的終端使用者體驗。 不過，電子錢包存取的端點必須可公開存取。 具體而言，它會使用特定的要求參數來控制重新導向至電子錢包。
商務規則
您可以建立新的邏輯，或使用信賴憑證者特定的現有邏輯，並透過 VC 的出示來增強該邏輯。
案例特定設計
以下是滿足特定使用案例的設計範例。 第一個是帳戶上線，用來降低與新員工上線相關聯的時間、成本和風險。 第二個是帳戶復原，可讓終端使用者使用自助機制來復原或解除鎖定其帳戶。 第三個是存取高價值應用程式和資源，特別是企業對企業使用案例，在這些案例中，會將存取權授與任職其他公司的人員。
帳戶上線
可驗認證可以用來取代一些人為互動，以加速上線。 VC 可用來將員工、學生、公民或其他人上線以存取服務。 例如，員工可以使用 VC 驗證身分來啟用從遠端傳遞給他們的徽章，而不需要前往中央辦公室來啟用員工徽章。 而公民可以使用 VC 證明身分並取得存取權，而不是必須收到兌換碼才能存取政府服務。
其他元素
上線入口網站：一種 Web 前端，可協調要求服務 API 呼叫以進行 VC 出示和驗證，以及可將帳戶上線的邏輯。
自訂邏輯/工作流程：在更新使用者帳戶前後，具有組織特定步驟的特定邏輯。 範例可能包括核准工作流程、其他驗證、記錄、通知等。
目標身分識別系統：上線入口網站在將主體上線時必須與之互動的組織特定身分識別存放庫。 要整合的系統取決於您想要使用 VC 驗證上線的身分識別類型。 上線身分識別驗證的常見案例包括：
Microsoft Entra ID 的外部身分識別會使用 API 上線，以發出企業對企業 (B2B) 邀請或套件的權利管理指派。
員工身分識別，位於已透過人力資源 (HR) 系統上線的集中式身分識別系統中。 在此情況下，身分識別驗證可能會整合為 HR 工作流程現有階段的一部分。
設計考量
簽發者：帳戶上線適合作為 VC 簽發者的外部身分識別證明服務。 上線檢查範例包括：活躍度檢查、政府核發的文件驗證、地址或電話號碼確認等。
儲存 VC 屬性：如果可能的話，請勿將 VC 的屬性儲存在應用程式特定存放區中。 請特別小心處理個人資料。 如果應用程式中的特定流程需要這項資訊，建議您要求 VC 依需求擷取宣告。
VC 屬性與後端系統的相互關聯：與簽發者定義 VC 的屬性時，請建立一個機制，在使用者出示 VC 之後，將後端系統中的資訊相互關聯。 此機制通常會在 RP 的內容中，搭配您收到的宣告使用具有時限的唯一識別碼。 一些範例：
新員工：當 HR 工作流程到達需要身分識別證明的點時，RP 可以產生具有時限的唯一識別碼連結。 然後 RP 會將其傳送至 HR 系統上的應徵者電子郵件地址。 此唯一識別碼應該足以將 VC 驗證要求中的資訊 (例如 firstName、lastName) 與 HR 記錄或基礎資料相互關聯。 VC 中的屬性可用來完成 HR 系統中的使用者屬性，或驗證員工相關使用者屬性的正確性。
外部身分識別 - 邀請：若外部使用者受邀加入目標系統，RP 可以產生代表邀請交易的唯一識別碼的連結。 此連結可以傳送至外部使用者的電子郵件位址。 此唯一識別碼應該足以將 VC 驗證要求與邀請記錄或基礎資料相互關聯，並繼續佈建工作流程。 VC 中的屬性可用來驗證或完成外部使用者屬性。
外部身分識別 - 自助：當外部身分識別透過自助 (例如 B2C 應用程式) 註冊到目標系統時，可以使用 VC 中的屬性來填入使用者帳戶的初始屬性。 VC 屬性也可用來查明設定檔是否已存在。
與目標身分識別系統的互動：Web 前端與您目標身分識別系統之間的服務對服務通訊，由於可能會建立帳戶，因此必須當作具有高權限的系統加以保護。 請盡可能將最低權限角色授與 Web 前端。 這些範例包含：
若要在 Microsoft Entra ID 中建立新的使用者，RP 網站可使用已授與 MS Graph 範圍
User.ReadWrite.All的服務主體來建立使用者，並使用已授與範圍UserAuthenticationMethod.ReadWrite.All的服務主體來重設其驗證方法。若要使用 B2B 共同作業邀請使用者加入 Microsoft Entra ID，RP 網站可使用已授與 MS Graph 範圍
User.Invite.All的服務主體來建立邀請。如果您的 RP 正在 Azure 中執行，請使用受控識別來呼叫 Microsoft Graph。 使用受控身分識別可移除在程式碼或設定檔中管理服務主體認證的風險。 若要深入了解受控識別，請前往 Azure 資源受控識別。
存取組織內的高價值應用程式
可驗認證可作為存取組織內敏感性應用程式的其他證明。 例如，VC 也可根據是否達成特定準則 (例如認證)，來允許員工存取企業營運應用程式。
其他元素
信賴憑證者 Web 前端：這是應用程式的 Web 前端，已根據您的商務需求並透過要求服務 API 呼叫予以增強，以進行 VC 出示和驗證。
使用者存取授權邏輯：應用程式中的邏輯層會授權使用者存取，並經過增強，能夠使用 VC 中的使用者屬性來做出授權決策。
其他後端服務和相依性：代表應用程式邏輯的其餘部分，通常不會因包含透過 VC 的身分識別證明而有所改變。
設計考量
目標：案例的目標決定所需的認證和簽發者類型。 一般案例包括：
授權：在此案例中，使用者會出示 VC 來制定授權決策。 專為證明是否完成訓練或持有特定認證而設計的 VC 即適合此案例。 VC 屬性應該包含有助於授權決策和稽核的精細資訊。 例如，VC 用來認證個人經過訓練，而且可以存取敏感的財務應用程式。 應用程式邏輯可以檢查部門宣告是否有細微的授權，並使用員工識別碼進行稽核。
確認身分識別驗證：在此案例中，目標是要確認一開始上線的同一人確實是嘗試存取高價值應用程式的人員。 來自身分識別驗證簽發者的認證會很適合。 應用程式邏輯應該驗證來自 VC 的屬性是否與登入應用程式的使用者相符。
檢查撤銷：使用 VC 存取敏感性資源時，通常會向原始簽發者確認 VC 的狀態，並拒絕已撤銷 VC 的存取權。 與簽發者合作時，請確定在設計案例的過程中已明確討論撤銷。
使用者體驗：使用 VC 存取敏感性資源時，有兩種模式可供考慮。
逐步驗證：使用者使用現有的驗證機制來啟動應用程式的工作階段。 使用者必須針對應用程式中的特定高價值作業 (例如商務工作流程的核准) 出示 VC。 這適用於能夠在應用程式流程中輕鬆發現和更新這類高價值作業的情況。
工作階段建立：使用者必須在起始應用程式工作階段的過程中出示 VC。 出示 VC 適用於整個應用程式的本質是高價值的情況。
存取組織界限外部的應用程式
如果信賴憑證者想要根據不同組織的成員資格或雇用關係來授與存取權或權益，也可以使用可驗認證。 例如，電子商務入口網站可以提供權益 (例如折扣) 給特定公司的員工、特定機構的學生等。
可驗認證的分散式本質讓您不需要建立同盟關係，就能實現此案例。
其他元素
信賴憑證者 Web 前端：這是應用程式的 Web 前端，已根據您的商務需求並透過要求服務 API 呼叫予以增強，以進行 VC 出示和驗證。
使用者存取授權邏輯：應用程式中的邏輯層會授權使用者存取，並經過增強，能夠使用 VC 中的使用者屬性來做出授權決策。
其他後端服務和相依性：代表應用程式邏輯的其餘部分，通常不會因包含透過 VC 的身分識別證明而有所改變。
設計考量
目標：案例的目標決定所需的認證和簽發者類型。 一般案例包括：
驗證：在此案例中，使用者必須持有 VC，才能證明受雇於特定組織或與特定組織的關係。 在此情況下，RP 應該設定為接受目標群組織所發出的 VC。
授權：根據應用程式需求，應用程式可能會使用 VC 屬性來進行更細緻的授權決策和稽核。 例如，如果電子商務網站為特定地點的組織員工提供折扣，就能根據 VC 中的國家/地區宣告 (如果有) 來驗證折扣資格。
檢查撤銷：使用 VC 存取敏感性資源時，通常會向原始簽發者確認 VC 的狀態，並拒絕已撤銷 VC 的存取權。 與簽發者合作時，請確定在設計案例的過程中已明確討論撤銷。
使用者體驗：使用者可以在起始應用程式工作階段的過程中出示 VC。 一般而言，應用程式還會提供替代方法來啟動工作階段，以因應使用者沒有 VC 的情況。
帳戶復原
可驗認證可作為帳戶復原方法。 例如，使用者需要復原其帳戶時，他們可能會存取一個網站，該網站會要求他們出示 VC，然後藉由呼叫 MS Graph API 來起始 Microsoft Entra 認證重設，如下圖所示。
注意
雖然本節所述案例是復原 Microsoft Entra 帳戶的特定案例，但這種方法也可用來復原其他系統中的帳戶。
其他元素
帳戶入口網站：這是一種可協調 API 呼叫以進行 VC 出示和驗證的 Web 前端。 此協調流程可以包含在 Microsoft Entra ID 中復原帳戶的 Microsoft Graph 呼叫。
自訂邏輯或工作流程：在更新使用者帳戶前後，具有組織特定步驟的邏輯。 自訂邏輯可能包括核准工作流程、其他驗證、記錄、通知等。
Microsoft Graph：公開具象狀態傳輸 (REST) API 和用戶端程式庫，以存取用來執行帳戶復原的 Microsoft Entra 資料。
Microsoft Entra 企業目錄：這是 Microsoft Entra 租用戶，其中包含要透過帳戶入口網站建立或更新的帳戶。
設計考量
VC 屬性與 Microsoft Entra ID 的關聯：在與簽發者共同定義 VC 的屬性時，請務必在識別使用者的宣告達成共識。 例如，如果身分識別驗證提供者 (IDV) 在進行員工上線作業之前驗證身分識別，請確定已核發的 VC 包含可比對內部系統的宣告。 此類宣告可能是電話號碼、地址或出生日期。 RP 可能會在此流程中要求在 VC 找不到的資訊，例如其社會安全號碼 (SSN) 的最後四位數。
具有現有 Microsoft Entra 認證重設功能的 VC 角色：Microsoft Entra ID 具有內建的自助式密碼重設 (SSPR) 功能。 在使用者無法存取或失去 SSPR 方法控制權的情況下，可以使用可驗認證來提供另一種復原方式。 在使用者同時遺失電腦和行動裝置的情況下，使用者可以從身分識別證明簽發者重新取得 VC，並出示以從遠端復原其帳戶。
同樣地，您可以使用 VC 來產生臨時存取密碼，讓使用者重設其 MFA 驗證方法，而不需要密碼。
授權：建立安全性群組之類的授權機制，RP 必須先檢查才能繼續進行認證復原。 例如，只有特定群組中的使用者才有資格使用 VC 復原帳戶。
與 Microsoft Entra ID 的互動：Web 前端與 Microsoft Entra ID 之間的服務對服務通訊，由於可能會重設員工的認證，因此必須當作具有高權限的系統加以保護。 請盡可能將最低權限角色授與 Web 前端。 這些範例包含：
讓 RP 網站能夠使用已授與 MS Graph 範圍
UserAuthenticationMethod.ReadWrite.All的服務主體來重設驗證方法。 請勿授與能夠建立和刪除使用者的User.ReadWrite.All。如果您的 RP 正在 Azure 中執行，請使用受控識別來呼叫 Microsoft Graph。 受控身分識別可移除在程式碼或設定檔中管理服務主體認證的相關風險。 如需詳細資訊，請參閱適用於 Azure 資源的受控識別。
規劃身分識別管理
以下是將 VC 納入信賴憑證者時的一些 IAM 考量。 信賴憑證者通常是應用程式。
驗證
VC 的主體必須是人類。
一個人在電子錢包裡有 VC，必須以互動方式出示 VC。 不支援非互動式流程 (例如代理者)。
授權
VC 的成功出示本身可視為粗略的授權閘道。 您也可以使用 VC 屬性進行更細緻的授權決策。
判斷已過期的 VC 在您的應用程式中是否有意義；如果是，請檢查 VC 的
exp宣告值 (到期時間)，作為授權檢查的一部分。 與到期無關的其中一個範例，就是要求政府核發的文件 (例如駕照) 以驗證主體是否滿 18 歲。 出生日期是有效的，即使 VC 已過期也一樣。判斷已撤銷的 VC 對您的授權決策是否有意義。
如果無關，則略過檢查狀態 API 的呼叫 (預設為開啟)。
如果相關，請在您的應用程式中新增適當的例外狀況處理。
使用者設定檔
您可以使用所出示 VC 中的資訊來建立使用者設定檔。 若要使用屬性來建立設定檔，請考慮下列項目。
發出 VC 時，它會包含發行時屬性的快照集。 VC 可能會有很長的有效期間，因此您必須判斷屬性存在多久才算是夠新，而能作為設定檔的一部分。
如果每次主體啟動 RP 的工作階段都必須出示 VC，請考慮使用 VC 出示的輸出來建立具有屬性的非永續性使用者設定檔。 非永續性使用者設定檔有助於降低與儲存待用使用者屬性相關聯的隱私權風險。 您的應用程式可能需要在本機儲存主旨的屬性。 如果是，則請只儲存應用程式所需的宣告。 請勿儲存整個 VC。
如果應用程式需要永續性使用者設定檔存放區：
請考慮使用
sub宣告作為使用者的固定識別碼。 這是不透明的唯一屬性，對於指定的主體/RP 配對而言會固定不變。定義從應用程式取消佈建使用者設定檔的機制。 由於 Microsoft Entra 驗證識別碼系統的分散式本質，因此沒有應用程式使用者佈建生命週期。
請勿儲存在 VC 權杖中傳回的個人資料宣告。
只儲存信賴憑證者邏輯所需的宣告。
規劃效能
如同任何解決方案，您必須規劃效能。 重點領域包括延遲、輸送量和可擴展性。 在發行週期的初始階段期間，應該不需要在意效能。 然而，當採用解決方案會讓許多可驗認證通過驗證，效能的規劃可能會變成解決方案中最重要的部分。
以下項目提供規劃效能時需考慮的領域：
Microsoft Entra 已驗證的識別碼簽發服務已部署至西歐、北歐、美國西部 2 和美國中西部 Azure 區域。 若要限制延遲，請在最接近的區域部署您的驗證前端 (網站) 和金鑰保存庫。
以輸送量為基礎的模型：
VC 驗證容量必須遵守 Azure Key Vault 服務限制。
每次驗證 VC 都需要一個 Key Vault 簽章作業。
您無法控制節流；不過，我們建議您閱讀 Azure Key Vault 節流指引，以了解節流可能會對效能造成何種影響。
規劃可靠性
為了最妥善地規劃高可用性和災害復原，我們提出下列建議：
Microsoft Entra 驗證識別碼服務已部署至西歐、北歐、美國西部 2 和美國中西部、澳洲和日本 Azure 區域。 請考慮在其中一個區域中部署支援網頁伺服器和支援應用程式，特別是在大部分驗證流量預期來源的區域中。
當您針對可用性和備援目標設計時，請檢閱 Azure Key Vault 可用性與備援並納入最佳做法。
規劃安全性
針對安全性進行設計時，請考慮下列事項：
單一租用戶中的所有信賴憑證者 (RP) 由於共用相同的 DID，因此會有相同的信任界限。
為存取 Key Vault 的網站定義專用服務主體。
只有 Microsoft Entra 已驗證的識別碼服務和網站服務主體才應該具有使用 Key Vault 透過私密金鑰簽署訊息的權限。
請勿對 Key Vault 指派任何個人身分識別管理權限。 如需 Key Vault 最佳做法的詳細資訊，請參閱適用於 Key Vault 的 Azure 安全性基準。
如需為解決方案管理支援服務的最佳做法，請參閱使用 Microsoft Entra ID 保護 Azure 環境的安全 (英文)。
請利用下列方式降低詐騙風險：
實作 DNS 驗證以協助客戶識別簽發者商標。
使用對終端使用者有意義的網域。
降低分散式阻斷服務攻擊 (DDOS) 和 Key Vault 資源節流風險。 每個 VC 出示要求都會產生逐漸造成服務限制的 Key Vault 簽署作業。 建議您在產生發行要求之前納入替代驗證或 Captcha，以保護流量。
規劃作業
當您規劃作業時，建議規劃在稽核過程中擷取認證驗證的每個嘗試。 您可以使用該資訊進行稽核和疑難排解。 此外，請考慮產生客戶和支援工程師可以視需要參考的唯一交易識別碼 (ID)。
在作業規劃的過程中，請考慮監視下列各項：
可擴展性：
監視失敗的 VC 驗證，以作為應用程式端對端安全性計量的一部分。
監視認證驗證的端對端延遲。
可靠性和相依性：
監視驗證解決方案所使用的基礎相依性。
安全性：
啟用 Key Vault 的記錄以追蹤簽署作業，以及監視設定變更的警示。 如需詳細資訊，請參閱如何啟用 Key Vault 記錄。
在安全性資訊與事件管理 (SIEM) 系統 (例如 Microsoft Sentinel) 中封存記錄以供長期保留。
下一步
深入了解如何建構 VC 解決方案
實作可驗認證