Catégorie dans Sécurité

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.

Consommer les solutions VMware as a Service via un partenaire Service Provider

Le programme VCPP (VMware Cloud Provider Program) permet aux clients finaux de consommer les solutions VMware comme un service (VMware as a Service) avec une couverture locale ou géographiquement répartie à travers le monde. Il existe environs 4 600 partenaires Service Provider VMware dans le monde qui offrent ces possibilités dont plusieurs centaines en france.  Les services proposés vont de la mise à disposition d’infrastructure nue (Bare Metal) jusqu’à une infrastructure complètement opérée, simplifiant ainsi au maximum leurs usages. La liste complète ainsi que les services proposés sont disponibles via ce lien :https://cloud.vmware.com/providers/search-result.

Ce qui caractérise tous ces partenaires, c’est qu’ils utilisent au moins une technologie VMware, pour la majorité d’entres-eux ils utilisent au minimum l’hyperviseur vSphere, ce qui rassure les clients finaux car c’est une technologie pérenne, largement répandue, fiable et performante leur permettant ainsi d’accroitre leur business.

Les raisons pour lesquels les clients finaux trouvent un(des) intérêt(s) à consommer ces services ?

  • Diminuer les frais d’infrastructures. Pour certains clients, consommer ces services peuvent coûter moins chers s’ils n’ont pas les outils leur permettant d’optimiser l’utilisation des ressources physiques On Premise, n’ont pas la taille critique pour un contexte spécifique ou encore n’ont pas de temps à passer sur des problèmes de sécurité (comme par exemple) le hacking permanent de site web.
  • N’ont pas et ne souhaitent pas acquérir les compétences pour gérer une infrastructure.
  • Ont besoin d’une agilité qu’ils n’ont pas On Premise et ainsi gagner du temps pour développer et déployer les applications.
  • Ne veulent plus gérer le cycle de vie matériel et logiciel, s’affranchir ainsi des mises à jour et des matrices inter-solutions de plus en plus complexe.
  • Avoir des ressources informatiques à travers le monde sans avoir à investir dans des data center.
  • Intégrer plus facilement les nouvelles filiales.
  • Respecter les SLAs et les normes comme par exemple HADS pour la santé, ISO 27000 pour la confidentialité des données ou encore la gestion d’archivage des données publique, SIAF et bien d’autres.
  • Avoir un “réceptacle” pour les sauvegardes et/ou une possibilité de relancer les applications en cas de désastre.
  • Proposer des postes de travail virtuels comme une commodité, accessibles depuis n’importe où pour les populations à risque ou ultra nomade.
  • D’être une extension du Data Center On Premise en permettant un “débordement” sur le cloud public.
  • D’héberger des applications nécessitant de gros serveurs puissants pour les BDD type SAP HANA ou au contraire nécessitant beaucoup de petit serveur pour des cluster Hadoop.
  • De bénéficier de gros tuyaux vers Internet, les applications orientées consommateurs externes seront ainsi au plus proche d’Internet.
  • Avoir un hébergement sécurisé par des services provider dont c’est le métier.
  • Une consommation à l’usage et donc la capacité à changer de type de service ou de volumétrie simplement, réduire les risques projets lié à des volatilités ou non prédictibilité suffisante.

Sur quels critères les clients finaux choisissent leur(s) partenaire(s) VCPP ?

  • Présence locale, régionale et/ou international, un client peut vouloir rechercher de la proximité et choisir un partenaire de sa région, un autre peut vouloir choisir un partenaire ayant une couverture internationale pour par exemple une extension au Brésil, en Chine, en Afrique du sud. Il sera peut-être amené à devoir choisir plusieurs partenaires si un seul n’est pas en mesure de tout couvrir.
  • La possibilité de personnaliser des configurations matériels et/ou de machines virtuelles c’est le  “sur mesure”.
  • Qualité de l’interconnexion entres les plaques géographiques.
  • Standardisation, avoir les mêmes hyperviseurs, les mêmes réseaux, les mêmes outils d’opération….
  • Bien sur le prix, les niveaux de services attendus ainsi que les services proposés

Types d’usages généralement proposés :

  • Bare Metal as a Service : les serveurs physiques sont installés, configurés et maintenus automatiquement par le partenaire.
  • vSphere as a Service / vCenter as a service : Les serveurs physique, vSphere et le vCenter sont installés et configurés automatiquement et maintenus par le partenaire. Le client a accès au vCenter et l’utilise comme habituellement.
  • VM as a Service : Le client dispose d’un portail pour créer des VMs sur une infrastructure déjà opérationnel, elle est en générale mutualisée et partagée par plusieurs clients.
  • SDDC as a Service, tous le composants du SDDC VMware (vSphere, vSAN, NSX et vCenter) sont installés automatiquement.
  • Les postes de travail virtuels.
  • Des Service applicatif.
  • Mise à disposition d’un cloud privé, portail de self service avec un parfaite maîtrise des services , de la sécurité et des coûts.
  • Service avec validation de certification ou contexte (HADS, PCI-DSS, SIAF …).

