ゼロトラストセキュリティにおいて、アイデンティティの検証は最も重要な柱の一つです。パスワードのみの認証は、フィッシング、クレデンシャルスタッフィング、パスワードスプレー攻撃など、多くの脅威に対して脆弱であることが知られています。強固な認証基盤を構築するためには、多要素認証(MFA)の導入と、さらに進んだパスワードレス認証への移行が不可欠です。

本記事では、ゼロトラストにおける認証強化について以下の内容を解説します。

  • 多要素認証(MFA)の種類と各認証要素の特徴
  • TOTP、FIDO2/WebAuthn、パスキーの仕組みと違い
  • パスワードレス認証のメリットと導入時の考慮点
  • Microsoft Entra ID、Oktaでの設定例と実装パターン
  • 組織への段階的な導入アプローチ

この記事を読むことで、MFAの重要性を理解し、パスワードレス認証を含む強固な認証基盤の設計ができるようになります。

前提知識

本記事を理解するために、以下の知識があることを前提としています。

  • ゼロトラストの基本原則を把握している
  • 認証と認可の違いを理解している
  • IAMとIdPの基本的な役割を知っている

アイデンティティ管理の基礎については、ゼロトラストにおけるアイデンティティ管理 - IAMとIdPの基礎を先に読むことをお勧めします。

期待される学習成果

本記事を読み終えると、以下のことができるようになります。

  1. MFAの3つの認証要素を説明し、適切な組み合わせを選択できる
  2. TOTP、FIDO2/WebAuthn、パスキーの仕組みと違いを理解できる
  3. パスワードレス認証のセキュリティ上のメリットを論理的に説明できる
  4. 組織にMFA・パスワードレス認証を導入する際の考慮点を把握できる
  5. Microsoft Entra IDやOktaでの設定方法の概要を理解できる

なぜMFAがゼロトラストに不可欠なのか

パスワードのみの認証は、現代のサイバー攻撃に対して十分な防御を提供できません。Verizonの2024年データ侵害調査報告書によると、侵害の主要な要因としてクレデンシャルの窃取と脆弱性の悪用が増加しています。

パスワード認証の限界

パスワード認証には以下のような根本的な問題があります。

脅威 説明 影響
フィッシング 偽サイトでパスワードを窃取 正規ユーザーになりすまし
クレデンシャルスタッフィング 流出したパスワードリストで試行 大規模な不正アクセス
パスワードスプレー よく使われるパスワードで多数のアカウントを試行 アカウントロック回避
ブルートフォース 総当たり攻撃 弱いパスワードの突破
ソーシャルエンジニアリング 人間の心理を悪用 パスワードの詐取

MFAによるセキュリティ強化

MFAは、パスワードが漏洩した場合でも、追加の認証要素により不正アクセスを防止します。

flowchart LR
    subgraph attack["攻撃者"]
        stolen["盗まれた<br/>パスワード"]
    end
    
    subgraph auth["認証システム"]
        factor1["第1要素<br/>パスワード"]
        factor2["第2要素<br/>所持・生体"]
        decision["アクセス判定"]
    end
    
    subgraph result["結果"]
        deny["アクセス拒否"]
    end
    
    stolen -->|"パスワード入力"| factor1
    factor1 -->|"追加認証要求"| factor2
    factor2 -->|"認証失敗"| decision
    decision --> deny

MFAの3つの認証要素

MFAは、複数の異なる種類の認証要素を組み合わせることで、セキュリティを強化します。認証要素は大きく3つのカテゴリに分類されます。

知識要素(Something You Know)

ユーザーが「知っている」情報に基づく認証です。

代表例

  • パスワード
  • PIN(Personal Identification Number)
  • 秘密の質問への回答
  • パターン(スマートフォンのロック解除パターン)

特徴

  • 導入コストが低い
  • ユーザーが忘れる可能性がある
  • 第三者に教えてしまうリスク(フィッシング等)
  • 推測される可能性がある

