aws・4分で読める

Aurora 監査についてまとめ

Aurora MySQL の監査ログで迷いやすい server_audit_events を、監査目的別に推奨構成で整理する。証跡の網羅性とログ量・性能のバランスを実務向けに解説。

#AWS#Aurora#RDS#監査#セキュリティ#ログ

Aurora 監査についてまとめ

結論から言うと、監査目線では 最低でも CONNECT,QUERY_DDL,QUERY_DCL は有効化を検討します。 さらに「誰がデータを変更したか」まで追うなら QUERY_DML_NO_SELECT（または環境に応じて QUERY_DML）を追加します。

監査とは何か（この文脈での意味）

ここでいう監査は、ざっくり言うと 「後から第三者が見ても、操作の正当性を説明できる状態を作ること」 です。 セキュリティ事故が起きた時だけでなく、平常時にも「統制が機能しているか」を確認する目的があります。

Auroraの監査ログで特に問われるのは次です。

  • だれが（ユーザー/ロール）
  • いつ（時刻）
  • どこから（接続元）
  • 何をしたか（接続、権限変更、DDL/DML）
  • その操作は承認されたものか（変更管理との突合）

つまり、監査ログは「単なる技術ログ」ではなく、説明責任を果たすための証跡として扱います。

監査要件は会社によって変わる

監査で「どこまで取るべきか」は、業種や規制、会社のリスク許容度によって変わります。 そのため、server_audit_events に唯一の正解はありません。

差が出る主な要因:

  • 業種・規制: 金融/医療/公共などは要求される証跡粒度が厳しい
  • 扱うデータ: 個人情報・機密情報の有無で監査強度が変わる
  • 運用体制: 監査ログをレビューできる人員・プロセスがあるか
  • コスト/性能要件: ログ量増加をどこまで許容できるか

実務では、まず最低ラインを満たし、必要に応じて段階的に強化する方針が現実的です。

監査ログに「基準」はあるのか

あります。 業界標準（フレームワーク）+ 法規制 + 社内規程 を組み合わせて要件化します。

代表的な参照先と使いどころは次です。

資料使いどころ要点
NIST SP 800-53 Rev.5 / AU: Audit and Accountability
https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final		監査ログに含めるべき項目の根拠監査記録には、イベント種別、発生時刻、発生場所、発生元、結果、関連主体・オブジェクト等を含める考え方を示す。
CIS Controls v8 / Control 8: Audit Log Management
https://www.cisecurity.org/controls/v8		ログ管理全体の方針攻撃の検知・理解・復旧に役立つイベントを収集し、アラート、レビュー、保持することを重視。
ISO/IEC 27001:2022 Annex A 8.15 Logging
https://www.iso.org/standard/27001		ISMS・社内監査向け重要イベントのログ化、ログ保護、定期確認を求める。全イベント記録ではなく、リスクに応じた選定が前提。
OWASP Top 10 A09: Security Logging and Monitoring Failures
https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/		アプリ/セキュリティ観点の根拠ログイン、失敗ログイン、高価値取引など監査可能イベントが記録されないことを主要リスクとして挙げる。
PCI DSS v4.0.1 Requirement 10
https://www.pcisecuritystandards.org/document_library?document=PCI_DSS_v4		保持期間・運用要件の参考監査ログ履歴を少なくとも12か月保持し、直近3か月は即時分析可能な状態で保持する要件がある。
NIST SP 800-92（ログ管理ガイド）
https://csrc.nist.gov/pubs/sp/800/92/final		ログ管理の実務設計収集、保管、保護、分析、運用体制まで含めたログ管理の実践ガイド。
AWS公式: Aurora MySQL Advanced Auditing
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Auditing.html		Aurora実装の一次情報server_audit_events や server_audit_incl_users など、実装パラメータの定義と挙動を確認できる。

つまり「基準がない」のではなく、基準は存在するが、採用する基準セットと厳しさが会社ごとに違うというのが実態です。

前提: これはAurora MySQLの話

server_audit_events は、Aurora MySQL の Advanced Auditing（MariaDB Audit Plugin系）で使う主要パラメータです。 Aurora PostgreSQL は仕組みが異なり、一般的には pgaudit などで設計します。

