Réconcilier les besoins de l’acheteur du monde réel et l’offre de l’industrie des pare-feux génériques, ou comment bâtir son propre réseau sécurisé de fournitures d’applications.

Les conversations sur les pare-feu de nouvelle génération ont évolué ces derniers temps. Le contrôle des applications et la prise de conscience des utilisateurs étant devenus des éléments pris en compte par tous, l’industrie des pare-feu tente maintenant de faire la différence sur les fonctionnalités de protection avancée contre les menaces. Les menaces avancées sont, de fait, un problème pressant, mais il existe tout un éventail d’autres nouveaux défis économiques et opérationnels à relever pour les organisations informatiques, dans un monde où les applications sont de plus en plus consommées en tant que services.

Un pare-feu est à la fois un point de barrage pour la mise en œuvre de la politique de sécurité et un routeur pour les communications réseau. C’est-à-dire qu’il existe également un aspect significatif de fournitures d’applications à son domaine d’action. À cet égard, il ressemble un peu au cerveau humain, dans lequel on trouve deux hémisphères d’importance égale, chacun ayant des compétences et des missions très distinctes. Seule leur étroite collaboration nous permet de fonctionner efficacement.

Malheureusement, tout ce que l’on entend en matière de nouveautés pour les pare-feu se limite à des conversations sur l’inspection des paquets en profondeur et la mise en œuvre de la sécurité. Qu’en est-il du trafic bénin sur lequel comptent les unités d’exploitation de votre entreprise ? Ce trafic d’applications doit être fourni de façon sécurisée, avec une qualité de service fiable, de site à site et de plus en plus, de cloud à site. Se concentrer sur la seule sécurité sans gérer correctement l’aspect de fourniture dans votre pare-feu, c’est un peu comme un cerveau qui n’utiliserait qu’un seul hémisphère entièrement, alors que l’autre reste en veille. Bien que nous considérions de tels cerveaux comme dysfonctionnels, il semble que nous acceptions des défauts comparables dans nos pare-feu.

Revenons donc un peu en arrière pour mieux comprendre pourquoi ce déséquilibre devient un problème de plus en plus contraignant. Il n’y a pas si longtemps, existait un monde où le réseau d’entreprise était principalement utilisé pour accéder à des données sur des répertoires internes partagés, recevoir ou envoyer des e-mails, et naviguer sur Internet pour se divertir. Les deux principaux composants des infrastructures d’entreprise étaient les LAN, réseaux locaux sur lesquels résidaient les utilisateurs, et le WAN, c’est-à-dire les liaisons réseau connectant les bureaux satellites aux principaux sites de l’entreprise.

La centralisation des infrastructures d’arrière-plan des bureaux et l’extension des applications qui n’étaient pas exactement conçues pour des environnements à latence élevée sur le WAN ont rapidement entraîné des problèmes de performances et une baisse de la productivité. Ces problèmes ont ouvert la porte à nouveau genre de produits d’optimisation de WAN, qui ont alors été utilisés pour les régler. Ils fournissaient une optimisation générique grâce à des techniques de déduplication des données et de compression, ainsi que des améliorations spécifiques de protocole pour certaines applications populaires. Généralement, ces purs produits-jouets ne proposaient pas de fonctionnalités d’inspection en profondeur ou VPN adéquates, et très souvent, les clients hésitaient devant les complications liées à l’utilisation d’un pare-feu et d’outils d’optimisation WAN, en parallèle d’une complexification des schémas des flux du trafic via les deux équipements. Ils recouraient alors souvent à des structures WAN basées sur un système MPLS dans lesquelles tout le trafic, y compris la navigation Internet, passe par le data center.

À cette époque, les clients dépendaient peu de l’accessibilité aux offres de SaaS ou aux services cloud résidant en dehors des confins de leurs LAN d’entreprise. De nos jours, avec l’offre prolixe de SaaS pesant de plus en plus sur les besoins courant comme les offres d’applications bureautiques (par exemple Microsoft Office365), l’ancienne approche montre ses défauts puisque l’axe central du MPLS ne peut pas faire la différence entre les diverses applications qui utilisent maintenant la même ligne physique. Il est donc possible qu’une application de sauvegarde interne ou un agent de mise à jour inonde complètement la ligne et rende difficile l’utilisation des applications en ligne critiques de l’entreprise.

L’ultime solution à ce problème est de séparer les différents types de trafic d’applications, au niveau logique ou physique, en partitionnant la ligne en plusieurs segments qualitatifs. Pour en revenir à notre analogie avec le cerveau, cela signifierait que l’hémisphère de l’inspection est nécessaire pour détecter la nature d’un flux de trafic, puis que l’autre hémisphère est nécessaire pour agir intelligemment et délivrer ce flux de trafic différemment d’autres flux de trafic moins importants.

Face à l’utilisation de nombreuses offres de SaaS, le meilleur choix est d’opter pour des passerelles directes vers Internet sur les divers sites. Bien sûr, toute passerelle vers Internet doit également être protégée par un pare-feu de nouvelle génération adapté. Le spectre des polices de nombreux pare-feu à synchroniser plane à présent sur l’équipe informatique. Mais ce n’est pas le cas si le pare-feu est livré avec une puissante architecture de gestion centrale, dans laquelle une politique unique, ou un nombre limité de politiques, peuvent être actualisées de façon centrale, puis envoyées vers les points de blocage pour une mise en œuvre décentralisée, c’est-à-dire grâce au paradigme MORE classique (gestion unique, exécution partout).

L’avantage supplémentaire d’une passerelle locale est que l’on peut désormais exploiter un réseau WAN hybride. Le réseau étendu hybride se compose de lignes WAN traditionnelles complétées par des liaisons VPN basées sur Internet. Une approche plus radicale consisterait à n’utiliser que des VPN basés sur Internet, mais deux FAI différents pour ensuite créer plusieurs tunnels. Là encore, un pare-feu tenant compte des applications peut orchestrer et répartir divers types de trafic interne entre les liaisons disponibles. En cas de défaillance des liaisons individuelles, le pare-feu doit le remarquer et redistribuer les flux en fonction de cela sans aucune perturbation du service.

Si l’on utilise des pare-feu de ce type et que l’on crée des redondances réseau, on parvient à une structure de communication sécurisée qui fournit toute l’inspection de paquets en profondeur et la réduction des menaces dont on a besoin, en plus d’une fourniture résiliente et performante des applications métier aux utilisateurs de l’entreprise.

 

_____________
Klaus Gheri est VP de la sécurité réseau chez Barracuda Networks, Inc.