Amazon Web Services ブログ

中島 章博

Author: 中島 章博

Security Solutions Architect

AWS re:Invent 2026 で見逃せないデジタル主権関連セッション

2026 年 11 月 30 日~12 月 4 日にラスベガスで開催される AWS re:Invent 2026 から、デジタル主権に関するブレイクアウトセッション、チョークトーク、ワークショップ、ライトニングトークを 5 つのテーマ別に紹介します。AWS European Sovereign Cloud による運用上の自律性、データレジデンシー要件下での AI ワークロードの配置、AWS Outposts や AWS 専有ローカルゾーンなどのインフラストラクチャの選び方、ディザスタリカバリとパーティション間接続、業界別のデジタル主権を取り上げます。

AWS Nitro Sandboxes: Amazon EKS で実現するハードウェア強制型ワークロード分離

Amazon Elastic Kubernetes Service (Amazon EKS) 向けに AWS Nitro Sandboxes の提供を開始しました。サンドボックス化されたポッドは AWS Nitro System を基盤とする専用の軽量 VM で実行されるため、ポッドごとにハードウェアベースのセキュリティ境界を設けられます。EKS Auto Mode ではポッド仕様を 1 行変更するだけで有効にでき、分離モードと機密モードを選べます。AI エージェント、マルチテナント SaaS、規制対象のワークロードを安全かつ効率的に実行する方法を、AI コーディングエージェントの実行例とともに紹介します。

Amazon Bedrock を活用したアプリケーションの設計に信頼と安全性を組み込む

Amazon Bedrock を活用した生成 AI アプリケーションでは、設計段階から安全性を組み込むことが重要です。本記事では、責任ある AI の主要な側面と、設計と開発、デプロイ、運用の各フェーズで安全性を確保するための考え方を解説します。さらに、Amazon CloudWatch による監視や Amazon Bedrock Guardrails による保護措置のカスタマイズなど、不正使用を防止する方法を紹介します。AWS Trust & Safety チームから不正使用の報告を受けた際の対応プロセスも説明します。

Amazon Bedrock AgentCore Policy がエージェンティックワークフローの保護に Cedar を採用した理由

AI エージェントの中核にある大規模言語モデル (LLM) は非決定論的で、ハルシネーションやプロンプトインジェクションのリスクがあります。本記事では、LLM を信頼できないアクターとして扱う考え方を説明します。そのうえで、Amazon Bedrock AgentCore Gateway でツール呼び出しを認可制御する AgentCore Policy が Cedar を採用した理由を解説します。可読性、決定論的な動作、自動推論による分析可能性を活かして、ニューロシンボリック AI でポリシーを作成し、Cedar Analysis で論理エラーや競合を検出する仕組みも紹介します。

Amazon Route 53 Resolver DNS Firewall によるハイブリッドワークロードの保護

Amazon Route 53 Resolver DNS Firewall による保護をオンプレミスワークロードへ拡張し、ハイブリッド AWS 環境全体で統一された DNS セキュリティポリシーを実現する方法を紹介します。AWS Direct Connect や AWS Site-to-Site VPN を使ったプライベート接続と、インターネット向け Network Load Balancer を使ったパブリック接続について、DNS クエリのフローを解説します。スケーラビリティ、高可用性、パフォーマンス、セキュリティに関する設計上の考慮事項も取り上げます。さらに、AWS Firewall Manager と AWS Security Hub を使って、マルチアカウント環境で DNS 保護を一元管理する方法も説明します。

AWS Network Firewall 向け Route 53 Resolved IP Validation の紹介: ドメイン名による非ウェブトラフィック制御と SNI スプーフィング防止

AWS は 2026 年 10 月 21 日、AWS Network Firewall 向け Route 53 Resolved IP Validation を追加料金なしでリリースしました。Network Firewall は、新しいアウトバウンド接続の宛先を、Amazon Route 53 Resolver が返した IP アドレスと照合します。これにより、SFTP や SSH などの非ウェブトラフィックをドメイン名でフィルタリングでき、TLS インスペクションなしで SNI スプーフィングも防止できます。この記事では、機能の仕組み、アラートモードで有効化する手順、2 つのユースケース、ベストプラクティスを紹介します。

Amazon Route 53 Resolver DNS Firewall で高度な DNS 脅威を防ぐ

Amazon VPC 内の DNS クエリは Amazon Route 53 Resolver を経由する独自の経路をたどるため、セキュリティグループや AWS Network Firewall などの制御をバイパスします。この記事では、従来のブロックリストでは捕捉できない DNS トンネリングやドメイン生成アルゴリズム (DGA) の仕組みに加え、Amazon Route 53 Resolver DNS Firewall Advanced によるリアルタイム検出と信頼度のしきい値の選び方を解説します。さらに、コンソールでのルール作成、AWS CloudFormation テンプレートによる推奨ルールグループのデプロイ、クエリログ記録、AWS Security Hub との統合も紹介します。

AWS WAF を使用した PHP2Shell RCE 脆弱性 (CVE-2026-109618 および CVE-2026-109619) の緩和策

PHP2Shell (CVE-2026-109618 および CVE-2026-109619) は、PHP コアランタイムに存在する認証不要の RCE 脆弱性です。完全な修正は PHP のアップグレードのみですが、本記事ではパッチ適用期間中に AWS WAF で露出を低減する方法を紹介します。セッションアップロード進捗フィールドや multipart リクエストのブロック、本文サイズの上限設定、レートベースのルールについて、AWS WAFv2 の JSON ルール例と Count モードから Block への段階的なデプロイ手順を解説します。また、AWS WAF による保護の限界と、補完するサーバー側の緩和策についても説明します。

Amazon Threat Intelligence が PHP2Shell の脆弱性公開前の悪用を MadPot で特定

Amazon Threat Intelligence は、MadPot のテレメトリから、CVE-2026-109618 と CVE-2026-109619 が公開される 4 日前の 2026 年 10 月 17 日に、PHP2Shell の悪用の試みを特定しました。本記事では、エンバーゴの限界を解説します。また、AI を活用した分析によって、パッチのリリースからエクスプロイト作成までの時間が短くなっている現状も取り上げます。さらに、時間単位でのパッチ適用やシグネチャに依存しない検出など、セキュリティリーダーが見直すべき前提を説明します。併せて、直ちに実施すべき推奨対策と侵害指標 (IOC) も紹介します。

AWS がネットワークスキャンのガイドラインを導入

AWS は、お客様のワークロードを対象としたネットワークスキャンのガイドラインを導入します。ネットワークスキャンは正当なセキュリティ目的にも、脅威アクターによる偵察にも使われ、両者を見分けるのは困難です。本記事では、セキュリティデータに利害を持つさまざまな関係者を整理します。そのうえで、ガイドラインに準拠したスキャナーが従うべき 4 つの原則 (観察のみ、識別可能、協調的、機密保持) と、準拠によって得られるメリットを紹介します。