Netskope Cloud Firewall - Documentation technique Netskope

Note

Ce document vous guide dans la configuration du Netskope Cloud Firewall. Le Netskope Cloud Firewall contrôle le trafic sortant non-HTTP(S) de votre organisation. Toutefois, si vous avez l'intention de gérer le trafic HTTP(S) (sur le port 80/443 et les ports non standard), vous pouvez vous référer à la documentation de Netskope Secure Web Gateway et de Netskope Cloud Access Security Broker.

Netskope Cloud Firewall offre une gestion centralisée, une visibilité et des politiques cohérentes pour les bureaux distribués et les utilisateurs itinérants. De plus, vous bénéficiez d'une sécurité et de contrôles d'accès avancés sans les limites de coût, de complexité et de performance des pare-feux traditionnels. Netskope offre également des fonctionnalités intégrées de pare-feu hébergées dans le nuage qui permettent un contrôle granulaire du trafic sortant non-HTTP(S) de votre organisation, à savoir le trafic TCP, UDP et ICMP.

Netskope Cloud Firewall assure la sécurité du réseau sur le trafic sortant à travers tous les ports et protocoles pour les utilisateurs et les bureaux. Les contrôles de la politique du pare-feu Cloud comprennent le 5-tuple (adresses et ports source et destination avec protocole), plus les identifiants d'utilisateur et de groupe, les domaines entièrement qualifiés et les caractères génériques en tant que destinations, une passerelle de couche d'application pour FTP et l'enregistrement des événements du pare-feu.

Avec Netskope Cloud Firewall, vous pouvez appliquer une politique de sécurité d'autorisation/blocage basée sur l'adresse IP source et de destination, les ports de destination, les protocoles et les utilisateurs.

Avantages et capacités clés du pare-feu dans le nuage de Netskope

Contrôles de la politique de pare-feu : Comprend un 5-tuple (adresse et port source / destination, protocole), des identifiants d'utilisateur et de groupe, des FQDN et des caractères génériques pour les paramètres de la politique de pare-feu de sortie.
Passerelle de couche d'application FTP : Permet l'utilisation transparente de FTP par le biais de services de traduction d'adresses de réseaux en périphérie du nuage.
Enregistrement des événements du pare-feu : Enregistrement complet de tous les événements de pare-feu (TCP, UDP et ICMP), disponible pour l'exportation.
Architecture SASE intégrée : Netskope Security Cloud intègre un pare-feu dans le nuage avec Secured Web Gateway (SWG), Cloud Access Security Broker (CASB) et Zero Trust Network Access (ZTNA) pour les utilisateurs et les bureaux, afin d'assurer la protection de tous les ports et protocoles. Sécurisez les utilisateurs distants et les succursales avec Firewall-as-a-Service (FWaaS) à l'aide d'une console, d'un moteur de règles et d'une plateforme.
Réduction des coûts d'exploitation : Réduisez les dépenses et la maintenance des appareils, la dépendance à l'égard des pare-feu des points d'extrémité et les efforts d'administration avec plusieurs consoles.
Protégez les utilisateurs : Assure la sécurité du réseau pour le trafic sortant sur tous les protocoles de port de sable pour un accès direct et sûr à l'internet avec le Netskope Client sur le périphérique géré. Le pare-feu en nuage filtre le trafic de sortie des utilisateurs gérés en couvrant tous les ports et protocoles, ainsi que les FQDN et les caractères génériques comme destinations, un ALG FTP, et avec une journalisation complète.
Secure Office : Assure la sécurité du réseau pour tous les ports et protocoles sortants afin de garantir un accès direct à l'internet via des tunnels GRE et IPSec pour n'importe quel utilisateur ou périphérique. Compatible SD-WAN, le pare-feu en nuage prend en charge les tunnels IPSec et GRE entre les bureaux et le Netskope Security Cloud pour filtrer le trafic sortant.
Sécurité DNS

Netskope vous permet de diriger le trafic non-HTTP(S) à l'aide de différentes méthodes. Les sections suivantes décrivent les différentes étapes de la configuration.

Meilleures pratiques

Si vous avez configuré Explicit Proxy over Tunnel (EPoT) et que vous avez l'intention d'acquérir une licence Cloud Firewall, vous devez respecter les directives EPoT suivantes avant d'activer Cloud Firewall ( must ) :
1. Utilisez EPoT avec le port 80 (recommandé par Netskope).
2. Si le port EPoT doit être utilisé avec le port 8080 pour des raisons inévitables, vous devez également définir le port 8080 dans votre configuration de pilotage à l'adresse Non-Standard Ports.
Not following above guidelines would result in traffic loss for EPoT after activation of Cloud Firewall.
Veuillez consulter /fr/explicit-proxy-over-ipsec-and-gre-tunnels#general-guidelines pour plus de détails.

