レートリミッティング

レートリミッティングとは？

さらに詳しく説明する前に、レートリミッティングの簡単な定義を説明します。これは、システムが過負荷にならないよう、トラフィックとAPI利用量に上限を設けることを意味します。制限がなければ、少数の利用者がシステムに過剰な負荷をかけ、ダウンさせ、他の利用者のアクセスを妨げる恐れがあります。 

一般に、システム資源のパフォーマンスを最適化し、サービスを公平に提供するためにレートリミッティングが利用されます。これがないと、攻撃者がリソースを過度に利用し、正当な利用者のアクセスが阻害される可能性があります。

例：利用者がパスワードを忘れて誤ったパスワードを入力し、ログインできなくなる状況を考えてみてください。多くのウェブサイトやアプリでは、ログイン時にレートリミッティングが適用され、3～4回の誤入力で利用が制限されます。 

‍

レートリミッティングはどう機能するか？

基本的な考え方は、レートリミッティングがウェブサーバではなくアプリ内部で動作するという点です。主な仕組みは、APIリクエストを送ったIPアドレスを追跡し、連続するリクエスト間の時間差を確認することにあります。 

IPアドレスとは、各インターネット接続に割り当てられる固有の番号です。

IPアドレスがあれば、誰が、いつ、どのようにAPIリクエストを送ったかが分かります。レートリミッティングが有効なら、システムは単一のIPからの総リクエスト数や連続するリクエスト間の時間を管理します。リクエストが多すぎたり頻繁すぎると、あらかじめ設定された制限がそのIPに適用されます。

制限を受けたIPには通常、エラーメッセージが返されます。実社会で速度違反を取り締まる交通警察が存在するように、仮想空間にもレートリミッティングがあります。これは重大な事故や詐欺を防ぐための予防策です。

レート制限の種類

組織のニーズは多様なため、レートリミッティングの戦略も一種類だけでは不十分です。以下のように、複数の基準で設定することが可能です。

• 利用者

システムが利用者とそのAPI利用状況を識別できれば、特定の時間内のAPIリクエストを制限できます。

例えば、1分に10回までのリクエストのみを許可し、11回目以降は拒否することが可能です。これにより、すべての利用者に公平なAPI利用が実現されます。 

• サーバ

APIベースのサービスは分散型で提供され、1つのリクエストが多数のサーバの中の1台で処理されます。こうした分散環境では、レートリミッティングによりサーバ間で効果的に負荷が分散されます。

各サーバにはリクエスト処理の上限が設けられ、全サーバが均等に利用され、過負荷や遊休状態を防ぎます。もしサーバの制限を超えると、リクエストは自動的に次のサーバに振り分けられます。これはDDoS攻撃の抑制にも寄与します。 

• 地理的

地理的な制限は、世界中に分散するサーバを効果的に活用するためのものです。APIサービスでは、利用者のリクエストは最も近いサーバで処理されるため、特定サーバへの偏りが生じる可能性があります。 

地理に基づくレートリミッティングを行えば、遠方のサーバもリクエスト処理に参加させることができ、迅速な対応が可能となります。この方式は時間ベースにすることも可能で、例えば一定時間経過後に遠隔サーバへリクエストを転送する設定を行えます。 

‍

レートリミッティングの用途

前述の通り、レートリミッティングはシステムやネットワークが過負荷にならないよう防ぎ、パフォーマンスを最適化するための手法です。特に共有サービスでは、多くの利用者が同時にアクセスするため、その重要性が際立ちます。クライアント側とサーバ側の双方にとって不可欠な対策です。

• リソースの過剰消費を防ぐため

レートリミッティングを利用することで、リソース不足を防ぎ、APIサービスの稼働率を向上させられます。大規模システムに対するDoS攻撃の多くは、システム内のソフトウェアや設定の不具合が原因です。 

計画外のDoSによるリソース不足、いわゆるフレンドリDoSは、警戒線を設けたレートリミッティングで防止できます。 

警戒線により負荷の急増に対処でき、レートリミッティングがなければ、スケーラブルなAPIでも大量の呼び出しが発生し、リソース過多のリスクが高まります。

