はじめに

こんにちは、第三SAチームのamaebiです。
今回はプライベートサブネットにあるAmazon EC2にSession Managerを使ってアクセスし、その操作ログをAmazon S3に保存し、確認する方法について紹介します。
操作ログを残す選択肢としてAmazon CloudWatch Logsがございますが、敢えてAmazon S3を選択した理由についても軽く触れていきます。
・Amazon CloudWatch Logs を使用してセッションデータをログ記録する (コンソール)

なお、プライベートサブネットにあるAmazon EC2にアクセスするまでの手順は、本ブログでは取り扱わないため、以下の記事をご覧ください。

関連記事

AWS Systems Manager Session Managerを利用してプライベートにあるAmazon EC2環境に接続する

なぜS3にログを残すのか

では、なぜSession Managerの操作ログをAmazon CloudWatch Logsではなく、S3バケットに格納する必要があるのか。
その理由は、Amazon CloudWatch Logsよりも保管コストが安いからです。

Amazon CloudWatch LogsとAmazon S3の料金表で見比べてみましょう。
※東京リージョンでのコスト比較です。

Amazon CloudWatch

引用：Amazon CloudWatch 料金表

Amazon S3 標準

引用：Amazon S3 の料金

その他の要因によって多少のコスト変動はありますが、Amazon S3に保存した方が全体的にコストパフォーマンスが高いことが分かります。
更にSession Managerの操作ログの他にも、エラーログやアクセスログ等のログを長期保存する場合、Amazon S3標準からS3 Glacierにストレージクラスを変更することで更なるコスト削減に繋がります。

構成図

今回は、以下のような構成でSession Managerからログを取得します。

使用リソース

今回の検証環境で使用するリソース情報は以下の通りです。

• Amazon EC2
  • OS：Amazon Linux 2023
  • インスタンスタイプ：t2.micro
  • ストレージタイプ：gp3
  • ストレージ容量：8GiB
• IAM Role
  • ポリシー1：AmazonSSMManagedInstanceCore
  • ポリシー2：AmazonS3FullAccess
• VPCエンドポイント
  • Session Manager用エンドポイント
    • インターフェースエンドポイント1：com.amazonaws.ap-northeast-1.ssm
    • インターフェースエンドポイント2：com.amazonaws.ap-northeast-1.ec2messages
    • インターフェースエンドポイント3：com.amazonaws.ap-northeast-1.ssmmessages
  • S3用エンドポイント
    • ゲートウェイエンドポイント：com.amazonaws.ap-northeast-1.s3
• Amazon S3
  • ストレージクラス：標準
  • 暗号化タイプ：SSE-S3

手順

大まかな手順としては以下の通りです。
※先ほども述べたようにプライベートサブネットにあるAmazon EC2にアクセスするまでの手順は、本ブログでは取り扱いません。

1. アタッチされているIAMロールにポリシー追加
2. ゲートウェイタイプのエンドポイント追加
3. 操作ログ格納用のS3バケット作成
4. S3 ロギング設定
5. 確認

それでは、詳細な手順を見ていきましょう。

アタッチされているIAMロールにポリシー追加

ここではAmazon EC2の操作ログがS3バケットに格納できるようアクセス権限を付与します。

マネジメントコンソール ＞ EC2 ＞ インスタンス ＞ 該当インスタンスを選択し、詳細からアタッチされているIAMロールをクリックします。

IAMロールのページに遷移したら、許可タグから 許可を追加 ＞ ポリシーをアタッチ をクリックします。

検索欄からAmazonS3FullAccessと検索し、該当ポリシーを選択します。
その後、許可を追加します。

許可ポリシーがアタッチされていることを確認します。

ゲートウェイエンドポイント追加

プライベートサブネットに配置されているAmazon EC2とS3バケットとの疎通ができるよう、ゲートウェイエンドポイントを設置します。

マネジメントコンソール ＞ VPC ＞ エンドポイント ＞ エンドポイントの作成をクリックします。

エンドポイント名入力後、サービスカテゴリから「AWS のサービス」を選択します。
サービスの検索欄からcom.amazonaws.ap-northeast-1.s3と検索し、該当するエンドポイントを選択します。
その際、必ずエンドポイントタイプがGatewayであるものを選択してください。

対象のAmazon EC2が配置されているVPCとプライベートサブネットが紐づけられているルートテーブルを選択します。

その他の設定はデフォルトのまま、エンドポイントの作成をクリックします。
エンドポイント一覧から先ほど作成したゲートウェイエンドポイントを確認します。

操作ログ格納用のS3バケット作成

今回は検証の為、デフォルト設定のまま作成します。
※アクセス許可設定はバケット内の情報を守る上で必須ですので、ご自身の要件に合った設定をお願いします。
・アクセスコントロールのベストプラクティス

マネジメントコンソール ＞ S3 ＞ バケット ＞ バケットを作成をクリックします。

バケット名を入力し、先ほども述べたように設定はデフォルトのままバケットを作成します。

先ほど作成したバケットに操作ログを格納するためのフォルダを作成しておきます。
サーバー側の暗号化はデフォルトの暗号化設定を使用します。

S3 ロギング設定

Session Managerの操作ログをS3バケットに格納するためのロギング設定を行います。

マネジメントコンソール ＞ Systems Manager ＞ Session Manager ＞ 設定タグから編集をクリックします。

S3 loggingを有効化にします。
暗号化されたS3バケットのみを許可を有効化にして、先ほど作成したS3バケット名と操作ログ格納用フォルダ名を入力します。その後、設定を保存します。

設定タグから上記の設定が反映されていることを確認します。

確認

実際に操作ログがS3バケットが格納されるのか確認します。

先ほどの画面からセッションタグを選択し、セッションの開始をクリックします。

