Amazon API Gateway TLS セキュリティポリシーによる API セキュリティの強化

本記事は 2025年11月21日に公開された「Enhancing API security with Amazon API Gateway TLS security policies」を翻訳したものです。

コンプライアンスフレームワークが進化し、暗号化標準が進歩するにつれて、組織はクラウドセキュリティ体制を改善するための追加の制御を求めています。必要な制御の1つは、より詳細な TLS 設定です。たとえば、規制要件で CBC のような古い暗号を無効にすることや、TLS 1.3 を最小バージョンとして強制することが義務付けられている場合などです。

この記事では、新しい Amazon API Gateway の強化された TLS セキュリティポリシーが PCI DSS、Open Banking、FIPS などの標準を満たすのにどのように役立つのかや、API が TLS ネゴシエーションを処理する方法を強化する仕組みについて学びます。この新機能は、運用の複雑さを増やすことなくセキュリティ体制を向上させ、API Gateway インフラストラクチャ全体で TLS 設定を標準化する単一の一貫した方法を提供します。

概要

以前、API Gateway は TLS 設定に対する制御が限定的で、カスタムドメイン名に対してのみ提供されていました。デフォルトエンドポイントは固定のセキュリティポリシーを使用していたため、組織のセキュリティやコンプライアンス要件を満たすために、カスタム Amazon CloudFront ディストリビューションなどの追加インフラストラクチャを導入する必要がありました。

今回のリリースにより、すべての REST API エンドポイントタイプ（リージョナル、エッジ最適化、プライベートを含む）で TLS 動作を直接設定し、API とそのカスタムドメイン名の両方に一貫した TLS 設定を適用できます。ワークロードが必要とする最小 TLS バージョンと暗号スイートを強制するために、事前定義された強化セキュリティポリシーから選択できます。たとえば、TLS 1.3 を強制したり、CBC 暗号なしで強化された TLS 1.2 を使用したり、政府ワークロード向けに FIPS に準拠したスイートを採用したり、ポスト量子暗号（PQC）を含むポリシーで将来に備えたりできます。新しいセキュリティポリシーは、運用の複雑さを増やすことなく、より細かい制御を提供し、進化するセキュリティとコンプライアンスの期待に API を適合させるのに役立ちます。

API Gateway セキュリティポリシーの理解

API Gateway のセキュリティポリシーは、最小 TLS バージョンと厳選された暗号スイートのセットの事前定義された組み合わせです。クライアントが REST API またはカスタムドメイン名に接続すると、API Gateway は選択されたポリシーを使用して、TLS ハンドシェイク中に受け入れるプロトコルバージョンと暗号を決定します。これにより、クライアントが API への暗号化接続を確立する方法を予測可能かつ強制可能な方法で制御できます。

API Gateway は 2 つのカテゴリのセキュリティポリシーをサポートしています。TLS_1_0 や TLS_1_2 などのレガシーポリシーは、下位互換性のために引き続き利用可能です。SecurityPolicy_* プレフィックスで識別される強化ポリシーは、規制されたワークロード、高度なガバナンス、または暗号化の強化に対して、より厳格で最新の制御を提供します。強化ポリシーを使用する場合は、エンドポイントアクセスモードも指定する必要があります。これにより、トラフィックが API に到達する方法に対する追加の検証が追加されます。詳細は以下のセクションで説明します。

強化ポリシーは、各ポリシーが何を強制するかを素早く理解するのに役立つ一貫した命名パターンに従っています。たとえば、REGIONAL および PRIVATE エンドポイントタイプの場合、次のパターンが適用されます：

SecurityPolicy_[TLS-Versions]_[Variant]_[YYYY-MM]

この構造から、サポートされる最小 TLS バージョン、特殊な暗号化バリアント（FIPS、PFS、PQ など）、およびポリシーのリリース日を識別できます。たとえば、SecurityPolicy_TLS13_1_3_2025_09 は TLS 1.3 トラフィックのみを受け入れ、SecurityPolicy_TLS13_1_2_PFS_PQ_2025_09 は TLS 1.2 を最低、TLS 1.3 を最高 TLS バージョンとして、前方秘匿性とポスト量子拡張をサポートします。

各ポリシーは、厳選された暗号の組み合わせにマッピングされます。たとえば、SecurityPolicy_TLS13_1_3_2025_09 は、3 つの TLS 1.3 暗号スイート（TLS_AES_128_GCM_SHA256、TLS_AES_256_GCM_SHA384、および TLS_CHACHA20_POLY1305_SHA256）のみを受け入れ、他のプロトコルバージョンや暗号を拒否します。サポートされているポリシーと暗号の完全なリスト、および EDGE エンドポイントタイプの命名パターンについては、API Gateway ドキュメントをご参照ください。

セキュリティポリシーをデフォルトエンドポイントとカスタムドメインに適用する方法

API Gateway を使用して、デフォルト API エンドポイントとカスタムドメイン名に異なるセキュリティポリシーを適用できます。TLS ネゴシエーション中、API Gateway は、HTTP Host ヘッダーではなく、クライアントの TLS ハンドシェイクの Server Name Indication（SNI）値に基づいてポリシーを選択します。つまり、ポリシーは、クライアントが TLS を開始するときに使用するホスト名に依存します。

