はじめに
どうもkakeruです。ブログ全然書けてなくてすみません。時間見つけてちゃんと書きます。 本題ですが、本日は、NetskopeのReal time Procteionポリシーどう書けばいいのかわからないという声が多いため、このブログを書いています。本ブログでは細かい話は触れずに、Real-time Protection全体のポリシーの組み方について解説していきたいと思います。
本ブログは、下記Netskope公式ドキュメントをもとに作成しています。 Best Practices for Real-time Protection Policies
Real time Protection ポリシーとは
Real time Protection ポリシーは、Netskopeの主要機能の一つで、Netskope Clientの入ったデバイスを持つユーザーのトラフィックをリアルタイムで監視・制御するためのポリシーセットです。設定は、管理コンソール > Policies > Real-time Protectionにて行います。
主な機能として以下があります：
- ウェブフィルタリング – カテゴリやリスクレベルに基づいてウェブサイトへのアクセスを制御
- データ保護 – 機密データの流出を防止
- マルウェア対策 – リアルタイムでのマルウェアスキャンと検知
- クラウドアプリの制御 – 承認/未承認アプリケーションの利用制御
ポリシーは組織のセキュリティ要件に応じて柔軟にカスタマイズすることが可能です。
利用にあたっての考慮事項
ポリシーは上のポリシーより適用されます。つまり、より上位のポリシーが優先して適用され、下位のポリシーは上位のポリシーで許可、制御されていない範囲内でのみ制御を行うことができます。そのため、ポリシーの順序は慎重に検討する必要があります。
例(設定順序通り上位から適用)：
- カスタムカテゴリーによるブロック ← Google Driveが含まれるカテゴリーを指定
- 自社テナントGoogle Drive アクセス許可ポリシー ← 適用されない
- Cloud Storage カテゴリ ブロックポリシー ← 自社テナントのGoogle Driveアクセスには適用されない
ポリシー設定の構築順
参照：Best Practices for Real-time Protection Policies
公式ドキュメント上、Real-time Protectionポリシーの設定順は下記が良いと記載されています。
- Threat Protection (High risk) マルウェア検出ポリシー – 既知の脅威パターンやシグネチャに基づくマルウェア検出
- 高度な脅威検出ポリシー – ゼロデイ攻撃や未知の脅威に対する保護
- フィッシング対策ポリシー – フィッシングサイトへのアクセスブロック
Utility Policies
- ユーティリティポリシーのベストプラクティスに関しては別途公式ドキュメントに記載がありますので、そちらも参考にしてください。Best Practices for Utility Policies
重要でない、使用頻度の低い Web サイトに関するアラートをユーザーに送信するポリシー DNS over HTTPSをブロックするポリシー
- DNS over HTTPS は、Netskopeのステアリングとの互換性がないため、ポート 443 (HTTPS) 経由で動作する DNS をブロックします。
- Netskope では、このポリシーを最初のポリシーの後に配置することをお勧めしています。
Remote Browser Isolation (RBI)
- 危険なサイトやコンテンツへのアクセス時にRBIを適用するポリシー – ユーザーを既知の脅威から保護
- 特定カテゴリのWebサイト（ソーシャルメディアなど）にRBIを適用するポリシー
CASB (Activity Oriented)
- 承認済みのSaaS/クラウドアプリケーションへのアクセスポリシー 正規利用を許可
未承認アプリケーションへのアクセス制限・監視ポリシー データ漏洩防止（DLP）ポリシー – 機密情報の流出を防止する設定 Web (Category Based)
- ウェブフィルタリングポリシー – カテゴリ別のウェブサイトアクセス制御（例：ギャンブル、アダルトコンテンツの制限）
- 特定のウェブサイトや URL パターンに対するカスタムルール – 業務に必要なサイトの許可/不要なサイトのブロック
- 帯域幅制御ポリシー – 動画ストリーミングなど帯域を多く消費するコンテンツの制限
Netskope Private Access (要追加ライセンス)
- プライベートアプリケーションへのセキュアなアクセスを提供するポリシー
- ユーザーごとのアクセス権限設定 ユーザー・グループベースのアクセス制御によるきめ細かな許可設定
アプリケーションセグメンテーション Netskope Private AccessでTCP80/443を利用する場合
NPAポリシーを最下層に書くように記載されていますが、TCP80/443をNPAで制御する場合上位ポリシーに同じ宛先のドメインやカテゴリがあると正常に動作しない可能性がございます。必要に応じてユーティリティポリシーとして上位に置くことを検討ください。
ポリシーのアクションどうしたらいい？
ポリシー設定でのあるあるは、「とりあえずAlertにしておこう」です。導入初期段階であればこちらはおおよそ正しいと考えます。しかしながら、Alertにするということは、そのAlertを誰がどこを確認して、どういう対応をするのか整理する必要があります。
対応の例：
- ポリシーに設定したメールやSlackにAlert通知 or 定期的に管理コンソールのSkope IT > Alertsを確認
- どのポリシーに合致しているか、誰が合致しているか確認する
- 誤検知・過検知なのか、対応が必要なAlertなのか判断する 必要に応じてユーザーにヒアリング・指導を行うなど
誤検知・過検知であれば、ポリシーの調整をする
運用がこなれてきたタイミングで、ユーザーにポップアップを出す、User Alertの利用やBlockへの移行をご検討ください。
ポリシー設定前でよく利用する設定
管理コンソール > Policies > PROFILESに、Real-time Protectionの設定前に用意することのある設定が多くあります。
- DLP DLP Rulesで正規表現や特定の文字列を指定する
- DLP Profileで作成したRuleを設定してReal-time Protectionポリシーで利用可能な状態にする
Custom CategoriesとURL Lists
- 特定の許可/ブロック/アラートを行いたいURLのListsを作成
- Custom Categoriesでカスタムのカテゴリを作る 事前定義のカテゴリの利用、作成したURL Listの利用、除外が可能
Tips
Real-time Protectionポリシーにて、すべてのカテゴリを指定する場合、カスタムカテゴリーでALL Categoryのカテゴリを用意しておくとカテゴリ追加の際の運用の手間が減ります。
- App Instanceここから設定することはあまりないですが、テナントを識別するための定義が可能です
- 実際にサービスにアクセスしてログを記録した上で、 Skope IT > Application Eventsから[+New App Instance]で作成するとインスタンスIDの間違いがなくなります
- File Profile特定の拡張子のファイルをブロック・許可したい場合に利用する
Constraint
- 自社のドメインの利用かどうかを判定するために利用する Matches：*@domain.com
GmailやOutlookを使ってないか判定する
- Matches：*@gmail.com
- Matches：*@outlook.*
これらの設定を適切に組み合わせることで、組織のセキュリティ要件に合わせたきめ細かなポリシー設計が可能になります。
あとがき
以上、Real-time Protectionポリシーの設計に関する基本的な考え方を説明しました。ポリシーの優先順位や適用範囲を理解し、段階的に導入することで効果的なセキュリティ対策が実現できます。次は、各ポリシーの細かい設定方法などの解説ブログを出す予定です。皆様のNetskope導入・運用の一助となれば幸いです。