Il existe donc une multitude de raisons pour travailler avec un partenaire VMware fournisseur de services mais la principale réside sur l’utilisation d’une ou plusieurs solution VMware gage de sécurité, de fiabilité et simplicité .

 

La Fondation Digitale pour la Transformation Digitale

De nos jours, la nouvelle monnaie c’est la rapidité.

Dans tous les secteurs d’activités les entreprises subissent une nouvelle concurrence venue de la digitalisation, ces entreprises l’ont bien compris mais malheureusement bien souvent trop tard, rares sont celles qui l’ont anticipée, elles sont réactives. Il existe de multitude d’exemples comme Uber avec les taxis et Airbnb avec l’hôtellerie. Ce qui caractérise cette concurrence, c’est l’apport ou l’amélioration d’un service par un nouvel acteur sur un secteur d’activité dominé par des acteurs historiques et qui n’ont pas sus/voulus évolués.

Ces nouveaux services nécessitent d’adapter ou de développer des logiciels à de nouveaux usages et à de nouvelles méthodes de consommation. Pour une entreprise qui vient de se créer c’est simple, elles n’ont pas d’infrastructure et de patrimoine d’applications à faire évoluer, elles peuvent démarrer directement sur un environnement agile et à partir de là développer ces applications. En revanche pour les entreprises existantes ca sera beaucoup plus complexe et cette complexité et proportionnelle à la taille de l’entreprise. Plus les entreprises sont importantes et plus elles auront à faire évoluer un patrimoine d’applications important et auront aussi besoin d’en developper de nouvelles. Pour cela elles devront entreprendre une transformation du personnel et des process mais aussi une Transformation Digitale ! Un “Digital Business” nécessite une “Digital Foundation”

 

La transformation digitale s’opère sur la fourniture des applications, l’hébergement des applications et la consommation des applications tout en renforçant la sécurité. Elle doit résulter d’une foundation unique pour différents usages. Elle repose évidement sur du matériel pour lequel on peut exiger performance, capacité et fiabilité. L’autre partie c’est la part belle du logiciel, c’est elle qui va apporter l’agilité nécessaire à la digitalisation. La fondation peut-être dans le data center privé comme sur une infrastructure cloud public. Elle doit pouvoir héberger des applications classiques comme des Cloud Native Apps qui seront consommées via des desktops, des objets connectés ou des smartphones.

 

 

