mcpField
E
entra-verified-id

entra-verified-id

github.com/vinayaklattheセキュリティ17844 回インストール19 週間前に更新
リポジトリ

entra-verified-id について

オープン標準に基づく検証可能な資格情報プラットフォーム、Microsoft Entra Verified ID の ID フロー設計を支援するスキルです。バックチャネルで ID データを交換せずに、資格情報の発行と他の発行者による資格情報の検証を行えます。

主な機能

  1. 01デジタル資格情報の発行と検証
  2. 02資格情報スキーマと証明フローの設計
  3. 03資格情報の失効計画
  4. 04SDK を使った検証アプリの構築
  5. 05Conditional Access による提示要求

活用シーン

  1. 01リモート入社時の本人確認
  2. 02ヘルプデスクへの問い合わせなしでのアカウント復旧
  3. 03アクセス付与前の委託先資格情報の確認
  4. 04特権操作での Face Check 要求

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/vinayaklatthe/microsoft-security-skills --skill entra-verified-id

インストール後、Claude Code で/entra-verified-idを入力して読み込まれたか確認します。

詳細

Microsoft Entra Verified ID

Entra Verified ID は、オープンスタンダード（W3C Verifiable Credentials Data Model、Decentralized Identifiers、OpenID4VC）に基づいて構築された、Microsoft の検証可能なクレデンシャルプラットフォームです。組織はバックチャネル経由でユーザーの本人確認データを共有することなく、誰に対しても（従業員、契約社員、顧客）署名済みデジタルクレデンシャルを発行し、他者（Microsoft、政府機関、パートナー、自分のテナント）が発行したクレデンシャルを検証できます。

使用する場面

  • 高い信頼性が求められるオンボーディング（リモートでの新規採用者の本人確認）。
  • ヘルプデスクへの問い合わせなしでのアカウント復旧。
  • 組織間のアクセス（雇用主から VC を受け取った契約社員）。
  • 特権アクセスを付与する前のベンダー／パートナーの本人確認。
  • 持ち運び可能で、ユーザーが管理できるクレデンシャルを必要とする顧客向けシナリオ。

B2C のコンシューマー認証（entra-external-id）、標準的な従業員 ID（entra-id）、X.509 PKI（pki-design）には、このスキルを使用しないでください。

アーキテクチャの概要

テナントには分散識別子（DID）が割り当てられます。Key Vault の署名キーで、スキーマ（クレーム）、発行時にクレームを収集する方法を定義するルールファイル、ウォレットでの表示方法を定義する表示ファイルに従って、検証可能なクレデンシャルを作成します。ユーザーはクレデンシャルをMicrosoft Authenticator（既定のウォレット）に保持します。検証者（任意のアプリ／テナント）が QR コードまたはディープリンク経由でクレデンシャルを要求すると、ウォレットがそれを提示し、検証者は発行者の DID に基づいて署名を検証します。オプションの顔認証チェックでは、ウォレットにライブセルフィーと VC 内の写真クレームを照合させます。

進め方

  1. 発行者テナントを設定します。

    • ドメインの所有権を確認します（リンクされたドメインの証明を DID に紐付けます）。
    • Key Vault と署名キーをプロビジョニングし、Verified ID サービスにアクセス許可を付与します。
    • DID メソッドを選択します。did:web（ドメインに紐付ける方式で、エンタープライズに推奨）または did:ion。

  2. クレデンシャルのスキーマを設計します。 10 個ではなく、まずは 1 ～ 2 個のクレデンシャルから始めます。

    • 確認済み従業員（氏名、従業員 ID、事業部、発行日）。
    • 確認済み技能／資格（技能、有効期限）。 属性が増えるとプライバシーのリスクと失効処理の頻度が高まるため、クレームを過剰に含めないでください。

  3. 発行時のアテステーションフローを選択します。

    • ID Token（Entra） — サインイン後に Entra ID からクレームを取得します（従業員向けの場合に迅速です）。
    • ID Token Hint — アプリからクレームを提供します（カスタムデータストア）。
    • 自己アテステーション — ユーザーがクレームを入力します（保証レベルが最も低く、まれにしか使用しません）。
    • Verifiable Credential — 別の VC からクレームを取得します（再発行／ステップアップ）。
    • 本人確認パートナー（例：Microsoft マーケットプレース経由の LexisNexis、Onfido、IDEMIA）— リモートでのオンボーディング時に実際の本人確認を行います。

  4. 発行前に失効戦略を定めます。一括失効にはステータスリスト 2021方式を使用します。ライフサイクルイベントに備えます。たとえば、退職時には失効 API を呼び出します。

  5. 検証者アプリを構築します。 Web／モバイルアプリで QR コードを生成し、ユーザーが Authenticator でスキャンして、アプリが提示を受け取ります。.NET、Node.js、Java、Python の SDK を利用できます。

  6. 価値の高いユースケース（まずはここから始めましょう）：

    • リモートオンボーディング：候補者がパートナーを通じて本人確認を行い、確認済み従業員 VC を受け取ります。この VC を使って、初回の TAP なしの Entra ID セットアップ（パスキーのプロビジョニングを含む）を行います。
    • ヘルプデスクを介さないアカウント復旧：アカウントにロックアウトされたユーザーが確認済み従業員 VC を提示し、チケットを起票せずに MFA をリセットします。
    • 特権アクセスでの顔認証チェック：影響の大きい管理者操作の認可前に、顔認証チェックの提示を要求します。

  7. 認証コンテキストと認証強度を組み合わせて、条件付きアクセスと統合します。CA で機密性の高いリソースへのアクセス時に VC の提示を必須にできます。

