AWS Config を使用したポスト量子暗号 (PQC) 対応の自動化

本ブログは 2026 年 5 月 14 日に公開された AWS Blog “Automating post-quantum cryptography readiness using AWS Config” を翻訳したものです。

TLS エンドポイントをポスト量子暗号 (PQC) に移行する際は、まず現在の TLS エンドポイントのインベントリと状態を把握することから始めます。本記事では、PQC Readiness Scanner を紹介します。これは Application Load Balancer (ALB)、Network Load Balancer (NLB)、Amazon API Gateway のエンドポイントをインベントリ化し、PQC 対応の観点から TLS 設定を継続的に監視する自動化ツールです。スキャナーは各エンドポイントを 3 階層フレームワークに分類し、PQC 移行の優先順位付けと計画立案を支援します。

量子コンピューティングの進展に伴い、データを長期的に保護するには耐量子暗号への移行が必要になります。PQC Readiness Scanner を使用すると、どのエンドポイントから移行すべきかを特定し、アカウント全体での進捗を追跡できます。ウェブトラフィックでは、PQC 鍵交換アルゴリズムは TLS 1.3 内でのみネゴシエートされます。つまり、耐量子接続を実現するには、TLS 1.3 と PQC 鍵交換をサポートするエンドポイントが必要です。

AWS 責任共有モデルのもとで、AWS はインフラストラクチャを保護し、各サービス全体で PQC サポートを実現します。一方、お客様は PQC 対応の TLS ポリシーを使用するようにリソースを設定する責任を担います。Application Load Balancer (ALB)、Network Load Balancer (NLB)、Amazon API Gateway、Amazon CloudFront など、AWS が TLS 接続を終端するケースでは、お客様がセキュリティポリシー (リスナーがサポートする TLS プロトコルバージョンと暗号スイートを定義する AWS マネージドの設定) を選択します。このポリシーによって、TLS バージョンと暗号スイート、鍵交換、認証アルゴリズムのサポート範囲が決まります。

AWS が TLS を終端するエンドポイント向けに自動化された PQC Readiness Scanner は、AWS Config コンフォーマンスパックを使用して構築されています。コンフォーマンスパックとは、AWS Config ルールと修復アクションをまとめたもので、アカウントとリージョン内の単一エンティティとして、または AWS Organizations の組織全体にデプロイできます。

ソリューションの概要

PQC Readiness Scanner は、コンフォーマンスパックを使用して AWS Config ルールをデプロイし、各エンドポイントのセキュリティポリシーを評価します。評価結果に基づいて、各リソースは 3 階層フレームワークに分類され、PQC 対応の TLS を実現するために必要な移行アクションの優先順位が付けられます。

PQC Readiness Scanner は、リソースごとに次の 2 つのチェックを実行します。

エンドポイントが PQC 対応のセキュリティポリシーを使用しているか
エンドポイントがレガシーの TLS 1.0 または 1.1 をサポートしているか

各チェックは COMPLIANT または NON_COMPLIANT のステータスを、具体的なポリシー推奨事項とともに返します。

PQC では、エンドポイントが TLS 1.3 をサポートし、PQC 鍵交換アルゴリズムを使用する必要があります。3 階層フレームワークは、検出結果の解釈と修正の優先順位付けに役立ちます。目標は、エンドポイントで PQC 鍵交換を有効にした TLS 1.3 を使用することです。ただし、これを実現するにはクライアントとの下位互換性を維持する必要があります。

ティア	対応レベル	TLS プロトコル	PQC ステータス	移行優先度
ティア 1	PQC 対応 (最も強固な状態)	PQC 鍵交換を使用する TLS 1.3 のみ	PQC 対応	なし
ティア 2	PQC 対応 (下位互換性あり)	PQC 鍵交換を使用する TLS 1.2 および 1.3	PQC 対応	低
ティア 3	PQC 非対応	PQC 鍵交換なし	PQC 非対応	高

移行の優先順位付け方法

