Web Security

API Gateway

APIゲートウェイ

Category: Web Security / Updated: 2026-05-26

📖

Overview

APIゲートウェイ(API Gateway)とは、クライアントからのAPIリクエストを一元的に受け付け、認証・認可、レート制限、ログ集約、ルーティングなどの共通機能を提供するサーバーコンポーネントです。マイクロサービスアーキテクチャにおいて、複数のバックエンドサービスへのアクセスを統合管理する要となります。

APIゲートウェイはリバースプロキシとして機能し、外部からの全APIトラフィックの入り口となります。これにより、個々のマイクロサービスが認証やレート制限のロジックを個別に実装する必要がなくなり、セキュリティポリシーの一貫した適用が可能になります。また、リクエスト・レスポンスの変換やプロトコル変換も担います。

近年のクラウドネイティブ環境では、APIゲートウェイはセキュリティの第一防衛線として不可欠なインフラストラクチャです。不正なAPIアクセスの増加に伴い、APIセキュリティの重要性はますます高まっており、適切に設定されたAPIゲートウェイはAPIの悪用・乱用を防ぐ上で極めて重要な役割を果たします。

🔬

Details

主要機能

  • ルーティング:クライアントのリクエストを適切なバックエンドサービスに振り分ける。URLパス、HTTPメソッド、ヘッダーなどに基づいてルーティングルールを定義
  • 認証・認可:API Key検証、OAuth 2.0トークン検証、JWT(JSON Web Token)の署名検証を一元的に実行し、不正なリクエストをバックエンドに到達させない
  • レート制限(Rate Limiting):クライアントごと・エンドポイントごとのリクエスト頻度を制限し、DDoS攻撃やAPIの乱用を防止する
  • キャッシュ:頻繁にアクセスされるレスポンスをキャッシュし、バックエンドサービスの負荷を軽減するとともにレスポンス速度を向上
  • ログ・モニタリング:全APIトラフィックのアクセスログを一元管理し、異常検知やトラブルシューティングに活用する
  • リクエスト・レスポンス変換:プロトコル変換(REST↔gRPC等)やデータフォーマット変換(XML↔JSON等)を行い、クライアントとバックエンドの差異を吸収

主要製品・サービス

  • Kong:オープンソースのAPIゲートウェイで、Nginxベースの高性能なプラグインアーキテクチャを持つ。Kubernetes環境との統合に優れる
  • AWS API Gateway:AWSが提供するフルマネージドサービス。REST API、HTTP API、WebSocket APIに対応し、Lambda関数との連携が容易
  • Google Apigee:エンタープライズ向けのAPI管理プラットフォーム。APIライフサイクル管理、開発者ポータル、高度な分析機能を提供
  • Azure API Management:Microsoft Azureのフルマネージドサービス。APIの公開・保護・分析を統合的に管理でき、ハイブリッド環境にも対応

BFF(Backend for Frontend)パターン

BFFとは、フロントエンドの種類(Web、モバイル、IoTなど)ごとに専用のAPIゲートウェイ層を設けるアーキテクチャパターンです。各クライアントに最適化されたAPIインターフェースを提供することで、不要なデータ転送を削減し、クライアントごとに異なるセキュリティポリシーや認証フローを適用できます。

GraphQL Gateway

GraphQL Gatewayは、複数のGraphQLサービスやRESTサービスを統合し、単一のGraphQLエンドポイントとして公開するゲートウェイです。スキーマスティッチングApollo Federationなどの技術を用いてスキーマを統合します。GraphQL特有のセキュリティリスク(クエリの深さ制限、コスト分析、イントロスペクション無効化)にも対応が必要です。

セキュリティ機能

APIゲートウェイのセキュリティ機能は多岐にわたります。IPホワイトリスト・ブラックリストによる接続元制限、mTLS(相互TLS認証)によるクライアント証明書検証、WAF連携による攻撃パターン検出、ボット検出による自動化された不正リクエストの遮断など、多層的な防御を実現します。

