DLPオンデマンドのAIファイル分類とエンティティ検出の構成

DLP On Demand (DLPoD) アプライアンスは、AI搭載のコンテンツ検査機能（これらをまとめて DLP-LLM と呼びます）を3つサポートしています。

Capability	その機能	推論が実行される場所
AI File Classification	抽出されたドキュメントをファイルカテゴリ（予算計画やバンキング契約など）に分類して、DLPプロファイルがファイルタイプと照合できるようにします。	AWS Bedrock (Netskope管理アクセス)
AI Entity, NER (Named Entity Recognition)	名前、住所、電話番号、社会保障番号などの個人を特定できる情報（PII）を抽出して、DLPエンティティルールで検出および編集できるようにします。	独自のAWSアカウントでホストするSageMakerリアルタイムエンドポイント
AI Entity, Genomic and Human-omic Detection	科学または臨床テキストから遺伝子、タンパク質、疾患などの生物医学的実体を抽出します。	NERと同じSageMakerエンドポイントと、セカンドゲノムパス用のAWS Bedrock

これらの機能は、nsshellから2つの独立したコマンドで有効にします。

リクエストdlp-llm設定はAIファイル分類を設定します。
リクエスト dlp-llm-ner 設定は NER とゲノム検出を設定します。

2つのコマンドは異なるクレデンシャルを使用し、互いに干渉しません。一方を有効にして、もう一方を有効にしないこともできます。

AIエンティティの結果がDLPプロファイルにどのように表示されるかの詳細については、DLP Entityを参照してください。ファイルカテゴリの詳細については、File Classifiersを参照してください。

DLPoDアプライアンスがどこにホストされているかに関係なく、DLP-LLM推論は常にAWSで実行されます。アプライアンス自体はAWS、Azure、GCP、およびオンプレミスのハイパーバイザー（Hyper-V、KVM、およびVMware）をサポートしていますが、どちらにしても推論バックエンドをホストするにはAWSアカウントが必要です。アプライアンスが使う認証方法は、アプライアンスがどこで実行されているかによって異なります。

DLPoDアプライアンスホスティングプラットフォーム	AIファイル分類 (Bedrock) 認証	NERおよびゲノム（SageMaker）認証
AWS (EC2)	IAMロール（インスタンスプロファイル）（推奨）、またはAWSキー	IAMロール（インスタンスプロファイル）を推奨。または永続的IAMキー、STS、JWT
Azure、GCP、またはオンプレミス	Bedrockの長期APIキー（必須）	Amazon Cognito経由のJSON ウェブ Token (JWT)、必須

アプライアンスがAWS EC2で実行されている場合、EC2インスタンスロールが両方の機能に対するデフォルトの推奨オプションです。ロールのクレデンシャルは自動的にローテーションされるため、キーを管理またはローテーションする必要はありません。アプライアンスがAzure、GCP、またはオンプレミスで実行されている場合、ネイティブなAWS IDがないため、AIファイル分類にはBedrock長期APIキー、NERにはJWTで認証する必要があります。

Azure ML、Azure AI Foundry、Vertex AI、プライベートAIインフラストラクチャをネイティブ推論バックエンドとしてサポートすることはロードマップに含まれていますが、このリリースではご利用いただけません。AWS外でホストされたアプライアンスは、推論のためにAWSにアクセスします。

Prerequisites

DLP-LLMを構成する前に、以下を確認してください。

DLPoDアプライアンスは展開され、完全に初期化されており、dlp-llmサービスを含むリリースで使用されます。
アプライアンスはテザリングされています。コンフィギュレーターは、テザリング後にのみ利用可能なテナント転送キーを使用してクレデンシャルを暗号化します。
アプライアンスは、AWS Bedrockへのネットワーク送信およびNERの場合はSageMakerエンドポイントへのネットワーク送信を行う必要があります。送信にSSL検査を使用している場合は、CAバンドルオプションのトラブルシューティングセクションを参照してください。
AWSアカウントをお持ちです。BedrockとSageMaker NERエンドポイントは、アプライアンスのホスティングプラットフォームに関係なく、常にAWSで実行されます。

AIファイル分類の場合、アプライアンスがBedrockを呼び出すために使うことができるAWSクレデンシャルも必要です。NERの場合は、AWSアカウント内にSageMakerリアルタイムエンドポイントと、アプライアンスがそれを呼び出すためのクレデンシャルも必要です。

SageMakerエンドポイントを自分でセットアップする場合は、これらのローカルツールも必要です。

AWS CLI v2
Docker（デーモンが実行中の状態）
crane。NERデプロイメントスクリプトが、SageMakerが必要とするマニフェスト形式でイメージをプッシュするために使用します。
ECRリポジトリ、IAMロールおよびポリシー、SageMakerモデルおよびエンドポイントを作成するためのIAM権限

