レシピ: 検出結果と台帳を SIEM へプッシュする

SIEM and ITSM push, OTLP downloads, external trace and metric delivery, and posture export require Business. Community keeps local observability, trace-context propagation, saved settings and olivares dr backup. Generic chat, email and webhook notifications remain available in Community.

目的: ファイルを追従するフォワーダーを使わずに、control plane の検出結果と改竄検知可能な監査台帳をプッシュ配信で SIEM に受信させる。

これはイベンティングプラットフォーム上の S2S（サービス間）プッシュ経路です。プル方式のエクスポートとファイル追従の運用形態は引き続き完全にサポートされます。プルは WORM アーカイブとオフライン再検証に適した形であり、プッシュはライブの SIEM 取り込みに適した形です。

1. シンクサブスクリプションを作成する

まず選択可能な台帳フォワーダーを有効にします。依存する eventing も有効になります:

olivares modules on siemforward

エンジンの再起動が完了するまで待ち、olivares modules ls を実行してください。サブスクリプションを作成する前に、siemforward と eventing が稼働中であることを確認します。

curl -ks -X POST "$BASE/v1/m/eventing/subscriptions" \
  -H "Authorization: Bearer $TOKEN" -H "X-Olivares-Tenant: $TENANT" \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "splunk-prod",
    "event_types": ["finding.reported", "audit.recorded"],
    "endpoint": "https://splunk.internal:8088/services/collector",
    "sink_kind": "splunk_hec",
    "sink_format": "ocsf",
    "sink_cred": "<hec-token>"
  }'

sink_kind は運用基盤の方言を選択します: splunk_hec、sentinel_dcr、 datadog、newrelic ── または完全に省略すると 汎用 Webhook になります（JSON イベントを受信する HTTPS エンドポイントで、エンジンの HMAC 署名で認証されます。 …/{id}/rotate-secret でローテートします）。
sink_format: ocsf（SIEM シンクのデフォルト ── AI を意識したスキーマ）、 cef、leef、syslog、otlp、otlp_envelope、json。
sink_format には sink_kind が必要
フォーマットはシンク種別が設定されている場合にのみ適用されます。sink_kind の省略は「HTTPS を選ぶこと」ではありません — 汎用 Webhook が選ばれ、Olivares のイベント JSON が送信され、sink_format は検証すらされません。自前のエンドポイントへ SIEM 方言を POST するには sink_kind: "https" を明示してください。
{ "event_types": ["audit.recorded"], "sink_kind": "https", "sink_format": "otlp_envelope", "endpoint": "https://collector.internal:4318/v1/logs" }
otlp（およびその厳密なエイリアス otlp_envelope）ではエンドポイントをコレクターの /v1/logs に正確に合わせる必要があります（本文は URL にそのまま POST されます）。
sink_cred（HEC トークン / DCR ベアラ / API キー）は一度だけ受け付けられ、 保管時に封緘され、返却もログ出力もされません。ベンダー種別では作成時に必須です。汎用 Webhook では不要です。
event_types はストリームの選択です: 検出結果レールには finding.reported、台帳には audit.recorded（下記参照）、あるいはその両方を指定します。

信頼する前に配信をテストしてください:

curl -ks -X POST "$BASE/v1/m/eventing/subscriptions/$ID/test" \
  -H "Authorization: Bearer $TOKEN" -H "X-Olivares-Tenant: $TENANT"

2. 台帳プッシュ、正直に説明すると

siemforward が有効な場合、台帳ポンプは各テナントのカーソルから封緘済み台帳を辿ります。 audit.recorded サブスクリプションは、作成後に永続的な配信エンジンへ投入されたレコードを 少なくとも1回配信し、再開可能です。各レコードはチェーン整合性フィールドをそのまま保持するため、SIEM 側のコピーはプル方式のエクスポートが許すことを正確に許し、それ以上ではありません。すなわち連鎖のリンク（n+1 の prev_hash が n の hash に等しいこと）と hash に対するチェックポイント署名はオフラインで検証できます。さらに、レコードの hash は 1 行の エクスポート内容から再導出できるようになりました ── 正規の occurred_at テキストとメタデータ・コミットメントを含め、チェーンハッシュの入力はすべて配線上を流れます。このコミットメントはレコードごとにブラインドされているため、背後のメタデータを一切明かさずにプリイメージを完成させます。3 つの主張は区別したままです ── ハッシュの再導出は、AUTHENTICITY（外部で信頼された鍵が必要）でも COMPLETENESS（隣接レコードとチェックポイントが必要）でもありません。監査アーカイブは依然としてより強い成果物です。メタデータ本体をそのブラインドとともに携えるため、あるコミットメントがどのメタデータを覆っているかにも答えられます。

知っておく価値のある3つの性質:

サブスクリプションがなくてもカーソルは前進します。 audit.recorded の購読者がいない場合、配信はキューに入りませんが、有効なポンプはカーソルを保存します。新しいシンクはカーソルが通過済みのレコードを遡って配信しません。過去のレコードにはプルエクスポートを使用してください。
少なくとも1回は重複の可能性を意味します（再配信時）。テナントごとにレコードのシーケンス番号で重複排除してください。
ポンプは HA でリーダーゲート方式です ── ちょうど1つのノードだけが転送します。

3. ITSM: チケットとしての検出結果

同じサブスクリプション機構が、通知レール経由で ITSM 宛先を駆動します ── 検出結果から ServiceNow インシデントや Jira 課題を生成し、重大度を優先度にマッピングします。これらは SIEM シンクではなく、通知宛先（servicenow / jira の出力コネクタ）として設定してください。 Splunk ページの宛先テーブルにそのパターンが示されています。

エンドツーエンドで検証する

…/test が配信済みを返す。
観測可能な何か（予算アラートのしきい値、拒否されたツール）を起動し、検出結果が到着するのを確認する。
台帳について: SIEM 側の seq ハイウォーターマークを GET /v1/audit/export?from=<seq> と比較する ── 両ストリームは一致しなければなりません。

注記

エンドポイントは HTTPS でなければなりません。エンジンは平文シンクを拒否します。
ポスチャースナップショット（コンプライアンス / NHI / 検出結果のロールアップ）は、同じレールに乗る独自のエクスポートモジュールを持っています ── コンプライアンスモジュールを参照してください。
完全な判断表 ── いつプルし、いつ追従し、いつプッシュするか ── は Splunk 転送ページにあります。