【SSE】[Zscaler] [ZIA] [設計] [個別] [非インライン] Nanolog Streaming Service（NSS）

はじめに

ZIAでは、WebアクセスやFirewall、DNSなど様々なログを確認できます。

しかし、ZIA管理画面から参照できるログの保存期間は最大2週間です。

そのため、以下のような要件がある場合には、Nanolog Streaming Service（NSS）を利用します。

• 長期間ログを保存したい
• SIEMへログを転送したい
• SOCでセキュリティ分析を実施したい
• 本記事では、NSSサーバの役割と設計時の考え方について紹介します。

Nanolog Streaming Service（NSS）とは

Nanolog Streaming Service（NSS）は、

ZIAが生成するNanologを外部システムへ転送するための中継サーバです。

名前に「Streaming」とある通り、ログをリアルタイムで受信し、外部システムへ転送する役割を担います。

ここで重要なのは、NSS自体はログを保存するサーバではないということです。

ログの保管先は、以下のような外部ログ管理基盤になります。

• Syslogサーバ
• Splunk
• Microsoft Sentinel
• Elastic

NSSは、ZIAとログ保管基盤をつなぐログ転送・変換ゲートウェイ

と考えると理解しやすいでしょう。

NSSが必要になる理由

NSSを利用する目的は、大きく2つあります。

長期間ログを保管するため

ZIA管理画面から確認できるログは、最大2週間までとなっています。

そのため、監査要件やコンプライアンス要件で、

数か月〜数年間ログを保管する必要がある場合は、

NSSを経由して外部ログサーバへ転送しておく必要があります。

SIEMへログを転送するため

現在では、プロキシログやDNSログは、

SOCやCSIRTによる分析で非常に重要なログソースとなっています。

例えば、以下のような分析で利用されます。

• マルウェア感染調査
• シャドーITの検知
• 不審サイトへのアクセス分析
• インシデント調査

そのため、SIEMへリアルタイムにログを転送する構成が一般的です。

NSSの仕組み

NSSはユーザーが用意した仮想マシン（または物理サーバ）へデプロイします。

その後、ZIAテナントから払い出される証明書を利用して、

ZIAのNanologサービスとTLS通信を確立します。

この接続は、NSSからZIAへのアウトバウンド通信で確立されるため、

インターネットからNSSへの受信通信（Inbound）は不要です。

ログは、NanologサービスからNSSへリアルタイムに転送され、

その後、NSSからSyslogやSIEMへ送信されます。

NSSはログ変換サーバでもある

NSSの役割は、単純なログ転送だけではありません。

ZIAから送られてくるNanologは、圧縮・トークン化された内部フォーマットとなっています。

NSSでは、そのログを復元し、外部システムが理解できる形式へ変換して転送します。

例えば、

• Syslog
• CEF
• LEEF
• JSON

など、SIEM製品に合わせた形式で出力できます。

つまり、NSSはログ転送サーバであると同時に、ログ変換サーバでもあります。

必要なログだけ転送できる

ZIAでは、様々な種類のログが生成されます。

• Webログ
• Firewallログ
• DNSログ
• Tunnelログ
• Sandboxログ
• Auditログ

などです。

もちろん、すべて転送することもできますが、ログ量は非常に大きくなります。

SIEM製品は、取り込むログ量によってライセンス費用が変わることも多いため、

実際の設計では、必要なログだけを転送する構成が一般的です。

新しいZIA機能が追加されると、ログソースも追加されることがあるため、

NSSの運用では、「どのログを転送するか」を継続的に見直していくことも重要になります。

一時的な通信断にも対応している

NSSには、一時的にログを保持するバッファ機能があります。

例えば、SIEM側がメンテナンスなどで一時停止した場合でも、

短時間であればNSSがログを保持し、復旧後に再送できます。

また、一定条件下ではZIA側から過去のログを再取得（Replay）できる機能も用意されています。

もちろん、長期間ログを保持できるわけではないため、

ログ保管については引き続きSIEMやSyslogサーバ側で実施する必要があります。

設計で重要なこと

NSSを導入すると、「すべてのログを転送しておけば安心」と考えがちです。

しかし、実際にはログ量が非常に多くなり、ネットワーク帯域やSIEMのストレージ、

ライセンスコストへ影響します。

そのため、まず

「SOCで何を分析したいのか」

「どのログが本当に必要なのか」

を整理した上で、必要なログソースだけを転送する設計がおすすめです。

また、NSS自体はログ保存サーバではありません。

ログの保管や検索はSIEM側で行うことになるため、

NSSはログ転送・ログ変換の役割に特化したコンポーネントとして考えることが重要です。

Cloud NSSという選択肢

ここまで紹介したNSSは、ユーザー自身が仮想マシンをデプロイし、運用する必要があります。

そのため、OS管理やリソース管理など、一定の運用負荷が発生します。

現在では、これらをクラウドサービスとして提供するCloud NSSも利用できます。

構成が大きく異なるため、Cloud NSSについては次回の記事で詳しく紹介します。

➡【次の記事へ】【SSE】[Zscaler] [ZIA] [設計] [個別] [非インライン] Cloud NSS

管理人

自称SASEエンジニアです。 2児の父親をやりながら、日々エンタープライズ向けの次世代ネットワークインフラと格闘しています。一日一投稿を目標に投稿頑張りますので、是非読んでください！