はじめに
こんにちは、セキュリティチームのむろです。
前回はNetskopeのSecure Enrollment機能の特に導入(はじめ方)と運用(トークン更新)についてお話ししました。
Netskope Secure Enrollment 結局どうすれば良いの?
前回のブログ内でもマルチトークンサポート機能の存在ついて言及していましたが、実際に有効化して試してみたのでマルチトークン編としてお話しします。(大枠の流れは前回のほぼ焼き直しの内容です)
本ブログの内容は2025/4/18時点の情報となる点はご了承ください。
はじめにまとめ
- Secure Enrollmentは2025/6/1に強制有効化が発表されている
- Secure Enrollmentに関係するのはUPNモードでインストールしている端末
- IdPモード、Email Inviteでインストールしている端末は関係はない
- ただし、UPNモード以外でもNPAのPrelogon機能を利用している場合は設定が必要となる
- Secure Enrollmentに関係するのはUPNモードでインストールしている端末
- Secure Enrollmentは管理コンソール上で単純に有効化する操作だけではなく、MDM側も設定変更が必要
- Secure Enrollmentで利用するトークン値は定期的に更新が必要
- マルチトークンサポート機能を有効化すると2セットのトークンが同時に有効化できるため、MDM側の設定反映中にNot Enforceにして一時的にSecure Enrollmentが無効化される期間をゼロにできる
- 有効化する際やトークンの更新する際に影響を少なくするために作業の順序性が存在する
2025/6/1に強制有効化が予定されている
Netskope社にて2025/6/1にSecure Enrollmentを強制有効化する旨のアナウンスが発表されています。
End-of-Life Announcement for Insecure API Enrollment Mechanisms
※本URLはNetskpe Supportサイトのアカウントによるログインが必要となります
というわけでSecure Enrollmentの有効化が未実施の環境は期限まで対応を済ませておく必要がありますが、Secure Enrollmentは管理コンソールから有効化を選択するだけでは正しく動作しません。
MDM側にも対応が必要になり、適切な対応をしないとNetskope Clientのインストール(厳密にはユーザーエンロール)に影響が出る可能性があります。
公式ドキュメントや関連情報
まずは公開されている公式ドキュメントやコミュニティの情報を貼っておきます。
本ブログと一緒に参考にしながら参照いただけると幸いです。
Secure Enrollment – Netskope Knowledge Portal
Secure Enrollment Frequently Asked Questions – Netskope Knowledge Portal
Understanding and Actioning Notification Related to Secure Enrollment | Community
また、脆弱性「NSKPSA-2024-001(CVE-2024-7401 )」についてもご理解いただくとSecure Enrollmentがなぜ必要か、なぜ強制化をしようとしているか背景が見えてくるので知らない方は読んでみると良いかもしれません。
弊社の過去のブログは以下となります。
Netskope Secure Enrollment有効化のご案内
Netskope Secure Enrollment 結局どうすれば良いの?
Secure Enrollmentについて簡単におさらい
先ほどの公式ドキュメントに記載されていますがポイントをおさらいしておきます
Netskope Clientのインストールモードによる影響の違い
- Secure Enrollmentの「Authentication Token」はUPNモードの端末に影響がある
- Secure Enrollmentの「Authentication Token」はIdPモードの端末には影響はない
- 例外的にNPAのPrelogin機能を利用する場合はIdPモードでも「Authentication Token」が必要となります
Enforce authentication of Netskope Client Enrollment is mandatory to be enabled to protect against enrollment bypass issues. If user enrollment is enforced using UPN, then the token must be present in the end-user machine. For IDP enrollments, the token need not be present on the end-user machine as the user is authenticated using IdP. However, to use NPA Prelogon, auth token must be present on the end-user machine even with IDP enrollments.
- 手動でインストールする際のEmail Invite手順はSecure Enrollmentは関係はない
既存のNetskope Clientへの影響
- すでにユーザーエンロール済みのNetskope Clientには影響はない
- 既存端末でシングルユーザーモードのNetskope Clientは影響はない
- 既存端末でもマルチユーザーモードのNetskope Clientは新規にユーザーエンロールされる可能性があるため、影響を受ける
- 新規にNetskope Clientがインストールされ、これから新規にユーザーエンロールするNetskope Clientには影響がある
- 既存端末でもNetskope Clientを再インストールする場合は影響がある
その他
- Secure Enrollmentの2つのオプションの内、「Authentication Token」は有効化が必須ですが「Encryption Token」の有効化は必須ではありません。
- 本ブログの「Secure Enrollment」は基本的に「Authentication Token」のみ有効化された状態を指します
マルチトークンサポートの有効化方法
マルチトークンサポートは現時点(2025年4月時点)ではControlled GAでの提供となっています。
New Features And Enhancements In Release 123.0.0
Controlled General Availability (GA) of Multiple Token Support
This feature was earlier available as Beta in version 122.0.0. In version 123.0.0, Netskope extends as a Controlled GA feature. There is no change in the functionality or working of this feature.
つまり、管理コンソールからの設定変更ではなく、個別にバックエンドフラグとして申請し、テナント上で有効化する必要があります。
有効化についてはNetskopeのライセンスを契約しているサポート窓口へご相談ください。(弊社契約の場合はもちろんクラウドネイティブへ連絡でOKです)
なお、今後新規開設されるNetskopeテナントではデフォルトでマルチトークンサポートは有効化されるそうです。
マルチトークンサポートを有効化する際の流れ
- 有効化の依頼の前に現状のトークン値や期限、ステータス(Enforce or Not Enforce)を控えておく
- 想定外の挙動に備えて現行の状態を控える意図となります
- サポート窓口へSecure Enrollmentのマルチトークンサポート機能の有効化を依頼
- サポート窓口から有効化された旨を連絡を受ける
- 有効化前のトークンの情報が維持されているか確認する
- もしも、トークンの内容が変化していたり、削除されている場合はMDM側へ本ブログの内容を参考にトークン更新を端末側でのユーザーエンロールが走る前に必要になります
Secure Enrollmentを有効化する前の準備
既存端末のNetskope Clientのバージョンアップを行っておきます
- 原則はバージョンによって追加機能がある可能性があるため、最新バージョンへの更新をおすすめします
- 例えば、R124からmacOSにおいてnsdiagによるトークン情報書き換えがサポートされています(以前はWindowsのみでした)
本ブログ手順の前提
- 「Authentication Token」のみを有効化する前提の手順となります。
- Netskope ClientバージョンがR124以上の前提となります。
- 今回はタイトル通り、マルチトークンサポート状態のSecure Enrollmentが前提の手順となります。
Secure Enrollmentの有効化手順(はじめ方)
Secure Enrollmentを有効化する手順を以下に示します。
1) Secure Enrollmentを有効化してトークン値を控える
- Netskope画面より「Settings > Security Cloud Platform > Netskope Client > MDM Distributions」内のSecure Enrollment部分を開く
- 「Create TokenSet」を選択

