Lakewatchで理解するSecurity Lakehouse：収集から検知・対応まで

まず、証拠についての問いを立てる

普段と違う国からのサインインが成功し、3分後に同じ主体がクラウドの権限を変更した。調査を始めるのか、インシデントと判断するのか、アカウントを封じ込めるのか。それぞれの判断に必要な証拠は違う。国の違いはVPNで説明できるかもしれない。権限変更は予定された保守作業かもしれない。端末ログが見つからない理由も、収集処理の停止かもしれない。

LakewatchはDatabricksのSIEM（Security Information and Event Management、セキュリティ情報・イベント管理）である。Security Lakehouseとして、セキュリティのログと参照が許された業務情報を合わせ、検知や調査に使う。2026年3月24日の発表は、開始時の段階をPrivate Previewと明記している。これは発表時点の記録だ。10月4日の確認では、その後の公開資料による段階の移行、現在の参加条件、cloudとregionの詳細な一覧を確定できなかった。現行製品ページの広い提供表現だけで、それらを確定しない。

この教材では設計判断とオフライン調査を学ぶ。Lakewatchの設定画面を操作する検証済み手順ではない。AWSを想定する例は教材の範囲を示しており、そのAWSアカウントでLakewatchを利用できるという意味ではない。

道具を選ぶ前に、全体の流れを見る

図を横にスクロールして読む。

図は独自の教材用設計であり、Lakewatchの内部構成図ではない。番号に沿って上段を左から右へ読み、下段へ進む。対応判断を囲む破線は、この演習で設けた承認の境界を表す。製品の既定設定を示してはいない。

日本語での読み順は、収集 → 正規化 → 権限管理された証拠 → 検知 → 調査 → 対応判断である。参照権限のある業務情報を調査に加え、結果を次の検知テストへ戻す。対応を実行する主体には、別の権限判断が必要になる。

証拠の受付窓口を思い浮かべると分かりやすい。証言を受け取る仕事、同じ規則で整理する仕事、手掛かりを探す仕事、介入を決める仕事は、それぞれ役割が違う。ただし、この比喩は証拠の信頼性を保証しない。正規化した記録にも元データの誤りは残る。エージェントの説明が自然でも、その主体が行動した証明にはならない。

発表記事の構成説明には、OCSF、Lakeflow Connect、管理されたセキュリティデータ、検知のコード化が登場する。製品ページとFAQは、エージェントによる優先度付け、複数の情報源をまたぐ調査、Unity Catalogによる統制を説明している。これらは公式の機能説明であり、すべてのconnectorの対応、正規化の対応表、Lakewatch固有の権限を定義する資料ではない。

段階	出力と設計上の責任
収集	情報源と配信の進捗を残す。収集主体には必要な情報源だけの権限を与え、到着の遅れを観測できるようにする。
正規化	発生時刻、主体、操作の意味をそろえ、元イベントへの参照を残す。フィールド名を変えるだけでは本人の対応関係は確定しない。
証拠の管理	生ログ、正規化後の行、追加の業務情報について閲覧範囲を決める。各問い合わせをどの主体が実行したか記録する。
検知	版管理した仮説を評価し、根拠のイベント参照を持つアラートを出す。ルールへの一致だけでインシデントとは決まらない。
調査	分析担当者と許可されたエージェントが情報を集め、別の説明を検討し、不足する証拠を示す。一つの表を読めることと全業務データを読めることを分ける。
判断と対応	担当する責任者が対応の必要性を決める。承認、実行主体、要求した操作、確認できた結果をそれぞれ残す。

この表の実行主体と承認方針は、教材で選んだ設計要件である。確認した公開資料では、Lakewatch内部のエージェントの主体や具体的なgrant操作まで確定していない。

四種類の記録は、別の問いに答える

ログ、trace、アプリの状態、検知結果が同じ保存技術を使っていても、その意味は違う。問いと保持方針を分けて考える。

