Microsoft Entra 確認済み ID の発行ソリューションを計画する
資格情報の発行に加えて、アーキテクチャとビジネスに対するソリューションの影響が完全にわかるように、発行ソリューションを計画することが重要です。 まだ行っていない場合は、Microsoft Entra 確認済み ID アーキテクチャの概要に関する記事を参照して、基本情報を確認することをお勧めします。
ガイダンスのスコープ
この記事では、検証可能な資格情報の発行ソリューションの計画に関する技術的側面について説明します。 Microsoft の検証可能な資格情報ソリューションは、World Wide Web コンソーシアム (W3C) の検証可能な資格情報のデータ モデル 1.0 と分散識別子 (DID) V1.0 標準に従っているため、Microsoft 以外のサービスと相互運用できます。 ただし、このコンテンツの例には、検証可能な資格情報の Microsoft ソリューション スタックが反映されています。
このコンテンツの対象外となるのは、発行ソリューションに固有ではないサポート技術に関する記事です。 たとえば、検証可能な資格情報の発行ソリューションでは Web サイトが使用されますが、Web サイトのデプロイ計画について詳しくは説明しません。
ソリューションのコンポーネント
発行ソリューションの計画の一環として、発行者、ユーザー、検証者間の対話を可能にするソリューションを設計する必要があります。 次の図は、発行アーキテクチャのコンポーネントを示しています。
Microsoft VC 発行ソリューションのアーキテクチャ
Microsoft Entra テナント
Microsoft Entra 確認済み ID サービスを実行するための前提条件は、それを Microsoft Entra テナントでホストすることです。 Microsoft Entra テナントにより、ソリューションに含まれる Azure リソース用の ID およびアクセス管理 (IAM) コントロール プレーンが提供されます。
各テナントは、マルチテナント Microsoft Entra 確認済み ID サービスを使い、分散化識別子 (DID) を持ちます。 DID により、発行者が DID に組み込まれているドメインを所有していることが証明されます。 DID は、発行者を検証するために、サブジェクトおよび検証者によって使用されます。
Microsoft Azure サービス
Microsoft Entra 確認済み ID 発行サービスを開始すると生成される発行者キーは、Azure Key Vault サービスに格納されます。 このキーとメタデータを使用して、資格情報の管理操作が実行され、メッセージのセキュリティが提供されます。
各発行者は、署名、更新、回復に使用する 1 つのキー セットを所有します。 このキー セットは、生成するすべての検証可能な資格情報のすべての発行に使用されます。
Microsoft Entra 確認済み ID サービスは、資格情報のメタデータと定義 (具体的には、資格情報のルールと表示の定義) を保存するために使用されます。
表示定義は、ホルダーのウォレットに要求を表示する方法を決定します。この定義には、ブランドやその他の要素も含まれます。 表示定義は、複数の言語にローカライズできます。 「検証可能な資格情報をカスタマイズする方法」を参照してください。
ルールは、発行者定義モデルであり、検証可能な資格情報の必須入力について記述します。 ルールでは、信頼された入力ソースと、VC に格納されている出力要求への入力要求のマッピングも定義されています。 ルール定義で定義されている構成証明の種類に応じて、入力要求を異なるプロバイダーから取得できます。 入力要求は、OIDC ID プロバイダー、id_token_hint、または発行中のウォレット内のユーザー入力を介したセルフ アサート要求から発生する可能性があります。
- 入力 – クライアントが使用するための、ルール ファイル内のモデルのサブセットです。 このサブセットでは、入力のセット、入力を取得する場所、検証可能な資格情報を取得するために呼び出すエンドポイントを表す必要があります。
Microsoft Entra 確認済み ID サービス
Microsoft Entra 確認済み ID サービスを使用すると、構成に基づいて VC を発行したり、取り消したりすることができます。 サービスによって:
分散化識別子 (DID) をプロビジョニングします。 各発行者は、テナントごとに 1 つの DID を所有します。
キー セットが Key Vault にプロビジョニングされます。
発行サービスおよび Microsoft Authenticator によって使用される構成メタデータが保存されます。
発行者と検証者の Web フロントエンド用の REST API インターフェイスを提供します
信頼システム
Microsoft Entra 確認済み ID は現在、信頼システム DID Web として Web をサポートしており、DID ドキュメントは発行者の Web サーバーでホストされています。
Microsoft Authenticator アプリケーション
Microsoft Authenticator はそのモバイル アプリケーションです。 Authenticator は、ユーザー、Microsoft Entra 確認済み ID サービス、および VC の発行に使用されるコントラクトの間の相互作用を調整します。 これは、VC の所有者が VC (VC のサブジェクトの秘密キーを含む) を保存するデジタル ウォレットとして機能します。 Authenticator は、検証対象の VC を提示するために使用されるメカニズムでもあります。
発行ビジネス ロジック
発行ソリューションには、Web フロントエンドが含まれます。ここで、ユーザーは VC、ID ストア、その他の属性ストアを要求して、サブジェクトやその他のバックエンド サービスに関するクレームの値を取得します。
Web フロントエンドは、ディープ リンクや QR コードを生成することによって、サブジェクトのウォレットに対して発行要求を出します。 コントラクトの構成によっては、VC を作成するための要件を満たすために、他のコンポーネントが必要になる場合があります。
これらのサービスにより、Microsoft Entra 確認済み ID 発行サービスと必ずしも統合する必要のないサポート ロールが提供されます。 通常、このレイヤーには次のものが含まれます。
OpenID Connect (OIDC) 準拠の 1 つ以上のサービス – VC を発行するために必要な id_tokens を取得するために使用されます。 Identity Server などのカスタム ソリューションで OIDC 準拠のサービスを提供できるように、Microsoft Entra ID や Azure AD B2C などの既存の ID システムでも OIDC 準拠のサービスを提供できます。
属性ストア - 属性ストアはディレクトリ サービスの外部にある場合があり、VC を発行するために必要な属性を提供します。 たとえば、学生情報システムで、取得済みの学位に関するクレームを提供する場合があります。
追加の中間層サービス – これには、検索、検証、課金に関するビジネス ルール、および資格情報を発行するために必要なその他のランタイム チェックとワークフローが含まれます。
Web フロントエンドの設定の詳細については、検証可能な資格情報を発行するための Microsoft Entra ID の構成に関するチュートリアルを参照してください。
資格情報の設計に関する考慮事項
特定のユース ケースにより、資格情報の設計が決まります。 ユース ケースによって以下が決まります。
相互運用性の要件
ユーザーが VC を取得するために本人であることを証明する方法
資格情報に必要なクレーム
資格情報を取り消す必要があるかどうか
資格情報のユース ケース
Microsoft Entra 確認済み ID では、最も一般的な資格情報のユース ケースは次のとおりです。
本人確認: 資格情報が複数の条件に基づいて発行されます。 複数の条件には、パスポートや運転免許証などの政府発行ドキュメントの信頼性を検証し、そのドキュメント内の情報を次のような他の情報と関連付けることが含まれる場合があります。
ユーザーの自撮り写真
生存性の検証
この種の資格情報は、新しい従業員、パートナー、サービス プロバイダー、学生、および本人確認が必要なその他の場合の ID オンボード シナリオに適しています。
雇用/メンバーシップの証明: ユーザーと機関の間の関係を証明するために資格情報が発行されます。 この種の資格情報は、従業員や学生に割引を提供する小売業者など、疎結合企業間アプリケーションにアクセスする場合に適しています。 VC の主な価値の 1 つはポータビリティです。発行後、ユーザーは多くのシナリオで VC を使用できます。
その他のユース ケースについては、検証可能な資格情報のユース ケース (w3.org) に関する記事を参照してください。
資格情報の相互運用性
設計プロセスの一環として、相互運用性と使用率を最大化するために、適用できる業界固有のスキーマ、名前空間、識別子を調査します。 例については、Schema.org および DIF - クレームと資格情報の作業グループに関するページを参照してください。
共通スキーマは、標準が考案されたばかりの分野です。 このような取り組みの 1 つの例として、教育機関向けの検証可能な資格情報タスク フォースがあります。 所属組織の業界の形になりつつある標準を調査し、それに協力することをお勧めします。
資格情報の種類と属性
資格情報のユース ケースを確立した後、資格情報の種類と、資格情報に含める属性を決定する必要があります。 検証者は、ユーザーが提示した VC のクレームを読み取ることができます。
検証可能な資格情報のすべてにおいて、ルール定義で "type" を宣言する必要があります。 資格情報の種類によって、検証可能な資格情報のスキーマが他の資格情報と区別され、発行者と検証者の間の相互運用性が確保されます。 資格情報の種類を示すには、資格情報が満たす 1 つまたは複数の資格情報の種類を指定します。 それぞれの種類は一意の文字列です。 多くの場合、グローバルな一意性を確保するために URI が使用されます。 この場合、アドレス指定可能な URI でなくてもかまいません。 文字列として扱われます。 例として、Contoso 大学によって発行された卒業証書の資格情報は、次の型を宣言する場合があります。
| Type | 目的 |
|---|---|
https://schema.org/EducationalCredential |
Contoso 大学によって発行された卒業証書に、schema.org の EducationaCredential オブジェクトによって定義された属性が含まれていることを宣言します。 |
https://schemas.ed.gov/universityDiploma2020 |
Contoso 大学によって発行された卒業証書に、米国教育省によって定義された属性が含まれていることを宣言します。 |
https://schemas.contoso.edu/diploma2020 |
Contoso 大学によって発行された卒業証書に、Contoso 大学によって定義された属性が含まれていることを宣言します。 |
シナリオに適用できる可能性のある業界固有の標準とスキーマに加えて、次の点を考慮します。
個人情報を最小限にする: 必要最小限の個人情報でユース ケースに対処します。 たとえば、従業員と退職者に割引を提供する e コマース Web サイトで使用される VC は、名と姓のクレームのみで資格情報を提示することで実現できます。 入社日、役職、部署などの追加情報は必要ありません。
抽象クレームを優先する: 詳細を最小限に抑える一方で、各クレームでニーズを満たす必要があります。 たとえば、13、21、60 といった離散的な値を持つ "ageOver" というクレームは、生年月日のクレームよりも抽象的です。
取り消しに関する計画: 資格情報を検索して取り消すメカニズムを有効にするために、インデックス クレームを定義することをお勧めします。 コントラクトごとに定義できるインデックス クレームは 1 つのみです。 インデックス クレームの値はバックエンドに保存されず、クレーム値のハッシュのみが保存されることに注意することが重要です。 詳細については、「以前に発行された検証可能な資格情報を失効させる」を参照してください。
資格情報の属性に関するその他の考慮事項については、「検証可能な資格情報のデータ モデル 1.0 (w3.org)」の仕様を参照してください。
品質属性の計画
パフォーマンスの計画
他のソリューションと同様に、パフォーマンスについて計画する必要があります。 注目する必要がある重要な領域は、待機時間とスケーラビリティです。 リリース サイクルの初期フェーズでは、パフォーマンスを考慮する必要はありません。 ただし、発行ソリューションを導入したことにより多くの検証可能な資格情報が発行されるときは、パフォーマンス計画がソリューションの重要な部分になる可能性があります。
以下では、パフォーマンスを計画するときに考慮する必要がある領域を示します。
Microsoft Entra 確認済み ID 発行サービスは、西ヨーロッパ、北ヨーロッパ、米国西部 2、米国中西部、オーストラリア、日本の各 Azure リージョンにデプロイされています。 Microsoft Entra テナントがヨーロッパ内に存在する場合、Microsoft Entra 確認済み ID サービスもヨーロッパに配置されます。
待機時間を制限するには、発行フロントエンド Web サイトとキー コンテナーを上記のリージョンにデプロイします。
スループットに基づくモデル:
発行者サービスは、Azure Key Vault サービスの制限の対象です。
Azure Key Vault では、VC の発行ごとに 3 つの署名操作が必要です。
Web サイトからの発行要求に対して 1 つ
作成される VC に対して 1 つ
コントラクトのダウンロードに対して 1 つ
スロットリングは制御できませんが、「Azure Key Vault のスロットル ガイダンス」を確認することをお勧めします。
VC の大規模なロールアウトとオンボードを計画している場合は、制限を超えないようにするために、VC の作成をバッチ処理することを検討してください。
パフォーマンスの計画の一環として、ソリューションのパフォーマンスをよりよく理解するために監視する対象を決定します。 VC 発行の監視戦略を定義するときに、アプリケーション レベルの Web サイト監視に加えて、次の点を考慮してください。
スケーラビリティについては、以下の項目のメトリックを実装することを検討してください。
発行プロセスの論理フェーズを定義します。 次に例を示します。
最初の要求
QR コードまたはディープ リンクの提供
属性の参照
Microsoft Entra 確認済み ID 発行サービスの呼び出し
資格情報の発行
フェーズに基づいてメトリックを定義します。
要求の総数 (量)
時間単位あたりの要求数 (スループット)
消費時間 (待機時間)
以下のリンクを使って Azure Key Vault を監視します。
ビジネス ロジック層に使用されるコンポーネントを監視します。
信頼性の計画
信頼性を計画するために、以下をお勧めします。
可用性と冗長性の目標を定義した後、次のガイドを使用して目標を達成する方法を理解します。
フロントエンドおよびビジネス層では、ソリューションは無数の方法で実現できます。 他のソリューションと同様に、識別された依存関係について、依存関係の回復性を確保し、監視できるようにします。
めったに起こりませんが、Microsoft Entra 確認済み ID 発行サービスと Azure Key Vault サービスが使用できなくなった場合、ソリューション全体が使用できなくなります。
コンプライアンスの計画
組織には、業界、トランザクションの種類、または運用する国/リージョンに関連する特定のコンプライアンス ニーズがある場合があります。
データ所在地: Microsoft Entra 確認済み ID 発行サービスは、Azure リージョンのサブセットにデプロイされます。 このサービスは、コンピューティング機能のためにのみ使用されます。 検証可能な資格情報の値は、Microsoft システムには保存されません。 ただし、発行プロセスの一環として、VM の発行時に個人データが送信され、使用されます。 VC サービスを使用しても、データ所在地の要件には影響しません。 本人確認の一環として個人情報を保存する場合、コンプライアンス要件を満たす方法で、要件を満たすリージョンに保存する必要があります。 Azure 関連のガイダンスについては、Microsoft トラスト センターの Web サイトを参照してください。
資格情報の取り消し: 組織で資格情報を取り消す必要があるかどうかを決定します。 たとえば、従業員が退職するとき、管理者は資格情報を取り消す必要がある場合があります。 詳細については、「以前に発行された検証可能な資格情報を失効させる」を参照してください。
資格情報の失効: 資格情報の有効期限を決定します。 たとえば、運転免許証を所持していることの証明として VC を発行した場合、数年後に有効期限切れになる可能性があります。 他の VC では、ユーザーが定期的に VC を更新するのに戻ってくるように、有効期間を短くすることができます。
運用を計画する
運用を計画する場合、トラブルシューティング、レポート作成、サポートするさまざまな顧客の識別に使用するスキーマを作成することが重要です。 さらに、運用チームが VC 取り消しの実行を担当する場合は、そのプロセスを定義する必要があります。 プロセスの各ステップを関連付ける必要があります。これにより、どのログ エントリを一意の各発行要求に関連付けることができるか特定できます。 監査のために、資格情報発行の各試行を個別にキャプチャすることをお勧めします。 具体的には:
顧客とサポート エンジニアが必要に応じて参照できる一意のトランザクション ID を生成します。
Azure Key Vault トランザクションのログを、ソリューションの発行部分のトランザクション ID に関連付けるメカニズムを考案します。
複数の顧客に代わって VC を発行する ID 検証サービスの場合は、顧客向けレポートと課金のために、顧客またはコントラクトの ID によって監視および軽減措置を行います。
複数の顧客に代わって VC を発行する ID 検証サービスの場合は、顧客向けレポートと課金、監視、および軽減措置のために、顧客またはコントラクトの ID を使います。
セキュリティの計画
セキュリティに重点を置く設計の考慮事項の一部として、以下の項目を推奨します。
キー管理:
VC 発行専用の Key Vault を作成します。 Azure Key Vault のアクセス許可を Microsoft Entra 確認済み ID 発行サービス、および発行サービス フロントエンド Web サイトのサービス プリンシパルに制限します。
Azure Key Vault を権限が高いシステムとして扱います - Azure Key Vault により資格情報が顧客に発行されます。 Azure Key Vault サービスに対する継続的なアクセス許可を人間の ID に付与しないようにすることをお勧めします。 管理者には、Key Vault への 1 回限りのアクセス権のみ付与する必要があります。 Azure Key Vault の使用に関するその他のベスト プラクティスについては、「Key Vault 用の Azure セキュリティ ベースライン」を参照してください。
発行フロントエンド Web サイトを表すサービス プリンシパルの場合:
Azure Key Vault へのアクセスを承認する専用のサービス プリンシパルを定義します。 Web サイトが Azure にある場合、Azure マネージド ID を使用することをお勧めします。
Web サイトを表すサービス プリンシパルとユーザーを 1 つの信頼境界として扱います。 複数の Web サイトを作成できますが、発行ソリューションに設定されるキーは 1 つのみです。
セキュリティ ログと監視について、以下の項目を推奨します。
資格情報の発行操作、キーの抽出試行、アクセス許可の変更を追跡するため、および構成の変更を監視し、アラートを送信するために、Azure Key Vault のログとアラートを有効にします。 詳細については、「Key Vault のログ記録を有効にする方法」を参照してください。
長期保有のため、Microsoft Sentinel などのセキュリティ情報イベント管理 (SIEM) システムにログをアーカイブします。
以下を使用してスプーフィングのリスクを軽減します。
顧客が発行者のブランドを識別するのに役立つ DNS 確認。
エンド ユーザーにわかりやすいドメイン名。
エンド ユーザーが認める信頼できるブランド。
分散型サービス拒否 (DDOS) と Key Vault リソース枯渇のリスクを軽減します。 VC 発行要求をトリガーするすべての要求により、Key Vault 署名操作が生成されます。これは、サービス制限まで増加します。 発行要求を生成する前に、認証または CAPTCHA を組み込むことにより、トラフィックを保護することをお勧めします。
Azure 環境の管理のガイダンスについて、Microsoft クラウド セキュリティ ベンチマークと Azure Microsoft Entra ID を使用した Azure 環境のセキュリティ保護に関する記事を確認することをお勧めします。 これらのガイドでは、Azure Key Vault、Azure Storage、Web サイト、その他の Azure 関連のサービスや機能など、基になる Azure リソースを管理するためのベスト プラクティスを提供しています。
その他の注意点
POC を完了した後、生成されたすべての情報とドキュメントを収集し、発行者の構成を破棄することを検討します。
Key Vault の実装と操作について詳しくは、「Key Vault を使用するためのベスト プラクティス」を参照してください。 Active Directory を使用した Azure 環境のセキュリティ保護について詳しくは、Microsoft Entra ID を使用した Azure 環境のセキュリティ保護に関する記事を参照してください。