API Security & Authentication

APIセキュリティとは、アプリケーション・プログラミング・インターフェース（API）を不正アクセス、データ漏洩、悪用から保護するための包括的なセキュリティ対策です。現代のWebサービス、モバイルアプリケーション、マイクロサービスアーキテクチャでは、APIがシステム間のデータ連携の中核を担っており、そのセキュリティは組織全体のセキュリティ態勢に直結します。

APIの認証方式には、APIキー、OAuth 2.0トークン、JWT（JSON Web Token）、mTLS（相互TLS認証）など複数の手法があり、APIの用途やセキュリティ要件に応じて適切な方式を選択する必要があります。単純なAPIキーは手軽ですが、セキュリティレベルは低く、OAuth 2.0やmTLSはより堅牢な認証・認可を提供します。

OWASP（Open Worldwide Application Security Project）はAPI Security Top 10（2023年版）を公開し、APIに特有の脆弱性と対策を体系的にまとめています。APIの爆発的な増加に伴い、API経由のデータ侵害は年々増加しており、APIセキュリティは現代のサイバーセキュリティにおける最重要課題の一つとなっています。

API認証方式の比較

• APIキー：ランダムな文字列をHTTPヘッダーやクエリパラメータで送信するシンプルな認証方式。実装は容易だが、キーの漏洩リスクが高く、アクセス制御の粒度が粗い。主にサービス間通信やパブリックAPIのレート制限に使用
• OAuth 2.0トークン：認可フレームワークOAuth 2.0で発行されるアクセストークンを使用。Authorization Code、Client Credentials、Device Codeなど複数のフローがあり、スコープによる細かなアクセス制御が可能。トークンの有効期限管理とリフレッシュトークンの安全な保管が重要
• JWT（JSON Web Token）：ヘッダー、ペイロード、署名の3つのパートで構成される自己完結型トークン。サーバーサイドでのセッション管理が不要で、マイクロサービス間の認証に適している。ただし、トークンサイズが大きくなりがちで、失効処理に工夫が必要
• mTLS（相互TLS認証）：クライアントとサーバーの双方がX.509証明書を提示して相互に認証。最も堅牢な認証方式で、証明書の管理コストは高いが、サービスメッシュやゼロトラストアーキテクチャで採用が進む

OWASP API Security Top 10（2023年版）

OWASPが2023年に公開したAPI Security Top 10は、以下の脅威カテゴリを定義しています。

• API1:2023 - Broken Object Level Authorization（BOLA）：オブジェクトIDの操作により、他ユーザーのデータに不正アクセスできる脆弱性。最も頻繁に悪用される
• API2:2023 - Broken Authentication：認証メカニズムの実装不備。弱いトークン生成、不適切な認証フロー、パスワードポリシーの欠如など
• API3:2023 - Broken Object Property Level Authorization：オブジェクトのプロパティレベルでのアクセス制御不備。過剰なデータ露出や一括割り当て（Mass Assignment）を含む
• API4:2023 - Unrestricted Resource Consumption：レート制限やリソース制限の欠如によるDoS攻撃やコスト増大のリスク
• API5:2023 - Broken Function Level Authorization：管理者APIエンドポイントへの水平的・垂直的な権限昇格

APIゲートウェイとセキュリティ

APIゲートウェイは、すべてのAPI通信の入り口として機能し、認証・認可、レート制限、リクエストの検証、ログ記録などのセキュリティ機能を一元的に提供します。Kong、AWS API Gateway、Azure API Management、Google Cloud Apigeeなどの製品が広く使用されています。

APIゲートウェイでは、レート制限（Rate Limiting）により、特定のクライアントやIPアドレスからの過剰なリクエストを制限し、DDoS攻撃やブルートフォース攻撃を防止します。また、リクエスト・レスポンスのスキーマ検証を行うことで、不正なペイロードをブロックできます。

GraphQLセキュリティ

GraphQLは、RESTとは異なり、クライアントが必要なデータを正確に指定できるクエリ言語ですが、固有のセキュリティリスクがあります。深くネストされたクエリによるDoS攻撃（クエリの深さ制限が必要）、イントロスペクション機能によるスキーマの情報漏洩（本番環境では無効化推奨）、バッチクエリを悪用した大量データの取得などに対策が必要です。

OpenAPI/Swagger セキュリティ定義

OpenAPI仕様（旧Swagger）では、セキュリティスキーム（apiKey、http、oauth2、openIdConnect）を定義し、各エンドポイントに必要な認証・認可要件を明示できます。このセキュリティ定義をAPIゲートウェイやテストツールと連携させることで、API仕様と実装のセキュリティ要件の一貫性を保つことができます。

• 01
  OAuth 2.0 + JWTの適切な実装：APIの認証にはOAuth 2.0フレームワークを採用し、JWTアクセストークンの署名アルゴリズムにはRS256またはES256を使用してください。「alg: none」攻撃を防ぐため、許可するアルゴリズムをホワイトリストで管理し、トークンの有効期限は短く（15分程度）設定しましょう。
• 02
  オブジェクトレベル認可（BOLA対策）の徹底：すべてのAPIエンドポイントで、リクエスト元のユーザーが対象のオブジェクト（リソース）にアクセスする権限を持つかを検証してください。IDの推測やインクリメントによる他ユーザーデータへのアクセスを防止するため、UUIDの使用と認可チェックの二重防御を実装しましょう。
• 03
  レート制限とスロットリングの実装：APIエンドポイントごとに適切なレート制限を設定し、ブルートフォース攻撃やDDoS攻撃を防止してください。認証エンドポイントにはより厳格な制限を設定し、レスポンスヘッダー（X-RateLimit-Limit、X-RateLimit-Remaining）で制限情報をクライアントに通知しましょう。
• 04
  APIキーのライフサイクル管理：APIキーには有効期限を設定し、定期的にローテーションしてください。キーはソースコードやバージョン管理システムにハードコードせず、シークレット管理サービス（AWS Secrets Manager、HashiCorp Vaultなど）で安全に管理しましょう。漏洩したキーの即座の失効も重要です。
• 05
  入力バリデーションとスキーマ検証：すべてのAPIリクエストに対して、OpenAPI仕様に基づくスキーマ検証を実施してください。パラメータの型、長さ、範囲、パターンを厳密に検証し、SQLインジェクション、NoSQLインジェクション、コマンドインジェクションなどのインジェクション攻撃を防止します。
• 06
  APIインベントリとシャドーAPI検出：組織内のすべてのAPIエンドポイントを把握するAPIインベントリを維持し、定期的にネットワークスキャンやトラフィック分析でシャドーAPI（管理されていないAPI）やゾンビAPI（廃止されたが稼働中のAPI）を検出・排除してください。把握されていないAPIは攻撃の入口になります。