多要素認証を「有効」にした、その次へ――フィッシングに強い認証とCloudflare Accessの確認点

「多要素認証を有効にしたので、ログイン対策は完了」と考えていませんか。多要素認証（MFA）は、パスワードに加えて別の要素で本人確認する大切な対策です。ただし、方式によってフィッシングへの強さは異なります。今回は、社内システム全体の見直しから一歩進めて、認証方法の選び方と運用の確認点を整理します。

「MFAあり」だけでなく、方式を確認する

米国NISTは、SMSやワンタイムコードなど、一部のMFAはフィッシングの影響を受ける可能性があると説明しています。偽サイトにコードまで入力してしまう状況も考慮する必要があります。一方、FIDOとWebAuthnという認証技術を使う方式は、フィッシングに強い選択肢として挙げられています。専用のセキュリティキーだけでなく、対応するPCやスマートフォンに組み込まれた認証器を使う形もあります。

今の方式を急に止めることが目的ではありません。まずは「どのシステムで、誰が、どの方式を使っているか」を把握し、より強い方式へ段階的に移れるか検討しましょう。

管理者と重要な業務から、小さく始める

全社員を一度に切り替えると、未対応の端末や復旧手順の不足で業務が止まることがあります。実務では、管理者や重要な情報を扱う業務を優先候補にし、少人数で試す進め方が考えられます。次の項目を、対象システムごとに一覧にすると判断しやすくなります。

• 対象と方式：メール、SaaS、社内アプリのログイン方法と、管理者・一般利用者の違いを確認する。
• 端末の対応：会社PC、スマートフォン、ブラウザーで利用できる方式を実機で試す。
• 登録と復旧：初回登録の案内、端末紛失や機種変更時の本人確認、問い合わせ先を決める。
• 例外の管理：一時的な代替手段には期限と責任者を設け、恒常的な抜け道にしない。

Cloudflare Accessと既存の認証基盤を組み合わせる

社内アプリへの入口を管理するCloudflare Accessでは、対応する認証基盤から伝えられる認証方式を、アクセス条件に使えます。認証基盤とは、利用者のログインや本人確認を担うサービスのことです。公式資料では、Microsoft Entra ID、Okta、汎用OIDC・SAML連携などに条件があり、連携先から必要な認証情報が伝わるかの確認が必要です。「認証基盤にログインできた」と「求める方式で認証された」を分けて検証することが大切です。

Access自身が追加の本人確認を行う仕組みもありますが、既存環境との役割分担を先に整理しましょう。利用できる認証方式、契約条件、端末対応は導入時点の公式情報で確認し、MFAを有効にする設定だけで、すべてのアプリが同じ強さになると考えないようにします。

切り替え後も、利用できることを確かめる

試行時は正常なログインだけでなく、条件を満たさない場合の拒否、代替端末での利用、紛失時の復旧まで確認します。認証方法を強くしても、不要な権限や更新されていない端末への対策は別途必要です。安全性と業務継続を両立できる運用を、担当者と利用者で確かめていきましょう。

既存の認証基盤と社内アプリの接続方法を整理したうえで、Cloudflareを使う範囲を検討したい場合は、ｉソフトのCloudflare・ゼロトラスト支援内容をご覧ください。

参考情報

• NIST：Multi-Factor Authentication（2022年1月10日公開、2026年1月5日更新）
• Cloudflare：Enforce MFA（2026年8月13日更新、公開日の明記なし）

確認日：2026年11月2日。機能・条件は変更される場合があります。確認手順の提案は、上記資料を踏まえた実務上の整理です。