本ブログは 2026 年 9 月 15 日に公開された AWS Blog “ AWS STS simplifies session token size limits and adds session token size monitoring ” を翻訳したものです。 AWS Security Token Service (AWS STS) でセッショントークンのサイズ制限が簡素化され、セッションポリシーとセッションタグに使用できる容量が拡大しました。STS は、パックされたポリシー (packed policy) のサイズ制限とセッショントークン全体のサイズ制限を廃止し、4,096 バイトという単一のトークンサイズの制限に置き換えました。また、セッショントークンのサイズが API レスポンス、 Amazon CloudWatch メトリクス、 AWS CloudTrail イベントで報告されるようになりました。さらに、STS でさまざまなサイズのセッショントークンを生成できるため、インフラストラクチャがサポートできるトークンの最大サイズを確認できます。 4,096 バイトという制限は現時点での上限であり、恒久的なものではありません。セッショントークンにより多くの情報を含める必要がある新機能が追加されるのに伴い、AWS がこの制限を引き上げる可能性があります。 この記事では、変更点、この変更による影響、次に行うべきことについて説明します。 変更点 AWS STS のセッション発行 API (session-vending API) である AssumeRole 、 AssumeRoleWithSAML 、 AssumeRoleWithWebIdentity 、 GetSessionToken 、 GetFederationToken などは、一時的なセキュリティ認証情報 (アクセスキー ID、シークレットアクセスキー、セッショントークン) を返します。今回の変更の対象はセッショントークンです。セッショントークンとは、渡されたセッションポリシーとタグ、および AWS が追加するコンテキストを基に STS が作成する不透明な文字列です。 変更点は次の 3 つです。 単一の制限: 以前の STS は、セッショントークンに 2 つのサイズ制限を適用していました。STS はセッションポリシーとタグをシリアル化および圧縮して、パックされたポリシーと呼ばれる形式に変換しており、これに独自の制限がありました。さらに、パックされたポリシーを含む組み立て後のトークンには、全体に対する別の制限がありました。リクエストはどちらの制限でも失敗する可能性があり、いずれの場合も同じ PackedPolicyTooLargeException が返されるため、どちらの制限を超えたのかを判断できませんでした。現在は単一の制限のみが適用され、組み立て後のセッショントークンを 4,096 バイト以内に収める必要があります。パックされたポリシーに対する個別の制限は、失敗の予測を難しくしていましたが、廃止されました。組み立て後のセッショントークンが制限を超えると、STS は PackedPolicyTooLargeException を返します。STS は引き続き同じ例外を使用するため、既存のエラー処理コードは SDK を更新しなくてもそのまま動作します。 セッショントークンサイズの報告: STS のセッション発行 API から返されるすべての成功レスポンスに、 SessionTokenSize (セッショントークンのサイズをバイト単位で報告) と SessionTokenUtilization (4,096 バイトの制限に対する使用率を報告) が含まれるようになりました。また、STS は下位互換性のために、すべての成功レスポンスで PackedPolicySize も返します。 PackedPolicySize は現在 SessionTokenUtilization と同じ値を報告するため、古いバージョンの AWS SDK を使用するアプリケーションでも、このフィールドで使用率をモニタリングできます。これらのレスポンスフィールドは CloudTrail イベントにも記録されます。CloudWatch では、 SessionTokenSize と SessionTokenMaxSize (適用される制限) が AWS/STS 名前空間に発行されます。 テストの簡素化: MinimumSessionTokenSize は、STS のセッション発行 API に新しく追加されたオプションのパラメータです。このパラメータを使用すると、セッショントークンを指定したサイズ以上 (最大 4,096 バイト) に増やすことができます。インフラストラクチャが処理できるトークンの最大サイズを確認する際に使用してください。 動作 以前 現在 適用される制限 2 つ: パックされたポリシーのサイズと組み立て後のトークンのサイズ 1 つ: 組み立て後のセッショントークンのサイズ (4,096 バイト) 失敗時のエラー PackedPolicyTooLargeException : エラーメッセージには、2 つの制限のうちどちらを超えたのかが示されませんでした。 PackedPolicyTooLargeException : 更新されたメッセージには、セッショントークンのサイズと許容される最大サイズがバイト単位で示されます。 セッショントークンサイズの可視性 報告なし API レスポンスと AWS CloudTrail SessionTokenSize 、 SessionTokenUtilization 、 PackedPolicySize 。 PackedPolicySize は、下位互換性のために SessionTokenUtilization と同じ割合を報告します。 Amazon CloudWatch SessionTokenSize と SessionTokenMaxSize インフラストラクチャのテスト 仕組みなし MinimumSessionTokenSize : セッション発行 API のパラメータ この変更による影響 影響はお客様の状況によって異なります。代表的なケースは次のとおりです。 トークンサイズのエラーが発生したことがない場合: 変化に気付くことはほとんどないでしょう。トークンのサイズは現在のままで、制限までの余裕が広がります。ただし、時間の経過とともに、トークンがこれまでシステムで処理してきたサイズよりも大きくなる可能性があります。 MinimumSessionTokenSize を使用して、システムで処理できるトークンの最大サイズを確認することをお勧めします。詳細については、 「次に行うべきこと」 セクションを参照してください。 以前に PackedPolicyTooLargeException が発生したことがある場合: 制限が一本化されたことで、以前は失敗していた一部のリクエストが成功するようになります。トークンサイズのエラーを避ける目的で導入した回避策を見直し、引き続き必要かどうかを判断してください。一般的なベストプラクティスは引き続き有効です。タグの大文字と小文字を統一し、タグ値を再利用すると圧縮効率が高まります。また、セッションポリシーを簡潔にすると、組み立て後のトークンを小さく抑えられます。エラー処理のためのコード変更は不要です。組み立て後のセッショントークンが制限を超えた場合、AWS STS は引き続き PackedPolicyTooLargeException を返します。これは、今回の変更前に STS が返していたものと同じ例外です。 独自に認証情報のサイズ制限を適用しているシステムがある場合: アプリケーションが AWS SDK を使用して一時的な認証情報を取得し、AWS の API コールを行う場合は、SDK がセッショントークンを内部で処理するため、トークンサイズがコードに影響することはありません。注意が必要なのは、ロードバランサー、プロキシ、キャッシュ、データベースなど、セッショントークンを保存または転送するシステムです。これらのシステムには、これまでの小さなトークンでは抵触しなかったサイズ制限が設けられている可能性があります。例えば、 varchar(2048) として定義されたデータベース列には、4,096 バイトのトークンを格納できません。セッショントークンを永続化または受け渡ししている箇所を確認し、各システムがサポートするトークンの最大サイズを特定してください。テスト方法については次のセクションで説明します。 次に行うべきこと この変更に向けてシステムを準備するために、次の 3 つのステップを実施することをお勧めします。 システムで処理できるトークンの最大サイズを検証する 。 MinimumSessionTokenSize を使用して、インフラストラクチャ内の各システムで処理できるセッショントークンの最大サイズを確認します。これらの制限を把握しておくと、大きなトークンを拒否したり切り捨てたりする可能性のあるシステムを特定できます。4,096 バイトという制限は現在のニーズを反映したものであり、恒久的な上限ではありません。新しいサービス向けの追加のコンテキストキー、より充実した監査メタデータ、業界のポスト量子アルゴリズムへの移行に伴うより大きな暗号署名など、AWS が新機能を導入するにつれて、この制限が引き上げられる可能性があります。現在の最大値をシステムにハードコーディングすることは避け、制限が変更された場合は、固定サイズを前提としている箇所を見直してください。 ヒント: AWS STS はトークンを組み立てる際に、セッションポリシーとタグをシリアル化および圧縮します。圧縮結果は、長さだけでなく実際の内容によって変わります。文字数が同じ 2 つのタグセットでも、生成されるトークンのサイズが異なる場合があります。そのため、入力の長さから推定するよりも、 MinimumSessionTokenSize を使用する方がインフラストラクチャを確実にテストできます。 aws sts assume-role \ --role-arn arn:aws:iam::123456789012:role/MyRole \ --role-session-name validation-test \ --minimum-session-token-size 4096 まずは、最大サイズのトークンでテストできるように 4,096 バイトを指定します。システムがトークンを切り捨てたり拒否したりする場合は、値を下げてインフラストラクチャがサポートするサイズを特定し、可能であればそのシステムの制限を引き上げます。 MinimumSessionTokenSize は、AWS SDK、 AWS コマンドラインインターフェイス (AWS CLI) 、Tools for PowerShell の最新バージョンで利用できます。詳細については、「 STS API リファレンス 」を参照してください。使用中の AWS SDK または AWS CLI がこのパラメータに対応していない場合は、更新してからこの機能を使用してください。 セッショントークンのサイズをモニタリングする (推奨) 。インフラストラクチャにサイズの制約がある場合は、モニタリングによってその制限に近づいているトークンを把握し、リクエストが失敗する前に対処できます。AWS STS は 3 つのチャネルでサイズを報告しており、それぞれ異なる用途に適しています。 API レスポンス: レスポンスから SessionTokenUtilization と SessionTokenSize を読み取るには、最新バージョンの AWS SDK が必要です。なお、CloudWatch と CloudTrail を使用すれば、SDK を更新しなくてもトークンサイズをモニタリングできます。 { "Credentials": { "AccessKeyId": "REDACTED", "SecretAccessKey": "REDACTED", "SessionToken": "REDACTED", "Expiration": "2026-06-30T12:00:00Z" }, "AssumedRoleUser": { "...": "..." }, "PackedPolicySize": 61, "SessionTokenSize": 2532, "SessionTokenUtilization": 61 } CloudWatch: STS は、 SessionTokenSize と SessionTokenMaxSize を AWS/STS 名前空間に発行します。これらのメトリクスを使用して、ダッシュボードを作成したり、アラームを設定したりできます。アラームのしきい値は、4,096 バイトの最大値ではなく、テストで特定したサイズ制限に基づいて設定してください。最大値はすべてのアカウントで共通のため、重要なのはお客様のインフラストラクチャ固有の制限です。 次の図は、CloudWatch コンソールで SessionTokenMaxSize と SessionTokenSize のメトリクスをグラフ表示した例です。 図 1: CloudWatch コンソールの SessionTokenMaxSize および SessionTokenSize メトリクス CloudTrail: STS の各セッション発行イベントには、成功したコールについて SessionTokenUtilization と SessionTokenSize が記録されます。 { "eventName": "AssumeRole", "responseElements": { "credentials": { "...": "..." }, "assumedRoleUser": { "...": "..." }, "packedPolicySize": 61, "sessionTokenUtilization": 61, "sessionTokenSize": 2532 } } セッショントークンの使用率のモニタリングに適切なフィールドを使用する 。AWS STS は下位互換性のために、セッション発行 API のレスポンスと CloudTrail のレコードで引き続き PackedPolicySize を返します。このフィールドは現在、 SessionTokenUtilization と同じ値 (4,096 バイトのセッショントークンサイズの制限に対してトークンが占める割合) を報告します。そのため、トークンの内容が変わっていなくても、 PackedPolicySize の値が以前より低く表示される場合があります。 SDK で SessionTokenUtilization が公開されている場合は、フィールド名が値の現在の意味と一致しているため、こちらを使用してください。古い SDK で SessionTokenUtilization が公開されていない場合は、 PackedPolicySize を使用すれば、SDK を更新せずに同じ使用率をモニタリングできます。バイト単位のトークンサイズについては、 SessionTokenSize をモニタリングすることをお勧めします。 まとめ AWS のセッションで、セッションタグ、タグ値、セッションポリシーに使用できる容量が拡大しました。AWS STS は 4,096 バイトという単一のセッショントークンの制限を適用し、トークンが制限を超えた場合にはよりわかりやすいエラーメッセージを返します。また、トークンサイズが報告されるため、サイズの増加を早い段階で把握できます。 MinimumSessionTokenSize でトークンを処理するシステムを検証し、 SessionTokenUtilization と SessionTokenSize をモニタリングして、継続的に状況を把握してください。 参考資料 AWS STS API リファレンス 一時的なセキュリティ認証情報をリクエストする セッションポリシー AWS STS でセッションタグを渡す Rishi Tripathy Rishi は、AWS Identity and Access Management (IAM) チームの Principal Product Manager です。企業が AWS 環境を大規模に保護するためのアクセス制御の仕組みに注力しています。導入しやすく、設定ミスが起こりにくいセキュリティプリミティブの構築に情熱を注いでいます。 Tanmay Baid Tanmay は、AWS Identity and Access Management (IAM) チームの Senior Software Development Engineer です。お客様が大規模に AWS へアクセスする際に利用する認証情報とトークンを支える中核的なアイデンティティシステムの開発に携わっています。分散システム、アイデンティティ、セキュリティが交差する領域の難しい課題に取り組むことを楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 9 月 14 日に公開された AWS Blog “ Zero operator access for self-managed databases using EC2 instance attestation ” を翻訳したものです。 セルフマネージド型データベースには、プライベートキーや認証情報から、個人を特定できる情報 (PII)、金融取引に至るまで、組織にとって最も機密性の高いデータが保存されていることがよくあります。コンプライアンスや規制の要件が課されるセキュリティ重視のアプリケーションでは、ホストへのアクセス権を持つ者がこうしたデータにアクセスするリスクを許容できません。そのため、ホスト上でゼロオペレーターアクセス (ZOA) の実現を目指します。 この記事では、完全に再現可能な ZOA 環境で、ステートフルなデータベースを設計し、実装する方法を説明します。この環境は、 Amazon Elastic Compute Cloud (Amazon EC2)、EC2 インスタンス構成証明 、 Nitro Trusted Platform Module (NitroTPM)、および Attestable AMI によって実現します。これらの機能を利用すると、 Linux Unified Key Setup ( LUKS ) で暗号化された Amazon Elastic Block Store (Amazon EBS) ボリュームの対称キーを、特定の Amazon Machine Image (AMI) の暗号学的な測定値に紐付けることができます。その結果、EC2 インスタンスは、正しい Attestable AMI で起動された場合にのみストレージを復号できるようになります。この Attestable AMI で想定されるブート測定値は、AMI のビルド時にあらかじめ算出されています。 ここでは PostgreSQL をワークロードの例としてこの手法を紹介しますが、同じパターンは、AI モデルの重みや独自のアルゴリズムなど、暗号化されたデータにアクセスできるワークロードを厳格に制限するガードレールが必要なあらゆるユースケースに適用できます。 前提条件とデプロイ 始める前に、以下の内容を理解しておいてください。 Nix Flakes : Nix Flakes は、完全に自己完結型のビルドフレームワークです。 flake.nix ファイルでシステム全体 (カーネル、パッケージ、サービス、構成) を宣言的に定義し、 flake.lock ファイルですべての入力を特定の git コミットハッシュに固定します。これにより、内容がソースコードによって完全に決まる、ビット単位で再現可能な AMI イメージを生成できます。 Linux のブートプロセス : Unified Kernel Image (UKI) 、 dm-verity (読み取り専用ファイルシステムの整合性確保用)、および LUKS (暗号化ボリューム用)。 TPM/PCR の概念 : Platform Configuration Register (PCR) がブート測定値を蓄積する仕組みと、PCR を偽造できない理由。 AWS のサービス : EC2 、 AWS KMS 、 EBS 、および IMDS 。KMS キー、EC2 インスタンス、EBS ボリューム、 AWS Identity and Access Management (IAM) ロール を作成する権限を持つ AWS アカウント が必要です。 プロビジョニングスクリプトや NixOS ベースのイメージビルドを含む完全なリファレンス実装は、 https://github.com/aws/nitrotpm-attestation-samples リポジトリで公開されています。 適切な AWS コンフィデンシャルコンピューティングソリューションの選択 AWS Nitro Enclaves は、ステートレスなワークロード向けとして広く利用されているコンフィデンシャルコンピューティング機能です。ただし、Nitro Enclaves は厳格に分離された環境で動作し、永続ストレージを持たず、ネットワーク機能も vsock チャネル経由に限られます。EBS ボリュームへの直接アクセス、高いスループット、永続的な状態を必要とするデータベースワークロードをエンクレーブ上に構築しようとすると、これらの制約を回避するために多大なエンジニアリング作業が必要になります。 EC2 インスタンス構成証明は、ハードウェアとネットワークへの完全なアクセスを維持したまま、信頼できるソフトウェアとブートプロセスのみがインスタンス上で実行されていることを暗号学的に証明します。Nix Flakes のような再現可能なビルドシステムと組み合わせることで、データベースに求められるストレージの特性やパフォーマンスを犠牲にすることなく、ゼロオペレーターアクセスを実現できます。 ZOA データベースのユースケースには、EC2 インスタンス構成証明が適しています。必要な機密性を確保しながら、暗号化された EBS ボリュームのマウント、高いスループットでのクエリ処理、標準的なネットワークでの運用をこれまでどおり行うことができます。 再現可能な Attestable AMI の構築 このセクションでは、Nix Flakes を使用して、完全に再現可能で構成証明可能な AMI を構築する方法を詳しく説明します。図 1 は、再現可能で構成証明可能な AMI を構築するために必要な 5 つの大まかなステップを示しています。 図 1: Amazon EC2 インスタンス構成証明 (ビルド時のみ)。再現可能な AMI を作成し、その参照測定値を生成します。 1. Nix ビルド : ロックされた flake の入力から決定論的にビルドを行い、AMI の raw イメージを生成します。このイメージは、ESP (UKI)、 dm-verity ハッシュツリー、 nix store (erofs、読み取り専用) で構成されます。入力が同じであればビット単位で同一の AMI が生成されるため、 PCR4 測定値も同じになります。 2. dm-verity によるストアの紐付け : UKI の cmdline には、 nix store に対するマークルツリー (Merkle Tree) のルートハッシュが含まれます。ビルド後にストアを変更するとルートハッシュが変わり、その結果 PCR4 も変わります。オプションとして、ビルド後に UKI に署名してセキュアブート署名を追加することもできます。テンプレートでは --secure-boot フラグを使用してこの処理を行っています。 3. nitro-tpm-pcr-compute : このビルド時ユーティリティは、UKI の .efi ファイルのみを読み取り、測定アルゴリズムをオフラインで再現して PCR 値を算出します。PCR 値は 96 文字の SHA-384 ダイジェストで表されます。 4. 参照測定値 : このツールは tpm_pcr.json を出力します。 PCR4 (Boot Manager Code): UEFI 環境が実行するブートバイナリのハッシュです。Attestable AMI では、このハッシュが 構成証明ドキュメント に追加され、AWS KMS キーポリシーに設定された PCR4 値と一致するかどうかを AWS KMS が評価します。これにより、KMS キーを利用できるコードを PCR4 で厳密に固定できます。 PCR7 (Secure Boot Policy、セキュアブートが有効な場合のみ): UEFI セキュアブートポリシーのハッシュです。この値は AMI を更新しても変わらないため、特定の AMI の測定値ではなく、セキュアブート証明書を検証する AWS KMS ポリシーを 1 つ記述するだけで済みます。 PCR12 : カーネルコマンドラインに加えられた変更 (アドオンファイルによる変更など) のハッシュです。 PCR4 と組み合わせて、コマンドラインが改ざんされていないことを確認するために使用します。 5. AWS Key Management Service (AWS KMS) キーポリシーへの組み込み : 参照測定値を RecipientAttestation 条件として設定します。これにより AWS KMS は、 実際の 測定値が一致するインスタンスに対してのみキーを提供するようになります。 それでは、図 1 に示した各ステップの実装の詳細を見ていきましょう。ステップ 1 と 2 に対応する処理として、まず Linux カーネル、カーネルコマンドライン、initramfs、一部のメタデータを含む、強化された Unified Kernel Image (UKI) をビルドします。 ビルドには Nix を使用することをお勧めします。Nix を使用すると、ビルドを宣言的かつ再現可能にできます。ロックされた同じソースからは常にバイト単位で同一の UKI が生成されるため、PCR4 測定値も常に同じになります。図 1 のステップ 3 と 4 のとおり、ビルドでは raw イメージとともに tpm_pcr.json ファイルが出力されます。 { "Measurements": { "PCR4": "f3a1e2...", "PCR7": "a32b31...", "PCR12": "000000..." } } 管理下にある Attestable AMI の PCR 測定値を持つ EC2 インスタンスにのみ AWS Key Management Service (AWS KMS) キーでの復号を許可するため、参照測定値を使用して AWS KMS キーポリシー を設定します。 { "Sid": "Allow decryption for the Instance role", "Effect": "Allow", "Principal": { "AWS": "${INSTANCE_ROLE}" }, "Action": [ "kms:Decrypt" ], "Resource": "*", "Condition": { "StringEqualsIgnoreCase": { ${PCR_VALUES} } } } AWS KMS キーポリシーの JSON オブジェクト内にある ${PCR_VALUES} には、ビルド中に生成された tpm_pcr.json の測定値が入ります。 ここで重要なのは、インスタンス構成証明によって暗号学的に検証された AMI にのみ復号オペレーションを許可する唯一の制御点が、AWS KMS キーポリシーであるという点です。そのため、PCR 値は CI/CD パイプラインで自動更新するのではなく、慎重な手動プロセスで固定し、レビューする必要があります。自動更新を行うと、変更されたイメージや未承認のイメージが気付かないうちに許可され、構成証明による保証がすべて無効になるおそれがあります。 この例では、PostgreSQL データベース用の AMI を作成して、その PCR 測定値を取得します。そして、その測定値を使用して AWS KMS を設定し、正しい測定値で構成証明に成功した場合にのみ、データベースの EBS ボリュームのキーを復号できるようにします。それでは、Nix を使用して記述的かつ再現可能な形で実現できる、具体的なポイントをいくつか見ていきましょう。 ゼロオペレーターアクセス ゼロオペレーターアクセスを強制して不正アクセスの攻撃対象領域を限定するために、SSH やシリアル接続によるアクセスを含め、マシンへのあらゆる形式のログインを無効にします。 services.sshd.enable = lib.mkForce false; また、次の設定も行います。 systemd.services."autovt@" = lib.mkForce {}; systemd.services."getty@" = lib.mkForce {}; systemd.services.getty-static = lib.mkForce {}; systemd.services."serial-getty@" = lib.mkForce {}; ファイアウォールとインスタンスメタデータサービス (IMDS) の制御 さらに、インバウンド通信を PostgreSQL に必要なポート 5432 のみに制限し、 インスタンスメタデータサービス (IMDS) へのアウトバウンドアクセスを kms-init サービスにのみ許可できます。EC2 インスタンスで実行されるサービスが新しい一時的な AWS 認証情報を取得するには、IMDS へのアクセスが必要です。 networking.firewall = { # Allow inbound PostgreSQL connections over mTLS allowedTCPPorts = [ 5432 ]; # IMDS access control - only kms-init user can reach IMDS extraCommands = " # Allow kms-init service to access IMDS for KMS operations ${pkgs.iptables}/bin/iptables -A OUTPUT -d 169.254.169.254 -m owner --uid-owner kms-init -j ACCEPT [...]"; }; 読み取り専用ファイルシステムの測定 エフェメラルなルートファイルシステム ( tmpfs 、ディスクや永続ストレージを使用しない) を / に配置します。 "/" = { fsType = "tmpfs"; options = ["mode=0755"]; }; 一方、実際のアプリケーションデータ (例えば postgres バイナリ) は /dev/mapper/usr に格納され、 /usr に読み取り専用でマウントされます。 "/usr" = { device = "/dev/mapper/usr"; # explicitly mount it read-only otherwise systemd-remount-fs will fail options = ["ro"]; fsType = config.image.repart.partitions.${partitionIds.store}.repartConfig.Format; }; ここで注意が必要なのは、 /dev/mapper/usr は UKI に含まれないという点です。そのため、NitroTPM の測定値 (UKI のビルド時に算出する PCR 値) は、/dev/mapper/usr に保存したデータと直接紐付いていません。 この状態は望ましくありません。権限のないユーザーがこの領域にアクセスできた場合、例えば postgres バイナリを改ざんされたビルドに置き換えることで、データベースの整合性と機密性を損なう可能性があるためです。 マウントされた /dev/mapper/usr ( /usr にマウントされ、 nix store を含む) の内容が想定どおりで変更されていないことを検証するため、 Linux dm-verity を使用してこの領域を PCR 測定値に紐付けます (図 1 のステップ 2 を参照)。Attestable AMI のビルド時に、 /dev/mapper/usr 全体の マークルツリー を計算し、そのルートハッシュをカーネルブートパラメータとして渡します。 カーネルコマンドラインはビルド時に UKI に埋め込まれ、バイナリ全体を対象とする PCR4 の測定範囲に含まれます。カーネルコマンドラインには systemd.verity_root_options=panic-on-corruption が含まれているため、 dm-verity が /usr パーティションで破損を検出すると、改ざんされたコードを実行する代わりにカーネルパニックが発生し、インスタンスが再起動します。 セキュアブートのバリエーション ユースケースによっては、Attestable AMI を定期的に再ビルドしたり、異なるアプリケーションの Attestable AMI に同じポリシーを適用したりする必要があります。AMI への変更は PCR4 測定値に反映されるため、AWS KMS キーポリシーを PCR4 値で制御すると、AMI を変更するたびにキーポリシーも更新しなければなりません。これが運用上望ましくない場合は、代わりにセキュアブートを有効にし、その結果得られる PCR7 測定値にポリシーを紐付けることができます。 PCR7 はセキュアブートの状態を表す測定値で、UKI の署名者のアイデンティティが含まれます。つまり、Attestable AMI のビルド時にセキュアブートを有効にし、事前に定義したキーで署名すれば、AWS KMS へのアクセスを PCR7 測定値のみで制御できます (ポリシーから PCR4 と PCR12 を除外)。これにより、Attestable AMI と、それを実行する EC2 インスタンスのフリート全体を 1 つのポリシーでカバーできます。 ブート時の信頼チェーン 次に、ブート時に信頼チェーンがどのように評価されるかを見ていきましょう。図 2 は、EC2 のブート中に NitroTPM、Attestable AMI、AWS KMS の間で信頼チェーンが確立されるまでの 8 つのステップを示しています。 図 2: Amazon EC2 インスタンス構成証明のブート時の信頼チェーン。Attestable AMI 内の systemd サービスが、ブート時に暗号化されたキーの取得、復号、EBS ボリュームのロック解除、マウント、データベースの起動を連携して実行します。 0. UEFI による UKI の測定 : ブート時に AWS Nitro ファームウェアが ESP から UKI をロードし、NitroTPM の PCR を拡張します。実行される UKI は PCR4 に、cmdline (すべてゼロ) は PCR12 に、セキュアブートキー (オプション) は PCR7 に反映されます。 1. 構成証明のリクエスト : network-online になると、NitroTPM が発行した構成証明ドキュメント (実際の PCR 値を含む) が kms-init に渡されます。 2. ユーザーデータの取得 : kms-init が インスタンスメタデータサービス (IMDS) のユーザーデータから暗号化されたキーを読み取ります。 3. AWS KMS での復号 : kms-init が、署名された構成証明ドキュメントと暗号文を AWS KMS に送信します。AWS KMS は実際の測定値と参照測定値を比較し、一致した場合は対称キー ( tmpfs にのみ保持) を返します。 4. luks-unlock : 対称キーを使用して、Linux の cryptsetup で LUKS EBS ボリュームのロックを解除し、暗号化されたボリュームを読み書きできるようにします。 5. cert-init (並列) : 同じキーを使用して、PostgreSQL の Transport Layer Security (TLS) 用のサーバー証明書バンドルを復号します。 6. data.mount : ステップ 4 でロックを解除した ext4 ボリュームを /data にマウントします。これは、 tmpfs (エフェメラル) 以外で唯一の書き込み可能なボリュームです。 7. postgresql : cert-init が用意した TLS 証明書を使用して起動します。 dm-verity で保護された nix store から実行され、 /data/postgresql に対して読み書きを行います。 ブート時に同じキーを TLS サーバーアイデンティティにも活用 次に、AWS KMS で保護された対称キーを使用して、ブート時に機密情報を管理する方法を見ていきましょう。 ブートチェーンで提供される対称キーは汎用的なものです。プロビジョニング時にこのキーで暗号化したアーティファクトであれば、同じ構成証明済みのブートで復号できます。リファレンス実装では、この特性を利用して、AMI の測定値に紐付けられた PostgreSQL 用の TLS サーバーアイデンティティもプロビジョニングしています。認証局 (CA)、サーバー証明書、サーバーのプライベートキーを tarball にまとめ、同じ対称キーで暗号化したうえで、データベースの暗号文とともに EC2 ユーザーデータに埋め込みます。 cert-init.service は、Attestable AMI 内でこのバンドルを tmpfs ディレクトリに復号します。PostgreSQL は clientcert=verify-full を強制した状態でポート 5432 で接続を受け付け、同じ CA によって署名された証明書を持つクライアントとの間で相互 TLS を確立します。 リファレンス実装のビルドとデプロイ リファレンス実装は、そのままエンドツーエンドで実行できます。 --secure-boot や --debug など、利用可能なデプロイオプションの詳細については Readme を参照してください。 リポジトリをクローンし、そのディレクトリに移動します。 git clone https://github.com/aws/nitrotpm-attestation-samples && cd nitrotpm-attestation-samples 十分な IAM 権限があることを確認します。必要な権限は、 Readme の「 Minimal IAM Privileges 」セクションに記載されています。 リポジトリ内で次のコマンドを実行します。AWS リソースがプロビジョニングされ、セキュアブートと secrets-manager を使用して、構成証明済みの LUKS 暗号化ボリューム上で PostgreSQL を実行する EC2 インスタンスが起動します。 cd nix/examples/postgres-kms ./scripts/e2e-test.sh --secure-boot --secrets-manager --authorize-my-ip --create-roles --no-cleanup クリーンアップ この例で作成したすべての AWS リソースを削除するには、次のコマンドを実行します。 ./scripts/clean.sh まとめ この記事では、Amazon EC2 インスタンス構成証明を使用して、ゼロオペレーターアクセスを実現する PostgreSQL 用の Attestable AMI を再現可能な形でビルドするプロセスについて説明しました。また、NitroTPM ベースのブート検証プロセスと、ブートに成功した後に暗号化された EBS ボリュームをマウントする方法についても詳しく解説しました。さらに、PCR 測定値を使用して AMI への変更を検出し、EC2 インスタンスのブートを阻止するとともに、改ざんされたコードが AWS KMS での復号に必要な権限を取得できないようにする方法も紹介しました。 さっそく nitrotpm-attestation-samples リポジトリをクローンし、ニーズに合わせてテンプレートをカスタマイズして、Attestable AMI によるデータ保護を始めましょう! 著者について David-Paul Dornseifer David-Paul は AWS の Confidential Compute and Systems Architect です。デジタル資産のカストディ、コンフィデンシャル推論、低レイテンシーの取引インフラストラクチャを専門としています。 Ben Liderman Ben 氏は Fireblocks のシステムアーキテクトです。コンフィデンシャルコンピューティングを活用して高価値なデジタル資産の運用を保護する、セキュアな金融インフラストラクチャの設計に携わっています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 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 Authorit y (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 を使用します。この違いによって、どのコントロールが有効かが決まります。 kms:KeySpec : キーの KeySpec プロパティを反映します。この条件キーは、 CreateKey (リクエストされたキー仕様) と、特定のキーに対して実行される AWS KMS キーリソースオペレーション ( Sign 、 Verify 、 GetPublicKey など) の両方で評価されます。そのため、 kms:KeySpec は ML_DSA_44 を ML_DSA_65 や ML_DSA_87 と区別でき、ML-DSA-44 キーの作成の防止と既存キーの使用の制限の両方で信頼できる手段となります。 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 を使用してその使用をさらに制限できます。 SCP を使用した組織レベルおよびアカウントレベルのブロック 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 とその目的を社内で文書化しておいてください。 AWS KMS での ML-DSA-44 キー作成の防止 (プリンシパルレベル) 次の 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" } } } ] } 重要なポイント 条件の値は ML_DSA_44 です (ハイフンではなくアンダースコア)。 このポリシーがブロックするのは CreateKey だけです。プリンシパルレベルで既存の ML-DSA-44 キーの使用もブロックするには、 Sign 、 Verify 、 GetPublicKey の拒否を追加してください。この拒否は 「既存の ML-DSA-44 キーの使用の制限」 セクションで紹介しています。 上書きできない包括的な保護を実現するには、プリンシパルレベルのポリシーだけに頼らず、SCP としてデプロイしてください。 IAM のアクセス許可の境界 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) を使用します。 既存の ML-DSA-44 キーの使用の制限 「背景」セクションで説明したように、 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": "*"} 、またはより具体的なプリンシパル) を追加し、それ以外はそのままにします。 その他のアプローチ 目的によっては、使用を拒否するだけでなく、キーマテリアル自体を削除したい場合もあるでしょう。ただし、何らかの方法で追跡していない限り、特定のキーでどのデータが署名されたかを把握するのは困難です。使用済みのキーを削除すると、署名を検証できなくなります。キーを削除する前に、そのキーが使用されていないことを慎重に確認してください。 キーを無効化するか、削除をスケジュールします。 無効化するとキーの使用が直ちに停止し、後から元に戻すこともできます。キーの削除は、待機期間の経過後に確定し、元に戻せなくなるため、削除をスケジュールする前に十分に確認してください。 特定のキー ARN を指定して Sign 、 Verify 、 GetPublicKey を拒否します。 キー仕様全体ではなく、特定のキーだけを対象にできます。そのためには、IAM ポリシーの Resource 要素に対象のキー ARN を列挙します (条件キーは不要です)。この方法は特定のキーだけを対象にする場合には効果的ですが、キー ARN のリストを維持するのは手間がかかります。この方法は必要な場合に限って使用してください。なお、キー ARN を指定した IAM ポリシーを検討している場合は、対象キーのキーポリシーに Deny を記述しても同じ目的を達成でき、その拒否はキー自体にアタッチされることを覚えておいてください。 既存のキーの検索 (無効化または削除する場合にのみ必要)。 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 承認済み ML-DSA バリアントと AWS Private CA の制御 AWS Private CA では、CA の作成時に CertificateAuthorityConfiguration パラメータを CreateCertificateAuthority に指定して、CA の署名アルゴリズムを設定します (有効な値には ML_DSA_44 、 ML_DSA_65 、 ML_DSA_87 などがあります)。現在、アルゴリズムに対応する条件キーはないため、SCP で署名アルゴリズムを強制することはできません。このセクションで紹介するアプローチでは、CA を作成できるプリンシパルを制御し、その信頼されたパスでアルゴリズムを固定したうえで、 AWS CloudTrail を利用した検出で補完します。 推奨されるアプローチ CA を作成できるプリンシパルを制限します。 SCP で acm-pca:CreateCertificateAuthority を広く拒否し、少数の信頼されたロールや承認済みのプロビジョニングパイプラインにのみ許可します。これにより、任意のプリンシパルが未承認のアルゴリズムで CA を立ち上げることができなくなります。 信頼されたパスでアルゴリズムを固定します。 承認済みのパイプラインや IaC テンプレートで、 SigningAlgorithm を ML_DSA_65 または ML_DSA_87 として CertificateAuthorityConfiguration 内にハードコードします。AWS Private CA にはアルゴリズムの条件キーがないため、このプロビジョニングパスがアルゴリズムを強制する箇所になります。なお、CA のアルゴリズムで固定されるのは、その CA が発行する証明書の署名です。各証明書のサブジェクトキーは CSR から取得され、AWS Private CA はそのアルゴリズムを検証せずにそのままコピーします。そのため、同じ発行パイプラインで CSR のキーアルゴリズムも固定してください。 信頼チェーンを制御します。 PKI 側では、承認済みの CA のみをトラストストアと発行階層に追加し、ML-DSA-44 の証明書を発行する可能性がある CA を信頼したり、下位 CA として配置したりしないでください。これにより、未承認の CA が信頼されたパスに入り込むのを防止できます。 ドリフトを検出します。 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 内に記述してください。 NLB と ALB の TLS での ML-DSA-44 の使用の防止 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 のリスクへの緩和策ではなく、将来を見据えた多層防御です。 証明書のコントロール (ML-DSA-44 に有効な仕組み) リスナーの API コールでは証明書を ARN でしか参照しないため、 CreateListener 、 ModifyListener 、 AddListenerCertificates に対して、証明書のアルゴリズムを検査する SCP を記述することはできません。IAM の条件では、別途参照されるリソースの属性を参照できないためです。したがって、TLS から ML-DSA-44 を排除するには、関連付け可能な ML-DSA-44 の証明書マテリアルをそもそも存在させないことが前提となります。 プライベート CA が ML_DSA_65 または ML_DSA_87 の証明書のみを発行するように設定し、CA を作成できるプリンシパルを制御します。 AWS KMS で ML-DSA-44 キーの作成を防止し、AWS KMS で保持している ML-DSA-44 キーが証明書のサブジェクトキーにならないようにします。なお、ACM が発行した証明書や、インポートまたはアップロードされた証明書の TLS サーバーキーは KMS キーではないため、項目 1 と 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 のリソース評価を使用してください。 TLS のまとめ 主な予防的コントロールは、証明書マテリアルそのものの管理です。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-44 キーの作成をブロックする (組織全体、または組織の OU 内のすべてのアカウント) SCP で kms:CreateKey を制限。条件キー: kms:KeySpec 条件キーで完全にサポート ML-DSA-44 キーの作成をブロックする (アカウント単位またはロール単位) IAM ポリシーまたはアクセス許可の境界。条件キー: kms:KeySpec サポート (境界をプログラムで強制する必要あり) 既存の ML-DSA-44 キーの使用をブロックする 拒否対象: Sign 、 Verify 、 GetPublicKey 。条件キー: kms:KeySpec (キーポリシー、IAM、または SCP)。必要に応じてキーの無効化と削除も実施 サポート。条件キー: kms:KeySpec ( kms:SigningAlgorithm は不可) Private CA で承認済みバリアントのみを許可する CA を作成できるプリンシパルを制限。プロビジョニングパスで ML_DSA_65 または ML_DSA_87 を固定 アルゴリズムの条件キーなし。プロセスと検出で強制 インポートまたはアップロードされた TLS 証明書のバリアントを制限する プロセスによる制御、またはインポートやアップロードの API を拒否 ( iam:UploadServerCertificate ではなく ACM を推奨) API はアルゴリズムを認識しない Network Load Balancer (NLB) と Application Load Balancer (ALB) の TLS で ML-DSA-44 の使用をブロックする TLS ポリシーを制限。条件キー: elasticloadbalancing:SecurityPolicy 。証明書マテリアルを制御 TLS ポリシーの制限はサポート。証明書ごとのアルゴリズム条件はなし 未承認のバリアントの使用を検出する CloudTrail (API レベル) と AWS Config のカスタムルール AWS Config のカスタムルールでサポート (マネージドルールは非対応) まとめ この記事では、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 Harshvardhan Chunawala Harshvardhan は AWS のソリューションアーキテクト兼セキュリティ SME で、Amazon Leo、Amazon Security、AWS Agentic AI と連携したチーム横断的な取り組みを主導しています。クラウドセキュリティ分野で 10 年以上の経験を持つ Golden Jacket 受賞者であり、カーネギーメロン大学ではアドバイザリーボードメンバー、客員教員、研究者も務めています。世界中の経営幹部、エンタープライズのリーダー、スタートアップの創業者に対して、安全でスケーラブルなクラウドプラットフォームの構築について助言しています。 Blake Roberts Blake Roberts は AWS のシニアソリューションアーキテクトで、AWS Security Technical Field Community のメンバーです。英国の公共部門のお客様が直面するセキュリティの課題や疑問の解決を支援しており、ポスト量子暗号、脅威の検出とインシデント対応、戦略レベルでのガバナンスなど、幅広い分野をカバーしています。AWS に入社する前は、英国陸軍に 9 年間勤務していました。大の読書家であり、熱心なランナーでもあります。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。