Migration Assist vous aide à déplacer vos instances de protection des données API classiques, ainsi que leurs politiques correspondantes, vers la protection des données API de nouvelle génération. Il automatise la traduction et la configuration des politiques en arrière-plan, afin que vous n'ayez pas à recréer chaque politique manuellement avant que Classic API Data Protection n'atteigne end-of-life sur June 1, 2027.
Conditions préalables
Avant de commencer une migration avec Migration Assist, assurez-vous de disposer des éléments suivants :
-
Une instance de protection des données de l'API classique existante avec des politiques actives.
-
Au moins une application dans cette instance qui est prise en charge dans la protection des données API de nouvelle génération. Les instances qui utilisent uniquement des applications non prises en charge, telles que Workplace by Meta ou Slack Team, ne peuvent pas être migrées.
-
Avant de migrer, comprenez les nuances de Next Generation API Protection des données.
Portée de Migration Assist
Migration Assist ne migre que les politiques en cours. Il est utile de comprendre exactement ce que cela signifie : quelles applications sont couvertes, ce que vous indique le statut d'une politique migrée et ce qui ne fait jamais partie de la migration.
Migration statuses. Après la migration, chaque politique est signalée avec l’un des statuts suivants :
| Statut | Qu'est-ce que cela signifie ? | Que devez-vous faire ? |
|---|---|---|
| Migrated | La politique a été migrée automatiquement. | None. |
| Action requise | Next Generation prend en charge l'intention, mais vous devez recréer ou ajuster la politique manuellement. | Recréez la politique dans Next Generation. |
| Non disponible dans Next Gen | La nouvelle génération ne dispose d'aucun équivalent pour cette politique à ce jour. | Configurez un contrôle alternatif si vous avez toujours besoin de cette protection. |
| Netskope error | Un problème interne a empêché la migration. | Contactez le service d'assistance de Netskope. |
La plupart des politiques nécessitant une action entrent dans la catégorie « Action requise » — par exemple, une action telle que Révoquer qui correspond à plus d'une option de nouvelle génération, ou une politique faisant référence à un profil de mise en quarantaine ou de conservation légale qui n'existe pas encore dans la nouvelle génération. Un petit nombre de politiques sont « Non disponibles dans Next Gen » et ne peuvent pas être traduites du tout — par exemple, les politiques utilisant l'action Chiffrer ou RMS (Azure Rights Management), ou les politiques de gouvernance des applications connectées Google Workspace. Votre rapport de migration téléchargeable indique le statut exact et l'étape suivante pour chaque politique de votre instance.
Application scope. Migration Assist prend en charge 13 applications classiques : Box, Dropbox, Egnyte, GitHub, Google Drive, Microsoft Teams, OneDrive, Outlook, Salesforce, ServiceNow, SharePoint, Slack Enterprise et Workday. Les applications suivantes ne sont pas prises en charge, pour les raisons indiquées :
| Application | Statut |
|---|---|
| AWS, Azure, Google Cloud | Applications SaaS non protégées par API Data Protection. La sécurité des fournisseurs de cloud est couverte par un produit Netskope distinct ; contactez votre équipe de compte. |
| Lieu de travail de Meta | Obsolète selon le fournisseur. Aucun chemin de migration vers Next Generation. |
| Slack Team (non-Enterprise) | Non pris en charge. Utilisez Slack Enterprise, qui est pris en charge. |
Never part of the migration. Les éléments suivants ne sont pas pris en charge par l'assistant de migration et doivent être traités manuellement dans la nouvelle génération :
-
Configuration de la protection contre les malwares et les menaces.
-
Configuration de la destination pour l'informatique légale.
-
Les profils de quarantaine, de détention légale et d'IRM — les profils eux-mêmes doivent exister dans la nouvelle génération avant qu'une politique dépendante puisse être migrée.
-
Analyse rétroactive — Migration Assist ne prend pas en charge les stratégies d’analyse rétroactive ; configurez-les manuellement dans Next Generation.
-
Les identifiants d'instance, les autorisations OAuth et les permissions API — ceux-ci doivent être configurés indépendamment dans la nouvelle génération.
-
Historique des alertes, historique des incidents et historique d'audit.
-
Paramètres au niveau du locataire, tels que les notifications par défaut et la rétention.
Démarrer la migration
Migration Assist s'exécute en trois phases : vous initiez la migration, Netskope migre vos politiques en arrière-plan et vous examinez les résultats avant le basculement. Cette section explique comment démarrer le processus.
Pour démarrer une migration :
-
Connectez-vous à votre locataire Netskope. Une fenêtre contextuelle vous informe que la protection des données de l'API classique arrive en fin de vie.
-
Cliquez sur Create Next Gen Instance dans la fenêtre contextuelle. Si vous fermez la fenêtre contextuelle, vous pourrez lancer la migration plus tard depuis Settings > API-enabled Protection > Configure App Access > Next Gen, puis cliquer sur Set Up CASB API Instance.
-
Select l'application et l'instance Classic que vous souhaitez lier à la New instance Next Generation.
Pour la configuration spécifique à une application lors de la mise en place d'une instance, consultez Next Generation API Data Protection Platform.
-
Cliquez sur Grant Access.
La protection des données API de nouvelle génération établit ensuite un inventaire de l'instance, puis traduit et configure automatiquement ses politiques dans la nouvelle génération. Vous n'avez aucune action à entreprendre pendant l'exécution de ce processus.
Examiner les résultats de la migration
Une fois la migration en arrière-plan terminée, Netskope vous en informe sur la page d'instance Next Generation afin que vous puissiez examiner ce qui s'est passé avant d'effectuer la transition depuis la version classique.
Pour examiner les résultats :
-
Naviguez jusqu'à Settings > API-enabled Protection > Configure App Access > Next Gen.
-
Identifiez l'application SaaS que vous avez migrée. Cliquez sur Download Report pour obtenir un PDF répertoriant chaque politique et son résultat de migration, y compris des conseils pour toute politique nécessitant une action manuelle.
-
Examinez chaque politique migrée dans Next Generation, puis activez-la.
Pour activer la politique Next Generation API de protection des données, accédez à Policies > API Data Protection > SaaS > Next Gen.
-
Désactivez la politique correspondante dans votre plateforme classique.
Pour désactiver la protection des données de l'API classique, accédez à Policies > API Data Protection > SaaS > Classic.
Activez la politique de nouvelle génération avant de désactiver la politique Classic, afin qu'il n'y ait aucune interruption de couverture pendant la transition.Ne supprimez pas votre instance Classic immédiatement après la migration. Attendez six mois ou la durée de votre période de rétention des incidents. Consultez votre représentant commercial Netskope pour confirmer la période de rétention exacte. Pendant cette période, vous pouvez gérer les incidents et travailler avec les fichiers en quarantaine. -
Après la période de rétention, supprimez l'instance classic. Pour ce faire, accédez à Settings > Configure App Access > Classic, sélectionnez l'application SaaS, puis cliquez sur l'icône Remove Instance pour supprimer l'instance d'application.