また、APIゲートウェイはAPIスキーマ検証機能を通じて、不正なリクエストペイロード(SQLインジェクション、XXEなど)をバックエンドに到達する前にブロックすることもできます。

🛡️

Security Measures

  • 01
    強力な認証・認可の実装:APIゲートウェイでOAuth 2.0 / OpenID Connect / JWT検証を一元的に実施してください。API Keyのみの認証は避け、トークンベースの認証と適切なスコープ制御を組み合わせましょう。
  • 02
    適切なレート制限の設定:エンドポイントごと・ユーザーごとにレート制限を設定し、APIの乱用やDDoS攻撃を防止してください。スロットリングポリシーはAPIの重要度に応じて段階的に設定しましょう。
  • 03
    入力検証とスキーマバリデーション:OpenAPI仕様に基づいたリクエストスキーマ検証を有効にし、不正なペイロードをバックエンドに到達させないでください。Content-Typeの厳格な検証も実施しましょう。
  • 04
    ログとモニタリングの強化:全APIトラフィックのアクセスログを収集・分析し、異常なアクセスパターンをリアルタイムで検出してください。SIEM連携やアラート設定により、攻撃の早期発見を実現しましょう。
  • 05
    TLS/mTLSの適用:クライアント−ゲートウェイ間およびゲートウェイ−バックエンド間の全通信をTLSで暗号化してください。機密性の高いAPIではmTLS(相互TLS認証)を適用し、クライアント証明書による認証を追加しましょう。
  • 06
    APIバージョン管理と非推奨ポリシー:APIのバージョン管理を徹底し、古いバージョンのAPIを適切に非推奨・廃止してください。未使用のエンドポイントやシャドーAPIを定期的に棚卸しし、攻撃対象面を最小化しましょう。
⚠️

Incidents

📋 Optus APIゲートウェイ設定ミスによる大規模情報漏洩(2022年)

2022年9月、オーストラリアの大手通信事業者Optusは、APIゲートウェイの設定ミスにより約980万人の顧客個人情報が流出する重大なインシデントが発生しました。認証が不要な状態でAPIエンドポイントがインターネットに公開されており、攻撃者は認証なしで顧客データベースに直接アクセスできました。

流出した情報には氏名、生年月日、メールアドレス、電話番号、住所、パスポート番号、運転免許証番号などが含まれていました。この事件はAPIゲートウェイにおける認証設定の不備がいかに甚大な被害をもたらすかを示す代表的な事例となり、オーストラリア政府はデータ保護法の強化に着手しました。

📋 Parler APIスクレイピング事件(2021年)

2021年1月、SNSプラットフォームParlerがAWSからのサービス停止を通告された際、セキュリティ研究者がParlerのAPIの脆弱性を利用して、公開されていた投稿やメディアデータを大量にスクレイピングしました。APIにはレート制限が適切に設定されておらず、認証なしでアクセス可能なエンドポイントが多数存在していました。

約70TBのデータ(投稿、画像、動画、位置情報を含むEXIFデータ)がアーカイブされました。投稿のIDが連番で予測可能だったことも大量スクレイピングを容易にしました。APIゲートウェイのレート制限、認証の強制、IDの非推測性がいかに重要かを示す教訓的な事例です。

📋 APIレート制限不備によるデータ漏洩(Peloton 2021年)

2021年、フィットネス機器メーカーPelotonのAPIにおいて、レート制限と認証の不備により、約300万人のユーザーの個人情報が公開状態になっていることが発見されました。APIエンドポイントへの認証が適切に実施されておらず、リクエスト頻度の制限もない状態でした。

セキュリティ研究者が報告したにもかかわらず、Pelotonの初期対応は不十分で、修正に約3か月を要しました。ユーザーの年齢、性別、体重、ワークアウト統計、プロフィール情報などが外部から取得可能な状態でした。この事件はAPIセキュリティにおけるレート制限と認証の二重防御の重要性を改めて浮き彫りにしました。

🔗

Related Terms