- もしも、STATUSが「Enforced」ステータスの場合は右端の3点リーダから「Do Not Enforce」を選択してすぐにNot Enforcedステータスに変更する(通常は有効直後はNot Enforcedステータスで期間はN/Aとなっています)
- 「Copy token」を選択してAUTHENTICATION TOKENの値を控える


2) MDM内のインストールコマンドへトークンを追加する
- IntuneやJamfなどのMDMに設定しているインストールコマンドに控えたAUTHENTICATION TOKENをenrollauthtokenオプションを追加して指定する
- enrollauthtoken=<認証トークン=AUTHENTICATION TOKENの値>
例)Single User Modeで配布したい場合
msiexec /i "NSClient_<クライアントバージョン>_Windows.msi" host=addon-<テナント名>.goskope.com token=<Org Key> enrollauthtoken=abc123dummy123abc123dummy /qn /l*v %PUBLIC%\nscinstall.log
※他のパターンのインストールコマンドの例は前述の公式ドキュメントを参照ください(enrollauthtokenオプション自体の利用方法に差異はありません)
3) MDMで既存の端末上のトークンの値を配布する
この手順は「UPN x マルチユーザーモードのNetskope Client 端末」のみが対象です
- IntuneやJamfなどのMDMを利用してnsdiagコマンドの-eオプションを利用して端末内に保持されているAUTHENTICATION TOKENを更新した新しい値を配布する
nsdiag -e enrollauthtoken=abc123dummy123abc123dummy
- なお、nsdiagを利用する場合はフルパスで指定するか、パスをOS内の環境変数で通しておく必要があります。
4) Secure Enrollmentを強制モードに変更する
- 端末側に選択してEnforcedステータスにする

