AWS における耐量子署名、パート 2: SCP と IAM による ML-DSA アルゴリズムポリシーの強制

本ブログは 2026 年 10 月 12 日に公開された AWS Blog “Quantum-resistant signing on AWS, Part 2: Enforce your ML-DSA algorithm policy with SCPs and IAM” を翻訳したものです。

この記事では、暗号アルゴリズムポリシーを設定し、Amazon Web Services (AWS) 環境でポリシーに準拠しない選択を防ぐ方法を紹介します。ポスト量子暗号を導入する際に最初に直面する判断の 1 つは、どのアルゴリズムとパラメータセットがビジネスニーズに合うかという選択です。この選択では、セキュリティと、署名サイズ、キーサイズ、パフォーマンスとのバランスを取る必要があります。クラウド環境の役割は、その判断をポリシーとして表現し、一貫して適用できるようにすることです。これにより、承認された選択肢は引き続き問題なく使用でき、除外された選択肢は導入できなくなります。この記事では、AWS での具体的な例を 1 つ取り上げ、組織の暗号アルゴリズムポリシーを予防的コントロールと発見的コントロールに変換する方法を説明します。現在の承認済みセットがどのようなものでも、また標準の進化に伴ってそれがどう変わっても、同じパターンを適用できます。

この記事は、AWS における耐量子署名に関する 2 部構成のシリーズのパート 2 です。パート 1 の「ML-DSA によるソフトウェアサプライチェーンの構築」はビルダー向けの記事で、バイナリ、コンテナイメージ、ソフトウェア部品表を対象とするエンドツーエンドの ML-DSA 署名パイプラインを構築します。パート 2 となるこの記事は、そのパイプラインをはじめ組織内のあらゆるものが使用してよいアルゴリズムを決定し、その決定を確実に適用する必要があるセキュリティ、ガバナンス、コンプライアンスの各チームを対象としています。

AWS Key Management Service (AWS KMS) は、ML-DSA-44、ML-DSA-65、ML-DSA-87 の 3 つのパラメータセットで ML-DSA デジタル署名方式 (FIPS 204) をサポートしており、それぞれ NIST セキュリティカテゴリ 2、3、5 を対象としています。3 つとも強力で標準化された選択肢です。いずれも、署名サイズ、キーサイズ、速度と、セキュリティマージンとの間にトレードオフがあります。セキュリティマージンとは、目標とするセキュリティカテゴリに対して、パラメータセットが余力として備えている暗号強度のことです。ML-DSA-44 は最もコンパクトで高速です。ML-DSA-65 と ML-DSA-87 はより大きなセキュリティマージンを備えているため、長期間にわたって信頼性を保つ必要がある署名に適しています。

この記事では、全体を通じて同じポリシー例を使用します。ML-DSA-65 と ML-DSA-87 を標準として採用し、ML-DSA-44 を承認済みセットから除外したい組織の例です。これは標準化に関する判断であり、ML-DSA-44 が安全でないという判断ではありません (次の注を参照)。以降のコントロールで ML-DSA-44 が登場する箇所は、自組織のポリシーに含まれないバリアントと読み替えてください。どのような許可/拒否の区分を選択しても、仕組みは同じです。ここでの承認済みセットは、パート 1 のアーキテクチャでデプロイするものと同じで、ルート認証局 (CA) には ML-DSA-87、下位 CA とコード署名キーには ML-DSA-65 を使用します。パート 1 で選択を行い、この記事でその選択を確実に守らせる仕組みを作ります。

注: ML-DSA-44 は有効な選択肢です。ML-DSA-44 は NIST によって完全に標準化されたパラメータセット (FIPS 204) で、NIST セキュリティカテゴリ 2 に該当し、おおよそ 128 ビットクラスの古典的セキュリティを目標としています (カテゴリ 2 は SHA-256 の衝突耐性を基準としています)。3 つのバリアントの中で署名とパブリックキーが最も小さく (パブリックキーは 1,312 バイト、署名は 2,420 バイト)、署名と検証も最も高速です。そのため、リソースが限られたデバイス、大量の署名処理、帯域幅やストレージの制約が厳しいワークロードに適しています。ML-DSA-65 や ML-DSA-87 を選択するのは、長期間にわたって信頼性を保つ必要がある署名のためにセキュリティマージンを上乗せしたい場合や、社内標準に合わせたい場合であり、ML-DSA-44 が脆弱だからではありません。

承認済みのバリアント (この例では ML-DSA-65 と ML-DSA-87) は、常に問題なく使用できる状態を保ちます。排除したいのは、ポリシー外のバリアント (ここでは ML-DSA-44) の導入です。具体的には、対象範囲内の AWS サービスにおいて、プリンシパルが次の操作を実行できないようにします。

