Amazon Bedrock を使った AWS Systems Manager Session Manager ログの AI による異常検知

本記事は 2026 年 10 月 13 日に公開された “AI-powered anomaly detection for AWS Systems Manager Session Manager logs using Amazon Bedrock” を翻訳したものです。

運用エンジニアや開発者がマネージドノード上で AWS Systems Manager Session Manager のセッションを開始すると、実行したコマンドはすべてトランスクリプト（セッション中のコマンドとその出力の記録）に残ります。そのコマンドの 1 つ 1 つは、日常的な作業であることもあれば、セキュリティインシデントの最初の兆候であることもあります。数百台のノードが毎日数千件のコマンドを記録する規模になると、セキュリティオペレーションセンター (SOC) のチームがこれらのトランスクリプトを手作業で確認することはできません。1 日分のセッションの操作を解析するだけで何時間もかかり、被害が出るまで脅威に気付けないというセキュリティ上の死角が生まれます。目指すのは、分析の精度を保ち、コストを抑えながら、これらのトランスクリプトをほぼリアルタイムで分析することです。

以前のブログでは、生成 AI を使って Amazon FSx for Windows File Server の監査ログから異常を検知する方法を紹介しました。このブログでは、同じアプローチを Session Manager のトランスクリプトに適用します。Amazon Bedrock、AWS Lambda、Amazon Simple Storage Service (Amazon S3)、Amazon Bedrock AgentCore を使って、異常検知とセッション要約のソリューションを構築する方法を説明します。セキュリティアナリストは、セッションの分類結果を自動で受け取れます。不審なコマンドにはアラートが上がり、セッションの履歴は自然言語で問い合わせられます。

ソリューションの概要

このソリューションは 2 つのモジュールで構成されます。Module 1 は、セッションが終了するたびにそのセッションを自動で分析し、Suspicious または Critical に当たるものにフラグを立てます。Module 2 では、SOC チームがセッションの履歴を、必要なときに普段の言葉で問い合わせられます。2 つを組み合わせることで、自動検知と人の手による調査の両方をカバーします。

アーキテクチャ

ソリューションのアーキテクチャ。Module 1 は、Session Manager の各トランスクリプトを Amazon Bedrock で自動的に分析し、SOC にアラートを送れます。Module 2 では、アナリストが Amazon Bedrock AgentCore を通じてセッションの履歴を自然言語で問い合わせられます。

Module 1 の流れ

1. オペレーターが、マネージドノード（Amazon EC2、オンプレミス、ハイブリッド）で Session Manager のセッションを開始します。
2. セッション中、AWS Systems Manager (SSM) Agent はコマンドを Amazon CloudWatch Logs へリアルタイムにストリーミングし、トランスクリプトファイルをディスクに書き込みます。
3. セッションが終了すると（exit の入力、アイドルタイムアウト、明示的な終了など、終了の方法は問いません）、SSM Agent は完全なトランスクリプトを Amazon Simple Storage Service (Amazon S3) に自動でアップロードします。
4. S3 の PutObject イベントが AWS Lambda 関数を呼び出します。
5. Lambda 関数はトランスクリプトを読み取り、AWS Systems Manager からセッションのメタデータを取得して、その内容を Amazon Bedrock に送って分析させます。
6. Lambda 関数は、AWS CloudTrail でそのセッションの StartSession イベントも検索し、セッションを開始した IAM プリンシパルと送信元 IP アドレスを特定して、その両方をアラートに含めます。
7. Amazon Bedrock の基盤モデルがセッションを自動で分類し、構造化された分析結果を返します。
8. Lambda 関数は要約を Amazon DynamoDB に保存し、セッションが Suspicious または Critical の場合は Amazon Simple Notification Service (Amazon SNS) にアラートを発行します。

Module 2 の流れ

1. SOC アナリストが、Amazon Bedrock AgentCore ハーネスに自然言語で質問を送ります。
2. ハーネスは質問を解釈し、AgentCore ゲートウェイを通じて Lambda 関数を呼び出します。
3. Lambda 関数は、DynamoDB で要約を検索するか、CloudWatch Logs Insights のクエリを実行してセッションの生データを取得します。
4. ハーネスは、AI による文脈の説明と推奨事項を添えて結果を返します。

モデルによるセッションの分類

モデルは、各セッションを次の 3 つのカテゴリのいずれかに分類します。

訳注: Suspicious と Critical は、いずれも同じ Amazon SNS トピックに通知されます。通知のされ方に差はなく、件名に分類が入るだけです（サンプルの CloudFormation テンプレートで確認。2026-10-14 時点）。差があるのは分類の基準で、認証情報へのアクセスを試みた段階が Suspicious、認証情報の抽出や永続化の設置まで行われた段階が Critical です。

モデルが検知するパターンには、次のようなものがあります。

