[アップデート] Amazon API Gateway の REST API にポスト量子暗号を含む TLS セキュリティポリシーが2つ追加されました

特定のコンプライアンス対応が必要な時に役に立つ
2026.09.23
いわさです。
API Gateway の REST API とカスタムドメイン名では、TLS のバージョンと暗号スイートの組み合わせを「セキュリティポリシー」として選択できます。

2025 年 11 月には拡張 TLS ポリシーが追加されており TLS 1.3 のみ、Perfect Forward Secrecy、FIPS、ポスト量子暗号などが選べるようになっています。
https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-api-gateway-tls-security-rest-apis/
先日のアップデートで、この拡張ポリシー群に新しく 2 つのポリシーが追加されました。

What's New でのアナウンスはまだですが、API や CLI では通知されています。
https://github.com/aws/aws-cli/commit/941e56792156b8f79cb08fd9d0d45f3f96a8668e
SecurityPolicy_TLS13_1_2_Ext2_PQ_2025_09 と、それに FIPS を足した SecurityPolicy_TLS13_1_2_Ext2_FIPS_PQ_2025_09 です。

どちらも TLS 1.3 と TLS 1.2 に対応しつつ、ポスト量子暗号のハイブリッド鍵交換が使えるようです.
今回こちらを確認してみたので紹介します。
 実際に確認してみるでは REST API を作って、新しいポリシーに切り替えてみましょう。
東京リージョンで Regional の REST API を作り、Mock 統合の GET メソッドを用意しました。

作成直後のセキュリティポリシーはデフォルトの TLS_1_0 で、エンドポイントアクセスモードはまだ設定されていません。
まずコンソールのセキュリティポリシー選択を開いてみます。
PQ や FIPS PQ は並んでいますが、今回の Ext2 系はドロップダウンに出てきませんでした。

まだマネジメントコンソール側の反映がまだみたいです。

また、公式ドキュメントのサポートポリシー一覧にもまだ反映されていないことに気が付きました。[1]。すぐ反映されるとは思うのですが。
というわけで今回の記事では AWS CLI で検証をしてみます。

作成した REST API のセキュリティポリシーだけ AWS CLI で変更します。

次のようにSecurityPolicy_TLS13_1_2_Ext2_PQ_2025_09 と BASIC を指定しました。
$ aws apigateway update-rest-api --rest-api-id xxxxxxxxxx --patch-operations '[
    {"op":"replace","path":"/securityPolicy","value":"SecurityPolicy_TLS13_1_2_Ext2_PQ_2025_09"},
    {"op":"replace","path":"/endpointAccessMode","value":"BASIC"}
  ]'
拡張ポリシーには、レガシーポリシーに無い「エンドポイントアクセスモード」という設定（BASIC か STRICT のどちらか）が必要です。
STRICT にすると、同じエンドポイントタイプ由来のリクエストであること、そして リージョナル/プライベートなら SNI のホスト名一致、エッジ最適化なら CloudFront のドメインフロンティング防止に従うこと、などの条件を満たさないとAPI Gateway がリクエストを拒否します。
https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-security-policies.html#apigateway-security-policies-endpoint-access-mode
今回はガバナンス周りの検証はしないでの BASICでいきます。

ドキュメントでは反映に約15分かかると案内されていますが、今回は数分で AVAILABLE になりました。
$ aws apigateway get-rest-api --rest-api-id xxxxxxxxxx \
    --query '{sp:securityPolicy,eam:endpointAccessMode,st:apiStatus}'
{
    "sp": "SecurityPolicy_TLS13_1_2_Ext2_PQ_2025_09",
    "eam": "BASIC",
    "st": "AVAILABLE"
}
CLI で設定したあとにコンソールの API 設定画面を見ると、選択肢には出てこなかった SecurityPolicy_TLS13_1_2_Ext2_PQ_2025_09 がちゃんと表示されていました。
 ポスト量子の鍵交換がネゴシエートされるか確認してみるPQ を含むポリシーは、TLS のハイブリッド鍵交換にポスト量子アルゴリズムを使います[2]。

将来の量子コンピューターに対して通信の機密性を守る目的で、従来の楕円曲線とポスト量子アルゴリズムを組み合わせた鍵交換グループ（X25519MLKEM768 など）を使います。
実際にネゴシエートされるか、openssl で確認してみましょう。
$ echo | openssl s_client -connect xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com:443 \
    -servername xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com \
    -tls1_3 -groups X25519MLKEM768 2>/dev/null | grep "Negotiated TLS1.3 group"
