はじめに
こんにちは、セキュリティチームのHitomiです。
Netskope の Real-time Protection ポリシーで、Browse を含む通信を Alert で様子見してから Block に切り替える・・・ホワイトリスト運用を始めるときの定番の進め方だと思います。
ところが Alert のまま何日待っても、Skope IT > Alerts には何も出てきません。それでいて Block に変えた瞬間、「この通信、Alert のときは影も形もなかったのに」という遮断が起きる。
Browse の Alert でアラートが生成されない仕様そのものは、昨年の弊社ブログ「【Netskope】Advanced Analyticsで特定のカテゴリに対する閲覧状況を可視化してみよう！」でも取り上げました。あのときは「特定カテゴリのサイトを誰がどれだけ見ているか」を知りたかったので、Advanced Analytics の Page Events をカテゴリで絞ってダッシュボードにする、という答えで足りていました。
今回、お客様からいただいたご相談は、そこから一段進んだものです。「Block へ変更する前に、影響範囲を洗い出す方法はないのか」・・・カテゴリ単位の閲覧状況ではなく、「この Alert ポリシーを Block にしたら、実際に何が止まるのか」をポリシー単位で知りたい、という内容でした。
最初に仕様を確認した時点では「Alert のまま、ユーザーに通知せず、Block で止まる通信だけを事前に抽出する標準的な方法はない」というのが答えでした。
ただ、そこで終わらせるのも悔しかったので、弊社環境で検証したところ、Transaction Events に答えが残っていました。
とはいえ、拾えない通信もあります。そこも隠さず書いておきます。
はじめにまとめ
- Browse を Alert にしても
Skope IT > Alertsには起票されない。これは仕様で、ポリシーマッチ自体は正常に行われている- User Alert なら見えるが、ユーザー通知を伴ううえ Browse での利用は Netskope が推奨していない
- Transaction Events には、トランザクション単位で
RTP Name（ポリシー名）とRTP Action = alertが記録される。Alert 期間中に対象ポリシー名で抽出すれば、Block 化の影響を検討するための母集団を確認できる- 条件・順序を変えず Action だけを Alert → Block にする前提で、メーカーからも「設計上も適切」と回答あり
- 総件数ではなく「ユニークドメイン数」「対象ユーザー数」で見る
- 抽出に出ない通信や、別途扱いを確認すべき通信がある。ステアリング対象外の通信、Netskope Advanced Analytics（NAA）への反映遅延やサンプリング期間不足に加え、SSL Do Not Decrypt は
SSL DND: Alert Action Supportフラグの状態やポリシー順序で扱いが変わる
Browse の Alert は、なぜ Alerts に出てこないのか
今回のポリシー構成は、上位に業務で許可するアプリ・サイトの Allow ポリシーを並べ、最下位に Any Web Traffic を対象にした Alert ポリシーを置く、というものです。Alert 期間で通信を見極めてから、最下位のポリシーだけ Block に変える・・・いわゆるホワイトリスト運用の移行手順です。
この構成で Alert 期間に Skope IT > Alerts を眺めても、最下位ポリシーに該当した Browse 通信は一件も出てきません。公式ドキュメントにはこう書かれています。
Alert events are not generated for Real-time Protection Policies with the “Alert” action selected for “Browse” activity.
「じゃあ User Alert にすれば見えるのでは」と考えるのは自然な流れです。実際、User Alert なら通知画面が出るので通信の存在は分かります。ただ、User Alert は初回通知を抑止できません。
Mute 設定で初回通知後の再通知を一定期間抑えることはできますが、初回は必ずユーザーの画面に出ます。そして Netskope のベストプラクティスには、アラート頻発を避けるため Browse では User Alert を使わないよう明記されています。
To avoid frequent alerts, do not use User Alert when the activity is Browse.
つまり、Alert では見えず、User Alert ではユーザー体験に影響する。この時点で「ユーザーに気づかれずに、Block で止まる通信を事前に数える」道は塞がっているように見えます。
実際、お客様環境では Alert 期間に確認できなかった通信が、Block 変更後にポリシーで判定されていました。
確認したログでは、Application Events には記録されず、Page Events にだけ記録される Browse 通信が存在しています。アプリにマッピングされないドメインへの通信がこの典型で、Application Events だけを見ていると丸ごと抜け落ちます。
〜 参照元 〜
- Alerts —「Customize Columns」
- Configuring Real-time Protection Policies —「Profile & Action」Alert の Tip
- Best Practices for User Alert Policies —「Configuring User Alert Policies」
結論：ポリシーマッチは Transaction Events に残っている
Alerts に起票されないのは「ログが残っていない」からではありません。Browse の Alert ポリシーは通信量が膨大になるため、Skope IT > Alerts には起票しない仕様になっている・・・これがメーカーからの回答です。
ポリシーマッチ自体は正常に行われていて、その結果は Transaction Events に、トランザクション単位で記録されています。
Transaction Events のフィールドリファレンスを見ると、Real-time Protection Policy セクションに次の 2 つがあります。
| フィールド名 | 管理コンソール上の名称 | 説明（公式記載の要約） |
|---|---|---|
x-policy-action | (RTP Policy) Action | RTP ポリシー評価後に実行されるアクション。allow、block、bypass、alert、useralert など |
x-policy-name | (RTP Policy) Name | マッチして x-policy-action をトリガーした RTP ポリシー名 |
x-policy-action の取りうる値に alert が明記されています。NAA上ではこれが RTP Action と RTP Name として見えます。
Alert 期間中に「RTP Name = 対象ポリシー名」で絞り込めば、Block に変えたときに止まる通信の母集団がそのまま出てくる、というわけです。
メーカーからは、ポリシー順序や条件を変えず Action のみを Alert から Block へ変更する場合、Alert 時に対象ポリシー名で抽出した Transaction Events を Block 時の影響把握に使う手法は設計上も適切、と回答をもらっています。
〜 参照元 〜
- Transaction Events Fields Reference —「Real-time Protection Policy」
- Advanced Analytics Transaction Events
検証：Advanced Analytics の Transaction Events で抽出する
弊社環境で実際に抽出した条件と結果です。
1）データセットとフィルター
Advanced Analytics > Explore で次のように設定します。
- データセット：Transaction Events
- フィルター 1：Event Date が直近 1 日（検証用は1日で設定しましたが、7日程度が良いと思います）
- フィルター 2：RTP Name が対象の Alert ポリシー名
2）結果の読み方
弊社環境では約 500 行が抽出され、すべて RTP Action が alert、RTP Name が対象ポリシー名でした。Application が未マッピングの通信も、Domain を含めて Transaction Events 上に並んでいます。Application Events だけでは見えなかった通信が、ここでは同じ土俵に乗っています。
またNAAはエクスポートできるのでデータ保持期間の関係で保持しておきたい場合は結果を抽出しておくこともできますね。
3）影響範囲の軸：ユニークドメイン数・対象ユーザー数
総件数は、影響範囲の指標としては使いにくい数字です（理由は次章）。メーカーからも、Domain や User でグループ化し、影響を受けるユニークドメイン数・対象ユーザー数を軸に確認するのが影響範囲を把握しやすい、と案内をもらっています。
| 見たいこと | グループ化の軸 | 読み方 |
|---|---|---|
| Block で止まる宛先の数 | Domain（Distinct Count） | 1 ドメインずつ「許可に上げるか、止めるか」を判断する単位になる |
| 影響を受ける人の数 | User（Distinct Count） | 少人数に偏っていれば個別フォロー、全社に広がっていれば周知が先 |
| 誰がどこに行っているか | Domain × User | 特定部署だけが使う業務 SaaS の洗い出しに使う |
| アプリ認識の有無 | Application の有無 × Domain | 空の側が Application Events から漏れていた母集団 |
〜 参照元 〜
件数をそのまま「ブロック回数」と読まないこと
約 500 件という数字を見て「Block にしたら 1 日 500 回止まるのか」と思ったら、それは違います。
Transaction Events の 1 行は、画像や JavaScript などのサブリソースを含む「個別の HTTP/HTTPS リクエスト」です。1 ページを開けば数十リクエストが走るので、Alert 期間の件数はページ数よりもずっと多くなります。一方 Block に切り替えると、最初のアクセスで遮断されてサブリソースの通信そのものが発生しません。結果として、Block 後の遮断回数は Alert 期間の抽出件数と一致しません。
件数は「多い・少ない」の肌感に使うにとどめて、判断にはユニークドメイン数と対象ユーザー数を使う。前章の表はそのための軸です。
抽出に出てこない通信
Transaction Events はポリシー評価の結果を記録するものなので、ポリシー評価の対象にならなかった通信は当然出てきません。
1）ステアリング対象外の通信
Steering Configuration で例外にしている通信は Netskope を通らないので、Transaction Events にも残りません。そもそも例外設定としている通信はBlock 化の影響も受けないため、影響範囲の観点では「出てこなくて正しい」通信です。
2）NAA への反映遅延と、サンプリング期間
まず確認したいのが、Transaction Events の取り込みが止まっていないかです。公式ドキュメントには、直近 90 日間に Transaction Events のクエリやダッシュボードを一度も実行していないテナントは取り込みが自動的に一時停止される、と記載されています。
この状態で Explore を開いても結果は 0 件です。こういった状況であることを確認したときは購入元の相談窓口にご相談ください。
それ以上に効くのが期間の問題です。1 日単位では、週次・月次でしか発生しない定常業務の通信（締め処理、月初の申請系 SaaS など）を拾いきれません。メーカーからは 1〜2 週間程度のサンプリングが推奨されています。弊社の検証は直近 1 日で行いましたが、本番の見極めでは期間を伸ばしてください。
〜 参照元 〜
3）SSL Do Not Decrypt の対象通信
SSL Do Not Decrypt の対象通信は、Action が Alert の Real-time Protection ポリシーにマッチするかどうかがテナント設定で変わります。これを制御するのが SSL DND: Alert Action Support（公式ドキュメント上の機能名は Alert Action Support）というバックエンドフラグです。
フラグが無効のテナントでは、Alert 期間中に DND 通信は最下位の Alert ポリシーにマッチしません。そのため Transaction Events を RTP Name で絞っても出てきません。一方 Block に変えると Block ポリシーにはマッチして止まります。「Alert のときは影も形もなかったのに」の正体の一つがこれです。
この通信は Page Events には記録されています。メーカーからは、Page Events を Bypass Traffic = yes かつ Bypass Reason = SSL Do Not Decrypt Bypass Policy Matched で絞り、対象ポリシーの宛先ドメインやカテゴリと突き合わせれば、ある程度の見積もりは可能と案内をもらっています。見る軸は本文の表と同じく Domain と User の Distinct Count です。
メーカー回答によるとフラグが有効のテナントでは、DND 通信に限り Browse でも Alert イベントが出力されます。復号対象の Browse がアラートを出さない仕様とは挙動が異なります。ただし同一ユーザー・同一ドメインへのアクセスは 1000 回につき 1 件に抑制されるため、Alerts の件数をアクセス数として読むことはできません。
- フラグを有効化する場合は、これまで下位の Block ポリシーにマッチして止まっていた DND 通信が、有効化後は上位の Alert ポリシーにマッチして通るようになる可能性があります。ポリシー順序の確認を先に行ってください。
〜 参照元 〜
- Configuring Real-time Protection Policies —「Source > Access Method」Tip および「Profile & Action」Note
- Add a Policy for SSL Decryption
- Transaction Events Fields Reference —「SSL Policy」
おわりに
冒頭の問いに戻ると、「Alert のままユーザーに気づかれず、Block で止まる通信を事前に洗い出す」ことは、Alerts 画面を見ている限りはできません。
ですが、ポリシーマッチの記録は Transaction Events に残っていて、ポリシー名で抽出すれば母集団は取り出せます。見るべき数字は総件数ではなく、ユニークドメイン数と対象ユーザー数です。
仕様のせいで見られないと諦めていた通信も、全部ではありませんが把握できますので良かったら試してみてくださいね！
参考リンク（一次情報）
- Alerts（Skope IT） — Netskope 公式ドキュメント
- Configuring Real-time Protection Policies — Netskope 公式ドキュメント
- Best Practices for User Alert Policies — Netskope 公式ドキュメント
- Transaction Events Fields Reference — Netskope 公式ドキュメント
- Advanced Analytics Transaction Events — Netskope 公式ドキュメント
- Skope IT Transaction Events — Netskope 公式ドキュメント
- Add a Policy for SSL Decryption — Netskope 公式ドキュメント
- Advanced Analytics Data Retention — Netskope 公式ドキュメント
- Pausing and Resuming Transaction Events — Netskope 公式ドキュメント
関連記事
※本記事の内容は 2026 年 10 月時点の公式ドキュメントの記載、Netskope サポートからの回答、および弊社環境での検証結果に基づいています。検証結果はテナント構成やライセンスにより異なる可能性があります。
