【実務・中級編】 CASBの監査ログ（Audit Log）収集とSIEM/SOARとの連携フォーマット – ゼロトラスト＆エンタープライズセキュリティ実践ガイド

境界防御の終焉と「見えない場所」の可視化：CASBログをSIEMへ流し込む実務の作法

「VPNさえ張っておけば安全だ」――そんな神話が崩壊して久しい。SASE（Secure Access Service Edge）という概念が現場のスタンダードとなり、我々は今、オフィスという物理的な箱から解放された代わりに、クラウドという広大な荒野に全社員を放り出している。

そこで重要になるのが、CASB（Cloud Access Security Broker）の役割だ。だが、CASBを入れて満足してはいないだろうか？ ログをダッシュボードで眺めているだけでは、真のインシデントは防げない。真の凄腕エンジニアは、CASBが吐き出す宝の山を、SIEM（Security Information and Event Management）という「脳」へ接続し、リアルタイムで相関分析を回すことに執念を燃やす。

今日は、CASBの監査ログを外部基盤へ転送し、SOAR（Security Orchestration, Automation and Response）で自動検知・遮断まで繋げるための、泥臭くも極めて実務的な「ログ収集の作法」を伝授しよう。

—

1. ログ収集の現在地：ポーリング（API）か、プッシュ（Syslog/Webhook）か

実務において、CASBからログを吸い上げる手法は大きく分けて二つある。

  • API経由のポーリング: CASB側のManagement APIを定期的に叩き、JSON形式でログを取得する。網羅性は高いが、ポーリング間隔によるタイムラグが最大の敵だ。
  • イベント駆動（Webhook/Syslog）: 特定のイベントが発生した瞬間にCASB側からSIEMへデータを飛ばす。即時性は抜群だが、ネットワーク経路の信頼性や認証設定に頭を悩ませる必要がある。

現場で一番多いトラブルは、「APIのレートリミット（429 Too Many Requests）に引っかかり、重要なログが欠損する」というケースだ。ここを制御できるかどうかが、一人前と半人前の分かれ道になる。

—

2. API連携の実装：Pythonで書く堅牢な収集スクリプト

APIを使ってログを取得する場合、ただリクエストを送るだけではダメだ。cursor（カーソル）やtimestampを用いた増分取得の実装が必須となる。以下は、あるCASB APIを想定した、実務で使えるPythonの骨子だ。

import requests
import time

# API設定
API_ENDPOINT = "https://api.casb-vendor.com/v1/audit/logs"
API_KEY = "your-api-key-here"
HEADERS = {"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"}

def fetch_logs(last_timestamp):
    params = {"start_time": last_timestamp, "limit": 1000}
    try:
        response = requests.get(API_ENDPOINT, headers=HEADERS, params=params, timeout=30)
        response.raise_for_status() # 4xxや5xxエラーを検知
        return response.json()
    except requests.exceptions.RequestException as e:
        # ここでアラートを飛ばす仕組みを入れるのがプロの仕事
        print(f"ログ取得失敗: {e}")
        return None

# メインループのイメージ
last_ts = "2023-10-27T00:00:00Z"
while True:
    logs = fetch_logs(last_ts)
    if logs:
        # ここでSIEMのインジェストAPIへ転送する処理を記述
        # 最後にラストタイムスタンプを更新
        last_ts = logs[-1]['timestamp']
    time.sleep(60) # 頻度を適切に調整してレートリミットを回避

—

3. Syslog転送時の落とし穴：RFC 5424の解釈

もしSIEMがSyslogでの受診を求めているなら、RFC 5424形式を意識する必要がある。特に、「構造化データ」をどう扱うかが重要だ。

多くのCASBは、デフォルトのSyslog設定だと冗長なヘッダーを吐き出す。SIEM側で正しくパース（正規化）させるためには、CASB側の出力設定で以下を徹底せよ。

  • Priority: 正しいファシリティ（local0など）とセベリティを設定する。
  • Timestamp: ISO 8601形式（2023-10-27T10:00:00Z）で統一する。これがないと、ログの時系列が狂い、相関分析が意味をなさなくなる。
  • Structured Data: 可能であればJSON形式でペイロードを囲む。正規表現で無理やりパースするのは、運用の負債になるだけだ。

—

4. 現場のデバッグTips：パケットを信じろ

ログがSIEMに届かない時、管理画面を眺めていても解決しない。まずは tcpdump を使って、パケットが正しく飛んでいるか確認する。

# SIEMの収集サーバー（例: 192.168.10.50）に向けたUDP 514番ポートの通信をキャプチャ
sudo tcpdump -ni eth0 port 514 and host 192.168.10.50 -v

もしパケットが見えないなら、CASB側の設定ミスか、途中のFWで遮断されている。もしパケットは見えているのにSIEMで可視化されないなら、それはSIEM側の「パーサー（Parser）」の設定ミスだ。ログのフォーマットを grep で抜き出し、SIEM側で期待しているスキーマと突き合わせる。この「泥臭い突き合わせ」こそが、障害を最短で解決する唯一の道だ。

—

結びに：エンジニアとしての矜持

ゼロトラストとは、単にツールを導入することではない。「すべての通信を疑い、その証跡を逃さず記録し、自動的に分析する」という運用の哲学そのものだ。

CASBのAPIを叩き、ログを整形し、SIEMへ流し込み、SOARで自動化する。この一連の流れを構築することは、一見すると地味で骨の折れる作業だ。だが、深夜のインシデント発生時に、SIEMのダッシュボードに「異常なデータダウンロード」のアラートが即座に表示され、自動で該当ユーザーの権限を無効化できたとき、君は実感するはずだ。自分が守っているのは、単なるネットワークではなく、組織の信頼そのものなのだと。

さあ、マニュアルを閉じて、まずは自分の環境でAPIの疎通確認から始めてみよう。現場のエンジニア諸君、幸運を祈る。

スポンサーリンク

コメント

タイトルとURLをコピーしました