ティア 1 は、PQC 鍵交換を使用する TLS 1.3 のみを使用する、最も強固なセキュリティを表します。これらのリソースは既に目標状態を満たしています。
ティア 2 は、下位互換性のある PQC 対応の構成を表します。エンドポイントは TLS 1.2 と TLS 1.3 の両方をサポートし、PQC 鍵交換は TLS 1.3 接続でネゴシエートされます。これらのリソースは、TLS 1.3 をサポートするクライアントに対して既に耐量子保護を提供しつつ、レガシークライアント向けに TLS 1.2 互換性を維持しているため、移行優先度は低くなります。クライアント側の分析によって、接続するクライアントが PQC 鍵交換を使用する TLS 1.3 をサポートしていることが確認できたら、ティア 1 に移行してください。
ティア 3 は、PQC 非対応のリソースを対象とします。これには、TLS 1.3 をサポートしていないエンドポイントや、TLS 1.3 はサポートしているが PQC 鍵交換ポリシーを持たないエンドポイントが含まれます。これらのリソースには早急な対応が必要です。

評価範囲

このスキャナーは、お客様のアプリケーションに代わって TLS 接続を終端する、次の AWS エッジサービスを評価します。

エッジサービス:
- HTTPS、TLS、TCP SSL プロトコルを使用する Application Load Balancer (ALB)、Network Load Balancer (NLB) のリスナーが評価対象です。
- API Gateway REST API は AWS リージョンエンドポイントとプライベートエンドポイントが評価され、あわせて API Gateway HTTP API (v2) と WebSocket API (v2) も評価されます。
評価対象外のエッジサービス:
- CloudFront ディストリビューションは PQC 対応の評価範囲から除外されます。これは、ビューワーからエッジへの接続について、既存の CloudFront TLS セキュリティポリシー全体でハイブリッドポスト量子鍵交換を使用する TLS 1.3 が自動的に有効になっているためです。CloudFront のインバウンド (ビューワー向け) PQC については、お客様による対応は不要です。
Classic Load Balancer の推奨アプローチ:
- Classic Load Balancer については、AWS は ALB または NLB への移行を推奨します。Classic Load Balancer は TLS 1.3 または PQC 鍵交換をサポートしておらず、PQC 対応にすることはできません。

ソリューションの仕組み

AWS Config によって、継続的な監視と評価が可能になります。コンフォーマンスパックを使用すると、組織全体へのデプロイが可能になります。AWS Lambda は、AWS Config ルールに基づいてセキュリティポリシー評価を行うコードを実行するサーバーレスコンピューティングサービスです。AWS サーバーレスアプリケーションモデル (AWS SAM) は、AWS Lambda 関数のデプロイに使用するオープンソースフレームワークです。

図 1: PQC 対応ソリューションのアーキテクチャ

PQC Readiness Scanner コンフォーマンスパックは、2 つの Lambda 関数によって動作する 4 つのカスタム AWS Config ルールを実装します。

ルール	チェック内容	非準拠の結果
ELB PQ-ready	ロードバランサーのリスナーが、PQC 鍵交換アルゴリズムを使用する TLS 1.3 をサポートするセキュリティポリシーを使用しているか	ポリシーに PQC サポートが含まれていない場合、リソースは推奨アップグレードポリシーとともにマークされます
ELB legacy TLS	ロードバランサーのリスナーが TLS 1.0 または 1.1 接続を許可しているか	レガシープロトコルが設定されている場合、リソースにフラグが付けられます。
API Gateway PQ-ready	API Gateway エンドポイントが、PQC 鍵交換アルゴリズムを使用する TLS 1.3 をサポートするセキュリティポリシーを使用しているか	ポリシーに PQC サポートが含まれていない場合、リソースは推奨アップグレードポリシーとともにマークされます
API Gateway legacy TLS	API Gateway エンドポイントが TLS 1.0 または 1.1 を許可しているか	レガシープロトコルが設定されている場合、リソースにフラグが付けられます。

前提条件

このソリューションをデプロイする前に、次のものが必要です。

適切なアクセス許可を設定した AWS コマンドラインインターフェイス (AWS CLI)
aws configure aws sts get-caller-identity # Verify
Python 3.12 がインストールされていること。Lambda ランタイムにはこのバージョンが必要です
python3 --version # Should show 3.12.x
AWS SAM CLI がインストールされていること (インストールガイド)
pip install aws-sam-cli # Verify sam --version
対象の AWS リージョンで AWS Config が有効になっていること
- 次のリソースタイプを記録するように設定する (アカウントがデフォルトですべてのリソースを記録している場合、このステップは不要です)
  - AWS::ElasticLoadBalancingV2::LoadBalancer
  - AWS::ApiGateway::RestApi
  - AWS::ApiGatewayV2::Api
