Session Managerで操作ログを完全記録する3つの設定

はじめに

今月誕生日の人、おめでとうございます🎉 エデュケーショナルサービス課の森純子です。

Session Managerを使っている方は多いと思いますが、操作ログの記録まで設定している方は意外と少ないのではないでしょうか。

実際に設定してみたところ、コマンドと出力がリアルタイムで記録され、SSHでは得られないレベルの操作ログが残せることがわかりました。

本記事では、その設定手順を3つにまとめて紹介します。

対象読者：EC2の運用でSSHを使っていて、AWS Systems Manager Session Manager（以下、Session Manager）への移行に踏み切れていないエンジニア、移行を検討しているエンジニア、または、Session Managerは使っているが操作ログの記録設定をまだしていないエンジニア

本記事で使用するAWSサービスの、略称と正式名称を先に記します：

略称	正式名称
Session Manager	AWS Systems Manager Session Manager
CloudWatch Logs	Amazon CloudWatch Logs
AWS KMS	AWS Key Management Service
SSM Agent	AWS Systems Manager Agent

SSHとSession Managerの比較

Session Managerは、EC2インスタンスにSSHやキーペアなしで接続できるAWSのマネージドサービスです。まずはSSHとの違いを確認しておきましょう。

項目	SSH	Session Manager
キーペア管理	必要	不要
インバウンドポート開放	22番が必要	不要
操作ログ	OS側で別途設定が必要	CloudWatch Logs/S3に記録可能
操作者の特定	キーペア共有時は困難	IAMユーザー/ロール単位で特定可能
ファイル転送	SCP/SFTPが利用可能	S3経由で代替可能

なお、Session Managerは接続機能だけであれば特別なログ設定は不要ですが、操作ログの記録はデフォルトでは有効になっていません。

有効にしないと、誰が何を実行したかの記録が残らないため、調査やトラブルシューティングに対応できません。

以下の3つの設定で、操作ログの記録を有効にしましょう。

3つの設定

Session Managerの操作ログを記録するには、以下の3つの設定が必要です。

IAMロールへの権限追加
Session Managerのログ設定（CloudWatch Logs）
Session Managerのログ設定（Amazon S3）

前提条件

EC2インスタンスにSSM Agentがインストール済みで、ステータスがOnlineであること
EC2インスタンスにIAMロール（インスタンスプロファイル）がアタッチされていること
IAMロールに AmazonSSMManagedInstanceCore ポリシーがアタッチされていること
Session Managerログ専用のCloudWatch Logsロググループを事前に作成しておくこと（Session Managerの設定画面からは新規作成できません）
ログの暗号化を行う場合は、AWS KMS キー（カスタマーマネージドキー、対称キー）を事前に作成し、ロググループに関連付けておくこと（キーポリシーでCloudWatch Logsサービスへの権限付与が必要です）

なお、Amazon Linux 2023にはSSM Agentがプリインストールされています。インストールされていない場合は、以下のコマンドでインストールできます。

sudo dnf install -y amazon-ssm-agent
sudo systemctl enable amazon-ssm-agent && sudo systemctl start amazon-ssm-agent

設定1：IAMロールへの権限追加

EC2にアタッチされているIAMロールに、CloudWatch LogsとS3への書き込み権限を追加します。なお、IAMロールには、AmazonSSMManagedInstanceCore ポリシーが既にアタッチされている前提です（前提条件を参照）。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogStream",
                "logs:PutLogEvents",
                "logs:DescribeLogGroups",
                "logs:DescribeLogStreams"
            ],
            "Resource": "arn:aws:logs:<リージョン>:<アカウントID>:log-group:<ロググループ名>:*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetEncryptionConfiguration"
            ],
            "Resource": [
                "arn:aws:s3:::<バケット名>",
                "arn:aws:s3:::<バケット名>/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation"
            ],
            "Resource": "arn:aws:s3:::<バケット名>"
        }
    ]
}

重要：s3:GetEncryptionConfiguration を忘れると、セッション開始時に「Couldn't start the session because we are unable to validate encryption on Amazon S3 bucket」というエラーが発生します。

設定2：Session Managerのログ設定（CloudWatch Logs）