Configuring AI File Classification

AIファイル分類はAWS Bedrock上で実行されます。必要なIAM権限は、選択したモデルによって異なります。

Setting Up AWS IAM for Bedrock

2つのモデルファミリーが利用可能で、それぞれ異なるIAMポリシーを使用します。

google.gemma-4-31b およびopenai.gpt-5.6-lunaはBedrock Mantleで実行されます。
us.amazon.nova-pro-v1:0 および us.amazon.nova-2-lite-v1:0 は標準のBedrock上で実行されます。

Bedrock Mantleモデルの場合、bedrock-mantle：CreateInferenceおよびbedrock-mantle：CallWithBearerTokenを許可するポリシーをアタッチし、アカウントのデフォルトBedrock Mantleプロジェクトにスコープします。

標準のBedrockモデルの場合、bedrock:InvokeModelおよびbedrock:InvokeModelWithResponseStreamを許可するポリシーをアタッチします。リージョン間モデルの呼び出しは、推論プロファイルと基盤となるモデルという2つのリソースに対してチェックされます。両方をポリシーに含めます。

標準のBedrockでは、us.-プレフィックス付きを使う推論プロファイルモデルID。Bedrockサービスは、オンデマンドで使うプレフィックスのない基盤モデルIDを拒否します。

アプライアンスがAWS EC2で実行されている場合は、静的キーを使う代わりにインスタンスプロファイルをアタッチできます。ロールを作成し、Bedrockポリシーをアタッチし、インスタンスプロファイルを作成し、AWS CLIを使用して実行中のインスタンスに関連付けます。インスタンスの再起動は不要です。

AWSアカウントがNSPowerUser権限境界で管理されている場合は、作成するすべてのロール、ポリシー、およびインスタンスプロファイルに、アカウントが必要とするアプリケーションロールパスと権限境界が含まれている必要があり、ロールにはロールの引き受けを許可するためにアカウントが使うタグが付いている必要があります。このモデルでは、IAMリソースはAWSコンソールではなく、CLIまたはTerraformを使用して作成する必要があります。

アプライアンスがAWS以外（Azure、GCP、またはオンプレミス）で実行されている場合は、代わりにBedrockの長期APIキーを生成してください。

AWS コンソールで、 Amazon Bedrock > API Keysに移動します。
Long-term API Keysの下で、 Generate Long-Term API Keyを選択してください。
Specify an expiration.
キーをコピーします。dlp-llm configureリクエストでAPIキーのクレデンシャルとして入力します。

Running request dlp-llm configure

DLPoDアプライアンスのnsshellから、以下を実行します。

nsappliance> request dlp-llm configure

コマンドは以下の値の入力を求めます。デフォルトは括弧内に表示されています。

Auth method: aws-keys（デフォルト）またはapi-key。アプライアンスがAWS EC2で実行されている場合はaws-keysを、AWS以外で実行されている場合はapi-keyを選択します。
AWS credentials、選択した認証方法と一致します。
Region、BedrockのAWSリージョンです。デフォルトはus-west-2です。
Daily request limit、service.max_daily_requests。制限なしの場合は0を入力します。デフォルトは100000です。
Model、サポートされている4つのモデルIDの1つです。デフォルトはgoogle.gemma-4-31bです。

モデルの変更は、構成の再読み込みではなく、次にdlp-llmサービスが再起動したときに有効になります。

AWSのクレデンシャルフィールドを空のままにすると構成は保存されますが、有効なクレデンシャルを入力するか、正しいポリシーを持つインスタンスロールをEC2に割り当てるまではAIファイル分類は認証されません。この状況になるとコマンドは警告を出します。

Configuring NER and Genomic Entity Detection

NERおよびゲノム検出は、独自のAWSアカウントのSageMakerリアルタイムエンドポイントに対して実行されます。あなたがエンドポイントをホストし、アプライアンスがそれを呼び出します。検査のために送信されたコンテンツがAWS環境外に出ることはありません。

Deploying the SageMaker Endpoint

Netskopeは、NERモデルとゲノムモデルを組み込んだコンテナイメージを提供します。これは、圧縮されたDockerイメージのtarballとして、またはNetskopeがホストするレジストリへのプルリファレンスとして提供されます。

展開する前に以下を確認してください。

Requirement	Detail
AWSアカウントとリージョン	SageMaker GPUリアルタイムエンドポイントが利用可能なリージョン
インスタンスタイプ	ml.g5.xlargeはプロダクションに推奨
サービスクォータ	アカウントにml.g5.xlargeエンドポイント使用のクォータがあることを確認する
Amazon ECR	イメージを格納するための同一リージョン内のプライベートリポジトリ
IAM	ECRリポジトリ、SageMaker実行ロール、SageMakerモデル、エンドポイントを作成する権限。