所持要素(Something You Have)

ユーザーが「持っている」物理的なデバイスや仮想的なトークンに基づく認証です。

代表例

  • スマートフォン(認証アプリ)
  • ハードウェアセキュリティキー(YubiKey等)
  • ICカード
  • ワンタイムパスワード(OTP)生成デバイス
  • SMS/メールで送信されるコード

特徴

  • 物理的な所持が必要
  • 紛失・盗難のリスク
  • デバイスの購入・配布コスト
  • リモートからの窃取が困難

生体要素(Something You Are)

ユーザーの身体的特徴に基づく認証です。

代表例

  • 指紋認証
  • 顔認証
  • 虹彩認証
  • 声紋認証
  • 静脈パターン認証

特徴

  • 忘れることがない
  • 他者への譲渡が困難
  • 偽造が困難(高度な技術が必要)
  • プライバシーへの配慮が必要
  • 生体情報の変化(怪我、加齢)への対応が必要

認証要素の組み合わせ

真のMFAは、異なるカテゴリの認証要素を組み合わせることで実現します。

組み合わせ セキュリティレベル
知識 + 所持 パスワード + SMS OTP
知識 + 生体 パスワード + 指紋 中〜高
所持 + 生体 セキュリティキー + 指紋
知識 + 所持 + 生体 パスワード + セキュリティキー + 顔認証 最高

同じカテゴリ内の複数要素(例:パスワード + 秘密の質問)は、真のMFAとは見なされません。

主要なMFA技術の解説

TOTP(Time-based One-Time Password)

TOTPは、時刻に基づいて一定間隔(通常30秒)で変化するワンタイムパスワードを生成する方式です。RFC 6238で標準化されています。

sequenceDiagram
    participant User as ユーザー
    participant App as 認証アプリ
    participant Server as サーバー
    
    Note over User,Server: 初期セットアップ(一度だけ)
    Server->>User: QRコード表示<br/>(シークレットキー)
    User->>App: QRコードスキャン
    App->>App: シークレットキー保存
    
    Note over User,Server: 認証時
    User->>Server: ユーザー名 + パスワード
    Server->>User: OTP入力要求
    App->>App: 現在時刻 + シークレットキー<br/>→ TOTP生成
    User->>Server: TOTP入力
    Server->>Server: 同じアルゴリズムで<br/>TOTPを計算・検証
    Server->>User: 認証成功

TOTPの仕組み

  1. サーバーとクライアントで共通のシークレットキーを共有
  2. 現在の時刻(Unix時間)を30秒単位で区切った値を取得
  3. シークレットキーと時刻値からHMAC-SHA1でハッシュを計算
  4. ハッシュから6桁の数字を抽出

メリット

  • 広く普及しており、多くのサービスで対応
  • オフラインで動作可能
  • 導入コストが低い(無料の認証アプリ多数)

デメリット

  • シークレットキーが漏洩すると危殆化
  • フィッシングサイトにOTPを入力してしまうリスク
  • 時刻同期が必要

代表的な認証アプリ

  • Google Authenticator
  • Microsoft Authenticator
  • Authy
  • 1Password

FIDO2/WebAuthn

FIDO2は、FIDO Allianceが策定したパスワードレス認証の標準規格です。WebAuthnはそのWeb API仕様で、W3Cにより標準化されています。

flowchart TB
    subgraph fido2["FIDO2"]
        webauthn["WebAuthn<br/>(Web API)"]
        ctap["CTAP<br/>(Client to Authenticator Protocol)"]
    end
    
    subgraph components["構成要素"]
        rp["Relying Party<br/>(Webサイト/アプリ)"]
        client["Client<br/>(ブラウザ)"]
        auth["Authenticator<br/>(認証器)"]
    end
    
    webauthn -.->|"ブラウザとRPの通信"| rp
    webauthn -.->|"ブラウザとRPの通信"| client
    ctap -.->|"ブラウザと認証器の通信"| client
    ctap -.->|"ブラウザと認証器の通信"| auth