La transformation digitale doit être impulsée par la direction et répercutée dans toute la chaine managériales car elle implique l’adhésion du personnel qui lui aussi doit être prêt à se “transformer”. C’est la partie la plus compliquée, il faut s’attendre à avoir des résistances, je l’ai souvent constaté. La gestion des couches basses de part l’automatisation nécessitera de moins en moins de personnel qui sera désormais de en plus en plus proche du métier de l’entreprise. L’IT devient partenaire du business voire même partie prenante du business. Cependant c’est difficile de faire comprendre à un administrateur de stockage qu’il n’aura plus de baie de stockage et de réseau SAN à administrer (cf article sur la virtualisation du stockage  http://loeilduse.fr/?p=43). Difficile de faire comprendre à un administrateur réseau que la création de réseaux va être déportée dans une cloud management platform ou un orchestrateur de containers. Ils doivent pourtant comprendre qu’ils tentent de résister à un rouleau compresseur qu’est la tendance du marché et c’est une question de temps avant que la transformation ne s’opère. Ils doivent saisir l’occasion pour s’orienter vers de nouvelles technologies comme le cloud (privé, public et/ou hybride), le DevOps, les containers, la mobilité, l’IOT, les blockchains, …, la liste est longue et il y a quoi bien s’occuper.

Pour être efficiente, la fondation digitale doit être appliquée sur toute la chaine allant des ressources hébergeant les applications jusqu’à l’utilisateur qui va les consommer à l’instar de la sécurité (cf article la sécurité de bout en bout http://loeilduse.fr/?p=249). Très important, cette chaine doit être constituées de composants qui s’intègres les uns aux autres nativement sans effort. Pour diminuer les risques, il est indispensable d’avoir tous ces composants issus du même éditeur.

Commençons par l’hébergement sur le Data Center privé, ensuite le Cloud Hybrid pour finir par la consommation via les terminaux :

 

Le Data Center Privé 

L’agilité va permettre de gagner du temps en étant plus réactif voire proactif.  Pour cela, il faut le moderniser en le rendant agile afin que, le patrimoine d’applications puisse en bénéficier, pour y héberger les nouvelles applications Cloud Native et pour renforcer la sécurité existante (car on ne sécurise pas les Cloud Native Apps et les containers comme on le faisait avec les applications traditionnelles). Cette agilité ne peut être obtenue que par le SDDC (Software Defined Data Center) en virtualisant tous les composants du Data Center. Une fois virtualisés, ils pourront être automatisés presque robotisés! L’infrastructure physique, elle est là pour être capacitive, performante et fiable avec un sas de sécurité pour filtrer tout ce qui y rentre et tout ce qui sort. Le SDDC va utiliser ces ressources pour y exécuter tout type d’applications et sera couplé à une Cloud Management Platform ou un orchestrateur de container comme Kubernetes (cf article sur PKS http://loeilduse.fr/?p=158)

L’architecte peut ainsi en tout autonomie “désigner” son application en y intégrant tous les composants du SDDC dont il a besoin. Ci-dessous un exemple de design d’un service web en cluster, la création du réseau, l’insertion de service Load Balancer et l’application de règle de sécurité. Plus besoin de faire des demandes à différences services pour obtenir les ressources dont il a besoin.

 

Une fois terminé, l’architecte peut soit la déployer ou soit le mettre à disposition via un catalogue de services pour des utilisateurs puissent la déployer ultérieurement :

 

Aboutir à ce résultat n’est pas d’un point de vue technique si compliqué que ça, à condition, j’insiste, que tous les composants logiciels du SDDC soient prévus pour fonctionner nativement ensemble, ainsi les efforts d’intégrations et de maintient en condition opérationnel seront réduits. La mise à jour du SDDC se fait sans avoir à se soucier de l’intéropérabilité des versions des composants, le SDDC Manager se charge de ça.

Il ne faut pas aussi que le SDDC n’est d’adhérence avec la couche matériel, vous devez être libre de choisir et de changer les composants physiques avec un minimum d’impact. Ainsi les switches peuvent être des Cisco, des Arista, des juniper, ou autre, les serveurs peuvent être des HP, des DELL, des Lenovo, ou autre, ça n’a pas d’importance que ce soit à la création du SDDC ou durant son cycle de vie.

 

Le Cloud Hybride

Hybride au sens où on peut transférer des applications du cloud public vers le cloud privé et vice-versa en fonction des besoins. Ce qui est recherché :

  • Ce sont des services innovants utilisables à la demande sans avoir à les installer et à les administrer.
  • Des ressources physiques à la demande sans avoir à anticiper les achats matériels. Si un gros projet nécessitant beaucoup de ressources non disponibles sur le Data Center privé, il faudrait attendre de les commander, de les installer et les configurer avant de pouvoir commencer le projet. Avec le Cloud Hybrid on commande un SDDC et deux heures après il est disponible pour démarrer le projet. Si vous souhaitez le voir au final sur votre Data Center privé vous pourrez le rapatrier une fois les nouvelles ressources disponibles. Pour que ce soit faisable et sans risque, il faut que le SDDC public soit le même que le SDDC privé (à minima le même hyperviseur). Pour en savoir plus je vous conseil cet article : http://loeilduse.fr/?p=74.

 

Les terminaux

Une fois les applications déployées il faut les consommer, le problème c’est qu’elles prolifèrent et c’est difficile de s’y retrouver tellement on en a. En plus maintenant ont a plusieurs terminaux : un smartphone (Android ou IOS), une tablette (Android, IOS ou Windows) ou laptop (Mac, Chrome OS ou Windows).

Pour être efficace, l’utilisateur doit avoir une visibilité directe des applications dont il a besoin et ce quelque soit le terminal qu’il utilise. Ci-dessous une copie d’écran du portail avec les applications que j’utilise le plus souvent sur mon Mac ou mon S8.

En plus d’avoir accès rapidement aux applications, on n’a plus à se soucier d’avoir à gérer la complexité des différentes politiques de mot de passe par application, une fois connecté via son compte principal, l’utilisateur n’a plus besoin de s’authentifier à nouveau pour accéder à ses applications et ce quelque soit son mode d’hébergement (SaaS, Web ou installées sur le terminal) (cf article la sécurité de bout en bout, chapitre sécuriser les accès à distance  http://loeilduse.fr/?p=249).

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.