Des containers physiques ou virtuels ?

Se poser la question d’exécuter des containers directement sur des serveurs physiques dit “Bare Metal” versus sur des serveurs virtuels dit des VMs est légitime, surtout lorsqu’on utilise un orchestrateur de container comme Kubernetes. Pour chaque nouvelle architecture applicative on me pose la question : est-il nécessaire de mettre en place une architecture virtuelle pour ces types d’application ou pour d’autres : SAP HANA, HADOOP, MONGO DB, CASSANDRA, …. et donc aussi Kubernetes ? L’élément déclencheur de cette réflexion est de vouloir faire l’économie du coût de l’hyperviseur. Mais ce dernier à beaucoup d’avantages opérationnel, sécuritaire, d’extensibilité et de souplesse.  Si vous êtes déjà convaincu par la nécessité de s’appuyer sur une architecture de virtualisation et vous pensez partir sur un hyperviseur dit gratuit, je vous invite à lire cet article : “C’est gratuit ! ?”.

Les portes containers vont s’exécuter sur un porte containers. Un porte container est un système d’exploitation en général Linux sur lequel vont s’exécuter les container. Sur du Bare Metal, on va maximiser le nombre d’exécution de containers alors que dans une VM on va à l’inverse plutôt minimiser le nombre d’exécution de containers voire 1 container par VM. Pour que ce soit efficace ou pertinent, il ne faut pas partir sur des VMs classiques mais sur des micros VMs sur lesquels est installé un systèmes d’exploitation épuré de services inutiles, durci (sécurité renforcée) et optimisé pour les containers de sortes à ce qu’ils consomment très peu de ressources et démarrent en quelques millisecondes.

