Amazon Web Services ブログ
Kiro CLI でセキュリティ調査を迅速化
本ブログは 2026 年 6 月 18 日に公開された AWS Blog “Accelerate security investigations with Kiro CLI” を翻訳したものです。
お使いの Amazon Web Services (AWS) 環境でセキュリティイベントが発生した場合、迅速な対応が不可欠です。しかし、セキュリティチームは、時間のかかる手作業のプロセスによって調査が遅れるという課題を抱えがちです。アナリストは、複数のサービスにまたがる複雑な AWS コマンドラインインターフェイス (AWS CLI) の構文を思い出しながら、Amazon GuardDuty、AWS CloudTrail、その他のセキュリティツールの検出結果を手動で関連付け、コンプライアンス要件に対応するために調査の全ステップを文書化しなければなりません。しかも、脅威が継続している中で、プレッシャーを受けながら重要な判断を下す必要があります。AWS に関する深い専門知識を持たないアナリストにとっては、こうした課題がさらに大きくなり、セキュリティ運用のボトルネックとなります。
Kiro は、統合開発環境 (IDE) やコマンドラインとの統合を通じて、コードの記述、理解、最適化を支援する AI 搭載のコーディングアシスタントです。従来の開発タスクだけでなく、アーキテクチャのガイダンス、ベストプラクティス、コスト最適化の推奨事項、サービスドキュメントのナビゲーションなど、AWS に特化した専門知識も提供します。Kiro CLI を使用すると Kiro のすべての機能をターミナルで利用できるため、セキュリティ運用のワークフローにも自然に組み込めます。例えば、組み込みツールを使用すれば、Kiro CLI を GuardDuty の検出結果の調査に活用できます。Kiro CLI は適切な AWS CLI コマンドを提案し、各コマンドの内容を説明したうえで、承認を得てから実行します。そのため、調査方法に頭を悩ませることなく、脅威の分析に集中できます。
このブログ記事では、Kiro CLI を使用して、「AWS セキュリティインシデント対応ガイド」のフレームワークに沿ってセキュリティ調査を実施する方法を紹介します。このフレームワークでは、インシデント対応を次の 5 つのフェーズに分けています。
- 準備: インシデントが発生する前に適切なツールとプロセスを整備する
- 検出と分析: セキュリティイベントを特定し、その範囲を把握する
- 封じ込め: インシデントの影響を限定し、被害の拡大を防ぐ
- 根絶と復旧: 脅威を排除し、通常の運用に戻す
- インシデント後のアクティビティ: インシデントから教訓を得て、今後の対応を改善する
この記事では、Kiro CLI を使用して GuardDuty の検出結果をトリアージし、影響を受けた Amazon Elastic Compute Cloud (Amazon EC2) リソースを評価し、AWS CloudTrail ログを分析して、修復スクリプトを生成する方法を紹介します。この記事を読み終えるころには、Kiro CLI を使用して、手順を省略することなく、数時間ではなく数分でセキュリティ調査を実施する方法を学べます。
前提条件
開始する前に、次の準備が整っていることを確認してください。
- Kiro CLI をインストールする (macOS、Linux、Windows で利用可能)
- Kiro へのアクセス (次のいずれか)
- 無料の AWS Builder ID アカウントを作成する
- 組織の Kiro Pro サブスクリプションを使用する
- AWS CLI: ドキュメント「AWS CLI の設定」に記載されているいずれかの方法で設定します。Kiro CLI は、デフォルトの AWS CLI プロファイル (または
AWS_PROFILE環境変数で指定したプロファイル) を使用して AWS リソースを操作し、アクションを実行する前に必ず承認を求めます。
ソリューションの概要
Kiro CLI の実際の動作を紹介するため、「AWS セキュリティインシデント対応ガイド」のフレームワークに従い、次のステップで GuardDuty の検出結果をエンドツーエンドで調査します。
- 発見: 重要度が高い GuardDuty の検出結果を取得して分析する
- リソース分析: EC2 インスタンスの設定、セキュリティグループ、AWS Identity and Access Management (IAM) の権限を調査する
- 封じ込め: 侵害されたインスタンスを隔離し、過剰な権限を取り消す
- 証拠保全: フォレンジック用の Amazon Elastic Block Store (Amazon EBS) スナップショットを作成する
- 範囲の評価: CloudTrail ログを分析してイベントの範囲を特定する
- プロアクティブな防御: Amazon Simple Notification Service (Amazon SNS) と Amazon EventBridge を使用して自動アラートを設定する
- ナレッジの蓄積: ステアリングファイルを使用して再利用可能な調査ワークフローを作成する
調査全体を通じて、Kiro CLI はコマンドを提案し、その目的を説明し、承認を待ってから実行し、調査結果を自動的に文書化します。これにより、非効率な手作業のプロセスが、ガイド付きの効率的なワークフローに変わります。
Kiro CLI は AI による推論と AWS に関する深い知識を組み合わせて、セキュリティの検出結果を分析し、複数のサービスにまたがる証拠を関連付け、調査の各ステップで適切な AWS CLI コマンドを提案します。AI を活用したこのアプローチで調査は迅速になりますが、アクションを実行する前に、出力と推奨事項を検証することが重要です。このウォークスルーで示す具体的なコマンドと分析は一例です。実際の結果は、検出結果の内容や環境の設定によって異なります。
調査: アラートから解決まで
このセクションでは、発見から分析までの調査の各フェーズを順に説明します。
発見: 重要度が高い GuardDuty の検出結果
調査は、早急な対応が必要な GuardDuty の検出結果から始まりました。AWS CLI コマンドを手動で組み立てる代わりに、Kiro CLI の自然言語インターフェイスを使用しました。
訳注: このプロンプトの内容は、「us-east-1 の GuardDuty の検出結果 58cddb4e8705cde3f595ef5805f50491 を調査したい。検出結果の詳細、リソースの詳細、脅威の詳細を確認し、この検出結果を理解できるよう手伝ってほしい。調査の各ステップで AWS CLI コマンドを提案し、得られる情報を説明したうえで、次のコマンドを示す前に私の確認を待ってほしい。すべての内容を現在のディレクトリの findings.md ファイルに記録し、検出結果の概要、調査手順、収集した証拠、修復のガイダンスを含めてほしい。技術者と経営層の両方に向けた構成にしてほしい」というものです。Kiro CLI へのプロンプトは日本語でも入力できます。
図 1 に示すように、この 1 つのプロンプトで調査のフレームワーク全体が決まります。ステップごとに承認を求めることで、AI のガイダンスを活用しながらも、主導権を手放さずに済みます。また、文書化を指示しておくことで、コンプライアンス要件に対応する監査証跡をリアルタイムで構築できます。
図 1: 最初の調査プロンプトと、GuardDuty のディテクター ID と検出結果の詳細を取得するために提案された最初のコマンドを表示した Kiro CLI インターフェイス
Kiro CLI は、ディテクター ID と検出結果の詳細をすべて取得することを提案しました。承認すると、Kiro CLI はコマンドを実行し、図 2 に示すような重要な情報を明らかにしました。主な検出結果は次のとおりです。
- タイプ: CryptoCurrency:EC2/BitcoinTool.B!DNS
- 重要度: HIGH (8.0)
- インスタンス: i-05447e6dacd0a7e7e (m5.xlarge)
- 脅威: pool.minergate.com への 617 件の DNS クエリ
- タイムライン: インスタンスの起動から 9 分後に開始
インスタンスの起動から 9 分後にマイニングアクティビティが始まっていることから、手動の操作ではなく、自動化された処理によるものであることが示唆されます。Kiro CLI が自動的に抽出して強調表示したこのタイムライン情報は、セキュリティチームがイベントのパターンを把握するのに役立ちます。
図 2: 重要度 HIGH の暗号通貨マイニングの検出を、脅威インジケーターとタイムラインとともに示す GuardDuty の検出結果の詳細
リソースと範囲の分析
次に Kiro CLI は、EC2 インスタンスの設定、セキュリティグループ、IAM 権限を調査し、他に検出結果がないかを確認することを提案しました。この先回りした提案から、Kiro CLI がセキュリティ調査のワークフローを理解していることがわかります。潜在的な影響を把握するには、権限のないユーザーが何をしたかだけでなく、典型的な脅威シナリオで次にどのような行動を取りうるかも調べる必要があることを、Kiro CLI は理解しているのです。
以下の情報は図 3 にも示されています。
インスタンスの設定: Kiro CLI はインスタンスの詳細を取得し、次の点を明らかにしました。
- Amazon Linux 2023 AMI
- インスタンスメタデータサービスバージョン 2 (IMDSv2) が必須 (良好なセキュリティポスチャ)
- パブリック IP アドレスがあり、アウトバウンドアクセスが無制限
- IAM インスタンスプロファイルがアタッチ済み
セキュリティグループの評価: Kiro CLI はセキュリティグループのルールを分析し、次の点を特定しました。
- インバウンドルールなし
- 0.0.0.0/0 へのアウトバウンドアクセスが無制限で、マイニングトラフィックが通過可能
IAM 権限の分析: Kiro CLI はインスタンスプロファイルとアタッチされたロールポリシーを調べ、重大なセキュリティリスクを発見しました。
- 重大な検出結果: EC2 インスタンスプロファイルに AdministratorAccess ポリシーがアタッチ済み
- 侵害されたインスタンスから AWS アカウントへのフルアクセスが可能
- アカウント全体が乗っ取られるおそれあり
観測されたアクティビティは暗号通貨マイニングでしたが、AdministratorAccess ポリシーがアタッチされていたため、権限のないユーザーがデータを流出させたり、バックドアを作成したり、他のリソースを侵害したりできた可能性があります。これは、最小権限の IAM ポリシーがいかに重要かを示しています。権限を限定しておけば、インスタンスが侵害された場合でも、潜在的な影響を抑えられます。
図 3: AdministratorAccess ポリシー、無制限のアウトバウンドアクセス、同時に発生している複数のセキュリティ検出結果を強調表示した、Kiro CLI によるインスタンス設定の概要
範囲の評価: Kiro CLI は他に予期しないアクティビティがないかを確認し、図 4 に示すように、この 1 つのインスタンスで 7 件のセキュリティ検出結果を発見しました。これは、マルチベクトル攻撃であることを示しています。
図 4: マルチベクトル攻撃を強調表示した、Kiro CLI による調査結果の概要
封じ込めのアクション
図 5 に示すように、Kiro CLI は、「AWS セキュリティインシデント対応ガイド」の封じ込め戦略に従って得られた知見に基づき、体系的な修復計画を提案しました。
図 5: Kiro CLI による調査の概要と、直ちに実施すべきアクションの推奨事項
インスタンスの隔離: Kiro CLI は、インバウンドルールとアウトバウンドルールを持たない隔離用セキュリティグループを作成するコマンドを生成し (図 6 を参照)、侵害されたインスタンスに適用しました。この封じ込めステップにより、証拠を破壊することなく新しい接続を遮断できます。ただし、セキュリティグループはステートフルであり、接続追跡を使用している点に注意が必要です。セキュリティグループのルールを変更しても既存の接続はすぐには中断されず、タイムアウトするまでパケットが許可され続けます。
つまり、権限のないユーザーがインスタンスに対してアクティブな接続を確立している場合、隔離用セキュリティグループを適用した後も、その接続がしばらく維持される可能性があります。アクティブな接続も含めてすべてのトラフィックを即座に遮断するには、ステートレスで接続状態を追跡しないネットワークアクセスコントロールリスト (NACL) も併用することを検討してください。セキュリティグループとは異なり、NACL はルールを適用した時点で既存の接続を遮断できます。NACL はサブネットレベルで動作するため、インスタンスレベルのセキュリティグループよりも影響範囲は広くなりますが、ネットワークの隔離をより確実にする追加の防御レイヤーとなります。
このシナリオから、重要な原則がわかります。Kiro CLI のような AI 搭載ツールは、適切なコマンドを生成して迅速な対応を支援してくれますが、こうした細かな違いを理解している人間がプロセスに関与すること (ヒューマンインザループ) が不可欠です。Kiro CLI はエッジケースに関する情報を完全には把握していない可能性があります。そのため、セキュリティの専門家が推奨事項を検証し、自身の専門知識と具体的な脅威シナリオに基づいて追加の対策を検討する必要があります。
図 6: インスタンスの隔離が完了し、インバウンドルールとアウトバウンドルールがないこと、およびコマンドアンドコントロール (C&C) 通信やマイニングアクティビティを含むすべてのネットワークトラフィックがブロックされていることを示す確認画面
権限の取り消し: Kiro CLI は、侵害された IAM ロールに全拒否ポリシーをアタッチするコマンドを生成しました (図 7 を参照)。AI アシスタントの説明によると、IAM の評価ロジックでは明示的な拒否が常に許可よりも優先されるため、AdministratorAccess ポリシーがアタッチされたままでも全拒否ポリシーが優先されます。これにより、フォレンジック分析のために元の設定を残したまま、すべての権限を即座に取り消すことができました。
図 7: IAM 認証情報の取り消しの確認画面と現在のステータスチェックリスト (ネットワークの隔離と IAM 認証情報の取り消しが完了し、フォレンジックスナップショットは作成待ち)
証拠保全
Kiro CLI は、環境に変更を加える前に、侵害されたインスタンスの Amazon EBS ボリュームのフォレンジックスナップショットを作成することを推奨しました (図 8 を参照)。進行中の脅威の封じ込めを急ぐあまり、このステップは見落とされがちですが、インシデント後の分析や、法的手続きに発展する可能性に備えるうえで欠かせません。
メモリ保全の判断: インスタンスはすぐには停止せず、隔離した状態で稼働させたままにすることにしました。EC2 インスタンスを停止すると、実行中のプロセス、ネットワーク接続、ロードされたマルウェア、暗号化キーなど、フォレンジック証拠を含む揮発性メモリの内容が失われます。すべてのネットワークアクセスをブロックする隔離用セキュリティグループにインスタンスを置くことで、脅威を無力化しながら、必要に応じてより詳細なフォレンジック調査を実施できる状態を保ちました。
揮発性メモリには、イベントの発生経緯を示す証拠、マルウェアのバイナリ、復号キー、C&C 通信など、インスタンスを停止すると失われてしまう情報が含まれていることがよくあります。この判断は、脅威の即時排除と徹底的な調査とのバランスを取ることの重要性を示しています。
揮発性メモリをキャプチャするには専用のツールと手法が必要です。Linux インスタンスでは LiME (Linux Memory Extractor) で物理メモリをキャプチャでき、Windows インスタンスでは Winpmem などのツールを使用できます。キャプチャしたメモリダンプは、オープンソースのメモリフォレンジックフレームワークである Volatility で分析できます。証拠収集の過程でシステムに変更が加わらないよう、フォレンジックツールはあらかじめシステムにインストールしておく必要があります。このプロセスを効率化するため、AWS は Amazon Linux EC2 インスタンス用のフォレンジックカーネルモジュールのビルドを自動化する方法に関するガイダンスを提供しています。
図 8: 証拠保全のために、目的、インシデント ID、重要度を含む適切なタグを付けたフォレンジックスナップショットの作成確認
CloudTrail の分析
侵害の全容を把握するため、Kiro CLI に CloudTrail ログの分析を依頼しました。AI アシスタントは利用可能な CloudTrail 証跡を特定し、侵害されたインスタンスから、その一時的な認証情報を使用して行われた API コールを検索するクエリを提案しました (図 9 を参照)。
CloudTrail の分析は、多くの場合、インシデント調査の中で最も時間のかかる作業です。アナリストは複雑なクエリを作成し、時系列に沿ってイベントを関連付ける必要があります。Kiro CLI はこのプロセスを自動化し、関連するログソースをすぐに特定して、適切なクエリを提案します。
図 9: 利用可能な CloudTrail 証跡を特定し、対象を絞ったクエリを提案する Kiro CLI
Kiro CLI の分析では、インスタンスの認証情報を使用した予期しない API コールは見つかりませんでした。IAM ユーザーの作成、S3 バケットへのアクセス、シークレットの窃取は、いずれも確認されませんでした。イベントは DNS クエリを介した暗号通貨マイニングアクティビティに限られていたとみられ、データの流出やラテラルムーブメント (横方向への侵害拡大) の証拠もありませんでした。
図 10: Kiro CLI による調査結果
この結果から、CloudTrail を徹底的に分析することの価値がわかります。初期の検出結果から脅威が限定的だと考えられる場合でも、調査を終了する前に、より広範な侵害が起きていないことを確認することが不可欠です。
プロアクティブな防御の構築
「AWS セキュリティインシデント対応ガイド」では、準備こそが効果的なインシデント対応の基盤であると強調しています。差し迫った脅威を封じ込めた後、Kiro CLI を使用して今後のインシデントに備えた自動アラートを設定し、準備フェーズを強化しました。
図 11 に示すように、自然言語で次のようにリクエストしました。
訳注: このプロンプトの内容は、「重要度が HIGH 以上の検出結果があれば [email] にメールを送信する通知システムを設定してほしい」というものです。
Kiro CLI は要件を理解し、Amazon SNS と EventBridge を組み合わせた、複数ステップからなるソリューションを提案しました。
- GuardDuty アラート用の SNS トピックを作成する
- メールアドレスをトピックにサブスクライブする
- 重要度が高い検出結果 (重要度 7.0 以上) でトリガーされる EventBridge ルールを作成する
- SNS トピックを EventBridge のターゲットとして設定する
- SNS トピックへの発行権限を EventBridge に付与する
自動アラートを構築するには、複数の AWS サービスとそれらの連携方法、正しい設定構文を理解しておく必要があります。Kiro CLI は、シンプルな自然言語のリクエストを、本番環境で使用できる完全なソリューションに変換します。
自動修正とテスト: 複雑な統合を設定する際には、権限の問題、誤った Amazon リソースネーム (ARN) の参照、JSON ポリシーの形式の誤りなどが原因でコマンドが失敗することがあります。Kiro CLI はこうした失敗を自動的に検出し、修正したコマンドを提案します。
図 11: SNS トピックの作成と EventBridge ルールの設定が完了し、重要度 HIGH および CRITICAL の検出結果で通知がトリガーされることを確認した、通知システムのセットアップ完了画面
例えば、「この通知システムをテストして、正しく動作していることを確認してください」とプロンプトで指示すれば、Kiro CLI にセットアップをテストさせることもできます。Kiro CLI は、SNS サブスクリプションが確認済みであること、EventBridge ルールが適切に設定されていること、IAM 権限が正しいことを検証し、設定ミスがあれば特定したうえで、テストイベントを発行してエンドツーエンドで動作を確認します。このインテリジェントなエラー処理により、セキュリティチームは手動でトラブルシューティングをしなくても、安心して自動化をデプロイできます。
再利用可能な調査ワークフローの作成
差し迫った脅威を封じ込め、プロアクティブな防御を整えた後は、Kiro CLI を使用して、今回の調査ワークフローを今後のインシデントでも使えるように体系化した、再利用可能なステアリングファイルを作成しました。ステアリングファイルは .kiro/steering/ に保存される Markdown ファイルです。Kiro CLI の永続的なメモリとして機能し、セキュリティチームが組織のナレッジを蓄積して対応手順を標準化するのに役立ちます。チームで共有するには、他のランブックと同じように、Git リポジトリに追加するか、Confluence などのドキュメントシステムに公開します。
調査全体の実行とステアリングファイルの生成は、同じ Kiro CLI セッション内で行うことをお勧めします。そうすれば、調査で実際に行った手順、コマンド、判断がそのままステアリングファイルに記録されます。プロセスは組織に合った方法で進めてください。ステアリングファイルには、汎用的なテンプレートではなく、実際のワークフローが反映されます。
Kiro CLI には次のように依頼しました。
訳注: このプロンプトの内容は、「今後のアナリストが同じ体系的なアプローチに従えるよう、今回の GuardDuty の調査ワークフローをまとめたステアリングファイルを作成してほしい」というものです。
Kiro CLI は、.kiro/steering/guardduty-incident-response.md に詳細なステアリングファイルを生成しました。このファイルには次の内容が含まれています。
- 「AWS セキュリティインシデント対応ガイド」に沿った調査フェーズ
- GuardDuty、Amazon EC2、IAM、CloudTrail の AWS CLI コマンドパターン
- 文書化の要件と承認ゲート
- 封じ込め、根絶、証拠保全の手順
Kiro CLI が作成したステアリングファイルの例を次に示します。
従来のインシデント対応プレイブックは静的なドキュメントであり、すぐに内容が古くなってしまいます。一方、Kiro CLI のステアリングファイルは実行可能なプレイブックです。AI 支援型の調査を一貫した手順でガイドしながら、個々のシナリオに合わせて柔軟に対応できます。ステアリングファイルの更新は独立したタスクではなくワークフローの一部となるため、常に最新の状態に保たれます。調査プロセスを見直したら、セッションの最後に Kiro CLI にステアリングファイルの更新を依頼してください。Kiro CLI が変更内容を反映するので、更新版を Git や Confluence でチームと共有すれば、全員が常に最新バージョンを使って作業できます。
まとめ
セキュリティインシデントには正確かつ迅速な対応が求められますが、従来の調査ワークフローではボトルネックが生じ、平均対応時間 (MTTR) が長くなってしまいます。「AWS セキュリティインシデント対応ガイド」のフレームワークに従い、Kiro CLI の AI を活用した機能を使用することで、インシデント対応を事後対応型の作業から、プロアクティブで十分に文書化された運用へと変えることができます。
この記事では、初期の検出と分析から封じ込め、根絶、復旧に至るまで、Kiro CLI がインシデント対応ライフサイクルの各フェーズをどのように迅速化するかを紹介しました。また、自然言語のプロンプトを使用して、GuardDuty の検出結果の調査、侵害されたリソースの分析、封じ込め策の実施、フォレンジック証拠の保全、今後のインシデントに備えた自動アラートの設定を行う方法を説明しました。ステアリングファイルを利用すれば、苦労して得た専門知識を再利用可能なワークフローとして残すことができ、スキルレベルを問わずすべてのアナリストに役立ちます。
アラートの調査、防御の構築、手順の文書化のいずれにおいても、Kiro CLI は、迅速な対応、継続的な学習、防御の強化、徹底した文書化を実現するための専門知識と自動化を提供します。コマンドが失敗したり設定に誤りがあったりしても、Kiro CLI が問題を特定して修正するため、トラブルシューティングにかかる時間を短縮できます。
本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。