- AWS Config コンソール → Recorder → Recording Strategy → Select specific resource types から有効にします (特定のリソースタイプ向けの AWS Config 記録戦略については、手動セットアップの手順に従ってください)

PQC Readiness Scanner のデプロイ手順

PQC Readiness Config Scanner は 3 つのフェーズに分けてデプロイします。完全なデプロイコマンドと設定の詳細は GitHub リポジトリで確認できます。コンフォーマンスパックは Lambda 関数の ARN をパラメータとして参照するため、Lambda 関数を最初にデプロイする必要があります。詳細は GitHub リポジトリを参照してください。

シングルアカウントへのデプロイ

クローンとビルド:

git clone https://github.com/aws-samples/sample-PQC-Readiness-using-AWS-Config.git

cd sample-PQC-Readiness-using-AWS-Config/installation

sam build

1 つ以上のリージョンへのデプロイ:
# Make script executable (first time only) chmod +x deploy-per-regions.sh # Deploy to a single region ./deploy-per-regions.sh us-east-1 # Deploy to multiple regions ./deploy-per-regions.sh us-east-1 us-west-2 eu-west-1
図 2: これらのリソースに対して AWS Config 記録を有効にしているか、デフォルトですべてのリソースを記録している場合は、y を入力して続行します
このスクリプトは、次の処理を自動的に行います
- SAM を介して Lambda 関数をデプロイ
- コンフォーマンスパックをデプロイ (Config ルールを作成)
- デプロイの成功を検証
- 明確なステータスメッセージを提供

このデプロイにより、PQC 対応およびレガシー TLS のチェックを実行する 2 つの Lambda 関数が作成されます。ELB、ALB、NLB、API Gateway の describe オペレーション用に、最小権限のアクセス許可を持つ IAM ロールがプロビジョニングされます。Lambda アクセス許可により、AWS Config が関数を呼び出せるようになります。

図 3: デプロイ成功時の画面の例

マルチアカウントデプロイ (Organizations)

複数の AWS アカウントにまたがる組織全体のデプロイには、CloudFormation StackSets を使用して各アカウントに Lambda 関数をデプロイします。

重要な制約: AWS Config の CUSTOM_LAMBDA ルールでは、Lambda 関数が Config ルールと同じアカウント内に存在する必要があります。1 つのアカウント内に集約した Lambda を使用して、他のアカウントのリソースを評価することはできません。

前提条件: 共有 S3 バケット

パッケージ化の前に、組織内の各ターゲットアカウントからアクセスできる S3 バケットを作成します。このバケットには、CloudFormation StackSets が各メンバーアカウントに取り込む Lambda デプロイアーティファクトをホストします。

# Create the shared S3 bucket (run from management/central account)
aws s3 mb s3://<your-org-shared-bucket> --region us-east-1

次のいずれかのオプションを使用して、ターゲットアカウントに読み取りアクセス権を付与します。

aws s3api put-bucket-policy \
  --bucket <your-org-shared-bucket> \
  --policy '{
    "Statement": [
      {
        "Sid": "BucketOwnerFullAccess",
        "Effect": "Allow",
        "Principal": {
          "AWS": "arn:aws:iam::<bucket-owner-account-id>:root"
        },
        "Action": "s3:*",
        "Resource": [
          "arn:aws:s3:::<your-org-shared-bucket>",
          "arn:aws:s3:::<your-org-shared-bucket>/*"
        ]
      },
      {
        "Sid": "CrossAccountReadAccess",
        "Effect": "Allow",
        "Principal": {
          "AWS": [
            "arn:aws:iam::<account-id-1>:root",
            "arn:aws:iam::<account-id-2>:root"
          ]
        },
        "Action": ["s3:GetObject", "s3:ListBucket"],
        "Resource": [
          "arn:aws:s3:::<your-org-shared-bucket>",
          "arn:aws:s3:::<your-org-shared-bucket>/*"
        ]
      }
    ]
  }'