Tout système d’exploitation a ses contraintes, ses limites et ses faiblesses :

  • Sur un système d’exploitation, le nombre de container est limité (Exemple pour Kubernetes : https://kubernetes.io/docs/setup/best-practices/cluster-large/), la règle est la même pour un porte container basé sur une machine virtuelle. Par contre, un serveur de virtualisation hébergera plusieurs VMs soit autant de porte container à hauteur des ressources physiques disponibles soit : Max Container par OS x Nombre de VM porte containers par serveur de virtualisation.
  • En Bare Metal, le porte containers est en contact directe avec le matériel. Les composants physiques du serveur doivent être compatibles avec le système d’exploitation et ses drivers. La virtualisation elle, fait abstraction et le porte container n’a plus à se soucier de la compatibilité du matériel et des drivers associés, vous pouvez changer de fournisseurs de serveurs et des composants.
  • Le système d’exploitation du porte container doit être maintenu à jour et les opérations de maintenance auront un impact sur tous les containers qui y sont hébergés. Avec une approche VM, l’impact sera limité car comme expliqué juste avant, on privilégie peu de container par VM porte container voire même 1 container par VM.
  • Le porte container est dédié à un usage : dev, prod, pré-prod, …, donc si toutes les ressources ne sont pas utilisées pour cet usage, il y aura beaucoup de perte (€€€). Avec la virtualisation, les serveurs physiques peuvent héberger des VMs porte containers de différents usages et la consommation des ressources sont ainsi optimales.
  • En Bare Metal, le porte container exécutera un seul système d’exploitation. Avec une infrastructure virtualisée, un serveur physique peut héberger des porte containers, Windows et différents types de Linux.
  • Les solutions d’orchestration comme Kubernetes orchestre des containers mais pas le provisionnement de porte containers. L’orchestrateur utilise les ressources physiques qu’il a à sa disposition à un instant T et s’il en manque, il faut rajouter un serveur, mais ce n’est pas lui qui va le faire, il va s’appuyer sur un IaaS (Infrastructure As A Service). En environnement virtualisé le déploiement de porte containers consiste au déploiement de VMs. Les IaaS basés sur des VMs sont beaucoup plus commun que ceux basés sur des serveurs physiques.
  • Quid des performances ? Et bien là aussi un bon hyperviseur permet de gagner en performance, vSphere tire mieux parti des architecture NUMA que les systèmes d’exploitation du marché et permet ainsi d’avoir un gain de performance. Un test comparatif a été effectué par VMware sur des applications Web : https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/performance/docker-vsphere65-weathervane-perf.pdf
  • L’isolation des containers entres eux, même si elle fonctionne correctement, elle peut avoir un gros impact sur tous les containers en cas de faille de sécurité. La virtualisation offre en plus, une isolation inter VMs donc inter porte containers beaucoup plus robuste et plus vous limitez le nombre de containers par VM plus la sécurité sera renforcée.
  • Ne vous inquiétez pas sur la consommation des ressources par un porte container VM. Si un OS classique consomme des ressources et met du temps à démarrer, un OS optimisés pour l’hébergement des containers (Micro OS comme Photon OS), consomment peut de ressources et démarre en quelques millisecondes. De plus un bon hyperviseur à des optimisations de consommation de ressources lorsque des OS identiques sont exécutés en même temps.
  • Un container doit pouvoir démarrer sur n’importe quel porte container d’un cluster (regroupement des ressources de plusieurs serveurs), s’il a besoin de persistance des données, il doit pouvoir y a accéder depuis n’importe où et pour cela, il faut un système de fichiers partagé en général un export NFS externe qu’il faut maintenir. La virtualisation propose un système de fichier partagé natif qui est complètement intégré. Sur vSphere ce système de fichiers peut s’appuyer sur pratiquement n’importe quelle baie de stockage du marché. L’utilisation de la solution hyper convergée vSAN offre néanmoins beaucoup plus d’avantages qui sont détaillés dans cet article : Pourquoi vSAN (HCI : Hyper Convergence Infrastructure)

J’ai apporté une liste non exhaustive des avantages à utiliser la virtualisation pour des containers, si vous avez encore des doutes, je vous invite à vérifier sur quel type d’architecture s’exécute les offres de containers as a service proposées par les grands acteurs du Cloud Publics. D’ailleurs RedHat et VMware ont annoncé lors du Red Hat Summit de mai 2019 une architecture de référence pour la solution Red Hat OpenShift basée sur le SDDC VMware : https://octo.vmware.com/vmware-red-hat-bring-red-hat-openshift-vmware-sddc/.

Les offres autour de Kubernetes ne cessent d’évoluer, VMware vient d’annoncer à VMworld 2019 le Projet Pacific, une nouvelle évolution de l’hyperviseur vSphere qui intégra nativement l’orchestrateur Kubernetes et les portes containers, ca fera l’objet d’un nouvel article 🤔😉.

VeloCloud, le SD-WAN par VMware

Souvent les sites distants sont “délaissés” par rapport au Data Center principal et pourtant ils sont bien souvent nombreux et ont une part prépondérante dans l’activité des entreprises, Ils sont la partie “production” : Aéroports, agence, magasins, laboratoires, usines, entrepôts, hôtels, … Ils ont besoins d’accéder à des applications et des données hébergées en central et/ou sur des cloud publics, cela nécessite donc d’avoir un réseau de communication fiable, résiliant, performant ainsi qu’une administration simple et centralisée.

Le Software Defined WAN (SD-WAN) permet au-dessus d’un réseau physique existant, de créer un réseau WAN virtuel à l’instar d’un vrai Software Defined Network (SDN). La solution VeloCloud (acquise par VMware en 2017), agrège les capacités de plusieurs liens réseaux de différentes technologies (Internet, ADSL, MPLS, …) pour les utiliser comme un seul lien et ainsi gagner en performance et en résilience. Ils sont “monitorés” en temps réels et de manière continue (Bande Passante, Latence, Jitter , paquets perdus, …) cela permet ainsi à une application de bénéficier à tout moment du ou des meilleurs liens en fonction de sa criticité .

Les sites distants peuvent bénéficier de nouveaux services auxquels ils n’avaient pas droit auparavant comme des vidéos pour des conférences, des formations, des voeux de fin d’année ou tout autre message d’entreprise.

Il est possible de prioriser certains flux par rapport à d’autres de façon à garantir une qualité de service. il est même possible de spécifier quelles applications ont droit d’utiliser plusieurs liens réseaux et celles qui ont le droit d’en utiliser qu’un. Tout se fait par application de politique de niveau de service définies en central.

Concernant les applications en mode SaaS ou hébergées chez des Cloud Public, les sites distants peuvent y accéder directement sans avoir à repasser par un site central. Cela se fait grâce à des gateway hébergées directement dans les data center où sont installées ces applications, comme le montre l’exemple ci-dessous où il est possible de télécharger les gateway pour AWS et Azure via leur marketplace.

 

Les performances sont ainsi optimales sans compromettre la sécurité car les règles de sécurité restent gérées en centrale par l’administrateur.

 

Vous avez même la possibilité de la renforcer en la couplant avec le partenaire avec qui vous avez l’habitude de travailler : https://www.velocloud.com/partners

 

 

Concernant les déploiements, ils sont de type Zero Touch, que l’on opte pour des boitiers physiques ou virtuels, la configuration se fait par application automatique de profils. Il n’est plus nécessaire d’envoyer des compétences pointues sur chaque site, les déploiements sont ainsi beaucoup plus rapides et beaucoup moins couteux.

 

 

En résumé

  • Utilisation de plusieurs types de liens réseau pour augmenter la bande passante et la résilience
  • Accès aux applications Cloud optimisé sans repasser par le site central
  • Réduction du temps de déploiement avec le zéro touch et par application de profile, pas besoin d’envoyer de compétences pointues
  • Visibilité sur la performance des applications et sur les défaillances des liens réseau
  • Application de politique en fonction du niveau de service attendu, exemple : Bronze 1 seule ligne utilisée, gold 2 lignes utilisées
  • Segmentation des flux réseaux par type d’application et application de priorités

L’IOT a besoin d’une infrastructure et elle existe !

Les objets sont de plus en plus présents dans les entreprises et sous diverses formes (Caméra, capteur de température, ventilateur, ….). Ces objets génèrent énormément de données qui sont traitées par une ou plusieurs applications. Prenons un exemple simple de parking, avant d’y rentrer vous pouvez savoir le nombre de places de stationnement disponibles, puis une fois rentré le nombre de places par étage et enfin par rangée, ceci grâce à des capteurs qui sont généralement fixés au plafond à quelques dizaines de centimètres au-dessus des voitures. Dans ce même parking vous avez des caméras un peu partout pour enregistrer les mouvements des personnes, vous avez des capteurs pour mesurer le taux de monoxyde de carbone et enclencher des extracteurs pour évacuer ces particules. Tous ces objets vont générer des données et Il y aura une application provenant de différents constructeurs et par activité pour les traiter, une application pour les places de parking, une pour les caméras et une pour la détection des particules. Par contre comment gérer ces objets ? Comment connaitre leur santé, mettre à jour leur firmware ? Pour cela, il est pertinent d’avoir une infrastructure commune hétérogène.

La solution VMware IOT Pulse Center permet à l’IOT d’avoir à la fois son infrastructure basée sur le SDDC VMware et aussi de gérer le cycle de vie des objets comme le fait VMware Workspace One avec les périphériques utilisateur. 

Cependant il y a un élément nouveau dans l’IOT par rapport à une infrastructure classique, c’est la gateway, comme les objets sont nombreux et utilisent souvent un protocole et une connectique qui leurs sont propres, ils passent par cette gateway qui servira de concentrateur et permettra la communication avec les applications via le réseau classique IP.

 

En 2016 VMware a développé l’agent LIOTA (Little Internet Of Things Agent) qui est un SDK Open source installé sur ces gateway permettant la communication avec les objets et ainsi de les gérer, de les monitorer et d’orchestrer les données en provenance et allant vers le Data Center et/ou Cloud Public. LIOTA découple aussi l’application du type/marque/model d’objet, l’application communique ainsi via LIOTA qui lui retranscrira aux objets en fonction de leurs spécificités.

 

Pour les grosses architectures ou les solutions nécessitant des prises de décisions rapides, un élément intermédiaire sera ajouté entre la gateway et l’application qui va permettre de faire des pré/post traitements et être ainsi plus réactif, ces traitements sont hébergés et exécutés sur du Edge Computing. Le Edge Computing est au bout de la chaine au plus près des gateways et objets. Sur ces Edge Computing est installé le SDDC de VMware.

 

 

Les objets sont enregistrés dans Pulse IOT Center, ce qui permet de connaitre leur états de santé, de les sécuriser en sécurisant les mot de passe (bien souvent les mots de passe par défaut ne sont pas remplacés) et de gérer les cycles de vie des firmwares. Pulse IOT Center permet aussi de classifier les objets de manière à avoir des vues pertinentes et prendre les bonnes décisions rapidement.

 

Les objets ont désormais leur Infrastructure basée sur des solutions existantes et éprouvées depuis de nombreuses années. Cette infrastructure permet de s’affranchir de l’hétérogénéité et la massification induite par ce type de technologie. Les opérationnels ont avec le SDDC de VMware un case d’usage supplémentaire.

Pourquoi choisirais-je vIDM (alors que j’ai déjà un Identity Manager) ? 🤔

L’objectif d’un IDM (Identity Manager) est :

  • D’un point de vu consommateur/utilisateur : Simplifier le process d’authentification de sorte à ce qu’il n’ait qu’un seul identifiant et mot de passe à retenir et à gérer mais permettant la connexion à différentes applications et services et ce quel que soit le moyen d’accès et le type d’hébergement.
  • D’un point de vu fournisseur/administrateur : Renforcer la sécurité et la conformité d’accès aux applications/services par la mise en place de politique de gestions d’identification multicritères indépendamment des périphériques, des moyens d’accès et des applications/services.

Attention à ne pas confondre un annuaire et un Identity Manager, en général dans chaque entreprise il existe déjà un annuaire type Active Directory ou LDAP où sont créés les comptes des utilisateurs. L’identity Manager va synchroniser les utilisateurs (sans les mots de passe) issus de cet annuaire et l’IDM validera les mots de passe auprès de l’annuaire.

Les utilisateurs ne possédant pas d’IDM trouvent toujours des moyens pour retenir leurs identifiants issus des différentes applications auxquelles ils ont accès, mais ces moyens ne sont pas très sécurisés et/ou pas simple à gérer :

    • Ecrire ses identifiants sur un papier ou dans un fichier.
  • Utiliser le même mot de passe ou la même racine. Attention cependant, le cycle de vie du changement de mot de passe peut-être différent pour les différentes applications et il y se peut que votre identifiant soit différent par application.
  • Sauvegarder ses identifiants/mot de passe dans le navigateur. Cela ne concerne que les applications accessibles en mode Web et nécessite un navigateur multi-périphériques (oubliez Safari sur Android et sous Windows) et avoir un compte chez l’éditeur du navigateur pour les synchroniser.
  • Utiliser un outil de type coffre-fort à installer. Il faut qu’il soit multi-périphériques, que les identifiants/mot de passe soient synchronisés sur tous les périphériques que vous pensez utiliser dans le futur. Ca ne vous prémunie pas d’avoir à changer vos mots de passes quand l’application vous le demandera et d’avoir à respecter sa complexité (nombre de caractère, type de caractère à inclure, ne pas réutiliser x versions antérieurs, …)

vIDM en plus d’un IDM classique renforce la sécurité en permettant des accès conditionnels, Il est par exemple possible de demander uniquement le mot de passe si l’utilisateur est connecté via le réseau d’entreprise et de demander une authentification tierce comme un code RSA si l’utilisateur est connecté via un autre réseau : wifi publique, 4G, …

Il est possible aussi d’accepter l’authentification si le périphérique est conforme aux règles définies comme par exemple, version d’OS, niveau de patch ou bien encore si le périphérique n’est pas “jailbreaké”. Cette vérification de condition peut se faire pour toutes les applications ou par application en fonction de sa criticité.

vIDM couplé à Workspace One donne à l’utilisateur une fois authentifié accès à un catalogue d’applications locales (pour certains systèmes d’exploitation et smartphone), SaaS ou Web. Si l’utilisateur le souhaite, Il peut aussi se connecter directement à l’application sans passer par le catalogue et celle-ci redirigera l’utilisateur vers vIDM pour qu’il s’authentifie.

vIDM propose aussi la possibilité d’utiliser d’autres méthodes d’authentifications en fonction du périphérique comme par exemple l’utilisation d’un lecteur d’empreinte digitale.

Pour résumer, vIDM simplifie l’authentification des utilisateurs quel que soit le périphérique, accroit la sécurité liée à l’authentification, assure la conformité de gestion des mots de passes.

La sécurité de bout en bout !

Comme on ne vit pas dans le monde des Bisounours, la sécurité est pour nous tous un mal nécessaire je dirais même obligatoire. Elle ne se résume pas à la mis en place d’un firewall pour filtrer tout ce qui entre et qui sort du data center et d’un anti-virus sur le poste de travail, il faut sécuriser toute la chaine allant de l’utilisateur à l’application en passant par l’infrastructure.

Vous avez surement déjà vue l’image à droite lors d’une présentation VMware, elle explique la stratégie de VMware, à droite de cette image, il y a des petits cadenas orange qui correspondent à la sécurité. C’est ce que je vais décrire succinctement dans cet article : les fonctionnalités qui contribuent à améliorer la sécurité. Elles peuvent être utilisées de manière indépendantes ou complémentaires les unes par rapport aux autres. Je vais commencer par le bas (l’infrastructure) pour finir par le haut (l’utilisateur).

 

Sécuriser la base : le boot de l’hyperviseur

Pour être sûr que l’hyversieur est basé sur un code authentifié, celui-ci peut être vérifier dès la première phase de démarrage par le BIOS UEFI du serveur et si le code n’a pas la bonne signature, l’hyperviseur ne pourra pas démarrer. La vérification se fait par un système de clé privé / clé publique.

The UEFI secure boot stack includes multiple elements, explained in the text.

 

“Durcir” les composants

VMware délivre des “Security Hardenig Guides” https://www.vmware.com/security/hardening-guides.html pour sa solution d’hyperviseur vSphere et sa solution de réseau et de sécurité NSX. Ces “Security Hardening Guides” sont des règles de configuration de bonne pratique qui permettent de sécuriser au maximum les solutions VMware et limiter ainsi les surfaces d’attaques. Un exemple de règle sur vSphere parmi les 70 qui existent, le timeout d’accès au shell pour exécuter des lignes de commande, par défaut il n’y en a pas, la recommendation est de 900 minutes.

Pour faciliter la vérification du bon respect de ces règles la solution vRealize Opérations propose des tableaux de bords simples à consulter :

 

Le chiffrement des VMs

Pour éviter que des VMs soient copiées illicitement et ensuite démarrées sur un autre environnement, il est possible de chiffrer les fichiers qui les constitue ainsi que les éventuels déplacement (vMotion) vers d’autres hyperviseurs identifiés, et ce, quel que soit l’OS des VMs. La mise en place nécessite que le vCenter soit relié à un serveur de gestion de clés KMS, ensuite il suffit d’associer les VMs que l’on souhaite chiffrer à une politique de stockage ayant l’attribut chiffrement, cela peut se faire post création.

Il est possible aussi de chiffrer un espace de stockage complet (nécessite d’avoir la solution vSAN), tout ce qui y sera stocké sera sécurisé, pas besoin de sélectionner les VMs à sécuriser. Un autre avantage ce cette possibilité auquel on ne pense pas concerne la partie matériel, ainsi si un disque est défaillant vous n’êtes pas obligé de passer par une société tierce pour le détruire car son contenu est chiffré et donc illisible.

 

Sécuriser le boot des VMs

Pour éviter que des root kits malveillants soient installés dans le système d’exploitation de la VM et ainsi corrompre le système d’exploitation, l’hyperviseur vSphere permet de sécuriser le boot de la VM de façon a ce que seuls les systèmes d’exploitation, le boot loader et les drivers signés par l’éditeur puissent démarrer.

 

Création de réseaux par usage

Pour limiter les surfaces d’attaques, il faut limiter l’exposition des applications sur les réseaux. Idéalement une application devrait venir avec ses propres réseaux de communication. Prenons une architecture applicative composée de plusieurs services comme par exemple un service Web, un serveur d’application et un service de base de données. Seul le service Web doit être exposé aux utilisateurs. Les autres communications doivent se faire par réseau dédiés comme illustré dans le schéma ci-dessous :

Avec ce principe on créé un réseau dédié par canal de communication entre les services applicatifs. Le fait d’avoir des petits réseaux dédiés à chaque communication limite l’utilisation de règles de sécurité. Alors bien sûr avec un réseau classique c’est complexe à mettre en place mais avec la virtualisation du réseau (NSX), c’est un jeu d’enfant.

 

La micro segmentation

La micro segmentation consiste  à améliorer la sécurité de l’infrastructure en étant le plus granulaire possible. Elle permet de filtrer les communications de chaque carte réseau de chaque VM.

Grâce à cela les communications entres les VMs peuvent être filtrées mêmes si elles résident sur le sur un même segment réseau IP. Dans l’exemple ci-dessous la VM qui appartient à l’application Finance et connectée au réseau DMZ mais elle ne peut pas communiquer avec les autres VMs HR et Engineering même si elles aussi sont connectées au même segment réseau IP DMZ.

Alors il est possible de le faire avec une architecture physique classique mais ça devient vite une usine à gaz à mettre en place et à administrer au quotidien.  Avec la virtualisation de la sécurité (NSX), c’est beaucoup plus simple, les règles peuvent être créés dynamiquement, par exemple on peut identifier toutes les VMs (existantes et à venir) Windows sans avoir à spécifier les adresses IPs. De plus si les VMs sont amenées à se déplacer d’un hyperviseur à un autre, les règles restent toujours actives car le firewall est distribué dans le kernel de tous les hyperviseurs concernés.

 

La conformité

Suivant le secteur d’activité de son entreprise, on peut être amené à devoir respecter certaines normes de sécurité et mettre en conformité une partie de son infrastructure.  Comme un de mes clients stockait et traitait des informations relatives aux paiements par carte bancaire, J’ai dû travailler sur la norme de sécurité PCI-DSS ( Payment Card Industry Data Security Standard). Pour PCI-DSS, il faut prendre en compte toute une chaine à sécuriser. L’avantage principal des solutions VMware est qu’elles vont vous permettre de ne pas avoir à dédier une infrastructure physique mais plutôt de segmenter celle existante et dédier un segment à l’environnement PCI-DSS et de le rendre hermétique par rapport au reste. Prenons deux exemples, l’un coté utilisateur et l’autre coté réseau :

  • Coté utilisateur, le poste de travail utilisé par un opérateur manipulant des données de paiement par carte bancaire doit être dédié à cet usage, s’il est amené à travailler avec d’autres données, il doit avoir un autre poste pour cet usage. Grace à la visualisation du poste de travail (VMware Horizon), il a un poste physique avec son environnement classique et un autre environnement virtuel dédié à PCI-DSS, les deux sont complètement isolés et étanches l’un par rapport à l’autre.
  • Coté réseau, le réseau utilisé par l’environnement qui va manipuler des données de paiement par carte bancaire doit être isolé par rapport aux autres réseaux des autres environnements. Grace à la visualisation du réseau et de la sécurité (NSX), vous créez à la demande des réseaux virtuels de confiance dédiés au périmètre PCI-DSS complément isolés et hermétiques du réseau classique d’entreprise

Ce document (en Anglais) : https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/vmware-sddc-euc-product-applicability-guide-for-pci-dss.pdf détail l’apport de chaque solution à chaque recommandation.

 

La sécurité des applications

La devise est : si on sait modéliser le bon comportement d’une application alors on sait aussi identifier un mauvais comportement, un comportement déviant de la normal. La solution AppDefense modélise le bon comportement grace à une capture de l’application, c’est à dire identifier tous les process et communications réseau utilisés. (Tout est plus détaillé dans ce document (en Anglais) : https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/vmware-appdefense-solution-overview.pdf)

La première chose que tente de faire un “malware” est de désactiver les outils de sécurité basés sur des agents. AppDefense bénéfice d’une zone sécurisée fournie par l’hyperviseur qui est inaccessible par le système d’exploitation de la machine virtuelle, AppDefense ne peut ainsi pas être corrompu ou désactivé.

Lorsqu’une menace est détectée, AppDefense peut demander à vSphere d’arrêter une VM, de la suspendre ou d’en faire un snapshot afin de pouvoir la décortiquer. AppDefense peut aussi demander à NSX (solution de virtualisation de réseaux et sécurité) de bloquer les communications réseaux ou de le connecter à un réseau de quarantaine.

 

Sécuriser les accès distants

Il y a plusieurs possibilité d’accéder à distance à des applications d’entreprise, pour chaque méthode il faut une solution sécurisée :

  • Le VPN SSL de NSX permet à des utilisateurs de se connecter depuis n’importe où à un réseau spécifique du Data Center via un canal chiffré, comme si il était directement au réseau de son entreprise.
  • Le VPN IPSEC de NSX permet de connecter deux segments de réseaux IP différents tout en sécurisant les flux de communication.
  • Le VPN L2 permet d’interconnecter deux réseaux physiques de niveau 2 (Ethernet) différents pour qu’ils soient vus comme un seul. Les VMs ainsi connectées se voient toutes comme si elles étaient physiquement connectées sur un même réseau.
  • Les VPNs par application de Workspace One sont utilisés notamment pour les applications smartphone, ils permettent à chaque application d’avoir son propre tunnel sécurisé. Ça offre l’avantage de ne pas avoir un seul gros VPN pour tout le smartphone où il n’y a pas de distinction des communications personnelles et professionnelles. Cela permet aussi de diminuer la consommation de la batterie, le VPN engendrant des cycles CPU n’est activé que quand l’application est utilisée.
  • Le poste de travail virtuel (VMware Horizon anciennement VMware View) permet de donner accès via un réseau à un poste de travail qui est entièrement exécuté sur un Data Center, seuls les flux entrants et sortants comme le clavier, la souris, l’écran ou encore le son sont locaux. Toute la propriété intellectuelle de l’entreprise reste au sein de l’entreprise, les transferts de fichiers, le copier/coller, l’accès à des périphériques USB peuvent être inhibés. Le poste de travail virtuel est souvent utilisé lorsque les entreprise ont recours à des prestataires ou à des sous-traitant.
  • La gestion des terminaux (Android et IOS) et de leurs contenus (VMware Workspace One anciennement Airwatch) permet de sécuriser les accès. En effet quelque soit le model d’attribution choisi : Bring Your Own Device, Choose Your Own Device ou autre, il est possible de créer un espace professionnel distinct du personnel sans compromettre la sécurité. L’utilisateur gère son propre espace avec ses propres contenus et l’administrateur s’occupe de sécuriser l’espace professionnel. Il autorise l’accès aux applications et aux données de l’entreprise par des critères d’authentification multi facteur requis en fonction du réseau de connexion.  Pour simplifier et sécurisé les authentifications, la fédération d’identité est utilisée pour accéder à l’ensemble des applications (SaaS, Web,  Messagerie, …) empêchant ainsi les traditionnels risques liés aux mot de passe faibles et identiques, tout en permettant à l’utilisateur une seule authentification valable pour l’ensemble des applications. Si le terminal est perdu ou volé il est possible de remettre à zéro le contenu de la partie professionnelle.