Webサービスの不正ログイン対策をどう組み合わせるか — MFA・レート制限・検知の3つの判断軸

セキュリティ2026.11.10

不正ログイン対策は、多要素認証（MFA）・試行回数の制限（レート制限）・異常な挙動の検知の3つに分けて考えると設計しやすくなります。結論から言えば、この3つは選択肢ではなく重ねるものです。MFAは盗まれた正しいパスワードを無力化し、レート制限は総当たりやリスト型攻撃の試行量を削り、検知はその2つをすり抜けた少数のログインを拾います。判断すべきは「どれを入れるか」ではなく、「どのログイン経路に、どの強さで、利用者の手間をどこまで増やして入れるか」です。

3つの対策が防ぐ攻撃と、利用者への影響

まず、それぞれが担う範囲が重ならないことを確認します。

多要素認証：防げるのは、漏えいしたID・パスワードの使い回しによるログイン（クレデンシャルスタッフィング）と単純な推測。防げないのは、方式によってはフィッシングとリアルタイム中継。利用者への影響は大きく、登録時の離脱と端末紛失時の問い合わせが発生します。
レート制限：防げるのは、同一アカウントへの連続した推測とスクリプトによる大量試行。防げないのは、1アカウントあたり1〜2回しか試さない分散型のリスト型攻撃。利用者への影響は、正規利用者のロックアウトという形で出ます。
異常な挙動の検知：防げるのは、資格情報が正しいのに普段と違う端末・地域・時間帯から行われるログイン。防げないのは、利用者の普段の環境を再現された場合。利用者への影響は、誤検知による追加認証とプライバシー上の懸念です。

国内の状況もこの重ね方を裏づけます。警察庁・総務省・経済産業省が2026年3月に公表した資料では、令和7年の不正アクセス行為の認知件数は7,190件で前年から約34.2％増え、検挙された識別符号窃用型399件の内訳では「パスワードの設定・管理の甘さにつけ込んで入手」が84件と最多、「フィッシングサイトから入手」が77件で前年から36件増えています。パスワードの弱さだけでなく、正規の手順で入力させて奪う手口が伸びている以上、レート制限と推測対策だけでは足りません。

多要素認証：方式ごとにフィッシング耐性が違う

MFAを「入れたかどうか」で評価すると判断を誤ります。NIST SP 800-63B-4は、フィッシング耐性を「利用者の注意深さに頼らず、偽の検証者に認証情報や認証器の出力が渡ることを防げること」と定義しています。この定義では、利用者が画面に手入力するワンタイムパスワード（OTP）やSMSコードはフィッシング耐性があるとは認められません。入力された値を攻撃者がそのまま本物のサイトに中継できるからです。

一方、パスキー（FIDO2/WebAuthn）は、認証器が鍵を検証者のドメインに紐づけるため、偽ドメインでは署名が成立せずフィッシング耐性を持ちます。同ガイドラインはAAL2（二要素相当）で、フィッシング耐性のある選択肢を少なくとも1つ提供することを求めています。

運用面では次の3点が判断材料になります。第一に、SMSや音声通話を使う方式は「制限付き認証器」と位置づけられ、採用するなら制限のない代替手段の提供、利用者へのリスク説明、リスク評価、将来使えなくなる場合の移行計画が必要とされます。第二に、プッシュ通知で表示された数字を見比べて承認するだけの方式は、MFA疲労攻撃（承認要求を連打して誤承認を誘う手口）を理由に認められず、片方の画面の値をもう片方に転送させる方式が求められます。第三に、MFAの導入コストの多くは認証そのものではなく復旧側に出ます。認証器を2つ以上登録させる、復旧コードやメール・電話番号など複数の通知先を持たせる、認証器の追加やアカウント復旧は必ず別経路で通知する、という設計を同時に決めてください。

試行回数の制限：数える単位を間違えると効かない

NIST SP 800-63B-4は、同一アカウントの同一認証器に対する連続失敗を100回以内に制限し、超えたらその認証器を無効化して再登録を求める、としています。ただしこの100回は上限であり推奨値ではありません。6桁のOTPを100回推測される確率と、ロックアウト時の復旧コストを釣り合わせた数字だと注記されています。実装では5〜10回程度の段階的な制限を置くのが一般的です。

同時に、ロックアウト自体が攻撃者による妨害手段になります。緩和策として挙げられているのは、失敗のたびに待ち時間を延ばす（30秒から1時間程度まで）、ボット検知のチャレンジを先に求める、IPアドレスや位置情報・リクエスト間隔・ブラウザ情報からリスクベースで判断する、という方法です。認証に成功したら失敗回数はリセットし、残り回数と待ち時間を利用者に明示することも推奨されています。

見落としやすいのが「数える単位」です。リスト型攻撃は1アカウントにつき1〜2回しか試さないため、アカウント単位のカウンタには引っかかりません。総務省が平成25年に公表した対策集では、攻撃の試行件数に対する成立率は各社0.15〜1.35％と報告されています。裏を返せば、試行の99％前後は失敗として記録されます。サービス全体の失敗率、失敗元IPの数、1つのIPが試したID数といった横断的な指標を見なければ、攻撃の進行自体に気づけません。

