はじめに
こんにちは、セキュリティチームのHitomiです。
URLリストからDestination Profileへの移行やステアリング分離をはじめ、ここ最近のNetskopeはテナントまわりの変更が続いています。設定を触る機会が増えると、ふと手が止まる瞬間があります。
このFQDN、いまどのカテゴリに入っていて、どのポリシーから見られてるんだっけ？
カスタムカテゴリを1つずつ開いて、ポリシーを上から順に眺めていけば分かります。ただ、変更のたびにそれをやるのは正直しんどいしできればやりたくない。
そんなときに使えるのが Skope IT > Tools > URL Lookup です。URLを1件入れるだけで、カテゴリとポリシーが一覧で返ってきます。ただし、表の読み方に一つだけ落とし穴があります。
変更続きの今こそ使える、URL Lookup をご紹介します！
はじめにまとめ
- URL Lookupは、URLまたはドメインを1件入れると、情報を一覧で返してくれるツールです。
- 場所は
Skope IT > Tools > URL Lookupです。
- 場所は
- 結果は「カテゴリ」と「ポリシー」の2つの表で返ってきます。
- あわせて、SaaSアプリとの関連付け、Netskopeへステアリングされているか、動的に分類されたか、も表示されます。
- ポリシーの表に出るのは、そのURLが「参照されている」ポリシーです。
- まとめて引きたいときはREST APIがあります。
- ただし、公式ドキュメントが挙げている戻り値はカテゴリとURLリストで、ポリシーは入っていません。
URL Lookupで何が見えるの？
公式ドキュメントの説明は短く、URL Lookupは「単一のURLまたはドメインの情報を検索して取得するツール」です。返ってくるのは、そのURLが属するカテゴリと、そのURLが参照されているポリシー（Real-time ProtectionやSSLなど）です。
画面に出る項目を整理するとこうなります。
| 見えるもの | 内容 |
|---|---|
| カテゴリの表 | 該当するカテゴリの名前と種別（Predefined／Custom） |
| ポリシーの表 | 関連するポリシーの名前と種別（SSL、Inlineなど） |
| SaaSアプリとの関連付け | 関連付けがない場合は、Site Name 欄にトップレベルドメインを除いたドメイン名が表示される |
| ステアリング | Netskopeへステアリングされているか（バイパスされている場合は、該当するSteering Configurationも表示される） |
| 動的分類 | Netskopeが動的に分類したか |
地味に嬉しいのは、カテゴリの表にカスタムカテゴリも出てくるところです。「このURL、どのカスタムカテゴリに入れたっけ」を、カテゴリを1つずつ開かずに確認できます。
〜 参照元 〜
- URL Lookup —「URL Lookup」（Netskope公式ドキュメント）
URL Lookupの使い方
1）URL Lookupを開く
管理コンソールで Skope IT > Tools > URL Lookup を開きます。
2）URLかドメインを1件入れる
入力欄に、調べたいURLまたはドメインを入れます。入力できるのは1回につき1件です。
3）2つの表を読む
有効なURLを入れると、カテゴリの表とポリシーの表が表示されます。
読む順番は、カテゴリの表が先です。想定したカテゴリ（特にカスタムカテゴリ）に入っているかを見てから、ポリシーの表で、そのURLを参照しているポリシーに想定外のものが混ざっていないかを確認します。
〜 参照元 〜
- URL Lookup —「URL Lookup」（Netskope公式ドキュメント）
ポリシーの表を読むときに気をつけること
①「参照されている」は「当たった」ではない
冒頭で触れた、読み方を間違えやすいところがここです。
公式ドキュメントの表現は、ポリシーの表に出るのは「そのURLが参照されているポリシー」です。URL Lookupに入れるのはURLかドメインだけで、ユーザーやアクティビティといった条件は入力しません。
つまり、表に3つのポリシーが並んだとしても、それは「このURLに関係するポリシーが3つある」という意味です。ある通信が最終的にどのポリシーで処理されたかは、公式の説明からは読み取れません。実際の処理結果を確かめたいときは、Skope ITのログ側を見ます。
画面上部の説明文も、表示するのは「URL/ドメインに適用されうるポリシー」という書き方です（原文：the policies that would be applicable for the URL/domain）。また、複数のアプリで使われる共通ドメインを引くと、実際の通信では最終的な分類が変わる可能性がある、という注意書きが出ることもあります。
② Dynamic URL Classificationが有効だと、結果が揺れることがある
Dynamic URL Classificationは、未分類のURLをNetskopeが動的に既定のカテゴリへ分類する機能です。既定では無効で、Settings > Security Cloud Platform > Configuration から有効にできます。
URL Lookupは動的分類と未分類のURLもチェックしますが、公式ドキュメントには注意書きがあります。Dynamic URL Classificationが有効な場合、分類結果が一時的にキャッシュされること、プロキシモードに限られることから、結果に一貫性がなくなる可能性がある、というものです。
未分類だったURLを引いて、前回と違うカテゴリが出てきたら、まずこの設定が有効かどうかを確認してみてください。
③ カテゴリが実態と違っていたら
引いてみた結果、カテゴリが実態と合っていないこともあります。公式ドキュメントが案内している対処は2つで、カスタムカテゴリで独自に定義するか、Report Miscategorization からNetskopeへ報告するかです。
〜 参照元 〜
- URL Lookup —「URL Lookup」（Netskope公式ドキュメント）
- Security Cloud Platform Configuration —「Dynamic URL Classification」（Netskope公式ドキュメント）
変更が多い時期の使いどころ
設定を変える前と後で、同じURLを引く
カスタムカテゴリやURLリストを編集するときに、代表的なURLを変更の前後で1件ずつ引いておくと、カテゴリやポリシーの変更が意図どおりに変わったかを見比べられます。
変更前の結果をスクリーンショットで残しておくだけでも、あとから「前はどうなってたっけ」に答えやすくなります。
「ポリシーが適用されない」ときの切り分けに使う
ポリシーを設定したのに適用されない、というときにもURL Lookupが使えます。ポリシーの設定を見直す前に引いてみると、そもそもそのFQDNがバイパスされていて、Netskopeを経由していなかった・・・ということに気付けます。
しかも、どのSteering Configurationでバイパスされているかまで表示されるので、直しに行く先もすぐ分かりますよ。
「Destination Profileが消せない」ときの目星つけに使う
弊社で実際に使った例として検証用途のSteering Configurationの後片付けをやろうやろうと先延ばしにした結果、ステアリング構成の分離の移行に巻き込まれて不要なポリシー＆Destination Profile＆カスタムカテゴリが作られる結果になりました。片付けなかった自分が悪いです、それはそう。
検証用のDestination Profileを消そうとすると、参照しているポリシーがあるので消せないと怒られます。（もうそのSteering Configurationはないのに、勝手には消えてくれません。）
そんな時は、Destination Profileに入っているドメインを1つURL Lookupで引いてみます。どのカスタムカテゴリやポリシーに紐づいているかが一覧で出ますし、Netskopeへステアリングされているか、どのSteering Configurationでバイパスされているかも表示されるので、Steering Configurationを1つずつ開く前にまず当たりをつけられます。
あっちこっち見に行く前に、1か所でどこから、どれくらい参照されていそうかの目星をつけられるので便利です。
また、夏頃には表示されなかったDestination Profileで作成したSSL Decryptionポリシーも、対象URLのURL Lookup結果にポリシーとして表示されるようになっています。
〜 参照元 〜
- URL Lookup —「URL Lookup」（Netskope公式ドキュメント）
- Add Bypasses in Netskope —「Steering Bypass」（Netskope公式ドキュメント）
Appendix：まとめて引きたいならREST API
画面からは1件ずつしか引けません。棚卸しのように件数が多い場面では、URL Lookup APIが使えます。
- 入力：URL、ドメイン、またはIP
- 戻り値：カテゴリ（Predefined／Custom）、URLリスト、Predefinedカテゴリが動的分類で割り当てられたかどうか
- 既定ではURLとドメインのDNS解決も考慮される（無効にもできる）
テナントごとの上限は次のとおりです。
| 項目 | 上限 |
|---|---|
| 1回のAPIコールあたり | 最大100 URL |
| 1日あたり | 最大1,000 URL |
| 1日あたり（オプション） | 5,000 URLまで拡張可能。営業担当へ連絡が必要 |
画面と違うのは戻り値です。公式ドキュメントが挙げているのはカテゴリとURLリストで、ポリシーは含まれていません。「どのポリシーから参照されているか」まで見たいなら画面、「どのカテゴリ・どのURLリストに入っているか」を大量に引きたいならAPI、という使い分けになります。
仕様の詳細は、Settings > Tools > REST API v2 の API Documentation（Swagger）で確認できます。
〜 参照元 〜
- URL Lookup —「Netskope URL Lookup API」（Netskope公式ドキュメント）
- Checking URL for category and URL List using Rest API（Netskope Community）
おわりに
「このFQDN、どのポリシーから見られてるんだっけ？」の答えは、URL Lookupに1件入れれば、カテゴリとポリシーの一覧で返ってきます。カスタムカテゴリを1つずつ開いて回るのと比べると、確認の手間はだいぶ減ります。
ただし、表に出るのはあくまで「参照している」ポリシーです。その通信が実際にどのポリシーで処理されたかは、Skope ITのログとセットで確かめてください。
それにしても、検証用のSteering Configurationをちゃんと片付けていれば、この記事は生まれていなかったかもしれません・・・。
大きな変更が入る前のお片付け、大事です。自戒を込めて。
参考リンク（一次情報）
- URL Lookup（Netskope公式ドキュメント）
- Security Cloud Platform Configuration（Netskope公式ドキュメント／Dynamic URL Classification）
- Add Bypasses in Netskope（Netskope公式ドキュメント／Steering Bypass）
- Checking URL for category and URL List using Rest API（Netskope Community／Netskope社員による投稿、2024年11月13日）
関連記事
- NetskopeのURLリストを宛先プロファイルへ移行する。「複製」と「カテゴリ移行」の手順と注意点：URLリスト移行の手順と落とし穴はこちら。
- Netskope NG SWG Enterpriseを「使い切る」｜Destination Profileへの移行と2026年の正攻法：移行の全体像とURLリストの棚卸しはこちら。
※本記事の仕様説明は2026年11月10日時点のNetskope公式ドキュメントに基づいています。Destination Profileまわりの事例、バイパス表示、画面の説明文は弊社テナントでの確認結果です。画面表示や仕様は今後のリリースで変わる可能性があるため、作業前に最新の公式情報をご確認ください。
