セッションマネージャーの操作ログを取得する方法について整理してみる

IE課で研修中の河本と申します。弊社では中途入社でも4カ月の研修期間が設けられておりますが、早いもので残り1カ月となりました。

研修の中で、AWS Systems Manager Session Manager（以下セッションマネージャー）の操作ログについて考える機会があったため、ここで整理したいと思います。

前提

前提条件は以下とします。

接続対象であるEC2のOSはAmazon Linux2023とする。
OS側の機能（.bash_historyやscriptコマンド等）は対象外とする。

ロギングの種類

セッションマネージャーで操作ログを取得する場合は保管先の選択がポイントになり、以下の2パターンあります。

保管先	特徴
Amazon CloudWatch Logs	・ストリーミングでのログ取得が可能（コマンド実行ごとにCloudWatch Logsへ送信される）・S3と比較すると高価なため長期保存には不向き
Amazon S3	・ストリーミングでのログ取得が不可（セッション切断後にログファイルが生成される）・ログを安価に保存可能なため長期保管に最適

基本的にはS3をログ保管先とし、ストリーミングを活用して他のAWSサービスと連携したい場合のみCloudWatch Logsを選択するのがいいでしょう。

実際に取得してみる

保管先ごとにどのようにログが取得されるか見てみます。

CloudWatch Logsに保管した場合

まずはCloudWatch Logsでの操作ログを見てみましょう。念のためIDやユーザ名は黒塗りしています。

リージョンやIAMユーザ、OSユーザも記録されており、監査目的としては冗長な印象を受けますね。sessionDataキーに実行コマンドおよび結果が記載されていますが、空行までもれなくロギングしてくれるようです。

S3に保管した場合

次にS3へ保管した場合はどうなるか見てみましょう。
※誤ってログファイルを削除してしまったため、別のファイルの中身を記載します。

イメージするログファイルの内容ではないでしょうか。監査目的の場合はこれで十分だと思います。なお、セッション接続したIAMユーザ名はファイル名から判断することが可能です。

Script started on 2023-12-11 04:29:37+00:00 [<not executed on terminal>]
[?2004hsh-5.2$ 
[K
sh-5.2$ 
[?2004l
[?2004hsh-5.2$ 
[?2004l
[?2004hsh-5.2$ history
[?2004l
    1  history
    2  free
    3  free -m
    4  cat /proc/cpuinfo 
    5  exit
    6  history
[?2004hsh-5.2$ 
[?2004l
[?2004hsh-5.2$ 
[?2004l
[?2004hsh-5.2$ exit
[?2004l
exit


Script done on 2023-12-11 04:29:37+00:00 [COMMAND_EXIT_CODE="0"]