Negotiated TLS1.3 group: X25519MLKEM768
X25519MLKEM768 でネゴシエートできてますね。おそらくポスト量子のハイブリッド鍵交換が成立していると言っていいはず...。
 レガシークライアントでの後方互換性も確認してみるアナウンスでは、これらのポリシーは後方互換のためにレガシーなアルゴリズムを残しているとも書かれていました。

ポスト量子対応クライアントには新しい鍵交換を、そうでないクライアントには従来の鍵交換を、という使い分けをしてくれるっぽいです。試してみましょうか。
ポスト量子に対応していない古いクライアントでも接続できるかも見ておきます。X25519 だけを提示して接続すると、こちらも TLS 1.3 でつながりました。
$ echo | openssl s_client -connect xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com:443 \
    -servername xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com \
    -tls1_3 -groups X25519 2>/dev/null | grep "Protocol"
Protocol: TLSv1.3
なおExt2 のポリシーは TLS 1.3 だけでなく TLS 1.2 も使えます。

-tls1_2 で接続すると TLS 1.2 でネゴシエートできました。
$ echo | openssl s_client -connect xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com:443 \
    -servername xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com \
    -tls1_2 2>/dev/null | grep -E "Protocol|Cipher\s*:"
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
 FIPS 版との違いを見てみるもうひとつのポリシーも見てみます。

先ほどのポリシーに FIPS を足した SecurityPolicy_TLS13_1_2_Ext2_FIPS_PQ_2025_09 を設定した REST API も用意しました。

こちらも選択肢には出てこないので CLI で設定しています。設定後の API 設定画面ではポリシー名が表示されます。
FIPS は、機微な情報を扱う暗号モジュールのセキュリティ要件を定めた米国・カナダ政府の標準です（現行は FIPS 140-3）[3]。

名前に FIPS が付くポリシーは、AWS-LC の FIPS 検証済み暗号モジュールを使います。

海外向けの規制対応で FIPS 検証済み暗号の利用を求められることがありまして、そういった時に採用します。

日本国内でもグローバル対応する時とかに現地コンプライアンスの関係で必要になったりするので、我々も無視できない仕様です。
ポスト量子の鍵交換は FIPS 版でも同じく X25519MLKEM768 でネゴシエートできます。
# 非 FIPS 版: ChaCha20 を提示
$ echo | openssl s_client -connect <non-fips>.execute-api.ap-northeast-1.amazonaws.com:443 \
    -servername <non-fips>.execute-api.ap-northeast-1.amazonaws.com \
    -tls1_3 -ciphersuites TLS_CHACHA20_POLY1305_SHA256 2>&1 | grep "Cipher is"
New, TLSv1.3, Cipher is TLS_CHACHA20_POLY1305_SHA256

# FIPS 版: ChaCha20 を提示
$ echo | openssl s_client -connect <fips>.execute-api.ap-northeast-1.amazonaws.com:443 \
    -servername <fips>.execute-api.ap-northeast-1.amazonaws.com \
    -tls1_3 -ciphersuites TLS_CHACHA20_POLY1305_SHA256 2>&1 | grep "Cipher is"
New, (NONE), Cipher is (NONE)
FIPS 版は AES-GCM のみを受け入れ、ChaCha20 は対象外のようでした。

AES256-GCM を提示すれば FIPS 版でも接続できます。
AWS 公式ドキュメントの FIPS 対応ポリシーの暗号スイート一覧にも ChaCha20 は含まれていないので仕様どおりですね。[4]
FIPS 要件のあるワークロードでどの暗号スイートが通るかは、事前に確認しておくとよさそうです。
 さいごに本日は API Gateway の REST API とカスタムドメイン名に、ポスト量子暗号を含む TLS セキュリティポリシーが2つ追加されたので確認してみました。
レガシーポリシーではネゴシエートされなかった X25519MLKEM768 が、新しい Ext2_PQ ポリシーに変えるとネゴシエートされるところまで確認できました。

既存の REST API のポリシーを差し替えるだけで、ポスト量子の鍵交換が使えるようになります。

拡張ポリシーはエンドポイントアクセスモードとセットなのでそちらの仕様を忘れないようにしましょう。

脚注
Supported security policies ↩︎
Supported security policies ↩︎
Federal Information Processing Standard (FIPS) 140-3 ↩︎
Supported security policies ↩︎