• ML-DSA-44 のキーマテリアルを作成する
• 既存の ML-DSA-44 キーを署名または検証に使用する
• ML-DSA-44 を持ち込むことになるプライベート認証局 (CA) を立ち上げる

また、これらの設定からのドリフトはすべて検出できるようにします。

これらのコントロールは AWS サービスの API に対して機能し、主な対象は AWS KMS、AWS Private Certificate Authority (AWS Private CA)、AWS Certificate Manager (ACM) です。お客様が管理するコンピューティングリソース上で実行される暗号処理は対象外であり、統制することもできません。例えば、Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、コンテナ、AWS Lambda 関数上で、OpenSSL やアプリケーションが ML-DSA-44 署名を実行する場合が該当します。また、OpenSSH のハイブリッド ssh-mldsa44-ed25519 公開鍵認証などのプロトコルレベルでの使用も、サービスコントロールポリシー (SCP) や AWS Identity and Access Management (IAM) では制御できないため、この記事では取り上げません。

acm:ImportCertificate や iam:UploadServerCertificate で取り込まれる証明書マテリアルも、アルゴリズムを考慮した制御ができません (Private CA のセクションを参照)。その他の TLS 終端サービスや署名サービス (例えば Amazon CloudFront や Amazon API Gateway) と AWS IAM Roles Anywhere はこの記事の対象外のため、別途評価してください (このシリーズのパート 1 では ML-DSA 証明書と共に IAM Roles Anywhere を使用していますが、このサービスのコントロールはここでは扱いません)。

これらのコントロールは、多層防御として適用することを想定しています。どの程度厳格に統制したいかに応じて、すべてを適用することも、一部だけを適用することもできます。

• 組織ルートに包括的な SCP を適用すると、メンバーアカウントで ML-DSA-44 キーを作成または使用できなくなります (SCP は管理アカウントには適用されないため、管理アカウントのワークロードは制限されません)。
• 本番用の組織単位 (OU) に SCP を適用すると、本番アカウントでのみキーが制限されます。
• アカウント内で柔軟性が必要な場合は、SCP でアカウント全体に設定を強制するのではなく、IAM のアクセス許可の境界を使用します。

運用モデルに合った組み合わせを選択してください。ここで示すポリシー例は、すべての AWS リージョンに適用されるように記述しています。特定のリージョンだけを対象にする必要がある場合は、aws:RequestedRegion 条件を追加してください。

この記事で紹介するポリシーは、出発点として示す例です。お客様の環境に合わせた SCP、IAM ポリシー、アクセス許可の境界の作成、検証、保守は、お客様の責任で行ってください。デプロイ前に非本番環境ですべてのポリシーをテストし、組織の承認済み標準に合わせて例の値 (ポリシー名やキーの Amazon リソースネーム (ARN) など) を調整してください。

アルゴリズムポリシーは永久に固定されるものではなく、これらのコントロールも同様です。ポリシーを AWS のコントロールとして表現する意義は、ニーズや関連する標準の変化に応じて、アーキテクチャを再設計することなくポリシーを修正できる点にあります。承認済みセットを厳格化することも、緩和することも、入れ替えることもできます。ここで示す例は、現在のポリシーに合わせて調整するテンプレートとして扱ってください。

特定のアルゴリズムを指定して拒否するコントロールは、事実上、指定していないものをすべて許可する許可リストとして機能します。ここで問題となるのがデフォルト許可です。明示的に拒否していないパラメータセットはすべて許可されるため、まだ評価していないものも含め、新たに導入されたバリアントは、気付いて拒否リストに追加するまで使用できてしまいます。一方、承認済みのバリアントを非推奨にする場合は、そのバリアントを拒否リストに追加するだけなので、このモデルで簡単に対応できます。このモデルだけではとらえられないのは、新しいバリアントの登場です。これらのコントロールを定期的に見直し、拒否リストと検出を組み合わせることで、ポリシー外のバリアントが偶然見つかるまで放置せず、すぐに把握できるようにしてください。

もう 1 つの方法は、除外対象ではなく承認済みセットを基準に条件を記述することです。Deny ステートメントで StringNotEquals と承認済みキー仕様のリストを使用すると、リクエストのキー仕様がそのいずれにも一致しない場合に拒否が発動します。そのため、新しいバリアントやまだ評価していないバリアントは、リストに追加するまでデフォルトでブロックされます。この方法ではデフォルト許可の問題は解消されますが、新たに承認したバリアントを使えるようにするには、先にポリシーを更新する必要があります。このシリーズのパート 1 で紹介したファミリーレベルの SCP はこの形式で、キー仕様が ML_DSA_* ではない署名キーの作成をすべて拒否します。この記事の例はもう一方の形式を採用し、除外するバリアントを指定しているため、承認済みバリアントはポリシーを変更しなくても引き続き使用できます。どちらも有効な方法です。新しいものをまずブロックして後から承認したいのか、まず検知してからその時点で判断したいのかに応じて選択してください。

