規劃您的 Microsoft Entra 驗證識別碼 發行解決方案
請務必規劃您的發行解決方案，如此一來，除了發行認證之外，您還有解決方案架構和業務影響的完整檢視。 如果您尚未這麼做，建議您檢視基本資訊 Microsoft Entra 驗證識別碼 架構概觀。
指引範圍
本文涵蓋規劃可驗證認證發行解決方案的技術層面。 適用於可驗證認證的 Microsoft 解決方案遵循萬維網聯合會 （W3C） 可驗證認證數據模型 1.0 和分散式識別碼 （DID） V1.0 標準，因此可與非 Microsoft 服務 互通。 不過，此內容中的範例會反映 Microsoft 解決方案堆疊，以取得可驗證的認證。
此內容的範圍不足是涵蓋發行解決方案專屬支持技術的文章。 例如，網站會用於可驗證的認證發行解決方案，但規劃網站部署並未詳細說明。
解決方案的元件
作為發行解決方案計劃的一部分，您必須設計解決方案，以啟用簽發者、使用者和驗證程式之間的互動。 下圖顯示發行架構的元件。
Microsoft VC 發行解決方案架構
Microsoft Entra 租使用者
執行 Microsoft Entra 驗證識別碼 服務的必要條件是裝載在 Microsoft Entra 租使用者中。 Microsoft Entra 租使用者會為屬於解決方案的 Azure 資源提供身分識別與存取管理 （IAM） 控制平面。
每個租用戶都會使用多租使用者 Microsoft Entra 驗證識別碼 服務，並具有分散式標識碼 （DID）。 DID 提供證明簽發者擁有併入 DID 的網域。 主體和驗證程式會使用 DID 來驗證簽發者。
Microsoft Azure 服務
Azure 金鑰保存庫 服務會儲存您的簽發者密鑰，當您起始 Microsoft Entra 驗證識別碼 發行服務時所產生的密鑰。 金鑰和元數據可用來執行認證管理作業，並提供訊息安全性。
每個簽發者都有用於簽署、更新和復原的單一金鑰集。 此金鑰集會用於您產生之每個可驗證認證的每個發行。
Microsoft Entra 驗證識別碼 服務可用來儲存認證元數據和定義;特別是認證的規則和顯示定義。
顯示定義會決定宣告如何顯示在持有人的錢包中，也包含商標和其他元素。 [顯示] 定義可以本地化為多種語言。 請參閱 如何自定義可驗證的認證。
規則是簽發者定義的模型，描述可驗證認證的必要輸入。 規則也會定義受信任的輸入來源，以及輸入宣告與儲存在 VC 中的輸出宣告的對應。 根據規則定義中所定義的證明類型，輸入宣告可能來自不同的提供者。 輸入宣告可能來自 OIDC 識別提供者、來自id_token_hint，或來自透過錢包中使用者輸入進行發行期間自我判斷的宣告。
- 輸入 – 這是規則檔案中用於用戶端取用的模型子集。 子集必須描述一組輸入，其中要取得輸入，以及要呼叫的端點以取得可驗證的認證。
Microsoft Entra 驗證識別碼 服務
Microsoft Entra 驗證識別碼 服務可讓您根據設定發出和撤銷 VM。 此服務：
布建分散式標識碼 （DID）。 每個簽發者每個租使用者都有單一 DID。
將金鑰集佈建至 金鑰保存庫。
儲存發行服務和 Microsoft Authenticator 所使用的組態元數據。
提供簽發者和驗證程式 Web 前端的 REST API 介面
信任系統
Microsoft Entra 驗證識別碼 目前支援 Web 作為信任系統DID Web，其中 DID 檔裝載於簽發者 Web 伺服器上。
Microsoft Authenticator 應用程式
Microsoft Authenticator 是行動應用程式。 Authenticator 會協調使用者、Microsoft Entra 驗證識別碼 服務和用來發出 VCS 的合約之間的互動。 它作為數位錢包，VC 的持有者將 VC 儲存在其中，包括 VC 主體的私鑰。 驗證器也是用來呈現用於驗證之 VM 的機制。
發行商業規則
您的發行解決方案包含 Web 前端，讓使用者要求 VC、身分識別存放區和其他屬性存放區，以取得有關主體和其他後端服務之宣告的值。
Web 前端會藉由產生深層連結或 QR 代碼，為主體的錢包提供發行要求。 根據合約的設定，可能需要其他元件才能滿足建立 VC 的需求。
這些服務提供不一定需要與 Microsoft Entra 驗證識別碼 發行服務整合的支援角色。 此層次通常包括：
OpenID 連線 （OIDC）相容的服務或服務可用來取得發出 VC 所需的id_tokens。 Microsoft Entra ID 或 Azure AD B2C 等現有身分識別系統可以提供符合 OIDC 規範的服務，例如 Identity Server 等自定義解決方案。
屬性存放區 – 屬性存放 區可能不在目錄服務之外，並提供發出 VC 所需的屬性。 例如，學生資訊系統可能會提供有關所獲得學位的宣告。
包含查閱、驗證、計費，以及發出認證所需的任何其他運行時間檢查和工作流程的其他仲介層服務 。
如需設定 Web 前端的詳細資訊，請參閱設定您的 Microsoft Entra ID 以發出可驗證的認證教學課程。
認證設計考慮
您的特定使用案例會決定您的認證設計。 使用案例決定：
互操作性需求
使用者需要證明其身分識別以取得其 VC 的方式
認證中所需的宣告
如果需要撤銷認證，則為
認證使用案例
使用 Microsoft Entra 驗證識別碼 時，最常見的認證使用案例如下：
身分識別驗證：根據多個準則發出認證。 多個準則可能包括驗證政府簽發的文件真實性，例如護照或駕駛執照，並以其他資訊將該文件中的資訊核心化，例如：
使用者的自拍
驗證活躍度
這種認證很適合新員工、合作夥伴、服務提供者、學生和其他身分識別驗證至關重要的身分識別上線案例。
僱用/成員資格證明：認證會發出，以證明使用者與機構之間的關係。 這種認證非常適合用來存取鬆散結合的企業對企業應用程式，例如零售商為員工或學生提供折扣。 其中一個主要的 VCS 值是其可移植性：發出之後，用戶可在許多案例中使用 VC。
如需更多使用案例，請參閱可驗證的認證使用案例（w3.org）。
認證互操作性
在設計程式中，調查產業特定的架構、命名空間和標識碼，您可以配合以最大化互操作性和使用量。 您可以在 Schema.org 和 DIF - 宣告和認證工作組中找到範例。
常見的架構是標準仍在出現的區域。 這類工作的其中一個範例是 教育工作小組的可驗證認證。 我們鼓勵您調查並參與組織產業中的新興標準。
認證類型和屬性
建立認證使用案例之後，您必須決定認證類型和要在認證中包含哪些屬性。 驗證程式可以在使用者所呈現的 VC 中讀取宣告。
所有可驗證的認證都必須在其規則定義中宣告其類型。 認證類型會區分可驗證的認證架構與其他認證，並確保簽發者和驗證程序之間的互操作性。 若要指出認證類型，請提供認證滿足的一或多個認證類型。 每個類型都是唯一的字串。 URI 通常用來確保全域唯一性。 URI 不需要可尋址。 它會被視為字串。 例如，Contoso University 簽發的文憑認證可能會宣告下列類型：
| 類型 | 用途 |
|---|---|
https://schema.org/EducationalCredential |
宣告 Contoso University 發出的文憑包含由 schema.org EducationaCredential 物件定義的屬性。 |
https://schemas.ed.gov/universityDiploma2020 |
宣告 Contoso 大學頒發的文憑包含美國教育部所定義的屬性。 |
https://schemas.contoso.edu/diploma2020 |
宣告 Contoso University 發出的文憑包含 Contoso University 所定義的屬性。 |
除了可能適用於您案例的業界特定標準和架構之外，請考慮下列層面：
最小化私人資訊：以最少所需的私人資訊量滿足使用案例。 例如，用於為員工和校友提供折扣的電子商務網站的 VC，只要提供名字和姓氏宣告即可完成認證。 不需要其他資訊，例如招聘日期、職稱、部門。
偏好抽象宣告：每個宣告都應該符合需求，同時將詳細數據降到最低。 例如，名為 「ageOver」 的宣告具有離散值，例如 13、21、60，比出生宣告日期更抽象。
規劃可撤銷性：建議您定義索引宣告，以啟用尋找和撤銷認證的機制。 您只能為每個合約定義一個索引宣告。 請務必注意，索引宣告的值不會儲存在後端，而只會儲存宣告值的哈希。 如需詳細資訊，請參閱 撤銷先前發行的可驗證認證。
如需認證屬性的其他考慮，請參閱 可驗證認證數據模型 1.0 （w3.org） 規格。
規劃質量屬性
規劃效能
如同任何解決方案，您必須規劃效能。 要關注的主要領域是延遲和延展性。 在發行週期的初始階段，效能不應該是問題。 不過，當您的發行解決方案採用會導致許多可驗證的認證發行時，效能規劃可能會成為解決方案的重要部分。
下列提供規劃效能時要考慮的領域：
Microsoft Entra 驗證識別碼 發行服務部署在西歐、北歐、美國西部 2、美國中西部、澳大利亞和日本 Azure 區域。 如果您的 Microsoft Entra 租用戶位於歐盟內，則 Microsoft Entra 驗證識別碼 服務也位於歐盟。
若要限制延遲，請在上述區域中部署您的發行前端網站和密鑰保存庫。
以輸送量為基礎的模型：
簽發者服務受限於 Azure 金鑰保存庫 服務限制。
針對 Azure 金鑰保存庫，每個 VC 發行都會涉及三個簽署作業：
一個用於從網站發佈要求
其中一個用於建立的 VC
合約下載的其中一個
您無法控制節流;不過，建議您閱讀 Azure 金鑰保存庫 節流指引。
如果您要規劃大型推出和上線 VC，請考慮批處理 VC 建立，以確保您不會超過限制。
作為效能計劃的一部分，請決定您監視的內容，以進一步了解解決方案的效能。 除了應用層級網站監視之外，請考慮下列事項，因為您定義 VC 發行監視策略：
針對延展性，請考慮實作下列專案的計量：
定義發行程式的邏輯階段。 例如：
初始要求
維護 QR 代碼或深層連結
屬性查閱
呼叫 Microsoft Entra 驗證識別碼 發行服務
已核發認證
根據階段定義計量：
要求總數（磁碟區）
每個時間單位的要求 （輸送量）
花費的時間（延遲）
使用下列連結監視 Azure 金鑰保存庫：
監視商業規則層所使用的元件。
規劃可靠性
若要規劃可靠性，建議您：
定義可用性和備援目標之後，請使用下列指南來瞭解如何達成您的目標：
針對前端和商務層，您的解決方案可以無限數量的方式顯示。 如同任何解決方案，針對您識別的相依性，請確定相依性具有復原性和監視性。
如果 Microsoft Entra 驗證識別碼 發行服務或 Azure 金鑰保存庫 服務變得無法使用的罕見事件，整個解決方案就會變成無法使用。
規劃合規性
您的組織可能有與您的產業、交易類型或作業國家/地區相關的特定合規性需求。
數據落地：Microsoft Entra 驗證識別碼 發行服務會部署在 Azure 區域的子集中。 服務僅用於計算函式。 我們不會將可驗證認證的值儲存在 Microsoft 系統中。 不過，作為發行程式的一部分，個人資料會在發行DC時傳送和使用。 使用 VC 服務不應影響數據落地需求。 如果您將任何個人資訊儲存為身分識別驗證的一部分，則應該以符合合規性需求的方式和區域儲存。 如需 Azure 相關指引，請流覽 Microsoft 信任中心網站。
撤銷認證：判斷您的組織是否需要撤銷認證。 例如，當員工離職時，系統管理員可能需要撤銷認證。 如需詳細資訊，請參閱 撤銷先前發行的可驗證認證。
即將到期的認證：決定您的認證到期方式。 例如，如果您發出 VC 作為駕駛執照證明，它可能會在幾年後到期。 其他 VCS 可以有較短的有效性，以確保使用者定期回來更新其 VC。
規劃作業
規劃作業時，請務必開發架構，以用於疑難解答、報告及區分您支援的各種客戶。 此外，如果作業小組負責執行 VC 撤銷，則必須定義該程式。 程式中的每個步驟都應該相互關聯，以便判斷哪些記錄專案可以與每個唯一發行要求產生關聯。 若要進行稽核，建議您個別擷取每個認證發出的嘗試。 具體而言：
產生客戶和支持工程師可視需要參考的唯一交易標識碼。
設計機制，將 Azure 金鑰保存庫 交易的記錄與解決方案發行部分的交易識別元相互關聯。
如果您是代表多個客戶發出 VCS 的身分識別驗證服務，請針對客戶面向報告和計費，依客戶或合約標識碼來監視和減輕風險。
如果您是代表多個客戶發出 VM 的身分識別驗證服務，請使用客戶或合約標識碼進行客戶面向報告和計費、監視和緩和。
規劃安全性
作為您設計考慮的一部分，著重於安全性，我們建議下列專案：
針對金鑰管理：
建立 VC 發行的專用 金鑰保存庫。 將 Azure 金鑰保存庫 許可權限制為 Microsoft Entra 驗證識別碼 發行服務和發行服務前端網站服務主體。
將 Azure 金鑰保存庫 視為高許可權系統 - Azure 金鑰保存庫 向客戶發出認證。 我們建議沒有任何人類身分識別具有 Azure 金鑰保存庫 服務的長期許可權。 管理員 主義者應該只有我時間才能存取 金鑰保存庫。 如需 Azure 金鑰保存庫 使用量的最佳做法，請參閱適用於 金鑰保存庫 的 Azure 安全性基準。
針對代表發行前端網站的服務主體：
定義專用的服務主體，以授權存取 Azure 金鑰保存庫。 如果您的網站位於 Azure 上，建議您使用 Azure 受控識別。
將代表網站和用戶的服務主體視為單一信任界限。 雖然可以建立多個網站，但發行解決方案只有一個密鑰集。
針對安全性記錄和監視，我們建議下列專案：
啟用 Azure 金鑰保存庫 的記錄和警示，以追蹤認證發行作業、密鑰擷取嘗試、許可權變更，以及監視和傳送設定變更的警示。 如需詳細資訊，請參閱如何啟用 金鑰保存庫 記錄。
在安全性資訊和事件管理 （SIEM） 系統中封存記錄，例如 長期保留的 Microsoft Sentinel 。
使用下列專案降低詐騙風險
DNS 驗證可協助客戶識別簽發者商標。
對使用者有意義的功能變數名稱。
用戶可辨識的信任品牌。
降低分散式阻斷服務 （DDOS） 和 金鑰保存庫 資源耗盡風險。 觸發 VC 發行要求的每個要求都會產生 金鑰保存庫 簽署作業，以因服務限制而累算。 建議您先納入驗證或 captcha，再產生發行要求，以保護流量。
如需管理 Azure 環境的指引，建議您檢閱 Microsoft 雲端安全性效能評定 ，以及 使用 Microsoft Entra ID 保護 Azure 環境。 這些指南提供管理基礎 Azure 資源的最佳做法，包括 Azure 金鑰保存庫、Azure 儲存體、網站和其他 Azure 相關服務和功能。
其他考量
當您完成POC時，請收集所產生的所有資訊和檔，並考慮卸除簽發者設定。
如需 金鑰保存庫 實作和作業的詳細資訊，請參閱使用 金鑰保存庫 的最佳做法。 如需使用 Active Directory 保護 Azure 環境的詳細資訊，請參閱 使用 Microsoft Entra 識別符保護 Azure 環境。