こう
- 「API の
回数制限や、 不正な アクセスへの 手当ては どうしますか」 - 「ログインの
画面に、 パスワードを 総当たりで 試されたら どうしますか」 - 「回数制限は、
どこで、 何を 単位に 数えますか」
面接官が
- 1 つの
手で 全部守ろうと せず、 入口、 アプリ、 ログインと 層を 分けて 考えられるか - 「誰の回数を」
「どこで数えるか」を、 台数が 増えた 環境も 含めて 考えられるか - 止めすぎて
普通の 利用者を 困らせる、という 弱点も 分かっているか
短い答え
- 入口では WAF (怪しい
要求を 弾く 門番) と ボット対策で、 よく ある 攻撃と 機械的な 大量アクセスを 先に 落とします。 - アプリでは
利用者や API キーごとに 回数を 数え、 決めた 数を 超えたら 429 (多すぎる ) を 返します。 - ログインは
失敗の 回数を 絞り、 いつもと 違う 動きを 見つけたら 通知が 飛ぶように して おきます。
少し
層に
- 入口 WAF や
ボット対策で、 よく 知られた 攻撃の 形や、 明らかな 機械の アクセスを 落とします。 AWS WAF、 Google Cloud の Cloud Armor、 Cloudflare の WAF と レート制限の ルールなどが 使えます。 ボットか どうかの 確かめには reCAPTCHA や Cloudflare の Turnstile のような 物があります - アプリログインした
利用者、 API キー、 IP アドレスなどを 単位に 回数を 数えます。 IP だけだと、 同じ 回線を 使う 大勢を まとめて 止めてしまうので、 ログイン後は 利用者の 単位で 数えるのが基本です - ログイン同じ
アカウントへの 失敗が 続いたら、 待ち時間を 伸ばす、 追加の 確認を 求める、 などで 総当たりを 遅くします - 見張り失敗の
急増や、 ふだんと 違う 国や 時間からの アクセスを 数え、 通知を出します
数え方と置き場所
数え方には、
サーバーが
超えた
http
HTTP/1.1 429 Too Many Requests
Retry-After: 30トレードオフ
制限を
よく
- IP アドレスだけで数える 会社や
学校のように 同じ 回線を 使う 大勢を まとめて 止めてしまいます。 ログイン後は 利用者の 単位で数えます - 各サーバーの
手元で数える 台数が 増えると、 決めた 数の 何倍も 通ります。 共有の 置き場に 数を集めます - 止めたら
終わりにする 失敗の 急増に 気づく 通知が ないと、 攻撃が 続いている ことを 見逃します
深掘りの問い
- 「ログインの
総当たりと、 たくさんの アカウントに 同じ パスワードを 試す攻撃は、 どう 違いますか」 後者は アカウントごとの 失敗回数では 見つけに くいので、 IP や 全体の 失敗の 割合でも 見る、と答えます - 「回数の
置き場が 落ちたら どうしますか」通すか 止めるかを API の 重さで 決める、 たとえば ログインは 止める 側に 倒す、のように答えます - 「料金の
かかる API を 守るには」回数だけでなく、 1 回あたりの 重さや 費用で 上限を 置く、と答えます