<account IDs> は、StackSets が Lambda 関数をデプロイする AWS アカウント ID に置き換えてください。

注: バケットは StackSet のデプロイリージョンと同じリージョンに配置する必要があります。マルチリージョンデプロイの場合は、リージョンごとに 1 つのバケットを作成し、各リージョンに対して sam package を個別に実行します。

ステップ 1: Lambda パッケージのビルドと S3 へのアップロード

installation/ ディレクトリからパッケージ化スクリプトを実行します。

cd installation

# Make script executable (first time only)
chmod +x deploy-stacksets.sh

# Build, package, upload to S3, and generate resolved template
./deploy-stacksets.sh <your-org-shared-bucket>

このスクリプトは、次の処理を自動的に行います。

SAM を使用して Lambda 関数をビルド
ZIP パッケージを作成
ZIP を共有 S3 バケットにアップロード
S3 の値が組み込まれた packaged-template.yaml を生成 (デプロイ時にパラメータは不要)

図 4: Lambda パッケージが S3 バケットに正常にアップロードされたときのサンプルスクリプト出力

ステップ 2: StackSets を介した Lambda 関数のデプロイ

管理アカウント (または委任管理者アカウント) から、次のコマンドを実行します。

# Create StackSet (--region sets the StackSet "home region" where it is managed)
aws cloudformation create-stack-set \
  --stack-set-name pqc-readiness-lambda-functions \
  --template-body file://packaged-template.yaml \
  --capabilities CAPABILITY_IAM \
  --permission-model SERVICE_MANAGED \
  --auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false \
  --region us-east-1

# Deploy stack instances to member accounts
# --regions = target regions where Lambda functions are deployed in member accounts
# --region  = must match the StackSet home region above
aws cloudformation create-stack-instances \
  --stack-set-name pqc-readiness-lambda-functions \
  --deployment-targets OrganizationalUnitIds=ou-xxxx-xxxxxxxx \
  --regions us-east-1 \
  --region us-east-1

重要 — StackSet ホームリージョンとデプロイリージョンの違い:

--region (各 CLI コマンド) = StackSet リソースが存在する StackSet ホームリージョン。後続のオペレーション (describe、update、delete) では、これと同じリージョンを指定する必要があります。
--regions (create-stack-instances 上) = メンバーアカウントにスタックインスタンスが作成されるデプロイ先のターゲットリージョン
これらは独立した値です。CLI のデフォルトリージョンへの意図しないデプロイを避けるため、--region を明示的に指定してください。

注: SERVICE_MANAGED StackSets は、管理アカウントまたは委任管理者アカウントから作成する必要があります。管理アカウント自体はスタックインスタンスのデプロイから除外されます。管理アカウントでスキャナーが必要な場合は、deploy-per-regions.sh を別途使用してください。

ステップ 3: 組織コンフォーマンスパックのデプロイ

aws configservice put-organization-conformance-pack \
  --organization-conformance-pack-name pqc-legacy-tls-compliance \
  --template-body file://conformance-packs/pqc-legacy-tls-conformance-pack.yaml

これにより、各メンバーアカウントに、ローカルの Lambda 関数を参照する Config ルールが作成されます。

移行のガイダンスと優先順位付け

3 階層フレームワークは、PQC 移行の優先順位を提供します。

高優先度 – ティア 3 (PQC 非対応):

対象: PQC サポートのないリソース。これには、PQC 対応のセキュリティポリシーを使用していないエンドポイントや、依然として TLS 1.0 または 1.1 を許可しているエンドポイントが含まれます。
アクション: 名前に PQ を含む PQC 対応のポリシー (たとえば -PQ-2025-09 で終わるもの) にアップグレードします (完全なリストは Elastic Load Balancing セキュリティポリシーのドキュメントを参照してください)。
重要: PQC 対応のポリシーにアップグレードする前に、クライアントの TLS バージョンを監査してください。PQC 対応のポリシーには TLS 1.3 のサポートが必要です。TLS 1.2 以前のみをサポートするレガシークライアントは、接続のネゴシエーションに失敗します。まずティア 2 の下位互換性のあるポリシー (TLS 1.2 と 1.3 の両方を PQC とともにサポート) から始め、TLS ネゴシエーションの失敗がないか接続ログを監視します。クライアントが PQC 鍵交換を使用する TLS 1.3 をサポートしていることを確認してから、ティア 1 の TLS 1.3 のみのポリシーに移行してください。
リスク: エンドポイントが転送中のデータに対してポスト量子暗号をサポートしていません。レガシー TLS プロトコルは、現在の暗号攻撃に対して脆弱です。