• 認証情報へのアクセス: /etc/shadow、AWS の認証情報、SSH キーの読み取りの試行
• 権限昇格: SUID バイナリの列挙、許可されていない sudo の使用、権限の変更
• データの持ち出し: 外部への HTTP リクエストと、機密ファイルへのアクセスの組み合わせ
• 偵察: ネットワークのスキャン、ホストの列挙、プロセスの一覧取得
• 永続化: crontab の変更、サービスの作成、authorized_keys の変更
• 防御の回避: 履歴の削除、監査ログの改ざん、セキュリティサービスの無効化

注: モデルは、入力されたコマンドだけでなく、セッションのトランスクリプト全体を確認します。コマンドの出力、操作の順序、セッション全体の文脈も考慮します。この動作は、「SessionAnalyzerFunction」Lambda 関数の分類用プロンプトで制御できます。このプロンプトを編集すれば、各カテゴリの基準を調整したり、独自のルールを追加したり、運用要件に合ったカテゴリを定義したりできます。

前提条件

このソリューションをデプロイする前に、以下のものがそろっていることを確認してください。

• AWS CloudFormation スタックをデプロイする権限を持つ AWS アカウント
• AWS Systems Manager Agent (SSM Agent) がインストールされたマネージドノード（Amazon EC2 インスタンス、またはハイブリッドアクティベーションしたサーバー）が少なくとも 1 台
• Amazon Bedrock の基盤モデル（Claude Haiku 4.5、または任意のモデル）へのアクセス。手順は Amazon Bedrock 基盤モデルへのアクセスの追加または削除を参照してください。

注: マネージドノードは、Session Manager を使えるようにセットアップしておく必要があります。つまり、SSM Agent がインストールされ、必要な権限を持つ IAM ロールがノードに付与され、Systems Manager と Amazon S3 のエンドポイントにネットワークで到達できる状態です。最近の Amazon EC2 の Amazon Linux と Windows の AMI には、SSM Agent があらかじめ含まれています。オンプレミスのノードの場合や、ネットワークとセットアップの手順全体については、Session Manager のセットアップを参照してください。

ウォークスルー

次の手順では、AWS CloudFormation テンプレートを使ってソリューションをデプロイし、その後オンデマンドの問い合わせ用インターフェイスを設定します。

ステップ 1: CloudFormation スタックのデプロイ

1. このブログの GitHub リポジトリから CloudFormation テンプレートをダウンロードします。
2. AWS CloudFormation コンソールを開きます。
3. スタックの作成を選び、新しいリソースを使用 (標準) を選びます。
4. テンプレートファイルのアップロードを選び、ダウンロードしたテンプレートを選択して、次へを選びます。
5. スタック名に ssm-session-anomaly-detection と入力します。
6. パラメータを設定します。
   • Alert notification endpoint: セキュリティアラートの送信先メールアドレスを入力します。
   • Alert notification protocol: 既定の email のままにするか、使いたいプロトコルを選びます。
   • Bedrock model for session analysis: 既定の global.anthropic.claude-haiku-4-5-20251001-v1:0 のままにするか、使いたいモデルを入力します。
     • 注: デプロイする前に、Amazon Bedrock コンソール（または aws bedrock list-foundation-models）で、このモデル ID が現在も提供されていて、お使いのリージョンで有効になっているかを確認してください。
   • RolePermissionAutomationSchedule: 既定の rate(30 minutes) のままにします。
7. 次へを選び、IAM リソースが作成されることを承認して、次へを選びます。
8. 送信を選びます。

スタックは次のリソースを作成します。

図 2. デプロイ後の CloudFormation スタックの出力。トランスクリプト用バケット、要約用テーブル、アラート用トピック、2 つの Lambda 関数、AgentCore のハーネスとゲートウェイなど、主要なリソースが一覧で表示される。

ステップ 2: SNS サブスクリプションの確認

スタックの作成が完了したら、メールの受信トレイで Amazon SNS からのサブスクリプション確認メールを探します。Confirm subscription を選ぶと、アラートの配信が有効になります。

ステップ 3: 自然言語でのソリューションへの問い合わせ (Module 2)

AgentCore ゲートウェイと AgentCore ハーネスは、CloudFormation スタックがすでに作成しています。この 2 つと、クエリを実行する Lambda 関数との接続も済んでいます。作成や設定の作業は必要ありません。

ハーネスを開くには、次の手順を実行します。

1. Amazon Bedrock AgentCore コンソールを開きます。
2. ナビゲーションペインで ハーネスを選びます。
3. SSMSecurityAnalyst という名前のハーネスを開きます。完全な名前は、スタックの出力の AgentCoreHarnessArn に表示されています。

このハーネス (SSMSecurityAnalyst) は、DynamoDB からセッションの要約と CloudWatch から生ログを読み取ります。質問ごとに適切なツールを選び、セキュリティ上の懸念点を指摘します。次の節で実際に試します。

