Configuration de la classification de fichiers AI et de la détection d'entités pour DLP (Prévention des pertes de données) à la demande

L'appareil DLP (Prévention des pertes de données) On Demand (DLPoD) prend en charge trois fonctionnalités d'inspection de contenu basées sur l'IA, collectivement appelées DLP-LLM.

Capability	Ce que cela fait	Où l'inférence est exécutée
AI File Classification	Classe un document extrait dans une catégorie de fichier, telle que Plan budgétaire ou Accord bancaire, afin qu'un profil DLP (Prévention des pertes de données) puisse correspondre au type de fichier.	AWS Bedrock (accès géré par Netskope)
AI Entity, NER (Named Entity Recognition)	Extrait des informations d'identification personnelle (PII), telles que les noms, les adresses, les numéros de téléphone et les numéros de sécurité sociale, afin que les règles d'entité DLP (Prévention des pertes de données) puissent les détecter et les masquer.	Un point de terminaison en temps réel SageMaker que vous hébergez dans votre propre compte AWS
AI Entity, Genomic and Human-omic Detection	Extrait des entités biomédicales, telles que les gènes, les protéines et les maladies, des textes scientifiques ou cliniques.	Le même point de terminaison SageMaker que NER, plus AWS Bedrock pour un deuxième chemin génomique

Vous activez ces fonctionnalités à partir de nsshell avec deux commandes indépendantes :

La demande DLP (Prévention des pertes de données)-llm configure met en place la classification de fichiers AI.
request dlp-llm-ner configure configure NER et la détection génomique.

Les deux commandes utilisent des informations d'identification distinctes et ne s'affectent pas mutuellement. Vous pouvez activer l'une sans l'autre.

Pour plus d'informations sur la façon dont les résultats des entités IA apparaissent dans les profils DLP (Prévention des pertes de données), consultez DLP Entity. Pour plus d'informations sur les catégories de fichiers, voir File Classifiers.

L'inférence DLP (Prévention des pertes de données)-LLM s'exécute toujours dans AWS, quel que soit l'endroit où votre appliance DLPoD est hébergée. L'appliance elle-même prend en charge AWS, Azure, GCP et les hyperviseurs sur site (Hyper-V, KVM et VMware), mais vous avez besoin d'un compte AWS pour héberger les backends d'inférence de toute façon. La méthode d'authentification utilisée par l'appliance dépend de son lieu d'exécution.

Plateforme d'hébergement d'appliance DLPoD	Authentification de classification de fichiers AI (Bedrock)	Authentification NER et Genomic (SageMaker)
AWS (EC2)	Rôle IAM (profil d'instance), recommandé ; ou clés AWS	Rôle IAM (profil d'instance), recommandé ; ou clé IAM permanente, STS ou JWT
Azure, GCP ou sur site	Clé API à long terme Bedrock, requise	Jeton web JSON (JWT) via Amazon Cognito, requis

Si votre appliance s'exécute sur AWS EC2, un rôle d'instance EC2 est l'option par défaut et recommandée pour ces deux fonctionnalités. Les identifiants du rôle sont renouvelés automatiquement ; vous n'avez donc aucune clé à gérer ou à renouveler. Si votre appliance s'exécute sur Azure, GCP ou sur site, elle ne dispose pas d'identité AWS native. Par conséquent, elle doit s'authentifier à l'aide d'une clé API à long terme Bedrock pour la classification des fichiers IA et d'un JWT pour la reconnaissance d'entités nommées (NER).

La prise en charge d'Azure ML, Azure AI Foundry, Vertex AI et de l'infrastructure IA privée en tant que backends d'inférence natifs est prévue sur la feuille de route mais n'est pas disponible dans cette version. Les appareils hébergés hors AWS atteignent toujours AWS pour l'inférence.

Prerequisites

Avant de configurer DLP (Prévention des pertes de données)-LLM, vérifiez les éléments suivants :