AWS Systems Managerコンソールを開く
左メニューから「Session Manager」を選択
「設定」タブ→「編集」をクリック
「一般的な詳細設定」の「KMS 暗号化」を有効にし、KMSキーを選択する（セッション中の通信データを暗号化します）
「CloudWatch ログ記録」の「有効にする」にチェック
ログ記録オプションで 「セッションログをストリーミング (Recommended)」 を選択
必要に応じて「暗号化を強制」にチェック（KMSで暗号化されたロググループのみ許可する場合）
「Find Log Groups」でロググループを指定する
- 「リストからロググループを選択する」：既存のロググループから選ぶ場合
- 「テキストボックスにロググループ名を入力する」：ロググループ名を直接入力する場合 ※Session Managerログ専用のロググループを事前に作成しておくことを推奨します
「保存」をクリック

「セッションログをストリーミング」を選択する理由： ストリーミングはリアルタイムでログが送信されるため、セッション中に接続が切れてもそこまでのログが残ります。「セッションログをアップロード」はセッション終了時にまとめて送信するため、異常終了時にログが失われる可能性があります。

「KMS 暗号化」について： 「一般的な詳細設定」のKMS暗号化はセッション中の通信データを暗号化する設定で、「CloudWatch ログ記録」の暗号化を強制はログの保存先が暗号化されているかを検証する設定です。目的が異なるため、両方有効にすることを推奨します。

設定3：Session Managerのログ設定（Amazon S3）

同じ設定画面の「S3 ログ記録」セクションまでスクロール
「S3 にセッションログを送信」の「有効にする」にチェック
必要に応じて「暗号化を強制」にチェック（暗号化されたS3バケットのみ許可する場合）
「S3 バケットを選択」でバケットを指定する
- 「リストからバケット名を選択します」：既存のバケットから選ぶ場合
- 「テキストボックスにバケット名を入力する」：バケット名を直接入力する場合
「S3 のキープレフィックス」は任意。サブフォルダに出力したい場合のみ入力
「保存」をクリック

なお、同じ画面に「Linux シェルプロファイル」「Windows シェルプロファイル」の設定があります。セッション開始時に特定のディレクトリへの移動や環境変数の設定、注意書きの表示などを自動実行できる機能ですが、今回のログ記録の設定では割愛します。

また、Session Managerにはアイドルセッションタイムアウトの設定があり、一定時間操作がないと自動的にセッションが切断されます。セッションが開きっぱなしになるリスクを防げるため、セキュリティ面でも安心です。

CloudWatch Logsはリアルタイム監視に、S3は長期保管に適しています。両方有効にしておくのがおすすめです。コストが気になる場合は、CloudWatch Logsの保持期間を短く（例：30日）設定し、古いログはS3だけに残す運用が良いと思います。

実際のログの中身

設定が完了したら、Session Managerでセッションを開始してコマンドを実行してみます。

KMS暗号化を有効にしている場合、セッション開始時に「This session is encrypted using AWS KMS.」と表示されます。

CloudWatch Logsのログ

CloudWatch Logsには、コマンドごとにJSON形式でログが記録されます。

{
    "eventVersion": "1.0",
    "eventTime": "2026-04-01T10:35:01Z",
    "awsRegion": "ap-northeast-1",
    "target": {
        "id": "i-xxxxxxxxxxxx"
    },
    "userIdentity": {
        "arn": "arn:aws:sts::123456789012:assumed-role/RoleName/user@example.com"
    },
    "runAsUser": "ssm-user",
    "sessionId": "user@example.com-xxxxxxxxxxxxxxxxxxxxx",
    "sessionData": [
        "sh-5.2$ whoami",
        "ssm-user"
    ]
}

ログから読み取れる情報：

誰が： userIdentity.arn でIAMユーザー/ロール単位で特定可能
どのEC2に： target.id でインスタンスIDを特定可能
いつ： eventTime でタイムスタンプを確認可能
何を実行したか： sessionData にコマンドとその出力が記録

S3のログ

S3にはセッション全体が1つのテキストファイルとしてまとめて保存されます。CloudWatch LogsがコマンドごとのJSON形式であるのに対し、S3のログはセッション全体の記録です。

