Workers AIで他人のデータ混入、原因と対応【2026年10月】
IT Picks編集部
IT Picks
AWS耐量子TLS、Aurora・CloudFrontで拡大【2026年10月】
IT Picks編集部
2026年10月29〜30日（米国時間）、AWS は通信の暗号を「量子コンピューターでも破られにくい方式」に切り替えるための発表を続けて出しました。Amazon Aurora PostgreSQL が耐量子 TLS の鍵交換に対応し、Amazon CloudFront では訪問者が耐量子の暗号で接続したかを確かめられるようになりました。
Amazon CloudFront now provides viewer ISP and post-quantum TLS details
あわせて Amazon MSK（Kafka のマネージドサービス）も TLS 1.3 に対応しています。どれも「すぐに何かが壊れる」話ではありません。将来に備えて、利用者が自分で選べる・確かめられる範囲が広がった——という位置づけの発表です。
この記事はこんな人向けです
- AWS で Web サイトや API、データベース（Aurora など）を運用している
- 「耐量子暗号（ポスト量子暗号）」が自分の環境に関係あるのか、今なにかする必要があるのかを知りたい
- CloudFront や Aurora で、耐量子の暗号が実際に使われているかを確かめる方法を知りたい
目次
AWSの耐量子TLS対応とは？一言でまとめると
一言でいうと、AWS 上の通信の「鍵の受け渡し」を、量子コンピューターに強い方式（ML-KEM）に切り替えられる場所が増えたという発表です。
| 発表日（米国時間） | サービス | 何が変わったか |
|---|---|---|
| 2026年10月29日 | Aurora PostgreSQL | バージョン18以上で、耐量子の鍵交換を設定で選べるように |
| 2026年10月30日 | CloudFront | 訪問者の接続が耐量子だったかをオリジンに伝えるヘッダーを追加 |
| 2026年10月30日 | MSK | TLS 1.3 に対応（耐量子暗号の前提の1つ） |
なお、10月26日には AWS KMS（鍵管理サービス）が ML-KEM の鍵に対応したことも発表されています。AWS 全体で、耐量子暗号への移行を進めている流れの一部です。
そもそも耐量子TLSとは：「今集めて後で解読」への備え
HTTPS などの TLS 通信は、最初に「鍵交換」で暗号の鍵を相手と共有してから、データを暗号化します。AWS によると、いま広く使われている公開鍵暗号は、将来の量子コンピューターなら効率よく解けるおそれのある数学の問題に基づいています。
心配されているのが、「harvest now, decrypt later（今集めて、後で解読する）」という攻撃です。AWS KMS の発表では、次のように説明されています。
- 攻撃者が、いまの暗号化された通信の鍵交換を記録しておく
- 十分に強力な量子コンピューターが登場した時点で、記録から鍵を取り出して解読する
つまり、何年も先まで秘密にしておきたいデータは、量子コンピューターが実用になる前から対策が必要になります。そのための新しい方式が、米国の標準（NIST FIPS 203）になった ML-KEM です。
AWS は ML-KEM を従来の楕円曲線の方式（ECDH）と組み合わせた「ハイブリッド」で導入しています。AWS のドキュメントに出てくる名前は次のとおりです。
| 名前 | 中身 |
|---|---|
| X25519MLKEM768 | 従来の X25519 と ML-KEM-768 の組み合わせ |
| SecP256r1MLKEM768 | 従来の P-256（prime256v1）と ML-KEM-768 の組み合わせ |
| X25519・prime256v1・secp384r1 | 従来の方式（耐量子ではない） |
※ 2026年11月2日時点（AWS「Post-Quantum Cryptography」、CloudFront 開発者ガイド）。
大事なのは、耐量子の鍵交換は TLS 1.3 でしか使えないことです（CloudFront・Aurora のドキュメント）。サーバーとクライアントの両方が対応して、初めて使われます。
① Aurora PostgreSQL：ssl_groupsで耐量子の鍵交換を選べる
10月29日の発表で、Aurora PostgreSQL 互換エディションが耐量子 TLS の鍵交換に対応しました。アプリから DB への通信を、耐量子の方式で暗号化できます。
Amazon Aurora now supports post-quantum TLS key exchange
使うには、DB クラスターのパラメータ ssl_groups（鍵交換に使う方式の一覧）を変更します。ユーザーガイドの内容をまとめます。
| 項目 | 内容（Aurora ユーザーガイドより） |
|---|---|
| 対象 | Aurora PostgreSQL 18 以降 |
| 既定値 | prime256v1:X25519（耐量子の方式は入っていない） |
| 選べる値 | X25519MLKEM768・SecP256r1MLKEM768・X25519・prime256v1・secp384r1 |
| 順番の意味 | 先頭ほど優先。クライアントも対応する最初の方式が使われる |
| 反映 | 再起動不要の動的パラメータ |
| 条件 | ML-KEM の方式は TLS 1.3 が必要 |
ポイントは、既定値のままでは耐量子の鍵交換は使われないことです。使いたい場合は、カスタムの DB クラスターパラメータグループで、たとえば X25519MLKEM768:X25519 のように耐量子の方式を先頭に置いた値にします（値は許可リストの中から選びます）。
確実に耐量子の方式だけを使わせたい場合、ユーザーガイドは ssl_min_protocol_version を TLSv1.3 にするよう案内しています。ほかにも、指定した方式だけを使うには rds.force_ssl を有効にする必要があります（Aurora PostgreSQL 17 以降は既定でオン）。
なお、発表のタイトルは「Amazon Aurora」ですが、本文で対象とされているのは PostgreSQL 互換だけです。MySQL 互換については、今回の発表に記載がありません。
② CloudFront：耐量子で接続した訪問者の割合を測れる
開発者ガイドによると、CloudFront は訪問者との TLS 1.3 の接続で X25519MLKEM768・SecP256r1MLKEM768 の耐量子の鍵交換に対応しています。今回追加されたのは、それが実際に使われたかを確かめる手段です。
オリジン（CloudFront の後ろのサーバー）に転送できるヘッダーが、2つ増えました。
| ヘッダー | 中身 | 使い道（AWS の説明） |
|---|---|---|
| CloudFront-Viewer-TLS-Details | 接続ごとの TLS のバージョン・暗号・鍵交換・署名方式・証明書の鍵の種類 | 耐量子で接続した訪問者の割合を測る、未対応のクライアントを見つける |
| CloudFront-Viewer-ISP | 訪問者のインターネットサービスプロバイダー（ISP）名 | 回線ごとのトラフィック・性能の分析、特定の ISP からの異常な通信の切り分け |
CloudFront-Viewer-TLS-Details の値は JSON です。開発者ガイドの例では、耐量子で接続した場合は次のようになります。
{"tlsVersion":"TLSv1.3","cipherSuite":"TLS_AES_128_GCM_SHA256","handshakeType":"fullHandshake","keyExchange":"X25519MLKEM768","signatureScheme":"ecdsa_secp256r1_sha256","signaturePublicKeyType":"ecdsa_secp256r1"}
見るべきなのは keyExchange です。X25519MLKEM768 などなら耐量子、x25519 や secp256r1 なら従来の方式です。
使い方は、オリジンリクエストポリシーにヘッダーを追加して、ディストリビューションに付けるだけです。注意点もまとめます。
- キャッシュポリシーには追加できない（オリジンリクエストポリシーのみ）
- ヘッダーはオリジンに届くものなので、割合を測るにはオリジン側（Web サーバーやアプリ）でログに記録して集計する
- セッションの再開（sessionResumed）では、使わない項目が
NONEになる。ただし TLS 1.3 の再開ではkeyExchangeは入る - CloudFront-Viewer-ISP は、ISP が分からないときは付かない
③ Amazon MSK：TLS 1.3に対応（耐量子の前提）
Kafka のマネージドサービス Amazon MSK では、MSK Provisioned のクラスターが TLS 1.3 に対応しました。AWS は、TLS 1.3 を「今集めて後で解読する」攻撃から守る耐量子暗号の前提条件の1つと位置づけています。
| 項目 | 内容（AWS の発表より） |
|---|---|
| 使い方 | クラスターの設定で名前付きのセキュリティポリシーを選ぶ（オプトイン） |
| 既存のクラスター | ポリシーを適用するまで変わらない |
| 混在 | TLS 1.2・1.3 両方を許すポリシーなら、対応するクライアントから順に 1.3 で接続 |
| 厳しくする | TLS 1.3 だけに限るポリシーも選べる（条件を満たさない接続は拒否） |
| 料金 | 追加料金なし |
発表文は、まず両方を許すポリシーにしてクライアントを順に更新し、その後で厳しいポリシーに切り替えるという進め方ができる、と説明しています。
料金・提供状況
2026年11月2日時点の AWS の発表・ドキュメントで確認できたことをまとめます。
| サービス | 料金 | 提供リージョン |
|---|---|---|
| Aurora PostgreSQL（ssl_groups） | 発表に記載なし | 発表に記載なし（対象は 18 以降） |
| CloudFront（2つのヘッダー） | 発表に記載なし | —（グローバルのサービス） |
| MSK（TLS 1.3） | 追加料金なし | MSK Provisioned が使えるすべてのリージョン |
| KMS（ML-KEM の鍵） | 発表に記載なし | 中東（UAE・バーレーン）と中国を除く全リージョン |
Aurora の発表には提供リージョンの記載がなく、東京・大阪で Aurora PostgreSQL 18 が使えるかは、この発表からは分かりません。使う前に、マネジメントコンソールで自分のリージョンのエンジンバージョンを確認してください。
いまやること：サービス別のチェック
AWS の「Post-Quantum Cryptography」のページは、共有責任モデルの考え方で、利用者側の役割を次のように整理しています。
- AWS のサービスのエンドポイント（S3・KMS など）：クライアントが対応していれば自動で耐量子の鍵交換を優先する。利用者がやるのはブラウザやクライアントの更新
- 利用者が持つリソース（ロードバランサーなど）：ML-KEM に対応した TLS ポリシーが用意されている。ポリシーの変更は利用者がやる
これに今回の発表を合わせると、運用者のチェックは次のようになります。
① ALB（Application Load Balancer）：ポリシーの名前を確認する
ELB のドキュメントによると、名前に「PQ」が付くセキュリティポリシーが、ハイブリッドの耐量子鍵交換に対応しています。AWS が推奨しているのは ELBSecurityPolicy-TLS13-1-2-Res-PQ-2025-09（または FIPS 版）です。
注意したいのは、作り方によって既定のポリシーが違うことです。
| HTTPS リスナーの作り方 | 既定のポリシー |
|---|---|
| マネジメントコンソール | ELBSecurityPolicy-TLS13-1-2-Res-PQ-2025-09（耐量子に対応） |
| CLI・CloudFormation・CDK など | ELBSecurityPolicy-2016-08（PQ が付かない） |
CLI や CloudFormation・CDK でポリシーを指定せずに作ったリスナーは、耐量子に対応していない可能性があります。鍵交換が実際にどうなっているかは、ALB の接続ログの13番目の項目（鍵交換）で確認できます。
② CloudFront：まずは割合を測る
まずは CloudFront-Viewer-TLS-Details をオリジンに転送してログに残し、keyExchange の内訳を見るのが手軽です。AWS は、まだ耐量子で接続していないクライアントを見つける使い方も挙げています。CloudFront-Viewer-ISP と組み合わせれば、回線ごとの傾向も見られます。
③ Aurora PostgreSQL：18 以降なら ssl_groups を検討
Aurora PostgreSQL 18 以降を使っているなら、ssl_groups に耐量子の方式を加えることを検討できます。再起動は不要ですが、本番の前に検証用のクラスターで、アプリの DB ドライバーが接続できるかを確かめるのが安全です。なお、どの方式で接続したかを DB 側で確かめる方法は、今回確認したユーザーガイドには書かれていません。
④ ブラウザ・クライアントを更新する
どのサービスでも、クライアントが ML-KEM に対応していなければ従来の方式で接続されます。ブラウザ・OS・SDK・DB ドライバーを最新に保つことが、利用者側でできる一番の対策です。
ブラウザの更新は、セキュリティの修正の面でも欠かせません。Chrome の更新方法はこちらでまとめています。
あわせて読みたい
Chrome脆弱性52件を修正、安全なバージョンと更新方法【2026年10月】
注意点：TLS 1.3だけにすると古いクライアントが切れる
耐量子の方式を「確実に」使わせる設定は、古いクライアントを締め出す設定でもあります。
- Aurora：
ssl_min_protocol_versionをTLSv1.3にすると、TLS 1.2 までしか使えないクライアントは接続できなくなる - MSK：TLS 1.3 だけのポリシーでは、条件を満たさない接続は拒否される
- ALB：PQ ポリシーにも TLS 1.3 だけのものがある。AWS は互換性のため、TLS 1.2 も受け付ける Res-PQ のポリシーから始め、クライアントの対応に合わせて段階的に厳しくすることを勧めている
まずは「耐量子を優先しつつ、従来の方式も受け付ける」設定にして、ログで割合を確かめてから絞るのが、各ドキュメントに共通する考え方です。
また、今回の対応は通信（データの移動中）を守るものです。AWS は、KMS などで使われている保存データの暗号化は引き続き量子に耐えると説明しています。
IT Picks的な所感
今回の発表は、「耐量子暗号は AWS が裏で自動でやってくれる部分」と「利用者が自分で設定する部分」の境目がはっきりしたものだと思います。S3 や KMS などの AWS 側のエンドポイントは自動で切り替わる一方、ALB のポリシーや Aurora のパラメータは、利用者が変えない限りそのままです。
特に気をつけたいのは、CLI や CDK で作った ALB の既定のポリシーが今も ELBSecurityPolicy-2016-08 である点です。コンソールで作った環境とコードで作った環境で、暗号の設定が違っている——ということは十分ありえます。この機会に一度、自分のリスナーのポリシー名を一覧で確認する価値はあると考えています。
一方で、Aurora の対応は PostgreSQL 18 以降に限られ、既定値も従来のままです。量子コンピューターの脅威は「今日明日」の話ではないため、長く秘密にしたいデータを扱うシステムから、検証しながら順に進めるのが現実的でしょう。
TLS の証明書まわりでは、10月に eMudhra の証明書の鍵が漏えいした件もありました。暗号の設定は「一度作ったら終わり」ではない、という点で共通しています。
あわせて読みたい
eMudhra証明書の鍵漏えい、サーバー側で必要な対応【2026年10月】
AWS の運用で見落としやすい設定としては、サブドメイン乗っ取りの対策もあわせて確認しておくと安心です。
あわせて読みたい
サブドメイン乗っ取りとは？AWSで起きる原因と対策【2026年版】
まとめ
AWS の10月末の耐量子 TLS 関連の発表のポイントをまとめます。
- 発表日：2026年10月29日（Aurora）・10月30日（CloudFront・MSK）（米国時間）
- 耐量子 TLS とは：鍵交換に ML-KEM を使い、「今集めて後で解読する」攻撃に備える方式（TLS 1.3 のみ）
- AWS の方式の名前：X25519MLKEM768・SecP256r1MLKEM768（従来方式とのハイブリッド）
- Aurora：PostgreSQL 18 以降で ssl_groups を変更して選べる（既定値は従来方式、再起動不要）
- CloudFront：CloudFront-Viewer-TLS-Details ヘッダーで接続ごとの鍵交換が分かる（オリジンリクエストポリシーで転送）
- MSK：MSK Provisioned が TLS 1.3 に対応（追加料金なし、オプトイン）
- ALB：名前に PQ が付くポリシーが対応。CLI・CDK などの既定は ELBSecurityPolicy-2016-08
- 注意点：TLS 1.3 だけに絞ると古いクライアントは接続できない
AWS でサイトや DB を運用しているなら、まずは ALB のセキュリティポリシーの名前と、CloudFront の keyExchange の内訳を確かめるところから始めるのがおすすめです。
ABOUT ME
IT Picks 編集部。VPS・クラウド・AIツール・SaaSを中心に、実際に検証した情報を届けるITメディアです。「本当に使えるか」を基準に、初心者からエンジニアまで役立つ記事を制作しています。