Votre appliance DLPoD est déployée et entièrement initialisée, sur une version qui inclut le service dlp-llm.
Votre appareil est associé. Le configurateur chiffre les identifiants avec la clé de transit du locataire, qui n'est disponible qu'après l'association.
Votre appliance dispose d'une sortie réseau vers AWS Bedrock et, pour NER, vers votre point de terminaison SageMaker. Si votre sortie utilise l'inspection SSL, consultez la section de dépannage pour l'option de bundle CA.
Vous avez un compte AWS. Bedrock et le point de terminaison SageMaker NER s'exécutent toujours sur AWS, quelle que soit la plateforme d'hébergement de votre appliance.

Pour la classification de fichiers AI, vous avez également besoin d'identifiants AWS que l'appliance peut utiliser pour appeler Bedrock. Pour NER, vous avez également besoin d'un point de terminaison SageMaker en temps réel dans votre compte AWS et d'identifiants permettant à l'appliance de l'invoquer.

Si vous prévoyez de configurer le point de terminaison SageMaker vous-même, vous avez également besoin des outils locaux suivants :

AWS CLI v2
Docker, avec le démon en cours d'exécution
crane, que le script de déploiement NER utilise pour envoyer des images au format manifeste requis par SageMaker
Autorisations IAM pour créer des référentiels ECR, des rôles et des politiques IAM, ainsi que des modèles et des points de terminaison SageMaker

Configuring AI File Classification

La classification des fichiers par IA s'exécute sur AWS Bedrock. Les autorisations IAM dont vous avez besoin dépendent du modèle que vous sélectionnez.

Setting Up AWS IAM for Bedrock

Deux familles de modèles sont disponibles et chacune utilise une politique IAM différente.

google.gemma-4-31b et openai.gpt-5.6-luna fonctionnent sur Bedrock Mantle.
us.amazon.nova-pro-v1:0 et us.amazon.nova-2-lite-v1:0 s'exécutent sur Bedrock standard.

Pour les modèles Bedrock Mantle, attachez une politique qui autorise bedrock-mantle:CreateInference et bedrock-mantle:CallWithBearerToken, limitée au projet Bedrock Mantle par défaut de votre compte.

Pour les modèles Bedrock standard, joignez une politique qui autorise bedrock:InvokeModel et bedrock:InvokeModelWithResponseStream. Les appels de modèles inter-régions sont vérifiés par rapport à deux ressources : le profil d'inférence et le modèle de base sous-jacent. Incluez les deux dans la politique.

Avec Bedrock standard, utilisez le préfixe us. identifiants de modèle de profil d'inférence. Le service Bedrock rejette les IDs de modèle de base sans préfixe pour une utilisation à la demande.

Si votre appliance s'exécute sur AWS EC2, vous pouvez attacher un profil d'instance au lieu d'utiliser des clés statiques. Créez le rôle, attachez la politique Bedrock, créez un profil d'instance et associez-le à votre instance en cours d'exécution à l'aide de l'AWS CLI. Cela ne nécessite pas de redémarrage de l'instance.

Si votre compte AWS est géré sous une limite d'autorisations NSPowerUser, chaque rôle, politique et profil d'instance que vous créez doit inclure le chemin du rôle d'application et la limite d'autorisations requise par votre compte, et le rôle doit porter l'étiquette utilisée par votre compte pour autoriser l'假設 du rôle. Dans ce modèle, les ressources IAM doivent être créées via la CLI ou Terraform, pas la console AWS.

Si votre appareil fonctionne en dehors d'AWS (Azure, GCP ou sur site), générez plutôt une clé API à long terme Bedrock :

Dans la console AWS, accédez à Amazon Bedrock > API Keys.
Sous Long-term API Keys, sélectionnez Generate Long-Term API Key.
Specify an expiration.
Copiez la clé. Vous la saisissez en tant que clé d'identification API dans la commande dlp-llm configure.

Running request dlp-llm configure

Depuis nsshell sur l'appareil DLPoD, exécutez :

nsappliance> request dlp-llm configure

La commande demande les valeurs suivantes. Les valeurs par défaut sont affichées entre parenthèses.

