Netskope LogoNetskope Logo
  • セキュリティサービス
  • AIサービス
  • ネットワークサービス
  • 分析サービス
  • 統合
  • getting-started.svg始める
    • サポート
    • コミュニティ
    • Netskope.com
    © 2026 無断転載を禁じます。Netskope 株式会社
    トップページ
    次世代 API データ保護プラットフォーム
    ServiceNow の次世代 API データ保護
    次世代 API データ保護用に ServiceNow を構成する

    次世代 API データ保護用に ServiceNow を構成する

    ServiceNowを次世代APIデータ保護用に設定するには、以下の手順に従ってください。

    前提条件

    ServiceNowを次世代APIデータ保護用に構成する前に、前提条件を確認してください。

    • ServiceNowアカウントで、San Diegoの最小バージョンが動作していること。

    • アプリケーションレジストリテーブルへの書き込み権限を持つ管理者ユーザー。

    Netskopeは、より適切なクォータとアクセス制御のために、専用のユーザーとロールを作成することを推奨しています。そのためには、ユーザーとユーザーロールの両方に書き込み権限が必要です。ただし、これは任意です。

    (オプション)認証スコープとREST API認証スコープを設定します

    ServiceNow アカウントで Xanadu 以降のバージョンを実行していて、認証スコープまたは REST API 認証スコープを通じてよりきめ細かな API アクセス制御を有効にする場合は、認証スコープを作成して開始します。 開始するには、以下の手順に従ってください。

    1. REST API認証スコープを有効にするには、この記事の手順に従ってください。

    2. アプリケーションのスコープを「グローバル」に設定してください。

    3. Allに移動し、フィルタ編集ボックスの下にsys_auth_scope.listと入力してEnterキーを押します。次にAuthentication Scopesページをクリックし、 Newをクリックします。

    4. Authentication Scopeページで、希望の名前とデスクリプションを入力し、Submitをクリックします。

      Ensure Application is set to Global.
    5. All > System Web Service > API Auth Scopes > REST API Auth Scopeに移動します。このページでは、テーブル用と添付ファイル用の2つの新しいAPIレコードを作成する必要があります。 Newをクリックしてください。

    6. 以下の詳細を入力してください。

      • NameREST API認証スコープの名前

      • REST API: Select Table API from the drop-down.

      • Ensure Application is set to Global.

      • Auth Scopeステップ4で作成した認証スコープSelect 。

      • Apply auth scope to all http methods in this APIチェックを外してください。

      • Ensure HTTP Method is set to GET.

      その他の項目は変更しないでください。

    7. Submitをクリックしてください。

    8. 別の新しいレコードを作成し、次の詳細を入力します。

      • NameREST API認証スコープの名前

      • REST API: Select Attachment API from the drop-down.

      • Ensure Application is set to Global.

      • Auth Scopeステップ4で作成した認証スコープSelect 。

      • Apply auth scope to all http methods in this APIチェックを外してください。

      • Ensure HTTP Method is set to GET.

      その他の項目は変更しないでください。

    9. Submitをクリックしてください。

    ServiceNow APIアクセスの設定

    この手順では、ServiceNowアカウントに新しいアプリケーションを作成し、NetskopeがAPIを介して必要なデータに安全にアクセスできるようにします。

    1. 管理者ユーザーとしてServiceNowアカウントにログインしてください。

    2. All > System OAuth > Application Registryに移動してNewをクリックしてください。

    3. Create an OAuth API endpoint for external clientsをクリックしてください。

    4. 新しいフォームに、以下の詳細を入力してください。

      • 名前: 識別可能な名前、例: Netskope Next-Gen CASB

      • クライアントシークレット: ~!@#$%^&*()_+`-=[]\{}|,./<>?;':"以外の特殊文字を含まない安全なシークレットを生成します。

        クライアントIDとシークレットをメモしておいてください。これらはNetskope UIでServiceNowインスタンスを作成する際に必要になります。
      • リダイレクトURL: https://nso.goskope.com/common/oauthorize

        – 米国の FedRAMP アカウントを接続する場合は、次のリダイレクト URL を入力してください: https://nso.govskope.us/common/oauthorize
        – カナダの連邦 PBMM アカウントを接続する場合は、次のリダイレクト URL を入力してください: https://nso.govskope.ca/common/oauthorize
      • リフレッシュトークンの有効期間: 31,536,000

        リフレッシュトークンの有効期間のデフォルト値は 86,400 秒 (約 100 秒) です。100日間)。その後はトークンが無効となり、データにアクセスできなくなります。Netskopeはアクセスを確保するために最低31,536,000秒(約1年)の入力を推奨しています。リフレッシュトークンが期限切れになると、Netskope UI内のアプリインスタンスは非アクティブとして表示されます。Netskope UIでServiceNowアプリインスタンスを再付与すべきです。
        リフレッシュトークンの有効期限切れを防ぐ方法の1つは、 Token record expiry in the Manage Token (oauth_credential)テーブルを更新するビジネスルールを作成することです。コミュニティの投稿はこちらをご覧ください。
      • Auth Scopeの下で、新しく作成した認証スコープを選択します。

        認証スコープとREST API認証スコープを設定済みの場合のみ、認証スコープSelect 。 そうでない場合は、この設定を空白のままにしてください。

      その他の項目は変更しないでください。

    5. 完了したら、 Submitをクリックしてください。

    Netskope専用のユーザーを作成する

    この手順は任意ですが、 Netskope次世代 API データ保護統合専用のユーザーとロールを作成するか、 作成することを強く推奨します。 専任のユーザーは、アクセス制御の改善や、NetskopeアプリのAPIリクエスト割り当て量の管理を支援することができます。Netskope専用のユーザーと役割が既に設定されている場合は、以下の手順をスキップできます。

    1. All > Organization > Usersに移動して、 Newをクリックします。

    2. 新しいフォームで必要なユーザー情報を入力し、 Submitをクリックします。

    3. All > User Administration > User Rolesに移動して、 Newをクリックします。

    4. 作成したユーザーにadminロール管理者、または下記のテーブルへのアクセス許可を持つ専用ロールを付与してください。

    Enable ServiceNow Table Permission

    管理者ロールを持つユーザーを認証する場合、デフォルトの管理者ロールにはNetskope監視するすべてのテーブルへのアクセスが含まれているため、通常は追加のアクセス制御リスト(ACL)の変更は必要ありません。 オンボーディングの際、次世代APIデータ保護機能は、必要なテーブルとカスタムテーブルすべてへのアクセス権限を検証します。 組織が管理者ロールをカスタマイズしている場合は、以下の表を確認して、ユーザーが アクセス権限を持っていることを確認してください。 そうでない場合、オンボーディングは失敗し、アクセスできない特定のテーブルが特定されます。

    次世代 API データ保護 ◇ は、すぐに使える (コア) テーブルとカスタム テーブルをサポートします。 彼らです:

    1. 基本構成項目

    2. Catalog Task

    3. 変更フェーズ

    4. 変更依頼

    5. 変更タスク

    6. 機能タスク

    7. グループ承認

    8. IMAC(インストール、移動、変更)

    9. Incident

    10. インシデントタスク

    11. KB提出

    12. Knowledge

    13. Problem

    14. 問題課題

    15. リリースフェーズ

    16. Request

    17. リクエストアイテム

    18. SC Item Option

    19. SC 複数行質問回答

    20. Task

    21. Ticket

    22. 変動所有権

    23. Any custom table

    Netskope上記のテーブルをスキャンするには、APIデータ保護がServiceNowへのAPI呼び出しを正常に実行できるようにするための追加の権限が必要です。 上記の各表について、以下の手順を繰り返してください。

    1. 管理者ユーザーとしてServiceNowアカウントにログインしてください。

    2. 左側のナビゲーションで「システム定義」という用語を検索し、 Tablesをクリックします。

    3. Search each table by either Label or Name. Click on the desired table.

    4. Application Accessの下で、 Allow access to this table via web servicesとcan readチェックボックスを選択してください。

    5. Updateをクリックしてください。

    6. 前述の専任ユーザーが、すべての標準テーブルやカスタムテーブルに対して読む権限を持っていることを確認してください。 詳細については、 ACLのドキュメントを参照してください。

    システムテーブルのアクセス権限を設定する

    NetskopeがServiceNowをスキャンしてAPI呼び出しを正常に行うためには、他にもいくつかのシステムテーブルが必要です。以下のシステムテーブルについても、上記と同じ手順に従ってください。

    TableUsage
    sys_db_objectTablesテーブルからレコードにアクセスします。
    ua_custom_table_inventoryCustom Tablesテーブルからレコードにアクセスします。
    このテーブルは テナントに登録されているカスタムテーブルを検出および検証するためのものです。 読むアクセスをお勧めします。 テーブルが利用できない、または読み取り不可能な場合でも、オンボーディングは完了します。ただし、Netskopeはテナントに登録されているカスタムテーブルを検出またはスキャンしません。
    sys_userCustom Tablesテーブルからレコードにアクセスします。
    sys_user_has_roleUser Roleテーブルにアクセスして、どのユーザーに役割が割り当てられているかを確認します。この表は、課金対象となるユーザー数を正確に計算するために必要です。アクセスが許可されない場合、オンボーディングは完了しますが、すべてのアクティブユーザーが課金対象としてカウントされます(役割のないリクエスターは除外できません)。 これにより、課金対象ユーザーの大幅な過剰計上が修正されます。
    sys_attachmentAttachmentメタデータテーブルからレコードにアクセスします。これは添付ファイルの内容を監視するために必要です。
    sys_attachment_docAttachmentコンテンツテーブルからレコードにアクセスします。これは添付ファイルの内容を監視するために必要です。

    Netskopeを設定してServiceNowアカウントにアクセスできるようにする

    NetskopeがServiceNowインスタンスにアクセスすることを承認するには、以下の手順に従ってください。

    1. NetskopeテナントUIにログインしてSettings > Configure App Access > Next Gen > CASB APIに移動します。

    2. Appsの下でServiceNowを選択し、 Setup CASB API Instanceをクリックします。

      Setup Instanceウィンドウが開きます。

    3. 以下の詳細を入力してください。

      • ServiceNow API アクセスの設定からクライアント ID とシークレットを入力してください。

      • ServiceNowアカウントインスタンスのサイトドメインを入力してください。

        ServiceNowのログインURLがhttps://my_instance.service-now.com/の場合、次に、ドメイン名としてmy_instance.service-今.comを入力します。
      • Instance Nameの下に、SaaSアプリインスタンスの名前を入力してください。この手順は任意であり、空白のままにした場合、Netskopeは権限付与後にアプリインスタンスの名前を決定します。

    4. Grant Accessをクリックしてください。ログインを求められます 以前の手順で作成した管理者ユーザー名とパスワードを入力し、 Sign Inをクリックしてください。 設定結果ページが開いたら、 Closeをクリックします。

    ブラウザを更新すると、インスタンス名の横に緑色のチェックマークが表示されます。

    オンボーディング検証

    オンボーディングの際、次世代APIデータ保護機能は、ServiceNowへの接続を完了する前に、必要なすべてのテーブルへのアクセス権限を確認します。 次世代APIデータ保護は、以下の点を検証します。

    • 上記にリストされているすべてのデフォルトテーブルは、ServiceNowインスタンス( sys_db_object )に存在します。

    • 専用ユーザーは 必要な各テーブルへのアクセス権を持っています。

    • ua_custom_table_inventoryに登録されているカスタムテーブルはすべて、同じユーザーがアクセスできます。

    ServiceNow テナントに上記のデフォルト テーブルが 1 つ以上含まれていない場合は、 Netskopeサポートにお問い合わせください。 例えば、関連するプラグインがアンインストールされ、再インストールされる予定がない場合などに、このような状況が発生する可能性があります。Netskopeのサポート担当者は、オンボーディング時にテナント内で利用可能なデフォルトテーブルのみを検証するように、オーバーライドを設定できます。オーバーライドから除外されたテーブルはスキャンされません。

    検証チェックが失敗した場合、オンボーディングは停止し、NetskopeテナントUIは失敗の原因となった特定のテーブルを特定します。ServiceNowにおけるアクセスまたは構成の問題を解決してから、オンボーディングを再試行してください。詳細については、「オンボーディングエラーのトラブルシューティング」セクションを参照してください。

    次に、「Next Generation API データ保護 Inventory ページを見て、ServiceNowアカウント上のさまざまなエンティティについて深い洞察を得ることができます。 Inventoryページの詳細については、「次世代APIデータ保護インベントリ」をご覧ください。

    Skope ITでは、監査イベントや標準的なユーザー行動分析アラートを受信できます。詳細については、次世代 API データ保護スコープ IT イベントをご覧ください。

    次に、次世代 API データ保護ポリシーを構成する必要があります。 これを行うには、 「次世代 API データ保護ポリシー ウィザード」を参照してください。

    オンボーディングエラーのトラブルシューティング

    オンボーディングが失敗した場合、NetskopeテナントUIに、注意が必要なServiceNowテーブルを特定するエラーが表示されます。参考として、以下のエラーメッセージを参照してください。

    • Error 1

      Required ServiceNow tables are not configured in the tenant: <table list>

      お使いのServiceNowインスタンスには、次世代APIデータ保護に必要なデフォルトテーブルが1つ以上不足しています。 これは通常、テナントがSan Diegoより前のリリースを実行している場合、またはテーブルを提供するServiceNowプラグイン(ITSMやKnowledgeなど)がアンインストールされている場合に発生します。必要なテーブルがSystem Definition > Tablesの下に存在することを確認してから、オンボーディングを再試行してください。

    • Error 2

      The User used during authentication does not have read access to the following ServiceNow tables: <table list>

      デフォルトのテーブルは存在しますが、専用ユーザーには リストされたテーブルへのアクセス権がありません。 影響を受ける各テーブルについて、上記の「ServiceNowテーブル権限の有効化」セクションを確認し、 Allow access to this table via web servicesとCan read有効になっていることを確認してください。また、ユーザーの役割が テーブル ACL でアクセス権を持っていることを確認してください。

    • Error 3

      The User used during authentication does not have read access to the following ServiceNow custom tables: <table list>

      専用ユーザーは読む ua_custom_table_inventory を読み、登録されたカスタムテーブルを発見できますが、読む テーブル自体へのアクセス権はありません。 上記の「 Enable ServiceNow Table Permissions 」セクションで説明したのと同じウェブサービスおよびACL構成を、各カスタムテーブルに適用します。

    複数のエラーが該当する場合は、 Netskopeでそれらをまとめて処理することで、一度にすべてを修正できます。

    このトピックでは
    • 次世代 API データ保護用に ServiceNow を構成する