本ブログは 2026 年 10 月 12 日に公開された AWS Blog “ GuardDuty Extended Threat Detection has added five new indicators to surface attack sequences ” を翻訳したものです。 Amazon GuardDuty 拡張脅威検出 は、弱い GuardDuty シグナルの組み合わせが信頼性のしきい値を超えると、それらを相関付けて、重要度が Critical の単一の攻撃シーケンスの検出結果にまとめます。2026 年 5 月 20 日から、攻撃シーケンスに 5 種類の新しいインジケーター ( MALICIOUS_PACKAGE 、 MISCONFIGURATION 、 REACHABILITY 、 SENSITIVE_DATA 、 VULNERABILITY ) が付与されるようになりました。詳細については、「 Document history for Amazon GuardDuty 」および「 Attack sequence finding details 」を参照してください。 これらのインジケーターの情報源は、 Amazon Inspector 、 Amazon Virtual Private Cloud (Amazon VPC) Reachability Analyzer 、 Amazon Macie 、そして AWS Security Hub を通じて提供されるポスチャデータです。これらのサービスを既に別の目的で利用しているお客様もいるでしょう。今回のアップデートにより、拡張脅威検出はこれらのサービスのシグナルを攻撃シーケンスの検出結果に取り込むようになりました。この記事は、前提条件となるサービスを既に利用しているチーム向けの運用ガイドです。新しいインジケーターが検出結果にどのように表示されるか、リリース後のデータから何がわかるか、そしてインシデント対応ワークフローにどう組み込むかについて説明します。これらのインジケーターにより、拡張脅威検出はアカウント内で最も優先すべきシグナルを判断しやすくなります。その結果、 Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon Elastic Container Service (Amazon ECS) 、 Amazon Elastic Kubernetes Service (Amazon EKS) のランタイムアクティビティをモニタリングするアクティブディフェンス戦略の一環として、ワークロード領域でより信頼度の高い検出結果が得られます。 新しいインジケーターの概要 GuardDuty におけるシグナルとは、GuardDuty が不審なアクティビティを探す際に評価するあらゆるイベントを指します。弱いシグナルとは、それ単体では脅威を明確に示さないシグナルのことで、5 つの新しいインジケーターはこれに該当します。例えば、ホスト上で Common Vulnerabilities and Exposures (CVE) が 1 件検出されたとしても、それは脆弱性が存在することを示すだけで、攻撃者がその脆弱性を悪用していることを示すわけではありません。次の表に示すように、これらの検出結果は、GuardDuty が既に追跡している不審なアクティビティのシグナルと相関付けられることで、初めて価値を発揮します。 インジケーター ソース 示される内容 VULNERABILITY Amazon Inspector Common Vulnerability Scoring System (CVSS) の重要度と Exploit Prediction Scoring System (EPSS) の悪用可能性スコアを含む CVE のリスト。 MALICIOUS_PACKAGE Amazon Inspector Amazon Inspector の MAL-* パッケージインジケーター。Amazon Inspector による脆弱性のスコアリング方法の詳細については、「 Amazon Inspector Security Research 」を参照してください。 REACHABILITY Amazon VPC Reachability Analyzer ホストまたはクラスターがインターネットから到達可能かどうか MISCONFIGURATION AWS Security Hub のコントロール (ポスチャ管理) リソースの設定が、AWS または 業界のベストプラクティス に沿っていないこと。例えば、IMDSv1 が有効なままになっている、管理者ポリシーの権限が過剰である、パブリックにアクセス可能な Amazon Simple Storage Service (Amazon S3) バケットがある、などです。 SENSITIVE_DATA Amazon Macie リソース内で機密データと思われる情報が検出されたこと。 これら 5 つの値は、GuardDuty の AWS マネジメントコンソールで攻撃シーケンスの検出結果を開いたときの [インジケーター] タブと、 GetFindings の JSON ファイルに表示されます。 図 1: 攻撃シーケンスの検出結果の [インジケーター] セクション VULNERABILITY インジケーターには EPSS が含まれるため、ここで EPSS について補足しておきます。「 FIRST EPSS overview 」によると、EPSS スコアは、公開済みの CVE が今後 30 日以内に実際の環境で悪用される確率を 0～1 の範囲で表したものです。EPSS は CVSS を置き換えるものではありません。CVSS が脆弱性本来の重要度を表すのに対し、EPSS は近いうちに悪用される可能性の高さを表すため、インシデント対応ではより役立つ数値となります。 前提条件 インジケーターにデータを反映させるには、次の AWS サービスを有効にしておく必要があります。 Amazon Inspector (Amazon EC2 および Amazon EKS で有効化): VULNERABILITY と MALICIOUS_PACKAGE に対応します。 AWS Security Hub : AWS Foundational Security Best Practices に基づいて MISCONFIGURATION を提供します。 Amazon VPC Reachability Analyzer (本番環境の VPC で有効化): REACHABILITY に対応します。 GuardDuty Runtime Monitoring (Amazon EC2、Amazon ECS、Amazon EKS で有効化): 生成されるすべてのシグナルが、相関付けの起点 (アンカー) になり得ます。 Amazon Macie : SENSITIVE_DATA を提供します。 弱いランタイムシグナルの強化 プロセスの呼び出し、ポッドでの exec、システムコールのパターンなどのランタイムシグナルは、ノイズが多くなることがあります。既知の攻撃ツールのパスに一致しないランタイムシグナルは単体では重要な意味を持たず、リソース状態のコンテキストがなければ、通常は重要度が Critical の攻撃シーケンスとなるしきい値に達しません。 新しいインジケーターは、この欠けていたコンテキストを補います。弱いランタイムシグナルが観測されたホストに、優先度の高いパッチ未適用の CVE、既知の悪意のあるパッケージ、IMDS の設定ミス、インターネットからの到達可能性が併存する場合、拡張脅威検出はそれらをまとめて、高い信頼度で重要度が CRITICAL の単一の攻撃シーケンスに昇格させます。個々の GuardDuty ランタイム検出結果については、ノイズの多さが大きな課題であるというフィードバックをお客様から一貫していただいてきました。このリソース状態のコンテキストを加えることで、弱いシグナルが対応可能なアラートへと変わります。 実際に、ランタイムプロセス領域では新規の攻撃シーケンスの検出結果が大幅に増加し、優先順位付けされたランタイムプロセスの攻撃シーケンスのおよそ 4 件に 1 件を占めるまでになりました。一方、ネットワークベースの侵害の痕跡 (IOC) 領域ではほとんど変化はありませんでした。リリース後 1 週間で、このパターンは多くのお客様のアカウントで確認されています。従来は弱く相互に関連のない複数の検出結果としてばらばらに表示されていた攻撃シーケンスが、重要度が CRITICAL の単一の検出結果として表示されるようになったのです。 例: Amazon EKS で新規に検出された攻撃シーケンス 追加のインジケーターによって拡張脅威検出がどのように改善されたかを説明したところで、これらのインジケーターがどのような価値をもたらすかを具体的な例で見ていきましょう。ここでは、Amazon EKS クラスターで実際に観測されたシナリオを分析します。このアクティビティは 8 日間にわたって発生し、11 件の異なる GuardDuty の検出結果が生成されました。 図 2: 拡張脅威検出がシグナルを相関付ける前の EKS クラスターのアクティビティの概要 図 2 に示すように、GuardDuty が 8 日間にアクティビティ領域で観測したのは、55 件の EKS_AUDIT_LOGS シグナル (ポッドでの exec、ロールの引き受け、 AssumeRoleWithWebIdentity の呼び出し) と、18 件の検出結果レベルのシグナルでした。これらはすべて、198.51.100.69 という単一の外部 IP アドレスから発生していました。この IP アドレスから、同じ EKS クラスターに対して 4 つの異なる AWS Identity and Access Management (IAM) アイデンティティによる認証が行われていました。ワーカーノード上のランタイムアクティビティは、既知の攻撃ツールのパスに一致するプロセスがなく、実行プロファイルのフラグも立たなかったため、ありふれたものに見えました。リリース前の相関ロジックでは、このシーケンスを検出するには EKS_MALICIOUS_PROCESS ルールが発動する必要がありました。このルールの発動には、悪意のある exec パスか、異常で疑わしいツールのプロファイルのいずれかが必要です。今回のアクティビティにはどちらも該当しなかったため、相関付けられた攻撃シーケンスの検出結果は生成されませんでした。 新しい GuardDuty 拡張脅威検出のインジケーターによって、この EKS の例に追加された情報は次のとおりです。 MALICIOUS_PACKAGE (クラスター上): Amazon Inspector の識別子 MAL-2022-4933 が検出されています。 VULNERABILITY (Amazon Inspector の全出力、クラスター上): 合計 42 件の CVE があり、そのうち 33 件が CVSS で CRITICAL と評価されています。 クラスター上: CVE-2022-1471 (SnakeYAML のデシリアライゼーション、EPSS 0.94)、CVE-2024-4577 (PHP-CGI の引数インジェクション、EPSS 0.97)、CVE-2024-34351 (Next.js の SSRF)、CVE-2025-29927 (Next.js の認証バイパス)、CVE-2023-44487 (HTTP/2 Rapid Reset)、CVE-2022-37434 (zlib のヒープオーバーフロー、EPSS 0.92) を含む 12 件の CVE があります。 5 つのワーカーノード全体: 合計 379 件の CVE があり、そのうち 68 件が Amazon Inspector によって CRITICAL と判定されています。 REACHABILITY : クラスターの API エンドポイントがインターネットから到達可能で、5 つのワーカーノードのうち 3 つもインターネットから到達可能です。 MISCONFIGURATION (EC2 IMDS): 5 つのワーカーノードすべてで、引き続き IMDSv1 にアクセスできる状態になっています。 これらの追加インジケーターを考慮すると、この一連のアクティビティは単一の AttackSequence:EKS/CompromisedCluster の検出結果として表示されます。重要度は CRITICAL で、データが反映された 4 つのインジケーターすべてが [インジケーター] タブに表示されます。また、 MITRE ATT&CK® の Initial Access (External Remote Services)、Discovery、Persistence へのマッピングも示されます。 図 3: 攻撃シーケンス内の新しい脆弱性インジケーター この検出結果には、ワーカーノードレベルで 100 件を超える Amazon EC2 の CVE が記載されています。CVSS が CRITICAL のものが 1 件、 HIGH のものも多数ありますが、EPSS スコアが低いため、ほとんどは脆弱性の優先度が LOW です。GuardDuty が優先度の高いものを強調表示するため、100 件を超える検出結果を精査してどれから対処すべきかを判断する必要はなく、最も効果の高い箇所に対応作業を集中できます。 例: 暗号資産マイニングと脆弱なホスト 2 つ目の例では、EC2 インスタンスグループのケースを取り上げます。このケースでは、GuardDuty は暗号資産マイニングを示す有力なネットワークベースの検出結果を既に得ていましたが、新しいインジケーターが修復に役立つ追加のコンテキストを提供したことで、インシデント対応を迅速化できました。 図 4: EC2 インスタンスに対する暗号資産マイニング攻撃 複数の EC2 インスタンスが既知の暗号資産マイニングの宛先と通信しており、この宛先は脅威インテリジェンスによって mining/misc としてフラグ付けされていました。ネットワーク IOC の証拠は、それ単体でも十分に強力なものでした。 新しいインジケーターによって追加された観測内容 : VULNERABILITY により、関与した 3 つのインスタンスのうち 2 つで、EPSS が約 0.9 の CVE-2007-4559 (Python tarfile) が示されました。 結果 : AttackSequence:EC2/CompromisedInstanceGroup の検出結果を基に、「 宛先 IP のブロック 」にとどまらない対応が可能になりました。暗号資産マイニングツールが侵入に悪用したと考えられる脆弱性と、それを修復するパッチが示されるため、アウトバウンド接続を遮断するだけでなく、根本的な侵入経路に対処できます。 GuardDuty は EC2 インスタンスグループで暗号資産マイニングが行われている強力な証拠を得ていたため、この攻撃シーケンス自体は脆弱性のコンテキストがなくても生成されていたはずです。ただし、コンテキストが増えることで、トリアージを迅速に行えます。 リリース後 1 週間のサンプルで観測された侵害の痕跡 次の CVE (EPSS スコアは観測当時の値) は、リリース後の最初の 1 週間に新しい拡張脅威検出のインジケーターが付与されたお客様のアカウントのホストで、各インジケーターの検出結果が生成された時点で観測されたものです。EPSS スコアは特定時点の値であるため、今後の検出結果に表示される CVE の優先度は、ここに示す値ではなく、その時点の EPSS に基づきます。 CVE-2024-4577 – Windows 上の PHP-CGI の引数インジェクション。EPSS 0.97 以上。 CVE-2022-1471 – SnakeYAML のデシリアライゼーション。EPSS 0.94。CVSS は Critical。 CVE-2022-37434 – zlib のヒープバッファオーバーフロー。EPSS 0.92。 CVE-2007-4559 – Python tarfile のパストラバーサル。2026 年時点でも EPSS は 0.9 以上。 CVE-2025-29927 – Next.js の認証バイパス。Node ベースのウェブ層で頻繁に検出。 CVE-2024-34351 – Next.js の SSRF。 CVE-2023-44487 – HTTP/2 Rapid Reset。 ランタイムモニタリングでは、侵害されたホストから回収されたマルウェアやツールのアーティファクトに関連する弱いシグナルが検出されました。 HackTool ファミリーの Linux/frp : Fast Reverse Proxy の亜種で、コマンドアンドコントロールトンネルとして使用されていました。Amazon EKS ワーカーノード上では、多くの場合 kuboard-agent や kuboard-agent-server というバイナリに偽装されていました。また、 /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/.../usr/bin/ 配下で、コンテナスナップショットのパスとの一致も観測されました。frp バイナリはコンテナイメージ内とノード上の両方に存在するため、パッチが適用されていない AMI からノードを再構築するだけでは修復として不十分です。 Burp Collaborator のアウトオブバンドのコールバックホスト名が *[.]oastify[.]com 配下で見つかり、パターン <35-char base32>[.]oastify[.]com に一致していました。これらは同じ EKS シーケンス上で frp と同時に観測されており、共有インフラストラクチャ上で 2 つ目のツールまたは別のアクターが活動していた可能性が高いと考えられます。 Amazon Inspector の悪意のあるパッケージインジケーター MAL-2022-4933 が、Amazon EC2 と Amazon EKS の両方のコンテキストで検出されました。 上記のツール関連のシグナルと相関していたアイデンティティとアクセスのパターンは次のとおりです。 単一の外部送信元 IP から、短期間のうちに Amazon EKS、Amazon ECS、Amazon EC2 の別々の領域にまたがって、人間が使用する複数の異なる IAM アイデンティティによる認証が行われていました。これは、新規に検出されるようになった Amazon EKS プロセス関連のクラスで最も多く見られたアイデンティティのシグネチャです。 これらのインジケーターを活用した攻撃シーケンスへの対応 新しいインジケーターによって、既に発生した攻撃シーケンスに対するインシデント対応のランブックが変わるわけではありません。新しいインジケーターが意味を持つのは新規の検出結果であり、それらの検出結果は、ランタイムモニタリング関連のシグナルが強化された領域に集中しています。新規の検出結果には、次のように対応してください。 シーケンスに緊急に対応してください 。 MALICIOUS_PACKAGE と優先度の高い VULNERABILITY が示されている場合、そのホストは侵害されるリスクにさらされてきただけでなく、現在もさらされています。露出しているリソースを封じ込め、脆弱性を修復してください。また、攻撃者にさらされた可能性があるすべての IAM 認証情報、 インスタンスプロファイル 、 IAM Roles for Service Accounts (IRSA) にバインドされたロール をローテーションしてください。 EPSS で重み付けした優先度に基づいてパッチを適用してください 。CVSS の値だけで判断しないでください。検出結果に含まれる優先度の高い VULNERABILITY リストは、既に EPSS の高い CVE に絞り込まれています。 パブリックなリソースを隔離してください 。 REACHABILITY インジケーターで示されたリソースが対象です。悪用可能な脆弱性があり、インターネットから到達可能なホストは、修復のために隔離する必要があります。 さらに詳しい対応方法については、「 Remediating detected GuardDuty security findings 」の修復手順と、GuardDuty の検出結果とアカウントを AI で分析するセキュリティ分析機能である GuardDuty Investigation を参照してください。 まとめ GuardDuty 拡張脅威検出は、セキュリティチームが特に支援を必要とすることが多いランタイムワークロード領域 (Amazon EC2、Amazon ECS、Amazon EKS) で、信頼度の高い攻撃シーケンスの検出結果をより多く提供できます。これは、GuardDuty のアクティビティシグナルと、他の AWS サービスから得られるリソース状態のコンテキストを組み合わせることで実現しています。個々の GuardDuty ランタイム検出結果については、ノイズの多さが大きな課題であるというフィードバックをお客様から一貫していただいてきました。拡張脅威検出は、こうした弱いシグナルを脆弱性、パッケージリスク、到達可能性、設定ミス、機密データの各インジケーターと相関付けることで、ノイズを、重要度が CRITICAL の対応可能な検出結果に変えます。AWS Security Hub、Amazon Inspector、Amazon VPC Reachability Analyzer、Macie、GuardDuty Runtime Monitoring を既に有効にしている場合、新しいインジケーターは攻撃シーケンスの検出結果に自動的に表示されます。これらのサービスをまだ使用していない場合は、新しい GuardDuty 拡張脅威検出のインジケーターと、各サービス自体が提供する価値を活用するために、ぜひ有効化をご検討ください。 この記事に関する質問がある場合は、 AWS re:Post で新しいスレッドを開始するか、 AWS サポートにお問い合わせください 。 Aman Khare Aman は Amazon GuardDuty のシニアソフトウェア開発者です。 拡張脅威検出 の開発に携わり、AWS インフラストラクチャで検出された悪意のある攻撃チェーンをお客様が正確に特定できるよう支援しています。以前は Amazon OpenSearch のパフォーマンスとレジリエンシーに関する取り組みを主導し、クラスターマネージャーのメモリ使用量の 10 分の 1 への削減や、1,000 ノード規模のクラスターの実現などを達成しました。仕事以外では、旅行、アドベンチャーアクティビティ、読書、ボードゲームを楽しんでいます。 Kyle Koeller Kyle は Amazon GuardDuty チームのセキュリティエンジニアで、脅威検出を専門としています。クラウドの脅威検出とオフェンシブセキュリティに情熱を注いでおり、CompTIA Security+、PenTest+、CompTIA Network Vulnerability Assessment Professional、SecurityX の資格を保有しています。仕事以外では、ジムで過ごしたり、ニューヨーク市を散策したりすることを楽しんでいます。 本ブログは 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 の 中島 章博 が翻訳しました。

