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