記録	説明できること	それだけでは確定しないこと
Databricksの監査イベント	記録されたプラットフォーム操作、主体、応答	外部の認証・端末を含む網羅性や、侵害の確定
MLflowのエージェントtrace	エージェントの手順、入出力、時間	完全なセキュリティ監査証跡や、提案を実行する権限
Lakebaseの運用telemetry	DBのsession、待ち、実行計画、資源の状況	企業全体を横断するSIEMの調査
エージェントのsession状態	アプリの一つのやり取りで保存した履歴	独立した情報源の証拠、対応の承認、封じ込めの成功

AWSの監査テーブルのリファレンスでは、system.access.auditはPublic Previewである。定義されたフィールドにevent_time、event_id、user_identity、responseがあり、identity_metadataではrun_byとrun_asを区別できる。workspaceのログの多くはregionの範囲を持つ。調査では、要求した人、実行主体、対象の資源を混同しない。これらはDatabricksの監査フィールドであり、Lakewatchの設定項目ではない。

MLflowのtraceは、エージェントの途中の処理や品質の調査に使う。生成されたtool引数に「アクセスを取り消す」とあれば、分かるのは提案した内容までだ。実行成功を判断するには、toolの結果を独立に確認し、操作後の状態も調べる必要がある。

AWSのsystem table一覧には、監査ログの無料保持期間が365日、Lakebase observabilityが7日と記載されている。監査の資料には例外もある。workspaceを削除すると、そのworkspaceの14日より古いイベントはsystem.access.auditから削除される。Lakebase telemetryの資料では機能はBetaであり、schema単位の権限でアカウント内の各projectのtelemetryを参照する。これは周辺テーブルの仕様であって、Lakewatchの保持期間の既定値ではない。7日間の運用記録だけで30日前までの調査を行うには、適切な別の証拠保持経路が必要だ。行が見つからないときも、何も起きなかったと決めず、記録対象や到着状況を確認する。

Managed agent sessionsはBetaで、Lakebaseへ一つのやり取りの状態を保存する。サービスは内容を解釈しないitemを保存する仕組みで、approvalやrunを独立した実行制御の資源として追加しない。アプリの会話履歴とSIEMの証拠は、所有者、閲覧権限、削除規則を別に決める。この説明は、Lakewatchが内部でそのsession APIを使うという意味ではない。

出所を残した合成ケース

次の値とフィールド名は、すべて演習用に作成した。aws-audit-demoはAWSを想定したクラウドイベントのfixtureであり、実在するconnectorやCloudTrailのイベント名ではない。この簡易schemaはOCSFに準拠したレコードでもLakewatch APIのpayloadでもない。実際のOCSFへの対応には、対象version、event class、connectorの資料が必要になる。

オフライン演習を行う場合は、以下をevents.jsonとして保存する。時刻と主体は架空である。org-demo内でemployee-8が同じ主体であることは、上流の本人情報の対応付けで確認済みという前提を置く。表示名が同じだけでは、この前提は成立しない。

[
  {"event_id":"i-1","tenant":"org-demo","source":"identity-demo","occurred_at":"2026-10-01T09:00:00Z","received_at":"2026-10-01T09:00:05Z","actor":"employee-8","kind":"sign-in","outcome":"success","expected_country":"JP","observed_country":"GB"},
  {"event_id":"e-1","tenant":"org-demo","source":"endpoint-demo","occurred_at":"2026-10-01T08:58:00Z","received_at":"2026-10-01T09:07:00Z","actor":"employee-8","kind":"device-status","outcome":"unknown"},
  {"event_id":"c-1","tenant":"org-demo","source":"aws-audit-demo","occurred_at":"2026-10-01T09:03:00Z","received_at":"2026-10-01T09:04:00Z","actor":"employee-8","kind":"permission-change","outcome":"success","resource":"object-store-demo"},
  {"event_id":"i-2","tenant":"org-demo","source":"identity-demo","occurred_at":"2026-10-01T09:12:00Z","received_at":"2026-10-01T09:12:05Z","actor":"employee-9","kind":"sign-in","outcome":"success","expected_country":"JP","observed_country":"JP"}
]