FIDO2の認証フロー(登録)

  1. ユーザーがサービスへの登録を開始
  2. サーバーがチャレンジ(ランダムな値)を生成
  3. 認証器が公開鍵/秘密鍵のペアを生成
  4. 秘密鍵は認証器内に安全に保存
  5. 公開鍵とチャレンジへの署名をサーバーに送信
  6. サーバーが公開鍵を保存

FIDO2の認証フロー(認証)

  1. ユーザーがログインを開始
  2. サーバーがチャレンジを生成
  3. 認証器がユーザー検証(PIN/生体認証)を実行
  4. 秘密鍵でチャレンジに署名
  5. サーバーが保存済み公開鍵で署名を検証

FIDO2のセキュリティ特性

特性 説明
フィッシング耐性 オリジン(ドメイン)に紐づいた認証情報のため、偽サイトでは使用不可
サーバー侵害耐性 サーバーには公開鍵のみ保存。秘密鍵は漏洩しない
リプレイ攻撃耐性 毎回異なるチャレンジに署名するため、過去の認証情報を再利用不可
なりすまし検証耐性 認証器がオリジンを検証し、正規サービスにのみ応答

パスキー(Passkey)

パスキーは、FIDO2/WebAuthnに基づく認証資格情報の総称で、特にデバイス間で同期可能な「同期パスキー」と、特定デバイスに紐づく「デバイス固定パスキー」があります。

flowchart TB
    subgraph passkey_types["パスキーの種類"]
        subgraph synced["同期パスキー"]
            icloud["iCloud Keychain"]
            google["Google Password Manager"]
            windows["Windows Hello"]
        end
        
        subgraph device_bound["デバイス固定パスキー"]
            security_key["FIDO2セキュリティキー"]
            authenticator_app["Microsoft Authenticator<br/>(デバイス固定モード)"]
        end
    end
    
    subgraph use_case["利用シーン"]
        consumer["コンシューマー向け<br/>(利便性重視)"]
        enterprise["エンタープライズ向け<br/>(セキュリティ重視)"]
    end
    
    synced --> consumer
    device_bound --> enterprise

同期パスキーの特徴

  • 秘密鍵がクラウド経由でデバイス間で同期
  • デバイス紛失時のリカバリーが容易
  • 同じアカウント(Apple ID、Googleアカウント等)でサインインしたデバイスで利用可能
  • アテステーション(デバイス証明)非対応

デバイス固定パスキーの特徴

  • 秘密鍵が特定のデバイスから離れない
  • 高いセキュリティ保証
  • アテステーションによるデバイス検証が可能
  • デバイス紛失時は別途リカバリー手段が必要

パスキーによるサインイン体験

  1. ユーザーがサービスにアクセス
  2. パスキーでのサインインを選択
  3. デバイスのロック解除と同じ方法(顔認証、指紋、PIN)で認証
  4. サインイン完了

パスキーは、パスワードと比較して以下の優位性があります。

項目 パスワード パスキー
フィッシング耐性 なし あり
覚える必要 あり なし
サインイン成功率 約30% 約95%
サインイン時間 約69秒 約3秒
再利用リスク 高い なし

パスワードレス認証への移行

パスワードレス認証は、パスワードを完全に排除し、より安全で使いやすい認証方式に移行することを目指します。

パスワードレス認証の実現方式

flowchart LR
    subgraph methods["パスワードレス認証方式"]
        fido2_key["FIDO2セキュリティキー"]
        passkey["パスキー"]
        phone_signin["電話によるサインイン"]
        cert["証明書ベース認証"]
    end
    
    subgraph factors["認証要素"]
        possession["所持<br/>(デバイス)"]
        biometric["生体<br/>または<br/>PIN"]
    end
    
    fido2_key --> possession
    fido2_key --> biometric
    passkey --> possession
    passkey --> biometric
    phone_signin --> possession
    phone_signin --> biometric
    cert --> possession

