本ブログは 2026 年 3 月 18 日に公開された AWS Blog “ Amazon threat intelligence teams identify Interlock ransomware campaign targeting enterprise firewalls ” を翻訳したものです。 Amazon Threat Intelligence は、Cisco Secure Firewall Management Center (FMC) Software の重大な脆弱性 CVE-2026-20131 を悪用する Interlock ランサムウェアのアクティブなキャンペーンを確認しました。この脆弱性は、認証を必要とせずにリモートの攻撃者が対象デバイス上で root 権限により任意の Java コードを実行できるというもので、2026 年 3 月 4 日に Cisco が公開しました。 Cisco による 脆弱性の公開 を受け、Amazon Threat Intelligence は Amazon MadPot のグローバルセンサーネットワークを使用して、この脆弱性の調査を開始しました。Amazon MadPot は、サイバー犯罪者のアクティビティをおびき寄せて監視するハニーポットサーバーのシステムです。過去から現在にかけてのエクスプロイトを調査した結果、Interlock が脆弱性公開の 36 日前にあたる 2026 年 1 月 26 日から悪用を開始していたことが判明しました。これは単なる脆弱性の悪用ではありませんでした。Interlock はゼロデイを手にしており、防御側がこの脆弱性の存在を認識するよりも前に、組織を侵害するための数週間の猶予を得ていたのです。この発見を受けて、AWS は Cisco の調査を支援するとともにお客様を保護するため、調査結果を Cisco と共有しました。 設定に誤りのあったインフラストラクチャサーバー、つまり攻撃者が使用していたセキュリティが不十分なステージング領域から、Interlock の攻撃ツールキットの全容が明らかになりました。このまれな設定ミスにより、Amazon のセキュリティチームは、ランサムウェアグループの多段階攻撃チェーン、カスタムのリモートアクセス型トロイの木馬 (RAT、攻撃者が侵害したシステムをリモート制御するためのバックドアプログラム)、偵察スクリプト (被害者のネットワークをマッピングする自動化ツール)、および回避テクニックの全容を把握することができました。 今回のキャンペーンにおいて、AWS インフラストラクチャや AWS 上のお客様のワークロードが影響を受けた事実は確認されていません。本アドバイザリでは、潜在的な侵害の特定と Interlock の活動からの防御に役立てていただけるよう、包括的な技術分析と侵害インジケータ (IoC) を共有します。Cisco Secure Firewall Management Center を使用している組織は、Cisco のセキュリティパッチを直ちに適用し、以下に示す IoC を確認してください。 発見と調査のタイムライン Amazon Threat Intelligence は、CVE-2026-20131 に関連する可能性のある脅威アクティビティが、脆弱性の公開に先立つ 2026 年 1 月 26 日から発生していたことを特定しました。確認されたアクティビティには、影響を受けるソフトウェアの特定のパスに対する HTTP リクエストが含まれていました。リクエスト本文には、Java コードの実行を試みるコードと 2 つの埋め込み URL が含まれていました。1 つはエクスプロイトに必要な設定データの配信用で、もう 1 つは脆弱なターゲットから HTTP PUT リクエストで生成ファイルをアップロードさせ、悪用の成功を確認するためのものでした。複数のエクスプロイト試行を通じて、これらの URL にさまざまなバリエーションが確認されました。 調査をさらに進め、脅威インテリジェンスを得るため、AWS は想定されるファイル内容を含む HTTP PUT リクエストを送信し、侵害に成功したシステムを装いました。これにより Interlock は攻撃の次のステージに進み、リモートサーバーから悪意のある ELF バイナリ (Linux 実行ファイル) をダウンロードして実行するコマンドを送信してきました。 アナリストがこのバイナリを取得したところ、同一のホスト (攻撃者が制御するサーバー) が Interlock の攻撃ツールキット全体の配布にも使用されていることが判明しました。この外部に露出していたインフラストラクチャでは、アーティファクトが標的ごとに個別のパスで整理されており、侵害したホストへのツールのダウンロードとステージングサーバーへのアーティファクトのアップロードの両方に同じパスが使用されていました。 Interlock ランサムウェアへのアトリビューション ELF バイナリと関連アーティファクトは、技術的および運用面の指標の一致から、Interlock ランサムウェアファミリーによるものと判断されます。埋め込まれたランサムノートと TOR 上の身代金交渉ポータルは、Interlock が従来使用してきた特徴的な手口やインフラストラクチャと合致しています。ランサムノートで複数のデータ保護規制に言及していることは、規制上のリスクを指摘して被害者に圧力をかけるという Interlock の既知の手法を反映しています。データの暗号化だけでなく、規制上の罰金やコンプライアンス違反をも利用して組織を脅迫する手口です。ランサムノートに埋め込まれたキャンペーン固有の組織識別子も、Interlock が被害者ごとに追跡を行うモデルと一致しています。 Interlock はこれまで、業務の中断が身代金支払いへの大きな圧力となる特定のセクターを標的としてきました。標的として最も多いのは教育セクターで、次いでエンジニアリング・建築・建設企業、製造・産業組織、医療機関、政府・公共セクターの順となっています。 観測された脅威アクティビティのタイムスタンプ、設定に誤りのあったインフラストラクチャサーバー上のアーティファクト、および取得した脅威アーティファクトに埋め込まれたメタデータの時間分析から、この脅威アクターは 75～80% の確度で UTC+3 タイムゾーンにおいて活動していると推定されます。すべての UTC オフセットを対象とした体系的な分析の結果、UTC+3 が最も一致しました。アクティビティの開始は 08:30 頃、ピークは 12:00～18:00、推定される非活動時間帯は 00:30～08:30 でした。 図 1: Interlock ランサムウェアの身代金交渉ポータル。被害者が組織 ID とメールアドレスを入力し、認証トークンを受け取って交渉チャットセッションを開始する 技術分析: Interlock の攻撃ツールキット 侵害後の偵察スクリプト Interlock は初期アクセスを獲得した後、さまざまなツールを使用して攻撃を展開します。Amazon Threat Intelligence チームは、Windows 環境を体系的に列挙する (被害者のネットワーク情報を自動収集する) PowerShell スクリプトを取得しました。このスクリプトは、オペレーティングシステムとハードウェアの詳細、実行中のサービス、インストール済みソフトウェア、ストレージ構成、Hyper-V 仮想マシンインベントリ、デスクトップ・ドキュメント・ダウンロードの各ディレクトリにわたるユーザーファイル一覧、Chrome、Edge、Firefox、Internet Explorer、360 ブラウザからのブラウザアーティファクト (履歴、ブックマーク、保存された認証情報、拡張機能を含む)、プロセスに関連付けられたアクティブなネットワーク接続、ARP テーブル、iSCSI セッションデータ、および Windows イベントログからの RDP 認証イベントを収集します。 このスクリプトは、各システムの完全修飾ホスト名に基づいて専用ディレクトリを作成し、結果を集約用ネットワーク共有 (\JK-DC2\Temp) にステージングします。つまり、侵害した各コンピュータにフォルダが作成されます。収集が完了すると、データはホスト名に基づく名前の ZIP アーカイブに圧縮され、元の生データは削除されます。このようなホスト単位の構造化された出力形式は、スクリプトがネットワーク内の複数マシンにまたがって実行されていることを示しており、組織全体の暗号化に向けた準備を行うランサムウェア侵入チェーンの典型的な特徴です。 カスタムリモートアクセス型トロイの木馬 リモートアクセス型トロイの木馬 (RAT) とは、攻撃者が侵害したシステムへの持続的な制御を可能にする悪意のあるプログラムであり、不正なリモートデスクトップソフトウェアのように機能します。 JavaScript インプラント: Amazon Threat Intelligence は、難読化された JavaScript ベースの RAT を取得しました。この RAT はブラウザコンソールのメソッドをオーバーライドしてデバッグ出力を抑制し、基本的な検出ツールからアクティビティを隠蔽します。実行時には、PowerShell と Windows Management Instrumentation (WMI) を使用して感染ホストのプロファイリングを行い、システム ID、ドメインメンバーシップ、ユーザー名、OS バージョン、権限コンテキストを収集した上で、暗号化された初期化ハンドシェイクでこれらのデータを送信します。 コマンドアンドコントロール (C2) 通信には永続的な WebSocket 接続が使用され、メッセージごとにパケットヘッダーに埋め込まれた 16 バイトのランダムキーによる RC4 暗号化が適用されます。各メッセージが異なる暗号化キーを使用するため、傍受がより困難になる仕組みです。インプラントは、オペレーターが制御する複数のホスト名と IP アドレスをランダムな順序で巡回し、再接続試行間にはエクスポネンシャルバックオフを適用します。 このインプラントは、インタラクティブなシェルアクセス、任意のコマンド実行、双方向ファイル転送、TCP トラフィックのトンネリングに対応する SOCKS5 プロキシ機能 (悪意のあるトラフィックを他のシステム経由でルーティングして発信元を隠蔽) といった機能を備えています。また、自己更新および自己削除の機能もあり、オペレーターは再感染を伴わずにインプラントを置換または削除でき、フォレンジック調査を妨害する痕跡消去にも対応します。 Java インプラント: Java で実装された機能的に同等のクライアントも存在し、同一の C2 機能を提供します。GlassFish エコシステムライブラリ上に構築されており、ノンブロッキング I/O トランスポートには Grizzly を、WebSocket プロトコル通信には Tyrus を使用しています。つまり Interlock は、同じバックドアを 2 つの異なるプログラミング言語で構築することで、防御側が一方のバージョンを検出した場合でもアクセスを確実に維持できるようにしているのです。 インフラストラクチャロンダリングスクリプト 高度な脅威アクターは自身のインフラストラクチャから直接攻撃を仕掛けるのではなく、使い捨ての中継ネットワークを構築して痕跡を隠蔽します。Amazon Threat Intelligence チームは、Linux サーバーを HTTP リバースプロキシ (攻撃者の実際の所在地を隠すためにトラフィックを転送する中間サーバー) として構成する Bash スクリプトを特定しました。このスクリプトは、システムアップデートの実行、SSH ブルートフォース保護機能を持つ fail2ban のインストール、HAProxy 3.1.2 のソースからのコンパイルを行います。構成された HAProxy インスタンスはポート 80 でリッスンし、すべてのインバウンド HTTP トラフィックをハードコードされたターゲット IP に転送します。また、systemd によりシステム再起動後も持続性が確保されます。 特に注目すべきコンポーネントが、5 分ごとに cron ジョブとして実行されるログ消去ルーチンです。このルーチンは /var/log 配下のすべての *.log ファイルを切り詰め、HISTFILE 変数をアンセットしてシェル履歴を抑制します。5 分間隔でログを消去するこの積極的な証拠破壊は、専用に構築された HTTP 転送プロキシと組み合わせて考えると、このスクリプトが使い捨てのトラフィックロンダリング用中継ノードの構築を目的としていることを示しています。これらのノードは、エクスプロイトトラフィックの発信元隠蔽、C2 通信の中継、データ窃取のプロキシとして機能し、攻撃の発信源への追跡をほぼ不可能にします。 メモリ常駐型 Web シェル Amazon Threat Intelligence チームは、ELF バイナリの投下に代わる手段として配信される Java クラスファイルを確認しました。Java Virtual Machine (JVM) によってロードされると、静的イニシャライザが、サーバーの StandardContext に ServletRequestListener を登録し、ディスクへのファイル書き込みを一切行わずに HTTP リクエストを傍受する永続的なメモリ常駐型バックドアをインストールします。この「ファイルレス」アプローチにより、悪意のあるファイルを探索する従来のウイルス対策スキャンを回避することが可能になります。 リスナーは受信リクエストを検査し、暗号化されたコマンドペイロードを含む特殊なパラメータの有無を確認します。ペイロードは、ハードコードされたシード値 “geckoformboundary99fec155ea301140cbe26faf55ed2f40” の MD5 ハッシュから導出されたキー (先頭 16 文字の 09b1a8422e8faed0 を使用) による AES-128 で復号されます。復号されたペイロードはコンパイル済みの Java バイトコードとして扱われ、JVM に動的にロードされて実行されます。これは、悪意のあるコードを完全にメモリ内で実行することで、ファイルベースの検出を回避するために設計されたテクニックです。 接続確認ツール Amazon Threat Intelligence チームは、ポート 45588 でリッスンする基本的な TCP サーバーを実装した Java クラスファイルを取得しました (ポート番号は静的分析による特定を困難にするため、Unicode 文字 넔 としてエンコードされていました)。サーバーは接続を受け入れると、接続元の IP アドレスをログに記録し、挨拶メッセージを送信した後、即座に接続を切断します。この動作パターンは、初期エクスプロイト実行後のコード実行成功確認やネットワークポートへの到達性確認に使用される軽量なネットワークビーコン (いわゆる「フォンホーム」ツール) の特徴と一致しています。 正規ツールの悪用 Interlock はカスタムインプラントと並行して、正規の商用リモートデスクトップツールである ConnectWise ScreenConnect もデプロイしていました。ランサムウェアオペレーターが正規のリモートアクセスツールをカスタムマルウェアと併用するのは、いわば保険をかけているようなものです。防御側が 1 つのバックドアを発見して除去しても、別の侵入経路が残ります。これは冗長なリモートアクセス手段を複数確保するパターンであり、個々の足場が除去されてもアクセスを維持しようとするランサムウェアオペレーターの典型的な手法と一致しています。正規ツールならではのネットワークフットプリントにより、許可されたリモート管理トラフィックに紛れ込むことができ、検出がさらに困難になります。 Amazon Threat Intelligence チームは、インシデントレスポンダーが広く使用するオープンソースのメモリフォレンジックフレームワークである Volatility も取得しました (防御側が攻撃調査に使用するのと同じツールです)。自動化された使用を示すアーティファクトは確認されなかったものの、カスタムインプラントや偵察スクリプトとともに配置されていたことは、高度な脅威オペレーションの特徴と合致しています。ランサムウェアグループと国家支援型アクターの双方が、侵入時に Volatility をデプロイしていることが確認されています。メモリダンプの解析に特化したこのツールは、RAM に保存された認証情報などの機密データへのアクセスを可能にし、ラテラルムーブメント (ネットワーク内の横展開) やより深い環境侵害を通じてランサムウェアオペレーションやスパイ活動を支援します。 さらに Interlock は、Active Directory Certificate Services (AD CS) の設定ミスを悪用するためのオープンソースの攻撃的セキュリティツールである Certify も使用していました。ランサムウェアオペレーターにとって、Certify は脆弱な証明書テンプレートや、認証用証明書の要求を許可する登録権限を特定する手段となります。取得した証明書は、ユーザーのなりすまし、権限の昇格、永続的なアクセスの維持に悪用できます。これらの機能は、ランサムウェアオペレーションにおける初期侵害と長期的な永続化の双方を直接支援するものです。 侵害インジケータ (IoC) 以下のインジケータは、影響を受けた可能性のある組織での防御に役立てることができます。Interlock はコンテンツバリエーション技法を使用しているため、ほとんどのファイルハッシュは信頼性の高いインジケータとしては掲載していません。脅威アクターは、異なるターゲットに配信するスクリプトやバイナリなどのアーティファクトに逐次変更を加えており、機能的には同一のツールであってもファイルハッシュが異なるものとなっていました。このカスタマイズにより、ファイルの完全一致に依存するシグネチャベースの検出が回避されていました。 206.251.239[.]164 エクスプロイトソース IP 2026 年 1 月に活動確認 199.217.98[.]153 エクスプロイトソース IP 2026 年 3 月に活動確認 89.46.237[.]33 エクスプロイトソース IP 2026 年 3 月に活動確認 Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:136.0) Gecko/20100101 Firefox/136.0 エクスプロイト HTTP User-Agent 2026 年 1 月および 3 月に観測 b885946e72ad51dca6c70abc2f773506 エクスプロイト TLS JA3 2026 年 1 月および 3 月に観測 f80d3d09f61892c5846c854dd84ac403 エクスプロイト TLS JA3 2026 年 3 月に観測 t13i1811h1_85036bcba153_b26ce05bbdd6 エクスプロイト TLS JA4 2026 年 1 月および 3 月に観測 t13i4311h1_c7886603b240_b26ce05bbdd6 エクスプロイト TLS JA4 2026 年 3 月に観測 144.172.94[.]59 C2 フォールバック IP 2026 年 3 月に活動確認 199.217.99[.]121 C2 フォールバック IP 2026 年 3 月に活動確認 188.245.41[.]78 C2 フォールバック IP 2026 年 3 月に活動確認 144.172.110[.]106 バックエンド C2 IP 2026 年 3 月に活動確認 95.217.22[.]175 バックエンド C2 IP 2026 年 3 月に活動確認 37.27.244[.]222 ステージングホスト IP 2026 年 3 月に活動確認 hxxp://ebhmkoohccl45qesdbvrjqtyro2hmhkmh6vkyfyjjzfllm3ix72aqaid[.]onion/chat.php 身代金交渉ポータル 2026 年 3 月に活動確認 cherryberry[.]click エクスプロイトサポートドメイン 2026 年 1 月に活動確認 ms-server-default[.]com エクスプロイトサポートドメイン 2026 年 3 月に活動確認 initialize-configs[.]com エクスプロイトサポートドメイン 2026 年 3 月に活動確認 ms-global.first-update-server[.]com エクスプロイトサポートドメイン 2026 年 3 月に活動確認 ms-sql-auth[.]com エクスプロイトサポートドメイン 2026 年 3 月に活動確認 kolonialeru[.]com エクスプロイトサポートドメイン 2026 年 3 月に活動確認 sclair.it[.]com エクスプロイトサポートドメイン 2026 年 3 月に活動確認 browser-updater[.]com C2 ドメイン 2026 年 3 月に活動確認 browser-updater[.]live C2 ドメイン 2026 年 3 月に活動確認 os-update-server[.]com C2 ドメイン 2026 年 3 月に活動確認 os-update-server[.]org C2 ドメイン 2026 年 3 月に活動確認 os-update-server[.]live C2 ドメイン 2026 年 3 月に活動確認 os-update-server[.]top C2 ドメイン 2026 年 3 月に活動確認 d1caa376cb45b6a1eb3a45c5633c5ef75f7466b8601ed72c8022a8b3f6c1f3be 攻撃的セキュリティツール (Certify) 2026 年 3 月に観測 6c8efbcef3af80a574cb2aa2224c145bb2e37c2f3d3f091571708288ceb22d5f スクリーンロッカー 2026 年 3 月に観測 防御に関する推奨事項 Interlock ランサムウェアの脅威から組織を守るために、以下の対策を実施してください。 直ちに実施すべきアクション: Cisco Secure Firewall Management Center に対する Cisco のセキュリティパッチを適用する 上記の IoC についてログを確認する 侵害の兆候がないかセキュリティ評価を実施する ScreenConnect の不正なインストールがないか確認する 検出のポイント: ネットワーク共有にホスト名ベースのディレクトリ構造でデータをステージングする PowerShell スクリプトを監視する Web アプリケーションコンテキストでの Java ServletRequestListener の登録 (Java Web アプリケーションへの通常とは異なる変更) を検出する 積極的なログ消去用 cron ジョブを伴う HAProxy のインストール (5 分間隔で自身のログを消去するプロキシサーバー) を特定する 通常とは異なる高番号ポート (例: 45588) への TCP 接続を監視する 長期的な対策: 複数のセキュリティ制御レイヤーによる多層防御戦略を実装する 継続的な脅威監視とスレットハンティングの能力を維持する 侵害を受ける可能性のあるシステムとは分離した、安全で一元化されたログストレージによる包括的なログ収集を確保する ランサムウェアシナリオに対するインシデントレスポンス手順を定期的にテストする Interlock の戦術、テクニック、手順についてセキュリティチームを教育する ここで本当に重要なのは、これが特定の脆弱性や特定のランサムウェアグループだけの問題ではないということです。ゼロデイエクスプロイトがあらゆるセキュリティモデルに突きつける根本的な課題なのです。パッチが存在しない段階で攻撃者に脆弱性を悪用されてしまえば、どれほど徹底したパッチ管理を行っていても、その重要な期間中は防御できません。だからこそ多層防御が不可欠なのです。複数のセキュリティ制御を重ねることで、いずれかの対策が機能しない場合や、まだ導入されていない場合でも保護を維持できます。迅速なパッチ適用は脆弱性管理の基盤であり続けますが、多層防御は、エクスプロイトが確認されてからパッチが提供されるまでの空白期間に、組織が無防備にならないための重要な手段です。 Amazon Threat Intelligence チームは Interlock ランサムウェアの活動を引き続き監視しており、新たな情報が判明し次第アップデートを提供します。今回のキャンペーンから収集したインテリジェンスは、お客様をプロアクティブに保護するため、AWS のセキュリティサービスに統合されています。 この記事に関するご質問は、 AWS サポート までお問い合わせください。 CJ Moses CJ Moses は Amazon Integrated Security の CISO です。Amazon 全体のセキュリティエンジニアリングとオペレーションを統括しており、セキュリティの実践が最も自然で簡単な選択肢となるようにすることで Amazon のビジネスを支えることを使命としています。2007 年 12 月に Amazon に入社し、Consumer CISO、直近では AWS CISO を含むさまざまな役職を歴任した後、2023 年 9 月に現職に就任しました。 Amazon 入社以前は、連邦捜査局 (FBI) サイバー部門でコンピュータおよびネットワーク侵入に関する技術分析を率いていました。また、空軍特別捜査局 (AFOSI) の特別捜査官も務めました。現在のセキュリティ業界の基盤を築いたとされる、複数のコンピュータ侵入捜査を指揮しました。 CJ はコンピュータサイエンスと刑事司法の学位を取得しており、SRO GT America GT2 のレースカードライバーとしても活躍しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 3 月 10 日に公開された AWS Blog、” AWS Security Hub is expanding to unify security operations across multicloud environments ” を翻訳したものです。 多くのお客様と話をして、1 つ明確なことがあります。それは、セキュリティの課題は容易になっていないということです。今日の企業は、オンプレミスインフラストラクチャ、プライベートデータセンター、複数のクラウドなど、複雑に混在する環境で運用しており、多くの場合、連携を前提に設計されていないツールを使用しています。その結果、企業のセキュリティチームは、リスク管理よりもツール管理に多くの時間を費やすことになり、ますます複雑化する環境全体で脅威に先回りすることが困難になっています。 Amazon Web Service (AWS) では、セキュリティはシンプルで、統合され、企業が実際に運用する方法に合わせて構築されるべきだと考えています。この信念が、 AWS Security Hub を再構築し、単一のエクスペリエンスを通じてフルスタックセキュリティを提供する原動力となり、このビジョンが私たちの次の展開を推し進めています。 統合セキュリティの基盤の上に 私たちは Security Hub を、 統合セキュリティオペレーションソリューション に変革しました。これは、 Amazon GuardDuty 、 Amazon Inspector 、 AWS Security Hub Cloud Security Posture Management (Security Hub CSPM) 、 Amazon Macie を含む AWS セキュリティサービスを統合し、脅威、脆弱性、設定ミス、機密データに関するセキュリティシグナルを自動的かつ継続的に分析する単一のエクスペリエンスを実現しています。Security Hub は共通の基盤を提供し、AWS 環境全体からの検出結果を統合することで、セキュリティチームがシグナルの解釈に費やす時間を減らし、対応により多くの時間を割けるようにします。この基盤の上に構築された統合オペレーションレイヤーは、セキュリティチームにニアリアルタイムのリスク分析、自動化された分析、優先順位付けされたインサイトを提供し、大規模に最も重要なことに集中できるよう支援します。 また、企業がエンドポイント、ID、メール、ネットワーク、データ、ブラウザ、クラウド、AI、セキュリティオペレーション全体にわたるフルスタックセキュリティソリューションを調達、デプロイ、統合する方法を簡素化する新機能 ( the Extended plan ) を導入しました。現在、お客様は Security Hub を使用して、厳選された AWS パートナーソリューション (ローンチ時: 7AI、Britive、CrowdStrike、Cyera、Island、Noma、Okta、Oligo、Opti、Proofpoint、SailPoint、Splunk (Cisco 傘下)、Upwind、Zscaler) を通じて、すべて 1 つの統一されたエクスペリエンスでセキュリティポートフォリオを拡張できます。AWS が販売元となるため、従量制料金の料金体系、単一の請求書、長期契約なしというメリットを享受できます。私たちのゴールはシンプルです。企業が運営するあらゆる場所で、統一されたセキュリティを提供することです。 ワークロードがどこにあっても、自由にイノベーションを AWS では、相互運用性とは、お客様のニーズに最適なソリューションを自由に選択でき、ワークロードが実行される場所でそれらを使用できることを意味します。しかし、マルチクラウド環境全体で自由にイノベーションを起こすということは、運用の複雑さを増すことなく、一貫してそれらを保護することが重要であることも意味します。 Security Hub の今後の展開 今後数か月間で、AWS を超えた統合セキュリティオペレーションを拡張する新しいマルチクラウド機能を Security Hub に追加します。この拡張の基盤となるのは、ワークロードがどこで実行されていても、セキュリティシグナルを統合する共通データレイヤーです。その上に、統合されたポリシーとオペレーションレイヤーが、一貫したポスチャ管理、エクスポージャー分析、リスクの優先順位付けを提供するため、セキュリティチームは断片化されたコンソールの集合ではなく、単一のリスクビューから運用できます。 Security Hub は、マルチクラウド環境全体にわたる重要なリスクを明らかにする統合リスク分析を提供します。一貫したセキュリティポスチャの可視性を提供する Security Hub CSPM チェックを使用してクラウドセキュリティポスチャを管理でき、仮想マシンスキャン、コンテナイメージスキャン、サーバーレススキャンを含む拡張された Amazon Inspector 機能により、脆弱性管理を拡張できます。また、Security Hub は、外部ネットワークスキャンにより、AWS 以外で実行されているリソースを含むマルチクラウド環境全体のインターネット公開状態に関するコンテキストでセキュリティ検出結果をエンリッチします。 その結果、企業全体でより包括的なリスクカバレッジが実現されます。これは、セキュリティチームに対して、どこで運用していても、リスクを検出して対応するための単一の統一されたエクスペリエンスを提供することを目的としています。 ビジネスを加速するセキュリティ 私が話をするセキュリティリーダーたちは、単により良いツールを求めているわけではありません。求めているのは、リスクを管理するだけでなく、リスクに先回りする方法です。ビジネスのペースについていくセキュリティを求めており、ビジネスを遅らせるセキュリティではありません。 これが AWS Security Hub のビジョンです。共通のデータ基盤上に構築され、インテリジェントな分析によって強化され、一貫した運用レイヤーを通じて提供される、単一の統合されたセキュリティ運用体験による統一されたセキュリティです。これにより、セキュリティリスクの軽減、チームの生産性向上、AWS 全体およびそれ以外でのセキュリティ運用の強化を支援します。 マルチクラウドへの拡大は進行中であり、まだ始まったばかりです。 詳細については、 aws.amazon.com/security-hub をご覧いただくか、3 月 23 日から 26 日にサンフランシスコで開催される RSA Conference の AWS ブース (S-0466) にお越しください。 Gee Rittenhouse Gee は AWS のセキュリティサービス担当バイスプレジデントで、Security Hub、GuardDuty、Inspector などの主要サービスを統括しています。MIT で博士号を取得し、エンタープライズセキュリティとクラウド分野で豊富なリーダーシップ経験を持っています。以前は Skyhigh Security の CEO および Cisco セキュリティビジネスグループの SVP 兼 GM を務めていました。 翻訳は Security Solutions Architect の 松崎 博昭 が担当しました。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 先日、 AI 駆動開発ライフサイクル（AI-DLC） の社内研修を受けて、生成 AI をフル活用することで開発のスピードと品質の両立ができる可能性を実感しました。AI-DLC に関するお客様事例ブログを下記で紹介していますので、ぜひご一読ください。 3 月 25 日（水）には「 AWS での Claude Code の買い方・使い方 」という Claude Code をAWS 上で活用する手段や買い方をご紹介するイベントが開催されます。また3 月 26 日（木）には「 Amazon Quick で変わる業務の現場 — 活用企業・AWS社員による事例紹介 」が開催されます。ご興味がある方はぜひご参加ください！ 「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き募集中ですのでよろしくお願いします。 それでは、3 月 2 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「第 6 回 AWS ジャパン 生成 AI Frontier Meetup ～学びと繋がりの場～【開催報告】」を公開 2026 年 2 月 17 日に開催された第 6 回 生成 AI Frontier Meetup の開催レポートです。PwC Japan との生成 AI 実態調査に基づくディスカッションや、みずほフィナンシャルグループ様、ライオン様、電通デジタル様、日本経済新聞社様、Sky様、アクト・ノード様など多様な企業によるライトニングトーク、基盤モデル開発者の紹介、経済産業省 GENIAC の最新動向が共有されました。 ブログ記事「三菱電機のエンジニア 33 名が 3 日間で体感した AI 駆動開発の可能性 — AI-DLC Unicorn Gym 座談会」を公開 三菱電機 電力システム製作所 電力 ICT センター様で 33 名のエンジニアが参加した 3 日間の AI-DLC Unicorn Gym の座談会レポートです。5 チームがそれぞれ実際の業務課題を持ち寄り、AI 駆動開発ライフサイクルを実践。参加者の 90% 以上が「働き方を変える可能性が高い」と回答し、体感で 30〜40 倍の生産性向上を実感した様子が語られています。 ブログ記事「株式会社タイミー様の AI-DLC Unicorn Gym 開催レポート: 全社横断で挑む開発生産性の変革」を公開 株式会社タイミー様と AWS が共同で実施した AI-DLC Unicorn Gym のレポートです。11 チーム約 69 名がエンジニア・PdM・デザイナー・QA など職種横断で参加し、3 日間で全チームが MVP を構築。一部チームは翌週にプロダクションリリースを達成しました。Inception（企画・構想）フェーズでのモブワークの効果や、既存コードベースへの適用における課題と学びが共有されています。 ブログ記事「AST を活用した Kiro の高精度なコード編集」を公開 Kiro に導入された AST（抽象構文木）ベースのコードナビゲーション・編集エンジンについて解説しています。従来のテキストベースのファイル読み込みや文字列マッチングに代わり、コードを構造的に理解して操作することで、ベンチマークにおいてトークン使用量を 20% 削減し、実行時間を約 49% 短縮するなどの成果を紹介しています。 ブログ記事「[資料公開 & 開催報告] Amazon Q Developer & Kiro Meetup #5 を開催しました」を公開 2025 年 12 月 15 日に開催された Amazon Q Developer & Kiro Meetup #5 の開催レポートです。AWS re:Invent 2025 前後の Kiro のアップデート紹介に加え、ゼンリンデータコム様による組織展開の工夫、NTT ドコモ様の活用事例、リクルート様による AI-DLC の現場導入についての登壇内容がまとめられています。登壇資料もダウンロード可能です。 ブログ記事「バグ修正のパラドックス：AI エージェントが正常なコードを壊してしまう理由」を公開 AI エージェントにバグ修正を依頼すると、関係のないコードまで変更してしまう「過剰解決」の問題に対して、Kiro が採用する「プロパティ指向コード進化」という方法論を解説しています。バグ条件と事後条件を明示的に定義し、修正プロパティと保持プロパティのテストで修正の正しさと既存動作の維持を保証するアプローチを、二分探索木 (BST) 削除バグや RocketMQ のメモリリークなどの具体例で紹介しています。 ブログ記事「自律型プライベート AI エージェントを実行するための OpenClaw が Amazon Lightsail に導入されました」を公開 Amazon Lightsail で OpenClaw インスタンスを簡単に起動できるようになりました。OpenClaw はオープンソースのセルフホスト型 AI エージェントで、Amazon Bedrock がデフォルトの AI モデルプロバイダーとして事前設定されています。ブラウザとのペアリングや WhatsApp・Telegram 等のメッセージングアプリとの連携手順、セキュリティに関する考慮事項が紹介されています。 サービスアップデート Amazon Lightsail が OpenClaw (プライベートなセルフホスト型 AI アシスタント) を提供開始 上記ブログでも触れたように Amazon Lightsail で OpenClaw をワンクリックデプロイできるようになりました。サンドボックス分離、自動HTTPS、デバイス認証、自動バックアップといったセキュリティ機能が最初から組み込まれており、デフォルトの LLM プロバイダーとして Amazon Bedrock が統合されています。Slack・Telegram・WhatsApp・Discord への接続やモデルの切り替えも可能で、東京を含む15リージョンで利用できます。詳細は クイックスタートドキュメントページ をご覧ください。 新しい Kiro Power で Lambda durable functions 開発を加速 AWS が Lambda durable functions の Kiro power を発表しました。これにより、Kiro IDE や Kiro CLI 上の開発環境で、長時間実行される複雑なワークフローを簡単に構築しやすくなります。注文処理や支払い調整など複数ステップが必要な処理を、AI エージェントのサポートを受けながら効率的に開発可能です。詳細は こちらの developer guide をご参照ください。 AWS HealthLake が自動 CCDA-to-FHIR データ変換のためのデータ変換エージェントを発表 (プレビュー) AWS HealthLake に新機能「data transformation agent」(プレビュー版) が登場しました。この AI 機能により、医療機関の従来の CCDA 形式文書を FHIR R4 形式に自動変換できます。従来は数ヶ月かかっていた作業が数日で完了し、専門知識も不要です。自然言語で「エラー状態の薬剤情報をスキップ」などの指示を出せば AI が自動でテンプレートを調整します。患者の縦断的記録作成や集団健康分析など、医療データ活用の可能性が大きく広がります。 Amazon Connect Health の紹介、ヘルスケア向けに構築されたエージェント AI Amazon Connect Health が一般提供開始となりました。医療機関向けに特化した AI エージェントサービスで、患者対応や診療業務を効率化できます。患者確認エージェントは Electronic Health Records (EHR) 記録とリアルタイムで照合して本人確認を行い、予約管理エージェントは自然言語での音声対話により24時間365日の予約受付を提供します。診察前には患者インサイトエージェントが関連する患者履歴と臨床コンテキストを自動表示し、診察中はアンビエント文書化エージェントが会話から臨床ノートをリアルタイム生成、診察後は医療コーディングエージェントがICD-10・CPTコードを監査証跡付きで自動生成します。現在バージニア北部とオレゴンリージョンで利用できます。 AWS Elastic Beanstalk が AI を活用した環境分析機能を提供開始 AWS Elastic Beanstalk で AI 搭載の環境分析機能が利用可能になりました。従来は環境に問題が発生した際、ログやイベントを手動で確認して原因を特定する必要がありましたが、今回のアップデートにより Amazon Bedrock を活用した自動分析が可能となります。環境の状態が Warning や Degraded の場合、コンソールの AI Analysis ボタンから分析を実行でき、具体的なトラブルシューティング手順が提示されます。開発者や運用チームの作業効率向上と、平均解決時間の大幅短縮が期待できます。詳細は こちらのドキュメント をご参照ください。 Amazon Bedrock AgentCore Policy が一般提供開始 Amazon Bedrock AgentCore で Policy 機能の一般提供が開始されました。これまでエージェントのツールアクセス制御にはコード変更が必要でしたが、今回の機能により、セキュリティチームや運用チームがエージェントコードを変更することなく、一元的にアクセス制御ルールを設定できるようになりました。自然言語でポリシーを記述すると自動的に Cedar 言語に変換され、AgentCore Gateway がリクエストを監視・制御します。組織のガバナンス強化やコンプライアンス対応に活用でき、東京リージョンを含む 13 リージョンで利用可能です。詳細は こちらのドキュメント をご参照ください。 Amazon SageMaker Unified Studio が Kiro IDE からのリモート接続サポートを開始 Amazon SageMaker Unified Studio で Kiro IDE からのリモート接続サポートが開始されました。これまでローカル IDE とクラウドインフラの間で作業環境を切り替える必要がありましたが、今回のアップデートにより Kiro の AI 機能を使いながら SageMaker のスケーラブルな計算リソースに直接アクセスできるようになります。データサイエンティストや ML エンジニアは使い慣れた開発環境を維持しつつ、クラウドの強力なリソースを活用した効率的な開発が可能です。詳細は こちらのドキュメント をご参照ください。 Amazon SageMaker HyperPod が Restricted Instance Groups に包括的な可観測性を提供開始 Amazon SageMaker HyperPod で Restricted Instance Groups (RIG) の包括的な監視機能が提供開始されました。これまで手動で行っていた GPU 使用率や CPU 負荷などのメトリクス収集が自動化され、Amazon Managed Grafana ダッシュボードで一元管理できます。基盤モデル訓練時のパフォーマンス監視や障害診断が大幅に効率化され、訓練ログやエラーも自動収集されるため運用負荷が軽減されます。詳細は こちらのドキュメント をご参照ください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI Agent と毎日戯れており、AI Agent 無しでは生きていけなくなっています。好きなうどんは’かけ’です。