RDSの監査ログ出力でハマったポイントまとめ

とある目的がありRDSの監査ログをCloudWatchlogsに出したいという要件がありました。思ったより苦戦したのでまとめたいと思います。

RDSの監査ログを有効にする

まず、これだけでは圧倒的に足りないのですが、普通これだけだと思うのではないでしょうか。 RDS->データベース->データベース名->Modify DB Cluster->ログのエクスポート

コンソール画面のRDSの変更で監査ログにチェックを入れて登録することができます。できるんですが、これを登録しても何も起きません。

DBクラスターのパラメータグループを変更する

上記の監査ログの設定はチェックを入れて変更している必要はあるのですが、同時にパラメータグループも変更する必要があります。

server_audit_logging

server_audit_loggingというパラメータがデフォルトで0になっているのでこれを1に変更します。このパラメータの適用タイプはdynamicなので再起動を伴わずに即時変更されます。

server_audit_logs_upload

同じくserver_audit_logs_uploadというパラメータがデフォルトで0になっているのでこれを1に変更します。このパラメータの適用タイプもdynamicなので再起動を伴わずに即時変更されます。

これで十分かなと思っていたのですが、もう1つパラメータグループを変更する必要がありました。

server_audit_events

このserver_audit_eventsはCONNECT, QUERY, QUERY_DCL, QUERY_DDL, QUERY_DML, TABLEの中で監査する対象のイベントを選ぶことができます。複数イベントの入力が可能です。

それぞれの意味としては

Connect・・・接続の成功と失敗を記録します。ユーザー情報が含まれます。 Query・・・構文や権限のエラーを含めてクエリとクエリ結果を記録します。 Query_DCL・・・Queryと同様ですがDCLクエリ(GRANT、REVOKEなど)のみ記録します。 Query_DDL・・・Queryと同様ですがDDLクエリ(CREATE、ALTERなど)のみ記録します。 Query_DML・・・Queryと同様ですがDMLクエリ(INSERT、UPDATEなど)のみ記録します。 Table・・・クエリの実行で影響を受けたテーブルを記録します。

です。他にもserver_audit_excl_usersで除外するユーザー名(rdsadminとか）、逆にユーザー名を指定するserver_audit_incl_usersなどのパラメータもあります。デフォルトだとrdsadminによるシステムログが大量に出るので追加した方が良さそうでした。

ここまでは公式ドキュメントにも記載があるのでよく読めば問題ないかと思います。

ハマったポイント

上記までやってみたのですが、数日後様子をみると、ログがでていないどころか、自動でできるはずのロググループすらありませんでした。そこでサポートに問い合わせてみたところ下記のような回答がありました。

お客様が現在ご使用の Aurora MySQL 1.14.1 では、三日間監査ログへの書き込みが発生しないか、100 MB 程度を超える書き込みが発生しない場合、過去のログが削除され、新たな監査ログの書き込みが行われなくなる問題が発生しております。調査の結果、今回の事象もこちらの事象に該当している可能性が高いと判断しております。こちらの問題は、Aurora MySQL 1.17.8 以降および 2.03.3 以降で修正されていますので、回避策といたしましては、バージョンアップをご検討いただけますと幸いでございます。この度は、Aurora の問題によりお客さまにご迷惑をおかけし、誠に申し訳ございません。

なんと、三日間監査ログへの書き込みが発生しないか、100 MB 程度を超える書き込みが発生しない場合、過去のログが削除されたあげく、新たな監査ログの書き込みが行われなくなる問題があるそうです。3日間書き込みがないと削除されるのも監査ログとしてどうなんだという気がしますが、しかもその後の監査ログが書き込みされなくなるというのはだいぶ問題な気がします。

特定のバージョンだけで発生するようですのでバグということでしょうか。回避策はバージョンアップということですが、そもそも今回の監査ログを仕込む目的がバージョンアップするか否かを決めるための調査なので、バージョンアップするという選択肢はありませんでした。

別の回避策として提案されたのは

お客様のユースケースにより、Aurora MySQL のバージョンアップが難しいようでしたら、一度監査ログの設定を無効化して再度有効化することで改善されることが確認されておりますので、現在のバージョンのままで以下の手順の回避策をお試しいただけます。

パラメータグループで再度、監査ログの設定を無効化して有効化するという方法で良いそうです。具体的には

1. クラスターパラメータグループの `server_audit_logging` を "0" に変更する => AWS CLI にて、DBClusterParameterGroupStatus が "applying" から "in-sync" になることをご確認ください $ aws rds describe-db-clusters --db-cluster-identifier --query 'DBClusters[0].DBClusterMembers' 2. クラスターパラメータグループの `server_audit_logging` を "1" に変更する => 手順 1 と同様に、AWS CLI にて、DBClusterParameterGroupStatus が "applying" から "in-sync" になることをご確認ください $ aws rds describe-db-clusters --db-cluster-identifier --query 'DBClusters[0].DBClusterMembers'

この指示通り、server_audit_loggingをもう一度0に戻して、さらに1にするという手順を行ったところ、無事に監査ログが吐かれるようになりました。サポートの説明では一度監査ログの出力に成功してたけど、その後3日間出力がなかったので削除されていたのではないかという話でした。

まとめ

レアケースかと思いますが、公式ドキュメントを読んだだけでは分からない罠がありましたので誰かの役に立てれば幸いです。