ネクストモードブログ

【Netskope】【運用】Pythonのインターネットアクセス制御について整理してみた件（SWG）｜Nextmode Blog

作成者: sobar｜25/05/14 3:42

はじめに

こんにちは、 ネクストモード株式会社 の sobar です。Netskope運用におけるPython 制御の実践ガイドをご紹介します。

Netskope は、柔軟性とアジリティを兼ね備えた DevOps型のセキュリティ製品です。使いながら必要な機能追加・変化への対応を速やかに行える点は、現代のセキュリティ対策において特に重要視される特徴であり、Netskopeの強みのひとつです。詳細はこちらをご覧ください。

Python は開発、データ収集・分析、自動化処理等いろいろな場面で利用されていますが、Netskope クライアント（以降NSClient）を端末にインストールすると Python のスクリプトでインターネットアクセスができない…といった状態になります。今回の記事はそういった場合にどう検討・対処・制御すべきか？をなかなか整理できないといった方向けに対応方法をまとめたものとなります。

主に該当するNetskope の公式ドキュメントはこちらとなります。（※リンク先のコミュニティーの内容が新しいようです。）

 

今回の構成 ＆ PythonのインターネットアクセスをNetskope で制御する際の前提となる点

NSClient を端末にインストールすると、Netskope の網経由でインターネットアクセス制御が行われます。網内でSSLインスペクションを実施する際には、NetskopeのルートCA証明書が必要です。

Python インストール直後、Pythonからのインターネット通信は、インストール時にツールと共に配布される証明書バンドルを使用して行われますが、そのバンドルにはNetskopeのルートCA証明書が含まれていません。そのためSSL証明書エラーとなり通信が失敗します。

Python スクリプト実行時（インターネットアクセス時）の SSL Error（certificate verify failed）

 

端末で利用するPythonのインターネットアクセス制御例４つ

以下、端末で利用するPythonのインターネットアクセス制御例を４つご紹介します。

１．Python通信においてNetskopeのルートCAを含んだ複合証明書作成・設定

２．特定のインターネット通信をSSL Do Not Decrypt で許可（Python＆それ以外の通信にも許可ポリシーが適用される）

３．Python（プロセス）からすべての宛先のインターネット通信をBYPASS

４．Python のインターネット通信をブロック

Pythonでインターネットアクセスを実施する場合は「1-3.」 のいずれかを対応する必要があります。まずは一度(1.) Python でNetskopeのルートCAを含んだ複合証明書作成・設定するといった運用・対応が可能かをご検討ください。

対応が難しい場合は(2.) SSL Do Not Decrypt 対応、(3.) プロセスのBYPASS にて対応を行うこととなりますが、(2.)か(3.)のどちらかを選択する場合は (2.)SSL Do Not Decrypt での対応可否をまずはご検討ください。一部SWG制御可能であること、(2.) SSL Do Not Decrypt で通信が行われた際に最低限のログはSkope ITに残せるためです。

(2.)でも通信に失敗する場合や、Python（プロセス）でのインターネット宛て通信は基本的に全許可するという方針であれば(3.) プロセスそのもののBYPASS で対応することをご検討ください。（プロセスと特定の宛先（ドメイン）のみBYPASS する設定も可能）

※利用するプロセス・通信内容によっては他のプロセスと連携・サイトアクセスが実行される場合もあり、通信内容によってはプロセスの特定に時間がかかるケースがございます。

※バイパス・SSL Do Not Decrypt について詳しく知りたい方は以下弊社のブログも併せてご参照ください。

Python のインターネット通信をブロックしたいといったニーズもあるためこちらもご紹介(4.) いたします。

以下、まずはプロセスの特定を実施します。

 

プロセスの特定

Python でインターネット通信を行った日時を控え、nsdebuglog.log より、「python」 、「宛先（今回はnews.google.com）」等の検索でプロセスを特定します。（今回は python3.12.exe と特定）

以下で４つの対応方法（Windows PCでの対応方法）を順番にご紹介します。

 

１．Python通信においてNetskopeのルートCAを含んだ複合証明書作成・設定