パスワードレス認証のメリット

セキュリティ向上

  • フィッシング攻撃に対する耐性
  • クレデンシャルスタッフィングの無効化
  • パスワード関連の脆弱性の排除
  • 中間者攻撃への耐性強化

ユーザー体験の改善

  • パスワードを覚える必要がない
  • サインインの成功率向上
  • サインイン時間の短縮
  • パスワードリセットの負担削減

運用コストの削減

  • パスワードリセット対応の減少
  • ヘルプデスク負荷の軽減
  • セキュリティインシデント対応の減少

導入時の考慮点

技術的考慮点

項目 考慮事項
対応ブラウザ/OS WebAuthnの対応状況を確認
既存システムとの統合 レガシーアプリケーションへの対応方法
認証器の選定 プラットフォーム認証器 vs ローミング認証器
バックアップ認証 認証器紛失時のリカバリー手段

組織的考慮点

項目 考慮事項
ユーザー教育 新しい認証方式の使い方説明
段階的展開 パイロットグループから順次拡大
例外対応 特殊な環境での代替認証手段
ポリシー策定 認証ポリシーの更新と周知

Microsoft Entra IDでのMFA/パスワードレス設定

Microsoft Entra ID(旧Azure AD)では、多様なMFAおよびパスワードレス認証オプションを提供しています。

認証方法の概要

flowchart TB
    subgraph entra["Microsoft Entra ID認証方法"]
        subgraph mfa["MFA"]
            authenticator_push["Microsoft Authenticator<br/>(プッシュ通知)"]
            authenticator_otp["Microsoft Authenticator<br/>(TOTP)"]
            sms["SMS"]
            voice["電話"]
        end
        
        subgraph passwordless["パスワードレス"]
            passkey_entra["パスキー(FIDO2)"]
            authenticator_passwordless["Microsoft Authenticator<br/>(パスワードレス)"]
            whfb["Windows Hello for Business"]
            cert_auth["証明書ベース認証"]
        end
    end

パスキー(FIDO2)の有効化手順

Microsoft Entra IDでパスキーを有効化する手順の概要です。

1. 認証方法ポリシーの設定

Microsoft Entra管理センターで以下の設定を行います。

  • [保護] > [認証方法] > [ポリシー]を選択
  • [FIDO2セキュリティキー]または[パスキー]を選択
  • 有効化と対象ユーザー/グループを設定

2. アテステーション設定(オプション)

高セキュリティが必要な場合、アテステーションを強制できます。

  • アテステーション強制を有効にすると、認証器のベンダーとモデルを検証
  • デバイス固定パスキーのみが許可され、同期パスキーは除外

3. キーの制限(オプション)

特定の認証器のみを許可する場合の設定です。

  • AAGUID(Authenticator Attestation GUID)による制限
  • FIDO Allianceのメタデータサービスに基づく検証

条件付きアクセスとの連携

パスキー認証を条件付きアクセスと組み合わせることで、より強固なセキュリティを実現できます。

flowchart TB
    subgraph ca["条件付きアクセスポリシー"]
        condition["条件"]
        grant["アクセス許可制御"]
    end
    
    subgraph conditions["評価条件"]
        user["ユーザー/グループ"]
        app["対象アプリ"]
        location["場所"]
        device["デバイス状態"]
        risk["リスクレベル"]
    end
    
    subgraph grants["許可制御"]
        require_mfa["MFA必須"]
        require_passwordless["フィッシング耐性のある<br/>認証必須"]
        require_compliant["準拠デバイス必須"]
    end
    
    conditions --> condition
    condition --> grant
    grant --> grants

フィッシング耐性のある認証を要求するポリシー例

  • 対象:全ユーザー
  • 対象アプリ:すべてのクラウドアプリ
  • 許可制御:認証強度「フィッシング耐性のあるMFA」を要求

