分享方式：

規劃 Microsoft Entra 已驗證的識別碼核發解決方案

  • 文章

請務必規劃您的簽發解決方案，如此一來，除了簽發認證之外，您對於解決方案的架構和商務影響可以有完整的檢視。 如果您尚未這麼做，則建議您檢視 Microsoft Entra 已驗證的識別碼架構概觀，以了解基礎資訊。

本指南的涵蓋範圍

本文涵蓋規劃可驗認證核發解決方案的技術層面。 Microsoft 的可驗認證解決方案遵循 World Wide Web Consortium (W3C) 的 Verifiable Credentials Data Model 1.0 (可驗認證資料模型 1.0) 和 Decentralized Identifiers (DIDs) V1.0 (分散式識別碼 (DID) V1.0) 標準，因此可以與非 Microsoft 服務互通。 不過，本內容中的範例會反映可驗認證的 Microsoft 解決方案堆疊。

非核發解決方案特定的支援技術主題則不在本文內容涵蓋範圍。 例如，可驗認證簽發解決方案中會使用到網站，但是規劃網站部署的詳細資訊不在涵蓋範圍內。

解決方案的組成部分

在規劃簽發解決方案的過程中，您必須設計一個解決方案，使簽發者、使用者與驗證者之間可以進行互動。 下圖顯示簽發架構的元件。

Microsoft VC 簽發解決方案架構

圖表：顯示核發解決方案的各種元件。

Microsoft Entra 租使用者

執行 Microsoft Entra 驗證識別碼服務的先決條件是該服務要裝載於 Microsoft Entra 租使用者中。 Microsoft Entra 租用戶提供身分識別和存取管理 (IAM) 控制平面，以用於屬於解決方案的 Azure 資源。

每個租用戶都會使用多租用戶 Microsoft Entra 驗證識別碼服務，並且具有分散式識別碼 (DID)。 DID 可以提供證明，證明簽發者擁有已納入 DID 的網域。 主體和驗證者會使用 DID 來驗證簽發者。

Microsoft Azure 服務

圖表：顯示核發解決方案的元件，聚焦於 Azure 服務。

Azure Key Vault 服務會儲存您的簽發者金鑰，而此金鑰是在您起始 Microsoft Entra 已驗證的識別碼核發服務時產生。 金鑰和中繼資料用來執行認證管理作業並提供訊息安全性。

每個簽發者都有一個金鑰組，用於簽署、更新和復原。 您每次簽發您產生的每個可驗認證時，都會使用到此金鑰組。

「Microsoft Entra 已驗證的識別碼服務」用來儲存認證中繼資料和定義，尤其是您認證的規則和顯示定義。

  • 顯示定義會決定宣告如何顯示在持有者的錢包中，同時包括商標和其他元素。 顯示定義可以當地語系化為多種語言。 請參閱如何自訂可驗認證。

  • 規則是簽發者定義的模型，描述可驗認證的必要輸入。 規則也已定義信任的輸入來源，以及 VC 中所儲存的輸入宣告與輸出宣告對應。 根據規則定義中所定義的證明類型，輸入宣告可以來自不同的提供者。 輸入宣告可能來自 OIDC 身分識別提供者、來自 id_token_hint，或是透過電子錢包中的使用者輸入在簽發期間自我判斷的宣告。

    • 輸入 – 規則檔內的模型子集，供用戶端使用。 子集必須描述一組輸入、何處可取得輸入，以及呼叫以取得可驗認證的端點。

Microsoft Entra 已驗證的識別碼服務

圖表：Microsoft Entra 驗證識別碼服務。

Microsoft Entra 已驗證的識別碼服務可讓您根據設定來核發和撤銷 VC。 此服務：

  • 佈建分散式識別碼 (DID)。 每個簽發者的每個租用戶都有一個 DID。

  • 將金鑰組佈建至 Key Vault。

  • 儲存簽發服務和 Microsoft Authenticator 所使用的設定中繼資料。

  • 提供 REST API 介面給簽發者和驗證者 Web 前端

信任系統

醒目提示架構中信任系統的螢幕擷取畫面。

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

Microsoft Authenticator 應用程式

圖表：顯示 Microsoft Authenticator 作為可驗認證解決方案的電子錢包。

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

