SSO・IDaaSLOCKED MSO

FIDO2認証完全実装ガイド【フィッシング耐性99%】

公開日: 2026年3月11日

パスワード認証はもはや過去のものです。フィッシング攻撃の巧妙化により、多くの企業が従来のパスワード+多要素認証 MFA では対応しきれない脅威に直面しています。FIDO2（Fast Identity Online 2）認証は、生体認証やセキュリティキーを使用することで、フィッシング攻撃に対してほぼ完全な耐性を実現できます。本記事では、FIDO2の技術仕様、認証器登録フロー、Attestation/Assertion の仕組み、実装パターン、企業導入の課題と対策を詳細に解説します。

FIDO2 の必要性：パスワード認証の限界

従来のパスワード認証の課題

多くの企業がいまだに従来のパスワード認証（＋MFA）に依存しています。

従来方式の主な課題：

フィッシング耐性の欠如： ユーザーが詐欺サイトにパスワードを入力してしまえば防止できない
ユーザー負担： 複雑なパスワード要件と定期的な変更で、メモ帳管理や使い回しが発生
MFA 疲労攻撃： 攻撃者が多数の MFA プッシュ通知を送信し、ユーザーが誤承認
SIM スワップ詐欺： SMS ベース MFA は SIM 乗っ取りで無効化される

国内の金融機関では、2023年のフィッシング被害が前年比 150% 増加、その多くがパスワード盗聴と SMS MFA 回避が原因でした。

FIDO2 認証による解決

FIDO2 は以下の特徴により、上記の課題を根本的に解決します。

フィッシング耐性 99.9%： ユーザーが認証器を物理的に操作するため、詐欺サイトでの認証は不可能
パスワード不要： 生体認証やセキュリティキーのみで認証を完結、ユーザー負担の劇的削減
フィッシング詐欺への耐性： URL 検証により、認証器が正規サイトのみで動作することを保証
プロトコルレベルのセキュリティ： 鍵交換から暗号化、署名検証まで HTTPS で保護

RFPテンプレート（無料）

IDaaS導入RFPテンプレート

IDaaS導入の社内稟議に使えるRFPテンプレート。SSO、MFA、プロビジョニングなどの要件を網羅したフォーマットです。

無料でダウンロード

FIDO2 の技術仕様：Attestation と Assertion

FIDO2 のプロトコル構成

FIDO2 は、以下 3 つの層から構成されます。

CTAPレイヤー（Client to Authenticator Protocol）
- クライアント（PC・スマートフォン）と認証器の通信プロトコル
- USB、NFC、Bluetooth などの物理インターフェース経由で通信
WebAuthn API（Web Authentication API）
- Web ブラウザが CTAP を呼び出すための標準 JavaScript API
- W3C 標準として 2019 年に完成
認証器（Authenticator）
- FIDO2 に対応したセキュリティキー、スマートフォン、Windows Hello など

Attestation フロー：認証器の登録

FIDO2 認証の初期段階では、ユーザーが認証器をサービスに登録します。

Attestation プロセス（8 ステップ）：

1. ユーザーが登録を開始
     ↓
2. サーバーが Challenge（ランダムなバイト列）を生成
   Challenge = random(32 bytes)
     ↓
3. サーバーが challenge + その他パラメータを WebAuthn API に渡す
   navigator.credentials.create({
     publicKey: {
       challenge: ArrayBuffer,
       rp: { name: "Example Corp", id: "example.com" },
       user: { id, name, displayName },
       pubKeyCredParams: [
         { alg: -7, type: "public-key" }  // ES256
       ],
       timeout: 60000,
       attestation: "direct"
     }
   })
     ↓
4. ブラウザがユーザーに認証器の使用を促す
   "セキュリティキーをタップしてください"
     ↓
5. 認証器がユーザー確認（PIN または生体認証）を実施
   - セキュリティキー：PIN コード入力
   - Windows Hello：顔認証・指紋認証
   - スマートフォン：生体認証
     ↓
6. 認証器が以下を生成・署名
   - PublicKey（公開鍵）
   - PrivateKey（秘密鍵）
   - Attestation Object（認証器の証明データ）

   signature = sign(attestation_data + client_data_json, private_key)
     ↓
7. ブラウザが AttestationObject をサーバーに送信
   {
     "fmt": "fido-u2f",
     "attStmt": { "sig": "..." },
     "authData": { "credentialId": "...", "credentialPublicKey": "..." }
   }
     ↓
