コンテンツにスキップ
Yagra

転送

お使いの機器はすでに syslog、トラップ、フローを Yagra へ送っています。転送機能は、そのデータを さらに先へ — SIEM、コンプライアンス用のアーカイブ、別のコレクタへ — 引き渡します。すべての機器に 2 つ目のエクスポート先を設定する必要はなく、Yagra 側が何かを手放すこともありません。

転送とは何か

Section titled “転送とは何か”

転送は、受信したパッシブデータのフィルタ付きのティーです。転送先は「このフィルタに一致した ものはそこへも送る」と宣言するだけで、Yagra は変わらず取り込み、照合し、アラートを上げ、 保存し続けます。これは分岐コピーであって迂回ではありません — Yagra は記録の正本であり続けます。

転送先は設定 ▸ 転送で設定します。送信側の形は意図的に定められています。 送信はすべてコアが行い、ポーラーは受信したバイト列をバス経由でコアへ運ぶだけです。これに より外向き通信の出口が 1 か所にまとまります — ファイアウォールで許可するアドレスはポーラーごとに 1 つではなく全体で 1 つで済み、本社側で転送先を追加してもリモート拠点のポーラーに新しいアウト バウンドルールは要りません。高可用性のペア構成では、送信するのはアクティブ（リーダー）のコア なので、コアが 2 台動いていても出口は 1 か所のままです。

ソース

Section titled “ソース”

転送先が何を受け取るかは、3 つのソース種別で選択します。

ソース 運ぶもの
syslog 受信した syslog メッセージ — および Webhook で取り込まれたイベント。これらはこの種別に含まれます
trap 受信した SNMP トラップと inform
flow 受信したフローエクスポート（NetFlow v5/v9、IPFIX、sFlow）。データグラム丸ごとで中継されます

ポーラーは、現時点で転送先が 1 つも存在するかどうかに関わらず、元のバイト列をコアへ運びます。 この運搬は意図的なものです。キャプチャの切り替えスイッチを設けてしまうと、転送の忠実度がシステム の性質ではなく設定に左右されることになります — 転送先を追加したその瞬間から、バイト単位で正確な 出力がそのまま使えるべきだからです。（ただしリモート拠点ではバス帯域のコストがかかります。 外向き通信の要件を参照してください。）

転送先

Section titled “転送先”

転送先の種別は 6 つ。それぞれワイヤ上の挙動が定義されています。

種別 ワイヤ形式 受け付けるソース
Syslog over UDP RFC 5424 syslog、trap
Syslog over TCP RFC 6587 のオクテットカウントフレーミング（メッセージ境界が埋め込み改行に耐えます） syslog、trap
Syslog over TLS RFC 5425 syslog、trap
SNMP トラップの再送出 UDP 上の SNMPv2c トラップ PDU trap のみ
フロー中継 元のデータグラムを原本のまま UDP で flow のみ
BigQuery ストリーミングインサートによる正規化済みの型付き行 すべて

中継の忠実度。 中継系の転送先には 2 つのモードがあります。原本（verbatim） は元のデータ グラムをバイト単位で正確に送るため、コレクタは機器が送ったものをそのまま受け取ります。 復元品（rendered） はパース済みのフィールドからメッセージを組み立て直したものです（syslog 転送先なら RFC 5424、トラップ転送先なら SNMPv2c トラップ PDU）。組み合わせによっては「元のもの」 が意味を成しません — たとえばトラップを syslog 転送先へ中継する場合です。このときは復元品が 使われます。syslog のポートに落とされたトラップ PDU はデコード不能だからです。

上の対応表も同じ論理から導かれます。トラップ再送出の転送先が受け付けるのはトラップだけです — syslog の 1 行から SNMP PDU を組み立てることはできません。syslog 系の転送先が syslog に加えて トラップも受け付けるのは、トラップがログ行へ自然に変換できるからで、実際たいていの SIEM は トラップをその形で受け取りたがります。

