SaaS

Netskopeを利用するとクラウドサービスの認証がうまくいかない場合のトラブルシュート(よくあるお問合せ-Netskope編)

はじめに

こんにちは!セキュリティチームのTaguchiです。最近書いている「よくあるお問合せシリーズ」のNetskope編の記事を書きたいと思います。今日紹介するのは、個人的に Netskope 関連で一番質問をもらうと感じるトピックになっております。

ご注意

本ブログの内容は、2022年1月11日時点までの情報を元に作成しておりますが、クラウドサービスの仕様変更等に伴い、将来的に状況が変化することがございます。当社側で仕様変更が確認できた場合は可能な限り修正をしますが、最新の情報を常に維持することは難しい点についてはご了承ください。

お問合せ内容

お客様

Netskepeを利用しているとクラウドサービスの認証を行うことができないけど、どうしたらいいの?

主な原因

前提として、Netskope利用中はクライアントから発生した通信をNetskopeのデータセンターで一度通信を終端し、HTTPSの通信はここで一度復号されます。そしてNetskopeのデータセンターにおいて、Netskopeで用意する証明書を利用して再暗号化し、アプリケーションに対して新しく通信を発生させます。

この過程において、認証で利用する元の証明書が新しい通信に含まれなくなってしまうことなどが、認証が成功しない主な要因です。(ただし、クラウドサービスの特性ごとに、細かい状況は異なります。)

対処方針

  1. Netskopeが原因か否かを特定する
  2. Netskopeのログから、事象の原因となるFQDNを特定する
  3. そのFQDNに対して以下のいずれかの対処を行う
    1. SSL Decryption Policyを設定し、SSLを復号しないようにする
    2. 通信をNetskopeから例外設定(Exception)する

設定時の考慮事項

当たり前の話ですが、SSL Decryption Policy を設定するか、Netskope から例外設定(Exception) するということは、Netskopeの機能を使ったクラウドサービスの監視・制御が一部できなくなるということです。(ただし、API Introspectionを使った監視など別軸での監視・制御は引き続き可能です)

ワイルドカード等を利用して広範囲を指定することも機能的には可能ではありますが、この設定にはNetskopeの認証に最低限必要なFQDNの情報を仕入れて設定するようにしてください。

手順

事象を再現し、再現した時刻を記録

Netskopeをオンにした状態で、クラウドサービスの認証を行うことができない事象を再現します。その後、再現した時間を正確に記録します。

ログを見やすくするために、確認したい事象以外のアプリケーションやWebサイトは終了しておくと確認がスムーズになります。

Netskope Clientからログを取得

Netskopeのアイコンをクリックし、 [Save Logs] からログの保存先を指定し、ログ取得を実行してください。Zipファイルで指定した保存先に保存されます。

疑わしいFQDNの特定する

Zipファイルの中に[nsdebuglog.log]というログファイルがあります。このログは端的にいうと「Netskope Client(端末)からどこに向かって通信を行ったか」を記録しているログです。このログには、「直接インターネットに通じている通信」と「Netskopeに向かっている通信」の2つのパターンが確認できます。

直接インターネットに通じている通信

下記のログサンプルのように bypassAppMgr.cpp:996 と記載されいているログが、直接インターネットに向かっている通信です。このログは、認証がうまくいかないという今回のケースで疑わしいものではありません。

2021/12/07 12:21:40.207711 stAgentSvc p8c t3e0f 4 bypassAppMgr.cpp:996 BypassAppMgr bypassing flow to exception host: x.google.com, process: google chrome helper, Dest IP: X.X.X.X, Dest Port: 443
Netskopeに向かっている通信

下記のログサンプルのように tunnel.cpp:695 と記載されているログが、Netskopeに向かっている通信です。疑わしいFQDNを特定するにはこのログの host: の次にある値を確認します。

2021/12/07 12:21:41.870744 stAgentSvc p8c t3e0f 4 tunnel.cpp:695 nsTunnel TLS [sessId 501] Tunneling flow from addr: X.X.X.X:X, process: google chrome helper to host: cloudnative-blog.no.sample.com, addr: X.X.X.X to nsProxy

上記のログサンプルでは cloudnative-blog.no.sample.com が今回、認証失敗問題の原因となっていることが疑わしいFQDNです。

💡 上記で紹介した手順の他に、利用するクラウドサービスの開発元から当該サービスの認証で利用しているFQDNの情報を聞くパターンでも対応が可能です。

原因となるFQDNに対しての対処

対処のパターン

原因となるFQDNを特定したら、それに対しての対処を行いますが、方法としては「SSL Decryption Policy の設定」と「例外設定(Exception)」の2種類があります。

SSL Decryption Policy の設定」では、登録したFQDNに対してNetskopeのデータセンターを経由するが、通信の終端やHTTP通信の復号処理を行わずアプリケーションにアクセスするようにできます。弊害として、通常時よりもNetskope管理コンソールに出力される情報量少なくなりますが、Netskopeのデータセンターを経由する分、次に紹介する「例外設定(Exception)」よりは取得できる情報が多くなります。

一方、「例外設定(Exception)」を実施した場合、Netskopeのデータセンターを経由せずに、端末から直接登録したFQDNに対して通信します。この場合は、Netskope管理コンソールでは情報を取得することができません。

可能な限り、「SSL Decryption Policy の設定」で対処することが望ましいですが、「SSL Decryption Policy の設定」でも認証が成功しない場合のみ、例外設定(Exception)も試していただけると良いと思います。

パターン①:該当FQDNのSSL Decryption Policy の設定

1. Netskopeの管理コンソールで[Policies] > [SSL Decryption] と遷移し、[ADD Policy] をクリックします。

2. 以下のように設定しSaveします。

  • Match Criteria:*特定したFQDNを入力
  • Action:Do Not Decryptを選択
  • Set Policy:任意のポリシー名
  • Status:Enabled

3. APPLY CHANGESをクリックする

パターン②:該当FQDNの例外設定(Exception)

  1. Netskopeの管理画面へログインし、 [Settings] > [Security Cloud Platform]> [Steering Configuration] > [Default tenant config] > [EXCEPTIONS]の順に遷移します。
  2. [NEW EXCEPTIONS]をクリックして、該当のFQDNを記載して[Add]をクリックします。

この設定においては、*.hogehoge.com など、ワイルドカードで指定することができます。ただし先に述べた通り、広範囲をバイパスしてしまうと、Netskopeを入れた意味が薄くなってしまうので、必要最低限のFQDNを特定して入力するようにしてください。

動作確認

Netskopeのアイコンをクリック > [Configuration] > をクリックし、Config Updated に記載されている時間がEXCEPTIONの設定を行った後の時間になっているか確認します。もしUpdateと表示されていればクリックしてUpdateしてください。

ここまで終わったら、Exception設定したクラウドサービスにログインして、認証ができるかを確認します。もし今回の設定でも認証が失敗する場合は、別のFQDNが影響している可能性があるので、泥臭い作業になりますが再度調査をして手順を実施してください。

終わりに

僕がクラウドネイティブに入社して5ヶ月になりますが、この問い合わせは頻繁にもらうので、この記事が皆様のお役にたれてば幸いです。これからもよくあるお問合せはガンガン記事にしていきたいと思いますのでよろしくお願いします。

改訂履歴

  • 2022年1月12日:公開

参考資料

TAGUCHI

新卒で入社したコンサルティングファームにてISO27017やISMAP等のセキュリティ規格案件を経験した後、クラティブに転職。趣味はLock Danceです。