Auth method: aws-keys (par défaut) ou api-key. Choisissez aws-keys si votre appliance s'exécute sur AWS EC2, ou api-key si elle s'exécute en dehors d'AWS.
AWS credentials, en faisant correspondre la méthode d'authentification que vous avez choisie.
Region, la région AWS pour Bedrock. La valeur par défaut est us-west-2.
Daily request limit, service.max_daily_requests. Entrez 0 pour aucune limite. La valeur par défaut est 100 000.
Model, l'un des quatre IDs de modèles pris en charge. La valeur par défaut est google.gemma-4-31b.

Un changement de modèle prend effet lors du prochain redémarrage du service dlp-llm, et non lors d'un rechargement de la configuration.

Si vous laissez les champs d'identification AWS vides, la configuration est toujours enregistrée, mais la classification des fichiers par IA ne s'authentifie pas tant que vous n'avez pas fourni des identifiants valides ou, sur EC2, un rôle d'instance avec la politique appropriée. La commande vous avertit lorsque cela se produit.

Configuring NER and Genomic Entity Detection

La détection NER et génomique s’exécute sur un endpoint temps réel SageMaker dans votre propre compte AWS. Vous hébergez le endpoint et l'appareil l'invoque. Le contenu envoyé pour inspection ne quitte jamais votre environnement AWS.

Deploying the SageMaker Endpoint

Netskope fournit une image de conteneur avec les modèles NER et génomiques intégrés, livrée sous forme de tarball d'image Docker compressée ou de référence de pull vers un registre hébergé par Netskope.

Confirmez les éléments suivants avant de déployer :

Requirement	Detail
Compte AWS et région	Toute région où les points de terminaison en temps réel GPU SageMaker sont disponibles
Type d’instance	ml.g5.xlarge recommandé pour une utilisation en production
Quota de service	Vérifiez que votre compte dispose d'un quota pour l'utilisation du point de terminaison ml.g5.xlarge
Amazon ECR	Un dépôt privé dans la même région pour conserver l'image
IAM	Autorisations pour créer des dépôts ECR, un rôle d'exécution SageMaker, ainsi que des modèles et des points de terminaison SageMaker

Netskope fournit un script de déploiement, deploy_ner_sagemaker.sh, qui automatise la configuration complète : il charge l'image, la transmet à ECR, crée le rôle d'exécution SageMaker s'il n'existe pas, crée le modèle, la configuration de point de terminaison et le point de terminaison, et valide les familles de modèles PII et génomiques avec un appel de test. Exécutez-le avec votre archive tar, votre ID de compte AWS et votre région :

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

Si vous effectuez le déploiement manuellement au lieu d'utiliser le script, vous devez définir la variable d'environnement du conteneur NER_MODEL_TYPE=xlmr lorsque vous créez le modèle SageMaker. Sans cela, le point de terminaison ne parvient pas à démarrer et n'atteint jamais l'état En service. Cette exigence s'applique aux images 26.8.x ; elle n'affecte pas le modèle génomique.

Pour valider un point de terminaison en cours d'exécution sans redéployer, exécutez le script avec –validate-only.

Setting Up NER Authentication

Vous choisissez la manière dont l'appareil s'authentifie auprès de votre point de terminaison SageMaker. Quatre types d'informations d'identification sont disponibles.

Type	Quand utiliser	Ce qu'il fournit
A, clé IAM permanente	Option basée sur une clé simplifiée	Une clé d'accès AWS à longue durée de vie
B, JWT via Amazon Cognito	Requis pour les appareils hébergés en dehors d'AWS	Jetons à courte durée de vie créés à partir d'un secret client Cognito à longue durée de vie ; aucune clé AWS permanente sur l'appliance
C, identifiants temporaires STS	Avancé ; seulement si vous faites déjà pivoter des informations d'identification à courte durée de vie dans l'appliance	Identifiants AWS temporaires que vous devez actualiser avant leur expiration
D, rôle d'instance EC2	Recommandé si votre appareil s'exécute sur EC2	Identifiants temporaires et à rotation automatique issus du rôle de l'instance ; rien n'est stocké sur l'appareil

