規劃您的 Microsoft Entra 驗證識別碼 驗證解決方案

Microsoft Microsoft Entra 驗證識別碼 （Microsoft Entra VC） 服務可讓您信任使用者身分識別證明，而不需要擴充您的信任界限。 使用 Microsoft Entra VC，您可以建立帳戶或與其他識別提供者同盟。 當解決方案使用可驗證的認證實作驗證交換時，它可讓應用程式要求未繫結至特定網域的認證。 這種方法可讓您更輕鬆地大規模要求和驗證認證。

如果您尚未這麼做，建議您檢閱 Microsoft Entra 驗證識別碼 架構概觀。 您也想要檢閱規劃您的 Microsoft Entra 驗證識別碼 發行解決方案。

指引範圍

此內容涵蓋使用 Microsoft 產品和服務規劃可驗證認證驗證解決方案的技術層面。 解決方案會與信任系統介面，其中目前支援 DID Web。 DID Web 是集中式公鑰基礎結構。

不支援驗證解決方案專屬的技術不在範圍內。 例如，網站會用於可驗證的認證驗證解決方案中，但規劃網站部署並未詳細說明。

當您規劃驗證解決方案時，必須考慮要新增或修改哪些商務功能。 您也必須考慮可以重複使用哪些IT功能，以及必須新增哪些功能來建立解決方案。 也請考慮參與商務程序的人員以及支援解決方案用戶和人員所需的培訓。 此內容未涵蓋這些文章。 建議您檢閱 Microsoft Azure 架構完善的架構 ，以取得涵蓋這些文章的資訊。

解決方案的元件

作為驗證解決方案計劃的一部分，您必須啟用驗證者、主體和簽發者之間的互動。 在本文中，信賴憑證者和驗證者會交替使用條款。 下圖顯示驗證架構的元件。

Microsoft Entra 驗證識別碼 服務

在驗證器解決方案的內容中，Microsoft Entra 驗證識別碼 服務是解決方案與信任系統之 Microsoft 元件之間的介面。 服務會將金鑰集佈建為 金鑰保存庫，並佈建分散式標識碼 （DID）。

Microsoft Entra 租使用者

此服務需要一個 Microsoft Entra 租使用者，可為屬於解決方案一部分的 Azure 資源提供身分識別和存取管理 （IAM） 控制平面。 每個 Microsoft Entra 租用戶都會使用多租使用者 Microsoft Entra 驗證識別碼 服務，併發出代表驗證程式的單一 DID 檔。 如果您有多個信賴憑證者使用您的驗證服務，它們全都會使用相同的驗證程式 DID。 驗證程式 DID 提供公鑰的指標，可讓主體和簽發者驗證來自信賴憑證者的訊息。

Azure Key Vault

Azure 金鑰保存庫 服務會儲存驗證器密鑰，當您啟用 Microsoft Entra 驗證識別碼 發行服務時，就會產生這些密鑰。 金鑰是用來提供訊息安全性。 每個驗證器都有一個用於簽署、更新和復原 VM 的單一密鑰集。 每次服務驗證要求時，都會使用此金鑰集。 Microsoft 金鑰集目前使用橢圓曲線密碼編譯 （ECC） SECP256k1。 我們正在探索更廣泛的 DID 社群採用的其他密碼編譯簽章架構。

要求服務 API

應用程式開發介面 （API） 提供開發人員一種方法，以抽象化解決方案元件之間的互動，以執行驗證作業。

信任系統

Microsoft Entra 驗證識別碼 目前支援DID Web 作為信任系統，其中 DID 檔案裝載於簽發者 Web 伺服器上。

Microsoft Authenticator 應用程式

Microsoft Authenticator 是行動應用程式。 Authenticator 會協調使用者、Microsoft Entra 驗證識別碼 服務和用來發出 VC 的合約之間的互動。 它作為數位錢包，VC 的持有者將 VC 儲存在其中，包括 VC 主體的私鑰。 驗證器也是用來呈現用於驗證之 VM 的機制。

信賴憑證者 (RP)

Web 前端

