データベース監査ログは 2 つのレイヤーに分かれます。インフラ層はプロバイダー側の操作 (プロビジョニング、構成、バックアップ) を捕捉します。ワークフロー層はデータベース内部で起きること (スキーマ変更、クエリ、承認、エクスポート) を捕捉します。なぜコンプライアンスが両方を必要とするかは データベース監査ログ: 2 つのレイヤー、1 本の証跡 で扱っています。
Bytebase はワークフロー層をカバーします。本稿はその仕組みについてです。
Bytebase が 3 つのギャップをどう閉じるか
エンジンネイティブの監査は 3 つのギャップを残します。ID、文脈、網羅性です。Bytebase はデータベースの内側ではなく前段に立つため、それぞれを閉じます。
ID。 Bytebase は SSO でマップされたエンドユーザーを記録します。SQL が 1 本でも外に出る前に、全員がまず Bytebase に認証するので、共有の app_user 接続を通っても帰属が保たれます。エンジンネイティブログが手がかりを失うのはまさにこの共有接続です。すべてのクエリが app_user として現れ、実際に誰が実行したのか分からなくなります。
文脈。 Bytebase はすべての SQL 実行を、承認チェーン、プロジェクト、Issue ID と組み合わせます。根拠は変更時に SQL のすぐ隣で記録されます。数週間後に監査担当者が「なぜ 4,000,000 行目が変わったのか」と尋ねてきてから再構成するのではありません。
網羅性。 Bytebase は PostgreSQL、MySQL、SQL Server、Oracle、その他にわたって 1 つの監査スキーマを出します。捕捉はゲートウェイで起きるため、複数エンジンのフリートでも、自分で正規化しなければならない 5 方言の監査ログではなく、単一フォーマットの証跡が得られます。
Bytebase が記録するもの
イベントは 6 カテゴリです。
- SQL 実行: SQL Editor または変更ロールアウトを通るすべてのクエリ。SQL 全文、対象データベース、パラメータ、実行結果を含む
- スキーマ変更: Issue 作成、承認判断、ロールアウトステータス、ロールバック
- データアクセス: 申請ユーザーに紐付くクエリとエクスポート。行数とエクスポート先を含む
- 認証: ログイン、ログアウト、SSO トークン交換、失敗試行
- 権限変更: ロール付与、プロジェクトメンバーシップ更新、ポリシー変更
- システム構成: インスタンス接続、環境設定、ワークスペースポリシー
データアクセスのエントリはカラム単位のマスキング判断も保持します。どのカラムがマスクされて返ったか、どのセマンティックタイプが発火したか、どのルールが一致したかです。
各エントリには、ユーザーのメール、送信元 IP、タイムスタンプ、操作時間、影響を受けたリソースパス、リクエスト/レスポンスのペイロードが含まれます。機微なフィールド (パスワード、証明書、SSH 鍵、接続文字列) は、レコードが書き込まれる前に自動でリダクトされます。
典型的な SQL 実行レコード (request と response はデコード表示。実際の通信上は JSON エンコードされた文字列):
{
"name": "workspaces/-/auditLogs/12345",
"createTime": "2026-05-05T14:23:11Z",
"user": "users/alice@example.com",
"method": "/bytebase.v1.SQLService/Query",
"severity": "INFO",
"resource": "instances/prod-postgres/databases/app",
"request": {
"name": "instances/prod-postgres/databases/app",
"statement": "SELECT email, plan FROM users WHERE id = 12345",
"limit": 1000
},
"response": {
"results": [
{
"columnNames": ["email", "plan"],
"columnTypeNames": ["TEXT", "TEXT"],
"rowsCount": "1",
"masked": [
{
"semanticTypeId": "bb.default.email",
"semanticTypeTitle": "Email",
"algorithm": "Range Mask",
"context": "Matched global rule: PII Protection"
},
{}
]
}
]
},
"status": { "code": 0 },
"latency": "0.018s",
"requestMetadata": {
"callerIp": "10.0.5.42",
"callerSuppliedUserAgent": "bytebase-web/3.x"
}
}masked 配列こそ、エンジンネイティブの監査では得られない部分です。エンジンネイティブログは SQL が実行され行が返ったことを記録します。Bytebase はカラム単位のマスキング理由を記録します。email は、グローバルの PII Protection ルールのもとで bb.default.email セマンティックタイプに一致したため、マスクされて返りました。マスクされていないカラムは空のエントリとして現れ、カラムと理由の対応をそのまま保ちます。この形は SQL Editor のクエリ、変更ロールアウト、データエクスポートで同一です。1 つのスキーマで、すべての操作を捉えます。
監査データを取り出す
エクスポート経路は 3 つです。
GUI
Settings → Audit Log。ユーザー、メソッド、リソース、重大度、期間でフィルタします。スポットチェックや、監査担当者を証跡に沿って案内するのに向いています。
API
スコープに応じて 2 つのエンドポイントがあります。
/v1/auditLogs:search: ワークスペースレベル。プロジェクト横断ですべての監査レコードを返す/v1/projects/{project}/auditLogs:search: プロジェクトスコープ
どちらもユーザー、期間、メソッド、重大度、リソースのフィルタ式を受け付けます。レスポンスは構造化 JSON で、任意の SIEM にそのまま取り込めます。ページングは pageToken で行います。スキーマとフィルタ構文の全体は API 監査ログチュートリアル にあります。
ログストリーミング
Settings → General → Audit Log Export。Bytebase は内部ストレージに加えて、監査レコードを stdout に書き出します。プロセスに --enable-json-logging フラグを付けると構造化 JSON を出力します。サイドカーのログシッパー (Vector、Fluent Bit、Datadog Agent、Splunk Universal Forwarder) が stdout を拾い、SIEM へ転送します。
API ポーリングがレイテンシを足してしまう高ボリューム環境ではストリーミングを使ってください。アドホックな証拠取得や定期エクスポートには API を使ってください。
エンジンネイティブ監査との組み合わせ
境界については正直に言いましょう。Bytebase は Bytebase 経由でルーティングされた SQL を監査します。それ以外の経路はこれを迂回します。
psql、mysql、その他クライアントからの直接接続- 自前の資格情報で繋ぐ本番サービスのアプリケーショントラフィック
- データベースホストへの緊急 SSH アクセス
- WAL や binlog を読むレプリケーション・CDC パイプライン
そこで完全なカバレッジのためには、人による活動の主証跡として Bytebase を運用し、エンジンネイティブ監査を後ろ盾として有効にしておいてください。
| 経路 | 捕捉 |
|---|---|
| Bytebase 経由の人による SQL | Bytebase |
| アプリのサービスアカウントトラフィック | エンジンネイティブ (pgaudit、MySQL 監査プラグイン、SQL Server Audit) |
| 緊急の直接アクセス | エンジンネイティブ + セッションの送信元 IP へのアラート |
| クラウドインフラの変更 | プロバイダー監査ログ (CloudTrail、Cloud Audit Logs、Azure Monitor) |
プラン提供形態
監査ログは Pro と Enterprise プラン で利用できます。Pro はすべてのイベントカテゴリ、GUI と API アクセス、自動リダクションをカバーします。Enterprise はカスタム承認ワークフローと高度なアクセス制御を追加し、これらはポリシー強制まわりで追加の監査イベントを生成します。
セットアップの詳細と最新のフィールドリファレンスは Bytebase 監査ログのドキュメント を参照してください。