まず押さえるべき考え方（監査目線）

監査で必要になるのは、主に次の3点です。

  • 識別: だれが接続したか（認証・接続）
  • 権限変更の追跡: だれが権限やスキーマに変更を加えたか
  • データ変更の追跡: だれが重要データを更新・削除したか

この観点で server_audit_events を選ぶと、設定の迷いが減ります。

server_audit_events の主要イベント

イベント何が取れるか監査上の重要度注意点
CONNECT接続/切断、認証関連高基本的に常時有効推奨
QUERY_DDLCREATE/ALTER/DROP などスキーマ変更高変更管理との突合に必須
QUERY_DCLGRANT/REVOKE など権限変更高特権乱用の追跡に必須
QUERY_DML_NO_SELECTINSERT/UPDATE/DELETE（読み取り除く）中〜高変更監査に有効、ログ量は増える
QUERY_DMLDML全般（環境によりSELECT含む扱いに注意）高（網羅）ログ量/コスト/性能影響が大きくなりやすい
QUERYほぼ全クエリ非常に高（網羅）通常運用では過剰になりやすい
TABLEテーブルアクセス詳細用途限定高頻度アクセスで肥大化しやすい

※ 利用可能イベントや挙動は Aurora MySQL のバージョンで差が出る場合があります。適用前に対象バージョンの公式ドキュメントで確認してください。

監査目的別の推奨セット

1) まず外さない最小構成（多くの本番環境向け）

CONNECT,QUERY_DDL,QUERY_DCL

この構成で、最低限の監査証跡（接続・スキーマ変更・権限変更）を押さえられます。 ログ量と性能影響のバランスがよく、最初の導入点として現実的です。

2) 変更追跡を強める構成（監査強化）

CONNECT,QUERY_DDL,QUERY_DCL,QUERY_DML_NO_SELECT

データ更新・削除の追跡が必要な場合はこちら。 「参照（SELECT）まで全部は要らないが、改ざん・誤更新は追いたい」ケースに向きます。

3) フル監査寄りの構成（限定適用推奨）

CONNECT,QUERY_DDL,QUERY_DCL,QUERY_DML,QUERY,TABLE

網羅性は高いですが、ログ量が急増しやすく、費用・運用負荷・性能影響が大きくなります。 常時適用より、対象DB/対象期間を絞る運用が安全です。

結局どれを選べばいいか（そのまま使える結論）

「自分はどれを設定すべきか」を先に決めたい場合は、次で選べます。

あなたの状況推奨 server_audit_events
一般的な本番環境（まず迷わず始めたい）CONNECT,QUERY_DDL,QUERY_DCL,QUERY_DML_NO_SELECT
規制が厳しく、閲覧操作（参照）まで追跡したいCONNECT,QUERY_DDL,QUERY_DCL,QUERY_DML,QUERY
性能・コストを最優先しつつ最低限の証跡が必要CONNECT,QUERY_DDL,QUERY_DCL

SELECTを含めるべきかの判断

次のいずれかに当てはまるなら、SELECTを含む監査（QUERY_DML または QUERY）を検討します。

  • カード会員データや高機密データへの「閲覧行為」自体が監査対象
  • 内部不正対策として「誰が読んだか」を追跡する必要がある
  • 監査法人/規制で参照アクセスの証跡提出を求められる

当てはまらない場合は、通常は QUERY_DML_NO_SELECT までで十分です。

まずこの設定で開始（推奨）

CONNECT,QUERY_DDL,QUERY_DCL,QUERY_DML_NO_SELECT

この設定は、監査で重要な「接続」「権限変更」「スキーマ変更」「データ変更」を押さえつつ、SELECTのログ爆発を避けやすいバランス案です。

実務での推奨運用

1. いきなりフル監査にしない

まずは最小構成で開始し、監査要件に応じて段階的に追加します。 最初から QUERY や TABLE を有効化すると、ログのノイズとコストが先に問題化しがちです。

