Confluent での監査ログ設計：CCAAK 実務と試験の要点

監査ログは「誰が・いつ・どこで・何を・結果はどうだったか」を一貫して残す仕組みです。Kafka 環境では API 呼び出し（Produce/Fetch/Metadata）、権限変更、スキーマ操作、接続情報などが対象になります。

Confluent は Cloud と Platform で実装や配信の形が異なります。本稿では差分を前提に、設計判断のポイントと実装の落とし穴を解説します。

監査ログの目的と適用範囲

監査ログは可観測性ログやメトリクスとは目的が異なり、後追い検証とコンプライアンス証跡のために整合性の取れたイベント履歴を残すことが主眼です。Kafka 環境では特に、認可判定（許可/拒否）、管理操作（トピック/ACL/RBAC/コネクタ/ksqlDB/Schema Registry）、およびクライアント識別（Principal・Client ID・認証方式・ソース IP）を網羅的に残す必要があります。

Confluent Cloud では監査ログはマネージドな配信機構を通じて外部シンクへ出力します。Confluent Platform（自己運用）ではブローカーや周辺コンポーネントが監査イベントを Kafka トピックとして発行し、それを外部に転送します。どちらもスキーマ化されたイベントで、最小権限の原則と改ざん耐性の設計が必須です。

• 対象行為: 認証/認可、トピック/ACL/RBAC/Schema/Connect/ksqlDB の管理操作、Produce/Fetch などのデータプレーン
• 必要属性: actor（実行主体）、action（操作）、resource（対象）、outcome（許可/拒否）、時刻、リクエストメタデータ（client.id 等）
• 監査と運用ログは分離し、保存先は WORM 特性（改ざん困難）を優先

Confluent Cloud の監査ログ：設計の基本

Confluent Cloud は監査ログをマネージドに収集し、指定したシンク（例: S3、GCS、Azure Blob、Datadog、Splunk）へ近リアルタイムで配信します。利用者は Kafka トピックから直接購読するのではなく、配信先で保管・分析します。

イベントには組織/環境/クラスタの識別子、リソースタイプ、アクション、主体、結果、タイムスタンプが含まれます。保持期間はシンク側のポリシーで管理する前提で、Cloud 側に長期保持を期待しない設計が基本です。

• シンプルな導入：管理面は Cloud 側で吸収、配信の信頼性とスキーマ整合性が確保されやすい
• アクセス制御：監査ログ設定の操作権限は組織レベルの管理ロールに限定
• 設計ポイント：リージョン/アカウント分離時はシンクも分離し、横断集約は SIEM 側で行う

Confluent Platform の監査ログ：設計の基本

Confluent Platform（Confluent Server を含む）では、監査イベントは Kafka の内部トピックとして発行されます。RBAC/ACL の認可判定、管理 API、データプレーンの主要操作が対象です。監査トピックは高い可用性（十分なレプリカとパーティション）と、厳格なアクセス制御（読み取りは監査担当者のみ）で保護します。

外部システム（SIEM、オブジェクトストレージ）へは Kafka Connect の各種シンク（S3、GCS、Azure、Splunk 等）で転送します。転送パイプライン自体の可観測性と再送設計（少なくとも At-Least-Once）は必須です。

• 内部トピックは別クラスタ（監査専用）にミラーする設計も有効
• 拒否イベントと管理操作は優先監視対象。許可イベントは要件に応じて集約/間引き
• 時間同期（NTP）を全ノードで徹底し、時系列の一貫性を担保

設計パターンとアーキテクチャ

Cloud はマネージド配信をそのまま使い、シンク側で保存と分析を標準化。Platform は内部トピック→Connect→シンクの経路に対し、冗長化と容量見積り（高スループット時の増加）を事前評価します。

批判系イベント（拒否、権限変更、データ定義変更）は別トピック/別ストレージ階層に振り分け、保管期間を長く設定すると運用コストを抑えつつ監査要件を満たしやすくなります。