8. サーバーが Attestation を検証
   - 署名の検証（認証器の公開鍵を使用）
   - attestation object の完全性確認
   - challenge の検証（元の challenge と一致するか）
   - credentialPublicKey を保存

重要ポイント：

Attestation Object には、認証器の製造者情報が含まれる
企業が FIDO キーの品質を保証したい場合、特定メーカーのみを許可できる
ただし、プライバシー保護の観点から Attestation を完全検証する企業は少数派

Assertion フロー：認証

ログイン時には、以前登録した認証器を使用して認証を完結させます。

Assertion プロセス（7 ステップ）：

1. ユーザーがログイン画面で ID を入力
     ↓
2. サーバーが Credential ID と Challenge を WebAuthn API に渡す
   navigator.credentials.get({
     publicKey: {
       challenge: ArrayBuffer,
       timeout: 60000,
       userVerification: "preferred",
       allowCredentials: [
         { id: credentialId, type: "public-key", transports: ["usb"] }
       ]
     }
   })
     ↓
3. ブラウザがユーザーに認証器の使用を促す
   "セキュリティキーをタップしてください"
     ↓
4. 認証器がユーザー確認を実施（再度 PIN/生体認証）
     ↓
5. 認証器が署名を生成
   signature = sign(authenticator_data + client_data_json, private_key)

   authenticator_data = {
     "rpIdHash": hash("example.com"),
     "flags": 0x45,  // User Present, User Verified
     "signCount": 42
   }
     ↓
6. ブラウザが AssertionResponse をサーバーに送信
   {
     "id": credentialId,
     "clientExtensionResults": {},
     "response": {
       "clientDataJSON": {...},
       "authenticatorData": "...",
       "signature": "..."
     }
   }
     ↓
7. サーバーが Assertion を検証
   - challenge の一致確認
   - signature の検証（登録済み public key を使用）
   - signCount の確認（クローン検出）
   - rpIdHash の検証

クローン検出（Clone Detection）：

各認証器は signCount を保持し、ログイン時にインクリメントされます。サーバーが signCount の逆行を検出した場合、認証器がクローンされた可能性があります。

# サーバー側の検証ロジック
stored_sign_count = 42
received_sign_count = 41

if received_sign_count <= stored_sign_count:
    raise CloneDetectedException("認証器がクローンされた可能性があります")

対応認証器の選定基準

セキュリティキーの比較

FIDO2 対応セキュリティキーは複数存在し、機能・価格が異なります。

主要キー比較表：

製品	メーカー	価格	NFC	Bluetooth	耐久性	推奨用途
YubiKey 5 NFC	Yubico	6,000円	○	✕	★★★★★	エンタープライズ
YubiKey Security Key C	Yubico	3,000円	✕	✕	★★★★★	汎用・コスト重視
Titan Security Key	Google	5,000円	○	○	★★★★	Google サービス連携
FIDO2 Key	SoloKeys	2,000円	✕	✕	★★★	オープンソース志向
Windows Hello	Microsoft	無料	-	-	★★★★	企業 Windows PC
Apple Face ID	Apple	無料	-	-	★★★★★	Apple デバイス

企業導入で推奨される選定基準：

汎用性： USB-C、USB-A、NFC に対応（全従業員のデバイス環境をカバー）
耐久性： 企業での使用に耐える（IP67 等級、落下耐性）
サポート体制： メーカーの日本語対応、故障時の交換対応
価格： 1 本 2,000～6,000 円程度
管理機能： 複数キー登録、バックアップキー、リセット機能

スマートフォン・PC 内蔵認証器

FIDO2 認証器はセキュリティキーだけではありません。

デバイス内蔵タイプ：

Windows Hello（Windows 11/10）
- 顔認証・指紋認証を使用
- セキュリティキー不要だがデバイスを紛失すると認証不可
Apple Face ID・Touch ID（iOS/Mac）
- Face ID：精度 99.9999%、プライベートキーはセキュアエンクレーブに保存
- Touch ID：指紋認証、Face ID よりコンパクト
Android 生体認証（Android 7.0 以上）
- 指紋認証・顔認証
- メーカー・機種による対応状況の差あり

デバイス内蔵型の利点・欠点：

項目	利点	欠点
追加コスト	無料	-
デバイス紛失時	-	認証できない
ユーザー満足度	高い（追加デバイス不要）	-
クローン耐性	高い	-

推奨戦略：

企業導入では、セキュリティキー（物理的な第二因子）+ デバイス内蔵（利便性）の組み合わせが最適です。

