データベース監査ログには 2 つのレイヤーがあります。インフラ層はプロバイダー管理の操作 (プロビジョニング、構成、バックアップ) を、ワークフロー層は DB 内の操作 (スキーマ変更、クエリ、承認、エクスポート) を捕捉します。なぜコンプライアンスが両方を求めるかは データベース監査ログ: 2 つのレイヤー、1 本の証跡 を参照してください。
Bytebase はワークフロー層をカバーします。以下にその仕組みを示します。
Bytebase が 3 つのギャップをどう閉じるか
エンジンネイティブの監査は 3 つのギャップを残します — ID、文脈、網羅性。Bytebase は DB の内ではなく前段に立つため、それぞれを閉じます。
ID。 Bytebase は SSO でマップされたエンドユーザーを記録します。ユーザーは SQL を発行する前に Bytebase に認証するため、エンジンネイティブログが共有 app_user 接続で見失うところでも、帰属が保たれます。
文脈。 Bytebase はすべての SQL 実行を、承認チェーン、プロジェクト、Issue ID と組み合わせます。根拠は SQL とともに変更時に記録され、監査官に問われてから事後に再構成するものではありません。
網羅性。 Bytebase は PostgreSQL、MySQL、SQL Server、Oracle ほかに対し、1 つの監査スキーマを出します。捕捉はゲートウェイで起きるため、多エンジンのフリートでも 1 フォーマットの証跡になります。
Bytebase が記録するもの
イベントは 6 カテゴリ:
- SQL 実行 — SQL Editor からのすべてのクエリ、または変更ロールアウト。SQL 全文、対象 DB、パラメータ、実行結果を含む
- スキーマ変更 — 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 は bb.default.email セマンティックタイプにグローバルルール PII Protection で一致したため、マスクされて返った。マスクされていないカラムは空エントリとして並び、カラム ↔ 理由の対応を保ちます。形は 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など他クライアントからの直接接続- 自前資格情報で繋ぐ本番サービスのアプリケーショントラフィック
- DB ホストへの緊急 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 監査ログのドキュメント を参照してください。