Script started on 2026-04-10 00:05:12+00:00 [<not executed on terminal>]
sh-5.2$ whoami
ssm-user
sh-5.2$ hostname
ip-10-0-2-128.ap-northeast-1.compute.internal
sh-5.2$ date
Thu Apr  9 23:52:05 UTC 2026
Script done on 2026-04-10 00:05:12+00:00 [COMMAND_EXIT_CODE="0"]

S3のログにはセッションの開始・終了時刻と終了コードも記録されるため、セッション全体の流れを把握するのに適していると思います。

SSHでは、OS側で別途設定しない限りこのレベルの操作ログは残りません。しかもキーペアを共有している場合、誰がログインしたかの特定すら困難です。

さらに、SSHでOS側にログを残す設定をしたとしても、ログはEC2インスタンスのEBS内に保存されるため、EC2インスタンスやEBSが破棄されるとログも一緒に失われます。

また、複数のインスタンスがある場合は、個別にログインしてログを確認しなければなりません。

Session ManagerでCloudWatch LogsやS3にログを残す設定にしておけば、EC2インスタンスが破棄されてもログは残りますし、複数インスタンスのログをまとめて参照することもできます。

プライベートサブネットのEC2でも利用可能

Session ManagerはプライベートサブネットのEC2でも利用できます。ただし、SSMのエンドポイントへの通信経路が必要です。

方法は2つあります。

NAT ゲートウェイ経由でインターネットに出る
- 設定がシンプルで、SSM以外のインターネット通信も必要な場合に適していることが多い
VPCインターフェイスエンドポイントを3つ作成する
- com.amazonaws.ap-northeast-1.ssm
- com.amazonaws.ap-northeast-1.ssmmessages
- com.amazonaws.ap-northeast-1.ec2messages
- インターネットに出ないのでセキュリティが高く、NAT ゲートウェイより安価な場合が多い

SSM以外にインターネット通信が不要な環境ではVPCエンドポイント、他の用途でもインターネット通信が必要な環境ではNAT ゲートウェイが適している場合が多いです。要件に合わせて選択してください。

注意：VPCインターフェイスエンドポイントを作成する際、「プライベートDNS名を有効にする」がデフォルトでオンになっています。有効にすると、VPC内からそのサービスへの通信が全てエンドポイント経由に切り替わるため、既存のサービス通信に影響が出る可能性があります。本番環境では、検証環境で事前に影響を確認してから導入してください。

まとめ

Session Managerの操作ログを記録するために必要な設定は以下の3つです。

IAMロールへの権限追加（CloudWatch LogsとS3への書き込み権限、特に s3:GetEncryptionConfiguration を忘れずに）
CloudWatch Logsのストリーミング設定（リアルタイムでコマンドと出力を記録）
S3のログ設定（長期保管用）

EC2の運用でSSHを使っていて、Session Managerへの移行に踏み切れていない方や、移行を検討している方の参考になれば幸いです。

セキュリティ上の注意点

Session Managerのログには、実行したコマンドだけでなく、その出力もそのまま記録されます。例えば、env コマンドで環境変数を表示したり、cat で設定ファイルを開いた場合、パスワードやAPIキーなどの機密情報がログに残ってしまいます。

ここで注意すべきは、CloudWatch LogsのKMS暗号化は「保存時の暗号化」であり、閲覧権限の制御とは別、ということです。 CloudWatch Logsコンソールにアクセスできる人には、暗号化の有無に関わらずログの中身が見えます。

Session Managerを利用できる人を限定している環境では、ログの閲覧者も同様に制限しないと、本来アクセスできないはずのメンバーに機密情報が見えてしまう可能性があります。

対策として、本稿では以下を推奨します。

ロググループ単位でIAMアクセスを制限する： CloudWatchFullAccess や CloudWatchReadOnlyAccess のような広い権限ではなく、セッションログ用のロググループのARNを指定した最小権限のポリシーを使う
KMS暗号化を設定する： 閲覧制御とは別に、保存データの保護として設定する
ログの保持期間を設定する： 不要になったログが残り続けないようにする
運用ルールを整備する： 本番環境で機密情報を含むコマンド（env、catによる設定ファイル表示など）の実行に関するルールを定める
ロググループの削除保護を有効にする： ログが誤って削除されるのを防ぐ
データ保護を検討する： ログ内の機密データ（メールアドレス、IPアドレスなど）を自動検出してマスキングする機能です。追加料金が発生しますが、本番環境では有効にすることを推奨します