こんにちは。現場の最前線で泥臭いインシデント対応を続けているセキュリティエンジニアです。
今日は「APIの守り方」についてお話しします。難しそうに聞こえるかもしれませんが、実はあなたの家の防犯と同じ。考え方はとてもシンプルです。一緒に一歩ずつ学んでいきましょう。
—
泥棒は「ガチャガチャ」とドアノブを回すことから始める
APIのセキュリティでまず意識すべきなのが「ブルートフォース攻撃（総当たり攻撃）」です。
想像してみてください。泥棒があなたの家の玄関前で、何千個もの鍵を試して開けようとする光景を。もし、鍵を試す回数に制限がなかったら？泥棒は夜通しガチャガチャとドアノブを回し続け、いつかは正解の鍵にたどり着いてしまいますよね。
APIの世界でも同じことが起きています。攻撃者は自動化されたプログラムを使って、パスワードやAPIキーを1秒間に何百回、何千回と送りつけてきます。これに対抗するのが「レート制限（Rate Limiting）」という仕組みです。
レート制限＝「インターホン越しに制限する門番」
レート制限とは、簡単に言えば「短時間に何度もアクセスしてくる怪しい人を、門前払いする仕組み」です。
「1分間に10回までしかAPIを叩いてはいけない」というルールを設けることで、もし誰かがその制限を超えてアクセスしてきたら、「ちょっと多すぎますよ、しばらく待ってください」と門前払いするわけです。これで、泥棒がガチャガチャと鍵を試すスピードを物理的に封じ込めることができます。
実際に設定してみよう（Nginxの例）
現場でよく使われるWebサーバー「Nginx」での設定例を見てみましょう。この設定を入れるだけで、特定のIPアドレスからのアクセスを自動的に制限できます。
# 1分間に10回までのリクエストを許可するゾーンを定義
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/m;
server {
location /api/ {
# 定義したゾーンを適用。バースト（一時的な集中）は5回まで許容
limit_req zone=api_limit burst=5 nodelay;
# 制限を超えたら「429 Too Many Requests」エラーを返す
limit_req_status 429;
}
}rate=10r/m: 1分間に10回（10 requests/minute）という制限です。burst=5: ちょっとしたアクセス集中は許してあげる「余裕枠」です。429 Too Many Requests: これが「今は多すぎるから少し休んで！」という合図です。
なぜ「暗号」の話とセットなのか？
よく「レート制限があるなら、暗号化しなくていいの？」と聞かれますが、それは大きな間違いです。
暗号（AESやRSAなど）は「通信内容を盗み見られないようにする」ためのもの。一方でレート制限は「サーバーがダウンしないように、そして不正アクセスを遅延させる」ためのもの。
たとえるなら、暗号は「郵便物に鍵をかけること」、レート制限は「ポストに大量のチラシを詰め込まれないように門を閉じること」です。両方揃って初めて、あなたの家（サーバー）は安全になるのです。
開発者が知っておくべき「防御ヘッダー」の正体
APIを叩く側（クライアント）に向けて、「あと何回アクセスできるか」を伝えるのも親切な設計です。HTTPレスポンスヘッダーに以下のような情報を載せるのが一般的です。
X-RateLimit-Limit: 全体で許可されている回数X-RateLimit-Remaining: 残りあと何回叩けるかX-RateLimit-Reset: 制限が解除される時刻
これらを実装することで、正当なユーザーは「あ、今叩きすぎるとエラーになるんだな」と理解して、アプリ側でリクエストのタイミングを調整できるようになります。
—
最後に：完璧な防御なんて存在しない
セキュリティの世界では「100%安全」は幻想です。今回紹介したレート制限も、攻撃者がIPアドレスを数万個用意する「分散型DoS攻撃」には突破される可能性があります。
でも、安心してください。セキュリティとは「泥棒が『この家は面倒くさいな、他に行こう』と思うくらいの手間をかけること」です。
まずは、あなたのAPIに「1分間に100回以上のアクセスがあったら弾く」という簡単な鍵をかけることから始めてみませんか？その小さな一歩が、あなたのサービスとユーザーを守る大きな盾になります。
何か分からないことがあれば、いつでもまた聞きに来てくださいね。一歩ずつ、強固なシステムを作っていきましょう！
コメント