なぜ今ポスト量子暗号への移行を始めるのか
量子コンピューティングの進展は、RSA や楕円曲線暗号といった現行の公開鍵暗号にとって将来的な脅威となります。これらのアルゴリズムは大規模な量子コンピュータによって解読されうると考えられており、長期的にデータを保護するには耐量子（ポスト量子）暗号への移行が欠かせません。攻撃者が暗号化された通信を今のうちに収集し、将来の量子コンピュータで復号する可能性も指摘されており、長期保存が前提のデータほど早期の対策が重要になります。
ウェブトラフィックにおいて、PQC の鍵交換アルゴリズムは TLS 1.3 の中でのみネゴシエートされます。つまり耐量子の接続を成立させるには、エンドポイントが TLS 1.3 と PQC 鍵交換の両方をサポートしている必要があります。米国 NIST はポスト量子暗号の標準化を進めており、業界全体で TLS への組み込みが広がりつつあります。とはいえ、大規模な環境で「どのエンドポイントがどこまで対応しているか」を手作業で把握するのは困難です。移行はまず現状を可視化することから始めるのが現実的です。
本記事では、AWS が公開するサンプルソリューション「PQC Readiness Scanner」を用いて、TLS エンドポイントの PQC 対応状況を AWS Config で継続的に評価する方法を解説します。
PQC Readiness Scanner の仕組み
PQC Readiness Scanner は AWS Config のコンフォーマンスパックとして構築され、TLS エンドポイントのセキュリティポリシーを継続的に評価します。各リソースに対して、大きく2種類のチェックを実施します。1つはエンドポイントが PQC 対応のセキュリティポリシーを使用しているか、もう1つはレガシーな TLS 1.0 または 1.1 をサポートしていないか、という観点です。
技術スタックはシンプルです。継続的な監視と評価には AWS Config を、セキュリティポリシーの評価ロジックには Python 3.12 ランタイムの AWS Lambda を使用します。Lambda 関数のデプロイには AWS SAM を、複数アカウントへの展開には CloudFormation StackSets を利用します。実装としては、2つの Lambda 関数が4つのカスタム AWS Config ルールを駆動する構成です。
ソリューションは GitHub の aws-samples/sample-PQC-Readiness-using-AWS-Config リポジトリで公開されており、conformance-packs・installation・lambda-functions などのディレクトリで構成されています。評価に用いる IAM ロールは describe 系オペレーションに限定した最小権限で設計されており、監視のために過剰な権限を付与しない点も実運用で安心できる配慮です。
ALB・NLB・Amazon API Gateway の TLS エンドポイントを監視する
Scanner が評価対象とするのは、インターネットに面しやすい代表的なエッジサービスです。Application Load Balancer (ALB) と Network Load Balancer (NLB) については、HTTPS・TLS・TCP(SSL) プロトコルを使用するリスナーが対象になります。Amazon API Gateway は、REST API のリージョンエンドポイントおよびプライベートエンドポイントに加え、HTTP API と WebSocket API も評価されます。
一方で、対象外となるサービスもあります。Amazon CloudFront は既存の TLS セキュリティポリシー全体でハイブリッドなポスト量子鍵交換を伴う TLS 1.3 が自動的に有効化されているため、評価対象から除外されています。Classic Load Balancer は TLS 1.3 や PQC 鍵交換をサポートしておらず、PQC 対応にすること自体ができないため対象外です。これらの前提を理解しておくと、評価結果の解釈がぶれません。
Scanner を正しく動作させるには、AWS Config で次のリソースタイプを記録しておく必要があります。具体的には AWS::ElasticLoadBalancingV2::LoadBalancer、AWS::ApiGateway::RestApi、AWS::ApiGatewayV2::Api の3つです。Config の記録設定が漏れていると評価が行われないため、導入前に必ず確認しておきましょう。
コンフォーマンスパックと3階層フレームワークで優先順位を付ける
コンフォーマンスパックとは、AWS Config ルールと修復アクションをひとまとめにしたものです。アカウントとリージョン単位の単一エンティティとして、あるいは AWS Organizations の組織全体に対してデプロイできます。Scanner では ELB と API Gateway それぞれについて、PQC 対応を確認するルールとレガシー TLS を検出するルールの計4ルールが動作します。非準拠と判定されたリソースにはフラグが付き、推奨されるアップグレードポリシーが提示されます。
評価結果は3階層のフレームワークで整理されます。ティア1はPQC 鍵交換を伴う TLS 1.3 のみを許可する状態で、すでに目標に到達しており移行は不要です。ティア2はPQC 鍵交換に加えて TLS 1.2 と 1.3 を許可する状態で、TLS 1.3 接続では耐量子保護を提供しつつレガシークライアント向けに 1.2 の互換性を維持しており、移行優先度は低めです。ティア3はPQC 鍵交換がない、または TLS 1.3 に未対応の状態で、転送中データに耐量子保護がなく移行優先度は高いと位置づけられます。
ティア3に該当するリソースは、名前に「PQ」を含むポリシー（例として末尾が -PQ-2025-09 のようなもの）へのアップグレードが推奨されます。ただしポリシーを変更する前に、接続してくるクライアントの TLS バージョンを監査することが欠かせません。古いクライアントが残っていると、性急な変更が通信断を招くおそれがあるためです。
シングルアカウントと AWS Organizations へのデプロイ
導入の共通前提として、適切な権限を持つ AWS CLI、Python 3.12、AWS SAM CLI、そして対象リソースタイプを記録するよう設定された AWS Config が必要です。シングルアカウントの場合は、リポジトリをクローンしたうえで installation ディレクトリで sam build を実行し、deploy-per-regions.sh にデプロイ先リージョンを渡して実行します。Lambda 関数のデプロイ、コンフォーマンスパックによる Config ルールの作成、デプロイ検証までが一連で自動的に進みます。
AWS Organizations を使うマルチアカウント展開では、Config の CUSTOM_LAMBDA ルールが「Lambda 関数を Config ルールと同じアカウント内に置く」ことを要求する点に注意が必要です。そのため、まず共有 S3 バケットを用意し、管理アカウントとターゲットアカウントに s3:GetObject と s3:ListBucket を許可するバケットポリシーを設定します。次に deploy-stacksets.sh で Lambda をパッケージ化して S3 にアップロードし、StackSets を SERVICE_MANAGED かつ自動デプロイ有効で作成して各メンバーアカウントへ Lambda を配布します。最後に組織コンフォーマンスパックを配布すれば、組織全体での評価が始まります。
このとき StackSet のホームリージョンを示す引数と、デプロイ先のターゲットリージョンを示す引数は別物であり、意図しない展開を避けるために明示的な指定が求められます。また SERVICE_MANAGED の StackSets は管理アカウント自体を展開対象から除外するため、管理アカウントには別途シングルアカウント向けのスクリプトを実行する必要があります。
結果の確認と今後のアクションステップ
デプロイ後は AWS Config コンソールのコンフォーマンスパックから結果を確認できます。pqc- プレフィックスを持つ4つのルールごとに、準拠・非準拠のリソース、注釈、ARN、ポリシー設定を参照できるため、現状把握がひと目で進みます。
確認後のアクションは優先度に沿って進めます。高優先のティア3では、PQ 系ポリシーへのアップグレードを行い、その前提としてクライアントの TLS バージョンを監査します。あわせて接続ログを監視し、鍵交換のネゴシエーション失敗を早期に検出すると安全に移行できます。低優先のティア2では、クライアント互換性を分析したうえで TLS 1.3 のみのポリシーへ移行できるかを検討します。複数アカウントにまたがる環境では、AWS Config アグリゲーターを活用してアカウント横断で進捗を追跡すると、移行全体の見通しが立てやすくなります。
ポスト量子暗号への移行は一度で終わる作業ではなく、可視化・優先順位付け・段階的な置き換えを継続するプロセスです。PQC Readiness Scanner のような仕組みで現状を継続的に評価し、ティア3から着実に解消していくことが、来たる量子時代に向けた堅実な第一歩になります。
