AWSのPQC対応について

Transcript

1. AWSのPQC対応について Post-Quantum Cryptography （耐量子計算機暗号）
2. 次世代の暗号技術 量子コンピュータによる解読を防ぐために設計された新 しい暗号技術です。量子コンピュータでも解くことが困難 な数学的問題に基づいています。 標準化の動向 • NIST（米国標準技術研究所） が2024年に標準化 を完了。 • 主なアルゴリズム： ◦ ML-KEM（旧Kyber）：鍵カプセル化メカニズム ◦ ML-DSA（旧Dilithium）：デジタル署名 PQC（耐量子計算機暗号）とは
3. "Harvest Now, Decrypt Later" 攻撃 現在の暗号（RSA、ECDHE等）は将来の量子コンピュータで解読可 能です。 • 現在： 攻撃者は暗号化された通信データを収集・保存しま す。 • 将来： 実用化された量子コンピュータを使って、保存データを 解読します。 • 結論： 機密性の高いデータは、今すぐ長期的な保護が必要 です。 なぜ今対応が必要なのか
4. 鍵交換 (ECDHE) クライアントとサーバーが暗号 鍵を安全に共有。第三者に傍 受されても鍵が漏れない。 認証 (RSA) デジタル証明書により通信相 手（サーバー）が本物かを確 認。中間者攻撃を防ぐ。 共通鍵暗号 (AES) 実際のデータの暗号化。128 ビット鍵のAES、GCMモードで 認証付き暗号化。 ハッシュ (SHA256) データの改ざん検知とメッセー ジ認証。データの完全性を保 証。 TLS暗号スイートの構成要素 例：ECDHE-RSA-AES128-GCM-SHA256
5. Client Hello クライアントが対応する暗号スイートの リストを送信 選択基準 両者が対応する中で最も強力なものを 優先。サーバー側のポリシー順位に従 う。 Server Hello 選択された暗号スイートをサーバーが 回答 暗号スイートの決定プロセス
6. 転送中のデータ 保護 最優先・展開中 HNDL脅威に直接対抗 するため、鍵交換に PQCを適用。 棚卸しと計画 継続的 暗号使用箇所の把握と リスク評価。 デジタル署名 優先度高・実装段階 長期的な真正性担保 （ML-DSA等）。 セッション認証 中優先度・将来 短期的な認証における 対応。 PQCの適用箇所と優先度
7. ハイブリッド暗号方式 従来のアルゴリズム（ECDHE）とPQCアルゴリズム （ML-KEM等）を併用します。 どちらか一方が破られても安全性を維持できる堅牢な設計です。 責任共有モデル • AWSの責任： クラウドの基盤部分（インフラ、ロードバランサー 等）のPQC対応。 • 顧客の責任： アプリケーションコードやOS内部、データ自体の PQC対応。 AWSのPQC対応方針
8. アプリケーションの通信 データ保護 サーバーとしての通信 対象： ユーザー → インターネットゲートウェイ → ALB → ECS と いうインバウンド通信フロー。 今回は、このサーバー側（ALB）でのPQC対応に焦点を当てま す。 図は一般的なVPC構成を示しており、ALBがTLSの終端点と なります。
9. デフォルトで有効 CloudFrontはすでにPQC対応が完了 しています。 追加の設定変更は不要です。 クライアントがPQCに対応していれば、自動的にPQCネゴシ エーションが使用されます。 CloudFrontの対応
10. PQC対応ポリシー AWSが提供する新しいポリシーを適用するだけで対応完 了です。 TLS 1.2, 1.3 に加え、PQC暗号スイートが含まれていま す。 後方互換性あり 既存の環境への影響を最小限に抑えられます。 • 既存のポリシーにPQC暗号スイートが追加される 形です。 • PQC非対応のクライアントは、従来通りの暗号ス イートで通信可能です。 ALBの対応：セキュリティポリシー
11. トラフィックが少ない時間帯に更新する ロードバランサーが高負荷の状態でセキュリティポリシーを更新すると、一時的な通信断が発生するリスクがあ ります（AWS公式ドキュメントより）。 複数リスナー間の整合性 同一ALBに複数のHTTPSリスナー（例：443番と8443番）がある場合、それらのセキュリティポリシーには互換性 が求められます。従来のポリシーとPQCポリシーは互換性がない場合があるため注意が必要です。 ALB更新時に気を付けること