EntraID条件付きアクセスゼロトラストセキュリティYubikey

専用FIDO2キーを登録する方法

12 分で読めます

Microsoft Entra IDで特定のFIDO2キーだけを許可するための設定方法を、Yubikeyを例に解説します。AAGUIDの調べ方とよくあるハマりポイントもまとめます。

はじめに

Entra ID で「会社が支給した特定のセキュリティキーだけを許可したい」という要件、地味にありがちです。 個人所有の安価なFIDO2キーや出所の怪しいキーを勝手に登録されては困るので、企業としては「このベンダーのこの型番しか認めない」と縛りたいわけです。自分も過去の案件で、特権アカウント用に「IT部門が検証済みのYubikeyのみ登録可」という要件を実装したことがあります。

この記事では、そもそもFIDO2とは何かに軽く触れたうえで、Entra IDで「特定モデルのセキュリティキーだけを許可する」ための設定方法と、ベンダーのAAGUIDをどこで調べるかを、Yubikeyを例にまとめます。条件付きアクセスの設計を書いた「条件付きアクセスポリシーの設計パターン」のパターン5を実装する前提として読んでもらえればと思います。

FIDO2とは

FIDO2は FIDO Alliance が策定した認証規格です。ざっくり言うと「パスワードの代わりに、物理デバイス（セキュリティキー）とバイオメトリクスを使って強い認証を行うための規格」と理解してもらえれば大外ししません。Webブラウザ向けの WebAuthn と、クライアントとデバイスの間のプロトコルである CTAP2 の2つを組み合わせて成り立っています。

FIDO2の良いところは、

  • フィッシングに強い：署名にオリジン情報が含まれるため、偽サイトで抜いたリクエストを本物のサイトで使い回せない
  • 中央サーバーに秘密情報が残らない：秘密鍵はキー内部のセキュアエレメントに保存され、外に出ない
  • 記憶する必要がない：ユーザーはPINやタッチ操作だけで済む

という点です。もはや「強いMFAはSMS OTP」という時代ではなく、「フィッシング耐性がある＝FIDO2（またはパスキー）」という位置付けが当たり前になってきました。

Entra ID でも FIDO2セキュリティキーはサインインの一次認証として使うことができ、パスワードレス運用を目指す企業では必須の道具になっています。

AAGUIDとは

AAGUID（Authenticator Attestation GUID）は、FIDO2認証器を一意に識別するためのGUID（グローバル一意識別子）です。ベンダーや製品モデルごとに異なる 値が割り当てられていて、認証時にこのAAGUIDを見ることで、「このキーはYubico社のYubiKey 5 NFCである」といった情報が判別できます。

Entra IDには、このAAGUIDをフィルターとして使う仕組みがあります。要するに「許可したいAAGUIDだけをリストに入れ、それ以外のFIDO2キーは登録できないようにする」ことが可能です。

ベンダーごとのAAGUIDは、基本的に各セキュリティキーベンダーが公式ドキュメントで公開しています。例えば Yubico は「YubiKey Hardware FIDO2 AAGUIDs」というページでモデルごとの値を公開しているので、「yubikey aaguid」で検索すると一覧にたどり着きます。Feitian、Token2、SoloKeys なども同様に公式サイトで公開しています。

AAGUIDを集めてくる時のコツは、同じ製品ラインでも世代・インターフェースごとにAAGUIDが違う ことを忘れないことです。例えばYubiKey 5 NFCとYubiKey 5C NFCでは別のAAGUIDが割り当てられているので、「会社支給」として配布する製品の型番を全部洗い出して、対応するAAGUIDを全部集めてくる必要があります。ここを抜けると「なぜか自分のキーだけ登録できない」という問い合わせが飛んできます。

Entra ID側の設定手順

それでは実際にEntra ID側の設定に進みます。

1. FIDO2認証方法を有効化する

まずは、Entra IDのテナントで「FIDO2セキュリティキー」認証方法そのものを有効化しておく必要があります。

  1. Entra ID 管理センター（entra.microsoft.com）にサインイン
  2. 左メニューから 保護 → 認証方法 → ポリシー を開く
  3. 一覧から 「FIDO2 セキュリティキー」 を選択
  4. 「有効にする」を はい に
  5. ターゲットでユーザー全員か、特定のグループを選択（自分の案件では特権ユーザー用グループのみ対象にするケースが多いです）

2. 詳細オプションでAAGUIDの強制を設定する

「FIDO2 セキュリティキー」の設定画面で、「構成」タブ を開くと詳細オプションが出てきます。ここで次のように設定します。

  • 認証器の構成証明を強制する：オン（これがオンでないとAAGUIDフィルタが信用できません）
  • キーの制限を強制する：オン
  • 許可または制限：「許可」を選択
  • AAGUIDを追加：ここに、許可したいセキュリティキーのAAGUIDを一つずつ入力

「キーの制限を強制する」をオンにしたうえで「許可」リストにAAGUIDを入れると、そのリストに 載っていないセキュリティキーは登録自体を拒否される ようになります。これで「会社支給の特定モデルしか登録できない」という状態が作れます。

3. 既存で登録されているキーへの影響に注意

ここは一度ハマったので強調しておきます。 上記の設定を入れた後、既存で既にFIDO2登録されていて、リストにAAGUIDが含まれていないキー は、新しく認証しようとすると失敗します。つまり、「昨日まで使えていたセキュリティキーが突然弾かれる」という事象が発生しえます。