{
  "Sid": "OnlyApprovedMlDsaVariants",
  "Effect": "Deny",
  "Action": "kms:CreateKey",
  "Resource": "*",
  "Condition": {
    "StringLike": {
      "kms:KeySpec": "ML_DSA_*"
    },
    "StringNotEquals": {
      "kms:KeySpec": ["ML_DSA_65", "ML_DSA_87"]
    }
  }
}

StringLike 句は、ステートメントの対象を ML-DSA のキー仕様に限定し、他のキータイプに影響しないようにします。StringNotEquals 句は、承認済みリストにない ML-DSA バリアントをすべて拒否します。

アルゴリズムやキーサイズが時間とともに追加されたり、承認済みから未承認に変わったりするのと同様に、AWS サービスのオペレーションも変化します。現在 ML-DSA-44 キーを使用できるオペレーション (AWS KMS の Sign、Verify、GetPublicKey) は現時点のサービス機能に基づくものであり、AWS が新機能をリリースするにつれて増える可能性があります。作成だけでなく使用もブロックする方針の場合は、サービスの進化に合わせて、制限対象のオペレーションのリストを定期的に見直してください。

AWS KMS の ML-DSA サポートでは、3 つのキー仕様 (ML_DSA_44、ML_DSA_65、ML_DSA_87) が導入されていますが、いずれも同じポスト量子署名アルゴリズム ML_DSA_SHAKE_256 を使用します。この違いによって、どのコントロールが有効かが決まります。

1. kms:KeySpec: キーの KeySpec プロパティを反映します。この条件キーは、CreateKey (リクエストされたキー仕様) と、特定のキーに対して実行される AWS KMS キーリソースオペレーション (Sign、Verify、GetPublicKey など) の両方で評価されます。そのため、kms:KeySpec は ML_DSA_44 を ML_DSA_65 や ML_DSA_87 と区別でき、ML-DSA-44 キーの作成の防止と既存キーの使用の制限の両方で信頼できる手段となります。
2. kms:SigningAlgorithm: Sign と Verify で指定された署名アルゴリズムを反映します。この値は 3 つのバリアントすべてで ML_DSA_SHAKE_256 です。そのため、ML-DSA-44 を承認済みバリアントと区別できず、この目的には使用できません。

実務上の結論として、AWS KMS で保持するキーについては、ML-DSA-44 キーマテリアルの作成を防止することが、単独のコントロールとして最も堅牢です。ML-DSA-44 の KMS キーが存在しなければ、AWS KMS を通じた署名に使われることも、証明書のサブジェクトキーになることもありません。なお、CA のキーと TLS サーバーキーは別のマテリアルです。AWS Private CA は CA のキーペアを独自の HSM で生成して保持し、ACM が発行した TLS 証明書や、インポートまたはアップロードされた TLS 証明書は、それぞれ独自のキーを持ちます。そのため、これらは後述する AWS Private CA と証明書のコントロールで管理します。ML-DSA-44 の KMS キーが既に存在する場合は、kms:KeySpec を使用してその使用をさらに制限できます。

ML-DSA-44 を制限するために、SCP を組織ルートまたは特定の OU に適用できます。適用範囲は SCP をどこに配置するかで決まります。ルートにアタッチすると組織全体に、OU にアタッチするとその OU 内のアカウントに適用されます。SCP は、利用できる予防的コントロールの中で最も適用範囲の広いものです。

なお、SCP はメンバーアカウントと OU には適用されますが、組織の管理アカウントには適用されません。SCP による制限が及ばないため、ML-DSA-44 を使用できるワークロードを管理アカウントで実行しないようにしてください。

次の SCP の例では、ML-DSA-44 キーの作成 (kms:CreateKey) と使用 (kms:Sign、kms:Verify、kms:GetPublicKey) の両方を、ML_DSA_44 キー仕様との一致を条件に拒否します。作成の拒否は新しいキーの作成を防ぎます。使用の拒否は既存のキーを対象とし、SCP のアタッチ前に作成されたキーや、後から OU に参加したアカウントに存在するキーにも適用されます。これは、kms:KeySpec がこれらの使用オペレーションでもリクエスト時に評価されるためです。SCP はガードレールです。SCP 内の Deny は、メンバーアカウント内のどの IAM ポリシーでも上書きできません。