実際の設計では、情報源の生のオブジェクトも別に残す。tenant・source・event IDで範囲を限定した参照から、元の証拠と正規化のversionを確認できるようにする。occurred_atは情報源が記録した発生時刻、received_atは収集の遅れを調べる時刻だ。到着順で結び付けると、早く発生した端末イベントが権限変更より後に並んでしまう。

残る説明は二つある。盗まれた資格情報から権限変更に進んだ可能性と、許可された担当者がVPNを使って予定された保守を行った可能性だ。次の読み取り専用の調査では、クラウド要求の実行主体を該当する変更承認と比較し、認証基盤のsessionやMFAの証拠を確認する。資源の所有者であることだけでは保守の承認を証明できない。端末のunknownという結果も、どちらの説明の根拠にもならない。

検知の仮説を書き、壊してみる

ここでの仮説は、「国の不一致があるサインインに成功し、同じtenant・本人について10分以内に権限変更が成功したら、確認する価値がある」である。地理情報だけでは弱いため、出力は調査のためのアラートにとどめる。

次のPythonは著者が作成したローカルファイル用の例で、未実行である。Databricksのサービスは呼び出さない。window_minutesは演習の変数であり、Lakewatchの設定項目ではない。発生時刻で比較し、情報源ごとのIDで重複を除き、同じIDの内容が食い違う場合やtimezoneのない時刻を拒否する。

import json
from datetime import datetime, timedelta

window_minutes = 10  # 著者が選んだ正の整数。単位は分。
with open("events.json", encoding="utf-8") as file:
    events = json.load(file)

def time_of(value):
    result = datetime.fromisoformat(value.replace("Z", "+00:00"))
    if result.tzinfo is None:
        raise ValueError("Event time requires a timezone")
    return result

unique = {}
for event in events:
    if not event["actor"] or not event["tenant"]:
        raise ValueError("Unresolved subject or tenant")
    time_of(event["occurred_at"])
    key = (event["tenant"], event["source"], event["event_id"])
    if key in unique and unique[key] != event:
        raise ValueError("Conflicting source event ID")
    unique[key] = event

alerts = []
for signin in unique.values():
    if signin["kind"] != "sign-in" or signin["outcome"] != "success":
        continue
    if signin["expected_country"] == signin["observed_country"]:
        continue
    for change in unique.values():
        if change["kind"] != "permission-change" or change["outcome"] != "success":
            continue
        same_subject = (signin["tenant"], signin["actor"]) == (change["tenant"], change["actor"])
        gap = time_of(change["occurred_at"]) - time_of(signin["occurred_at"])
        if same_subject and timedelta(0) <= gap <= timedelta(minutes=window_minutes):
            alerts.append({"rule_version":"exercise-v1", "evidence":[signin["event_id"], change["event_id"]]})
print(alerts)

コードを読んだ予測では、i-1とc-1を参照するアラートが一つ出る。ここではその予測を実行して確認していない。コードは端末の証拠を問い合わせず、インシデントを作成せず、通知や権限変更も行わない。4件のfixtureなら二重の走査で理解しやすいが、本番ではqueryやstreamの方式を測定し、遅れて届くイベントや再評価の扱いを決める必要がある。

発表された検知のコード化を、開発手順を考える手掛かりにする。ルールをreviewし、fixtureを試し、過去データでbacktestし、アラートの質を評価してから適用を承認し、分析担当者の結果を戻す。公式説明にはSQLやPythonを含むYAML、CI/CDが登場するが、検証できるLakewatchのYAML schemaやdeployコマンドは示されていない。このPythonは独立した学習例である。

