AWSにおけるサーバ操作ログの自動取得の実装のポイント
1. はじめに
こんにちは!株式会社SHIFTでインフラアーキテクトをやっているNHです。
AWS構築の際のセキュリティ要件として、サーバOSの操作ログの取得が必要な場合があるかと思います。 とあるプロジェクトにおいて、AWS Systems ManagerのSession Manager機能とAmazon CloudWatch Logsを利用して、EC2のサーバ操作ログの自動取得を実装しました。そのため、今回はその備忘も兼ねて、構築手順と実装時のポイントをご紹介したいと思います。 また、操作ログは、CloudWatch Logsだけでなく、S3にも出力できるため、2つの出力先の比較もご紹介します。
2.Session Managerとは
Session Managerとは、AWS Systems Managerの機能の1つです。 Session Manager を使用することで、AWS Consoleのブラウザ上からEC2(LinuxやWindows)にログインし、操作が可能になります。その機能の中で、操作ログをCloudWatch LogsやS3に出力し、保存することが可能となります。 また、Session Managerインバウンドポートを開いたり、踏み台ホストを維持したり、SSH キーの管理したりする必要がないため、安全かつ監査可能なノード管理を実現できる特徴があります。
https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/session-manager.html
3.今回の構成
今回の構成は、以下の構成図のように作成しています。
アカウント内でインターネットに出れない構成になっているため、VPCエンドポイントを利用した構成になっています。
対象のEC2(Amazon Linux)はプライベートサブネットに配置
VPCエンドポイントを作成し、SSMのSession ManagerによるEC2への接続をできるようにする
CloudWatch Logsへのログ転送は、VPCエンドポイントを利用
CloudWatch LogsはAWS KMSでCMKを作成し、暗号化
4.構築方法
VPC、サブネット、EC2は既に構築されている前提における手順を記載します。
SSMのSession Manager接続の設定方法から記載していますので、CloudWatch Logsの設定を見たい方は、[4-2.操作ログ出力設定]から確認してください。
また、今回はセキュリティレベルが高い環境であったため、VPCエンドポイントやログの暗号化を実施してますが、不要な場合はそれらの手順をスキップしてください。
4-1.SSMのSession Manager接続の設定
1. 対象のEC2にSSM Agentをインストールする。(今回の構成では、AmazonLinuxのため省略)
※Amazon Linux以外のOSを利用する場合は、下記などを参考にインストール指定ください。
https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/sysman-manual-agent-install.html
2. EC2用のIAMロールを作成し、IAMポリシーとして「AmazonSSMManagedInstanceCore」を追加し、EC2にアタッチ
3 . 以下3つのVPCエンドポイントを作成し、EC2のあるサブネットにアタッチ。
com.amazonaws.ap-northeast-1.ssm
com.amazonaws.ap-northeast-1.ssmmessages
com.amazonaws.ap-northeast-1.ec2messages
VPCエンドポイントのセキュリティグループは、全て下記のように設定します。
インバウンド :EC2のあるプライベートサブネットのHTTPS通信を許可
アウトバウンド:全ての通信を許可
SSMのSession Manager接続の設定における設定のポイントは、以下だと思います。
正しいVPCエンドポイントをEC2インスタンスのあるサブネットにアタッチする
エンドポイントのセキュリティグループを正しく設定する(特にアウトバウンドを許可するのを忘れがち)
4-2.操作ログ出力設定
KMSを利用し、CloudWatch Logs用の暗号化キーを作成
作成したKMSのポリシーを編集し、CloudWatch Logsサービスを利用者として追加。
下記のように、Allow use of the key"の部分に、"Service": "logs.ap-northeast-1.amazonaws.com"を追加します。
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": "CMK作成時に利用者として指定したロールorユーザ",
"Service": "logs.ap-northeast-1.amazonaws.com"
}
3. CloudWatchのメニューからロググループを作成します。
作成時に、KMSを選択することができるため(オプション)、事前に作成した暗号化キーのARNを入力します。
4. CloudWatchのPutEventを許可するIAMポリシーを作成
下記のように、作成したロググループに対する"logs:PutLogEvents"の権限を追加します。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "logs:PutLogEvents",
"arn:aws:logs:ap-northeast-1:アカウント名:log-group:ロググループ名:*"
]
}
]
5. EC2用のIAMロールに、4で作成したIAMポリシーとAWS管理ポリシーの"CloudWatchAgentServerPolicy"をアタッチします。
6. CloudWatch Logs用のVPCエンドポイント(com.amazonaws.ap-northeast-1.logs)を作成し、EC2のあるサブネットにアタッチします。
VPCエンドポイントのセキュリティグループは、SSM用のエンドポイント同様に、下記のように設定します。
インバウンド :EC2のあるプライベートサブネットのHTTPS通信を許可
アウトバウンド:全ての通信を許可
7. AWS System Manager > Session Manager から設定のタブに遷移し、編集からCloudWatchの項目を編集します。CloudWatch loggingの設定は、下記を参照に入力してください。
操作ログ出力設定における設定のポイントは、以下だと思います
CloudWatch Logsを暗号化する場合は、KMSのポリシーにLogsの利用権限を記載する
CloudWatch Logs用のVPCエンドポイントの作成を忘れずに行うこと
以上で、設定は完了です。 AWS System Manager > Session Managerからインスタンスの接続を行うと、操作ログがCloudWatchのロググループから参照できるようになります。イメージとしては下記のように出力されます。
出力ログの一覧
操作ログの中身
5.ログ出力先の比較
今回は、CloudWatch Logsをログの出力先として指定しましたが、S3にも出力が可能です。 CloudWatch LogsとS3を保存先としての各観点で比較したのが下記の表です。 (費用は、2023年8月22日時点の東京リージョンものです)
S3標準に比べると収集コスト分追加費用がかかりますが、出力ログの検索性や視認性という意味で CloudWatch Logsの方が優れていると感じました。特に、過去の操作ログ全てから特定のコマンドを実行有無を知りたいという場合に、GUIから全ログファイル一括で検索できる(「全てのログストリームの検索」 から可能)は、実際の運用でも有用だと感じました。 操作ログの観点だけで、どちらかを検討するケースは少ないかと思いますが、比較検討の一助になれば幸いです。
6.まとめ
ログ出力の設定は、VPCエンドポイントや暗号化の権限、IAM権限を適切に設定することがポイント
ログ保存先として、CloudWatch LogsとS3を比較した場合、コスト性はS3、視認・検索性はCloudWatch Logsが優れる
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて(コーポレートサイト)
https://www.shiftinc.jp/
SHIFTのサービスについて(サービスサイト)
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/
PHOTO:UnsplashのAlina Grubnyak