監査ログ

VeloDB Cloudは組織の活動、SQL活動、インフラストラクチャイベントを記録するため、誰が何を、いつ、どこから行い、システムがどのように応答したかを把握できます。このガイドでは、セキュリティレビューやインシデント調査のために、各監査ソースをどこで表示・クエリするかをマッピングします。

監査ログのソース

ソース	記録内容	参照場所
Organization Activity Logs	メンバー変更、ロール変更、課金変更、warehouseライフサイクルアクションを含む、コンソールとコントロールプレーンのアクション。	Account and Organization
Database audit log	warehouseに対して実行されたSQLとクエリ活動。`__internal_schema.audit_log`システムテーブルに保存される。	audit_log table schema
Infrastructure events	クラウドアカウント内のリソースに対するクラウドプロバイダーの運用イベント。特にBYOCデプロイメントにおいて。	AWS CloudTrailやGoogle Cloud Audit Logsなど、お使いのクラウドプロバイダーの監査ログ。

SQL監査ログは、audit_logテーブルに対するSQLで確認するか、コンソールのQuery AuditとLog Explorerで確認できます。監査の保持期間はaudit_logテーブル自体で管理されます。

監査ログテーブルのクエリ

SQLベースのフィルタリング、集約、エクスポート、または反復可能な証跡収集が必要な場合は、__internal_schema.audit_logテーブルを直接クエリします。各レコードには、ユーザー、クライアントアドレス、ステートメントタイプ、ステートメントテキスト、実行時間、実行ステータス、エラー情報、スキャンされたデータ、返された行数、workload group、および関連するクエリ識別子を含めることができます。完全なスキーマについては、Audit Event Referenceを参照してください。

例：最近の失敗したステートメントを確認する。

SELECT
    time,
    user,
    client_ip,
    stmt_type,
    state,
    error_code,
    error_message,
    stmt
FROM __internal_schema.audit_log
WHERE time >= NOW() - INTERVAL 1 DAY
  AND state = 'ERR'
ORDER BY time DESC
LIMIT 100;

例：ユーザー別にクエリアクティビティを要約する。

SELECT
    user,
    COUNT(*) AS statement_count,
    MAX(time) AS last_seen
FROM __internal_schema.audit_log
WHERE time >= NOW() - INTERVAL 7 DAY
GROUP BY user
ORDER BY statement_count DESC;

Audit Log Retention

SQL監査ログは__internal_schema.audit_logシステムテーブルに保存されます。このテーブルは時間によってパーティション分割されており、保持期間はテーブルの動的パーティションプロパティによって制御されます。

現在の保持期間設定を確認するには、以下を実行してください：

SHOW CREATE TABLE __internal_schema.audit_log;

出力では、以下のような動的パーティションプロパティを確認してください：

"dynamic_partition.enable" = "true",
"dynamic_partition.time_unit" = "DAY",
"dynamic_partition.start" = "-30"

日付ベースのパーティションの場合、dynamic_partition.start = -30は、テーブルが最新約30日分の監査データを保持することを意味します。これは、マネージド分析サービスにおけるデータベース監査ログの一般的なデフォルトウィンドウです。実際の環境では異なる値を使用している可能性があるため、SHOW CREATE TABLEを信頼できる情報源として使用してください。

保持ウィンドウを変更するには、dynamic partitionのstart値を変更します。例えば、SQL監査データを約90日間保持する場合：

ALTER TABLE __internal_schema.audit_log
SET (
    "dynamic_partition.start" = "-90"
);

より長い保持期間は調査期間の拡大を提供しますが、より多くのストレージを消費し、広い時間範囲を検索する際にクエリコストを増加させる可能性があります。コンプライアンス要件、インシデント対応プロセス、およびストレージ予算に適合する値を選択してください。

ConsoleでAudit Logをクエリする

SQLを記述することなくコンソールからクエリアクティビティを確認するには、Monitoring > Query Auditを使用してください。

internal_schema > audit_logなどのログテーブルデータに対して、インタラクティブなフィールドフィルター、キーワード検索、SQLモード、トレンドチャート、行詳細、JSONビュー、または周辺コンテキストが必要な場合は、Log Explorerを使用してください。

Infrastructure Events

Infrastructure eventsは運用およびプラットフォームレベルのイベントです。これらはSQL audit recordsとは異なります。

BYOCデプロイメントでは、インフラストラクチャリソースは独自のクラウドアカウントで実行されるため、インフラストラクチャレベルの監査証跡は通常、AWS CloudTrailやGoogle Cloud Audit Logsなどのクラウドプロバイダーのネイティブロギングサービスから提供されます。

Audit Evidence Checklist

セキュリティアンケートに回答する際、最も有用な証跡は通常以下を含みます：

質問	証跡ソース
組織設定やアクセスを変更したのは誰か？	Activity Logs
SQL文を実行したり、SQLを通じてデータにアクセスしたのは誰か？	`__internal_schema.audit_log`テーブルまたはMonitoring > Query Audit
SQL audit recordsはどのくらいの期間保持されるか？	`SHOW CREATE TABLE __internal_schema.audit_log`
SQL audit retentionはどのように変更されるか？	`ALTER TABLE __internal_schema.audit_log SET ("dynamic_partition.start" = "-N")`
BYOCでinfrastructure eventsはどこで確認できるか？	クラウドプロバイダーの監査ログ

監査ログのソース​

監査ログテーブルのクエリ​

Audit Log Retention​

ConsoleでAudit Logをクエリする​

Infrastructure Events​

Audit Evidence Checklist​

関連ドキュメント​