フィッシング耐性の高いMFA実践ガイド

ラックの小林です。
いわゆる情シスで社内のセキュリティ強化を行っています。

ユーザ名とパスワードだけでの認証は脆弱な認証方法とされており、複数の認証方式を組み合わせた多要素認証（以下、MFA）を徹底することがセキュリティ上重要です。ただし、MFAであれば何でも安全というわけではありません。ワンタイムパスワード（OTP）やプッシュ通知は利便性が高い一方で、リアルタイムフィッシングや中間者攻撃によって突破されるケースも報告されています。

そこで注目されているのが、FIDO2やパスキーといったフィッシング耐性のある認証方式です。これらを適切に導入・普及させることで、攻撃者に認証情報そのものを渡さない構造を実現し、パスワードに依存しない環境を構築することができるようになります。

この記事では、フィッシング耐性のあるMFAを推進する上で、気を付けておくべきセキュリティ上のポイントについて解説します。

フィッシング耐性のあるMFAとは

二段階認証を突破するフィッシングが出てきているため、MFAを導入しただけでは十分とは言えません。そこで、利用者の利便性を損なわずにフィッシング耐性のある認証方式として、パスキーが注目されています。この記事では、FIDOアライアンスの定義に従い、パスキーはFIDO標準に基づくFIDO認証資格情報として扱います。

MFAの効果を最大限にする

フィッシング耐性のあるMFAを使っていたとしても、MFAが適用されていない箇所が残っていると、そこが弱点となってしまいます。効果を最大化するため、未適用の箇所がないかを洗い出し、確実に有効化しましょう。以下では見落としがちな点を挙げます。

レガシー認証を拒否

レガシー認証（例：IMAP/POP/SMTP AUTH）はMFAを要求できないため、攻撃者からブルートフォース攻撃などにより認証を突破される恐れがあります。すべてのアカウントにおいてレガシー認証を拒否する設定になっているか確認することを推奨します。

一部のアカウントでレガシー認証を許可していると、そこが弱点となって侵入を許してしまうことにつながるので注意が必要です。

MFAが除外されているアカウントの見直し

MFAが除外されているアカウントがないか棚卸ししましょう。典型例は自動化用アカウントや初期セットアップ用アカウントです。自動化するアカウントをMFAにせずに使っている場合は、ベストプラクティス（例：マネージドIDによるアプリケーション認証）に沿って実装する必要があります。

初期セットアップについては、MicrosoftではTemporary Access Pass（TAP）という有効期限付きパスコードが提供されており、TAPはMFA相当として扱われます。これにより一時的にMFAを除外する運用を避けられます。

認証強度の低い方式の縮小

音声通話やSMSによる認証はフィッシングによる中間者攻撃（AiTM）やSIMスワップ等に弱く、認証強度が低い方式とされています。パスワードを忘れたときのリセット手段の一つとして利用が可能になっていることがありますが、利用する必要のないアカウントまで放置するとアカウントが乗っ取られる可能性があります。認証強度が低い認証方式を使っているアカウントを最小限にする必要があります。

パスワードに依存しない環境を整える

MFAを徹底する環境を整備したら、フィッシング耐性の低い認証方式から、高い方式へと段階的にシフトさせていくことが重要です。

そのためには、OTPやプッシュ通知に依存した運用から、FIDO2やパスキーといったフィッシング耐性のある認証へと誘導し、最終的にはパスワードに依存しない認証基盤へ移行していく必要があります。このとき、既存の利用体験を大きく損なわずに段階的に切り替える設計とすることで、現場の抵抗感を抑えつつスムーズな移行を実現できます。

パスキーの認証の許可

パスキーは正規サイトのURLへのアクセスでないと利用できない仕組みになっているため、フィッシングに強い特性があります。パスキーを組織で管理しているアカウントやデバイスに保存することで安全に利用できます。

許可設定の際は、組織で管理していないアカウントやデバイスに対してパスキーが保存されないように、特定のセキュリティキーモデルまたはパスキープロバイダーのみを許可することを推奨します。

Windows Hello for Businessの活用

生体認証データまたはPINでWindowsデバイスにサインインする機能がWindows Hello for Businessです。Windows Hello for BusinessのFIDO2サポートにより利用者のセキュリティと利便性を向上できます。

特に、資格情報はTrusted Platform Module（TPM）と呼ばれるキーを安全に格納する場所に保管されるため、承認されていないユーザが資格情報にアクセスするのは困難になります。

認証強度の高い方式の強制

フィッシング耐性のある認証方法を用意しても、移行が進まないと弱い認証強度に依存してしまいます。

強い認証強度を強制する方法として、例えば高権限のユーザが管理ポータルへのアクセスの際には、パスキーによる認証を強制するように条件付きアクセスポリシーで設定できます。多くの管理ポータルへのアクセスはMFAが必須になっていますが、さらにフィッシング耐性のあるMFAを求められます。

さいごに

パスワードに依存しない環境への移行は一朝一夕で実現できるものではありません。既存システムや利用者の習慣に深く根付いているからこそ、拙速な置き換えは現場の混乱や運用リスクを招きます。

一方で、攻撃者は確実にパスワード前提の弱点を突いてくるため、時間をかけすぎてもリスクになり得ます。重要なのは、現実的な移行シナリオを描くことです。パスワードへの依存度を段階的に引き下げつつ、フィッシング耐性の低いMFAから高いMFAへと計画的にシフトしていく積み重ねが、セキュリティ強度とユーザビリティを両立した認証基盤の実現につながります。

この記事が、フィッシング耐性のあるMFAを組織として定着させるための次の一手を考える材料になれば幸いです。