ターゲットインスタンスから該当するインスタンスを選択し、Start sessionをクリックします。

セッションがスタートするまで、数分ほど時間がかかります。
EC2インスタンスにアクセスできました。

試しに適当なコマンドを入力してみます。

sh-5.2$ whoami
ssm-user
sh-5.2$
sh-5.2$
sh-5.2$
sh-5.2$ pwd
/usr/bin
sh-5.2$
sh-5.2$
sh-5.2$
sh-5.2$ cd /home/ssm-user/
sh-5.2$
sh-5.2$
sh-5.2$
sh-5.2$ ls -la
total 20
drwx------. 2 ssm-user ssm-user 99 May 9 10:13 .
drwxr-xr-x. 4 root root 38 May 9 06:58 ..
-rw-------. 1 ssm-user ssm-user 208 May 9 10:13 .bash_history
-rw-r--r--. 1 ssm-user ssm-user 18 Jan 28 2023 .bash_logout
-rw-r--r--. 1 ssm-user ssm-user 141 Jan 28 2023 .bash_profile
-rw-r--r--. 1 ssm-user ssm-user 492 Jan 28 2023 .bashrc
-rw-------. 1 ssm-user ssm-user 1279 May 9 10:12 .viminfo
sh-5.2$
sh-5.2$
sh-5.2$
sh-5.2$ vi hogehoge
sh-5.2$
sh-5.2$
sh-5.2$
sh-5.2$ cat hogehoge
hogehoge
sh-5.2$
sh-5.2$
sh-5.2$
sh-5.2$ ls -la
total 24
drwx------. 2 ssm-user ssm-user 115 May 9 10:17 .
drwxr-xr-x. 4 root root 38 May 9 06:58 ..
-rw-------. 1 ssm-user ssm-user 208 May 9 10:13 .bash_history
-rw-r--r--. 1 ssm-user ssm-user 18 Jan 28 2023 .bash_logout
-rw-r--r--. 1 ssm-user ssm-user 141 Jan 28 2023 .bash_profile
-rw-r--r--. 1 ssm-user ssm-user 492 Jan 28 2023 .bashrc
-rw-------. 1 ssm-user ssm-user 1727 May 9 10:17 .viminfo
-rw-r--r--. 1 ssm-user ssm-user 9 May 9 10:17 hogehoge
sh-5.2$
sh-5.2$
sh-5.2$
sh-5.2$ exit

操作ログが格納されているか確認するため、セッションを終了します。
※セッションが終了した時に、S3バケットに操作ログが格納されるようになっています。

セッション終了後、S3バケットの操作ログ格納用フォルダの中身を確認します。
先ほどの操作ログが格納されていることが確認できます。

最後にログの中身を確認していきましょう。

ダウンロードされたログファイルをテキストエディタ等で開いても文字化けが発生してしまうため、以下のコマンドを使用してPowerShellからログファイルを確認します。

Get-Content -Encoding utf8 "ログファイルのパス名"

PowerShellから確認した出力結果がこちらです。

Script started on 2024-05-09 10:19:55+00:00 [<not executed on terminal>]
sh-5.2$

sh-5.2$ whoami


ssm-user

sh-5.2$


sh-5.2$


sh-5.2$


sh-5.2$ pwd


/usr/bin

sh-5.2$


sh-5.2$


sh-5.2$


sh-5.2$ cd /home/ssm-user/


sh-5.2$


sh-5.2$


sh-5.2$


sh-5.2$ ls -la


total 20

drwx------. 2 ssm-user ssm-user   99 May  9 10:13 .

drwxr-xr-x. 4 root     root       38 May  9 06:58 ..

-rw-------. 1 ssm-user ssm-user  208 May  9 10:13 .bash_history

-rw-r--r--. 1 ssm-user ssm-user   18 Jan 28  2023 .bash_logout

-rw-r--r--. 1 ssm-user ssm-user  141 Jan 28  2023 .bash_profile

-rw-r--r--. 1 ssm-user ssm-user  492 Jan 28  2023 .bashrc

-rw-------. 1 ssm-user ssm-user 1279 May  9 10:12 .viminfo

sh-5.2$


sh-5.2$


sh-5.2$


sh-5.2$ vi hogehoge


sh-5.2$


sh-5.2$


sh-5.2$


sh-5.2$ cat hogehoge


hogehoge

sh-5.2$


sh-5.2$


sh-5.2$


sh-5.2$ ls -la


total 24

drwx------. 2 ssm-user ssm-user  115 May  9 10:17 .

drwxr-xr-x. 4 root     root       38 May  9 06:58 ..

-rw-------. 1 ssm-user ssm-user  208 May  9 10:13 .bash_history

-rw-r--r--. 1 ssm-user ssm-user   18 Jan 28  2023 .bash_logout

-rw-r--r--. 1 ssm-user ssm-user  141 Jan 28  2023 .bash_profile

-rw-r--r--. 1 ssm-user ssm-user  492 Jan 28  2023 .bashrc

-rw-------. 1 ssm-user ssm-user 1727 May  9 10:17 .viminfo

-rw-r--r--. 1 ssm-user ssm-user    9 May  9 10:17 hogehoge

sh-5.2$


sh-5.2$


sh-5.2$


sh-5.2$ exit


exit


Script done on 2024-05-09 10:19:55+00:00 [COMMAND_EXIT_CODE="0"]

操作ログが無事取得できていることが確認できました。

最後に

Session Managerの操作ログをAmazon S3に保存し、確認する方法についての紹介でした。
長期的に操作ログを残しておくことで、何か問題が発生した場合でもトレーサビリティは担保することができます。
Amazon S3に保存することでコストメリットの恩恵も受けられますので、こういった運用方法を検討するのもいいかもしれません。