簽發的商務邏輯

圖表：顯示驗證識別碼簽發商業規則。

您的簽發解決方案包括使用者在其中要求 VC 的 Web 前端、身分識別存放區和/或其他屬性存放區，以取得關主體和其他後端服務的宣告值。

Web 前端透過產生深層連結或 QR 代碼，對主體的錢包提出簽發要求。 根據合約的設定，可能需要其他元件才能滿足建立 VC 的需求。

這些服務擔任支援角色，不一定需要與 Microsoft Entra 驗證識別碼簽發服務整合。 這一層通常包括：

  • Open ID Connect (OIDC) 相容服務會用來取得簽發 VC 所需的 id_tokens。 現有的身分識別系統 (例如 Microsoft Entra ID 或 Azure AD B2C) 可以提供 OIDC 相容服務，自訂解決方案 (例如身分識別伺服器) 也可以。

  • 屬性存放區 – 屬性存放區可能位於目錄服務之外，提供簽發 VC 所需的屬性。 例如，學生資訊系統可能會提供有關獲頒學位的宣告。

  • 其他的中介層服務包含查閱、驗證、計費的商務規則，以及任何其他簽發認證所需的執行階段檢查和流程。

如需有關設定 Web 前端的詳細資訊，請參閱教學課程設定 Microsoft Entra ID 簽發可驗認證。

認證設計考量

您的特定使用案例會決定您的認證設計。 使用案例決定：

  • 互通性需求

  • 使用者必須證明其身分識別才能取得其 VC 的方式

  • 認證中所需的宣告

  • 是否有需要撤銷認證

認證使用案例

使用 Microsoft Entra 已驗證的識別碼時，最常見的認證使用案例如下：

身分識別驗證：根據多個準則簽發的認證。 多個準則可能包括驗證政府簽發的文件真實性，例如護照或駕駛執照，並將該文件中的資訊與其他資訊相互關聯，例如：

  • 使用者的自拍

  • 活躍度的驗證

這類型的認證非常適合身分識別上線案例，例如新員工、合作夥伴、服務供應商、學生，以及其他身分識別驗證為必要項的實例。

圖表：顯示身分識別驗證使用案例。

雇用/成員資格證明：簽發認證以證明使用者與機構之間的關係。 這類型的認證非常適合用來存取鬆散結合的企業對企業應用程式，例如零售商提供折扣給員工或學生。 VC 的主要價值之一是可攜性：一旦簽發之後，使用者就可以在許多案例中使用 VC。

圖表：顯示就業證明使用案例。

如需更多使用案例，請參閱 Verifiable Credentials Use Cases (w3.org) (可驗認證使用案例 (w3.org))。

認證互通性

在設計過程中，請調查業界特定架構、命名空間和識別碼，使您可以保持一致以充分利用互通性和使用方式。 您可以在 Schema.org 和 DIF - 宣告與認證工作群組 中找到範例。

通用結構描述是標準仍在新興中的領域。 這類工作的其中一個範例就是 Verifiable Credentials for Education Task Force (教育專案小組的可驗認證)。 我們鼓勵您調查並參與您組織產業中的新興標準。

認證類型和屬性

建立認證的使用案例之後，您需要決定認證類型以及要包含在認證中的屬性。 驗證者可以讀取使用者所出示 VC 中的宣告。

所有可驗認證都必須在其規則定義中宣告其「類型」。 認證類型可區分可驗認證結構描述與其他認證，並確保簽發者與驗證器之間的互通性。 若要指出認證類型，請提供一或多個認證所滿足的認證類型。 每個類型都是唯一的字串。 通常，URI 用來確保全域唯一性。 URI 不需是可定址的。 其會被視為字串。 例如，Contoso 大學發行的文憑認證可能會宣告下列類型：

類型 用途
https://schema.org/EducationalCredential Contoso 大學所發行文憑的宣告包含 schema.org EducationaCredential 物件所定義的屬性。
https://schemas.ed.gov/universityDiploma2020 Contoso 大學所發行文憑的宣告包含美國教育部所定義的屬性。
https://schemas.contoso.edu/diploma2020 Contoso 大學所發行文憑的宣告包含 Contoso 大學定義的屬性。

