こんにちは！インフラやセキュリティの世界へようこそ。新人IT担当者の皆さん、あるいは「セキュリティってなんだか難しそうだな…」と感じている一般開発者の皆さん、日々の開発やインフラ管理、本当にお疲れ様です。
今日は、私たちが日々作り上げるWebシステムやクラウド環境の「玄関口」を守る、とっても大切なテーマについてお話しします。その名も「APIゲートウェイにおける認証・認可とレート制限」です！
「うわ、また横文字がたくさん出てきたぞ……」と思いましたか？
大丈夫です。一歩ずつ、身近な例えを使いながら優しく紐解いていきますので、肩の力を抜いて読み進めてくださいね。
—
1. 家の防犯に例えて考えてみよう
皆さんが暮らしている「家」を想像してみてください。
頑丈な玄関のドアがあって、鍵をかけますよね。さらに、オートロックのマンションだったり、インターホンで相手を確認してからドアを開けたりするはずです。
もし、この玄関の鍵が壊れていて、誰でも自由に家の中に入れて、リビングの棚から勝手に持ち出せるとしたら……？ 想像するだけでゾッとしますよね。
私たちが作るWebシステムやAPI（外部のプログラムとデータをやり取りする窓口）もこれとまったく同じです。
インターネットという広大な外の世界にシステムを公開するとき、「誰が来てもウェルカム！」状態にしておくのは、玄関の鍵を全開にして泥棒を招き入れているようなものなんです。
ここで登場するのが、今回学ぶ「APIゲートウェイ」です。
APIゲートウェイは、いわば「マンションの頑丈なオートロック付きエントランス受付」のような役割を果たします。外からやってきたすべてのリクエスト（訪問者）は、まずこのAPIゲートウェイを通らなければなりません。
—
2. 認証と認可：合言葉と身分証のチェック
APIゲートウェイというエントランスにやってきた訪問者に対して、私たちは何をしなければならないでしょうか？ それが認証（Authentication）と認可（Authorization）です。
認証（Authentication）＝「あなたは誰ですか？」
これは、訪問者が本人であることを証明してもらう作業です。
身近な例で言えば、運転免許証を見せたり、パスポートを提示したりするアレですね。Webの世界では、OAuth 2.0やOIDC（OpenID Connect）といった仕組みを使い、Googleや社内の認証基盤などの信頼できる第三者に「この人は本物の〇〇さんですよ」とお墨付きをもらった「デジタル身分証（アクセストークン）」を提示してもらいます。
認可（Authorization）＝「この部屋に入っていい人ですか？」
無事に本人確認（認証）が済んだとしても、マンションの住人が他人の部屋の合鍵を持っているわけではありませんよね。
「この人は101号室の住人だから101号室には入れるけれど、管理人室や他の人の部屋には入れない」という、権限のチェックを行うのが認可です。
APIゲートウェイでこれらを一元管理することで、個別のバックエンドサーバー（部屋）がわざわざ毎回「あなたは誰？」と確認しなくて済むようになり、セキュリティと効率がぐっと向上するんです。
—
3. レート制限：無限アタックを防ぐ「入場規制」
さて、認証と認可のバリアを突破したとしましょう。でも、セキュリティの世界にはもう一つの大きな脅威が潜んでいます。それがブルートフォース攻撃（総当たり攻撃）やDDoS攻撃です。
悪意ある攻撃者は、自動化されたプログラムを使って、1秒間に何千回、何万回とパスワードを総当たりで試したり、サーバーをダウンさせようと大量のリクエストを送りつけてきます。これは例えるなら、悪質なクレーマーが何百人も一気に押し寄せて、お店の入り口を完全に塞いでしまう状態です。
これを防ぐためにAPIゲートウェイに設定するのがレート制限（スロットリング）です。
「1人のユーザーから許可するのは、1分間に最大60回のリクエストまで！」という風に、入場制限のルールを設けるわけですね。
もし制限を超えてアクセスしてきたお行儀の悪い訪問者がいたら、APIゲートウェイが「ちょっと早すぎます！落ち着いてくださいね」と、アクセスをピシャリと遮断（HTTPステータスコード 429 Too Many Requests を返却）してくれます。
—
4. 実践！NGINXを使ったAPIゲートウェイの設定例
百聞は一見に如かず。実際に、よく使われるリバースプロキシ／APIゲートウェイであるNGINXを例に、簡単なレート制限の設定を見てみましょう。
「設定ファイル」という言葉に身構えてしまうかもしれませんが、日本語のコメントを添えてありますので、一緒に見ていきましょうね。
# 1秒間に処理するリクエスト数のレート制限ゾーンを定義します
# ここでは「ip_zone」という名前で、クライアントのIPアドレスごとに制限をかけます
limit_req_zone $binary_remote_addr zone=ip_zone:10m rate=5r/s;
server {
listen 80;
server_name api.example.com;
location /v1/data {
# 定義したレート制限を適用します
# burst=10 は「ちょっとした急なアクセス集中なら10回までは待たせてあげるよ」という優しさのバッファです
# nodelay をつけると、バッファを超えた瞬間にエラーを返します
limit_req zone=ip_zone burst=10 nodelay;
# 認証が通った安全なバックエンドサーバーへ転送します
proxy_pass http://backend-server-cluster;
# セキュリティのためのヘッダー付与もここで行います
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}このように、APIゲートウェイのレイヤーで「1秒間に5回まで（rate=5r/s）」と明確にルールを定めておくことで、サーバー全体の崩壊を防ぐことができるのです。
—
5. 防御ヘッダーの意味を知る
APIゲートウェイやWebサーバーからクライアントへ応答（レスポンス）を返す際、いくつかのセキュリティヘッダーを付与することが、堅牢なシステムを作る上での定跡となっています。
代表的なものをいくつか、優しく解説しておきますね。
X-Content-Type-Options: nosniff- ブラウザが「本当のファイル形式を勝手に推測して実行しちゃうおせっかい」を禁止する設定です。悪意あるファイルがプログラムとして誤認されるのを防ぎます。
X-Frame-Options: DENY(またはSAMEORIGIN)- 自社のAPIやWeb画面が、見知らぬ悪意あるサイトのフレーム（iframe）の中にこっそり埋め込まれて操作される「クリックジャッキング」という攻撃を防ぎます。
Content-Security-Policy (CSP)- 「うちのサイトでは、許可されたドメイン以外のスクリプトや画像は絶対に読み込みません！」という強力なルールブックをブラウザに言い聞かせる設定です。
これらを設定ファイルに一行書き加えるだけで、ブラウザという「お客様の盾」をより硬くすることができます。
—
まとめ：一歩ずつ、セキュアなシステムへ
今回は、APIゲートウェイにおける認証・認可と、レート制限の仕組みについて学びました。
1. APIゲートウェイはシステムの「頑丈なオートロックのエントランス」
2. 認証・認可で「誰が来て、どの部屋に入っていいか」を厳しくチェックする
3. レート制限で「大量の不正アクセスや総当たり攻撃（ブルートフォース）」から身を守る
セキュリティ対策は、一度にすべてを完璧にやろうとすると息切れしてしまいます。「まずはAPIゲートウェイでアクセス制限をかけてみよう」「次は認証トークンの検証を入れよう」というように、一歩ずつ、着実に実装を重ねていくことが何よりも大切です。
皆さんが手掛けるシステムが、今日も安全で、そして多くのユーザーに安心して使われるものになるよう、心から応援しています！
それではまた、次回のセキュリティ解説でお会いしましょう。
コメント