サービスアカウントの移行とNetskope Client監査

この記事は、Netskope管理者がAPI統合を従来のREST API V2トークンモデルから、安全でロール駆動型のRBAC V3サービスアカウントフレームワークに移行するための包括的なガイドです。

この移行は重要なステップです。RBAC V3フレームワークは、分散型“API First” architectureへの必須のアーキテクチャ変更を表しており、WebUIとREST APIのやり取りの両方で一貫した認可を保証します。

REST API V2トークンの廃止と必須サービスアカウントワークフロー

以前のREST API V2トークンプロビジョニングワークフローは非推奨となり、RBAC V3機能が有効化されると利用できなくなります。

• V2 Token Deprecation Status: RBAC V3 が有効になると、非推奨のインターフェイス ([設定] > [ツール] > [Rest API V2]) を使用して、新しい V2 トークンをプロビジョニングすることはできなくなります。
• Existing V2 Tokens: 既存のV2トークンは、指定された有効期限まで引き続き機能します。しかし、これらのトークンはcannot be extended 。
• New Workflow Requirement: 今後のトークン プロビジョニングはすべて、RBAC V3 ロール管理フレームワークと完全に統合された新しいサービス アカウント作成プロセスを使用して実行する必要があります。

事前的なAPIクライアント監査（施行前の重要なステップ）

RBAC V3 ロールまたはグローバルに IP 許可リストを有効にする前に、管理者mustはすべての API クライアントの送信元 IP の事前監査を実施します。 これが壊滅的なサービス停止を防ぐ唯一の方法です。

既存の API クライアントの完全なインベントリなしにロールベースまたはグローバル IP 許可リストを有効にすると、 “self-inflicted denial-of-service attack.”

許可リストを有効にすると、リストに登録されていないIPアドレスからのすべてのAPI呼び出しが即座にブロックされ、以下を含む重要なセキュリティおよび運用上の統合が停止します。

• セキュリティ情報およびイベント管理（SIEM）プラットフォームがログを取り込む
• セキュリティオーケストレーション、自動化、およびレスポンス（SOAR）ツールによるレスポンスのオーケストレーション
• SCIMユーザープロビジョニングフロー
• カスタムスクリプトと自動レポートツール

IP インベントリ用の REST API を使用する

管理APIアクティビティに関する決定的な方法であり、最も信頼できる情報源は、UI監査ログではなく、Netskope REST API V2そのものです。

ステップ1：監査範囲の特定

1. Recommended Audit Window: 使う 最低 90-day audit window。 この期間はNetskopeのデフォルトのログ保持と一致し、頻繁なAPI活動と不頻繁なAPI活動の両方が記録されることを保証します。
2. Required Endpoints: REST API v2のエンドポイント datasearch クエリを問い合わせます。これらはアドホッククエリ用に設計されており、APIの活動を含む可能性が高いイベントに焦点を当てています。

    ◦ /api/v2/events/datasearch/alert

    ◦ /api/v2/events/datasearch/application

    ◦ /api/v2/events/datasearch/page

3. Key Data Point: 返されたログレコードからsrcipフィールドの値を抽出してください。このフィールドにはAPIクライアントの送信元IPアドレスが含まれています。

ステップ 2: スクリプトを使用してインベントリを抽出する (例)

ページネーションを効果的に処理し、大量のデータを処理するには、プログラムによるクエリが必要です。

主なタスクは、これらのイベントログをプログラムで照会し、 srcipを抽出し、すべての送信元 IP アドレスの最終的な一意のリストを集約することです。

Example Implementation Logic:

• スクリプトは、定義されたdatasearchエンドポイントを90日間繰り返し処理する必要があります。
• pagination処理するには、 offsetパラメータをインクリメントして、それ以上レコードが返されなくなるまで繰り返す必要があります。
• JSONレスポンスを解析し、一意のsrcip値を抽出して、最終的にすべてのクライアント送信元IPアドレスの網羅的なリストを提供する必要があります。

ステップ3：ロールベースの許可リストを実装する

1. Review and Approve: 一意の IP の集約リストを確認して、各 IP をその所有者および目的 (SIEM プラットフォーム、カスタム ツールなど) と関連付ける必要があります。
2. Configure Role Allowlist: 役割設定（設定 > 管理 > 役割）に移動し、 IP Allowlistセクションに承認済みの IPv4 アドレスを入力します。

    ◦ IPアドレスはspace-delimitedであり、有効なIPv4アドレスである必要があります。

3. Critical Security Note: ロールベースのIP許可リストsupersedes and overrides 、以前に設定されたグローバルIP許可リスト設定を含みます。その役割で有効化されている場合、その役割は当該サービスアカウントのアクセス制御に関する唯一の信頼できる情報源となります。

SCIM統合アップデート：サービスアカウントV3への段階的移行

従来の API トークンから RBAC V3 サービス アカウントへの移行には、役割の作成、サービス アカウントの作成、統合の更新という 3 つの段階からなる順序付けられたプロセスが必要です。

ステップ1：役割の作成（最小権限の原則）

RBAC V3はロール駆動型であるため、サービスアカウントを作成する前にcreate the role firstする必要があります。

1. Navigate to Role Management: Administration > Rolesに移動してNewをクリックしてください。
2. Define Permissions (PoLP): 説明的な名前を割り当ててください（例： scim_provisioner ）。Principle of Least Privilege (PoLP)を適用します。

    ◦ SCIMの場合は、 Administrationカテゴリを選択してください。

    ◦ サービスアカウントは非対話型であるため、明示的にdeselect permissions for UI functionsおよびその他の必須でない操作は行いません。

    ◦ UsersおよびGroup APIの権限レベルをManageに設定してください。これらはSCIMプロビジョニングに必要です。

3. Apply IP Allowlist: 監査（セクション 2）を実施した場合は、 IP Allowlistタブに移動して、ID プロバイダー (IdP) の承認済み送信元 IPv4 アドレスを追加します。

ステップ2：サービスアカウントとトークンの作成

1. Create Service Account: Administration > Administrators & Rolesに移動してService Accountをクリックしてください。
2. Configure Account: サービスアカウントの名前を入力し、フェーズAで作成したカスタムロールを選択します（例： scim_provisioner ）。
3. Set Expiration: Specify the token’s expiration period (e.g., 12 months).
4. Generate and Store Token (Critical Step): Createをクリックしてください。APIトークンは、作成が成功するとonly once表示されます。後で取得できないため、 critical to copy and securely store this token immediatelyとなります。

ステップ3：SCIM統合の更新

1. Update API Token: IDプロバイダー（IdP）のSCIMプロビジョニング設定（例：OktaまたはEntra ID）で、古いV2 APIトークンをnew V3 Service Account tokenに置き換えます。
2. Update Base URL: 古い SCIM サービス URL は非推奨になるため、新しい RBAC V3 準拠のエンドポイントを指すように変更する必要があります。

    ◦ New Base URL Format: https://<tenant-name>.goskope.com/api/v2/scim.

3. Test Connection: トークンとベース URL の両方を更新した後、 test the connection実行して統合が正しく機能していることを確認します。

接続エラーのトラブルシューティング

接続テストが失敗した場合、最も一般的な理由は、役割ベースの IP 許可リストとの競合です。

• Verify Source IPs: 役割の IP 許可リスト構成を確認し、現在の送信元 IP アドレスが 特定の SCIM プロバイダー (例: Okta のセル IP または Microsoft Entra ID 範囲) によって、役割の許可リストに正確に含まれていることを確認してください。 the role-based allowlist supersedes any global settingsを覚えておいてください。