SaaS

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

セキュリティチームの ぐっちー です。最近書いている「よくあるお問合せシリーズ」のNetskope編の記事を書きたいと思います。今日紹介するのは、個人的に Netskope 関連で一番質問をもらうと感じるトピックです。タイトルは認証がうまくいかないケースと記載していますが、機能が利用できないケースなどでも有効なケースがあります。

ご注意

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

お問合せ内容

お客様

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

主な原因

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

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

対処方針

  1. Netskopeが原因か否かを特定し、事象を再現する
  2. Netskopeのログを取得する
  3. ログから事象の原因となるFQDNを特定する
  4. そのFQDNに対して以下のいずれかの対処を行う
    1. SSL Decryption Policyを設定し、SSLを復号しないようにする
    2. CERTIFICATE PINNED APPSを使った例外設定（Exception）をする
    3. 通信をNetskopeから例外設定（Exception）する
設定時の考慮事項

当たり前の話ですが、SSL Decryption Policy を設定したり、Netskope から例外設定（Exception） するということは、Netskopeの機能を使ったクラウドサービスの監視・制御が一部できなくなるということです。ワイルドカード等を利用して広範囲を指定することも機能的には可能ではありますが、この設定には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を特定したら、それに対しての対処を行いますが、方法としては以下の3種類があります。

手法特徴
SSL Decryption Policy の設定登録したFQDNに対してNetskopeのデータセンターを経由するが、HTTP通信の復号処理を行わずアプリケーションにアクセスするようにできます。弊害として、通常時よりもNetskope管理コンソールに出力される情報量少なくなりますが、Netskopeのデータセンターを経由する分、他のパータンよりは取得できる情報が多くなります。
CERTIFICATE PINNED APPSを使った例外設定（Exception）この設定では「特定のアプリからのプロセス」と「特定のドメイン」の組み合わせでNetskopeのデータセンターを経由しないように除外します。
この例外設定の場合は、「Okta Verifyからの通信は例外設定するけど、Chromeからの通信はNetskopeを経由させる」といった事ができるため、例外設定を最小限にできる可能性があります。
該当FQDNの例外設定（Exception）登録したFQDNに対して、Netskopeのデータセンターを経由せずに、端末から直接登録したFQDNに対して通信します。この場合は、Netskope管理コンソールでは情報を取得することができないため、この設定は最終手段であると思っていただけたら幸いです。

可能な限り、「SSL Decryption Policy の設定」で対処することが望ましいですが、「SSL Decryption Policy の設定」でも認証が成功しない場合のみ、CERTIFICATE PINNED APPSやFQDNを使った例外設定（Exception）も試していただけると良いと思います。

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

最初に紹介するのは、HTTP通信の復号処理を行わずアプリケーションにアクセスするSSL Decryption Policyの設定方法です。

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

次に、以下のように設定しSaveします。

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

最後に、APPLY CHANGESをクリックして設定完了です。

パターン②：CERTIFICATE PINNED APPSを使った例外設定（Exception）

続いて紹介するのはCERTIFICATE PINNED APPSを使った例外設定（Exception）です。この設定では「特定のアプリからのプロセス」と「特定のドメイン」の組み合わせでの除外するため、例外の範囲を最小限にすることができる可能性があります。

CERTIFICATE PINNED APPSを使うケースの最も代表的なものとして「Netskopeを有効化しているとOkta Verifyを使った認証がうまくいかない」というものがあるので、ここではOkta Verifyからのプロセスを例外設定する設定例をご紹介します。

NetskopeとOktaは食い合わせが悪く、「サインインURLが安全ではありません」というエラーメッセージが出て、認証が失敗することがあります。

まず、Netskopeの管理画面へログインし、 [Settings] > [Security Cloud Platform]> [App Definition] > [CERTIFICATE PINNED APPS] に遷移し、[NEW CERTIFICATE PINNED APPS]で[CERTIFICATE PINNED APPS]を作成します。

  • [APPLICATION NAME] は任意のわかりやすい名前を入れてください。
  • [PLATFORM] はWindowsを選択し、[DEFINITION] はExactにしてoktaverify.exeと入力してください。
    • その後、[ADD PLATFORM]をクリックします。
  • [PLATFORM] はMacを選択し、[DEFINITION] はExactにしてokta verifyと入力してください。
注意

今回はOkta Verifyでの設定例を掲載していますが、他のアプリを対象にする場合は[DEFINITION]には当該アプリのプロセス名を記載してください。プロセス名は「手順③：疑わしいFQDNの特定する」で紹介している[nsdebuglog.log]というログファイルの中にprocess: google chromeという型式で記録されています。macOSとWindowsで表記が異なるのでその点もご注意ください。

次に、[Settings] > [Security Cloud Platform]> [Steering Configuration] > [Default tenant config] > [EXCEPTIONS]の順に遷移し、[NEW EXCEPTIONS] > [CERTIFICATE PINNED APPS] をクリックして、新しい除外設定を入れます。

  • [Certificate Pinned Apps]には先ほど作成したものを選択します。
  • [Custom App Domains] には、自社OktaのFQDN（xxx.okta.com）を入れます。

最後に[SAVE]して設定は完了です。

パターン③：該当FQDNの例外設定（Exception）

最後に紹介するのは該当FQDNの例外設定（Exception）です。繰り返しになりますが、この手段は最終手段です。

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

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

動作確認

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

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

終わりに

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

参考資料

ぐっち

コンサル会社にてISO27017やISMAP等のセキュリティ規格案件を経験した後、クラティブに入社。セキュリティチーム所属ですが、最近は生成AI等を使ったシステムの開発や導入をやっています。趣味はダンス。Microsoft MVP for AI Platform & M365(Copilot)

記事一覧