Connecteurs d’applications en ligne - Documentation technique Netskope

Netskope prend en charge la sécurité des données en temps réel et la protection contre les menaces pour le trafic des applications Web et Cloud grâce aux connecteurs d'applications en ligne de Netskope pour la sécurité en temps réel. Les connecteurs d'applications en ligne fournissent une visibilité sur les activités des utilisateurs en fonction de l'interaction de l'utilisateur final avec les applications en nuage. En outre, pour les applications en nuage qui ont des versions Enterprise et Commerciales, l'instance ou les comptes auxquels les utilisateurs accèdent sont également identifiés à travers les activités effectuées. L'administrateur peut traduire cette visibilité en application grâce à des politiques en temps réel.

Types de connecteurs d'application en ligne

Netskope propose plusieurs connecteurs d'applications, définis ci-dessous.

App-specific Connectors: Développé sur la base d'une analyse détaillée du trafic pour les différents cas d'utilisation de l'application. Ces connecteurs font partie du paquet de contenu déployé dans tous les centres de données. Netskope fournit des connecteurs spécifiques pour les principales applications Cloud de l'entreprise.

Universal Connector (UC): Le Connecteur Universel de Netskope est développé selon une approche heuristique pour identifier les activités. Les activités suivantes sont prises en charge pour le Connecteur Universel : Tentative de connexion, Connexion réussie, Connexion échouée, Déconnexion, Formpost (avec DLP (Prévention des pertes de données) uniquement), Téléversement, et Téléchargement. Pour la longue traîne des applications cloud, Netskope utilise le Universal App Connector pour fournir best-effort détection d’activité des activités spécifiées. Par défaut, seule une partie des applications UC apparaît dans la politique Temps Réel. Les applications UC marquées uniquement comme Découverte (et qui n’apparaissent pas dans la politique en temps réel) dans CCI nécessiteront une « Définition d’application » personnalisée. Consultez le sujet Définitions d’applications pour plus de détails afin de créer une définition d’application.

Web Universal Connector: Le connecteur universel Web de Netskope est également développé sur la base d'une approche heuristique pour identifier les activités. Cela s'apparente à un connecteur universel, mais avec une prise en charge des activités plus limitée. Les activités prises en charge incluent : Parcourir, Tentative de connexion, Formpost (avec DLP (Prévention des pertes de données) uniquement), Télécharger et Télécharger. Le connecteur universel Web fournit une détection d'activité best-effort pour les activités spécifiques au trafic non lié aux applications ou au Web.

On parle d'activité formpost lorsqu'un client HTTP envoie du HTML dont le type de contenu est défini sur "multipart/form-données" ou "application/octet-stream". Il s'agit d'une requête HTTP POST envoyée avec le corps de la requête spécifiquement formaté comme une série de "parties", séparées par des limites MIME

Custom Connectors: Netskope propose une option pour développer des connecteurs personnalisés via l’interface de votre compte en fournissant les définitions de trafic de l’application. Les définitions de trafic peuvent être enregistrées à l’aide d’un outil d’extension de navigateur Chrome dans un fichier JSON. Ce fichier JSON, qui contient les activités de l’application pour la cartographie du trafic et des informations supplémentaires, peut être chargé via l’interface de votre compte pour créer un connecteur personnalisé. La définition du connecteur personnalisé se fait via la configuration de l’application personnalisée workflow. Pour en savoir plus : Créer une définition d’application cloud

Flux de travail du connecteur d'applications en ligne

Lorsque le trafic d'une application en nuage passe par Netskope, les événements d'application sont générés en fonction de la correspondance du connecteur approprié, comme indiqué dans le diagramme workflow ci-dessous.

Une activité qui n'apparaît pas dans une politique mais qui est capturée dans les événements informatiques de Skope est la "navigation", qui est la toute première activité de la transaction initiale lors de l'accès à un domaine/URL. Cette activité n'est pas capturée en tant qu'événement à moins que le domaine/URL/application (dont les activités sont définies sur "Any") ne soit bloqué par une politique.

Catégorisation d'applications et catégorisation de sites web pour la mise en correspondance des politiques

Pour le trafic correspondant à des domaines qui ont été mis en correspondance avec une application répertoriée sur CCI, l'"Union" de la catégorie App + Web pertinente est utilisée pour la mise en correspondance des politiques. L'exemple de l'image ci-dessous montre la catégorisation pour box.com avec des correspondances possibles de catégories pour box.com pour les éléments suivants :