• ポリシーとクォータ管理の強化のため

理想的なサービスは、すべての利用者に公平に提供されるものです。レートリミッティングにより、各利用者のサービス利用が監視・最適化され、均一なリソース利用が実現されます。

• 効率的なフロー制御のため

複雑な連携システムや大量のデータ・メッセージを扱う場合、情報の流れを管理するのは容易ではありません。しかし、この管理責任を回避することはできません。 

レートリミッティングを用いれば、複数のデータストリームを一元管理して統合できます。また、特定の利用者に偏らず、作業負荷を均等に分散させる効果もあります。 

• コストの管理のため

レートリミッティングは、パフォーマンスの最適化だけでなく、コスト削減にも有用です。追加投資なしでリソースの自動スケールを実現し、SaaSソリューションや顧客別のサービス提供にも活用できます。

‍

レートリミッティングの方法

• 固定ウィンドウ方式

特定の時間内にのみAPIリクエストを受け付ける方式です。例えば、この方式を採用したサーバは、許可された時間帯にのみリクエストを受け入れます。

例えば、管理者が10:00～10:30の間、1秒に100リクエストまでと設定した場合、サーバはこのルールに従います。この方法はサーバレベル、利用者レベルの両方に適用されますが、それぞれ意味が異なります。 

利用者レベルでは、1利用者がその時間内に100リクエストを送れるという意味です。一方、サーバレベルでは、1台のサーバが1秒に100リクエストを受け入れ、利用者数は問いません。

この方式は使いやすく、新たなリクエスト不足を招くことはありませんが、時間帯開始時にリクエストが集中するという欠点もあります。

• スライディングウィンドウ方式

こちらも時間ベースで使いやすい方式です。新たなリクエストがあると同時にウィンドウが開始されるため、固定ウィンドウ方式のリクエスト不足の問題が解消されます。また、漏れバケツ方式の問題も見受けられません。

• トークンバケツ方式

利用可能な予算を段階的に管理し、トークンで残量を示す方式です。すべてのリクエストに1対1で対応する高度な技術を用い、同じ割合でトークンがバケツに追加されます。 

サービスリクエストが発生すると、対応する処理がトークンの引き出しを試み、成功すればリクエストが処理されます。バケツが空になる、またはトークンが不足すると、上限に達したと判断され、処理が遅延します。 

この方式の最も単純な例は、GraphQLサービスで見られ、1つのリクエストが複数の結果を生み出し、各結果にトークンが付与されて容量が管理されます。 

• 漏れバケツ方式

この方式は時間に依存せず、固定長のキューを使用します。ご存知の通り、ウェブサーバは先着順でリクエストに対応します。

先に送られたリクエストがキューの先頭に位置し、以降のリクエストが順次並びます。キューの長さは固定されており、あらかじめ定められた長さに達すると、それ以降のリクエストは受け付けられません。

この方式は分かりやすく、サーバが着実にAPIリクエストを処理できるようにします。しかし、キューが静的なため、新たなリクエストが長期間待たされる（スタベーション）リスクがあります。 

‍

レートリミッティングの利点

適切に活用すれば、レートリミッティングは特定の攻撃や危険を防ぐのに非常に有効です。

• DDoS攻撃

DDoS攻撃は、予期せぬAPIリクエストを大量に送り込むことでシステムに負荷をかけ、正当な利用者のアクセスを妨げる手法です。レートリミッティングはリクエスト頻度を厳格に制御するため、DDoS攻撃を防止できます。

• ブルートフォース攻撃

ブルートフォース攻撃は、無数のAPIリクエストを送り、一度でも通過することを狙います。多くの場合、攻撃者は自動化ツールを用いて大量のリクエストを送信します。リクエスト数を制限することで、異常な行動を検知し、サイバーセキュリティ担当者に速やかに知らせることが可能です。

‍

APIにおけるレートリミッティングとは？

APIは紹介を要せず、アプリの中核をなすものであり、クライアントとサーバ間の通信に不可欠です。接続リクエストがあるたびにAPIは応答し、その処理には計算資源のコストがかかります。 