Quel que soit le type choisi, accordez uniquement l'autorisation minimale, sagemaker:InvokeEndpoint, limitée au nom de ressource Amazon (ARN) de votre point de terminaison.

If your appliance runs on AWS EC2 (Type D, recommended): attachez un rôle IAM à l'instance EC2 de l'appareil avec l'autorisation d'invocation ci-dessus. Si l'instance possède déjà un rôle, ajoutez-y l'autorisation au lieu de remplacer le rôle, car une instance ne peut détenir qu'un seul rôle. Lorsque vous exécutez la commande dlp-llm-ner configure, laissez les champs d'identification AWS vides. L'appareil utilise alors automatiquement le rôle d'instance. Si le service DLP (Prévention des pertes de données)-llm est déjà en cours d'exécution, redémarrez-le pour qu'il prenne en compte le rôle.

If your appliance runs off AWS (Type B, required): placez votre point de terminaison SageMaker devant Amazon API Gateway et un autorisateur Cognito, de sorte que l'appliance détienne un secret client Cognito à longue durée de vie au lieu d'une clé d'accès AWS. En résumé :

Créez un pool d'utilisateurs, un domaine, un serveur de ressources et un périmètre Cognito.
Créez un client d'application de machine à machine, qui génère un ID client et un secret client.
Créez un rôle IAM qui autorise API Gateway à appeler votre point de terminaison SageMaker.
Créez une API REST API Gateway avec une méthode POST, protégée par l'autorisateur Cognito, qui s'intègre à votre point de terminaison SageMaker.
Déployez l'API et notez son URL.

Vous saisissez ensuite les valeurs suivantes dans la requête dlp-llm-ner configure :

Field	Value
client_id	Depuis le client de l'application que vous avez créé
client_secret	Depuis le client de l'application que vous avez créé
token_url	Votre point de terminaison de jeton OAuth de domaine Cognito
api_url	Votre URL de passerelle API déployée
scope	Votre périmètre de serveur de ressources Cognito, par exemple predict/Sagemaker.invoke

Pour faire pivoter les informations d'identification, régénérez le secret client de l'application dans Cognito, puis mettez à jour client_secret sur l'appareil. L'appareil génère automatiquement de New jetons à courte durée de vie et ne nécessite pas de gestion manuelle des jetons.

Running request dlp-llm-ner configure

Depuis nsshell sur l'appareil DLPoD, exécutez :

nsappliance> request dlp-llm-ner configure

La commande demande les valeurs suivantes. Les valeurs par défaut sont affichées entre parenthèses.