NetskopeのルートCAを含んだ複合証明書作成・設定は、該当通信のSWG制御が可能となるため一見一番よさそうに見えるのですが以下のデメリットがあり、特に開発用途でPython を利用するシーンにおいては採用が難しい場合がございます。

  • メリット

    • Netskope でSteeringされるため SWG制御が可能
  • デメリット
    •  次項(2.)SSL Do Not Decrypt 設定・(3.)プロセスBYPASSと比較した場合
      • 端末に対してそれぞれ個別に複合証明書を作成、環境変数の設定が必要
      • 開発環境での利用シーンにおいては以下のような点も考慮・検討する必要がある
        • NSClient はユーザ・デバイスに紐づき利用するものであるが、開発物（スクリプトや設定ファイル等）に加えてNetskope の設定関連のデータや、複合証明書をリポジトリにプッシュ、サーバ等へデプロイすべきか
        • 上記に対する検討＆Netskope利用メンバーへのご案内を含めた工数がとれるか

以下、Windows PCでのNetskopeのルートCA含んだ複合証明書作成・設定方法となります。（こちら参考）

1-1. Powershell にて以下実行し複合証明書を「nscacert_combined.pem」という名前で作成

((((gci Cert:\CurrentUser\Root) + (gci Cert:\LocalMachine\Root) + (gci Cert:\CurrentUser\CA) + (gci Cert:\LocalMachine\Root)) | Where-Object { $_.RawData -ne $null } | Sort-Object -Property Thumbprint -Unique | % { "-----BEGIN CERTIFICATE-----", [System.Convert]::ToBase64String($_.RawData, "InsertLineBreaks"), "-----END CERTIFICATE-----", "" }) -replace "`r","") -join "`n" | Out-File -Encoding ascii "$env:ProgramData\Netskope\STAgent\data\nscacert_combined.pem" -NoNewline

1-2. 「C:\ProgramData\Netskope\STAgent\data\」配下に作成されていることを確認

（※C:\ProgramData\Netskope\STAgent\data\」配下へ「nscacert_combined.pem」を作成後、OS再起動を行うと「nscacert_combined.pem」は削除されてしまうようですので、永続的に利用する場合は別のパスに保存することをお勧めいたします。）

1-3. 環境変数「REQUESTS_CA_BUNDLE 」に対しての参照先を上記作成した複合証明書バンドル「nscacert_combined.pem」に設定

  • set REQUESTS_CA_BUNDLE=C:\ProgramData\Netskope\STAgent\data\nscacert_combined.pem
    （※set コマンドだとコマンドプロンプトを閉じると設定が消えるため、永続化が必要であればsetx コマンドでの実施をご検討ください）


1-4. Pythonからのインターネットアクセスが可能なこと、SSL証明書エラーがでないことを確認（以下はレスポンス結果（一部）を出力するだけのスクリプト実行結果）

1-5. 複合証明書バンドル設定時おけるPythonでのインターネット通信ログについて

Skope IT > Page Events にて通信ログが出力。※ただし、スクリプトからのインターネット通信はブラウザ通信と比べてアクセス回数が少なかったり、以下のPage Events の生成条件に満たない場合はログに出力されない場合もございます。

 

1-6. SWG制御の確認ですが、たとえば Category = News&Media をBlock するReal-time Protection Policy を作成しPython でそれに合致するインターネットアクセスを実施し、通信がブロックされるか確認してみます。

 

1-7. 該当通信はブロックされ、Skope IT > Alerts にて python でのアクセスがBlockされていることが確認ができます。

 

２．特定のインターネット通信をSSL Do Not Decrypt で許可（Python＆それ以外の通信にも許可ポリシーが適用される）

該当のインターネット通信はnetskope の網内でSSLインスペクションを実施せずnetskope の網内を通過する設定となります。通信が行われたことのログはSkope ITに残ります。通信（宛先）を特定し、(2.)SSL Do Not Decryption 設定にするか、(3.)通信のBYPASSにするかで悩まれている場合は、まずはこちらの(2.)SSL Do Not Decrypt 設定でSSL証明書エラーが解消されるか確認することをお勧めいたします。

  • メリット

    • (1.)複合証明書対応と比較した場合

      • Netskope テナントで設定可能。端末に個別設定不要
      • 開発環境での利用シーンにおいての考慮・検討事項不要
    • 次項(3. )プロセスBYPASS （HOST：「*」指定）と比較した場合
      • SWG一部の機能が適用可能(ドメイン等の宛先制御)
      • 個別に通信の制御を行うため通信を許可するWebサイトの範囲は小さくすることが可能
      • 通信が行われた簡易なログは残すことが可能
  • デメリット
    • (1.)複合証明書対応と比較した場合
      • Netskope でSSLインスペクションされないため、SWG一部の機能のみが適用可能(ドメイン等の宛先制御)
    • 次項(3. )プロセスBYPASS （HOST：「*」指定）と比較した場合
      • 複数の通信先がある場合はひとつひとつ通信を特定しテナント側で設定を行う必要があるため、その分の稼働がかかる
      • 宛先ごとにSSL Do Not Decrypt を設定することになり、設定後該当通信はPython以外のプロセスもSSLインスペクションされなくなる

 