フロー中継はバイト単位で正確か、さもなくば送らないかのどちらかです。 フローエクスポートは テンプレートに束縛されたバイナリであり、復元品がその代わりを務めることはできません。そのため API は、コレクタがパースできないものを黙って送りつける代わりに、フロー転送先での復元品モードを 拒否します。テンプレートのデータグラム（NetFlow v9/IPFIX の定期的なテンプレート更新）は フィルタの有無に関わらず常に通過します — それがなければ、フィルタ付きのコレクタは受け取った レコードを永久にデコードできなくなるからです。

BigQuery だけは毛色が違います。ライブなストリームをミラーする代わりに、正規化された型付き の行を — イベント 1 件につき 1 行、フローレコード 1 件につき 1 行 — テーブルへストリーミングし、 数か月分の履歴を問い合わせられるようにします。テーブルは Yagra が日付パーティション付き・ クラスタリング済みで作成しますが、データセットはあらかじめ存在している必要があります。データ セットのリージョンは変更できず、Yagra があなたのデータ所在地を黙って選ぶことはしないからです。 使用する ID にはデータセットに対する BigQuery Data Editor ロールを付与してください。サービス アカウントの JSON 鍵を貼り付けるか（保存時に暗号化され、以後は二度と表示されません）、コアを Workload Identity 付きの Google Cloud 上で動かしているなら認証情報を空のままにします（この場合 認証情報は一切保存されません）。有効化する前に知っておくべきことが 2 つあります。1 つは、 ストリーミングインサートが Google の課金対象であること。もう 1 つは、元のバイト列を 意図的に保存しないことです — 中継されたデータグラムは自分で選んだコレクタを一度通り過ぎる だけですが、テーブルのほうは残り続けますし、syslog の本文には日常的に認証情報が含まれます。 バイト単位で正確なアーカイブも必要なら、BigQuery 転送先と中継系の転送先を組み合わせてください。

フィルタ

Section titled “フィルタ”

各転送先は任意のフィルタを持てます。最大 32 個の型付き条件からなる、すべて一致 （match-all）またはいずれか一致（match-any）のセットです（オペランドは 512 文字まで）。 フィルタが空なら、選択したソースのすべてを転送します。

条件はフィールド + 演算子 + オペランドです。イベント側のフィールドは、送信元 IP、ポーラープール、 イベント種別、syslog のファシリティと重大度、ホスト名、アプリケーション名、メッセージ本文、 トラップ OID、トラップの varbind をカバーします。フロー側のフィールドは、送信元／宛先アドレス、 プロトコル（tcp のような名前も受け付けます）、送信元／宛先ポート、送信元／宛先 AS をカバー します。演算子は 12 種類 — 等価、含む、前方一致、正規表現（およびそれぞれの否定）、リストへの 所属、CIDR への所属、数値の範囲 — があり、それぞれがフィールドに対して型検査されます。 ポートに対する正規表現や、ホスト名に対する CIDR 判定は、保存時に 400 で拒否されます。送信時に 黙って無視されることはありません。

典型的なかたちとしては、本当に必要なものだけを受け取る SIEM 向けの転送先（severity が warning 以上、かつ hostname が拠点コードで始まる）や、内部レンジに限定した NetOps 用のフロー アーカイブ（src_addr が 10.0.0.0/8 または dst_addr が 10.0.0.0/8）などがあります。

フィルタの意味はデータの形によって異なり、その違いは重要です。

  • イベントのフィルタはメッセージ単位で厳密です。 syslog の 1 行やトラップは、一致するか しないかのどちらかです。
  • フローのフィルタはレコード単位ではなくデータグラム単位です。 中継されるフローデータグラムは、 その中のいずれかのレコードが一致した時点で丸ごと転送されます — 一致しないレコードも含めて です。レコードを取り除くにはデータグラムを再エンコードするしかなく、再エンコードすればバイト 単位の正確さという約束が壊れるからです。求めたレコードの上位集合が届くと考えてください。部分 集合になることはありません。
  • BigQuery のフローフィルタはレコード単位で厳密です — 行は独立しているため、一致したレコード だけが行になります。フローを正確に選別したいなら、それができる転送先は BigQuery です。