次の SCP を組織ルート (または該当する OU) にアタッチします。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyMLDSA44KeyCreation",
      "Effect": "Deny",
      "Action": "kms:CreateKey",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "kms:KeySpec": "ML_DSA_44"
        }
      }
    },
    {
      "Sid": "DenyMLDSA44KeyUsage",
      "Effect": "Deny",
      "Action": [
        "kms:Sign",
        "kms:Verify",
        "kms:GetPublicKey"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "kms:KeySpec": "ML_DSA_44"
        }
      }
    }
  ]
}

使用の拒否は、キー仕様を評価する 3 つのアクションに限定します。使用を拒否する Deny の対象は、kms:Sign、kms:Verify、kms:GetPublicKey に限定してください (テストにより、kms:KeySpec が 3 つすべてで評価されることを確認しています)。包括的な kms:* は避けてください。このワイルドカードは、DescribeKey、DisableKey、ScheduleKeyDeletion などの管理オペレーションまで対象にしてしまいます。これらは対象のキーを調査したりクリーンアップしたりするために必要なオペレーションであり、拒否すると、削除しようとしているキーを管理できなくなってしまいます。マルチリージョンキーを使用する場合は、作成の拒否に kms:ReplicateKey も追加してください。ML-DSA-44 のプライマリキーをレプリケートすると別のリージョンに新しい ML-DSA-44 キーが作成され、kms:KeySpec は ReplicateKey でも評価されるためです。

ファミリーレベルのガードレールとの組み合わせ。この SCP はどの ML-DSA パラメータセットを許可するかを制御するもので、RSA や ECDSA については何も規定しません。このシリーズのパート 1 では、キー仕様が ML-DSA ではない署名キーの作成をすべて拒否する補完的な SCP を紹介しています。両方を併せてアタッチすると、新しい署名キーはすべて ML-DSA であり、かつ承認済みバリアントでなければならなくなります。

運用上の考慮事項。組織ルートでの包括的な Deny は最も強力なコントロールですが、トレードオフもあります。対象範囲内のどこでも ML-DSA-44 キーを作成できなくなり、例外を設ける手段もないため、正当なテストがブロックされたり、ML-DSA-44 キーの作成を試みる Infrastructure as Code (IaC) やパイプラインの実行が失敗したりする可能性があります。柔軟性を残したい場合は、Deny の対象を本番 OU に限定し、ビルドアカウントや非本番アカウントでは IAM のアクセス許可の境界 (次のセクションを参照) を使用することを検討してください。

呼び出し元に表示される内容。SCP によってリクエストが拒否されると、呼び出し元はサービスコントロールポリシーによる明示的な拒否を示す AccessDenied エラーを受け取ります。同じアカウント内や同じ組織内からのリクエストであれば、エラーには拒否したポリシーのタイプが含まれます。また、拡張エラーメッセージが各サービスに順次展開されるにつれて、そのポリシーの ARN も含まれるようになります。エラーには SCP のポリシー内容は表示されず、ブロックされたユーザーは自分の環境に適用されている SCP を確認できないことがよくあります。サポートチームが AccessDenied の原因をすばやく特定できるように、SCP の ARN とその目的を社内で文書化しておいてください。

次の IAM ポリシーは、プリンシパルレベルで ML-DSA-44 をブロックします。前述の SCP に相当するアイデンティティベースのポリシーであり、組織全体のガードレールではなく、アカウント単位やロール単位で制御したい場合に役立ちます。制限したい IAM ロールまたは IAM ユーザーにアタッチしてください。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyMLDSA44KeyCreation",
      "Effect": "Deny",
      "Action": "kms:CreateKey",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "kms:KeySpec": "ML_DSA_44"
        }
      }
    }
  ]
}

1. 条件の値は ML_DSA_44 です (ハイフンではなくアンダースコア)。
2. このポリシーがブロックするのは CreateKey だけです。プリンシパルレベルで既存の ML-DSA-44 キーの使用もブロックするには、Sign、Verify、GetPublicKey の拒否を追加してください。この拒否は「既存の ML-DSA-44 キーの使用の制限」セクションで紹介しています。
3. 上書きできない包括的な保護を実現するには、プリンシパルレベルのポリシーだけに頼らず、SCP としてデプロイしてください。

IAM のアクセス許可の境界は、アイデンティティベースのポリシーが IAM ロールや IAM ユーザーに付与できるアクセス許可の上限を設定するもので、SCP の代わりとしても、SCP を補完するものとしても使用できます。実際に有効なアクセス許可は、アイデンティティベースのポリシーと境界が重なる部分になり、境界内の Deny はアタッチされたポリシーで上書きできません。境界は、複数アカウントにまたがる包括的な拒否ではなく、アカウント単位やロール単位で柔軟に制御したい場合 (例えば、ビルドアカウントや非本番アカウント) に役立ちます。