信賴憑證者 Web 前端會使用要求服務 API，藉由產生主體錢包所取用的深層連結或 QR 代碼來驗證 VM。 視案例而定，前端可以是可公開存取或內部網站，以啟用需要驗證的終端用戶體驗。 不過，錢包存取的端點必須可公開存取。 具體而言，它會控制使用特定要求參數重新導向至錢包。

商務規則

您可以建立新的邏輯，或使用信賴憑證者特有的現有邏輯，並使用 VCS 的呈現來增強該邏輯。

案例特定設計

以下是滿足特定使用案例的設計範例。 第一個是用於帳戶上線，用來減少與上線新員工相關聯的時間、成本和風險。 第二個是帳戶復原，可讓使用者使用自助機制復原或解除鎖定其帳戶。 第三個是存取高價值應用程式和資源，特別是針對企業對企業使用案例，將存取權提供給其他公司工作的人員。

帳戶上線

可驗證的認證可用來藉由取代某些人為互動來加快上線速度。 VCS 可用來將員工、學生、公民或其他人員上線，以存取服務。 例如，與其員工需要前往中央辦公室來啟用員工徽章，他們可以使用 VC 來驗證其身分識別，以啟用從遠端傳遞給他們的徽章。 與其是公民收到代碼，他們必須兌換才能獲得政府服務，而是可以使用 VC 來證明自己的身份並取得存取權。

其他元素

上架入口網站：一個 Web 前端，可協調要求服務 API 呼叫 VC 簡報和驗證，以及讓帳戶上線的邏輯。

自定義邏輯/工作流程：在更新用戶帳戶之前和之後，具有組織特定步驟的特定邏輯。 範例可能包括核准工作流程、其他驗證、記錄、通知等等。

目標身分識別系統：上線入口網站在上架主旨時需要與其互動的組織特定身分識別存放庫。 要整合的系統會根據您想要上線的 VC 驗證身分識別類型來決定。 上線的身分識別驗證常見案例包括：

• Microsoft Entra ID 上線的外部身分識別，使用 API 發出企業對企業（B2B）邀請，或將權利管理指派指派給套件。

• 在集中式身分識別系統中的員工身分識別已經透過人力資源 （HR） 系統上線。 在此情況下，身分識別驗證可能會整合為 HR 工作流程現有階段的一部分。

設計考量

• 簽發者：帳戶上線很適合外部身分識別證明服務作為 VCS 的簽發者。 上線檢查的範例包括：活躍度檢查、政府核發的文件驗證、位址或電話號碼確認等等。

• 儲存 VC 屬性：可能的話，請勿將來自 VCS 的屬性儲存在應用程式特定存放區中。 特別小心個人資料。 如果應用程式內的特定流程需要這項資訊，請考慮要求 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 資源的受控識別。

存取組織內的高價值應用程式

可驗證的認證可用來做為存取組織內敏感性應用程式的其他證明。 例如，VCS 也可用來根據達到特定準則，提供員工存取企業營運應用程式的存取權，例如認證。

其他元素

信賴憑證者 Web 前端：這是透過要求服務 API 呼叫 VC 簡報和驗證，根據您的業務需求增強的應用程式 Web 前端。

使用者存取授權邏輯：應用程式中授權使用者存取的邏輯層，並增強為取用 VC 內的使用者屬性來進行授權決策。

其他後端服務和相依性：代表應用程式的其餘邏輯，通常透過 VCS 包含身分識別證明來變更。

設計考量

• 目標：案例的目標會決定所需的認證和簽發者類型。 一般案例包括：

  • 授權：在此案例中，用戶會顯示 VC 來進行授權決策。 專為完成定型或持有特定認證而設計的 VCS 適合此案例。 VC 屬性應包含有利於授權決策和稽核的精細資訊。 例如，VC 用來認證個人經過訓練，而且可以存取敏感的財務應用程式。 應用程式邏輯可以檢查部門宣告是否有細微的授權，並使用員工標識符進行稽核。

  • 確認身分識別驗證：在此案例中，目標是確認一開始上線的相同人員確實是嘗試存取高價值應用程式的人員。 身分識別驗證簽發者的認證會很適合。 應用程式邏輯應該驗證來自 VC 的屬性是否與登入應用程式的使用者一致。

