DLP (Prévention des pertes de données)/TSS Intégration avec le RBI
Lorsque cette fonction est activée, les limitations suivantes peuvent apparaître.
Limites :
- La politique basée sur les en-têtes personnalisés dans les requêtes HTTP ne s'appliquera qu'à l'URL correspondant à la politique d'isolement (requête initiale).
- Les politiques basées sur les en-têtes pour le trafic isolé s'appliquent aux en-têtes envoyés/reçus par le moteur du navigateur distant, et non par le périphérique de l'utilisateur.
- De même, la politique basée sur les attributs du périphérique dans la requête HTTP ne s'appliquera qu'à l'URL correspondant à la politique d'isolement (requête initiale).
La correspondance des politiques pour le trafic isolé prend en charge la plupart des attributs disponibles. Ces attributs sont les suivants
- méthode d'accès
- Browser
- OS
- identifiant de l'utilisateur
- src ip
- egress ip
- domaine
- categories
- Classification du périphérique
Ajustez votre politique d'isolation pour n'envoyer que les requêtes du navigateur de l'utilisateur à RBI.
RBI met en place une session de navigation interactive dans un environnement géré et isolé afin de protéger les points finaux/utilisateurs contre les contenus malveillants intégrés dans le code web lorsqu'ils naviguent sur ces pages. Un utilisateur doit naviguer sur une page web à l'aide d'un navigateur web.
L'ajout du critère de la source du navigateur à la politique d'isolement permet d'éviter que le trafic indésirable n'atteigne la politique d'isolement et ne soit envoyé à RBI pour être isolé, puisqu'il s'agit probablement d'un contenu non isolable (par exemple, un appel API par un agent de bureau pour récupérer du contenu au format JSON ; il ne peut pas être isolé).
Créer des politiques de protection en temps réel pour les contenus que vous ne pouvez pas isoler
RBI protège les utilisateurs en isolant la navigation sur les pages web. Étant donné la nature du proxy Netskope (URL) par rapport au RBI (pages web uniquement, un sous-ensemble d'URL), certaines demandes d'URL correspondant à une politique d'isolement peuvent atteindre la plateforme RBI, mais être impossibles à isoler (par exemple, une URL pour récupérer une mise à jour de paquet ou un fichier de configuration à partir d'un agent utilisateur qui n'est pas un navigateur).
RBI ne peut pas traiter ces demandes sans interrompre le flux d'activité ou interférer avec les politiques de protection en temps réel des clients ; lorsque ces situations se produisent, RBI transmet la demande à la destination, récupère la réponse et la transmet au proxy Netskope pour un traitement supplémentaire.
Les demandes qui ne sont pas isolées sont des demandes HTTP normales. La mise en place de contrôles pour ces demandes nécessite des politiques de contenu et/ou des politiques de protection en temps réel. Si vous souhaitez bloquer, alerter ou inspecter le contenu de ces réponses à des fins de prévention des pertes de données (DLP) ou de détection des menaces, vous devez créer des stratégies de protection en temps réel qui les prennent en compte.
1.Add the “browser” source criteria to all new or edited “isolate” policies.
RBI isole le trafic correspondant à un utilisateur qui visite une page web à l'aide d'un navigateur (par ex. Chrome, Firefox, etc.)
Pour New ou des politiques « isolées » modifiées, vous devez ajouter les critères «browser” source » à toutes les politiques «isolate», empêchant ainsi la correspondance du trafic non navigateur pour ces politiques RBI. La liste des navigateurs est limitée aux navigateurs RBI pris en charge.
L'ajout du critère de source "navigateur" permet de créer des politiques d'isolation plus efficaces et de réduire les demandes non isolables envoyées à RBI, qui pourraient affecter l'expérience de l'utilisateur en raison d'un traitement inutile du trafic.
Existing “isolate” policies will keep working as is, with no changes. New and edited “isolate” policies require the “browser” criteria.
2. Ajoutez les catégories RBI à vos politiques de gestion des menaces.
Netskope recommande que votre politique de lutte contre les menaces inspecte également les réponses qui ne sont pas isolées, afin qu'aucun logiciel malveillant n'atteigne le point final dans les cas où il est impossible de mettre en place une session de navigation isolée pour l'utilisateur.
3. Créez des politiques d'inspection du contenu pour des catégories isolées en fonction de votre position de sécurité.
Créez des politiques de blocage, d'alerte ou d'autorisation pour les activités des catégories RBI. Ils déclenchent des demandes qui touchent une politique du RBI et ne peuvent pourtant pas être isolés (il ne s'agit pas d'une page web). À ce jour, ces politiques doivent être créées au-dessus de la politique d'isolement, en suivant l'ordre d'évaluation du moteur de politique de proxy :
Limites du presse-papiers
Il existe certaines limites connues du presse-papiers, comme indiqué ci-dessous.
LIMITATION 1 : Restrictions liées au navigateur
Certains navigateurs limitent l'accès au presse-papiers pour coller des informations. Le bouton "Coller" est désactivé dans le menu contextuel si le navigateur de l'utilisateur ne le prend pas en charge. Cela peut s'appliquer si :
- La page web isolée est http (le presse-papiers n'est pris en charge qu'en https).
- Le navigateur est Firefox
- Le navigateur est Safari
Si vous utilisez la fonction "Coller", le système vous proposera d'utiliser le raccourci pour coller le texte.
LIMITATION 2 : Le navigateur invite l'utilisateur et lui demande la permission
RBI présente un menu contextuel personnalisé à l'utilisateur, différent du menu contextuel natif du navigateur. Le navigateur ne reconnaît pas l'interaction de l'utilisateur et lui demande l'autorisation :
La réponse recueillie auprès de l'utilisateur est stockée sur la machine locale et cette invite ne sera plus affichée pour ce domaine lors des prochaines sessions isolées. Les autorisations peuvent être vérifiées dans les paramètres du navigateur pour un site :
