AWSは2026年10月13日、耐量子署名の実装ガイド日本語版を公開しました。ソフトウェアに署名を付ける仕組みと、組織で使う暗号方式を制限する方法を2部構成で解説しています。開発部門だけでなく、暗号方式の社内ルールを管理する情シスやセキュリティ担当も、導入方法と統制できる範囲を確認できる内容です。
ソフトウェア署名の構成と、実装時の検討点
第1部は開発者向けで、NIST FIPS 204で標準化された署名方式「ML-DSA」を使います。対象はバイナリ、コンテナイメージ、ソフトウェア部品表(SBOM)です。AWSによると、構成には本番環境に対応した一般提供済みサービスを使います。
構成例では、署名用の鍵をAWS KMSで管理し、AWS Private CAで証明書の階層を作ります。AWS外で動くビルドエージェントの認証には、IAM Roles Anywhereを使います。AWS KMSの署名用秘密鍵は、鍵を保護する装置であるHSMの外には出ないとしています。
ただし、サービスの設定だけで完結する内容ではありません。コード署名用の証明書署名要求(CSR)の生成には、AWS CLIに加えてコード実装が必要です。また、ML-DSA-65の署名は3,309バイトで、比較対象のECDSA P-256は64バイトです。検証時には、署名サイズの違いも確認項目になります。
大容量の成果物には、代表値だけをKMSへ渡す「EXTERNAL_MU」を推奨しています。長期にわたって署名を検証するための対策としては、証明書の長期化、タイムスタンプ、再署名を挙げています。ただし、AWSはマネージドのタイムスタンプ局(TSA)を提供していません。長期検証まで必要な会社は、署名処理とは別に運用方法を検討する必要があります。
日本語のガイドは公開されていますが、日本での提供リージョンや料金は発表には書かれていません。
暗号方式の制限には、統制できない範囲もある
第2部は、セキュリティ、ガバナンス、コンプライアンスの各チームが対象です。組織のポリシーであるSCPと、権限を管理するIAMを使い、暗号方式の方針を適用する方法を示しています。
ポリシー例ではML-DSA-65とML-DSA-87を承認し、ML-DSA-44を除外します。AWSは、この除外は安全性を否定するものではなく、組織の標準化判断だと説明しています。例をそのまま社内の安全性評価として扱わず、自社の承認方式と照合することが重要です。
制限には「kms:KeySpec」を使い、未承認の鍵の作成と既存の鍵の使用を制御します。ただし、SCPは組織の管理アカウントには適用されません。また、統制対象はAWSサービスのAPIであり、利用者が管理する計算環境の内部で行う暗号処理は対象外です。SCPの設定だけで、社内の全ての暗号処理を統制できるわけではありません。
影響する会社・しない会社
- 影響する: バイナリ、コンテナイメージ、SBOMへのML-DSA署名を検討する会社です。鍵や証明書の構成に加え、追加実装と長期検証の担当を整理する材料になります。
- 影響する: AWS KMSで使う暗号方式を、SCPとIAMで制限したい会社です。新しい鍵だけでなく、既存の鍵の使用も確認対象になります。
- 影響しない: AWS組織の管理アカウントは、今回説明されたSCPによる制限の対象外です。IAMを含め、適用方法を別途確認する必要があります。
- 影響しない: 利用者管理の計算環境内で行う暗号処理は、この統制の対象外です。AWSサービスのAPIへの制限と分けて扱ってください。
情シスが今日やること
- 開発責任者に、バイナリ、コンテナイメージ、SBOMの署名状況を確認してください。ML-DSAを検討する場合は、AWS外のビルドエージェントの有無と、CSR生成コードの実装担当も整理します。
- AWS KMSの鍵の設定と、既存のSCP・IAMポリシーを確認してください。暗号方針の担当者に、自社で承認する方式とガイドの許可・除外例の違いを共有します。
- 制限ポリシーを導入する前に、非本番環境で鍵の作成と既存鍵による署名を試してください。管理アカウントと計算環境内の暗号処理は、同じSCPでは統制できない範囲として検証記録に残します。
- 長期検証が必要なら、本番導入前に開発部門と証明書の有効期間、タイムスタンプ、再署名の運用を決めてください。AWSのマネージドTSAは提供されていない点も共有します。
- ポリシーの見直し担当と実施時期を決めてください。AWSは、新たなバリアントや操作の追加に備え、制限ポリシーを定期的に見直すよう求めています。
