Google introduit des frais basés sur l’utilisation pour les appels API de Google Workspace. Pour protéger votre analyse Google Workspace contre toute limitation de quotas partagés et vous donner un contrôle total sur votre propre utilisation de l’API, Netskope fait passer la prochaine génération de protection des données de l’API pour les applications Google — Google Drive, Google Calendar et Gmail — vers un modèle Bring Your Own Project (BYOP). Dans ce modèle, vous créez et possédez le compte projet et service Google Cloud Platform (GCP) utilisé pour votre intégration Google Workspace, au lieu de dépendre d’un compte projet et service que Netskope possède et partage entre les clients.
Cette page explique ce qui change, pourquoi, et où aller ensuite. Il ne contient pas d’étapes de configuration — pour celles-ci, voir les liens ci-dessous.
Qu’est-ce qui change et pourquoi ?
À compter de la mi-décembre 2026, Google facturera au propriétaire d'un projet Google Cloud les appels d'API Workspace dépassant le seuil de l'offre gratuite. Jusqu'à présent, tous les clients de Netskope partageaient un seul projet GCP et un seul compte de service appartenant à Netskope pour ces appels d'API, ce qui signifie que Google attribue tout le trafic d'API généré par les clients à Netskope.
Sous BYOP, vous créez et possédez le projet GCP et le compte de service utilisés pour l’intégration de votre protection Google Next Generation API. Cela signifie :
-
Votre quota d’API est dédié à votre organisation. Vous n’êtes pas affecté par l’utilisation des autres clients de Netskope.
-
Si vous avez besoin de plus de quotas, vous pouvez le demander directement à Google pour votre propre projet.
-
Vous avez une visibilité complète sur votre propre utilisation de l’API Google et sur les coûts associés.
Que dois-je faire ?
L’action requise dépend de la configuration actuelle de votre application Google dans Netskope. Trouvez votre scénario ci-dessous.
Utilisez cet article pour trouver les étapes de migration pour la configuration spécifique de votre application Google dans Next Generation API données Protection. Cela s’applique à Google Drive, Google Agenda et Gmail. Trouvez ci-dessous le scénario qui correspond à votre configuration actuelle.
| Votre installation actuelle | Action requise |
|---|---|
| Protection des données API classique uniquement. | Passez à la protection des données API de nouvelle génération et intégrez l’intégration BYOP complète. |
| Protection des données API de nouvelle génération (instance créée avant le 10 août 2026). | Changez votre instance existante pour votre propre projet GCP. |
| À la fois les instances de protection des données Classic et Next Generation API créées avant le 10 août 2026). | Complétez les deux actions ci-dessus. |
| New intégration client sur Next Generation API données Protection. | Aucune migration nécessaire. Suivez la configuration standard BYOP lors de l’intégration. |
Protection des données API classique uniquement
La protection des données API classique ne prend pas en charge le BYOP. Pour garder la protection de votre Google Workspace ininterrompue, passez à la protection de données API Next Generation via le flux d’intégration New BYOP.
-
Créez votre projet GCP et votre compte de service.
-
Accordez à votre compte de service les champs de délégation requis à l’échelle du domaine.
-
Ajoutez une instance New Next Generation API données Protection pour votre application Google en utilisant votre propre compte de service.
-
Confirmez que l’instance New Next Generation est active et analyse comme prévu.
-
Recréez vos politiques Classic dans l’interface Next Generation. Les politiques classiques ne migrent pas automatiquement.
-
Supprimez l’instance de protection des données Classic API pour l’application Google.
Protection des données de prochaine génération API uniquement (instance créée avant le 10 août 2026)
Votre instance Next Generation existante créée avant le 10 août 2026 utilise actuellement le compte de service partagé de Netskope. Changez-le vers votre propre compte de service pour le garder dans la protection des données de l’API Next Generation. Cela préserve vos politiques et configurations existantes.
-
Créez votre projet GCP et votre compte de service.
-
Accordez à votre compte de service les champs de délégation requis à l’échelle du domaine.
-
Dans l’interface utilisateur du locataire Netskope, allez dans Settings > Configure App Access > Next Gen > CASB API, localisez votre instance existante, puis cliquez sur Edit.
-
Écrasez les champs de Service Account Email préremplis et Service Account Private Key (et Project ID pour Gmail) avec les valeurs de votre propre compte de service, puis enregistrez/accordez à nouveau.
-
Confirmez que le changement a été effectué avec succès et que vos politiques restent inchangées.
Protection des données API classique et nouvelle génération (instance créée avant le 10 août 2026)
-
Créez votre projet GCP et votre compte de service. Vous pouvez réutiliser le même projet entre applications, tant que les API requises sont activées pour chacune.
-
Mettez à jour votre instance Classic vers Next Generation en utilisant le flux d’intégration BYOP (voir ci-dessus).
-
Recréez vos politiques Classic, confirmez que l’instance New est active, puis supprimez l’instance Classic.
-
Changez votre instance Next Generation existante en utilisant Éditer (voir ci-dessus).
New Intégration des clients sur la protection des données API de nouvelle génération
Aucune action spéciale de migration n’est nécessaire. Suivez les étapes de l’article de configuration de votre application Google.
New Documentation d’intégration
Vous pouvez retrouver les étapes d’intégration New documentées ici :
Frequently asked questions
Non. Passer une instance existante à votre propre projet GCP ne met à jour que les identifiants du compte de service sous-jacents. Toutes vos politiques, règles et configurations existantes sont préservées.
Oui. BYOP s'applique à l'ensemble des licences Google Workspace. Ce n’est pas limité à une édition spécifique.
Si votre instance d’application Google utilise toujours le compte de service partagé de Netskope après la date limite, vous pourriez constater une dégradation des performances de la protection des données de l’API de nouvelle génération en raison des limites de taux imposées par Google. Netskope ne peut pas garantir la performance de l’API pour les instances qui n’ont pas migré.
L’utilisation de la plupart des organisations reste largement inférieure au niveau gratuit publié par Google pour les API Workspace. Pour connaître les chiffres d’utilisation spécifiques de votre locataire, contactez l’équipe Netskope chargée de votre compte.
Pour connaître les limites et les quotas d’API actuels de chaque application Google, consultez :
– Limites de l’API Gmail
– Limites de l’API Google Agenda
– Limites de l’API Google Drive
D’après les informations publiées par Google, l’utilisation de la plupart des organisations reste dans les limites du niveau gratuit, et seules certaines organisations les dépassent. Google n’ayant pas encore annoncé de tarification pour l’utilisation au-delà du niveau gratuit, Netskope ne peut pas fournir d’estimation des coûts pour les organisations qui le dépassent. Vous pouvez surveiller l’utilisation de votre API dans la console GCP sous APIs & Services > Dashboard.
Oui, pour la protection de Google Workspace. Cependant, vous configurez vos politiques dans l’interface Next Generation — vos politiques Classic ne migrent pas automatiquement. Contactez votre représentant commercial Netskope ou votre support pour obtenir de l’aide lors de la migration des politiques.
Oui. Vous pouvez créer un seul projet GCP et utiliser des comptes de service séparés (ou le même, lorsque les périmètres le permettent) sur vos instances Google Drive, Google Agenda et Gmail, tant que vous activez les API nécessaires pour chacun dans ce projet.
Chaque instance d’application Google dans Netskope que vous réattribuez devra une délégation à l’échelle du domaine autorisée dans la console d’administration correspondante de Google Workspace. Vous pouvez utiliser le même projet GCP et le même compte de service pour toutes les instances.
Google Workspace ne prend pas en charge la liste blanche d’adresses IP ni les contrôles de service VPC pour les comptes de service qui utilisent la délégation à l’échelle du domaine. La délégation à l’échelle du domaine s’authentifie via le point de terminaison de jeton OAuth 2.0 partagé de Google (oauth2.googleapis.com/token), qui n’est pas limité à un seul projet ou à une seule ressource GCP. Ni une restriction basée sur les IP ni un périmètre de contrôles de service VPC ne peuvent filtrer ces appels par réseau ou par identité d’appelant, de sorte que vous ne pouvez pas limiter cet échange de jetons aux seules adresses IP de Netskope.
Si vous devez séparément autoriser le trafic sortant de Netskope sur votre propre pare-feu ou périmètre Cloud, consultez Plages d’adresses IP NewEdge pour l’établissement d’une liste blanche pour connaître les plages d’adresses IP à utiliser pour la région de votre locataire.
Pour limiter ce que ce compte de service peut faire à la place, utilisez les contrôles suivants :
– Remove IAM roles from the service account. Il doit uniquement exister en tant qu’identité pour la délégation Workspace. Ne lui attribuez pas de rôles d’éditeur, de propriétaire ou de lecteur dans votre projet GCP. Gmail fait exception : son compte de service a besoin du rôle d’administrateur Pub/Sub, et d’aucun autre.
– Grant only the required OAuth scopes. Dans le cadre de la délégation à l’échelle du domaine, n’accordez que les portées répertoriées sous Grant Scopes to the Service Account dans l’article Configurer de votre application Google.
– Enable only the required APIs. Activez uniquement les API répertoriées sous Enable Google APIs dans l’article Configurer de votre application Google.
Secure the private key:
– Stockez la clé JSON téléchargée dans un gestionnaire de secrets (par exemple, Google Secret Manager ou le coffre-fort existant de votre organisation) plutôt que sur un lecteur partagé, dans un e-mail ou dans un système de contrôle de version.
– Limitez les administrateurs pouvant accéder au fichier de clé.
– Faites pivoter la clé périodiquement. Générez une nouvelle clé dans GCP, puis cliquez sur Edit sur votre instance dans l'interface utilisateur de Netskope et mettez à jour le champ Service Account Private Key pour l'appliquer.
Monitor activity:
– Dans Google Cloud, examinez Cloud Audit Logs pour ce compte de service sous IAM & Admin > Audit Logs dans votre projet GCP. Les journaux d'activité des administrateurs, qui enregistrent la création des comptes de service et des clés, sont activés par défaut.
– Dans la console d'administration Google Workspace, examinez le journal d'audit Token sous Reporting > Audit and investigation > Token pour consulter l'activité du jeton OAuth de ce compte de service, ainsi que le journal d'audit Admin pour afficher les modifications apportées à son attribution de délégation à l'échelle du domaine.
Contactez le support Netskope ou adressez-vous à votre représentant commercial Netskope pour une session de migration guidée.