多要素認証（MFA）を導入していても、すべての方式が同じ強さを持つわけではありません。 SMSで受け取ったコードや認証アプリのワンタイムパスワードを利用者が入力する方式は、 パスワード単独より防御を厚くできますが、偽サイトが入力内容をリアルタイムで中継する攻撃には限界があります。 プッシュ通知を承認する方式も、繰り返し通知を送り承認を誘う攻撃や、利用者が正当な要求か判断しにくい場面を考慮する必要があります。

NIST SP 800-63B-4は、フィッシング耐性を「利用者の注意力に依存せず、偽の検証者へ認証秘密や有効な認証出力を渡さない認証プロトコルの能力」と整理しています。 手入力するOTPなどは、認証先のセッションと暗号学的に結び付かないため、フィッシング耐性があるとは扱われません。 一方、WebAuthnを使うFIDO2認証は、認証情報を正規のドメインへ結び付ける方式の例として挙げられています。

ただし、全社員・全システムを一度にパスキーやセキュリティキーへ切り替えることが正解とは限りません。 既存システムの対応状況、端末、委託先、緊急時アクセス、アカウント復旧を含めて設計しなければ、 強い認証を導入しても例外経路が常用されたり、利用不能時に安全でない回避策へ戻ったりします。 本記事では、認証方式の選定だけでなく、業務と運用を含む移行手順を整理します。

具体的な課題：「MFA有効」の表示だけではリスクを説明できない

MFA導入率を唯一の指標にすると、守る対象と認証方式の組み合わせが見えません。 たとえば、全社員のメールにはMFAがある一方で、クラウド管理者、VPN、請求・送金、 パスワード管理、バックアップ、ドメイン管理などに弱い方式や共有アカウントが残ることがあります。

  • 方式の差が未把握：SMS、OTP、プッシュ、パスキー、物理セキュリティキーを同じ「MFA」として集計している。
  • 重要度と未接続：管理権限、扱う情報、停止時の影響と、必要な認証強度が結び付いていない。
  • 例外が常態化：未対応アプリ、共有端末、委託先接続を理由に、弱い認証経路が期限なしで残る。
  • 復旧が抜け道になる：端末紛失や機種変更時に、本人確認が弱いヘルプデスク手順で認証器を再登録できる。
  • 利用状況を測れない：登録率は把握しているが、実際の認証方式、拒否、失敗、例外利用を確認できない。
移行の目的は「パスキーを配ること」ではなく、重要なアクセスを、偽サイトで再利用できない認証と安全な復旧で守ることです。

考え方：対象・強度・経路・復旧を一つの設計にする

認証を製品機能ではなくアクセス経路全体として捉えます。 NISTの認証保証レベル（AAL）は米国政府機関向けの技術要件であり、日本企業へそのまま適用される義務を示すものではありません。 それでも、AAL2ではフィッシング耐性のある選択肢を提供し、AAL3ではフィッシング耐性と非エクスポート可能な暗号鍵を必須とする整理は、 業務リスクに応じて認証強度を段階化する参考になります。

  1. 対象：誰が、どの端末から、どのサービスと権限へアクセスするか。
  2. 強度：そのアクセスで、どの攻撃と事業影響を抑える必要があるか。
  3. 経路：SSO、直接ログイン、API、緊急用アカウントなど、実際に通れる経路は何か。
  4. 復旧：紛失・故障・異動・退職時に、誰が何を確認して認証器を追加・失効するか。

同期型パスキーは複数端末で利用しやすい一方、鍵を同期する仕組みとアカウントの保護を評価する必要があります。 物理セキュリティキーは重要な管理者アクセスに向く場合がありますが、配布、予備、紛失、在庫、遠隔勤務の運用が必要です。 方式名だけで優劣を決めず、対象業務、端末管理、復旧、使いやすさを合わせて選びます。

実践手順1：認証経路を棚卸しする

重要サービスから着手し、利用者、管理者、委託先、サービスアカウント、緊急用アカウントを分けて記録します。 SSOの設定だけでなく、サービス固有の直接ログイン、古いプロトコル、VPN、管理コンソール、 APIキー、ローカル管理者など、迂回できる経路も確認します。

各経路に、現在の認証方式、フィッシング耐性の有無、対象人数、権限、端末条件、 所有部門、ログ、復旧方法、例外期限を付けます。 「MFAあり／なし」の二択ではなく、攻撃者が認証情報を中継・再利用できるか、 登録や復旧で同等の本人確認が保たれるかを確認します。

実践手順2：重要アクセスから優先順位を付ける