以下、SSL Do Not Decryptでの設定方法となります。

(Policies > SSL Decryption)

2-1. SSL Decryption > ADD POLICY 

2-1. New SSL Decryption Policy

2-3. SSL Decryption > APPLY CHANGES を忘れず実施。

 

2-4. 設定＆該当通信実施後、Skope IT > Page Event で 「Bypass Reason：SSL Do Not Decrypt Bypass Policy Matched」といった通信ログが確認可能。

 

３．Python（プロセス）からすべての宛先のインターネット通信をBYPASS

Python のプロセスに対してのインターネットアクセスは、NSClient のSteering をBYAPASS しNetskope網内を経由せずローカルブレークアウトさせる構成となります。NSClient側 では SteeringせずBYPASS するため、Skope ITでの可視化は行われません。BYPASS されたログは端末のnsdebuglog.log にて確認が可能です。

  • メリット

    • (1.)複合証明書対応と比較した場合
      • Netskope テナントで設定可能。端末に個別設定不要
      • 開発環境での利用シーンにおいての考慮・検討事項不要
    • (2.)SSL Do Not Decrypt 設定と比較した場合
      • プロセスの特定さえできればプロセス単位でインターネット宛ての通信をBYPASSさせることができるため、複数の宛先宛てで通信を行うような場合においても通信許可対応が可能（※プロセスとドメインを指定してBYPASSさせることも可能）
      • 都度通信を特定する必要がないためそのための稼働がかからない
  • デメリット
    • (1.)複合証明書対応・(2.)SSL Do Not Decrypt 設定と比較した場合
      • Netskope でSteeringされないためSWG制御・可視化ができない
    • (2.)SSL Do Not Decrypt 設定と比較した場合
      • プロセス単位でBYPASS するため、宛先を指定しない場合（HOST：* 指定の場合）、通信許可Webサイトの範囲が広がる。（※プロセスとドメインを指定してBYPASSさせることも可能）

 

以下、プロセスBYPASSの設定方法（※Windows PCの場合の設定方法）となります。

3-1. CERTICATE PINNED APP 作成

(Settings > Security Cloud Platform > App Definition)

3-2. NEW EXCEPTION 作成

(Settings > Security Cloud Platform > Steering Configuration > 使用Config > EXCEPTIONS)

※設定後の動作確認前に 端末側でNSClient のConfiguration のUpdate を実施ください。

 

3-3. 設定＆該当通信実施後、端末のnsdebuglog.log を確認すると「BypassAppMgr Bypassing connection」といったBYPASS通信ログが確認可能。

 

 

４．Python のインターネット通信をブロック

上記最初にご説明した通り、NSClient をインストール直後は Python からのインターネット通信はSSL証明書エラーにより失敗しますが、端末側でNetskope のルートCA証明書を参照する設定（1.）を行った場合にはインターネット宛てに通信を行うことは可能になります。そのため、明示的にPython からのインターネット通信はすべてブロックしたいといった場合にはテナント側で設定を行います。プロセス単位で通信をブロックすることになり、NSClient側 では Steeringせずブロックするため、Skope ITでの可視化は行われません。ブロックされたログは端末の nsdebuglog.log にて確認が可能です。

  • メリット

    • Netskope テナントで設定が可能なため、端末に対して個別設定は不要
  • デメリット
    • Netskope でSteeringされないため可視化ができない

 

以下、Python のインターネット通信をブロックする設定方法となります。
 
4-1. CERTICATE PINNED APP 作成 → ※3.1 と同様

4-2. NEW EXCEPTION 作成

(Settings > Security Cloud Platform > Steering Configuration > 使用Config > EXCEPTIONS)

※3-2.同様にNEW ECEPTION > Certificate Pinned Applications 作成ボタンを押下

Block を選択

※設定後の動作確認前に 端末側でNSClient のConfiguration のUpdate を実施ください。

 

4-3. 設定＆該当通信実施後、端末の nsdebuglog.log を確認すると「BypassAppMgr Dropping connection」といったブロック実施ログが確認可能。

 

 

まとめ > メリット・デメリット

比較のためメリット・デメリットを改めて表にまとめました。Python制御方法の選択の参考にいただければと思います。

  メリット デメリット
