耐量子署名を導入すると、次に考えたいのは「組織で決めた方式を、各アカウントでも守れるか」です。設計書に承認済みのアルゴリズムを書いても、別の鍵を作成できる経路が残っていれば、運用とのずれが生まれます。

2026年10月12日公開のAWSの技術解説は、この問題をML-DSAのパラメーターセットで具体化しています。ML-DSA-65と87を承認し、44を対象外とする組織を例に、SCPやIAMで方針を実装する内容です。

鍵を作れなくするだけで十分なのか、既存の鍵や証明書はどう扱うのか。まずAWS KMSが何を条件として評価できるかを押さえると、ポリシーで制御できる範囲と、発行手順で管理する範囲が見えてきます。

ML-DSAの種類を見分ける条件は署名名ではなく鍵種別

ML-DSAは、耐量子のデジタル署名方式です。NISTのFIPS 204は2024年8月13日に公開され、AWS KMSの対応発表は2025年6月13日でした。今回の話題は、その署名機能を組織の方針に沿って運用するための権限制御です。

KMSでは、鍵の種類を表す KeySpec と、署名要求の SigningAlgorithm が別になっています。鍵仕様の公式リファレンスにある対応は次のとおりです。

署名アルゴリズム名は3種類とも同じです。そのため、kms:SigningAlgorithm で44だけを拒否しようとしても区別できません。kms:KeySpec なら、作成時の指定値にも、操作対象の鍵が持つ属性にも条件を設定できます。

なお、44を除外するのは、この例で採用した組織内の標準化方針です。ML-DSA-44もFIPS 204で標準化されており、脆弱だという意味ではありません。承認する組み合わせは、署名・鍵のサイズ、性能、必要な安全性の余裕を踏まえて決める話ですね。

作成と既存鍵の利用を、別々のAPI操作として拒否する

CreateKey を拒否しても、適用前に作られた鍵は残ります。そこで、作成経路に加え、既存鍵の Sign、Verify、GetPublicKey を対象にします。kms:KeySpec が作成時と鍵リソース操作の両方で使えることは、KMSの条件キー仕様でも確認できます。

次は、AWSの例を同じ条件の1ステートメントにまとめ、マルチリージョン鍵の複製も含めたSCP例です。対象アカウントで ML_DSA_44 の作成・複製・利用を拒否するもので、権限を付与するポリシーではありません。

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

ReplicateKey を含めるのは、別リージョンへの複製も鍵が増える経路だからです。一方、kms:* まで広げると、対象鍵の調査や無効化、削除予約といった管理操作も拒否しかねません。拒否する操作を列挙すれば、整理するための経路を残せます。

この例はRSAやECDSAを禁止せず、ML-DSA-65と87の利用権限も新たには与えません。「全署名鍵をML-DSAに統一する」という方針は、パラメーターセットの制限とは別に設計します。また、Verify も止まるので、既存成果物の検証に44の鍵を使っている処理は、適用前に切り替え方針を決めておきたいところです。

SCPの配置先とIAMロールをそろえて、拒否と成功を確かめる

SCPは、組織ルートやOU、アカウントへの配置によって適用範囲が変わります。まず検証用OUで影響を確かめ、本番OUへ段階的に展開するのが扱いやすいでしょう。Organizationsの仕様上、管理アカウントとサービスリンクロールはSCPの制限対象外です。

ロールごとに制御したい場合は、同じ拒否条件をIAMのアイデンティティポリシーに置けます。アクセス許可の境界を使う場合も、拒否条件だけをそのまま境界全体にするのではなく、必要な操作を境界側でも許可する設計が必要です。アクセス許可の境界は権限の上限を定める仕組みで、それ自体が権限を付与するわけではありません。付いていないロールへの適用や、境界の取り外しを防ぐ運用も必要になります。

検証では、対象ロールがもともと必要な権限を持つ状態で、追加した制限による差分を見ます。次の表は実測結果ではなく、上のSCPに対して確かめたい期待値です。

拒否だけを見ると、単なる権限不足でもテストが通ったように見えます。承認済みの鍵と管理操作の成功まで組み合わせると、狙った境界を確認しやすくなります。

Private CAとKMS外の処理には、発行経路の管理が必要

KMSで鍵を制限しても、AWS Private CAの鍵まで同じ条件で制御できるわけではありません。Private CAの権限リファレンスには、CA作成時のアルゴリズムを絞る専用条件キーがありません。そのため、CA作成を承認済みのプロビジョニング用ロールに限定し、発行経路で設定を固定する設計になります。

設定名にも違いがあります。CertificateAuthorityConfigurationでは、KeyAlgorithm と SigningAlgorithm に ML_DSA_65 などの値を指定します。KMSの ML_DSA_SHAKE_256 をそのまま使う項目ではありません。

さらに、CA自身の鍵と、発行される証明書に載る公開鍵は別です。後者は証明書署名要求（CSR）から渡されるため、CAの設定を固定するだけでなく、CSRの鍵種別も発行パイプラインで管理する必要があります。

同じ境界は、EC2やコンテナ、Lambda内で動く暗号ライブラリにもあります。SCPが評価するのはAWS APIへの操作であり、アプリケーション内部の署名計算ではありません。すでに取得した公開鍵によるローカル検証も、後から GetPublicKey を拒否して停止させることはできません。

ML-DSAの承認集合を、予防と検知の両方へ反映する

ここまでの拒否例は、指定した44だけを対象にします。将来、新しいパラメーターセットが追加されても、それを自動で拒否するわけではありません。未評価の種類を先に止めたい場合は、ML-DSAの範囲を StringLike: ML_DSA_* で絞り、承認済みの値以外を StringNotEquals で拒否する設計が候補になります。その分、新たな種類を承認するときにはポリシー更新が必要です。

予防策と合わせて、CloudTrailで鍵やCAの作成要求を追い、AWS Configのカスタムルールなどで構成のずれを検出します。APIイベントに含まれる情報だけで判断できるとは限りません。たとえば証明書をARNで参照する操作では、そのイベントだけから証明書のアルゴリズムを判定できず、証明書側の情報との照合が必要です。

組織の署名方針を運用へ落とし込むには、承認した鍵が使えること、除外した鍵の作成と利用が止まること、APIの外側に残る発行・実行経路を管理することを一続きで考えます。承認集合を変更するときに、この3点と検知ルールを一緒に更新できる状態にしておく。それが、暗号方式の選定を継続可能な統制に変える実務上のポイントです。

出典

• Title: Quantum-resistant signing on AWS, Part 2: Enforce your ML-DSA algorithm policy with SCPs and IAM
• URL: https://aws.amazon.com/blogs/security/quantum-resistant-signing-on-aws-part-2-enforce-your-ml-dsa-algorithm-policy-with-scps-and-iam/