ガードレールが 2 つあります。フィルタ判定のために検査されるのは 1 データグラムあたり最大 1,024 レコードまでであること、そしてまったくデコードできなかったデータグラムは、フィルタ付きの転送先 ではフィルタなしで転送されるのではなく破棄されてカウントされることです — フェイルオープンする フィルタは、フェイルクローズするフィルタより悪いからです。

TLS

Section titled “TLS”

中継系の種別のうち、通信路が保護されるのは TLS の syslog 転送先（RFC 5425）だけです — UDP と TCP の syslog、トラップ再送出、フロー中継はワイヤ上では平文なので、それらは信頼できるネットワークに 留め、コレクタまでの経路が自分の管理下にないものを通るときは常に TLS を選んでください。 （BigQuery は性質上 HTTPS です。）

証明書の検証にはシステムのトラストストアを使い、加えて任意で転送先ごとの CA 証明書（PEM）を 指定できます。プライベート CA が署名したコレクタ向けです。検証を無効化することはできません — そのためのフラグは存在しません — ので、TLS 傍受プロキシの背後にある転送先には接続できません。 代わりにそのプロキシの CA を転送先に追加してください。CA 証明書は秘密情報ではありません。他の 転送先設定と同じく API を往復しますし、意味を成さない非 TLS の転送先種別に指定した場合は拒否 されます。

信頼性と可視性

Section titled “信頼性と可視性”

遅い転送先や死んだ転送先が Yagra の問題になってはいけません。すべての転送先は次の仕組みで 隔離されています。

  • 上限のあるキュー（4,096 メッセージ）。いっぱいになると、その転送先向けの新しいメッセージ は破棄されてカウントされます — 追いつけない転送先のせいで取り込み・照合・アラートが 止まることは決してありません。
  • 転送先ごとの任意のレート制限。1 秒あたりのイベント数でライセンスやサイジングが決まっている コレクタ向けです。
  • サーキットブレーカー。連続 5 回の送信失敗で開き、30 秒後に 1 回だけプローブを通し、送信が 成功したときにだけ再び閉じます。死んだコレクタが生むのはカウンタであって、滞留ではありません。
  • タイムアウトと名前の再解決。接続と書き込みは 5 秒でタイムアウトし、転送先のホスト名は 5 分 ごとに再解決されるため、長命な中継はコレクタの移転に追随します。

これらはすべて転送先ごとに可視化されます — 送信数、フィルタで除外した数、破棄した数（理由別: キュー満杯、レート制限、サーキット開放、フィルタ不能、デコード不能）、現在のキュー深さ、 サーキットの状態 — 設定 ▸ 転送の画面、GET /api/v1/forwarding/status、そして コアの Prometheus メトリクス（破棄は yagra_forward_dropped_total に理由別で計上されます）で 確認できます。

忠実度も同じように監視されます。バイト単位で正確な出力を約束していたのに元のデータグラムなしで 済ませざるを得なかった転送先はそれをカウントし、元のバイト列を供給できないポーラーは画面上に名前が 出ます。転送は黙って劣化できないように作られています — 出力が約束より劣るときは、画面がそう 言います。

外向き通信の要件

Section titled “外向き通信の要件”

送信はすべてコアが行うため、ファイアウォールの例外が必要なのはコアホストだけです。

転送先の種別 必要な外向き通信
中継（UDP / TCP / TLS の syslog、トラップ、フロー） コレクタの host:port
BigQuery HTTPS で bigquery.googleapis.com と oauth2.googleapis.com — 保存鍵の代わりに Workload Identity を使う場合は GCE メタデータサーバー（169.254.169.254）も

転送先を追加するまで何も送信されません — 転送先を 1 つも設定していないデプロイは、転送のための 外向き通信を一切行いません。

1 つだけ、出口ではなくバス側で支払うコストがあります。転送機能が「機器が送ったとおりのもの」を 中継できるよう、ポーラーは常に元のバイト列をコアへ運びます — 生のイベント量のおよそ 1.45–1.64 倍、加えて受信したフローデータグラムすべてを集約ストリームと並行して原本のまま 運びます。これはリモート拠点のポーラーにとって実際の WAN トラフィックです。サイジングの議論と 外向き通信の全一覧はポートとファイアウォールにあります。

関連ページ

Section titled “関連ページ”