除了可能適用於您案例的業界特定標準和結構描述之外，請考慮以下層面：

  • 將私人資訊最小化：使用最小量必要私人資訊來符合使用案例。 例如，用於電子商務網站、提供折扣給員工和校友的 VC，透過出示僅具姓氏和名字宣告的認證即可滿足需求。 不需要額外的資訊，例如雇用日期、職稱、部門。

  • 抽象化宣告：每個宣告都應該符合需求，同時將細節最小化。 例如，使用離散值 (例如 13、21、60)、名為 ageOver 的宣告比出生日期的宣告更加抽象。

  • 規劃撤銷功能：建議定義索引宣告，使機制能夠尋找並撤銷認證。 每個合約定義限定義一個索引宣告。 請務必注意，已編製索引的宣告值不會儲存至後端，只會儲存宣告值的雜湊。 如需詳細資訊，請參閱撤銷先前簽發的可驗認證。

如需認證屬性的其他考量，請參閱可驗認證資料模型 1.0 (w3.org) 規格。

規劃品質屬性

規劃效能

如同任何解決方案，您必須規劃效能。 需要著重的關鍵領域在延遲和可擴縮性。 在發行週期的初始階段期間，應該不需要在意效能。 然而，當採用簽發解決方案以致簽發許多可驗認證時，效能的規劃可能會變成解決方案中最重要的部分。

以下提供規劃效能時需考慮的領域：

  • Microsoft Entra 驗證識別碼簽發服務已部署至西歐、北歐、美國西部 2 和美國中西部、澳州和日本 Azure 區域。 如果您的 Microsoft Entra 租用戶位於歐盟內，則 Microsoft Entra 驗證識別碼服務也會位於歐盟。

  • 若要限制延遲，請在上述區域中部署您的簽發前端網站和金鑰保存庫。

以輸送量為基礎的模型：

  • 簽發者服務受限於 Azure Key Vault 服務的限制。

  • 就 Azure Key Vault 而言，每次簽發 VC 都會涉及三個簽署作業：

    • 一個用於來自網站的簽發要求

    • 一個用於建立的 VC

    • 一個用於合約下載

  • 您無法控制節流；不過，建議您閱讀 Azure Key Vault 節流指導。

  • 若打算大規模推出 VC 並上線，則請考慮批次建立 VC，以確保不會超過限制。

在規劃效能的過程中，請判斷您要監視以進一步了解解決方案效能的項目。 除了應用程式層級的網站監視之外，您可以在定義 VC 簽發的監視策略時，考慮以下事項：

針對可擴縮性，請考慮實作以下項目的指標：

  • 定義簽發程序的邏輯階段。 例如：

  • 初始要求

  • QR 代碼或深層連結的提供

  • 屬性查閱

  • Microsoft Entra 已驗證的識別碼核發服務的呼叫

  • 已簽發的認證

  • 根據階段定義指標：

    • 要求總計數 (數量)

    • 每時間單位的要求 (輸送量)

    • 花費的時間 (延遲)

  • 請使用下列連結來監視 Azure Key Vault：

  • 監視商務邏輯層所使用的元件。

規劃可靠性

若要規劃可靠性，建議您：

  • 在定義可用性與備援的目標之後，請利用下列指南了解如何達成您的目標：

  • 針對前端和商務層，您的解決方案可以有無限多的方式來建立資訊清單。 但是如同任何解決方案，關於您辨識出的相依項目，請確定該相依項目可復原且已監視。

如果發生 Microsoft Entra 驗證識別碼核發服務或 Azure Key Vault 服務變成無法使用的罕見事件，則整個解決方案將會變成無法使用。

規劃合規性

您的組織可能有與您的產業、交易類型或作業國家/地區相關的特定合規性需求。

資料落地：Microsoft Entra 已驗證的識別碼核發服務會部署至 Azure 區域的子集。 該服務僅用於計算函式。 我們不會將可驗認證的值儲存至 Microsoft 系統。 不過，在簽發過程中，會在簽發 VC 時傳送和使用個人資料。 使用 VC 服務應該不會影響資料落地需求。 如果您在身分識別驗證過程中儲存任何個人資訊，則這些資訊應該會以符合合規性需求的方式儲存在符合合規性需求的區域中。 如需 Azure 相關的指引，請造訪 Microsoft 信任中心網站。

