VMware montre le réseau NSX aux entreprises européennes

Un firewall au plus près des machines virtuelles

NSX ajoute aux switches réseau virtuels déjà présents dans l’hyperviseur de vSphere des fonctions de routage évoluées et, surtout, de pare-feu. « Le gros intérêt de NSX par rapport à des firewalls traditionnels est qu’il fonctionne dans l’hyperviseur, au plus près des machines virtuelles. Ce qui signifie deux choses. D’une part, sa puissance de calcul est distribuée ; il n’est plus nécessaire d’installer en amont un firewall monstrueux pour gérer toutes les règles de sécurité (ACL) de toutes les machines virtuelles. D’autre part, lorsque l’on étend l’exécution des VM dans un autre datacenter, on a la garantie que les règles de sécurité suivent automatiquement  les VM. Sans NSX, il faut les réintégrer manuellement  dans le pare-feu du second datacenter », explique Olivier Savornin, directeur SEMEA SDDC, Network & Security.

Un DSI présent à la rencontre est ravi : « mon problème, c’est le Shadow IT. Les métiers souscrivent à des offres de Cloud publics de leur propre fait, puis viennent me demander de raccorder cette offre à notre SI interne. Mais je ne maîtrise pas la sécurité de cette offre publique. Et je ne veux pas que ses failles viennent contaminer mon SI. Jusqu’à présent, je ne savais pas répondre à ces métiers, au risque de passer pour celui qui bloque l’innovation de l’entreprise. Avec NSX, je peux leur dédier simplement et dynamiquement un réseau virtuel (VLAN) dans notre datacenter, avec des règles de sécurité conçues exprès pour leur offre publique », confit-il au MagIT.

Répondre à la complexité de configuration des AC

En réalité, le vrai problème que résout NSX est le coût de la complexité des firewalls traditionnels. « On ne parle plus ici de simplement bloquer des ports. On parle de dérouler des règles de sécurité sur le contenu de tous les paquets qui passent. Et, pour éditer de telles ACL, il faut pratiquement toujours faire intervenir un technicien du fournisseur de firewall, ce qui coûte une fortune », souligne Pascal Jacquin, le DSI de la Chambre de Commerce et d’Industrie de Paris.

Et encore. Ces règles de sécurité, appliquées à chaque paquet, sont consommatrices de beaucoup de puissance de calcul. Soit on opte pour un firewall bardé de lames CPU qui pourra toutes les appliquer, ce qui coûte très cher, soit on configure de manière extrêmement pointue autant de firewalls qu’il y a de réseaux virtuels, ce qui multiplie d’autant la facture du consultant, soit on opte pour un routeur cœur de réseau de type Cisco Nexus/ACI qui sait suivre les machines virtuelles et ne leur appliquer que les règles pertinentes, et dans ce cas le tarif horaire du technicien est proportionnel au prix de cette configuration haut de gamme.

« En revanche, au niveau de l’hyperviseur, comme le fait NSX, on ne doit plus analyser que les paquets qui ont été routés vers les serveurs physiques et, de plus, avec les règles de sécurité qui ne concernent que ces VM. Ce qui allège considérablement le travail », explique Pascal Jacquin. Il ajoute que la configuration des ACL peut dès lors être réalisée en interne, moyennant la formation des personnels. « En confiant toutefois cette tâche aux équipes de l’administration système, ce qui ne laisse plus aux équipes réseau que la configuration du routage vers les VLAN », observe-t-il. 

Reste à s’adapter aux prix et aux réglementations des entreprises

Pour autant, Pascal Jacquin n’achètera pas NSX. Il dénonce un problème de tarif : « on conçoit des règles de sécurité par VLAN. Il serait donc logique de payer NSX selon le nombre de VLAN en activité. Mais VMware facture ce produit comme le reste de vSphere : selon le nombre de cœurs de processeurs qui exécutent des machines virtuelles. En ce qui me concerne, cela rend la facture totalement prohibitive ! », dit-il.

Selon lui, le tarif de NSX est adapté aux prestataires de Clouds ou assimilés, c’est-à-dire ceux qui déploient régulièrement de nombreux VLAN. « En ce qui concerne la CCIP, nous changeons très peu souvent la configuration de nos VLAN, donc nous avons un coût d’exploitation très faible. Alors, bien entendu, je dois régulièrement augmenter la puissance de calcul de mon pare-feu CheckPoint à chaque fois que j’augmente le nombre de machines virtuelles. Cependant, j’ai calculé que cela me coûtait tout de même dix fois moins cher que d’acheter NSX », martèle-t-il !

Pour Pascal Jacquin, VMware a le défaut de ne s’adresser qu’aux très grands comptes. Martin Casado rétorque : « durant mes deux jours passés à Paris, j’ai pu constater que les entreprises françaises avancent très vite sur la question et mettent même rapidement NSX en production, y compris dans les grandes banques. »

Au terme de la rencontre, un DSI des services publics pondère : « NSX nous intéresse. En revanche, nous ne basculerons pas tant que l’ANSSI n’aura pas validé la sécurité qu’il nous apporte. » Olivier Savornin lui assure que des démarches ont été entamées dans ce sens.

Après Madrid la veille et Tel Aviv le surlendemain, Paris était la deuxième étape d’un périple durant lequel Martin Casado doit rencontrer les principaux clients de la zone Europe du Sud. Maître de conférence à Stanford, le jeune homme est réputé être l’inventeur du Software Defined Network. Il avait développé le concept au sortir de ses études, en créant la société Nicira au sein de laquelle il a mis au point des versions propriétaires d’OpenFlow (protocole pour distribuer un plan de routage au travers du réseau) et d’Open vSwitch (switch virtuel pour hyperviseurs). Après avoir conquis des clients comme eBay ou AT&T, Nicira fut rachetée en 2012 par VMware pour 1,26 milliard de dollars. Plutôt que d’entamer une carrière de business angel comme bon nombre d’autres fondateurs de startups, Martin Casado a décidé de rester chez VMware pour poursuivre son projet. A Paris, les entreprises se sont pressées pour rencontrer ce personnage qui entre petit à petit dans la mythologie de la Silicon Valley.