• 檢查撤銷：使用 VCS 存取敏感性資源時，通常會檢查 VC 與原始簽發者的狀態，並拒絕撤銷之 VM 的存取。 使用簽發者時，請確定在案例的設計中明確討論撤銷。

• 用戶體驗：使用 VM 存取敏感性資源時，您可以考慮兩種模式。

  • 逐步驗證：用戶以現有的驗證機制啟動應用程式會話。 用戶必須在應用程式內提供特定高價值作業的 VC，例如商務工作流程的核准。 這很適合這類高價值作業很容易在應用程式流程內識別和更新的案例。

  • 工作階段建立：用戶必須將 VC 呈現為起始應用程式工作階段的一部分。 當整個應用程式的本質是高價值時，呈現 VC 會很合適。

存取組織界限以外的應用程式

可驗證的認證也可以由想要根據不同組織的成員資格或僱用關係授與存取權或權益的信賴憑證者使用。 例如，電子商務入口網站可以為特定公司的員工、指定機構的學生等提供折扣等權益。

可驗證認證的分散式本質可啟用此案例，而不需要建立同盟關聯性。

其他元素

信賴憑證者 Web 前端：這是透過要求服務 API 呼叫 VC 簡報和驗證，根據您的業務需求增強的應用程式 Web 前端。

使用者存取授權邏輯：應用程式中授權使用者存取的邏輯層，並增強為取用 VC 內的使用者屬性來進行授權決策。

其他後端服務和相依性：代表應用程式的其餘邏輯，通常透過 VCS 包含身分識別證明來變更。

設計考量

• 目標：案例的目標會決定所需的認證和簽發者類型。 一般案例包括：

  • 驗證：在此案例中，用戶必須擁有 VC 才能證明與特定組織的雇用或關係。 在此情況下，應將 RP 設定為接受目標組織所發出的 VCS。

  • 授權：根據應用程式需求，應用程式可能會取用 VC 屬性，以進行更細緻的授權決策和稽核。 例如，如果電子商務網站針對特定位置的組織員工提供折扣，他們可以根據 VC 中的國家/地區宣告來驗證折扣資格（如果有的話）。

• 檢查撤銷：使用 VCS 存取敏感性資源時，通常會檢查 VC 與原始簽發者的狀態，並拒絕撤銷之 VM 的存取。 使用簽發者時，請確定在案例的設計中明確討論撤銷。

• 用戶體驗：用戶可以將 VC 呈現為使用應用程式起始會話的一部分。 一般而言，應用程式也會提供替代方法來啟動會話，以因應用戶沒有DC的情況。

帳戶復原

可驗證的認證可用來作為帳戶復原的方法。 例如，當使用者需要復原其帳戶時，他們可能會存取要求他們呈現 VC 的網站，並藉由呼叫 MS Graph API 來起始 Microsoft Entra 認證重設，如下圖所示。

注意

雖然本節所述的案例是復原 Microsoft Entra 帳戶的特定案例，但此方法也可用來復原其他系統中的帳戶。

其他元素

帳戶入口網站：協調 VC 簡報和驗證 API 呼叫的 Web 前端。 此協調流程可以包含 Microsoft Graph 呼叫，以復原 Microsoft Entra 識別碼中的帳戶。

自定義邏輯或工作流程：更新用戶帳戶之前和之後，具有組織特定步驟的邏輯。 自定義邏輯可能包含核准工作流程、其他驗證、記錄、通知等。

Microsoft Graph：公開表示狀態傳輸 （REST） API 和用戶端連結庫，以存取用來執行帳戶復原的 Microsoft Entra 數據。

Microsoft Entra 企業目錄：Microsoft Entra 租使用者，其中包含正透過帳戶入口網站建立或更新的帳戶。

設計考量