ソリューションのテスト

デプロイが終わったら、2 つのモジュールの動作をテストします。

Module 1 のテスト: 自動分析

1. Session Manager のセッションを開始します。

aws ssm start-session --target <your-instance-id>

2. 一般的なコマンドをいくつか実行します。

#whoami
#df -h
#uptime
#exit

3. 30 秒ほど待ってから、DynamoDB テーブルでセッションの要約を確認します。

aws dynamodb scan --table-name SSMSessionSummaries-ssm-session-anomaly-detection \
  --filter-expression "itemType = :t" --expression-attribute-values '{":t":{"S":"SUMMARY"}}' \
  --query "Items[].{Session:sessionId.S,Classification:classification.S,Summary:summary.S}" --output table

このセッションは Normal に分類されるはずです。

4. 別のセッションを開始し、不審なコマンドを実行します。

#cat /etc/shadow
#find / -perm -4000 -type f 2>/dev/null | head -5
#curl http://example.com
#history -c
#exit

注: これらのデモ用コマンドは、まずテスト用のアカウントで実行してください。

5. 30 秒後、もう一度 DynamoDB を確認します。このセッションは Suspicious に分類され、アラートのメールが届くはずです。

出力

SNS のメールによるアラート通知のスクリーンショットです。

1. Critical なセッションのアラート

図 3. Critical なセッションに対する Amazon SNS のメールアラート。重大度がより高いセッションでも同じ形式のアラートが届く。この例では、ユーザーがパスワードファイルにアクセスし、セキュリティログの無効化を試みている。

2. Suspicious なセッションのアラート

図 4. Suspicious なセッションに対する Amazon SNS のメールアラート。分類、セッション ID、対象のノード、わかりやすい言葉で書かれた要約、判定の根拠になったフラグ、推奨事項が表示される。

Module 2 のテスト: オンデマンドの問い合わせ

AgentCore ハーネスのプレイグラウンドで、次のような質問を試してください。

• 「過去 24 時間の Suspicious なセッションをすべて表示して」
• 「ユーザー jsmith は今週何をした？」
• 「/etc/shadow へのアクセスを試みたセッションを探して」
• 「今日のすべてのセッションについて、セキュリティの状況を要約して」

「過去 24 時間の Critical と Suspicious のセッションをすべて挙げて、重大度の順に並べて」というプロンプトの実行例

図 5. アナリストがセッションの履歴について自然言語で質問し、Amazon Bedrock AgentCore ハーネスが回答している。

多層的なセキュリティアプローチ

このソリューションは、多層的なセキュリティ戦略の一部として使うと最も効果を発揮します。

クリーンアップ

継続的な料金の発生を避けるため、次の手順でリソースを削除します。

1. AWS CloudFormation コンソールを開きます。
2. 作成したスタックを選択します。
3. 削除を選びます。

スタックを削除すると、リソースも自動的に削除されます。

まとめ

Session Manager は、チームが実行するすべてのコマンドを記録します。規模が大きくなると、トランスクリプトは 1 日に数千件にもなります。そのすべてを読める SOC チームはなく、その隙間に実際のインシデントが潜みます。

このソリューションを使えば、その隙間を埋めやすくなります。セッションが終了すると、Amazon Bedrock がトランスクリプトを確認し、Normal、Suspicious、Critical のいずれかに分類します。短い要約は DynamoDB に保存されます。Suspicious と Critical のセッションについては、ユーザーと送信元 IP を明記したメールが送られます。さらに詳しく調べたいときは、AgentCore ハーネスがわかりやすい言葉で質問に答え、セッションの履歴を代わりに検索します。

強みは文脈を踏まえられることです。curl コマンドが単独で実行されたなら、日常的な操作です。しかし、/etc/shadow を読み取り、履歴を消したあとに実行された同じコマンドは、そうではありません。モデルはセッション全体を見て判断するため、ルールベースのチェックでは見落とすパターンも捉えられます。

数分で使い始められます。CloudFormation テンプレートをデプロイし、Session Manager のログの出力先をトランスクリプト用のバケットに設定すれば、分類結果が届き始めます。

著者について

Rohan Vashi

AWS の Technical Account Manager で、DevOps、CloudOps（モニタリングとオブザーバビリティを含む）、生成 AI を専門としています。エンタープライズのお客様と協力して、安全でスケーラブルなソリューションを構築しています。運用上の優秀性と AI/ML による自動化に重点を置き、クラウドの導入とエージェント型 AI への取り組みを支援しています。AWS Certified Solutions Architect – Professional と AWS Certified Generative AI Developer – Professional の認定を保有しています。組織がクラウドのオブザーバビリティにどう取り組むかを変えるようなソリューションを作るのが好きです。

翻訳はソリューションアーキテクトの村田が担当しました。