たとえば、クライアントがデフォルトエンドポイントに直接接続する場合：

https://abcdef1234.execute-api.us-east-1.amazonaws.com

SNI 値がそのホスト名と一致するため、API Gateway はそのデフォルトエンドポイントに適用されたポリシーを使用します。

クライアントが代わりにカスタムドメイン名を介して接続する場合：

https://api.example.com

API Gateway はそのカスタムドメインに適用されたポリシーを使用します。この場合、SNI 値 api.example.com がどのポリシーが強制されるかを決定します。

この区別は、デフォルトエンドポイントを無効にした場合でも重要です。TLS ネゴシエーションは常に API Gateway がエンドポイント設定を評価する前に発生するため、デフォルトエンドポイントセキュリティポリシーは、そのホスト名に直接接続するクライアントに引き続き適用されます。予期しないクライアント動作を避けるために、可能な限り API とそのカスタムドメイン名を同じセキュリティポリシーで整合させる必要があります。

エンドポイントアクセスモードの理解

強化セキュリティポリシー（SecurityPolicy_*）を使用する場合、エンドポイントアクセスモードも指定する必要があります。エンドポイントアクセスモードは、リクエストが API に到達する前に、API Gateway がネットワークパスをどの程度厳密に検証するかを定義します。これにより、追加のガバナンス層が提供され、不正または誤ってルーティングされたトラフィックを防ぐのに役立ちます。

2 つのモードから選択できます：

BASIC モードは、標準的な API Gateway の動作を提供します。既存の API を強化セキュリティポリシーに移行する際の推奨される開始点です。クライアントは、追加の検証なしで、現在と同じように API に到達し続けることができます。
STRICT モードは、リクエストが正しいエンドポイントタイプから発信され、TLS ネゴシエーションが設定と整合していることを確認するための強制チェックを追加します。

STRICT モードを有効にすると、API Gateway は次のような追加の検証を実行します：

SNI と HTTP Host ヘッダー値が一致する
リクエストが API と同じエンドポイントタイプ（リージョナル、エッジ最適化、またはプライベート）から発信される

これらの検証のいずれかが失敗すると、API Gateway はリクエストを拒否します。STRICT は、規制されたワークロードや機密性の高いワークロードを実行する場合など、より強力なセキュリティ保証が必要な場合に適した選択肢です。詳細については、API Gateway ドキュメントをご参照ください。

BASIC から STRICT モードに切り替えると、変更が完全に伝播するまでに最大 15 分かかります。この期間中、API は引き続き利用可能です。エンドポイントアクセスモードが STRICT に設定されている場合、モードを BASIC に戻すまでエンドポイントタイプを変更できません。

新規および既存の API へのセキュリティポリシーの適用

新しい REST API またはカスタムドメイン名を作成するときにセキュリティポリシーを適用することも、既存のリソースを更新して強化された SecurityPolicy_* オプションのいずれかを使用することもできます。既存の API を移行する場合、推奨されるアプローチは、BASIC モードから開始し、クライアントの動作（SNI と HTTP Host ヘッダー値が一致し、リクエストが API と同じエンドポイントタイプから発信される）を検証してから、互換性を確認した後に STRICT モードに移行することです。

以下のコードスニペットは、さまざまなシナリオにセキュリティポリシーを適用する方法を示しています：

セキュリティポリシーと STRICT エンドポイントアクセスモードで REST API を作成する

API 作成時にセキュリティポリシーを直接適用でき、TLS ネゴシエーションを制御するためだけに追加のインフラストラクチャを必要としません。

aws apigateway create-rest-api \
  --name "your-private-api-name" \
  --endpoint-configuration '{"types":["PRIVATE"]}' \
  --security-policy "SecurityPolicy_TLS13_1_3_2025_09" \
  --endpoint-access-mode STRICT \
  --policy file://api-policy.json

セキュリティポリシーと STRICT エンドポイントアクセスモードでカスタムドメイン名を作成する

カスタムドメイン名を作成するときにもセキュリティポリシーを指定できます。API Gateway は、クライアントが提供する SNI 値に基づいて、TLS ネゴシエーション中に選択されたポリシーを適用します。

aws apigateway create-domain-name \
  --domain-name api.example.com \
  --regional-certificate-arn arn:aws:acm:region:account-id:certificate/certificate-id \
  --endpoint-configuration '{"types":["REGIONAL"]}' \
  --security-policy SecurityPolicy_TLS13_1_3_2025_09 \
  --endpoint-access-mode STRICT

既存の REST API の更新

既存の API を移行する場合は、まず BASIC モードで強化セキュリティポリシーを適用します。クライアントが BASIC モードで期待どおりに接続できることを確認した後、STRICT モードを有効にします。

1. BASIC モードで新しいポリシーを適用する

aws apigateway update-rest-api --rest-api-id abcd123 --patch-operations '[
    {
         "op": "replace",
         "path": "/securityPolicy",
         "value": "SecurityPolicy_TLS13_1_3_2025_09"
    },
    {
         "op": "replace",
         "path": "/endpointAccessMode",
         "value": "BASIC"
     }
]'