低優先度 – ティア 2 (PQC 対応、下位互換性あり):

対象: TLS 1.3 + PQC 対応のポリシーを使用し、下位互換性のために TLS 1.2 もサポートするリソース
アクション: クライアント互換性の分析によって、接続するクライアントが TLS 1.3 をサポートしていることが確認できた場合、TLS 1.3 のみのポリシーを検討します。
リスク: 最小限です。これらのリソースは、TLS 1.3 接続で既に PQ-TLS をサポートしています。TLS 1.2 以前へのフォールバックは下位互換性を維持しますが、これは一部のクライアントが PQ-TLS でネゴシエートしていない可能性を示しているかもしれません。修復策としては、ログを監視してこれらの接続数とクライアント数を特定し、これらのクライアントが TLS 1.3 と PQ-TLS を使用するように移行計画を立てます。

対応不要 – ティア 1 (PQC 対応、最適な構成):

対象: PQC 鍵交換を使用する TLS 1.3 のみを使用するリソース。これらのリソースは目標状態を満たしています。移行は不要です。

結果の表示

各メンバーアカウントで、デプロイしたリージョンの AWS Config コンソールに移動します。

コンフォーマンスパックビュー

AWS Config → コンフォーマンスパックに移動し、次を探します。

OrgConformsPack-pqc-legacy-tls-compliance-

注: 組織コンフォーマンスパックには OrgConformsPack- というプレフィックスが付き、ランダムなサフィックスが追加されます (例: OrgConformsPack-pqc-legacy-tls-compliance-gyv22je0)。

図 5: PQC コンフォーマンスパックのコンプライアンススコアは、準拠しているルールとリソースの数の割合です

コンフォーマンスパックをクリックすると、4 つすべてのルールにわたる全体的なコンプライアンス概要を確認できます。

個別ルールビュー

AWS Config → ルールに移動し、プレフィックス pqc- が付いた 4 つのルールを見つけます。

pqc-elb-pqc-compliance-conformance-pack-
pqc-elb-legacy-tls-conformance-pack-
pqc-apigateway-pqc-compliance-conformance-pack-
pqc-apigateway-legacy-tls-conformance-pack-

任意のルールをクリックすると、次を表示できます。

準拠リソースと非準拠リソースの数
各リソースの詳細な注釈
リソース ARN と現在のセキュリティポリシー設定

図 6: コンフォーマンスパック内の Config ルールステータスの可視化

図 7: 3 階層フレームワークに基づく移行ガイダンスを記述した Config ルールの検出結果と注釈のサンプル画像

まとめ

PQC Readiness Scanner をデプロイすると、AWS エッジサービス全体の TLS 状態を可視化でき、手動の設定レビューを削減できます。ティアシステムは具体的なアップグレード推奨事項を提供するため、チームは暗号の専門知識がなくても次のステップを把握できます。スキャナーは設定変更を自動的に検出し、新しいデプロイが対応基準を維持できるように支援します。組み込みの AWS Config レポート機能は監査要件をサポートし、PQC 対応に向けた測定可能な進捗を示します。

PQC Readiness Scanner をデプロイし、PQC Readiness Scanner で結果を確認してください。高優先度のティア 3 リソースから移行を開始し、AWS Config アグリゲーターを使用して、アカウント全体の進捗を監視してください。

追加リソース

GitHub リポジトリ: PQC Readiness Config Scanner
AWS Config ドキュメント: Lambda を使用したカスタムルール
AWS SAM ドキュメント: サーバーレスアプリケーションモデル
PQC 移行計画: NIST ポスト量子暗号標準
PQC 移行計画: AWS ポスト量子暗号移行計画

この記事に関するご質問がある場合は、AWS Config re:Post で新しいスレッドを開始するか、AWS サポートにお問い合わせください。

Amazon Web Services ブログ