- Enforce時にトークンの期間を選択する(デフォルトは90日)


- AUTHENTICATION TOKENの有効期限を控える(有効化後の運用時に定期的な更新が必要になります)

- 期限の右横のEditマークを選択すると現在の期限対して追加(Extend)を行うことが可能です

5) 動作確認を行う
- 検証機などを利用して実際にMDMからNetskope Clientを配布し、ユーザーエンロールまで正常に完了するか確認を行う
- 結果確認は端末側のNetskope Clientの状態を直接確認するか、Netskope管理コンソールのDevices上のNetskope Clientのステータスで判断することも可能です
- 細かなインストールタイミングなどはデバイスの詳細画面ごとのEVENT HISTORYからも確認できます
Devices – Netskope Knowledge Portal

6) トークンの有効期限を管理する
- 控えたAUTHENTICATION TOKENの有効期限を基準に対応漏れがないように管理してください
- 例)Asanaなどのタスク管理できるサービスでチケット化しておく
- 管理画面にも警告が出るようですが気づきにくいので別途期限管理することをおすすめします
- 期限切れの何日前、あるいは特定の指定日にAUTHENTICATION TOKENを更新するか決定しておく必要があります
- なるべくNetskopeのユーザーエンロールが発生しない・少ない日を選択することが望ましいです
- 例)新しい従業員の入社日を避ける
Secure Enrollment有効化後のトークン更新手順(運用対応)
前述のようにSecure Enrollmentのトークンは期限があり、定期的に更新が必要となります。
1つ目のトークンセットの有効期限が切れる前に2つ目のトークンセットを有効化することでSecure Enrollmentが有効な状態で途切れなくトークン値をローテーションできます。
1) トークンセットを追加する
- Netskope画面より「Settings > Security Cloud Platform > Netskope Client > MDM Distributions」内のSecure Enrollment部分を開く
- はじめに古いトークンセットを削除する(初回の更新時はこの作業は不要です)
- 右端の「Do Not Enforce」でNot Enforcedスタータスにしてから「Delete」を選択する
誤って新しい期限のトークンセットを削除しないように注意してください。

- 「Add New TokenSet」を選択してトークンセットを追加する

- 新しく作成されたトークンセットをEnforceする(1つ目のトークンセットがまだ有効なため、そのままEnforcedとしても問題ない)
- Enforce時にトークンの期間を選択する(デフォルトは90日)


- 新しいトークンセットのトークン値を控える
誤って古い期限のトークン値をコピーしないように注意してください。


2) MDM内のインストールコマンド上のトークンの値を更新する
- IntuneやJamfなどのMDMに設定しているインストールコマンド内のenrollauthtokenオプション指定で指定しているAUTHENTICATION TOKENを更新した新しい値へ書き換える
- enrollauthtoken=<認証トークン=AUTHENTICATION TOKENの値>
例)Single User Modeで配布したい場合
msiexec /i "NSClient_<クライアントバージョン>_Windows.msi" host=addon-<テナント名>.goskope.com token=<Org Key> enrollauthtoken=abc123dummy123abc123dummy /qn /l*v %PUBLIC%\nscinstall.log
※他のパターンのインストールコマンドの例は前述の公式ドキュメントを参照ください(ただし、enrollauthtokenオプション自体の利用方法に差異はありません)
3) MDMで既存の端末上のトークンの値を更新する
この手順は「UPN x マルチユーザーモードのNetskope Client 端末」のみが対象です
- IntuneやJamfなどのMDMを利用してnsdiagコマンドの-eオプションを利用して端末内に保持されているAUTHENTICATION TOKENを更新した新しい値へ書き換える
nsdiag -e enrollauthtoken=<認証トークン=AUTHENTICATION TOKENの値>
- なお、nsdiagを利用する場合はフルパスで指定するか、パスをOS内の環境変数で通しておく必要があります。
4) 動作確認を行う
- 検証機などを利用して実際にMDMからNetskope Clientを配布し、ユーザーエンロールまで正常に完了するか確認を行う
- 結果の確認は端末側のNetskope Clientの状態を直接確認するか、Netskope管理コンソールのDevices上のNetskope Clientのステータスで判断することも可能です
- 細かなインストールタイミングなどはデバイスの詳細画面ごとのEVENT HISTORYからも確認できます
Devices – Netskope Knowledge Portal