実装パターン別の対応状況

パターン 1：FIDO2 のみ（パスワードレス認証）

セキュリティレベルが最高ですが、ユーザー負担もあります。

適用シーン：

金融機関、政府機関などのハイセキュリティ環境
リモートアクセスやテレワークが少ない部門

実装フロー：

登録時：ユーザー確認 → 認証器登録 → 認証器設定完了
ログイン時：認証器使用 → ログイン完了

パターン 2：FIDO2 + TOTP（多層防御）

FIDO2 をメイン、TOTP（時間ベース OTP）をバックアップとする方式。

適用シーン：

大企業のホワイトカラー部門
FIDO2 キー紛失時のリカバリ対応

実装フロー：

登録時：FIDO2 キー登録 → TOTP アプリ登録 → バックアップコード配布
ログイン時：
  通常：FIDO2 キー使用
  キー紛失時：TOTP コード入力
  それも失った場合：バックアップコード使用

パターン 3：段階的移行（パスワード→FIDO2）

既存環境からの段階的なマイグレーション。

移行フェーズ：

フェーズ	期間	認証方式	対象
Phase 1	1～2 ヶ月	パスワード + SMS MFA	全従業員
Phase 2	2～3 ヶ月	パスワード + FIDO2（オプション）	IT部門、セキュリティ部門
Phase 3	3～4 ヶ月	FIDO2 強制	全従業員

導入課題と対策

課題 1：セキュリティキーの紛失・破損

物理デバイスなので、紛失・破損リスクが存在します。

対策：

複数キー登録
- 1 人当たり 2 本のセキュリティキーを配布
- 1 本が紛失しても別のキーでログイン可能
バックアップキー管理
- 予備キーを金庫に保管
- 紛失時は管理者が交換
保険・補償
- 企業が 1 本 3,000 円のキーを配布している場合、従業員 500 人で計 150 万円
- 紛失率を 5～10% と見積もると、交換費用は年 7.5～15 万円程度

課題 2：ユーザー教育と受け入れ

技術的に優れていても、ユーザーが受け入れなければ成功しません。

対策：

段階的教育
- Week 1：FIDO2 の概要説明（メール + イントラネット記事）
- Week 2：実地ワークショップ（小グループでの実際の操作）
- Week 3：個別サポート（サポートメール・チャット開始）
導入効果の可視化
- フィッシング被害の削減実績
- ユーザー満足度調査（アンケート）
- コスト削減効果の共有

課題 3：既存システムとの互換性

古いシステムや特殊なアプリケーションが FIDO2 に未対応の場合があります。

対策：

システム互換性調査
- 現在使用中のすべてのアプリケーション・サービスを洗い出し
- FIDO2 対応状況をベンダーに問い合わせ
段階的アップデート
- FIDO2 非対応システムは除外して段階的導入
- ベンダーのアップデート完了後に組み込み
パスフレーズによるフォールバック
- FIDO2 アクセス不可の場合、強化されたパスフレーズ（32文字以上）での認証を許可

LOCKED MSO での FIDO2 実装

標準搭載機能

LOCKED MSO は FIDO2（WebAuthn）認証を標準搭載しています。

主要機能：

WebAuthn API 統合： 最新の W3C 標準に完全準拠
マルチプロトコル対応： SAML、OIDC、OAuth 2.0 と並行して FIDO2 を利用可能
管理画面での設定： 複雑な実装を不要、GUIで簡単設定
クローン検出： signCount による認証器クローン検出
日本語対応： ドキュメント、UI、サポート全て日本語

設定手順

基本設定は 5 ステップで完了：

管理画面にログイン
- URL: https://console.locked.jp/admin
「セキュリティ」→「WebAuthn/FIDO2」を選択
- リライングパーティ ID 確認（example.com）
- リライングパーティ名設定（会社名など）
FIDO2 認証器の対応設定
- USB セキュリティキー：有効
- NFC セキュリティキー：有効
- デバイス内蔵（Windows Hello 等）：有効
- カスタム条件：設定可能
ユーザー登録フロー設定
- 必須にするか：オプションか
- バックアップ認証器要求：有効/無効
- クローン検出時の動作：通知/ブロック
テスト
- テストユーザーで登録・ログインを実施
- 複数の認証器タイプ（USB キー、Windows Hello など）で動作確認

カスタマイズ例

高度なセキュリティ設定（金融機関向け）：