運用上の考慮事項。アクセス許可の境界は、それがアタッチされたプリンシパルにしか効果がありません。境界をコントロールとして機能させるには、すべての IAM プリンシパルに境界をプログラムで強制する仕組みが必要です。その一例として、次のような SCP が考えられます。iam:CreateRole、iam:CreateUser、iam:PutRolePermissionsBoundary、iam:PutUserPermissionsBoundary は、承認済みの境界が設定されていない限り拒否します (iam:PermissionsBoundary 条件キーを使用)。さらに、iam:DeleteRolePermissionsBoundary と iam:DeleteUserPermissionsBoundary は無条件に拒否し、後から境界を削除できないようにします。また、準拠していないプリンシパルを定期的に調べ、PermissionsBoundary を自動的にアタッチするなどの対応を行うこともお勧めします。IAM ユーザーは使用すべきではありませんが、強制の仕組みでは IAM ユーザーが存在する可能性も考慮しておく必要があります。

境界は上限を設定するだけで、それ自体がアクセス許可を付与するわけではありません。そのため、まずすべてのアクションに Allow を指定したうえで、ML-DSA-44 キーの作成を明示的に拒否します。次のアクセス許可の境界は、ML-DSA-44 キーの作成を拒否します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAll",
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    },
    {
      "Sid": "DenyMLDSA44KeyCreation",
      "Effect": "Deny",
      "Action": "kms:CreateKey",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "kms:KeySpec": "ML_DSA_44"
        }
      }
    }
  ]
}

この境界が設定されたプリンシパルについて、既存の ML-DSA-44 キーの使用もブロックするには、次のセクションで紹介する Sign、Verify、GetPublicKey の拒否ステートメントを追加します。このステートメントでも同じ条件キー (kms:KeySpec) を使用します。

「背景」セクションで説明したように、kms:KeySpec は Sign、Verify、GetPublicKey でも評価され、使用されるキーの KeySpec を反映します。そのため、kms:KeySpec が ML_DSA_44 の場合にこれらのオペレーションを拒否しつつ、ML_DSA_65 と ML_DSA_87 は引き続き許可できます。次の IAM ポリシーを IAM プリンシパルにアタッチすると、この制御を実現できます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyMLDSA44KeyUsage",
      "Effect": "Deny",
      "Action": [
        "kms:Sign",
        "kms:Verify",
        "kms:GetPublicKey"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "kms:KeySpec": "ML_DSA_44"
        }
      }
    }
  ]
}

この拒否は AWS KMS のキーポリシーに記述することもできます。同じ kms:KeySpec による拒否を、AWS KMS キーのキーポリシーに直接記述できます。キーポリシーはリソースポリシーであるため、ステートメントには Principal 要素が必要です。一方、アイデンティティベースのポリシーと SCP では、適用対象のプリンシパルを指定しません。キーポリシー内の拒否は特定のキーを保護するリソース側の最後の防衛線となり、SCP は上書きできない組織全体の保護を提供します。前の例を AWS KMS キーポリシーに変換するには、ステートメントに Principal 要素 (例えば "Principal": {"AWS": "*"}、またはより具体的なプリンシパル) を追加し、それ以外はそのままにします。

目的によっては、使用を拒否するだけでなく、キーマテリアル自体を削除したい場合もあるでしょう。ただし、何らかの方法で追跡していない限り、特定のキーでどのデータが署名されたかを把握するのは困難です。使用済みのキーを削除すると、署名を検証できなくなります。キーを削除する前に、そのキーが使用されていないことを慎重に確認してください。

1. キーを無効化するか、削除をスケジュールします。無効化するとキーの使用が直ちに停止し、後から元に戻すこともできます。キーの削除は、待機期間の経過後に確定し、元に戻せなくなるため、削除をスケジュールする前に十分に確認してください。
2. 特定のキー ARN を指定して Sign、Verify、GetPublicKey を拒否します。キー仕様全体ではなく、特定のキーだけを対象にできます。そのためには、IAM ポリシーの Resource 要素に対象のキー ARN を列挙します (条件キーは不要です)。この方法は特定のキーだけを対象にする場合には効果的ですが、キー ARN のリストを維持するのは手間がかかります。この方法は必要な場合に限って使用してください。なお、キー ARN を指定した IAM ポリシーを検討している場合は、対象キーのキーポリシーに Deny を記述しても同じ目的を達成でき、その拒否はキー自体にアタッチされることを覚えておいてください。
3. 既存のキーの検索 (無効化または削除する場合にのみ必要)。IAM ポリシーや SCP で Deny を kms:KeySpec に基づいて指定する場合は、リクエスト時にキー仕様に基づいて適用されるため、どのキーが存在するかを把握しておく必要はありません。一方、既存の ML-DSA-44 キーを無効化または削除したい場合は、それらのキーを見つける必要があります。AWS KMS にはキー仕様で絞り込むサーバー側のフィルターがないため、ListKeys でキーを列挙し、DescribeKey を呼び出して各キーの KeySpec を確認します。このようにクライアント側でフィルタリングするパターンは AWS API で広く使われており、AWS SDK のページネーション機能で容易に実装できます。また、AWS Config を使用して KMS キーリソースを記録し、クエリすることもできます。

