認証されたユーザーのUserIdまたはIPアドレスに基づいてAPIリクエストをレート制限する方が良いですか？
IPに基づいて匿名リクエストをレート制限することを考えていますが、有効な認証トークンを持つユーザーの場合、ユーザーIDまたはIPアドレスに基づいてリクエストをログに記録してレート制限する方がよいかどうかを判断できません。
オプション1：UserIdごとに1分あたり15リクエスト
オプション2：IPアドレスごとに1分あたり30リクエスト
オプション：両方実行
悪意のある人物/エンティティがAPIに対してボット攻撃を実行することを決定した場合、最善のオプションは、IPアドレスに基づいてそれらをレート制限することであると思われます。各ユーザーが一意のメールアドレスで登録すると仮定します）。
ただし、高度な個人が攻撃中にIPアドレスを切り替え、同じ認証トークンを渡し、同じUserIdでシステムを悪用する可能性もあります。
3番目のオプションは魅力的なようですが、私にとっては、すべてのAPIリクエストをデータベースに2回書き込む必要があることを意味します（レコードはUserIdに基づいて水平にパーティション分割され、IPアドレスに基づいて別のパーティション分割スキームがあります。シャーディングにより、検索が容易になりますリクエストをカウントします）。
認証されたユーザーをレート制限するときにどのオプション（または他の何か）を追求するかに関するベストプラクティスはありますか？すべての検証ロジックを作成する前に、何をすべきかについての一般的なアイデアを知りたいですか？
場合によります。一般に、IPは匿名ユーザーに存在する唯一の識別子であるため、IPブロックは良い習慣です。ただし、ユーザーはオンラインプロキシサービスを使用してIPを「切り替える」ことができます。また、プロキシサーバーを使用する場合、複数のユーザーが同一のIPを共有する可能性があることに注意してください（エンタープライズ環境ではほとんどありません）。
ユーザーが認証されている場合は、ユーザーが悪意のある操作を行っているときにuserIdをブロックする必要があります。
別の側面として、匿名ユーザーがアプリで新しいアカウントを作成するのはどれほど簡単ですか。攻撃者が問題なく新しいアカウントを作成できる場合、userIdsをブロックしても意味がありません。攻撃者のユーザー1がブロックされていない場合、彼は簡単に新しいユーザーを作成できます。
したがって、両方のテクニックに頼って、個人が新しいアカウントを簡単に作成できるかどうかを確認する必要があります。
両方とも。さまざまな攻撃スタイルから保護します。
データベースをシャーディングする代わりに、IPブロッキングにFail2Banを使用することを検討し、ユーザーブロッキングのみのアプリケーション/内部モニタリングを使用できます。
リクエスト用のログがどこかにある限り、Fail2Banに読み取りアクセスを許可して、データベースに触れることなくその作業を行うことができます。
これがアプリケーションの場合は、Fail2Ban専用の最小限のログを実装できます。商用アプリケーションの場合は、インバウンドリクエストをログに記録する方法と場所を見つける必要があります。
Geoipの使用を追加します。場合によっては、サービスに属するものがない国を直接ブロックできることが望ましい場合があります。また、より信頼できる国のホワイトリストをブロックできます。