RDS監査ログを設定しよう

1. RDS監査ログを設定しよう
2. 本日お話しすること 監査ログとはなにか 監査ログはなぜ重要か 監査ログの取り方（主にOracle） 考慮事項 ❌話さないこと 具体的な料金 各DBエンジンごとの詳細な解説 RDS以外の監査ログについて
3. 監査ログとは 一言で言うと 「誰が、いつ、どのDBに接続し、どんなSQLを実行したか」記録したログ RDSはデフォルトでは監査ログを取得しません。 エンジンごとに明示的な設定を行う必要があります。
4. ログの種類（MySQLの場合） MySQLの場合、監査ログを含めて以下の5種類のログがあります。 ログ種別 何が記録されるか 主な用途 監査ログ 誰が何をしたか セキュリティ・監査対応 エラーログ 起動・停止・エラー 障害調査 一般ログ 接続と受け取ったSQL全部 デバッグ iam-db-auth-error ログ IAMデータベース認証の失敗 IAM認証のトラブルシュート スロークエリログ long_query_timeを超えたSQL 性能改善
5. ログの種類（MySQL以外） 各DBエンジンで取得できるログの種類が異なります。 採用エンジンでどのログを取得するべきか、検討する必要があります。 エンジン RDS for MySQL RDS for MariaDB Aurora MySQL 取得できるログ エラー、スロークエリ、一般（全般） 、監査、IAMデータベース認証エラー、インス タンス、バイナリログ エラー、スロークエリ、一般、監査、IAMデータベース認証エラー、バイナリログ エラー、スロークエリ、一般、監査（Advanced Auditing） 、インスタンス、バイナ リログ RDS for PostgreSQL PostgreSQLログ（pgAuditの出力もここに混ざる） 、アップグレードログ、IAMデー タベース認証エラーログ Aurora PostgreSQL PostgreSQLログ（pgAuditの出力もここ） RDS for Oracle RDS for SQL Server RDS for Db2 アラートログ（テキストとXML） 、監査ファイル、リスナーログ、トレースファイ ル、OEMエージェントログ エラーログ、エージェントログ、トレースファイル、ダンプファイル、監査ログ （SQL Server Audit） 診断ログ、通知ログ、監査ログ（Db2 Audit）
6. 監査ログはなぜ重要か 規制・コンプライアンス要件 金融機関・官公庁など多くの業界は、規制要件を満たすために 監査ログを保持する必要がある 内部不正・誤操作の追跡 誤操作が起こった場合の外部、内部からのアクセス・操作履歴 を確認することができる インシデント発生時の影響範囲の特定 情報漏洩が疑われたときのいつ・誰が・どのテーブルに・どの ようなSQL文実行が行われたか
7. CloudTrailではだめなの？ CloudTrailは、AWSのAPI操作を記録します。 RDSインスタンスの作成・削除・パラメータ変更などは記録されますが、 RDSのDB内部の操作は記録されません。 DB内部の操作（SELECT/INSERT/DELETE/LOGONなど）を記録するには 監査ログの有効化が必要です。
8. 監査ログの設定 エンジンごとに設定方法が異なります。 多くはパラメータグループやオプショングループの設定で有効化 ◆RDS for Oracleの場合（標準監査） Oracleの場合、パラメータグループで設定します。 監査ログをどのような形式で出力するか設定します。
9. 監査ログの出力形式（Oracle） デフォルトは「-」であり、無効化されています。 os OS上のファイルに出力 db/db,extended データベース内の表に出力 xml/xml,extended XMLファイルに出力
10. 監査ログの有効化（Oracle） パラメータグループの設定だけでは、ログはAWS側に出力されません。 Oracleの場合、3ステップで有効化を行います。 AWS上でパラメータグループの設定 DB側の設定で、各ユーザの「セッションの監査」を有効化 どのログをCloudWatch Logsに出力するか設定
11. ログのエクスポート Oracleの例では、auditを有効化すると以下のようなロググループに出力 されます。 aws/rds/instance/[インスタンス名]/audit 他種類のログについても同様（/alertなど…）
12. 保持期間 基本的にCloudWatch Logsへのエクスポートを推奨しています。 DB上のログは自動的にローテーションされるためです。 エンジン インスタンス上の保持 RDS for MySQL（監査ログ） SERVER_AUDIT_FILE_ROTATE_SIZE（既定1MB）に達する とローテーション。SERVER_AUDIT_FILE_ROTATIONS（既 定9）の世代数を超えると古いファイルから削除 RDS for MySQL（エラー・一般・スロークエリ） 1時間ごとにローテーション。2週間より古いログを削除。3種 の合計サイズが割り当てストレージの2%を超えると古いもの から削除 RDS for MariaDB（エラー・一般・スロークエリ） 1時間ごとにローテーション。24時間より古いログを削除。 2%の制限はMySQLと同じ RDS for PostgreSQL rds.log_retention_periodで制御。既定4320分（3日） 、設定 範囲は1440〜10080分 RDS for Oracle 監査ファイルは既定7日
13. 保持期間の調整 DBインスタンス上に保持する期間やローテーション世代数・サイズは、 本番稼働1、2週間動かしてログ量とFreeStorageSpaceの推移を見なが ら調整を推奨しています。 ログが想定より多い場合、DBストレージが逼迫する可能性があります。 ログファイルはデータと同じ割り当てストレージを消費 RDSはストレージがfullになると、自動停止 ストレージ拡張かオートスケーリングの有効化が必要
14. エクスポートの例 CloudWatch Logsへのエクスポートを推奨しています。 （運用担当者が調査しやすいため）
15. CloudWatch Logsでのログ調査 （人間が調査する場合）CloudWatch Logs Insightでログ調査を行います。
16. 有効化前に知っておくべき注意点 ◆ログの量が想像以上に増える 監査ログはSQL1つごとに1行以上を出力します。 全SQLを記録すると、想定以上にコストが発生する可能性があります。 対策 具体策 イベントを絞る ログイン監査だけならCONNECTのみ、更新監査なら QUERY_DML_NO_SELECT（MariaDB） ユーザーを絞る rdsadminなどヘルスチェック系ユーザーを除外 クエリ長を制限する SERVER_AUDIT_QUERY_LOG_LIMITで上限を設定 ストレージを監視する FreeStorageSpaceにCloudWatchアラームを設定
17. 有効化前に知っておくべき注意点 ◆何のために監査ログを記録するのか考える ・流出や不正アクセスがあったときにどのレコードが見られたのか判定する →SELECT文 ・破壊活動があった際のフォレンジックの一部として →CREATE, UPDATE, DELETE, ALTERなど
18. 有効化前に知っておくべき注意点 ◆設定変更に再起動が必要 監査ログは、オプショングループ・パラメータグループの設定が関与してきま す。設定変更にはDB再起動が必要です。検証環境で手順の整理を！ ◆オプショングループやパラメータグループは個別に用意を AWSデフォルトのオプショングループやパラメータグループをDBに設定する ことも可能。 しかし！デフォルトのものは設定変更不可のため、個別で用意したほうがよい
19. まとめ RDSはデフォルトで監査ログを取らない DB側、パラメータグループ・オプショングループの設定が必要 CloudWatch Logsエクスポートの設定も明示的に有効化 CloudTrailとRDS監査ログは別物。どっちも大事。 インスタンス上のログは数日から2週間程度で自動削除される CloudWatch Logs, S3へエクスポートしよう 全SQL記録すると容量とコストで肥大化する 本番でびっくりしないように、検証環境で試してみよう 何のために監査ログを記録するのか考え、記録が必要なSQLを絞る