参考: Choosing a KMS key spec – kms:KeySpec condition key

AWS Private CA では、CA の作成時に CertificateAuthorityConfiguration パラメータを CreateCertificateAuthority に指定して、CA の署名アルゴリズムを設定します (有効な値には ML_DSA_44、ML_DSA_65、ML_DSA_87 などがあります)。現在、アルゴリズムに対応する条件キーはないため、SCP で署名アルゴリズムを強制することはできません。このセクションで紹介するアプローチでは、CA を作成できるプリンシパルを制御し、その信頼されたパスでアルゴリズムを固定したうえで、AWS CloudTrail を利用した検出で補完します。

1. CA を作成できるプリンシパルを制限します。SCP で acm-pca:CreateCertificateAuthority を広く拒否し、少数の信頼されたロールや承認済みのプロビジョニングパイプラインにのみ許可します。これにより、任意のプリンシパルが未承認のアルゴリズムで CA を立ち上げることができなくなります。
2. 信頼されたパスでアルゴリズムを固定します。承認済みのパイプラインや IaC テンプレートで、SigningAlgorithm を ML_DSA_65 または ML_DSA_87 として CertificateAuthorityConfiguration 内にハードコードします。AWS Private CA にはアルゴリズムの条件キーがないため、このプロビジョニングパスがアルゴリズムを強制する箇所になります。なお、CA のアルゴリズムで固定されるのは、その CA が発行する証明書の署名です。各証明書のサブジェクトキーは CSR から取得され、AWS Private CA はそのアルゴリズムを検証せずにそのままコピーします。そのため、同じ発行パイプラインで CSR のキーアルゴリズムも固定してください。
3. 信頼チェーンを制御します。PKI 側では、承認済みの CA のみをトラストストアと発行階層に追加し、ML-DSA-44 の証明書を発行する可能性がある CA を信頼したり、下位 CA として配置したりしないでください。これにより、未承認の CA が信頼されたパスに入り込むのを防止できます。
4. ドリフトを検出します。CloudTrail で CreateCertificateAuthority の呼び出しを記録し、AWS Config で設定に ML_DSA_44 を使用している CA にフラグを立てます。これにより、未承認の CA をすばやく検出できます。

このシリーズのパート 1 では、この仕組みを実際に構築しています。具体的には、CreateCertificateAuthority を使用して ML-DSA-87 のルート CA と ML-DSA-65 の下位 CA を作成し、それらをアクティブ化して、生成された証明書チェーンを検証者に配布します。ここで説明するモデルでは、これらの呼び出しを実行できるのは承認済みのプロビジョニングパイプラインだけです。

ML-DSA の値を CertificateAuthorityConfiguration に設定する方法。KeyAlgorithm フィールドと SigningAlgorithm フィールドの両方に同じバリアントを指定します (例えば、KeyAlgorithm=ML_DSA_65 と SigningAlgorithm=ML_DSA_65)。AWS KMS と AWS Private CA では署名アルゴリズムの指定方法が異なる点に注意してください。AWS Private CA の SigningAlgorithm にはバリアントの値 (ML_DSA_44、ML_DSA_65、ML_DSA_87) を直接指定し、ML_DSA_SHAKE_256 は受け付けません。一方、AWS KMS では署名アルゴリズムとして ML_DSA_SHAKE_256 を使用します。また、一部の古い AWS コマンドラインインターフェイス (AWS CLI) ビルドでは、組み込みの CLI ヘルプに ML-DSA バリアントの説明が含まれていませんでした。有効な値を確認する際は、AWS CLI のヘルプに頼らないでください。詳細については、「CertificateAuthorityConfiguration API Reference」を参照してください。

既知の制限事項。一部の対象にはアルゴリズムの条件キーがないため、ポリシーではなくプロビジョニングと検出によって強制します。acm-pca:CreateCertificateAuthority にはアルゴリズムの条件キーがなく、acm:ImportCertificate と iam:UploadServerCertificate はアルゴリズムを認識しません。そのため、作成、インポート、アップロードされる証明書の署名設定が許可されていないものであっても、IAM ポリシーや SCP の条件でブロックすることはできません。これらはプロビジョニングプロセスで管理し、呼び出せるプリンシパルを制限したうえで、不要な場合はインポートとアップロードのアクションを完全に拒否してください。現時点で利用できる緩和策は、上記のコントロールです。

