Microsoft Entra 確認済み ID の検証ソリューションを計画する
Microsoft Entra 確認済み ID (Microsoft Entra VC) サービスを使用すると、信頼境界を広げることなく、ユーザー ID の証明を信頼することができます。 Microsoft Entra VC では、アカウントを作成するか、別の ID プロバイダーとフェデレーションします。 ソリューションで検証可能な資格情報を使用して検証の交換を実装する場合、アプリケーションで特定のドメインにバインドされていない資格情報を要求できます。 このアプローチにより、大規模な資格情報の要求と検証が容易になります。
まだご覧になっていない場合は、「Microsoft Entra 確認済み ID アーキテクチャの概要」を確認することをお勧めします。 「Microsoft Entra 確認済み ID 発行ソリューションを計画する」も確認してください。
ガイダンスのスコープ
このコンテンツでは、Microsoft の製品とサービスを使用した検証可能な資格情報検証ソリューションの計画の技術的側面について説明します。 このソリューションは、現在 DID Web がサポートされている信頼システムとインターフェイスします。 DID Web は、一元化された公開キー インフラストラクチャです。
検証ソリューションに固有ではないサポート テクノロジは対象範囲外です。 たとえば、検証可能な資格情報の検証ソリューションでは Web サイトが使用されますが、Web サイトの配置の計画については詳しく説明しません。
検証ソリューションを計画する際には、どのようなビジネス機能が追加または変更されているのかを検討する必要があります。 また、再利用できる IT 機能と、ソリューションを作成するために追加する必要がある機能も考慮する必要があります。 また、ビジネス プロセスに関係するユーザーや、ソリューションのエンド ユーザーとスタッフをサポートするユーザーに必要なトレーニングも検討する必要があります。 これらの記事については、このコンテンツでは説明しません。 これらの記事に関する情報については、「Microsoft Azure Well-Architected Framework」を確認することをお勧めします。
ソリューションのコンポーネント
検証ソリューションの計画の一環として、検証者、対象者、発行者の間の相互作用を有効にする必要があります。 この記事では、証明書利用者と検証者という用語を同じ意味で使用します。 次の図は、検証アーキテクチャのコンポーネントを示したものです。
Microsoft Entra 確認済み ID サービス
検証ソリューションのコンテキストでの Microsoft Entra 確認済み ID サービスは、ソリューションの Microsoft コンポーネントと信頼システムの間のインターフェイスになります。 このサービスによって、キー セットが Key Vault にプロビジョニングされ、分散化識別子 (DID) がプロビジョニングされます。
Microsoft Entra テナント
このサービスには、ソリューションの一部である Azure リソース用の ID およびアクセス管理 (IAM) コントロール プレーンを提供する Microsoft Entra テナントが必要です。 各 Microsoft Entra テナントでは、マルチテナント Microsoft Entra 確認済み ID サービスを使用し、検証ツールを表す 1 つの DID ドキュメントが発行されます。 検証サービスを複数の証明書利用者が使用する場合は、すべてが同じ検証者 DID を使用します。 検証者 DID により、対象者と発行者が証明書利用者からのメッセージを検証できる公開キーへのポインターが提供されます。
Azure Key Vault
Microsoft Entra 確認済み ID 発行サービスを有効にすると生成される検証者キーは、Azure Key Vault サービスに格納されます。 このキーは、メッセージのセキュリティを提供するために使用されます。 各検証者は、VC の署名、更新、回復に使用される 1 つのキー セットを持っています。 このキー セットは、検証要求を処理するたびに使用されます。 現在、Microsoft のキー セットでは、楕円曲線暗号 (ECC) SECP256k1 が使用されています。 より広範な DID コミュニティによって採用される他の暗号化署名スキーマが探索されています。
要求サービス API
アプリケーション プログラミング インターフェイス (API) により、検証操作を実行するソリューションのコンポーネント間の対話を抽象化するための方法が開発者に提供されます。
信頼システム
Microsoft Entra Verified ID は現在、DID Web を信頼システムとしてサポートしています。DID ドキュメントは発行者 Web サーバーでホストされています。
Microsoft Authenticator アプリケーション
Microsoft Authenticator はそのモバイル アプリケーションです。 Authenticator は、ユーザー、Microsoft Entra 確認済み ID サービス、および VC の発行に使用されるコントラクトの間の相互作用を調整します。 これは、VC の所有者が VC (VC のサブジェクトの秘密キーを含む) を保存するデジタル ウォレットとして機能します。 Authenticator は、検証対象の VC を提示するために使用されるメカニズムでもあります。
証明書利用者 (RP)
Web フロント エンド
証明書利用者 Web フロントエンドでは、要求サービス API を使用して、対象者のウォレットが使用するディープ リンクまたは QR コードが生成されることにより、VC が検証されます。 シナリオにより、フロントエンドは、パブリックにアクセスできるようにすることも、内部 Web サイトにして検証を必要とするエンド ユーザー エクスペリエンスを有効にすることもできます。 ただし、ウォレットがアクセスするエンドポイントは、パブリックにアクセスできる必要があります。 具体的には、特定の要求パラメーターを使用してウォレットへのリダイレクトを制御します。
ビジネス ロジック
新しいロジックを作成することも、証明書利用者に固有の既存のロジックを使用し、VC の提示でそのロジックを拡張することもできます。
シナリオ固有の設計
次に示すのは、特定のユース ケースを満たす設計の例です。 1 つ目は、アカウントのオンボードに関するものである、新しい従業員のオンボードに関連する時間、コスト、リスクを減らすために使用されます。 2 つ目はアカウントの回復に関するものであり、エンド ユーザーがセルフサービス メカニズムを使用してアカウントを回復またはロック解除できます。 3 つ目は、価値の高いアプリケーションとリソースへのアクセスに関するものであり、具体的には、他の会社で働くユーザーにアクセス権を与える企業間のユース ケースです。
アカウントのオンボード
検証可能な資格情報を使用すると、人間による操作の一部を置き換えることで、より高速なオンボードを可能にすることができます。 VC を使用して、サービスにアクセスするために従業員、学生、市民、または他のユーザーをオンボードできます。 たとえば、従業員は、中央オフィスにアクセスして従業員バッジをアクティブ化する必要はなく、自分の ID を検証する VC を使用して、リモートで提供されたバッジをアクティブ化できます。 コードを受け取った市民は、政府のサービスにアクセスして引き換える必要はなく、VC を使用して自分の ID を証明し、アクセスを取得できます。
その他の要素
オンボード ポータル: VC の提示と検証のための要求サービス API の呼び出しと、アカウントをオンボードするロジックを調整する Web フロントエンドです。
カスタム ロジックとワークフロー: ユーザー アカウントを更新する前と後の組織固有の手順が含まれる特定のロジック。 例には、承認ワークフロー、その他の検証、ログ記録、通知などが含まれる場合があります。
ターゲット ID システム: 対象者のオンバードの間にオンボード ポータルが対話する必要のある組織固有の ID リポジトリ。 統合するシステムは、VC 検証でオンボードする必要のある ID の種類に基づいて決定されます。 オンボードに関する ID 検証の一般的なシナリオには、次のものが含まれます。
API を使用して Microsoft Entra ID をオンボードして企業間 (B2B) の招待を発行する External Identities、またはパッケージへのエンタイトルメント管理の割り当て。
従業員 ID。これは、集中型 ID システムでは、人事 (HR) システムを通じて既にオンボードされています。 この場合、ID 検証は HR ワークフローの既存のステージの一部として統合される可能性があります。
デザインに関する考慮事項
発行者: アカウントのオンボードは、VM の発行者として外部 ID 証明サービスに適しています。 オンボードのチェックの例としては、生存チェック、政府発行ドキュメントの検証、住所または電話番号の確認などがあります。
VC 属性の格納: 可能な場合は、VC からの属性をアプリ固有のストアに格納しないでください。 個人データには特に注意してください。 アプリケーション内の特定のフローでこの情報が必要な場合は、要求時に要求を取得するように VC に依頼することを検討してください。
VC の属性とバックエンド システムの関連付け: 発行者で VC の属性を定義するときは、ユーザーが VC を提示した後でバックエンド システムの情報を関連付けるメカニズムを設けます。 このメカニズムでは、通常、受け取ったクレームと組み合わせて、RP のコンテキストでの期限付き一意識別子を使用します。 次に例をいくつか示します。
新しい従業員: HR ワークフローが ID 証明を必要とするポイントに達すると、RP で期限付き一意識別子のあるリンクを生成します。 RP はその後、それを HR システムの候補者のメール アドレスに送信します。 この一意識別子は、VC 検証要求の firstName や lastName などの情報を、HR レコードまたは基になるデータに関連付けるのに十分である必要があります。 VC の属性を使用して、HR システムでユーザー属性を完全にしたり、従業員に関するユーザー属性の正確さを検証したりできます。
外部 ID - 招待: 外部ユーザーがターゲット システムに招待されると、RP は招待トランザクションを表す一意の識別子を持つリンクを生成できます。 このリンクは、外部ユーザーのメール アドレスに送信できます。 この一意識別子は、VC 検証要求を招待レコードまたは基になるデータに関連付けて、プロビジョニング ワークフローを続行するのに十分である必要があります。 VC の属性を使用して、外部ユーザーの属性を検証したり、完全なものにしたりできます。
外部 ID - セルフサービス: 外部 ID がセルフサービスでターゲット システムにサインアップするときは (B2C アプリケーションなど)、VC の属性を使用してユーザー アカウントの初期属性を設定できます。 VC 属性を使用して、プロファイルが既に存在するかどうかを調べることもできます。
ターゲット ID システムとの相互作用: Web フロントエンドとターゲット ID システムの間のサービス間通信は、アカウントを作成することができるため、高い特権を持つシステムとしてセキュリティで保護する必要があります。 Web フロントエンドには、可能な限り最小の特権ロールを付与します。 次に例をいくつか示します。
Microsoft Entra で新しいユーザーを作成するには、RP Web サイトで、
User.ReadWrite.Allの MS Graph スコープと、認証方法をリセットするためのスコープUserAuthenticationMethod.ReadWrite.Allが付与されているサービス プリンシパルを使用できます。B2B コラボレーションを使用して Microsoft Entra ID にユーザーを招待するには、RP Web サイトで、招待を作成するための
User.Invite.Allの MS Graph スコープが付与されているサービス プリンシパルを使用できます。RP が Azure で実行されている場合は、マネージド ID を使用して Microsoft Graph を呼び出します。 マネージド ID により、コードまたは構成ファイルでサービス プリンシパルの資格情報を管理するときのリスクが軽減されます。 マネージド ID の詳細については、Azure リソースのマネージド ID に関する記事を参照してください。
組織内の価値の高いアプリケーションへのアクセス
組織内の機密性の高いアプリケーションにアクセスするためのその他の証拠として、検証可能な資格情報を使用できます。 たとえば、VC を使用すると、認定などの特定の条件の達成に基づいて、基幹業務アプリケーションへのアクセスを従業員に提供することもできます。
その他の要素
証明書利用者 Web フロントエンド: これは、ビジネス要件に基づいて、VC の提示と検証のために要求サービス API 呼び出しによって強化されたアプリケーションの Web フロントエンドです。
ユーザー アクセス承認ロジック: ユーザー アクセスの承認が行われ、VC 内のユーザー属性を使用して承認を決定するように拡張された、アプリケーション内のロジック レイヤー。
その他のバックエンド サービスと依存関係: アプリケーションのロジックの残りの部分を表します。通常、VC による ID 証明が組み込まれても変わりません。
デザインに関する考慮事項
目標: シナリオの目標によって、必要な資格情報と発行者の種類が決まります。 一般的なシナリオは次のとおりです。
承認: このシナリオでは、ユーザーは承認の決定を行うために VC を提示します。 トレーニングの完了を証明したり、特定の認定を保持したりするために設計された VM は、このシナリオに適しています。 VC 属性には、承認の決定と監査に役立つ詳細な情報が含まれている必要があります。 たとえば、VC は、個人がトレーニングされ、機密性の高い金融アプリにアクセスできることを証明するために使用されます。 アプリ ロジックでは、部門の要求できめ細かい承認を確認し、監査目的で従業員 ID を使用できます。
ID 検証の確認: このシナリオでの目標は、価値の高いアプリケーションにアクセスしようとしているユーザーが、最初にオンボードしたユーザーと本当に同じであることを確認することです。 本人確認発行者からの資格情報が適しています。 アプリケーションのロジックでは、VC の属性がアプリケーションにログインしたユーザーと一致することを検証する必要があります。
失効の確認: 機密性の高いリソースへのアクセスに VC を使用するときは、元の発行者で VC の状態を調べて、取り消された VC についてはアクセスを拒否するのが一般的です。 発行者を操作する場合は、シナリオの設計の一環として失効について明確に検討してください。
ユーザー エクスペリエンス: 機密性の高いリソースへのアクセスに VC を使用するときは、考慮できるパターンが 2 つあります。
ステップアップ認証: ユーザーは、既存の認証メカニズムを使用してアプリケーションとのセッションを開始します。 ユーザーは、ビジネス ワークフローの承認など、アプリケーション内での特定の高価値操作のために VC を提示する必要があります。 これは、そのような高価値操作をアプリケーション フロー内で簡単に特定および更新できるシナリオに適しています。
セッションの確立: ユーザーは、アプリケーションとのセッションを開始する一環として VC を提示する必要があります。 VC の提示はアプリケーション全体の性質が高価値である場合に適しています。
組織の境界の外側にあるアプリケーションへのアクセス
検証可能な資格情報は、別の組織のメンバーシップまたは雇用関係に基づいてアクセス権または特典を付与することを望む証明書利用者も使用できます。 たとえば、eコマース ポータルでは、特定の会社の従業員や特定の機関の学生などに、割引といった特典を提供できます。
検証可能な資格情報の分散型の性質により、フェデレーション関係を確立しなくても、このシナリオが可能になります。
その他の要素
証明書利用者 Web フロントエンド: これは、ビジネス要件に基づいて、VC の提示と検証のために要求サービス API 呼び出しによって強化されたアプリケーションの Web フロントエンドです。
ユーザー アクセス承認ロジック: ユーザー アクセスの承認が行われ、VC 内のユーザー属性を使用して承認を決定するように拡張された、アプリケーション内のロジック レイヤー。
その他のバックエンド サービスと依存関係: アプリケーションのロジックの残りの部分を表します。通常、VC による ID 証明が組み込まれても変わりません。
デザインに関する考慮事項
目標: シナリオの目標によって、必要な資格情報と発行者の種類が決まります。 一般的なシナリオは次のとおりです。
認証: このシナリオでは、特定の組織との雇用または関係を証明するために、ユーザーが VC を所有している必要があります。 この場合、対象の組織によって発行された VC を受け入れるように、RP を構成する必要があります。
承認: アプリケーションの要件に基づき、きめ細かな承認の決定と監査を行うために、アプリケーションで VC の属性が使用される場合があります。 たとえば、eコマース Web サイトが特定の場所にある組織の従業員に割引を提供している場合、VC の国/地域要求に基づいて割引の適格性を検証できます (存在する場合)。
失効の確認: 機密性の高いリソースへのアクセスに VC を使用するときは、元の発行者で VC の状態を調べて、取り消された VC についてはアクセスを拒否するのが一般的です。 発行者を操作する場合は、シナリオの設計の一環として失効について明確に検討してください。
ユーザー エクスペリエンス: ユーザーは、アプリケーションとのセッションを開始する一環として VC を提示することができます。 通常は、ユーザーが VC を持っていない場合に対応するために、セッションを開始する別の方法もアプリケーションで提供します。
アカウントの回復
検証可能な資格情報は、アカウント回復の手段として使用できます。 たとえば、ユーザーが自分のアカウントを回復する必要がある場合は、次の図に示すように、VC を提示する必要がある Web サイトにアクセスし、MS Graph API を呼び出すことによって Microsoft Entra 資格情報のリセットを開始できます。
Note
このセクションで説明するシナリオは、Microsoft Entra アカウントの回復に固有のものですが、他のシステムのアカウントの回復にもこの方法を使用できます。
その他の要素
アカウント ポータル: VC の提示と検証のための API の呼び出しを調整する Web フロントエンドです。 このオーケストレーションに、Microsoft Entra ID でアカウントを回復するための Microsoft Graph の呼び出しを含めることができます。
カスタム ロジックまたはワークフロー: ユーザー アカウントを更新する前と後の組織固有の手順が含まれるロジック。 カスタム ロジックは、承認ワークフロー、その他の検証、ログ記録、通知などが含まれる場合があります。
Microsoft Graph: アカウント回復の実行に使用される Microsoft Entra データにアクセスするための Representational State Transfer (REST) API とクライアント ライブラリが公開されます。
Microsoft Entra エンタープライズ ディレクトリ: アカウント ポータルで作成または更新されているアカウントが含まれる Microsoft Entra テナントです。
設計上の考慮事項
VC 属性と Microsoft Entra ID の関連付け: 発行者と連携して VC の属性を定義する場合は、ユーザーを識別する要求に同意していることを確認します。 たとえば、本人確認プロバイダー (IDV) が従業員のオンボード前に ID を検証する場合は、発行された VC に内部システムと照合できる要求が含まれていることを確認します。 要求は電話番号、住所、生年月日などにすることができます。 RP は、ソーシャル セキュリティ番号 (SSN) の最後の 4 桁など、このプロセスの一環として VC に見つからない情報を要求できます。
既存の Microsoft Entra 資格情報リセット機能での VC の役割: Microsoft Entra ID には、セルフサービス パスワード リセット (SSPR) 機能が組み込まれています。 検証可能な資格情報を使用すると、ユーザーが SSPR メソッドにアクセスできない場合や制御が失われた場合に回復する別の方法を提供できます。 ユーザーがコンピューターとモバイルの両方を紛失したシナリオでは、ユーザーは ID 証明発行者から VC を再び受け取り、それを提示してアカウントをリモートで回復できます。
同様に、VC を使用すると、ユーザーがパスワードなしで MFA 認証方法をリセットできる一時的なアクセス パスを生成できます。
承認: 資格情報の回復を進める前に RP によってチェックされるセキュリティ グループなどの承認メカニズムを作成します。 たとえば、特定のグループ内のユーザーにのみ、VC を使用してアカウントを回復する資格があります。
Microsoft Entra との対話: Web フロントエンドと Microsoft Entra ID の間のサービス間通信は、従業員の資格情報をリセットできるため、高い特権を持つシステムとしてセキュリティで保護する必要があります。 Web フロントエンドには、可能な限り最小の特権ロールを付与します。 次に例をいくつか示します。
認証方法をリセットするための MS Graph スコープの
UserAuthenticationMethod.ReadWrite.Allを付与されたサービス プリンシパルを使用するための機能を、RP Web サイトに与えます。 ユーザーを作成および削除できるUser.ReadWrite.Allは付与しないでください。RP が Azure で実行されている場合は、マネージド ID を使用して Microsoft Graph を呼び出します。 マネージド ID はコードまたは構成ファイルでサービス プリンシパルの資格情報を管理するときのリスクが軽減されます。 詳細については、Azure リソースのマネージド ID に関するページを参照してください。
ID の管理を計画する
証明書利用者に VC を組み込むときの IAM に関する考慮事項を次に示します。 通常、証明書利用者はアプリケーションです。
認証
VC の対象者は人間である必要があります。
人間は財布に VC を持っており、対話形式で VC を提示する必要があります。 On-Behalf-Of などの非対話型フローはサポートされていません。
承認
VC の提示の成功は、それ自体が粗い承認ゲートと見なされます。 VC の属性は、きめ細かな承認の決定に使用することもできます。
期限切れの VC がアプリケーションで意味を持つかどうかを判断します。持つ場合は、認可チェックの一部として、VC の
expクレーム (有効期限) の値を調べます。 有効期限が関係しない例の 1 つは、対象者が 18 歳以上かどうかを検証するための運転免許証のように、政府発行のドキュメントを要求する場合です。 VC の有効期限が切れている場合でも、生年月日のクレームは有効です。取り消された VC が承認の決定に意味を持つかどうかを判断します。
関係ない場合は、状態チェック API の呼び出しをスキップします (既定ではオン)。
関係する場合は、アプリケーションでの例外の適切な処理を追加します。
ユーザー プロファイル
提示された VC の情報を使用して、ユーザー プロファイルを作成できます。 属性を使用してプロファイルを作成する場合は、次の項目を考慮します。
発行される VC には、発行時点での属性のスナップショットが含まれます。 VC は有効期間が長いことがあり、属性の経過時間が、プロファイルの一部として受け入れて使用するのに十分な新しさであるかどうかを判断する必要があります。
対象者が RP とのセッションを開始するたびに VC を提示する必要がある場合は、VC 提示の出力を使用し、属性で非永続的なユーザー プロファイルを作成することを検討します。 非永続的なユーザー プロファイルは、保存時のユーザー プロパティの格納に関連するプライバシー リスクを軽減するのに役立ちます。 アプリケーションでは、サブジェクトの属性をローカルに保存する必要がある場合があります。 その場合は、アプリケーションに必要な要求のみを保存します。 VC 全体を保存しないでください。
アプリケーションで永続的なユーザー プロファイル ストアが必要な場合:
ユーザーの不変識別子として、
subクレームを使用することを検討します。 これは、対象者と RP の特定のペアに対して一定である、非透過的で一意の属性です。アプリケーションからユーザー プロファイルをプロビジョニング解除するメカニズムを定義します。 Microsoft Entra 確認済み ID システムには分散型の性質があるため、アプリケーション ユーザーのプロビジョニングにライフサイクルはありません。
VC トークンで返された個人データの要求を格納しないでください。
証明書利用者のロジックに必要なクレームだけを格納します。
パフォーマンスを計画する
他のソリューションと同様に、パフォーマンスについて計画する必要があります。 注目する領域としては、待機時間、スループット、スケーラビリティなどがあります。 リリース サイクルの初期フェーズでは、パフォーマンスを考慮する必要はありません。 ただし、ソリューションを導入したことにより多くの検証可能な資格情報が検証されるときは、パフォーマンス計画がソリューションの重要な部分になる可能性があります。
パフォーマンスを計画するときに以下の項目を考慮する必要があります:
Microsoft Entra 確認済み ID 発行サービスは、西ヨーロッパ、北ヨーロッパ、米国西部 2、米国中西部の各 Azure リージョンにデプロイされています。 待機時間を制限するには、最も近いリージョンに検証フロントエンド (Web サイト) とキー コンテナーをデプロイします。
スループットに基づくモデル:
VC 検証の容量は、Azure Key Vault サービスの制限の対象になります。
VC を検証するたびに、1 回の Key Vault 署名操作が必要になります。
スロットリングを制御することはできません。ただし、「Azure Key Vault のスロットル ガイダンス」を読んで、スロットリングがパフォーマンスに及ぼす影響について理解することをお勧めします。
信頼性を計画する
高可用性とディザスター リカバリーを最適に計画するため、次の項目をお勧めします:
Microsoft Entra 確認済み ID サービスは、西ヨーロッパ、北ヨーロッパ、米国西部 2、米国中西部、オーストラリア、日本の各 Azure リージョンにデプロイされています。 サポート Web サーバーとサポート アプリケーションは、それらのリージョンのいずれかにデプロイすることを検討します。具体的には、検証トラフィックが最も多く発生すると予想されるリージョンです。
可用性と冗長性の目標を設計するときは、「Azure Key Vault の可用性と冗長性」のベスト プラクティスを確認して組み込みます。
セキュリティの計画
セキュリティを設計するときは、次の点を考慮してください:
1 つのテナント内のすべての証明書利用者 (RP) は、同じ DID を共有するので、同じ信頼境界を持ちます。
Key Vault にアクセスする Web サイトに、専用のサービス プリンシパルを定義します。
Microsoft Entra 確認済み ID サービスと Web サイトのサービス プリンシパルのみが、Key Vault を使用して秘密キーでメッセージに署名するためのアクセス許可を持つ必要があります。
人間の ID 管理者には、Key Vault へのアクセス許可を割り当てないでください。 Key Vault のベスト プラクティスの詳細については、「Key Vault に関する Azure のセキュリティ ベースライン」を参照してください。
ソリューションのサポート サービスを管理するためのベスト プラクティスについては、「Microsoft Entra ID による Azure 環境のセキュリティ保護」を参照してください。
スプーフィングのリスクを軽減するには、次のようにします。
DNS 検証を実装して、ユーザーが発行者のブランドを識別しやすくします。
エンド ユーザーにとって意味のあるドメインを使用します。
分散型サービス拒否 (DDOS) と Key Vault リソース調整のリスクを軽減します。 すべての VC 提示要求により、サービスの制限を消費する Key Vault 署名操作が生成されます。 発行要求を生成する前に、代替の認証またはキャプチャを組み込むことにより、トラフィックを保護することをお勧めします。
運用を計画する
運用を計画するときは、監査の一部として資格情報検証の各試行をキャプチャする計画を立てることをお勧めします。 その情報を監査とトラブルシューティングに使用します。 さらに、顧客とサポート エンジニアが必要に応じて参照できる、一意のトランザクション識別子 (ID) を生成することを検討します。
運用計画の一部として、次の監視を検討します。
スケーラビリティに関して:
アプリケーションのエンドツーエンドのセキュリティ メトリックの一部として、失敗した VC 検証を監視します。
資格情報の検証のエンドツーエンドの待機時間を監視します。
信頼性と依存関係に関して:
検証ソリューションによって使用される基になる依存関係を監視します。
Azure Key Vault の監視とアラートに関する記事に従います。
セキュリティに関して:
Key Vault のログ記録を有効にして、署名操作を追跡するだけでなく、構成の変更を監視して警告します。 詳細については、Key Vault のログ記録を有効にする方法に関する記事を参照してください。
長期保有のため、Microsoft Sentinel などのセキュリティ情報イベント管理 (SIEM) システムにログをアーカイブします。
次のステップ
VC ソリューションの設計に関する詳細を確認する
検証可能な資格情報を実装する