VC 屬性與 Microsoft Entra 識別元相互關聯：在與簽發者共同定義 VC 的屬性時，請確定您已同意識別使用者的宣告。 例如，如果身分識別驗證提供者 （IDV） 在上線員工之前驗證身分識別，請確定已核發的 VC 包含可比對內部系統的宣告。 這類索賠可能是電話號碼、位址或出生日期。 RP 可以在此程式中要求在 VC 中找不到的資訊，例如其社會安全號碼的最後四位數（SSN）。

具有現有 Microsoft Entra 認證重設功能的 VM 角色：Microsoft Entra ID 具有內建的自助式密碼重設 （SSPR） 功能。 在使用者無法存取或失去 SSPR 方法控制權的情況下，可以使用可驗證的認證來提供另一種復原方式。 在用戶同時遺失計算機和行動裝置的情況下，使用者可以從身分識別證明簽發者重新擷取 VC，並呈現它從遠端復原其帳戶。

同樣地，您可以使用 VC 來產生暫時存取傳遞，讓使用者在沒有密碼的情況下重設其 MFA 驗證方法。

授權：建立授權機制，例如 RP 先檢查的安全組，再繼續進行認證復原。 例如，只有特定群組中的使用者才有資格復原具有 VC 的帳戶。

與 Microsoft Entra 識別符互動：Web 前端與 Microsoft Entra ID 之間的服務對服務通訊必須以高度特殊許可權的系統保護，因為它可以重設員工的認證。 將可能的最低特殊許可權角色授與 Web 前端。 這些範例包含：

• 授與 RP 網站使用已授與 MS Graph 範圍 UserAuthenticationMethod.ReadWrite.All 的服務主體重設驗證方法的能力。 請勿授 User.ReadWrite.All與 ，這可讓您建立和刪除使用者。

• 如果您的 RP 正在 Azure 中執行，請使用受控識別來呼叫 Microsoft Graph。 受控識別會移除程式代碼或組態檔中管理服務主體認證的風險。 如需詳細資訊，請參閱 Azure 資源的受控識別。

規劃身分識別管理

以下是將 VCS 併入信賴憑證者時的 IAM 考慮。 信賴憑證者通常是應用程式。

驗證

• VC 的主題必須是人類。

• 一個人在錢包里有 VC，必須以互動方式呈現 VC。 不支援非互動式流程，例如代理者。

授權

• 成功呈現 VC 可以單獨視為粗略授權閘道。 VC 屬性也可以用於精細的授權決策。

• 判斷過期的 VC 是否在您的應用程式中具有意義;如果是，請檢查 VC 的宣告值 exp （到期時間）作為授權檢查的一部分。 其中一個與到期無關的範例是要求政府發行的檔，例如駕駛執照，以驗證主體是否早於 18。 出生日期宣告有效，即使 VC 已過期也一樣。

• 判斷撤銷的 VC 是否對您的授權決策有意義。

  • 如果它不相關，請略過檢查狀態 API 的呼叫（預設為開啟）。

  • 如果相關，請在應用程式中新增適當的例外狀況處理。

使用者設定檔

您可以使用所呈現的 DC 中的資訊來建置使用者設定檔。 如果您要取用屬性來建置配置檔，請考慮下列專案。

• 發出 VC 時，它會包含發行時的屬性快照集。 VCS 可能會有很長的有效期間，而且您必須判斷屬性的存留期，而您將接受的屬性存留期足以作為配置檔的一部分使用。

• 如果每次主旨開始與 RP 工作階段時都必須顯示 VC，請考慮使用 VC 簡報的輸出來建置具有 屬性的非持續性使用者配置檔。 非持續性使用者配置檔有助於降低與儲存待用使用者屬性相關聯的隱私權風險。 您的應用程式可能需要在本機儲存主旨的屬性。 如果是，則只會儲存應用程式所需的宣告。 請勿儲存整個 VC。

• 如果應用程式需要持續性使用者設定檔存放區：

  • 請考慮使用 sub 宣告作為使用者不可變的標識碼。 這是特定主旨/RP 配對的不透明唯一屬性。

  • 定義從應用程式取消布建使用者配置檔的機制。 由於 Microsoft Entra 驗證識別碼 系統的分散本質，因此沒有應用程式使用者布建生命週期。

  • 請勿儲存在 VC 令牌中傳回的個人資料宣告。

  • 只有儲存信賴憑證者邏輯所需的宣告。