特に iam:UploadServerCertificate には、特定のアルゴリズムの使用を防止する手段がまったくありません。また、AWS はこの API を使用した証明書の生成とアップロードを推奨していません。この API は ACM より前から存在するもので、主に ACM がまだ利用できない AWS リージョンやパーティションに対応するために用意されています。新しいリージョンやパーティションの構築中は、ACM のサポートが提供される前でもワークロードに TLS サーバー証明書が必要になる場合があります。その間、IAM に証明書をアップロードすれば、証明書を保存して参照できます。そのリージョンで ACM が利用可能になったら、ACM に切り替えてください。このような限られたケースを除き、本当に必要な場合以外は iam:UploadServerCertificate を拒否してください。

ACM が発行するリーフ証明書。CA 自体のキーと署名アルゴリズムは、ACM がその CA から発行するリーフ証明書とは別物です。ACM でリーフ証明書をリクエストする場合は、acm:KeyAlgorithm 条件キーを acm:RequestCertificate で使用して、リーフ証明書のキーアルゴリズムを制限できます。これにより、前述の AWS KMS の例と同様に、SCP や IAM ポリシーでリーフ証明書の承認済みアルゴリズムを許可リストとして指定できます。なお、この記事の執筆時点では、ACM は ML-DSA のリーフ証明書を提供していません。そのため、このポリシーは差し迫った ML-DSA-44 のリスクへの対策ではなく、将来を見据えた多層防御のコントロールです。次の IAM ポリシーは説明用の例です (承認済みアルゴリズムの例を使用しています)。サービスの中でも変化が続いている領域のため、実際に利用する前に必ずお使いの環境で検証してください。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RestrictACMLeafKeyAlgorithm",
      "Effect": "Deny",
      "Action": "acm:RequestCertificate",
      "Resource": "*",
      "Condition": {
        "StringNotEqualsIfExists": {
          "acm:KeyAlgorithm": [
            "EC_secp384r1",
            "RSA_2048"
          ]
        }
      }
    }
  ]
}

この例では、Deny と StringNotEqualsIfExists を組み合わせているため、許可されていないアルゴリズムを指定したリクエストに加えて、リクエストコンテキストに acm:KeyAlgorithm が含まれないリクエストも拒否されます。...IfExists 演算子は、条件キーが存在しない場合に条件を true と評価するためです。通常の StringNotEquals を使用した場合も、キーが存在しなければ条件は true となり、同じく拒否されます。条件キーが存在する場合に限って未承認のアルゴリズムを拒否したい場合は、StringNotEquals による比較と、"Null": {"acm:KeyAlgorithm": "false"} による存在チェックを同じ Condition 内に記述してください。

Elastic Load Balancing は、Network Load Balancer (NLB) と Application Load Balancer (ALB) のどちらでも、アプリケーションに代わって TLS を終端します。これらのリスナーが使用する証明書は、ACM でリクエストされたもの、ACM にインポートされたもの、または IAM にアップロードされたもののいずれかです。ネゴシエーション時に提示される内容は、リスナーに設定されたセキュリティポリシーと証明書によって決まります。この記事の執筆時点では、ACM のリクエストとインポートは RSA キーと ECDSA キーのみに対応しており、NLB と ALB のリスナーも RSA 証明書と ECDSA 証明書のみに対応しています。そのため、現時点では ML-DSA 証明書をリスナーにバインドすることはできません。前述の ACM リーフ証明書のポリシーと同様に、このセクションのコントロールは、差し迫った ML-DSA-44 のリスクへの緩和策ではなく、将来を見据えた多層防御です。

リスナーの API コールでは証明書を ARN でしか参照しないため、CreateListener、ModifyListener、AddListenerCertificates に対して、証明書のアルゴリズムを検査する SCP を記述することはできません。IAM の条件では、別途参照されるリソースの属性を参照できないためです。したがって、TLS から ML-DSA-44 を排除するには、関連付け可能な ML-DSA-44 の証明書マテリアルをそもそも存在させないことが前提となります。

1. プライベート CA が ML_DSA_65 または ML_DSA_87 の証明書のみを発行するように設定し、CA を作成できるプリンシパルを制御します。
2. AWS KMS で ML-DSA-44 キーの作成を防止し、AWS KMS で保持している ML-DSA-44 キーが証明書のサブジェクトキーにならないようにします。なお、ACM が発行した証明書や、インポートまたはアップロードされた証明書の TLS サーバーキーは KMS キーではないため、項目 1 と 3 で管理します。
3. AWS Private CA のセクションで説明したように、インポートおよびアップロードされる証明書をプロビジョニングプロセスで管理するか、不要な場合はインポートとアップロードのアクションを拒否します。