対象エンドポイントも広げる必要があります。パスワード再設定、アカウント登録、OTPの送信・再送、復旧コードの検証は、いずれもログインと同じ強度で制限すべき入口です。NISTは復旧コードの検証にも同じスロットリングを課し、プッシュ通知の送信回数にも上限を設けることを求めています。OWASP API Security Top 10では、GraphQLのクエリをまとめて送ることで1リクエストに多数の試行を詰め、レート制限を回避された例が示されています。数えるべきはリクエスト数ではなく認証試行の回数です。

異常な挙動の検知：ブロックではなく段階を上げる

検知の位置づけは明確にしておく必要があります。NISTは、想定外の地域やクラウド事業者のIPレンジからのログインといった不正の兆候をリスクベースの追加制御に使ってよいとしつつ、それは認証要素の代わりにはならず、認証の強度（AAL）も変えないとしています。さらに、兆候の有効性を評価すること、特定の利用者層に不利益が出ていないか確認すること、プライバシーリスク評価に含めることを必須としています。

つまり検知の出口は「怪しいから遮断」ではなく、「追加の認証を求める」「セッションを終了する」「本人に通知する」に倒すのが基本です。ログイン後も、利用パターンや操作の速度、デバイスとブラウザの特性、位置情報、IPの属性を継続的に見るセッション監視が選択肢として挙げられています。

そして最後の検知者は利用者本人です。前述の警察庁の資料でも、IPAへの届出では原因不明とされるものが依然として多く、ログの取得方法や保管期間の見直し、不正ログインを早急に検知できる機能の追加検討が勧められています。検知ルールを作る前に、成功・失敗の別、IP、ユーザーエージェント、失敗理由を残すログ設計を先に済ませてください。

ログイン方式と利用者リスク別の組み合わせ方

一般利用者向けのEC・会員サイト

MFAを全員に必須化すると離脱が無視できません。最低線はレート制限、認証ログの可視化、新しい端末からのログイン通知の3点です。その上でパスキーを任意の選択肢として追加し、配送先の変更、ポイントの交換、メールアドレスや電話番号の変更といった重要操作のときだけ追加認証を求めます。パスワードを残すなら、単要素として使う場合は15文字以上、MFA併用なら8文字以上を下限とし、漏えいパスワードのリストと照合して拒否し、文字種の組み合わせ強制と定期変更は課さず、パスワードマネージャーの自動入力と貼り付けを妨げない、という現行ガイドラインに合わせます。

金銭や重要情報を扱うサービス

フィッシング由来の侵入が増えている領域では、SMSのOTPだけでは守りきれません。パスキーを既定の方式として提示し、SMSは代替手段として残しつつ移行計画を持つのが現実的です。再認証の目安は、全体で24時間、無操作1時間（AAL2相当）です。重要操作の直前に再認証を挟む設計も合わせて検討します。

管理画面・社内システム

利用者が限られ、端末を配布でき、教育もできるため、フィッシング耐性MFAを必須化しやすい領域です。最も高い保証レベル（AAL3）を狙う場合、鍵を書き出せるクラウド同期型のパスキーは要件を満たさず、ハードウェアに固定された鍵が必要になります。再認証の目安は全体12時間、無操作15分です。IP制限は補助であって、認証の代わりにはなりません。

着手の順番は、投資対効果の観点から次を推奨します。

レート制限と認証ログの整備。原因不明の事後調査を減らす前提条件になります。
重要操作の再認証と、認証器追加・復旧・新端末ログインの通知。
パスキーの提供開始と、既存のSMS・OTPからの移行計画の明文化。
検知ルールの追加と、誤検知率を含めた効果測定。

導入後に塞ぎ忘れやすい経路

パスワード再設定とアカウント復旧。ある要素を使って別の要素を手に入れられる設計は避けます。秘密の質問は安全にできないものとして扱われています。
同じアカウントを使う別のクライアント。モバイル向けAPI、古い認証エンドポイント、GraphQLの入口に同じ制限がかかっているか確認します。
ログイン後のセッション。認証成功時にセッションIDを再発行し、HTTPS限定・HttpOnly・SameSiteの設定を行い、ログアウトとタイムアウトで確実に無効化します。
エラーメッセージの差異。登録・再設定・ログインで応答を揃え、アカウントの存在を推測されないようにします。
ロックアウト解除の運用。サポート窓口が社会工学的な攻撃の抜け道にならないよう、本人確認の手順を決めておきます。

3つのうち1つだけを強化しても、残り2つが担う範囲は空いたままです。まずは自社サービスのログイン経路（Web、モバイル、API、再設定、復旧）を書き出し、それぞれについて「試行回数をどの単位で数えているか」「フィッシング耐性があるか」「失敗と成功のログが残っているか」を一覧にしてください。穴が見えた順に埋めるのが、最も費用対効果の高い進め方です。

出典

この記事に関連するchot Inc.の解説

Webサイトで扱う情報を守るには、日々の運用ルールに加えて、CMSやホスティングの構成から見直すことが有効な場合があります。従来型のCMSとヘッドレスCMSで対策の考え方がどう変わるかはヘッドレスCMSとは｜従来CMSとの違い・メリット・デメリットで、生成AIをWebサイトに組み込む際の注意点は生成AIをWebサイトに組み込む際のセキュリティで解説しています。

この記事をシェア