Stockage dans le nuage (catégorie Box App dans CCI)
Collaboration (catégorie web box.com)
Technologie (catégorie web box.com)

La catégorisation pour la définition des applications personnalisées n'est pas prise en charge.

Pour les domaines qui n’appartiennent à aucune application dans CCI, le trafic est traité par le connecteur Web universel et le « Web Category” » pertinent est applicable. L'exemple dans l'image ci-dessous montre la catégorie Web pour flipkart.com qui n'appartient à aucune application dans CCI.

Catégories personnalisées

En plus des catégories prédéfinies, si une catégorie personnalisée est définie pour l'un des domaines / URL, la catégorie personnalisée est également incluse dans le "Union of Categories” " lors de la correspondance des politiques.

Comprendre les événements de trafic d'application à application

Chaque fois qu'un utilisateur accède à une application, un trafic de fond peut être généré vers d'autres applications. Dans l'exemple ci-dessous, WeTransfer utilise S3 pour le stockage et y télécharge des fichiers.

Ce trafic d'application à application se traduit par un trafic http avec un champ referrer dans l'événement. Dans ce cas, l'application Background App (Telemetry App) Amazon S3 est remplacée par l'application “Referrer” (WeTransfer) lors de l'événement.

Configuration de la politique

Netskope permet de créer des politiques basées sur l’application principale ou « Référent » ou sa Catégorie. Une politique de catégorie / personnalisée peut être utilisée pour bloquer le trafic en arrière-plan.

En cas d’échange d’applications, les politiques par catégorie ne regardent que la catégorie de l’application Referrer. La catégorie de l’application Background (Télémétrie) n’est pas utilisée pour la correspondance de politiques dans ce cas.

Comprendre les domaines partagés de Google Apps

Le Netskope Inline Connector DLP (Prévention des pertes de données) pour les applications Google Suite est limité au contenu copié-collé d'une longueur minimale de 50 caractères. Les contenus en temps réel et les contenus collés en dessous de 50 caractères ne seront pas traités par la Prévention des pertes de données (DLP).

Google utilise shared domains pour son application Google Drive, qui est également utilisée pour d'autres services Google en attribuant différents sous-domaines. Cette utilisation partagée peut poser problème lors de la mise en œuvre d'une stratégie de blocage pour Google Drive.

La façon dont Fully Qualified Domain Names (FQDNs) est utilisé pour détecter le trafic spécifique à une application pose un problème majeur. Par exemple, Google Drive utilise généralement le FQDN clients6.google.com pour la détection des activités. Cependant, le même FQDN, lorsqu'il est complété par un sous-domaine - tel que testing.clients6.google.com - peut être utilisé par d'autres services en arrière-plan ou par des applications Google non liées.

La politique de pilotage de Netskope associe tout le trafic vers clients6.google.com sous l'application Google Drive, tout sous-domaine supplémentaire (par exemple, testing.clients6.google.com). sont également considérés comme du trafic Google Drive. Dans cet exemple, les sous-domaines n'appartiennent pas clairement à une application spécifique, ce qui peut entraîner des problèmes de classification.

Si vous avez des règles de blocage pour Google Drive, la meilleure pratique consiste à ajouter les domaines suivants dans votre liste d'autorisations pour éviter d'être bloqué avec ce type de règles.

clients6.google.com
googusercontent.com
googleapis.com

Comprendre le mode CASB et le pilotage du domaine principal de Google

Si votre version du locataire Netskope utilise le mode CASB, conçu pour les clients disposant d'une licence Cloud-Inline qui n'inclut pas les fonctionnalités SWG, seules les applications SaaS peuvent être dirigées vers Netskope. La décision de diriger le trafic est déterminée par le domaine d'application spécifique.

Le trafic dirigé vers le domaine www.google.com n’est associé à aucune application SaaS dans la base de données Netskope CCI. Par conséquent, ce trafic ne sera pas dirigé, même si les chemins URI sont utilisés pour cibler des applications spécifiques.

Best Practice

Créez des applications personnalisées et utilisez des connecteurs d'application dédiés prédéfinis. Ainsi, votre trafic est correctement orienté et la détection d'activité fonctionne comme prévu.

Exemple : vous voulez diriger www.google.com avec différents chemins URI liés à différentes applications, ajouter le chemin complet dans l’application personnalisée pour orienter le trafic.

App: Google Translate

URI www.google.com/async/translate