Lors de la mise en œuvre d'un pare-feu en nuage, il convient de respecter une série de bonnes pratiques générales. Cette liste contient les meilleures pratiques à suivre lors de la mise en œuvre d'un pare-feu dans le nuage dans la majorité des cas d'utilisation, mais elle ne doit pas être considérée comme une liste exhaustive car certaines meilleures pratiques peuvent dépendre de l'environnement, des cas d'utilisation et de la mise en œuvre.

Lors de la mise en œuvre d'un pare-feu en nuage, les meilleures pratiques les plus générales sont les suivantes :

Choisissez le comportement par défaut de la stratégie non web en fonction de la position de sécurité de votre organisation.
Par défaut, la politique de non-web par défaut (dernier recours) bloque tout le trafic non-web.
Bien que ce comportement par défaut soit conforme aux hiérarchies générales de pare-feu et aux meilleures pratiques, il est possible de modifier le comportement de la stratégie Non-Web par défaut afin d'autoriser tout le trafic non-web en dernier recours. Il existe des cas d'utilisation valables (à des fins de test, de découverte, pour une posture de sécurité non web plus "détendue" en ce qui concerne le trafic internet).
En fonction de la configuration de la politique de gestion du trafic non web par défaut, gardez à l'esprit les éléments suivants :
- S'il a été configuré pour bloquer tout le trafic non web, des politiques spécifiques autorisant le trafic sanctionné doivent être mises en place.
- S'il a été configuré pour autoriser tout le trafic non web, des politiques spécifiques qui bloquent le trafic non autorisé doivent être mises en place.
Lorsque vous configurez CFW en présence de tunnels, il est extrêmement important de.. :
- Définir correctement quel trafic non web doit être envoyé à Netskope via le routage basé sur des règles (Policy Based Routing).
- Définissez correctement les "Custom Web Ports" envoyés à Netskope et configurez-les dans la configuration de pilotage par défaut. Cela permet de s'assurer que le trafic Web bien connu et attendu envoyé vers des ports non standard (par ex. 8080) seront gérés par le CASB/SWG qui appliquera également les politiques FW au lieu de CFW.
Étant donné que le pilotage du trafic CFW à l'aide de NSClient, contrairement au trafic SWG, repose sur la capacité à filtrer les requêtes DNS en texte clair et à associer les FQDN demandés aux IP de destination afin d'associer correctement le FQDN de destination au trafic TCP/UDP sortant, veillez à ce que :
- DNS over HTTPS (DoH) est bloqué par la politique appropriée du locataire.
- DNS over TLS (DoT) est bloqué par une application de pare-feu personnalisée pour le port TCP 853 dans le locataire.
- DNS over Quic (DoQ) est bloqué par une application de pare-feu personnalisée pour les ports UDP 443 et UDP 853 dans le locataire.
Configurez toutes les stratégies contenant des applications de pare-feu personnalisées L3/4 au-dessus de toute stratégie contenant une application prédéfinie L7. Cela permet de garantir que les politiques pour les applications de pare-feu personnalisées L3/4 seront déclenchées dès le premier paquet.
Inversement, configurez toutes les stratégies pour les applications prédéfinies L7 en dessous de toute stratégie contenant une application de pare-feu personnalisée L3/4.
Il peut y avoir des exceptions où l'on peut vouloir placer une politique contenant une application de pare-feu personnalisée L3/4 sous une politique contenant une application prédéfinie L7, en fonction du cas d'utilisation, mais ces cas d'utilisation sont des cas d'utilisation de niche, et dans ce cas, il faut garder à l'esprit que la politique contenant l'application de pare-feu personnalisée L3/4 sous une politique donnée contenant une application prédéfinie L7 ne se déclenchera et ne sera appliquée qu'une fois que l'IAP aura terminé ou interrompu l'inspection du protocole L7.
Ne mélangez jamais des applications de pare-feu personnalisées L3/4 et des applications prédéfinies L7 dans la même politique, pour les raisons susmentionnées, à moins que les administrateurs n'aient une raison spécifique de le faire.
Les politiques de pare-feu en nuage qui agissent sur les ports/trafic Web doivent être placées en fonction de la hiérarchie globale des politiques du CASB/SWG. Par exemple :
- Les politiques qui contiennent des applications de pare-feu personnalisées L3/4 qui s'appliquent aux ports Web 80/443 bloquant le trafic, empêcheraient tout trafic CASB/SWG si elles étaient placées au-dessus d'une politique CASB/SWG.
- Les politiques pour les applications hybrides (telles que Teams) qui s'appliquent à la fois au CFW et à CASB/SWG en autorisant le trafic, empêcheraient toute autre politique CASB/SWG Activity/Instance/Threat Protection/DLP (Prévention des pertes de données) placée en dessous. Les politiques d'application hybrides doivent être placées généralement au bas de la page