規劃效能

如同任何解決方案，您必須規劃效能。 焦點區域包括延遲、輸送量和延展性。 在發行週期的初始階段，效能不應該是問題。 不過，當採用您的解決方案會導致許多可驗證的認證經過驗證時，效能規劃可能會成為解決方案的重要部分。

下列專案提供規劃效能時要考慮的領域：

• Microsoft Entra 驗證識別碼 發行服務部署於西歐、北歐、美國西部 2 和美國中西部 Azure 區域。 若要限制延遲，請在最接近的區域部署您的驗證前端（網站）和密鑰保存庫。

• 以輸送量為基礎的模型：

  • VC 驗證容量受限於 Azure 金鑰保存庫 服務限制。

  • VC 的每個驗證都需要一個 金鑰保存庫 簽章作業。

  • 您無法控制節流;不過，建議您閱讀 Azure 金鑰保存庫 節流指引，以了解節流如何影響效能。

規劃可靠性

若要針對高可用性和災害復原進行最佳規劃，我們建議下列專案：

• Microsoft Entra 驗證識別碼 服務部署在西歐、北歐、美國西部 2 和美國中西部、澳大利亞和日本 Azure 區域。 請考慮在其中一個區域中部署您支援的 Web 伺服器和支援應用程式，特別是您預期大部分驗證流量的來源區域。

• 當您針對可用性和備援目標進行設計時，請檢閱並納入 Azure 金鑰保存庫 可用性和備援的最佳做法。

規劃安全性

當您設計安全性時，請考慮下列事項：

• 單一租使用者中的所有信賴憑證者都具有相同的信任界限，因為它們共用相同的 DID。

• 定義存取 金鑰保存庫 之網站的專用服務主體。

• 只有 Microsoft Entra 驗證識別碼 服務和網站服務主體才有權使用 金鑰保存庫 使用私鑰簽署訊息。

• 請勿將任何人類身分識別系統管理許可權指派給 金鑰保存庫。 如需 金鑰保存庫 最佳做法的詳細資訊，請參閱適用於 金鑰保存庫 的 Azure 安全性基準。

• 請參閱 使用 Microsoft Entra ID 保護 Azure 環境，以取得管理解決方案支援服務的最佳作法。

• 藉由：

  • 實作 DNS 驗證，以協助客戶識別簽發者商標。

  • 使用對用戶有意義的網域。

• 降低分散式阻斷服務 （DDOS） 和 金鑰保存庫 資源節流風險。 每個 VC 簡報要求都會產生 金鑰保存庫 簽署作業，以累積至服務限制。 建議您先納入替代驗證或 captcha，再產生發行要求，以保護流量。

規劃作業

當您規劃作業時，建議您規劃在稽核時擷取認證驗證的每個嘗試。 使用該信息進行稽核和疑難解答。 此外，請考慮產生客戶和支援工程師可視需要參考的唯一交易標識碼（標識符）。

在作業規劃中，請考慮監視下列專案：

• 如需延展性：

  • 在應用程式的端對端安全性計量中，監視失敗的 VC 驗證。

  • 監視認證驗證的端對端延遲。

• 針對可靠性和相依性：

  • 監視驗證解決方案所使用的基礎相依性。

  • 請遵循 Azure 金鑰保存庫 監視和警示。

• 基於安全性：

  • 啟用 金鑰保存庫 記錄以追蹤簽署作業，以及監視和警示組態變更。 如需詳細資訊，請參閱如何啟用 金鑰保存庫 記錄。

  • 在安全性資訊和事件管理 （SIEM） 系統中封存記錄，例如 長期保留的 Microsoft Sentinel 。

下一步

深入了解架構 VC 解決方案

• Microsoft Entra 驗證識別碼 概觀

• 規劃您的 Microsoft Entra 驗證識別碼 發行解決方案

實作可驗證的認證

• Microsoft Entra 已驗證識別碼的簡介

• 開始使用可驗證的認證

常見問題集