2. CloudWatch Logs / S3の保管設計を先に決める

  • どこへ出力するか（CloudWatch Logs / S3）
  • 保持期間（例: 90日、1年）
  • 監査時の検索手段（CloudWatch Logs Insights / Athena）

server_audit_events だけ決めても、保管と検索が弱いと監査証跡として機能しません。

3. 監査対象ユーザーを絞る設計も検討する

監査対象を全ユーザーに広げる前に、管理者ユーザーや機密データ操作ユーザーに重点を置くと、ノイズを減らしつつ有効な証跡を得やすくなります。

4. 定期的に「取れているか」を検証する

  • GRANT/REVOKE が期待通り記録されるか
  • DDL変更がチケットと突合できるか
  • 4半期ごとにログ量と保持期間を見直す

インフラ/SREとしての判断軸（会話まとめ）

まず結論

インフラ/SREとしては、DB監査ログの「何を取るべきか」を単独で最終判断しない方が安全です。 一方で、技術的な実現方法、性能影響、ログ量、コスト、代替策を整理し、セキュリティ/監査/法務/事業が判断できる状態を作る責任があります。

特にSELECTログは、取る/取らないで運用負荷が大きく変わるため、全量取得ではなく必要範囲を絞るのが現実的です。

監査で見られる観点

観点見られること
アクセス管理必要な人だけが本番DBを触れるか
変更管理本番DB変更が申請・承認されているか
証跡誰が何をしたか追えるか
ログ保護ログを消せない/改ざんしにくいか
レビューログを取るだけでなく見ているか
例外対応問題発生時に調査・是正できるか

誰が何を判断するか

判断主担当
どのデータが重要/機密か事業、プロダクト、法務、セキュリティ
顧客契約上、閲覧ログが必要か法務、コンプラ、セキュリティ
監査上、SELECTログが必要か内部監査、監査法人、セキュリティ
リスクを受容できるかシステムオーナー、責任者
領域SREが出す情報
技術可否Auroraでどのログが取れるか
アクセス経路アプリ、踏み台、BI、SQLクライアント、運用スクリプト
対象ユーザーDBA、開発者、SRE、委託先、サービスアカウント
影響性能、ログ量、CloudWatch/S3/SIEMコスト
運用誰が見るか、どの頻度で見るか、アラート化するか
代替策アプリ操作ログ、権限制限、承認フロー、マスキング

SELECTログの現実的な扱い

  • 原則: SELECTは「取れるから取る」ではなく「必要範囲だけ取る」
  • 理由: 多くのシステムでSELECT比率が高く、全量取得はログ爆発を起こしやすい
  • 対象にしやすい例: DBAや管理者の直接SELECT、踏み台/BI経由、重要テーブルへの手動SELECT、大量取得/EXPORT
  • 対象外にしやすい例: アプリ通常処理の定型SELECT、低機密データの参照、ヘルスチェック系クエリ

SELECT要否チェック（簡易）

次の質問にYESが多いほど、SELECT監査対象に寄せます。

  1. 個人情報・顧客データ・財務重要データ・営業秘密を扱うか
  2. 「誰が見たか」の説明を求められ得るか
  3. アプリ以外の経路で人が本番DBを参照できるか
  4. 特権的に参照できる人（DBA/開発者/SRE/委託先）がいるか
  5. 大量取得/エクスポートが可能か
  6. 契約・規制・社内ルールでアクセス記録が求められているか

目安:

  • YES 0件: SELECT監査は不要寄り
  • YES 1件: 代替ログで足りるか要検討
  • YES 2件以上: SELECT監査を対象化するのが無難
  • 契約/規制で明示要求あり: 原則対象

監査目線の最終結論

迷ったら次を基準にすると実務で失敗しにくいです。

  1. 最低ライン: CONNECT,QUERY_DDL,QUERY_DCL
  2. 変更監査を強化: +QUERY_DML_NO_SELECT
  3. フル監査（例外運用）: QUERY / TABLE は期間・対象を限定

「網羅性を最大化する」より、監査で本当に使えるログを継続的に運用できるか を優先するのがポイントです。

RK

1997年生まれ

ITエンジニア

インフラ・SRE