本ブログは 2026 年 10 月 6 日に公開された AWS Blog “ Responsible AI governance: How AWS positions customers to align with ISO/IEC 42005:2025 ” を翻訳したものです。 生成 AI の導入は パーソナルコンピュータやインターネットの普及を上回るペースで進んでおり 、 2025 年の世界の AI 関連投資額は 5,816 億 9,000 万ドルに達しています 。こうした状況の中、組織は AI を責任ある形で活用して業務を強化できるよう、従業員の体制を整える必要があります。AI Adoption Initiative に所属する研究者らは、 従業員は AI イノベーター、ファシリテーター、ユーザーで構成される AI Labor Stack (AI 労働スタック) を通じて AI とかかわっていると論じています。さらに、ファシリテーターは「企業、業界、公共サービス全体で、AI の能力を実際のデプロイにつなげる」役割を担っているにもかかわらず、各国の AI 戦略では「欠けている中間層」となっていることが多いと指摘しています (Ferrone et al., 2026)。 AWS は、国際規格 ISO/IEC 42005:2025 のレビューを通じて、このファシリテーター層が組織内で AI ガバナンスへの体系的なアプローチを導入または改善できるよう支援します。その一環として、AI 影響評価を組織のより広範なガバナンスのエコシステムへ効率的に統合する方法について、この規格が示すガイダンスを考察します。 規格に基づくガバナンスフレームワークは、今後に向けた実践的な道筋を示すものであり、AWS はこうしたフレームワークを実際に活用できるものにするための投資を行ってきました。Amazon は、 国際標準化機構 (ISO) による AI リスク管理の規格策定プロジェクトを支持してきました。複数の AI サービス (Amazon Bedrock、Amazon Q Business、Amazon Transcribe、Amazon Textract) で認証を取得するとともに、お客様にも自社サービスの認証にこれらの規格を活用していただくよう推奨しています。 Amazon Web Services (AWS) は、ISO/IEC 42005 やその他の責任ある AI のベストプラクティスに沿ったガバナンス業務を支援するツールを提供しています。具体的には、「 AWS における ISO/IEC 42001:2023 AI マネジメントシステム (AIMS) 実装ガイド 」や、お客様が企業のリスク管理エコシステムでこの規格を活用する際に役立つ「 Well-Architected Framework: Responsible AI Lens 」があります。本記事では、AI システム影響評価とは何か、全社的なリスク管理をどのように改善するのか、そして ISO/IEC 42005 が AI システム影響評価のベストプラクティスをどのように体系化しているのかを解説します。 AI システム影響評価 AI システム影響評価とは、AI システムを開発、提供、または使用する組織が、組織、個人、コミュニティ、グループ、社会への影響を検討するための、文書化された AI システムのリスク特定プロセスです。また、AI システム影響評価プロセスでは、プライバシーへの影響、差別的な影響、パフォーマンスへの影響の特定といった成果を、組織のリスク管理の意思決定に反映します。このプロセスを活用することで、組織は特定したリスクの管理に適したガードレールを選択し、AI のデプロイを責任を持って管理できます。 AI 影響評価による全社的なリスク管理の促進 AI システム影響評価は、組織全体のリスク管理プロセスに不可欠な要素です。ISO/IEC 42005 は、AI システム影響評価を企業内の既存の影響評価プロセスに統合する方法について、明確なガイダンスを提供しています。多くの企業では、IT システムを対象としたさまざまな種類の影響評価 (リスク、プライバシー、サイバーセキュリティなど) が既に実施されています。 十分に整備された影響評価のエコシステムを持つ組織向けに、ISO/IEC 42005 の附属書 D では、影響評価を簡素化して重複を避けるためのプロセスを示しています。これにより、AI システム影響評価で必要となる関連レビュー (リスク、法務、セキュリティ、プライバシー、調達、アーキテクチャなど) を調整しやすくなります。 AI 影響評価を単独で実施したい組織向けには、ISO/IEC 42005 の附属書 E で、独立した形での評価実施にすぐに使えるテンプレートが提供されています。 ISO/IEC 42005 による AI ガバナンスプロセスとの連携 ISO/IEC 42005 を活用することで、お客様はより統合された AI ガバナンスプロセスを実現できます。具体的には、この規格では、AI システム影響評価の内容の策定方法と実施方法、AI ライフサイクルのどの段階で評価を組み込むべきか、そして評価プロセスとその結果の文書化方法についてのガイダンスを提供しています。 反復可能で拡張性のある AI システム影響評価プロセスの構築 AI システム影響評価の実施と文書化について、構造化された一貫性のあるアプローチを確立したいお客様は、ISO/IEC 42005 のガイダンスを参考にできます。この規格は、評価のライフサイクル全体 (スコーピングと実施、分析と報告、継続的なモニタリングとレビューなど) を網羅しています。また、AI システム影響評価をいつ実施すべきか、どの程度包括的に行うべきか、再評価のトリガーをどのように設定するかについても示しています。 より広範な AI 開発ライフサイクルに合わせて評価と再評価のタイミングを設定する際、この規格では、再評価が必要になる可能性を示すトリガーを (外部要因と内部要因の両方を考慮して) 検討することを推奨しています。例えば、適用される法的要件、契約上の義務、社内ポリシー、顧客の期待、再評価が必要となる可能性のある変更 (AI システム、その運用環境、またはそのコンテキストに対する変更)、その他の要因などです。また、本格的な評価や再評価に着手する前に、より軽量な AI システム影響評価のトリアージを実施する方法も説明しています。トリアージとは、(リスクのレベルに応じて) より包括的な評価が必要かどうかを判断するための簡易的な分類です。 評価の設計: 評価で答えるべき質問 AI システム影響評価をどこから始めればよいか検討しているお客様は、ISO/IEC 42005 を参考にできます。この規格では、テンプレート化された評価アプローチを通じて、AI システム影響評価で文書化すべき具体的な情報を規定しています。また、重複を避けるために、企業が既に実施している可能性のある他のリスク評価を活用する方法も説明しています。文書には、次のような項目を含めることが推奨されます。 AI システムとその意図された用途の説明 予見可能な誤用の形態 AI システムの開発に使用されたデータ、その基盤となるコンポーネントとアルゴリズム AI システムがデプロイされる環境 AI システムの影響を受ける可能性のある個人とコミュニティ ISO/IEC 42005 は、システムがどのように使用または誤用されうるかを考慮することで、AI システムのプラスとマイナスの両方の影響を特定するための方法論を提供しています。この規格は、組織が優先事項として選択できるさまざまな AI に関する目標 (公平性、信頼性、プライバシー、セキュリティなど) を、危害と便益の両面から影響を評価する基準として用いています。そのため、組織が責任ある AI の原則を実践するうえで役立ちます。また、AI システム影響評価プロセスにおけるステークホルダーの特定と協議に関する考慮事項も示しており、多様なコミュニティから意見を募り、評価に反映することを推奨しています。 ISO/IEC 42001 認証の取得支援 ISO/IEC 42001 の認証取得を目指す組織にとって、ISO/IEC 42005 は、ISO/IEC 42001 の主要な管理策である AI 影響評価への対応方法について有益なガイダンスとなります。ISO/IEC 42005 の附属書 A では、同規格が ISO/IEC 42001 の要件への対応をどのように支援するかを具体的に説明しています。 AWS は、AI サービスについて、認定された認証機関から ISO/IEC 42001 認証を 取得しています 。対象となるサービスは Amazon Bedrock 、 Amazon Q Business 、 Amazon Textract 、 Amazon Transcribe です。AWS はこの経験に基づき、責任ある AI への取り組みにおいて AI 影響評価が組織をどのように支援できるかを含め、AWS のベストプラクティスを策定しました。 責任ある AI への取り組みを支援する AWS のツール AWS Well-Architected Responsible AI Lens は、ビルダーチームが特定のユースケースに向けた AI ソリューションを責任を持って構築、運用できるよう支援します。AWS Responsible AI Lens は、ISO/IEC 42005 と密接に整合しています。 便益と危害の特定: どちらも、期待される便益と潜在的な危害を特定するようビルダーを導きます。 リスク管理の統合: どちらも、リスクの特定と分析の結果を、リスク対応の意思決定と緩和策に反映することを重視しています。 ライフサイクルへの統合: どちらも、影響評価を 1 回限りのコンプライアンス作業ではなく、AI 開発ライフサイクルに不可欠な要素として位置付けています。 さらに AWS は、2026 年 5 月に最新のコンプライアンスガイド「 AWS における ISO/IEC 42001 の実装 」を公開しました。このガイドは、AWS のサービスを使用して AIMS を設計、運用する組織を支援します。 まとめ ISO/IEC 42001 や ISO/IEC 42005 などの国際規格は、信頼、相互運用性、説明責任を支えます。これらの要素が、多様なグローバル環境における AI のイノベーションとデプロイを推進します。AWS は、これらの規格との整合を支援するツールの構築に取り組んでいます。この取り組みは、責任ある AI の開発とデプロイに対する AWS のコミットメントについて、独立した検証による裏付けをお客様に提供します。また、AWS の AI サービスがコンプライアンスへの取り組みをどのように加速できるかをお客様に示すものでもあります。 免責事項: 本ブログで紹介するリスク評価と影響評価に関するガイダンスは、ISO/IEC 42001 に基づく AI リスク管理の実装、ISO/IEC 42005 との整合、AI リスク管理基盤の確立について、一般的な方向性と実践的な知見を提供することを目的としています。ただし、規格および規制当局が求めるとおり、各組織はそれぞれの状況に応じたリスク評価を独自に実施する責任を負います。本ブログは、いかなるリスク管理の 規格や法律についても、準拠のための網羅的なアプローチを示すもの、または準拠を保証するものとして解釈されるべきではありません。 著者について Adam Powers Adam は Amazon の Director of Privacy Science and Responsible AI です。Adam の組織は、Amazon がお客様のデータを保護するために用いる科学的手法と技術を開発しています。また、Amazon の責任ある AI を統括する部門を率い、全社における AI の標準とコンプライアンスプログラムを策定し、ツールを整備しています。Amazon では以前、Worldwide Customer Service Security と Devices & Services Privacy を率いていました。Amazon に入社する前は、メディアおよび通信業界で 20 年にわたり、スタートアップの共同創業者兼 CTO、テクノロジー部門の幹部、国際標準化団体のリーダーとして活躍しました。ブロードバンドネットワーキングやインタラクティブテレビから、言語モデルベースのリスク特定に至るまで、幅広い分野で特許を保有しています。 Peter Hallinan Peter は Amazon の Director of Responsible AI として、AWS における責任ある AI の科学と実践を推進する組織を率いています。AI (ハーバード大学で博士号を取得) と起業 (Blindsight を Amazon に売却) に関する深い専門知識を有しています。ボランティア活動として、スタンフォード大学医学部の顧問教授や、マダガスカル米国商工会議所の会頭を務めた経験があります。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。