CloudTrail は、このセクションで扱う証明書とリスナーの API コールを記録します。対象は、証明書の作成とインポート (acm-pca:CreateCertificateAuthority、acm:ImportCertificate、iam:UploadServerCertificate) と、リスナーの設定 (CreateListener、ModifyListener、AddListenerCertificates) です。イベントにアルゴリズムが記録されるかどうかは、呼び出し自体にアルゴリズムの情報が含まれているかどうかで決まります。アルゴリズムを入力として受け取る作成系の呼び出しでは、アルゴリズムが記録されます。kms:CreateKey では KeySpec が、acm-pca:CreateCertificateAuthority では署名アルゴリズムが記録されます。そのため、CloudTrail は ML-DSA-44 のキーマテリアルや CA の作成を検出するのに効果的です。一方、リスナーへのバインドでは証明書を ARN でしか参照しないため、そのイベントには証明書のアルゴリズムが記録されません。バインドされた証明書やインポートされた証明書のアルゴリズムを評価するには、発見的コントロールの最後の防衛線として AWS Config のリソース評価を使用してください。

主な予防的コントロールは、証明書マテリアルそのものの管理です。ML-DSA-44 の CA も ML-DSA-44 の KMS キーも存在せず、証明書のインポートとアップロードが制御されていれば、ML-DSA-44 証明書を発行することもバインドすることもできません。許可する TLS セキュリティポリシーを許可リストとして運用している場合は、elasticloadbalancing:SecurityPolicy 条件キー (CreateListener と ModifyListener で使用) で、リスナーが使用できる TLS ポリシーをさらに制限することもできます。

次の表は、ポリシー例 (ML-DSA-65 または ML-DSA-87 を許可し、ML-DSA-44 を除外する) に対応する利用可能なコントロールをまとめたものです。自組織のポリシーで定める承認済みアルゴリズムのセットに合わせて、コントロールを調整してください。

この記事では、ML-DSA を例に、暗号アルゴリズムポリシーを実際に強制できる AWS のコントロールに変換する方法を説明しました。中心となるのは kms:KeySpec 条件キーです。この条件キーを使うと、承認済みのパラメータセット (ML-DSA-65 と ML-DSA-87) を問題なく使用できる状態に保ちながら、除外したパラメータセット (ML-DSA-44) の作成と使用を防止できます。対象となるのは CreateKey に加えて、Sign、Verify、GetPublicKey の各オペレーションです。これらのオペレーションでは、kms:SigningAlgorithm を使ってもバリアントを区別できません。これらのコントロールを SCP、IAM ポリシー、アクセス許可の境界、KMS キーポリシーによる多層防御として適用し、アルゴリズムの条件キーがない対象 (AWS Private CA、証明書のインポート、Elastic Load Balancing の TLS) にはプロビジョニング制御と AWS CloudTrail および AWS Config によるドリフト検出で対応することで、未承認のバリアントをアカウントから一貫して排除できます。

このパターンは ML-DSA-44 に限ったものではありません。アルゴリズムポリシーは標準や自組織の要件の変化に伴って変わっていくため、これらのコントロールを再利用可能なテンプレートとして扱い、同じ条件キーとガードレールを、その時点の承認済みセットに合わせて適用し直してください。強制の仕組みを作り直すことなく許可する内容を変更できる、この適応性こそが暗号アジリティの実践的な意味です。

まずは「ML-DSA keys in AWS KMS」と「Choosing a KMS key spec」を確認し、デプロイする前に非本番環境でポリシー例をテストしてください。

これらのコントロールで管理するワークロードについては、このシリーズのパート 1 をお読みください。パート 1 では、ここで強制する承認済みセットを使用して、キーの作成と PKI の構築からアーティファクトの署名と検証まで、ML-DSA 署名パイプライン全体を構築します。

• AWS における耐量子署名、パート 1: ML-DSA によるソフトウェアサプライチェーンの構築
• AWS KMS adds support for post-quantum ML-DSA digital signatures
• ML-DSA keys in AWS KMS
• AWS KMS condition keys (kms:KeySpec evaluated on CreateKey and key resource operations)
• Choosing a KMS key spec (kms:KeySpec)
• Use condition keys with ACM (acm:KeyAlgorithm)
• Actions, resources, and condition keys for AWS Private Certificate Authority
• Private CA CertificateAuthorityConfiguration API
• Actions, resources, and condition keys for Elastic Load Balancing v2 (elasticloadbalancing:SecurityPolicy)
• Enhanced access denied error messages with policy ARNs

本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。