ここでいう計算資源とは、コードの実行やAPIリクエスト・レスポンスの生成に必要なサーバリソースを指します。これには費用が伴うため、すべてのAPI利用者が同等の体験を得るための最適な管理が求められます。 

この時、登場するのがAPIレートリミッティング、別名API制限です。APIやそのセキュリティに関わる場合、必ず理解しておくべき内容です。

この手法は、単一のIPからのリクエストを最適化し制限することで、APIへの不正なアクセスを防ぎます。どの利用者もAPIを過剰に消費せず、均一に利用可能となります。

また、DDoSやブルートフォース攻撃からAPIを守るだけでなく、APIの利用拡大時にも、トラフィックを管理し、運用上の問題や利用過多を防ぐために有効です。

一般的なAPI制限の方法としては、以下のものがあります。

• hard stop方式では、APIリクエストの上限に達すると、それ以降のリクエストに対してエラーメッセージが返されます。
• soft stop方式では、システムはリクエストの受付を継続しますが、一定時間待機状態に置き、その間に追加リクエストに対して課金やプランのアップグレードを促すことが可能です。
• もう一つ、throttled stop方式は、上限を超えた時に応答速度を落とす手法です。

詳細はOWASP API4 - リソース不足とレートリミッティングをご参照ください。

APIスロットリング vs レートリミッティング

これらはほぼ同じと思われがちですが、実際は違いがあります。

それぞれについて順に説明します。

レートリミッティングは、時間やキューの長さを基準に総リクエスト数を制限し、上限を超えたリクエストは自動的に拒否されます。ミリ秒から数年まで、さまざまな時間ウィンドウで設定が可能です。 

一方、APIスロットリングではリクエスト処理方法に応じた制限が設けられ、上限を超えたリクエストはキューに入れられます。一定回数の試行後、処理が完了しなければ、それ以降のリクエストは拒否されます。

また、再試行の間隔や回数も設定可能で、これはサーバが定め、利用者は従う必要があります。APIスロットリングは、RetriesやExponential Backoffなどのポリシーと併用されます。

どちらの手法もリクエストやリソースに制限を設けます。APIレートリミッティングの実装方法を理解する前に、SLAに基づくポリシーが存在するかを確認することが重要です。SLAがない場合、制限の設定とポリシー適用は同時に行われます。

Wallarmによるレートリミッティング強化策

貴社では不正なリクエストに対して慎重に対処する必要があり、レートリミッティングがその助けとなります。適切に設定されれば、APIセキュリティに大きな効果をもたらしますが、これだけで完全な安全が確保されるわけではありません。 

APIやその他のリソースのエンドツーエンドのセキュリティを実現するには、Wallarmが提供する複数のAPIセキュリティ対策を組み合わせた、より詳細な防御策が必要です。以下に、Wallarmがどのように組織の防御策を強化するかを紹介します。 

• Cloud WAF

あらゆるAPIやサーバレスリソースを守るWallarm Cloud WAFは、革新的なセキュリティ技術で、レートリミッティングと併用することで保護効果を高めます。WAFは完全自動で使いやすく、DNS設定の簡単な変更のみで全方位の保護が可能です。 

また、WAFはPCIやSOC2の基準を満たしており、信頼に足る製品です。ゼロ RegExps、lib検出、バイパス耐性など、最先端の検知技術を備え、包括的な保護を提供します。問題があれば、迅速に対応するアナリストチームがサポートします。

• API Threat Prevention

Wallarmでは、API保護、自動インシデント対応、API検出を備えた統合型のAPI脅威対策が用意されています。この包括的な対策により、脆弱性がAPIに侵入し悪用されるリスクを大幅に減少させます。主要なAPI、サーバレスリソース、マイクロサービス、ウェブアプリにも対応可能です。

また、利用するデジタル環境に制約されず、どのクラウド環境でもリソースを保護できます。WebSocket、XML、JSON、グラフィックなどに対応した高度なAPIコール解析機能を備えており、このような革新的な防御策と組み合わせることで、レートリミッティングの効果がさらに向上します。