撤銷認證：判斷您的組織是否需要撤銷認證。 例如，當員工離職時，管理員可能需要撤銷認證。 如需詳細資訊，請參閱撤銷先前簽發的可驗認證。

使認證過期：決定您的認證到期方式。 例如，如果您簽發 VC 做為擁有駕照的證明，則 VC 可能會在數年後過期。 其他 VC 可以有較短的有效性，以確保使用者定期回來更新其 VC。

規劃作業

規劃作業時，請務必開發一種架構，可以用於疑難排解、報告以及區分您支援的各種客戶。 此外，如果作業小組負責執行 VC 撤銷，則必須定義該程序。 程序中的每個步驟都應該相互關聯，以便您可以判斷哪些記錄項目可以與每個唯一的簽發要求相關聯。 針對稽核，建議您個別擷取認證簽發的每一次嘗試。 具體而言：

  • 產生唯一交易識別碼，客戶和支援工程師可在需要時參考。

  • 設計一種機制，使 Azure Key Vault 交易的記錄與解決方案中簽發部分的交易識別碼相互關聯。

  • 如果您是代表多個客戶簽發 VC 的身分識別驗證服務，請依客戶或合約識別碼監視並減輕問題，以進行對客戶的報告與計費。

  • 如果您是代表多個客戶簽發 VC 的身分識別驗證服務，請使用客戶或合約識別碼，以進行對客戶的報告與計費、監視和減輕問題。

規劃安全性

在著重於安全性的設計考量過程中，我們建議以下項目：

  • 針對金鑰管理：

    • 建立 VC 簽發專用的 Key Vault。 將 Azure Key Vault 權限限制為 Microsoft Entra 已驗證的識別碼核發服務和核發服務前端網站服務主體。

    • 將 Azure Key Vault 視為具有高度權限的系統 - Azure Key Vault 簽發認證給客戶。 我們建議沒有任何人為身分識別對 Azure Key Vault 服務擁有長期權限。 管理員應只能即時存取 Key Vault。 如需 Azure Key Vault 使用方式的最佳做法，請參閱適用於 Key Vault 的 Azure 安全性基準。

  • 針對代表簽發前端網站的服務主體：

    • 定義專用的服務主體來授權 Azure Key Vault 的存取權。 如果您的網站位於 Azure，建議您使用 Azure 受控識別。

    • 將代表網站和使用者的服務主體視為單一信任邊界。 雖然可以建立多個網站，但簽發解決方案只會設定一個金鑰。

針對安全性記錄和監視，我們建議以下項目：

  • 啟用 Azure Key Vault 的記錄和警示來追蹤認證簽發作業、金鑰擷取嘗試、權限變更，以及監視和傳送設定變更的警示。 如需詳細資訊，請參閱如何啟用 Key Vault 記錄。

  • 在安全性資訊與事件管理 (SIEM) 系統 (例如 Microsoft Sentinel) 中封存記錄以供長期保留。

  • 利用以下事項來降低詐騙風險

    • 可協助客戶識別簽發者品牌的 DNS 驗證。

    • 對終端使用者有意義的網域名稱。

    • 終端使用者辨識的信任品牌。

  • 減輕分散式阻斷服務 (DDOS) 和 Key Vault 資源耗盡的風險。 每個觸發 VC 簽發要求的要求都會產生簽署作業，這些作業會累積至服務限制內。 建議您在產生簽發要求之前併入驗證或文字驗證 (Captcha) 以保護流量。

如需管理 Azure 環境的指引，建議您檢閱 Microsoft 雲端安全性基準和使用 Microsoft Entra ID 保護 Azure 環境。 這些指南提供管理基礎 Azure 資源的最佳做法，這些資源包括 Azure Key Vault、Azure 儲存體、網站和其他 Azure 相關的服務和功能。

其他考量

當您完成 POC 時，請收集產生的所有資訊和文件，並考慮卸除簽發者設定。

如需有關 Key Vault 實作及作業的詳細資訊，請參閱使用 Key Vault 的最佳做法。 如需有關使用 Active Directory 保護 Azure 環境的詳細資訊，請參閱使用 Microsoft Entra ID 保護 Azure 環境。

下一步

閱讀架構概觀

規劃您的驗證解決方案

開始使用可驗認證