失敗演習：入力を一つ変える	予測する結果と確認すべき問い
同じc-1オブジェクトを再度追加する	重複除去後はアラートが一つ残る。ルールを再実行した場合のアラート重複はどう防ぐか。
c-1の発生を09:11 UTCにする	このルールではアラートが出ない。長い時間幅は拾う範囲を増やすが、無関係な作業も結び付けやすい。
c-1を別tenantにする	tenantをまたいで結び付けない。相関処理の分離と、読み取り権限の両方を確認する。
timezoneやactorを欠落させる	推測で補わず入力を拒否する。拒否した記録や収集エラーをどこで確認できるか。
端末イベントを削除する	ルールは引き続き検知できるが、調査の証拠は不足する。その欠落を明示する。
確認済みの保守承認を加える	アラート自体は残る。担当者は根拠付きで終了判断できるが、承認は過去の信号を消す操作ではない。

結果を説明できる統制を選ぶ

以下は仮想の設計で選んだ条件である。Lakewatchの既定値、対応する範囲、設定キーとしては扱わない。

演習での選択	目的、代償、確認方法
発生時刻で10分間を比較	仮説の範囲を絞る。1分・10分・30分をラベル付きの例で比べ、ノイズと見逃すテストケースを別々に数える。
生の証拠を30日保持	この演習では後日の再確認を可能にする。実際の期間は調査、privacy、契約上の要件から選び、保存・query・connector・model等の費用を確認する。
資源の所有者と変更承認を参照	小さな閲覧範囲で必要な事情を知る。業務データを読む主体には別のgrantが必要になる。拒否されるqueryと、承認記録が取得できない場合を試す。
封じ込め前に人が判断	読み取り専用の調査と変更操作を分ける。承認済みの対象、権限のある実行主体、確認した結果を必要とし、失敗や不明も残す。

保持するデータが増えれば調査範囲が広がる一方、管理すべき機微情報も増える。長い検知時間幅は相関する候補と処理を増やす。エージェントに広い権限を与えると手作業は減るかもしれないが、読める情報も広がる。収集の新鮮さ、正規化で拒否した割合、review済みアラートの有用性、担当者の調査時間を別々に見る。収集処理が止まっているなら、「アラートなし」は成功の指標にならない。過去データのbacktest精度も、そこに含まれない情報源の品質は示さない。

Lakewatchが課題に合うか判断する

多くの情報源を結び付け、権限管理された業務情報を再利用し、再現できる検知を保つチームには、Security Lakehouseが候補になる。既存SIEMを置き換える前に、現在の利用資格を確認し、優先する情報源の網羅性、証拠の保持、閲覧範囲の統制、アラート品質、対応手順への接続を、実際の業務に沿って検証する。提供元が示す費用や速度の表現は、その負荷で測定した結果や契約上のSLAではない。

必要なconnectorとインシデント管理が既存SIEMで満たされ、新しい基盤の現在の対応範囲が分からないなら、既存の仕組みを使う判断が有利になる。Databricks内のアクセスについての狭い問いなら、許可された監査テーブルの分析で足りる場合もある。「このPostgres queryが遅い理由」ならLakebaseの運用telemetryから始める。エージェントの振る舞いならtraceとアプリ状態の統制を見る。それぞれ解く問いが異なり、それだけでSOC全体の設計が成立するわけではない。

10月4日に確認した公開資料からは、Lakewatchの詳細なAPI仕様、parserの既定値、現在の利用権限、regionごとの一覧を確定できなかった。製品ページの正規化のリンク先も、一般的なLakeflow Connectの資料である。これは今回確認した範囲の限界であり、制限付きの資料が存在しない証明ではない。実導入では具体的な仕様を入手し、別製品の設定で空白を埋めない。

演習：証拠の対応図を提出する

実アカウントを使わず、fixtureに注釈を付け、失敗演習の結果を予測する。調査記録を1ページにまとめ、ルールのversionと証拠への参照、二つの説明、データ欠落のリスク、次の読み取り専用query、参照してよい範囲、対応を判断する責任者を記す。

さらに、提案する対応について、対象、承認、実行主体、結果を別の記録にする。結果は最初に未実行と記し、どんな証拠がそろえば変更できるか説明する。出所を保ち、tenantをまたいで結合せず、相関を手掛かりとして扱い、アラート → インシデントの判断 → 対応の実行を三つの状態として区別できれば、この演習の目的を満たす。この教材の手順、backtest、対応演習は未実行である。