Netskopeは、完全なセットアップを自動化するデプロイスクリプトdeploy_ner_sagemaker.shを提供しています。このスクリプトは、イメージをロードし、それをECRにプッシュし、SageMaker実行ロールが存在しない場合に作成し、モデル、エンドポイント構成、およびエンドポイントを作成し、テストコールでPIIモデルとゲノムモデルの両方のファミリーを検証します。tarball、AWSアカウントID、およびリージョンを使用して実行します：

./deploy_ner_sagemaker.sh --tarball dlp-ner-sagemaker-<version>.tar.gz \
  --account <your-aws-account-id> --region <your-region>

スクリプトを使用せずに手動で展開する場合は、SageMakerモデルを作成するときにコンテナ環境変数NER_MODEL_TYPE=xlmrを設定する必要があります。これがない場合、エンドポイントは始めることができず、InService状態になることはありません。この要件は26.8.xイメージに適用されます。ゲノムモデルには影響しません。

再デプロイせずに実行中のエンドポイントを検証するには、–validate-onlyを使用してスクリプトを実行します。

Setting Up NER Authentication

アプライアンスがSageMakerエンドポイントに認証する方法を選択します。4つのクレデンシャルタイプが利用可能です。

タイプ	使うタイミング	提供される機能
A、永続的なIAMキー	最もシンプルなキーベースのオプション	長期間有効なAWSアクセスキー
B、Amazon Cognitoを通じたJWT	AWS外でホストされているアプライアンスに必要	長期間有効なCognitoクライアントシークレットから発行される短期間有効なトークン。アプライアンスに固定のAWSキーはありません
C、STSテンポラリクレデンシャル	上級：すでに短寿命のクレデンシャルをアプライアンスにローテーションしている場合のみ	期限切れになる前に更新しなければならない一時的なAWSクレデンシャル
D、EC2インスタンスロール	アプライアンスがEC2で実行されている場合に推奨	インスタンスロールから自動ローテーションされたテンポラリクレデンシャル。アプライアンスには何も保存されません。

どのタイプを選択する場合でも、エンドポイントのAmazonリソースネーム（ARN）にスコープ指定された最小限の権限sagemaker:InvokeEndpointのみを付与してください。

If your appliance runs on AWS EC2 (Type D, recommended): 上記の起動権限を持つアプライアンスのEC2インスタンスにIAMロールをアタッチします。インスタンスにすでにロールがある場合は、ロールを置き換えるのではなく、許可をロールに追加します。インスタンスは1つのロールしか保持できないためです。dlp-llm-ner configureを実行する際、AWSクレデンシャルのフィールドは空白のままにしてください。アプライアンスは自動的にインスタンスロールを使用します。dlp-llmサービスがすでに実行されている場合は、それを再起動して、そのロールを適用します。

If your appliance runs off AWS (Type B, required): SageMakerエンドポイントの前にAmazon API GatewayとCognitoオーソライザーを配置して、アプライアンスがAWSアクセスキーではなく、長期のCognitoクライアントシークレットを保持するようにします。大まかに言うと：

Cognitoユーザープール、ドメイン、リソースサーバー、スコープを作成します。
マシン間アプリクライアントを作成します。これにより、クライアントIDとクライアントシークレットが生成されます。
API GatewayがSageMakerエンドポイントを呼び出すことを許可するIAMロールを作成します。
SageMakerエンドポイントと統合され、Cognitoオーソライザーによって保護されたPOSTメソッドを使用してAPI Gateway REST APIを作成します。
APIをデプロイし、そのURLをメモしてください。

次に、リクエストdlp-llm-ner configureで以下の値を入力します。

Field	Value
client_id	作成したアプリクライアントから
client_secret	作成したアプリクライアントから
token_url	CognitoドメインのOAuthトークンエンドポイント
api_url	展開された API Gateway URL
scope	Cognitoリソースサーバーのスコープ。例：predict/Sagemaker.invoke

クレデンシャルをローテーションするには、Cognitoでアプリクライアントシークレットを再生成してから、アプライアンスでclient_secretを更新してください。アプライアンスは短期間有効な新しいトークンを自動的に作成するため、手動でトークンを管理する必要はありません。

Running request dlp-llm-ner configure

DLPoDアプライアンスのnsshellから、以下を実行します。

nsappliance> request dlp-llm-ner configure

コマンドは以下の値の入力を求めます。デフォルトは括弧内に表示されています。