• Cloud：環境/組織単位でシンクを分け、タグでコスト配賦
• Platform：監査専用 Connect ワーカーを分離しバックプレッシャを本番流量から隔離
• 全方式共通：書き込み失敗時の隔離バッファ（DLQ）と再送ポリシーを明示

Cloud/Platform 監査ログの標準経路（概略）

監査イベントのスキーマとフィルタリング

監査イベントはおおむね以下のフィールドで構成されます。actor（主体: ユーザー/サービスアカウント）、action（操作: CREATE_TOPIC/ALTER_ACL/PRODUCE 等）、resource（種類・名前・スコープ）、outcome（ALLOWED/DENIED）、reason（却下理由）、network/auth 情報、client.id、correlation.id、timestamp。Cloud/Platform で表現差はありますが、この骨子は安定しています。

高ボリュームの許可イベントは長期保存のコストを押し上げます。要件が許すなら、拒否イベントや管理操作を優先保存し、成功イベントは集約（サンプリング/日次ロールアップ）します。秘匿情報（トークン断片、IP セグメント、ユーザー属性）はシンク側でマスキング/トークナイズします。

• PII/機微情報が含まれ得るフィールドは収集前に棚卸し
• スキーマ進化に備え、未知フィールドはドロップせず透過転送
• 時刻は単一の基準（UTC）で正規化し、取り込み時に明示

例: Kafka Connect（S3 Sink）で監査トピックを長期保管

{
  "name": "audit-s3-sink",
  "config": {
    "connector.class": "io.confluent.connect.s3.S3SinkConnector",
    "tasks.max": "2",
    "topics": "audit-log-events",
    "s3.bucket.name": "org-audit-logs",
    "s3.part.size": "5242880",
    "flush.size": "1000",
    "format.class": "io.confluent.connect.s3.format.json.JsonFormat",
    "partitioner.class": "io.confluent.connect.storage.partitioner.TimeBasedPartitioner",
    "path.format": "year=YYYY/month=MM/day=dd/hour=HH",
    "locale": "en_US",
    "timezone": "UTC",
    "timestamp.extractor": "Record",
    "behavior.on.null.values": "ignore",
    "rotate.schedule.interval.ms": "900000",
    "schema.compatibility": "BACKWARD"
  }
}

運用・保護・試験（CCAAK）で外せないポイント

運用では、監査経路そのものの監査（誰が無効化/変更したか）を別経路で記録します。監査トピックのアクセス権は最小にし、Platform 側は暗号化（転送/保存）とログ保存先の WORM 設定を適用します。Cloud 側は配信先の IAM と保存クラス、ライフサイクルを厳格化します。

CCAAK では、Cloud と Platform の「どこで設定し、どこに出力されるか」の差分、RBAC/ACL の違いと監査イベントへの影響、そして SIEM 連携時の責任分界点が問われやすいです。ブローカー標準ログや OS ログを監査ログの代替にしない点も頻出の落とし穴です。

• Cloud：監査ログはマネージド配信。Kafka コンシューマで直接読む前提ではない
• Platform：内部トピックの耐久性/保護が利用者責任。シンクの再送設計を明確化
• 性能：監査有効化のオーバーヘッドは小さいがゼロではない。内部トピックのパーティション/レプリカを計画

例: 監査イベント（抜粋）

{
  "actor": {"type": "User", "name": "alice"},
  "action": "CREATE_TOPIC",
  "resource": {"type": "Topic", "name": "payments", "scope": {"cluster_id": "lkc-xxxx"}},
  "outcome": "ALLOWED",
  "request": {"client_id": "producer-1", "ip": "203.0.113.10"},
  "auth": {"mechanism": "SASL_SSL", "principal": "User:alice"},
  "correlation_id": "c-7b3d",
  "ts": "2026-04-18T04:21:34Z"
}

問題で確認

よくある質問