EC2でファイル監査を設定する(auditd設定編)

大柳です。

個人情報や企業の営業秘密など機密性の高い情報をシステムで扱う場合には、権限を持ったユーザのみファイルにアクセスできる設定を行うだけでなく、誰が、いつ、どのようにして、そのファイルにアクセスしたかの監査情報を求められることがあります。ファイル監査と呼ばれます。
Linuxではauditdを用いてファイル監査を行うことができます。今回はauditdを利用してAWSのマネージドサービスだけでファイル監査ログを取得し、不正アクセスがあった場合に即時に通知する仕組みを作ってみます。

今回のゴール

Amazon Linuxにauditdでファイル監査の設定を行い、CloudWatch Logsにログを連携して、監視できるようにします。
記事は2回に分けて、前半はauditdの設定までを説明します。

auditdとは

Linux上のカーネルレベルでシステムコールを監視することで、各種イベントを記録するコンポーネントです。
今回利用するファイルアクセスの監視だけでなく、ユーザが実行したコマンド、セキュリティイベント(ログイン失敗など)のように幅広くセキュリティ監視に利用できます。
なお、システムコールの都度、フィルター処理が動くので、パフォーマンスへ影響が出る可能性がありますので、利用にあたっては注意が必要です。

詳しい仕組みは以下の記事が分かりやすいです。
第5章 システム監査
https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/7/html/Security_Guide/chap-system_auditing.html#sec-audit_system_architecture

auditd設定手順

ではauditdの設定を行っていきます。

auditdのインストール確認

Amazon Linuxには標準でauditdがインストール済です。
念のため、インストールされていること、起動していることを確認しましょう。

インストールされているかの確認

起動しているかの確認

auditdの設定

auditdが動いていることが確認できたら、auditdの設定を行います。
ログの出力場所や出力形式に関する設定は /etc/audit/auditd.conf にあります。
今回はログの出力先がデフォルト値(/var/log/audit/audit.log)になっていることを確認して設定は変えません。
/etc/audit/auditd.confの設定内容

監査のルールに関する設定は /etc/audit/audit.rules にあります。
今回は、以下の設定を行います。
①システムコール監査の有効化(Amazon Linuxではデフォルトで無効)
-a never,taskの行をコメントアウト(先頭に#を付ける)

②監視するファイルパスの指定
-w /home/ec2-user/audit_test/ConfidentialInfo.txt -p rwxa -k file_audit

各オプションの意味は以下の通りです。
-w /home/ec2-user/audit_test/ConfidentialInfo.txt : 監視するファイルパスの指定。今回はファイルを指定していますが、ディレクトリ指定も可能です。
-p rw : ログ記録するパーミッションの指定。今回はRead、Writeを指定しています。
-k file_audit : ログに対するキー指定オプションが設定できます。後からログを検索しやすくするためにfile_audit というキーを指定しました。

audit.rulesは以下のように設定しました。

/etc/audit/audit.rulesの設定内容

ファイル監査テスト用のファイルを作成

テスト用にrootユーザで
/home/ec2-user/audit_test/ConfidentialInfo.txtを作成し、所有者(root)のみアクセスできる権限(700)を付けました。

auditdのリスタート

service auditd restart でauditdをリスタートすると設定が反映されます。

/var/log/audit/audit.log を確認するとログが出力されていることが確認できます。
システムコールを拾うため、今回設定したファイルパスへのアクセス以外の情報(例えばrestart時のログ)も出力されています。

ログ出力の確認

ファイル監査が動き始めたので、実際にログが出る操作をやってみましょう。

rootユーザで書き込み操作

rootユーザ(アクセス権限あり)で echo ‘Bad Data’ >> ConfidentialInfo.txt を実行します。
grepで file_audit に絞ると以下のメッセージの出力を確認できます。
uid=0(root)での/bin/bashの実行が成功したこと(success=yes)が確認できます。

ec2-userで読み込み操作
次にec2-user(アクセス権限なし)で view ConfidentialInfo.txt を実行します。
uid=500(ec2-user)での/bin/viの実行が失敗したこと(success=no)が確認できます。

なお、auditログのフォーマットの詳細は以下サイトに記載があります。
5.6. Audit ログファイルについて
https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Understanding_Audit_Log_Files.html

uidしか出ないのでユーザ名が分からず、タイムスタンプもUnix時間(1487591778だと2017/02/20 20:56:18)で表示されるので、可読性は良くありません。
また、上記のログ確認時にはgrepで絞ってみましたが、ログには他のメッセージも多数出力されています。システムコールを幅広く拾ってしまうためです。
ログ監視運用時には、必要なログを漏れなく効率よく検知できるように、監視ルールの設計が重要です。

まとめ

今回はAmazon Linuxでのauditdの設定とログ確認までを行いました。ログの可読性はあまりよくありませんが、簡単にファイル監査の設定を行うことができました。次回はCloudWatch Logsを使ってauditdのログ監視を設定します。

次回もお楽しみに。

次回記事:EC2でファイル監査を設定する(CloudWatch Logs設定編)

この記事を書いた人

aws-recipe-user