5) トークンの有効期限を管理する
- 控えたAUTHENTICATION TOKENの有効期限を基準に対応漏れがないように次回の更新日を管理してください
- 例)Asanaなどのタスク管理できるサービスでチケット化しておく
- 管理画面にも警告が出るようですが気づきにくいので別途期限管理することをおすすめします
- 期限切れの何日前、あるいは特定の指定日にAUTHENTICATION TOKENを更新するか決定しておく必要があります
- なるべくNetskopeのユーザーエンロールが発生しない・少ない日を選択することが望ましいです
- 例)新しい従業員の入社日を避ける
- 期限が古いトークンセットはいずれExpireするため、そのまま変更は行わない
- 本ブログでは「次回の更新時に削除する」運用としています
Secure Enrollmentに対する補足やTips
「nsdiag -e」とは
- すでにユーザーエンロール済みのNetskope Client 端末内のトークンを更新する際に利用するコマンドです
- 本ブログ内でも記載の通り、UPN x マルチユーザーモードのNetskope Clientで利用します
- macOSでの「nsdiag -e」はR124からサポートされました
トークンの更新周期はどうするべきか
- Secure Enrollmentマルチトークンサポートでは最小7日からとなります
- こういった前提の中で具体的に何日以内周期で更新すべきということの明言は難しいです
- 各組織の運用リソース、トークンが長期間更新されないリスク評価、セキュリティに関する規定によって変わるため、各組織ごとに適切な更新周期は異なると思います
- ただ、他製品のトークン期限のデフォルト値やCIS Benchmarkなどの記述からはこのような認証用のトークン(アクセスキー)は90日周期以下で更新することを推奨している記載や意図が多く見られます
- そのため、特定の事情や要件がなければ90日周期以下で更新する運用とするのが望ましいと思います
Secure Enrollmentの設定とインストールコマンドに対する挙動の違い
Secure Enrollmentの設定状態とインストールコマンドの状態の組み合わせに対して以下の挙動となる旨をサポートへ確認しています。
今回のブログ内手順はこの内容を元に順序性を組み立てています。
<Secure Enrollment自体が無効時の挙動>
- 「enrollauthtoken=」オプション自体無しの場合 > エラーとならずにエンロール成功
- 「enrollauthtoken=」を指定した場合 > エラーとならずにエンロール成功
<Not Enforcedステータス時の挙動>
- 「enrollauthtoken=<auth token>」オプション自体無しの場合 > エラーとならずにエンロール成功
- 「enrollauthtoken=<auth token>」トークン値が誤りの場合 > エラーとならずにエンロール成功
- 「enrollauthtoken=<auth token>」トークン値が正しい場合 > エラーとならずにエンロール成功
<Enforcedステータス時の挙動>
- 「enrollauthtoken=<auth token>」オプション自体無しの場合 > エラーとなりエンロール失敗
- 「enrollauthtoken=<auth token>」トークン値が誤りの場合 > エラーとなりエンロール失敗
- 「enrollauthtoken=<auth token>」トークン値が正しい場合 > エラーとならずにエンロール成功
おわりに
前回に引き続き、マルチトークンサポートを有効にしたSecure Enrollmentについて記載しました。
マルチトークンモードのSecure Enrollmentを検討したい方々に参考いただけると嬉しいです!