Auth method: aws-keys（デフォルト）、api-key、またはjwt。上記で設定したクレデンシャルタイプに基づいて選択します。
Credentials, 選択した認証方法と一致します。永続的なIAMキーまたはEC2インスタンスロールの場合、これはAWSアクセスキーIDとシークレットです（インスタンスロールを使用する場合は両方を空白のままにします）。JWTの場合、これはクライアントID、クライアントシークレット、トークンURL、API URL、およびスコープです。
Region、SageMakerエンドポイントのAWSリージョンです。デフォルトはus-west-2です。
Daily request limit、service.max_daily_requests。制限なしの場合は0を入力します。デフォルトは100000です。

このコマンドはモデル選択をプロンプトしません。NERモデルはあなたのSageMakerエンドポイントの一部であり、Bedrockモデルではありません。

Verifying and Troubleshooting

アプライアンスの全体的なステータスを確認し、どのサービスが実行されているかを確認するには、次のコマンドを使用します。

nsappliance> request status health
nsappliance> request status all

DLP-LLMがどの認証方法を使用しているかを確認するには、dlp-llmサービスのログで、IAM永続キー、一時キー、JWT、EC2インスタンスロールなどのアクティブな方法の名前を示すメッセージを確認します。

次の表は、よくある問題の一覧です。

Symptom	予想される原因と対策
構成がtransit-keyエラーで失敗する	アプライアンスがまだ接続されていないか、構成の同期の準備ができていません。待機してから、configureコマンドを再度実行してください。
NERクレデンシャルが拒否された	アクセスキーまたはシークレットが正しくないか、AWSアイデンティティを検証する権限がありません。クレデンシャルを修正して、もう一度試してください。
NERはネイティブアイデンティティエラーなしで無効のままです。	EC2インスタンスロールを使うためにクレデンシャルフィールドを空白のままにしましたが、インスタンスにロールが割り当てられていません。ロールを割り当ててからサービスを再起動してください。
NER構成にはJWTとIAM フィールドの両方があります。	構成を手動で編集するのではなく、dlp-llm-ner configureリクエストを再実行して、新しいスタイルを保存する前に古いフィールドをクリアしてください。
AIファイル分類がアクセス拒否エラーを返します	IAMポリシーが選択したモデルと一致しません。MantleモデルにはBedrock Mantleポリシーを使用し、2つのNovaモデルには標準のBedrockポリシーを使用していることを確認してください。
モデルの切り替え後にAIファイル分類が失敗する	新しいモデルは、Bedrock内のAWSアカウント用にプロビジョニングされません。プロビジョニングを確認し、モデルの変更は次回のサービス再起動時に有効になることにご注意ください。
SageMakerエンドポイントが作成中または更新中の状態のままになる	モデルはNER_MODEL_TYPE=xlmr環境変数なしで作成されました。変数を設定してモデルを再作成し、新しいエンドポイント構成を作成し、エンドポイントを更新してください。イメージの再構築は必要ありません。
Bedrock または SageMaker への接続時に発生する TLS または SSL エラー	ネットワーク出口でSSLインスペクションを使用しています。JWT認証パスにCAバンドルを提供するか、インスペクションCAをアプライアンスにインストールします。
NERクレデンシャルルックアップはコンテナ内では失敗しますが、ホスト上では機能します。	EC2 インスタンスメタデータのホップ制限を 2 に引き上げて、コンテナ化されたサービスがメタデータサービスにアクセスできるようにします。

Security Notes

AWS Bedrockはモデル呼び出しロギングをサポートしており、AWSアカウントで有効にすると、プロンプトとレスポンスの全文がCloudWatch Logs、S3、またはCloudTrailに記録されます。AIファイル分類は検査対象ファイルのコンテンツをBedrockに送信するため、このロギングを有効にすると、その機密コンテンツがログ出力先にキャプチャされます。Netskopeは、AIファイル分類にDLPoDアプライアンスが使うAWSアカウントのモデル呼び出しロギングを無効にすることを推奨します。監査のために有効にする必要がある場合は、ログ出力先を機密データストアとして扱い、それに応じて保護してください。この設定はアプライアンス上ではなく、AWSアカウント上で構成されるため、決定と露出のリスクはAWSアカウントの所有者に帰属します。このガイダンスはAIファイル分類にのみ適用されます。NERは独自のSageMakerエンドポイントで実行されるため、Bedrock呼び出しロギングの影響を受けません。

アプライアンスは、AWSキー、APIキー、JWTクライアントシークレットなど、すべてのクレデンシャル値を保存する前に、テナント転送キーで暗号化します。アプライアンスが転送キーサービスにアクセスできない場合、configureコマンドは暗号化されていないクレデンシャルを保存せずに何もしません。可能な場合は、保存されたキーの代わりにEC2インスタンスロールを使用して、アプライアンスに必要な最小限の権限のみを付与してください。

Quick Command Reference

request dlp-llm configure        # AI File Classification (Bedrock)
request dlp-llm-ner configure    # NER and genomic detection (SageMaker)