データベース監査ログは、誰が、何を、いつ、どこからしたかを記録します。SOC 2、ISO 27001、HIPAA、PCI DSS、GDPR はすべてこれを要求します。多くのチームは有効化しています。それでも多くが監査で落とされます。
ギャップは構造的です。データベース監査ログは 1 つのシステムではなく 2 つです。インフラ層は DB に対する操作を捕捉します — プロビジョニング、構成、バックアップ、ネットワーク。ワークフロー層は DB 内の操作を捕捉します — スキーマ変更、クエリ、承認、エクスポート。クラウドプロバイダーが前者を出荷し、後者はあなたが組み立てます。
2 つのレイヤー
インフラ層
インフラ層は DB インスタンスへの操作を監査します。
- プロビジョニング、削除、リサイズ
- パラメータグループと構成の変更
- ネットワークとファイアウォールルールの変更
- バックアップ、スナップショット、リストアの操作
- クラウドレベルの IAM 付与・取り消し
クラウドプロバイダーが既定でカバーします。AWS RDS は CloudTrail にイベントを送り、Google Cloud SQL は Cloud Audit Logs に書き、Azure Database は Azure Monitor に出力します。セルフホストは IaC ツール、コンテナ監査ログ、OS レベルアクセスログから同等のカバレッジを得ます。
レコードは整形され、中央に保存され、クラウドの主体に紐付きます。この層はほぼ解決済みの問題です。
ワークフロー層
ワークフロー層は DB 内の操作を監査します。
- スキーマ変更 — DB に適用された DDL
- データ変更 — テーブルに対して実行された DML
- 読み取りアクセス — 機微テーブルへの SELECT
- 承認 — 誰が、どの根拠で、どの変更を承認したか
- エクスポート — 誰が、どのデータを引き出し、どこへ持ち出したか
- 権限変更 — ユーザーに付与されたロールと権限
各エンジンが自前の監査を出荷します — PostgreSQL の pgaudit、MySQL の監査プラグイン、SQL Server Audit、Oracle Unified Auditing。4 つすべてに、設定でも閉じない 3 つの構造的ギャップがあります。
- ID は DB ユーザーで、人間ではない。 ほとんどのアプリと運用スクリプトは
app_userやadminで接続する。監査ログはロールを記録するが、人物は記録しない。 - 文脈が欠ける。 ログは SQL を記録しても、チケット、承認者、環境を記録しない。コンプライアンスは「なぜ」を尋ねる。
- カバレッジが分断される。 各エンジンが別々にログする。多エンジンのフリートはマルチフォーマットの証跡を生み、どんな SIEM もきれいには統一できない。
監査の指摘の大半は、ワークフロー層に起きます。
なぜ分割が重要か
監査官は「ログは有効ですか」とは尋ねません。特定の特権操作の証拠を求めます — 管理者がユーザーを昇格させた、開発者がスキーマを変えた、アナリストが顧客レコードを引き出した。その証拠はほぼ常にワークフロー層のイベントです。
CloudTrail のカバレッジが完璧でも、SOC 2 で落ちることは起こり得ます — 先週火曜の本番スキーマ変更を実行した SQL の、きれいな記録を出せないからです。私たちはそれを What SOC 2 Taught Us About Database Audit Logs に書きました。
分割はオーナーシップも明確にします。インフラ層はプラットフォームチームが、ワークフロー層はデータ・アプリチームが所有します。束ねるとアカウンタビリティが曖昧になります。
各層が捕捉すべきもの
両層とも同じ 4 つの問い — 誰、何、いつ、どこ — に答える必要があります。フィールドは異なります。
| フィールド | インフラ層 | ワークフロー層 |
|---|---|---|
| 誰 | クラウドの主体 (IAM ユーザー、サービスアカウント) | エンドユーザー ID (SSO からマップ)、DB ユーザーではない |
| 何 | API 呼び出し (ModifyDBInstance、RevokeSecurityGroupIngress) | SQL ステートメント (DDL、DML、SELECT) と承認・エクスポート操作 |
| いつ | API 呼び出しのタイムスタンプ | ステートメント実行のタイムスタンプ |
| どこ | リソース ARN またはインスタンス ID | DB、スキーマ、テーブル、加えて送信元 IP とリクエスト ID |
ワークフロー層は文脈も持つ必要があります — チケット ID、環境、承認チェーン、変更参照。文脈なしでは、監査官は操作を見ても根拠を見られません。
コンプライアンスフレームワーク別の監査ログ
どのフレームワークも両層を要求します。重点が変わります。
- SOC 2 — Trust Services Criteria CC6.1、CC6.3、CC7.2 は、両層にわたる管理者活動の証跡を求める。実際の監査がどう見えるかは What SOC 2 Taught Us About Database Audit Logs を参照。
- HIPAA — § 164.312(b) は ePHI を扱うシステムへの監査統制を求める。PHI テーブルへの SELECT 可視性がワークフロー層の要点。HIPAA データセキュリティと保存要件 も参照。
- PCI DSS — Requirement 10 はカード保有者データへのすべてのアクセスに監査証跡を要求し、保存は 1 年、うち 3 ヶ月はオンライン。負担はワークフロー層に集中する。
- ISO 27001 — Annex A 8.15 は活動、例外、セキュリティイベントのログを要求。範囲は SOC 2 と近い。
- GDPR — 第 30 条の処理記録義務は、個人データの読み取り、エクスポート、変更のたびに適用される。SELECT とエクスポートの監査はワークフロー層に住む。
データベースエンジン別の監査ログ
インフラ層は均一で、クラウドプロバイダーが扱います。ワークフロー層はエンジンごとに鋭く異なります。
- PostgreSQL — ネイティブログ、トリガ、論理レプリケーション、
pgaudit、ワークフローツール。詳細は Postgres 監査ログガイド に。 - MySQL — general log、監査プラグイン (Percona Audit、MariaDB
server_audit、MySQL Enterprise Audit)、binlog ベースの CDC。設定負担の大半はプラグイン選択に。 - SQL Server — サーバーおよび DB スコープでの SQL Server Audit。Audit Specification は細粒度。運用の難しさは
fn_get_audit_file()で.sqlauditをパースして SIEM に流すこと。 - Oracle — Unified Auditing (12c+) が
UNIFIED_AUDIT_TRAILにレコードを集約。最も細粒度のエンジン。AUDSYS テーブルスペースの能動的管理が必要。 - クラウド管理 DB — RDS、Cloud SQL、Azure Database はエンジンネイティブ監査をプロバイダーフォーマットに包む。SQL テキストの忠実度とイベントカバレッジはプロバイダー依存。
Bytebase はワークフロー層をどうカバーするか
Bytebase はデータベースの前段に立ちます。Bytebase 経由でルーティングされた SQL — SQL Editor、変更ワークフロー、データエクスポート — はエンジンに到達する前にログされます: ユーザーの SSO ID、SQL 全文、対象 DB、タイムスタンプ、実行結果。スキーマ変更には承認チェーンが付随します。Bytebase を迂回する直接接続は捕捉されません。
レコードフォーマット、エクスポート経路、エンジンネイティブ監査との組み合わせ方は How Bytebase Handles Audit Logging を参照。
よくあるミス
| ミス | 何が起きるか | 修正 |
|---|---|---|
| プロバイダーログを監査証跡のすべてと見なす | ワークフロー層の操作が不可視。SOC 2 や HIPAA の指摘につながる | ワークフロー層の監査を追加 |
| フィルタ無しの冗長なエンジンネイティブログ | ストレージコスト急増、シグナルがノイズに埋もれる | DDL、DML、ログイン失敗から始め、機微テーブルのみ SELECT を追加 |
| 共有 DB アカウント | ワークフローログが app_user で人間ではない | すべての SQL 操作を SSO ID にマップ |
| SELECT 監査をスキップ | 機微データを「誰が読んだか」を証明できない | PII、財務、資格情報テーブルへの SELECT を監査 |
| 文脈無しに SQL を捕捉 | 監査官は操作を見ても根拠を見られない | 各レコードにチケット ID、承認者、環境、変更参照を付ける |
| DB ホストにログを保存 | DROP DATABASE や侵害で証跡が消える | SIEM、S3、中央集約ログへ転送 |
| 保存ポリシー無し | ログがディスクを埋めるか、監査前にローテーションされる | フレームワーク別の保存 — SOC 2: 90〜365 日、PCI DSS: 1 年、HIPAA: 6 年 |
| ログが生ファイルに残り SIEM に届かない | アラートも相関も無く、監査時に手作業で証拠を集めることになる | Datadog、Splunk、CloudWatch、Grafana に監査データをストリーム |
FAQ
どのコンプライアンスフレームワークがデータベース監査ログを要求するか？
SOC 2、ISO 27001、HIPAA、PCI DSS、GDPR はすべて監査証跡を求めます。各フレームワークが重視するフィールドは異なります — PCI DSS は保存期間を、HIPAA は PHI アクセスを、SOC 2 は管理者活動を重視します。詳しくは SOC 2 データセキュリティ要件 と HIPAA データセキュリティと保存要件 を参照。
Bytebase を使えばエンジンネイティブの監査は要らないか？
Bytebase は Bytebase 経由でルーティングされた SQL のワークフロー層をカバーします。Bytebase を迂回する直接接続 — 緊急 SSH、アプリのサービスアカウント、アドホックツール — もあるなら、その経路のためにエンジンネイティブ監査も残してください。多くのチームは、Bytebase を主証跡に、エンジンネイティブログを後段として運用します。
Bytebase はデータベース監査ログをどう扱うか？
Bytebase はプラットフォームを通るすべての SQL ステートメント、スキーマ変更、承認、エクスポートを、実ユーザーの SSO ID と紐付けてログします。レコードフォーマットとエクスポート経路の詳細は How Bytebase Handles Audit Logging を参照してください。