API Gateway

この用語をシェア

概要

API Gateway（APIゲートウェイ）とは、複数のAPIサービスへの統一されたエントリーポイントとして機能するサービスです。クライアントとバックエンドサービス間の仲介役として、認証、認可、レート制限、監視、プロトコル変換などの横断的機能を提供します。

本ページではAPI Gatewayのセキュリティ観点（認証・認可、レート制限、WAF連携など）を中心に解説します。ルーティングやアーキテクチャ全般の機能については「API Gateway（機能・アーキテクチャ）」で詳しく解説していますので、あわせてご覧ください。

主な機能

セキュリティ機能

認証・認可 - JWT、OAuth 2.0、API キーによるアクセス制御
レート制限 - API使用量の制限とスロットリング
IP ホワイトリスト/ブラックリスト - IPアドレスベースのアクセス制御
SSL/TLS 終端 - 暗号化通信の処理

トラフィック管理

ロードバランシング - 複数のバックエンドサービスへの負荷分散
フェイルオーバー - サービス障害時の自動切り替え
サーキットブレーカー - 障害の連鎖を防ぐ自動遮断機能
リトライ機構 - 失敗したリクエストの自動再試行

データ変換

プロトコル変換 - HTTP/HTTPS、WebSocket、gRPCなどの変換
リクエスト/レスポンス変換 - データフォーマットの変換
ヘッダー操作 - HTTPヘッダーの追加・削除・変更

監視・分析

ログ記録 - 詳細なアクセスログの出力
メトリクス収集 - パフォーマンス指標の監視
分析・ダッシュボード - API使用状況の可視化
アラート機能 - 異常検知と通知

マイクロサービス環境での重要性

複雑性の軽減

マイクロサービスアーキテクチャでは、数十から数百のサービスが連携します。API Gatewayにより以下の課題を解決：

クライアントが個別のサービス位置を知る必要がない
横断的関心事の一元管理
サービス間通信の簡素化

運用効率の向上

バージョン管理 - APIバージョンの一元管理
デプロイメント戦略 - カナリアリリース、ブルーグリーンデプロイの支援
開発者体験 - 統一されたAPI仕様とドキュメント

主要なAPI Gatewayソリューション

クラウドネイティブ

Amazon API Gateway - AWSのマネージドサービス
Azure API Management - Microsoftのクラウドサービス
Google Cloud Endpoints - GCPのAPI管理サービス

オープンソース

Kong - 高性能なマイクロサービス API Gateway
Envoy Proxy - Cloud Native Computing Foundation プロジェクト
Zuul - Netflix開発のJavaベースゲートウェイ
Ambassador - Kubernetes ネイティブなAPI Gateway

エンタープライズ

Apigee - Google Cloudのエンタープライズソリューション
MuleSoft Anypoint Platform - 統合プラットフォーム
WSO2 API Manager - オープンソースベースのエンタープライズ製品

セキュリティ上の考慮事項

単一障害点リスク

API Gatewayは重要なインフラストラクチャコンポーネントのため、以下の対策が必要：

高可用性設計（冗長化）
適切な監視とアラート
バックアップとディザスタリカバリー計画

セキュリティベストプラクティス

最小権限原則 - 必要最小限のアクセス権限
入力検証 - すべてのAPIリクエストの検証
ログ監査 - セキュリティイベントの記録と分析
定期的な脆弱性評価 - セキュリティ監査の実施

WAF単体との違い

「WAF（Web Application Firewall）さえ導入すればAPIは守れるのでは」と考えられがちですが、API GatewayとWAFは防御対象が異なるため、両者を併用するのが一般的です。

比較項目	API Gateway	WAF単体
主な防御対象	認証・認可、レート制限、API仕様違反	SQLインジェクション、XSSなどの既知攻撃パターン
APIの仕様理解	エンドポイント・スキーマ単位で制御可能	HTTPリクエスト全般をシグネチャで検査
認証機能	あり（OAuth/JWT/APIキー等）	なし
推奨構成	WAFの後段でAPI固有の制御を実施	API Gatewayの前段で汎用攻撃を遮断

実務上は「WAFで汎用的な攻撃パターンを遮断し、その後段のAPI Gatewayで認証・認可やAPI固有のビジネスロジックに関わる制御を行う」という多層構成が推奨されます。

WAF連携の設定例

AWS API Gatewayの場合、AWS WAF（Web Application Firewall）をWebACLとして関連付けることで、SQLインジェクションやクロスサイトスクリプティング（XSS）などの攻撃をAPI到達前にブロックできます。

# API GatewayステージにWAF WebACLを関連付ける例（AWS CLI）
aws wafv2 associate-web-acl \
  --web-acl-arn "arn:aws:wafv2:region:account-id:regional/webacl/MyWebACL/xxxx" \
  --resource-arn "arn:aws:apigateway:region::/restapis/api-id/stages/prod"

# レート制限ルールの例（1つのIPから5分間に2000リクエストを超えたらブロック）
{
  "Name": "RateLimitRule",
  "Priority": 1,
  "Statement": {
    "RateBasedStatement": {
      "Limit": 2000,
      "AggregateKeyType": "IP"
    }
  },
  "Action": { "Block": {} }
}

Kongなどのオープンソースゲートウェイでは、rate-limitingプラグインやip-restrictionプラグインを設定ファイル（YAML）で宣言的に定義することで、同様の保護を実現できます。