webauthn_config:
  # 認証器の条件
  allowed_authenticators:
    - type: "security-key"
      manufacturers: ["Yubico"]  # Yubico 製キーのみ許可
      features: ["uv"]  # ユーザー確認機能必須

  # ポリシー
  policies:
    require_backup_key: true  # バックアップキー必須
    clone_detection: "BLOCK"  # クローン検出時はブロック
    sign_count_verification: true  # signCount検証を有効

  # UI/UX
  user_verification: "required"  # ユーザー確認を必須化

実装企業の事例

事例 1：大手銀行（従業員 3,000 名）

導入前：

フィッシング被害：年間 30～40 件
従業員のパスワード変更頻度が多く、パスワード忘却が月 100 件

LOCKED MSO + FIDO2（YubiKey）導入：

全従業員に YubiKey 5 NFC を配布
段階的移行：3 ヶ月で FIDO2 への完全移行
バックアップとして TOTP アプリも登録

導入結果（1 年後）：

フィッシング被害：0 件（100% 削減）
パスワード関連トラブル：月 5 件未満（95% 削減）
ユーザー満足度：78%（「便利になった」という評価）
セキュリティ部門の作業時間：年 500 時間削減

事例 2：IT 企業（従業員 1,500 名、リモートワーク 70%）

導入前：

リモートワーク従業員のアカウント乗っ取り：月 3～5 件
VPN + パスワード + SMS MFA でも不十分

LOCKED MSO + FIDO2（Windows Hello + YubiKey）導入：

PC 内蔵認証器（Windows Hello）をメイン
セキュリティキーをバックアップ
リモートワーク環境での多層認証

導入結果（6 ヶ月後）：

アカウント乗っ取り：0 件（100% 削減）
ユーザー負担削減：ログイン時間 30 秒 → 5 秒
VPN コネクション成功率：95% → 99.5%

運用のベストプラクティス

日次監視項目

新規キー登録申請の承認状況
キー紛失報告への対応（1 日以内に対応）
クローン検出アラートの確認

月次レビュー項目

FIDO2 利用率の監視（目標 95% 以上）
キー紛失率の監視（目標 5% 以下）
ユーザー満足度調査

まとめ：FIDO2 でフィッシングに強い企業へ

FIDO2 認証は、パスワード認証と比べてセキュリティが圧倒的に優れています。フィッシング耐性 99.9%、ユーザー負担の削減、パスワード関連トラブルの 95% 削減など、導入効果は明白です。

LOCKED MSO を活用することで、複雑な実装作業を避け、3～4 ヶ月で全社導入が可能です。初年度から年間 500 万～1,000 万円のコスト削減と、セキュリティインシデント対応の根本的な改善が実現できます。

FIDO2認証完全実装ガイド【フィッシング耐性99%】

FIDO2 の必要性：パスワード認証の限界

従来のパスワード認証の課題

FIDO2 認証による解決

IDaaS導入RFPテンプレート

FIDO2 の技術仕様：Attestation と Assertion

FIDO2 のプロトコル構成

Attestation フロー：認証器の登録

Assertion フロー：認証

対応認証器の選定基準

セキュリティキーの比較

スマートフォン・PC 内蔵認証器

実装パターン別の対応状況

パターン 1：FIDO2 のみ（パスワードレス認証）

パターン 2：FIDO2 + TOTP（多層防御）

パターン 3：段階的移行（パスワード→FIDO2）

導入課題と対策

課題 1：セキュリティキーの紛失・破損

課題 2：ユーザー教育と受け入れ

課題 3：既存システムとの互換性

LOCKED MSO での FIDO2 実装

標準搭載機能

設定手順

カスタマイズ例

実装企業の事例

事例 1：大手銀行（従業員 3,000 名）

事例 2：IT 企業（従業員 1,500 名、リモートワーク 70%）

運用のベストプラクティス

日次監視項目

月次レビュー項目

まとめ：FIDO2 でフィッシングに強い企業へ

外部参考リンク

関連記事

この課題、LOCKEDで解決できます

LOCKEDシリーズの詳細資料を無料でダウンロード

関連記事

MFA運用完全ガイド【TOTP/FIDO2/SMS比較と段階導入】

パスワードレス認証で不正ログイン完全防止【実装ガイド】

OTP運用ガイド完全版【TOTP/HOTP選択と実装】

パスワードセルフサービス（SSPR）完全ガイド【運用負荷70%削減】

アクセス制御ルール完全ガイド【12項目で柔軟な権限管理実現】

Azure AD SAML連携完全手順【証明書管理までの全手順】

まずは資料で詳細を確認