セキュリティ対策

  • 発行者の署名キーは CA キーと同様に扱ってください。 漏えいすると、攻撃者があなたの名義で偽の VC を発行できます。Key Vault の HSM で保護し、アクセス ポリシーを分離し、Verified ID サービス プリンシパル以外によるキーの使用を検知するアラートを設定してください。
  • 正当な理由のない個人情報をクレデンシャルに含めないでください。 VC はウォレット内に長期間保存されるため、GDPR のデータ最小化原則が適用されます。
  • 発行前に失効の計画を立ててください。 ステータスリストのエンドポイントには常にアクセスできる必要があります。CRL と同様に扱ってください。
  • DID ドキュメントは公開されます。 機密性の高いエンドポイントやメタデータを含めないでください。
  • 現在、ウォレットは Microsoft Authenticator のみです（サードパーティの OpenID4VC ウォレットも登場しつつありますが、まだ相互運用性が広く確保されているわけではありません）。この制約を考慮して計画してください。
  • クレームが変更されるたびに再発行しないでください。 短期間有効な VC を使用するか、API 経由でアテステーションを更新してください。失効の頻発は避けてください。
  • Face Check には、VC に写真のクレームが必要です。 元の写真の来歴（人事システム、パートナーによる検証）が適切であることを確認してください。入力データが不適切だと、顔照合も不適切になります。
  • 検証者の同意画面は重要です。 ユーザーには、要求しているクレームが表示されます。最小限に抑えてください。

よくあるアンチパターン

  • 「20 個の属性を含む巨大なクレデンシャルを 1 つ発行する」 — プライバシー漏えいにつながり、変更のたびに再発行が必要になります。小さな VC を複数組み合わせてください。
  • 「オンボーディング時に『検証済み従業員』を自己申告させる」 — 保証がなく、攻撃者は好きな内容を入力できます。Entra ID またはパートナーのアテステーションを使用してください。
  • 「App Service の構成に署名キーを保存する」 — HSM を迂回し、監査もできません。必ず Key Vault を使用してください。
  • 「失効の仕組みがない」 — 退職した従業員が有効な VC を永久に保持することになります。初日からステータスリストと退職処理の自動化を導入してください。
  • 「信頼リストなしで、どの DID も検証者が受け入れる」 — なりすました発行者を受け入れてしまいます。信頼する発行者の DID を明示的に指定してください。
  • 「パスキー／FIDO2 の代わりに、日々のサインインに Verified ID を使用する」 — VC は アイデンティティの証明 に使うものであり、セッション認証には使いません。サインインには FIDO2／パスキーを使用してください（passkeys-fido2）。
  • 「リモートオンボーディングのコスト削減のため、本人確認パートナーを省く」 — 最も弱い部分は最初の信頼の確立です。パートナーのアテステーションにこそ価値があります。

プロンプトの例

  • Issue Verified Employee credentials to 5,000 staff and integrate revocation with HR-driven termination workflow.
  • Design a remote onboarding flow with a verification partner that issues a VC, followed by passkey provisioning and TAP-less first sign-in.
  • Implement help-desk-less MFA reset by presenting a Verified Employee VC.
  • Add Face Check to privileged access for Global Administrator activations.
  • Schema design for a contractor credential with skill, project, and expiry claims.
  • Stand up a verifier web app in .NET using the Verified ID Request Service.
  • Choose did:web vs did:ion for an enterprise issuer rollout.

Microsoft Learn

コメント

Markdown 対応