そのため、設定を適用する前に、必ず次の順序で進めるのが安全です。

  1. 事前にテナント内で誰が何のFIDO2キーを登録しているかを棚卸しする（ユーザー > 認証方法 で確認）
  2. 許可したいAAGUIDを全てリスト化する
  3. 段階ロールアウト：まず小規模なパイロットグループに適用
  4. パイロット問題なければ、全ユーザー向けに展開

テナント全体に適用する前に必ずパイロットを挟むのは、条件付きアクセスと同じ原則です。「影響範囲の可視化→段階展開」はEntra ID系の設定ではいつでも正しい姿勢だと思っています。

AAGUIDを調べる具体的な方法

AAGUIDを集めてくる方法は大きく3つあります。

方法1：ベンダーの公式ドキュメントを見る

一番確実なのがこれです。YubicoなどのメジャーなベンダーはAAGUID一覧を公式サイトで公開しています。「ベンダー名 AAGUID」で検索すれば一覧ページにたどり着けます。 公式に載っているということは、ベンダーが保証している値なので、設定ミスで配布後にハマるリスクが小さいです。提案資料に「Yubico公式ドキュメントに記載されているAAGUID」と書けるので、顧客への説明コストも下がります。

方法2：実際に手元のキーを登録して確認する

Entra IDのユーザー認証方法画面では、ユーザーが登録済みのFIDO2キーのAAGUIDを確認できます。手元に現物があるなら、テスト用テナントに一度登録してみて、そこで見えているAAGUIDをコピーする、というアプローチも現実的です。新モデルでベンダー公式にまだ情報が無い時に役立ちます。

方法3：fido-mds（FIDO Metadata Service）から引く

FIDO Allianceは「FIDO Metadata Service」というリポジトリを提供しており、認証済みの認証器のメタデータが全部集約されています。ここにアクセスすれば機械的に全AAGUIDを取得することができますが、正直、ベンダー公式で済むならそちらの方が速いです。大規模にCI的な管理をしたい場合に選択肢として覚えておくくらいで良いと思います。

条件付きアクセスと組み合わせる

AAGUIDによる登録制限は、あくまで「どのキーを登録できるか」を縛るものです。「どのキーでサインインさせるか」を縛るには、もう一つ条件付きアクセス側の認証強度を組み合わせます。

具体的には、

  1. Entra IDの 認証強度 でカスタムの認証強度を作成する（例：FIDO2-Corp-Issued）
  2. その認証強度のメンバーとして、使用を許可したいAAGUIDを指定する
  3. 条件付きアクセスで、対象ユーザー／アプリ／強度＝FIDO2-Corp-Issued を指定

この組み合わせで「会社支給のYubikeyでなければ業務アプリにサインインできない」というかなり厳しめの設計ができます。特権アカウントに適用しているケースをよく見ますし、自分もこのパターンを提案することが多いです。

実装時にやった検証手順

自分が実案件で適用する前にやった検証内容を、メモレベルで残しておきます。同じことを繰り返し説明するのが面倒なので、テンプレ化してあります。

  1. テスト用テナントに許可AAGUIDリストを設定
  2. 許可リストに入っているキーで登録 → 成功することを確認
  3. 許可リストに入っていないキー（私物含む）で登録を試行 → 拒否されることを確認
  4. 既に登録済みキーのサインイン挙動を確認（許可リスト外であれば拒否される）
  5. 条件付きアクセスで認証強度を要求したフローでサインイン → 通ることを確認
  6. 予備キーを紛失したシナリオでの復旧手順が現実的か確認

ここまでやっておくと、顧客からの質問でだいたい詰まることはなくなります。特に「既存登録済みキーへの影響」は必ず聞かれるので、事前に画面キャプチャまで取っておくとスムーズです。

運用面の気をつけポイント

最後に、実運用で「これはやっておいたほうがいい」と思ったポイントをいくつか。

  • 予備キーを必ず用意する：1人1本運用にすると、キーを紛失した時に復旧手段が無くなります。メイン1本・予備1本が最低ラインです。予備キーの保管場所と、紛失時のエスカレーションフローを運用手順書に書いておきましょう。
  • 在庫管理を徹底する：許可AAGUIDを限定する以上、会社で配布した現物がどこにあるかを管理する必要があります。Excelでも構わないので、「誰にいつ何番の個体を配ったか」を追えるようにしておくと、紛失時の対応が楽です。
  • AAGUIDの更新を運用プロセスに組み込む：セキュリティキーは新モデルが出るたびにAAGUIDも増えます。調達チームが新しいロットを仕入れた時に、IT側で許可リストを更新する、というフローを事前に握っておくと運用事故が減ります。
  • Break Glassアカウントはこのポリシーから除外：条件付きアクセスの定番ですが、緊急用アカウントは必ず除外します。これを忘れるとテナントそのものから締め出される可能性があります。

まとめ

AAGUIDベースのFIDO2登録制限は、「特権アカウントだけはフィッシング耐性の強い認証のみで守りたい」という現場要件に対して、非常に有効な手段です。設定そのものは簡単ですが、「既存のキーへの影響を正確に把握する」「AAGUIDを漏れなく集める」「予備キーの運用まで考える」の3点を丁寧にやるだけで、事故率は大きく下がります。

個人的にはパスワードレスの本命はパスキーだと思っていますが、ハードウェアキーならではの「物理的な安心感」「紛失時の影響範囲の分かりやすさ」は、今でも特権ユーザーにはちょうど良い選択だと感じます。条件付きアクセスのパターン5と組み合わせて、ぜひ現場で活用してみてください。