Oktaでのパスワードレス認証設定

Oktaでもパスキーを含むパスワードレス認証を設定できます。

Oktaの認証ポリシー構造

flowchart TB
    subgraph okta["Okta認証ポリシー"]
        global["グローバルセッションポリシー"]
        app["アプリサインオンポリシー"]
        authenticator["認証器登録ポリシー"]
    end
    
    global --> app
    authenticator --> global

WebAuthn認証器の有効化

1. 認証器の追加

  • [セキュリティ] > [認証器]を選択
  • [認証器を追加] > [FIDO2 (WebAuthn)]を選択
  • 設定オプション(アテステーション、ユーザー検証等)を構成

2. 認証器登録ポリシーの設定

  • [セキュリティ] > [認証器] > [登録]タブを選択
  • 対象グループとFIDO2認証器の登録を許可

3. 認証ポリシーの更新

  • アプリサインオンポリシーでFIDO2/パスキーを要求
  • 必要に応じて他の認証方法を無効化

段階的な導入アプローチ

MFA/パスワードレス認証の組織への導入は、段階的に進めることを推奨します。

フェーズ1:評価と計画(1〜2ヶ月)

gantt
    title MFA/パスワードレス導入ロードマップ
    dateFormat  YYYY-MM
    section フェーズ1
    現状評価           :2026-02, 1M
    要件定義           :2026-02, 1M
    計画策定           :2026-03, 1M
    section フェーズ2
    パイロット準備     :2026-03, 1M
    パイロット実施     :2026-04, 2M
    section フェーズ3
    段階的展開         :2026-06, 3M
    section フェーズ4
    全社展開           :2026-09, 2M
    継続的改善         :2026-11, 2M

主なタスク

  • 現在の認証方法と課題の棚卸
  • セキュリティ要件の明確化
  • 対象システムとユーザーの特定
  • 認証器の選定と調達計画

フェーズ2:パイロット(2〜3ヶ月)

主なタスク

  • IT部門等の先進ユーザーグループで試行
  • 問題点の洗い出しと改善
  • ヘルプデスク対応手順の整備
  • ユーザー教育コンテンツの作成

フェーズ3:段階的展開(3〜6ヶ月)

主なタスク

  • 部門/地域ごとに順次展開
  • 例外対応プロセスの運用
  • フィードバックに基づく改善
  • KPIモニタリング

フェーズ4:全社展開と継続的改善

主なタスク

  • 残存ユーザーへの展開完了
  • レガシー認証方法の段階的廃止
  • 定期的なセキュリティレビュー
  • 新技術への対応検討

まとめ

本記事では、ゼロトラストにおける認証強化の要となるMFAとパスワードレス認証について解説しました。

重要なポイント

  • MFAは「知識」「所持」「生体」の異なる認証要素を組み合わせることで、単一要素の突破では不正アクセスを防止する
  • FIDO2/WebAuthnは、フィッシング耐性を持つ強固な認証標準であり、パスキーとして広く普及している
  • パスキーには「同期パスキー」と「デバイス固定パスキー」があり、利便性とセキュリティのバランスに応じて選択する
  • パスワードレス認証への移行は、セキュリティ向上とユーザー体験改善の両方を実現する
  • 組織への導入は段階的に進め、パイロットから順次展開していく

ゼロトラストの「決して信頼せず、常に検証する」という原則において、強固な認証は最初の防衛線です。パスワードのみの認証から脱却し、MFA、そしてパスワードレス認証へと進化させることで、組織のセキュリティ態勢を大幅に強化できます。

次の記事では、条件付きアクセスポリシーの設計と実装について詳しく解説します。ユーザー属性、デバイス状態、ネットワーク環境、リスクレベルに基づく動的なアクセス制御により、ゼロトラストの継続的検証をどのように実現するかを学びます。

参考リンク