はじめに
Zscaler Internet Access (ZIA) のログを Microsoft Sentinel に取り込む場合、従来は ZIA 側で NSS サーバを用意し、そこから CEF 形式の syslog を受信して Log Analytics ワークスペースへ転送する必要がありました。そのため、CEF コレクター用の Azure Monitor エージェントをインストールした Linux サーバを準備する必要があり、クラウドサービス同士の連携でありながら、オンプレミスのプロキシサーバーからログを収集するのと同じような手間がかかっていました。
この課題を解決するために、Zscaler Internet Access では Cloud NSS という機能を提供しています。Cloud NSS を利用することで、上記のようなサーバー構成を必要とせず、ZIA と Sentinel のクラウド間で直接ログを連携できるようになります。これにより、事前準備や運用の負担を大幅に軽減できます。今回は、この Cloud NSS の設定手順と動作について説明していきます。
前提条件
- ZIA において Cloud NSS の利用ライセンスを有していること
- ZIA において NSS を設定できる権限を有していること
- Azure サブスクリプションを有しており、Sentinel が構築済みであること
- Azure サブスクリプションの所有者の権限を有していること
- 設定手順内でロールの付与が必要であるため
- Entra ID アプリケーション登録が可能であること
構成イメージ
ZIA から直接 Azure Monitor のログ インジェスト API を実行し、Log Analytics ワークスペースにログを書き込む構成です。この際、書き込むための認証認可に Entra ID アプリを使用し、データ収集の設定にはデータ収集ルールとエンドポイントを設定します。
参考
デプロイメント ガイドはこちらです。
Sentinel 側設定
Entra ID アプリ登録
Entra ID アプリケーションを登録します。
Entra ID から [アプリの登録] > [新規登録] をクリックします。
名前を入力し [登録] をクリックします。
作成したアプリのページが開くので、[証明書とシークレット] > [新しいクライアント シークレット] をクリックします。
説明 (名称) と有効期限を設定し、[追加] をクリックします。
シークレット (パスワードに相当) が表示されるので [値] をコピーして保存します。
※ 再表示はできないため要注意
[概要]ページに戻り、アプリケーション (クライアント) ID と ディレクトリ (テナント) ID をコピーし保存します。
データ収集ルール設定
デプロイメント ガイドの通り、Bicep を利用してデプロイしていきます。
Sentinel の Log Analytics ワークスペースを開き、リソース グループ、ワークスペース名、ワークスペース ID、サブスクリプション ID をコピーします。
場所 (リージョン,ロケーション) については、上記画面だとデプロイ用の記載とは異なるため、右上の JSON ビューを開き、location の箇所をコピーします。
Zscaler の GitHub レポジトリにアクセスし、取得したいログ種別の .bicep と .bicepparam ファイルをダウンロードします。 (今回は Web を利用)
複数のログ種別 (web と fw など) を取得する場合、それぞれで設定が必要です。
.bicepparam ファイルを開き、先ほど取得した Log Analytics ワークスペースの情報とデータ収集エンドポイント、データ収集ルールの名称を入力します。
bicep ファイルを利用してデプロイしていきます。ローカルで Azure CLI を利用していないケースもあると思いますので、Cloud Shell を利用します。Azure ポータル右上のコンソール マークをクリックして開きます。
もし初回接続の場合、以下を参考に初期設定を行ってください。
Bash になっていない場合は、左上から切り替えます。
以下コマンドで操作するサブスクリプションを指定します。
az account set --subscription 'my-subscription-name'
[ファイルの管理] > [アップロード] から 2 つの bicep ファイルをアップロードし、ファイルが格納されていることを確認します。
デプロイメント ガイドにある bicep のデプロイコマンドを実行します。
az stack group create --name cloud-nss-web --resource-group <resource group
containing your log analytics workspace> --parameters cloud-nss-web.bicepparam --deny-settings-mode 'none' --action-on-unmanage deleteResources
実行後は以下のように表示されます。
次に以下 bicep の実行結果からログを送信する宛先のデータ収集エンドポイントの URL を取得します。
az stack group show -g <resouce group containing your log analytics workspace> -n
cloud-nss-web --query outputs.api_url
Entra ID アプリに対して、作成したデータ収集ルールにアクセス許可を設定します。Azure ポータルからモニター (検索する場合は「監視」) のページを開き、[データ収集ルール] から作成したデータ収集ルールをクリックします。
[アクセス制御(IAM)] > [+追加] > [ロールの割り当て追加] をクリックします。
監視メトリック発行者 (Monitoring Metrics Publisher) を選択し、[次へ] をクリック、メンバーのタブで [+メンバーを選択する] から、作成した Entra ID アプリを選択します。
[レビューと割り当て] からアクセス許可の設定を完了します。
ZIA 設定
ZIA ポータルで [Administration] から [Nanolog Streaming Service] をクリックします。
[Cloud NSS Feeds] タブで [+Add Cloud NSS Feed] をクリックします。
| 設定項目 | 設定内容 |
|---|---|
| SIEM Type | Azure Sentinel |
| OAuth 2.0 Authentication | デフォルトで有効、設定不可 |
| Client ID | 作成した Entra ID アプリのクライアント ID |
| Client Secret | 作成した Entra ID アプリのシークレットの値 |
| Scope | https://monitor.azure.com//.default |
| Grant Type | client_credentials |
| Authorization URL | 以下の URL で $tenantid を自組織のテナント ID を入れ替えて入力 https://login.microsoftonline.com/$tenantid/oauth2/v2.0/token |
| Max Batch Size | デフォルトの 1 MB を指定※ |
| API URL | az stack group show コマンドの実行結果 (データ収集エンドポイントの情報) |
| HTTP Headers | Key 1: Content-Type / Value 1: application/json |
| Log Type | Web Log |
| Feed Output Type | JSON |
| JSON Array Notation | Enable |
| Feed Escape Character | "\, |
| Feed Output Format | 後述します |
※ 使用するログ インジェスト API の最大サイズが 1MB のため
ログ フォーマットはデフォルト設定では正常に Sentinel 側でパースできないため、デプロイメントガイドに従い、以下の GitHub レポジトリの値をコピーして設定します。入力後に保存して、アクティベートします。
接続テストのボタンをクリックし、正常性を確認します。
成功すると以下の表示になります。
ログ取得結果
正常に設定が完了すると、以下のように CommonSecurityLog テーブルにログが記録されます。
トラブル シューティング
ログが正常に取得できない場合の Azure 側のトラブル シューティング方法をいくつか紹介します。
まず Entra ID アプリケーションが正常に認証できているかを認証ログで確認します。
Entra ID ページの [サインイン ログ] > [サービス プリンシパルのサインイン] を開き、作成した Entra ID アプリの名前のログを確認します。
データ収集ルールの診断設定をすることで、エラー発生時のログを取得・確認することが可能です。データ収集ルールの [診断設定] から取得対象のログを選択し、ログを保存する Log Analytics ワークスペースを指定します。
エラー時には以下のように記録されます。(以下は異常な json フォーマットの例)
データ収集ルールのメトリックからログの受信状況を確認できます。データ収集ルールの [メトリック] を開き、確認したい項目を選択します。
以下のように時系列でログ収集状況が確認できます。
懸念事項
ログ インジェスト API には以下の制限事項が存在します。
大規模な環境の場合、2GB/分 (=120GB /h) を超えるログが発生する可能性があります。そのため、Cloud NSS 側のエラー ハンドリング、リトライ処理について確認する必要があると考えています。
- 書き込み時にエラーとなったログは破棄されるのか、リトライされるのか
- 書き込みが遅延した場合、どの程度 (時間・容量) バッファされるのか
Discussion