不正ログイン対策｜レート制限を入れたら、自分たちの監視ツールが真っ先に止まった

「管理画面に不正なログインがあった形跡はありますか」と聞かれたら、少し考えてから「たぶん無いと思います」としか答えられなかった。
たぶん、という言葉が自分でも引っかかった。
うちのサイトの管理画面は、ログインの失敗を数える仕組みも、通知を送る仕組みも、前から用意してある。
ただそれぞれがいつ・どんな設定で有効になっているのか、まとめて棚卸ししたことは一度もなかった。
今回、ログイン周りのセキュリティ設定を一通り見直して、その途中で思わぬところで自分たちの首を絞めることになった話を書いておきたい。

管理画面の入り口を、ひとつずつ数えてみる

最初にやったのは、管理画面へたどり着ける経路を数えることだった。
ログインフォームそのものに加えて、パスワードを忘れたときの再発行の画面、外部からAPI経由でトークンを使ってアクセスする経路、スマホから直接投稿できる専用の入口もある。
サイトを運営していると、こうした入口は機能を増やすたびに静かに増えていく。
全部でいくつあるのか、数えるまで正確には把握していなかった。
数えてみて分かったのは、入口の数だけ守り方も分けて考える必要がある、ということだった。
通常のログインには、接続元のIPアドレスで絞り込む設定も用意してあるが、これは在宅勤務のメンバーがいる体制だと使いどころを選ぶ機能だと思う。
うちはオフィスの固定回線からしか管理画面を開かない運用にしているので、この絞り込みも有効にしている。
入口を数え終えたあと、それぞれの入口に同じ強さの対策をかけるのは違うとも思った。
通常ログインとAPI経由のトークン認証では、想定している利用者も、1日に発生するアクセスの回数も別物だからだ。
同じ基準をそのまま当てはめると、片方には緩すぎて、もう片方には厳しすぎるということが起きる。

入口を絞ったあとに気になったのは、パスワードの中身だった。
いくら入口を絞っても、使っているパスワードが別のサービスの漏洩事故で流出したものと同じなら、そこから突破されてしまう。
うちでは、新しく設定したパスワードが過去の漏洩データと一致していないかを確認する機能も有効にしている。
パスワードそのものを外部に送信するのではなく、ハッシュ値の一部だけを照合する方式なので、入力した文字列が漏れる心配はない仕組みになっている。
これを有効にして最初にやったのは、自分たちのアカウントのパスワードを一通り変更することだった。
長く使っていたパスワードの中に、別のサービスで一度使い回していたものが混ざっていないか、自分でも自信が持てなかったからだ。

ログイン試行の制限とロック解除までの時間

パスワードを連続して間違えたとき、何回でアカウントを止めるかは、最初に数字を決める段階で地味に悩んだ。
厳しくしすぎると、自分がタイプミスしただけでロックされて作業が止まる。
緩くしすぎると、総当たりで試す相手に時間を与えてしまう。
うちでは5回失敗したら15分間ロックする設定に落ち着いた。
15分という数字に深い理由はなく、担当者がパスワードを確認している間に自然と待てる長さ、という基準で決めた。
ロックされている間もログインフォーム自体は普通に表示されるので、相手に「ロック中」だと悟らせない作りになっている。
これも最初は意識しておらず、ロック中の挙動を実際に自分で試してみて初めて、そういう設計だと理解した。

二段階認証とパスキーを両方用意した理由

パスワードだけに頼らない仕組みとして、二段階認証とパスキーの両方を有効にしている。
最初はどちらか片方で足りると思っていたが、実際に運用してみると役割が違った。
二段階認証は、ログインのたびにコードを求める代わりに、信頼済みの端末としていったん認証すれば24時間は再入力を省略できるようにしている。
毎回コードを求めると、結局面倒になって機能ごと無効化してしまう担当者が出てくると考えたからだ。
パスキーは、端末に登録しておけばパスワードそのものを入力しない。
出先からスマホで急いで一件だけ更新したいときは、パスキーの方が圧倒的に早い。
どちらか一方に絞るのではなく、使う場面によって両方を使い分ける形に落ち着いている。
導入してすぐの頃は、パスキーの登録を忘れた端末から管理画面を開けなくなり、復旧の手順を自分たちで確認し直すことも1度あった。
便利さと引き換えに、登録済みの端末を失ったときの代替手段を先に決めておく必要があるとそのとき学んだ。

レート制限を入れた直後、監視ツールが止まった

ここまでの対策は数か月かけて少しずつ入れてきたが、最後まで後回しにしていたのがアクセス頻度そのものを制限するレート制限だった。
短い時間に大量のリクエストを送ってくる相手を機械的に締め出す仕組みで、1分間に60回を超えたアクセス元は5分間ブロックする設定で有効にした。
有効化した直後、サイト監視の機能から「応答がありません」という通知が届いた。
実際にはサイトは落ちていなかった。
定期的に死活確認のアクセスを送っていた監視の仕組み自体が、新しく入れたレート制限に引っかかって、自分のアクセスを自分でブロックしていた。
守りを固めたつもりが、正当な自動アクセスを先に止めてしまった形だった。

「不審なアクセス」と「正当な定期アクセス」を分ける作業

原因が分かってからの対応は、それほど難しくなかった。
監視の送信元を許可リストに登録して、カウントの対象から外した。
ただこの一件で、順番を間違えていたことに気づいた。
レート制限を先に有効化してから、ブロックされた相手をあとから確認するやり方だと、同じような誤検知がそのたびに起きる。
今は逆の順番にしている。
まず自分たちが定期的に送っている正当なアクセスを棚卸しして許可リストを固め、そのあとで制限の数値を有効にする。
対策を強めるときほど、先に自分たちの足元を確認しておかないと、守りたいはずのサイトを自分で止めることになる。

監査ログで見ているのは「誰が」より「いつ」

一連の見直しのあと、普段の確認作業も1つ変えた。
これまで操作の記録を見るときは、「誰が」何をしたかを中心に見ていた。
今は「いつ」の方に先に注目するようにしている。
通常の業務時間から外れた時間帯にログインや設定変更が記録されていないか、まずそこだけ機械的に確認する。
誰のアカウントによる操作かを見るのは、そのあとで十分だと今は思っている。
深夜や早朝の記録が1件あるだけでも、それが本人の作業なのか確かめる価値はある。
記録を残す仕組みそのものは前から用意されていたのに、見る順番を変えただけで気づける範囲が広がったのは、自分でも意外だった。

対策は足す順番で、失敗の種類が変わる

今回の見直しを通して感じたのは、ログイン対策は数を増やせば増やすほど安全になるとは限らない、ということだった。
パスワードの中身、試行回数、二段階認証、パスキー、アクセス頻度、操作の記録。
1つずつは単純な仕組みでも、入れる順番を間違えると、守るはずの仕組みが自分たちの業務を止める側に回ってしまう。
うちの場合は、レート制限を先に強く設定してしまったことで、自分たちの監視の仕組みを自分で止めてしまった。
もし逆に、許可リストを先に固めてからレート制限を有効にしていれば、この誤検知は起きなかったはずだ。
これから同じような見直しをするなら、まず自分たちの定期的なアクセスを全部洗い出してから、1つずつ制限を強めていくことを勧めたい。

ログインまわりの対策は、1つ入れるごとに安心が積み上がるものだと思っていたが、対策どうしがぶつかることもあると今回学んだ。
パスキーや操作の記録について、機能のページでも紹介している。
パスキー認証と操作監査ログのページも見てみてほしい。