Auth method: aws-keys (par défaut), api-key ou jwt. Choisissez en fonction du type d'informations d'identification que vous avez configuré ci-dessus.
Credentials, en faisant correspondre la méthode d'authentification que vous avez choisie. Pour une clé IAM permanente ou un rôle d'instance EC2, il s'agit d'un ID de clé d'accès AWS et d'un secret (laissez les deux champs vides pour utiliser un rôle d'instance). Pour JWT, il s'agit de votre ID client, de votre secret client, de votre URL de jeton, de votre URL d'API et de votre champ d'application.
Region, la région AWS de votre point de terminaison SageMaker. La valeur par défaut est us-west-2.
Daily request limit, service.max_daily_requests. Entrez 0 pour aucune limite. La valeur par défaut est 100 000.

Cette commande ne demande pas de sélection de modèle. Le modèle NER fait partie de votre endpoint SageMaker, pas d'un modèle Bedrock.

Verifying and Troubleshooting

Pour vérifier l'état général de l'appareil et confirmer quels services sont en cours d'exécution, utilisez :

nsappliance> request status health
nsappliance> request status all

Pour confirmer la méthode d'authentification utilisée par DLP-LLM, vérifiez les journaux du service dlp-llm pour trouver un message indiquant la méthode active, telle qu'une clé permanente IAM, une clé temporaire, JWT ou un rôle d'instance EC2.

Le tableau suivant répertorie les problèmes courants.

Symptom	Cause probable et solution
La configuration échoue avec une erreur de clé de transit	Votre appliance n'est pas encore liée ou la synchronisation de configuration n'est pas prête. Attendez, puis exécutez à nouveau la commande configure.
Les identifiants NER sont rejetés	La clé d'accès ou le secret est incorrect, ou ne dispose pas des autorisations nécessaires pour vérifier l'identité AWS. Corrigez les informations d'identification et réessayez.
NER reste désactivé sans erreur d’identité native	Vous avez laissé les champs des informations d'identification vides pour utiliser un rôle d'instance EC2, mais aucun rôle n'est attaché à l'instance. Attachez un rôle, puis redémarrez le service.
La configuration NER contient des champs JWT et IAM	Réexécutez la demande DLP (Prévention des pertes de données)-llm-ner configure, qui efface les champs obsolètes avant d'enregistrer le nouveau style, plutôt que de modifier manuellement la configuration.
La classification des fichiers par IA renvoie une erreur d'accès refusé	Votre politique IAM ne correspond pas au modèle sélectionné. Confirmez que vous avez utilisé la politique Bedrock Mantle pour les modèles Mantle, ou la politique Bedrock standard pour les deux modèles Nova.
La classification de fichiers par IA échoue après le changement de modèle	Le New modèle n'est pas provisionné pour votre compte AWS dans Bedrock. Confirmez le provisionnement et notez qu'une modification du modèle prendra effet au prochain redémarrage du service.
Le point de terminaison SageMaker reste dans un état Création ou Mise à jour	Le modèle a été créé sans la variable d'environnement NER_MODEL_TYPE=xlmr. Recréez le modèle avec la variable définie, créez une New configuration de point de terminaison et mettez à jour le point de terminaison. Aucune reconstruction d'image n'est nécessaire.
Erreurs TLS ou SSL lors de l'accès à Bedrock ou SageMaker	Votre sortie réseau utilise l'inspection SSL. Fournissez un bundle CA pour le chemin d'authentification JWT, ou installez l'AC d'inspection sur l'appareil.
La recherche d'identifiants NER échoue à l'intérieur d'un conteneur mais fonctionne sur l'hôte	Augmentez la limite de saut de métadonnées de l'instance EC2 à 2, afin de permettre au service conteneurisé d'atteindre le service de métadonnées.

Security Notes

AWS Bedrock prend en charge la journalisation des appels de modèle, qui enregistre le texte complet des invites et des réponses dans CloudWatch Logs, S3 ou CloudTrail si vous l'activez dans votre compte AWS. Comme la classification de fichiers AI envoie le contenu du fichier inspecté à Bedrock, l'activation de cette journalisation capture ce contenu sensible dans vos destinations de journal. Netskope recommande de laisser la journalisation des appels de modèle désactivée pour le compte AWS que votre appliance DLPoD utilise pour la classification de fichiers AI. Si vous devez l'activer pour l'audit, traitez les destinations des journaux comme des magasins de données sensibles et sécurisez-les en conséquence. Ce paramètre est configuré dans votre compte AWS, pas sur l'appliance, la décision et le risque d'exposition appartiennent donc au propriétaire du compte AWS. Ces conseils ne s'appliquent qu'à la classification de fichiers AI ; la NER s'exécute sur votre propre point de terminaison SageMaker et n'est pas affectée par la journalisation des appels Bedrock.

L'appliance chiffre toutes les valeurs d'identification, y compris les clés AWS, les clés API et les secrets client JWT, au repos avec la clé de transit du locataire avant de les enregistrer. Si l'appliance ne peut pas atteindre le service de clé de transit, la commande configure n'enregistre rien au lieu de stocker une information d'identification non chiffrée. Dans la mesure du possible, utilisez un rôle d'instance EC2 au lieu de clés stockées, et n'accordez que le minimum d'autorisations dont votre appliance a besoin.

Quick Command Reference

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