CISAのフィッシング対策ガイダンスは、管理者や特権利用者、顧客・財務情報へ広くアクセスできる利用者を優先する考え方を示しています。 自社では、アカウントが侵害された場合の影響と、攻撃されやすさを組み合わせて順位を決めます。

  • 第1優先：クラウド・ID基盤・ネットワーク・バックアップ・ドメイン・セキュリティ製品の管理者。
  • 第2優先：経営、財務、人事、顧客情報、ソースコード、機密研究などへ広くアクセスする役割。
  • 第3優先：メール、リモートアクセス、業務SaaSなど、攻撃の入口になりやすい一般利用者。

ただし「管理者だけ守ればよい」わけではありません。 一般利用者のメールから内部情報やセッションが奪われ、別の攻撃へ進む可能性があります。 優先順位は導入順を決めるものであり、対象外を恒久的に残す判断ではありません。

実践手順3：一つの業務で方式と運用を試す

対象を絞り、対応端末、ブラウザ、SSO、業務アプリで、FIDO2／WebAuthnに基づくパスキーや物理セキュリティキーを検証します。 正常なログインだけでなく、新規登録、複数端末、端末交換、紛失、オフライン、共有端末、 アクセシビリティ、委託先利用、緊急時を試験シナリオへ含めます。

フィッシング耐性のある方式へ直ちに移れないシステムでは、現行MFAを外さず、 プッシュ通知の番号一致、追加のアクセス条件、管理者分離、セッション制御、監視などを暫定対策として組み合わせます。 暫定策には所有者、終了条件、見直し日を設定し、恒久例外へ変わらないようにします。

実践手順4：登録・復旧・失効を強くする

認証器の初回登録と追加登録は、日常のログインと同じか、それ以上に重要です。 既存セッションだけで追加できる設計、電話一本で再登録できる運用、 管理者が本人確認なしで例外解除できる手順は、強い認証の抜け道になり得ます。

登録承認者、本人確認方法、複数認証器の保有ルール、予備キー、紛失時の即時失効、 異動・退職時の解除、緊急用アカウントの保管と利用後確認を定義します。 ヘルプデスクには確認項目だけでなく、拒否・エスカレーションの条件を渡し、 重要アカウントの復旧操作は記録とレビューの対象にします。

実践手順5：利用実態で拡大を判断する

登録者数だけでなく、重要経路のうちフィッシング耐性認証で保護された割合、 弱い方式での認証、直接ログイン、例外利用、登録・復旧件数、失敗率、 ヘルプデスク負荷、拒否された不審な試行などを継続確認します。

試行結果から、端末標準、調達条件、SSO接続基準、委託先要件、教育、サポート手順を更新します。 利用不能や業務停滞が増えた場合は、利用者の責任にせず、対応端末、導線、予備手段、 アクセシビリティ、説明の不足を見直します。効果と運用可能性が確認できた範囲から対象を広げます。

注意点：パスキー導入だけで認証リスクは消えない

  • 生体情報そのものを送る仕組みと誤解しない：多くの端末では生体認証やPINは認証器を端末内で有効化する要素として使われる。製品仕様とデータの扱いを確認する。
  • 同期型と端末固定型を一括りにしない：鍵の保存・同期・エクスポート可否、端末管理、保証レベルを対象業務に合わせて評価する。
  • 認証後を忘れない：セッション窃取、過剰権限、端末侵害、APIキー、ソーシャルエンジニアリングには、別の対策が必要になる。
  • 単一の認証器へ依存しない：故障や紛失に備え、同等の強さを持つ予備手段と失効手順を用意する。
  • 例外を期限なしにしない：未対応システムには補完策、責任者、移行期限、更新判断を残す。
  • 適用要求を確認する：法令、契約、業界基準、個人情報、労務上の判断は、関係部門や必要に応じて専門家へ確認する。

まとめ

MFA導入は重要な出発点ですが、「有効化した」という状態だけでは、フィッシングや認証中継への耐性を説明できません。 認証方式、対象業務、すべてのアクセス経路、登録・復旧、例外、監視を一つの運用として設計することが必要です。

まずは管理者と重要業務の認証経路を一枚にし、手入力OTPや承認型プッシュが残る場所、 直接ログインや復旧の抜け道を特定してください。 その上で一つの業務からフィッシング耐性認証を試し、利用実態と業務影響を見ながら段階的に広げます。 強い技術と無理なく続く運用を同時に整えることが、認証基盤を実効性のある経営管理へ変える近道です。

参考にした公式資料

本記事は公的資料をもとに一般的な認証・アクセス管理の考え方を整理したものであり、 個別組織の法令適合性、契約、監査、製品選定その他の専門的判断を保証するものではありません。 公式資料と製品仕様は2026年8月3日時点で確認しており、実際の判断時には最新情報を確認してください。

FW

WRITTEN BYFourthWall Consulting Teamテクノロジーと経営の両面から、企業変革を支援しています。

← 技術ブログ一覧へ戻る