はじめに こんにちは、セキュリティを気にする年頃の ネクストモード株式会社 のtommyです...
Netskopeのバイパスを理解する
面白説明おじさんになりたい はん です。
Netskopeは強力な可視化と制御のあるサービスですが、その制御を回避する「バイパス」を理解するのは導入・運用において非常に重要です。
今回はそのバイパスの仕組みについて説明をおこないます。
バイパスは4種類ある
Netskopeには「バイパス」が4通りあります。
それぞれバイパスするモノが異なっており、図示すると以下のようになります。
図の1~4が該当するのですが、それぞれバイパスするものが異なります。その仕組と用途によって使い分ける必要があるため、以下に解説を行います。
解説
バイパスなし(通常動作)
- どのような仕組みか
- Netskopeクライアントは通信はクライアント経由でNetskope Cloudに送ります
- Netskope Cloud ではSSL暗号化を解除し、Realtime Protection のポリシーに従い評価・制御がされます
- SSL復号化とアプリケーション可視化による詳細なログが残ります
1. ポリシーでのバイパス
-
どのような仕組みか
- 指定された通信をポリシー制御せずにバイパスします
- 通信は許可されますが通信ログは記録されません
- SSL復号化はされているためアプリケーションのテナントやアクティビティ毎にバイパスするかどうかを制御できます
-
設定方法
-
Real-time Protection のポリシー設定の Profile & Action にて Bypass を選択する
-
-
ユースケース
- ログを記録したくないシステムやアクティビティがある場合
- 例) 金融系システムの操作
- 特定のアクティビティ以外は記録したくない場合
- 例) 特定システムではログと制御はログイン・ログアウトのみ必要
- ログを記録したくないシステムやアクティビティがある場合
-
備考
- ポリシーにて許可(Allow)と似たような挙動となりますが、ログの記載や他のポリシーの評価が無いことが特徴です
- ポリシーのリスト内で上位に配置するのが良いでしょう
2. SSLインスペクションをバイパス
-
どのような仕組みか
- 通常行うSSLインスペクションをバイパスします
- ポリシー制御は行われますがSSL復号化が行われないため、CASB機能は利用できずSWG一部の機能のみが適用されます(ドメイン等の宛先制御)
- ログは記録されますが、SSL復号化がないため簡易なものとなります(テナント、アクティビティ等)
-
設定方法
-
SSL Decryption にて条件指定(ソース、宛先等)して Do Not Decrypt として登録
-
-
ユースケース
- SSL VPNとの併用したい場合 ※ スプリットトンネルに限る
- アプリケーション固有の証明書を利用しているためNetskopeの検査を通すと支障がある場合
3. Real-time Protection をバイパス
-
どのような仕組みか
- Netskopeでの検査を全てバイパスします
- 通信経路としてはNetskope Cloud を通ります
- Netskope Cloudを通るため、最低限のログが残ります
- 接続元IPアドレスはNetskope クラウドとなります
-
設定方法
-
設定方法は2通りあります
- 全てのExceptionをNetskopeクラウドを通過させる場合
- (注意)この設定を行うと全ての Exception が Netskope クラウド経由となります、一部のアプリのみを適用させたい場合はもう一つの方法を選択してください
-
Exception に対象アプリやドメイン等を登録する
-
Steering Configuration の Traffic Steeringにて “Bypass exception traffic at Netskope Cloud” とする (※ デフォルトから変更)
- 特定アプリのみNetskopeクラウドを通過させる場合
- ExceptionにCertificate Pinned App を登録する際に Advanced Options をONにして Tunnel Mode をONにします
- なお下段のDOMAINS欄はマッチしたもののみをトンネル対象とする際に用います
- 全てのExceptionをNetskopeクラウドを通過させる場合
-
-
-
-
- この挙動を有効にするにはステアリングのバイパス設定が “Bypass exception traffic at Client” である必要があります(次項参照)。
-
-
-
ユースケース
- アプリケーション固有の証明書を利用しているためNetskopeの検査を通すと支障があるが、SSLインスペクションのバイパスでも解決しない場合
4. Netskope Cloud をバイパス
-
どのような仕組みか
- 通信は端末から直接インターネットへ抜けNetskope Cloud を通りません
- Netskope Cloudを通らないためログは端末のみに残ります
- 接続元IPは端末環境のグローバルアドレスとなります
-
設定方法
-
Exception に対象アプリを登録する
-
Steering Configuration の Traffic Steeringにて “Bypass exception traffic at Client”(デフォルト値) とする
-
-
ユースケース
- Netskope Cloud にログを残さなくてもよい通信 (IdP、MDM、EDR など)
- アプリケーション固有の証明書を利用しているためNetskopeの検査を通すと支障があるが、SSLインスペクションのバイパスでも解決しない場合
- 端末環境のIPアドレスが必須な通信
-
備考
- Netskope Cloud をバイパスとの違いは通信経路のみとなり、通信例外(Exception)としてはこちらがデフォルト設定となります
- Steering Configuration での一括設定をなるため、ログをクラウドに残すかどうかでどちらかを選択してください
まとめ
ここまでの説明をまとめると下表のようになります。状況・用途に応じてどのバイパスを行うかの指標としていただけるとありがたいです。
通信経路 | SSL復号化 | ポリシー制御 | ログ | |
---|---|---|---|---|
バイパスなし | クラウド | する | する | 詳細に記録 |
Realtime Protection 内のポリシーをバイパス | クラウド | する | マッチしたらバイパス | 記録しない |
SSLインスペクションをバイパス | クラウド | しない | 復号化無しで見える範囲 | 簡易記録 |
Realtime Protectionの検査をバイパス | クラウド | ー | しない | 最小限 |
Netskope Cloud をバイパス | 直接通信 | ー | しない | クライアントのみ |
本稿は以上となります。
では、よりよい Netskope ライフを。