アクセスログと Amazon CloudWatch のパフォーマンスメトリクスを使用して、クライアントが期待どおりに API を利用できることを確認します。

2. 検証後に STRICT モードを有効にする

aws apigateway update-rest-api --rest-api-id abcd123 --patch-operations '[
    {
        "op": "replace",
        "path": "/endpointAccessMode",
        "value": "STRICT"
     }
]'

既存のカスタムドメイン名の更新

カスタムドメイン名は、REST API と同じ移行アプローチに従います。

1. BASIC モードで新しいポリシーを適用し、クライアントが正常に接続できることを検証します。

aws apigateway update-domain-name --domain-name api.example.com --patch-operations '[
    {
        "op": "replace",
        "path": "/securityPolicy",
        "value": "SecurityPolicy_TLS13_1_3_2025_09"
    },
    {
        "op": "replace",
        "path": "/endpointAccessMode",
        "value": "BASIC"
     }
]'

2. 検証後に STRICT モードを有効にする

aws apigateway update-domain-name --domain-name api.example.com --patch-operations '[
    {
        "op": "replace",
        "path": "/endpointAccessMode",
        "value": "STRICT"
     }
]'

REST API またはカスタムドメイン設定を更新した後、ステージが新しい設定を受け取るように API を再デプロイします。セキュリティポリシーを変更すると、更新が完了するまでに最大 15 分かかります。変更が伝播している間、API ステータスは UPDATING と表示され、完了すると AVAILABLE に戻ります。このプロセス全体を通じて、API は完全に機能し続けます。

エンドポイントアクセスモードのロールバック

STRICT モードを適用した後にクライアントが API への接続に失敗する場合は、いつでもエンドポイントアクセスモードを BASIC に戻すことができます。以下のコードスニペットは、REST API に対してこれを行う方法を示しています。

aws apigateway update-rest-api --rest-api-id abcd123 --patch-operations '[
    {
      "op": "replace",
      "path": "/endpointAccessMode",
      "value": "BASIC"
    }
  ]'

同じアプローチを使用してカスタムドメイン名を更新できます。

TLS 使用状況とポリシー移行の監視

強化セキュリティポリシーを採用する際、クライアントが API との暗号化接続をどのようにネゴシエートするかを理解することが重要です。監視は、クライアントの準備状況を確認し、更新が必要なレガシーコンシューマーを特定し、ロールアウト中に STRICT エンドポイントアクセスモードが期待どおりに動作することを検証するのに役立ちます。プロトコルと暗号の使用状況を経時的に監視するには、次の API Gateway アクセスログ変数を使用します。

$context.tlsVersion – ネゴシエートされた TLS バージョン
$context.cipherSuite – ハンドシェイク中に選択された暗号スイート

これらの変数を使用して、次のことを確認できます：

クライアントが期待される最小 TLS バージョンを使用している
強化ポリシーに移行した後、CBC ベースの暗号が使用されなくなった
PQC および FIPS に準拠したポリシーが適切なクライアントによって使用されている

アクセスログは、移行中に特に有用です。実際のクライアント動作を検証することは、STRICT モードを有効にする前の前提条件です。たとえば、BASIC モードで強化ポリシーを適用した後も、TLS 1.0 または TLS 1.2 CBC 暗号をネゴシエートしているライブクライアントが観察される場合、影響を受けるクライアントを特定し、STRICT モードに切り替える前に修復を計画できます。

将来を見据えたセキュリティ設定

新しいポリシーの一部は、TLS 1.3 とポスト量子暗号（PQC）を組み合わせて、量子対応の脅威アクターが存在する将来に備えるのに役立ちます。これらのポリシーを使用すると、API アーキテクチャを再設計することなく、量子耐性アルゴリズムのテストと採用を開始できます。

標準が進化し、新しい暗号スイートが導入されるにつれて、API Gateway のポリシーモデルは、設定をシンプルで予測可能に保ちながら、新しいバリアントを追加するための明確なパスを提供します。

まとめと次のステップ

Amazon API Gateway の強化された TLS セキュリティポリシーとエンドポイントアクセスモードにより、クライアントが API への安全な接続を確立する方法を直接制御できます。PCI DSS、FIPS、Open Banking、PQC などのコンプライアンスニーズに合ったポリシーを選択し、STRICT モードを使用してトラフィックがエンドポイントに到達する方法を制御し、追加のドメインレベルの検証を適用して、API のセキュリティをさらに強化できます。

開始するには：

API Gateway ドキュメントで利用可能なセキュリティポリシーのリストを確認します。
より強力な TLS 制御が必要な REST API とドメインを特定します。
BASIC モードで適切な SecurityPolicy-* ポリシーを適用します。
アクセスログと CloudWatch メトリクスを使用してクライアントの動作を検証します。
追加の接続レベルの保護を強制する準備ができたら、STRICT モードに移行します。

サーバーレスアーキテクチャの構築に関する詳細については、ServerlessLand.com をご参照ください。

翻訳はソリューションアーキテクトの松本が担当しました。

Amazon Web Services ブログ