認証方式の比較

API Gatewayで選択できる代表的な認証方式には、それぞれ適した利用場面があります。

認証方式	仕組み	主な用途	注意点
APIキー	固定の鍵文字列をヘッダー等で送信	社内向けAPI、シンプルな利用量管理	漏洩時のリスクが高く、権限の細分化が難しい
OAuth 2.0	認可サーバーが発行するアクセストークンで認可	サードパーティ連携、委譲された権限が必要な場面	実装がやや複雑、トークン管理の設計が必要
JWT	署名付きトークンにクレーム情報を格納	マイクロサービス間のステートレスな認証	失効管理が難しく、有効期限設計が重要
mTLS（相互TLS認証）	クライアント証明書による相互認証	サービスメッシュ内の通信、金融機関間API	証明書の発行・更新・失効管理の運用負荷

導入のメリット・デメリット（セキュリティ観点）

メリット

認証・認可ロジックを各マイクロサービスに個別実装せずに済み、実装漏れによる脆弱性を防げる
WAFやレート制限を一箇所に集約することで、攻撃を早期にブロックしバックエンドへの到達を防げる
監査ログを一元的に取得でき、インシデント発生時の調査（フォレンジック）が容易になる

デメリット・注意点

API Gateway自体が攻撃対象となるため、Gateway自身の脆弱性対策・パッチ適用が必須になる
設定ミス（認証の掛け忘れ、レート制限の閾値が緩すぎる等）が全APIに影響する単一障害点になり得る
WAFルールが厳しすぎると正規リクエストを誤検知（False Positive）でブロックする可能性がある
mTLSなど強固な認証を導入するほど、証明書管理などの運用コストが増加する

実務での導入時の注意点

OWASP API Security Top 10を参照する：認可の不備（BOLA）や過剰なデータ露出など、API特有の脆弱性パターンを踏まえてゲートウェイの設定を見直します。
デフォルト拒否（Deny by Default）を徹底する：明示的に許可したAPIパス・メソッドのみを通過させ、想定外のエンドポイントを塞ぎます。
段階的なレート制限を設計する：一律の制限ではなく、認証済みユーザーと未認証ユーザーで異なる閾値を設定します。
秘密情報のログ出力を避ける：APIキーやトークンがアクセスログに平文で残らないよう、マスキング設定を行います。

APIゲートウェイだけでは防げない脆弱性

API Gatewayはリクエストの入口を守る強力な防御層ですが、万能ではありません。特に注意すべきなのが、BOLA（Broken Object Level Authorization、オブジェクトレベル認可の不備）と呼ばれる脆弱性です。これは「認証は成功しているが、他人のリソースIDを指定すればアクセスできてしまう」という問題で、Gatewayでの認証チェックだけでは検知できません。

例えば、GET /api/users/123/ordersというエンドポイントに対して、認証済みの別ユーザーが自分のIDではない456を指定してアクセスできてしまうケースがこれに該当します。この種の脆弱性は、Gatewayでの認証（Authentication）に加えて、バックエンドアプリケーション側でリソース単位の認可（Authorization）チェックを実装することでのみ防げます。API Gatewayの導入を「セキュリティ対策が完了した」と誤解せず、アプリケーション層での対策とあわせて多層防御を構成することが重要です。

実装時のベストプラクティス

設計原則

ステートレス設計 - スケーラビリティの確保
非同期処理 - パフォーマンスの最適化
graceful degradation - 部分的な障害時の継続稼働

運用管理

APIファーストアプローチ - 設計段階からのAPI設計
継続的監視 - パフォーマンスとセキュリティの監視
ドキュメンテーション - 包括的なAPI仕様書の維持

2025〜2026年の最新動向

2025年はAI APIのセキュリティ管理が重要テーマに。LLM APIのプロンプトインジェクション対策、トークン使用量制限、コスト管理機能がAPIゲートウェイに統合されています。

よくある質問（FAQ）

Q. アプリケーションセキュリティにおけるAPIゲートウェイの役割は？

A. APIゲートウェイは、アプリケーション層でのセキュリティ（認証・認可、レート制限、入力検証、WAF機能）を一元管理し、バックエンドサービスを保護します。

Q. APIゲートウェイのセキュリティ機能は？

A. OAuth/JWT認証、IPホワイトリスト、レート制限（DDoS対策）、入力バリデーション、TLS終端、リクエスト/レスポンスの変換・フィルタリング、監査ログが主な機能です。

Q. マイクロサービスでのAPIゲートウェイは？

A. Istio、Envoy、Kong、NGINX等のサービスメッシュ/ゲートウェイがマイクロサービス間の通信を保護します。mTLS（相互TLS認証）による通信暗号化が標準です。

Q. APIキーとOAuth 2.0はどちらを使うべきですか？

A. 社内システムなど信頼できる限定的な利用者向けにはAPIキーで十分ですが、第三者アプリへのアクセス権限委譲やユーザー単位の細かい権限制御が必要な場合はOAuth 2.0が適しています。

Q. API Gatewayを導入すればAPIは安全になりますか？

A. API Gatewayは有効な防御層ですが万能ではありません。認可の不備（BOLA）など、Gateway単体では防げない脆弱性もあるため、OWASP API Security Top 10を踏まえた設計・コードレベルの対策と併用する必要があります。