aws-recipe-user 大柳です。
前回に引き続き、ファイル監査の設定を行います。
前回記事：EC2でファイル監査を設定する（auditd設定編）
後半の今回はCloudWatch Logsを設定し、特定のログが出たらメールに通知するよう設定を行います。
CloudWatch Logsの導入
CloudWatch Logsの導入手順を説明します。
IAMロールの設定
CloudWatch Logsを利用する前提条件として、インスタンスにCloudWatch Logsを使用できる権限を割り当てる必要があります。
既存のEC2インスタンスでCloudWatch Logsを使えるようにするには、①インスタンスのイメージからIAMロールを割り当てたインスタンスを新しく作るか、②IAMロールをアタッチする必要があります。
手順は以下を参照ください。
クイックスタート: 既存の Amazon EC2 インスタンスに CloudWatch Logs エージェントをインストールして設定する – Amazon CloudWatch ログ
http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/QuickStartEC2Instance.html
マネージメントコンソールからも、既存のEC2インスタンスにIAMロールを簡単にアタッチ、変更できるようになりました | Amazon Web Services ブログ
https://aws.amazon.com/jp/blogs/news/easily-replace-or-attach-an-iam-role-to-an-existing-ec2-instance-by-using-the-ec2-console/
エージェントのインストール
次にCloudWatch LogsのエージェントをEC2にインストールします。
以下コマンドで導入できます。
|
1 |
sudo yum install -y awslogs |
エージェントの設定
/etc/awslogs/awscli.confを編集して利用するリージョンを指定します。
今回はap-northeast-1（アジアパシフィック東京）を指定しました。
|
1 2 3 4 |
[plugins] cwlogs = cwlogs [default] region = ap-northeast-1 |
ログ監視設定の追加
次に /etc/awslogs/awslogs.conf を編集してauditdのログ対象に追加します。
auditログに出力される時刻の形式はUnix時刻形式のためCloudWatch Logsエージェントで対応できないので、datetime_formatは設定しません。
|
1 2 3 4 5 6 |
[/var/log/audit/log/audit.log] log_group_name = DevServer/audit/audit_log log_stream_name = {instance_id}_audit_log file = /var/log/audit/audit.log initial_position = start_of_file buffer_duration = 5000 |
エージェントの起動
CloudWatch Logsエージェントを起動します。
|
1 |
sudo service awslogs start |
ログ転送の確認
次に実際にログが転送されていることを確認します。
サービスから[CloudWatch]を選択します。
[ログ]タブを選択し、ロググループからファイル監査用に作成したロググループを選択します。
ログストリームを選択します。
ログが転送されていることを確認できました。ログのフィルタも可能です。ここでは file_audit を含むものだけを表示しています。
アラームの設定
次にファイル監査のログが出た場合のアラームをメールにて通知できるように設定を行います。
ロググループの画面に戻って、設定したいロググループのメトリクスフィルタ列を選択します。
[メトリクスフィルタの追加]を選択します。
フィルタパターンを設定します。
今回はアクセス権限のあるユーザ（root、uid=0）以外のユーザがアクセスし、ファイル監査ログ（key=file_audit）が出力された場合に検知する設定にします。
|
1 |
[,,,,,,,,,,,,,,uid != "uid=0" ,,,,,,,,,,,,key = "key=\"file_audit\""] |
[]（角カッコ）で囲った場合、スペース文字を区切りとしてログデータをカラムに分割します。
auditログの形式上、uidが15カラム目、keyが28カラム目にあたるので、uidが0以外の場合(つまりroot以外の場合)、keyがfile_auditの場合にフィルタでヒットする設定にしています。
フィルタパターンの設定については以下に記載があります。
フィルタとパターンの構文 – Amazon CloudWatch ログ
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html
下部のテキストエリアにサンプルログをペーストすれば、フィルタのテストもできます。
フィルタの設定と確認ができたら、[メトリクスの割り当て]を選択します。
次にフィルタの名前、メトリクスの情報を入力します。
[フィルタの作成]を選択するとフィルタが作成されます。
アラームの作成
引き続きアラームの設定を行います。[アラームの作成]を選択します。
アラームの名前と説明を入力し、閾値には以下のように設定します。
また、アクションとして通知したいメールアドレスを指定しました。
設定ができたら[アラームの作成]を選択するとアラーム設定は完了です。
アラーム発生時アクションの確認
実際に権限のないユーザがアクセスした場合にアラームがメール通知されることを確認します。
ec2-user（アクセス権限なし）で view ConfidentialInfo.txt を実行してファイルへのアクセスを試みます。
通知先のメールを確認すると以下のようにメール通知が届いていることが確認できました。
まとめ
Linuxのauditd機能とAWSのCloudWatch Logsを利用してファイル監査を行い、インシデント検知時にはメールで通知することができました。
CloudWatch Logsではアラームの発生は検知できますが、詳細なメッセージはマネージメントコンソールで確認する必要があります。また、auditログにはuidしか出ないので、ユーザ名をログからは確認することができません。検知時間もUnix時間で出力される課題もあります。
このあたりの課題はfluentdのようなログ収集基盤を利用して、時刻変換、ユーザID変換の仕組みを作ることで解消できそうですので、後日試してみたいと思います。
次回もお楽しみに。