１．Python通信においてNetskopeのルートCAを含んだ複合証明書作成・設定
・Netskope でSteeringされるため SWG制御が可能
【(2.)SSL Do Not Decrypt 設定・(3.)プロセスBYPASSと比較した場合】
・端末に対してそれぞれ個別に複合証明書を作成、環境変数の設定が必要
・開発環境での利用シーンにおいては以下のような点も考慮・検討する必要がある
※NSClient はユーザ・デバイスに紐づき利用するものであるが、開発物（スクリプトや設定ファイル等）に加えてNet関連のデータや、複合証明書をリポジトリにプッシュ、サーバ等へデプロイすべきか
※上記に対する検討＆Netskope利用メンバーへのご案内を含めた工数がとれるか
２．特定のインターネット通信をSSL Do Not Decrypt で許可（Python＆それ以外の通信にも許可ポリシーが適用される）
【(1.)複合証明書対応と比較した場合】
・Netskope テナントで設定可能。端末に個別設定不要
・開発環境での利用シーンにおいての考慮・検討事項不要
【(3. )プロセスBYPASS （HOST：「*」指定）と比較した場合】
・SWG一部の機能が適用可能(ドメイン等の宛先制御)
・個別に通信の制御を行うため通信を許可するWebサイトの範囲は小さくすることが可能
・通信が行われた簡易なログは残すことが可能
【(1.)複合証明書対応と比較した場合】
・Netskope でSSLインスペクションされないため、SWG一部の機能のみが適用可能(ドメイン等の宛先制御)
【(3. )プロセスBYPASS と比較した場合】
・複数の通信先がある場合はひとつひとつ通信を特定しテナント側で設定を行う必要があるため、その分の稼働がかかる
・宛先ごとにSSL Do Not Decrypt を設定することになり、設定後該当通信はPython以外のプロセスもSSLインスペクションされなくなる
３．Python（プロセス）からすべての宛先のインターネット通信をBYPASS
【(1.)複合証明書対応と比較した場合】
・Netskope テナントで設定可能。端末に個別設定不要
・開発環境での利用シーンにおいての考慮・検討事項不要
【(2.)SSL Do Not Decrypt 設定と比較した場合】
・プロセスの特定さえできればプロセス単位でインターネット宛ての通信をBYPASSさせることができるため、複数の宛先宛てで通信を行うような場合においても通信許可対応が可能（※プロセスとドメインを指定してBYPASSさせることも可能）
・都度通信を特定する必要がないためそのための稼働がかからない
【(1.)複合証明書対応・(2.)SSL Do Not Decrypt 設定と比較した場合】
・Netskope でSteeringされないためSWG制御・可視化ができない
【(2.)SSL Do Not Decrypt 設定と比較した場合】
・プロセスごとにBYPASS するため、宛先を指定しない場合（HOST：* 指定の場合）、通信許可Webサイトの範囲が広がる。（※プロセスとドメインを指定してBYPASSさせることも可能）
４．Python のインターネット通信をブロック
・Netskope テナントで設定が可能なため、端末に対して個別設定は不要
・Netskope でSteeringされないため可視化ができない

 

 

参考



 

さいごに

最後にお伝えしたいことをまとめます。

  • 今回はWindows でのPythonプロセス「python3.12.exe」のみのインターネット制御をご紹介しました。図には他に「python.exe」や「py.exe」も記載していますが必要に応じてこちらもプロセスの特定・制御を実施ください。MACやLinux端末の場合も同様となりますが、「3.」BYPASS「 4.」BLOCK で指定するプロセス名はWindowsと若干異なります。プロセスを特定する際にご確認ください。

  • Python 以外の他のプロセス制御においても考え方は上記「1-4.」でお伝えした内容と同様となります。その他ツール・フレームワークでの対応方法についてや、MACでの複合証明書作成の方法についてはこちら の公式ドキュメント・コミュニティーブログをご参照ください。

  • 「３．Python（プロセス）のBYPASS」ではインターネット宛て通信すべて（HOSTで「*」指定）を設定する方法をご紹介しましたが、HOSTで特定の宛先を指定することでBYPASSする範囲を最小とすることができます。（※ただしプロセスのBYPASSはNetskope を通過せずローカルブレイクアウトするためSWG制御はできないことに加えて、ログの可視化はできません）

本記事が、Netskopeを用いたPythonスクリプト制御の導入・設計の一助となれば幸いです。

 
完全な記事を表示