vSphere 6.5 : le chiffrement à l’honneur

On continue cette série de billets consacrés à vSphere 6.5. Celui-ci est dédié à un nouveau module de chiffrement intégré à ESXi qui va permettre de sécuriser à la fois les données stockées sur les datastores mais aussi pendant les phases de vMotion ! A n’en pas douter, cela ouvre de nouvelles perspectives particulièrement intéressantes pour le cloud hybride et l’utilisations de ressource publiques en général : si vous conservez la maîtrise de vos clefs de chiffrement (via un service KMS on-premise), vous vous affranchissez de-facto des contraintes d’hébergement (je pense en particulier au secteur de la santé où les Hébergeurs de Données de Santé sont une obligation, désormais, en dehors des hôpitaux et établissements officiels pour leurs propres données patient).

Voyons cela de plus près.

Vous pouvez désormais chiffrer vos VMs

Première fonctionnalité phare, la possibilité de chiffrer une VM. Le chiffrement en lui-même utilise une méthode asymétrique, comme la plupart des systèmes aujourd’hui. Vous disposez d’une paire de clefs publique/privée pour chaque machine concernée. La clef privée vous permet de déchiffrer à la volée (via un module kernel ESXi) les données stockées sur le disque et la clef publique est utilisée pour le chiffrement initial. Ici, vCenter n’héberge pas lui-même les couples de clefs et il vous faudra acquérir un système de gestion de clefs (KMS en bon anglais technique) pour vous servir de coffre-fort.

Evidemment, tout cela est parfaitement intégré et vient se rajouter aux storage policies, déjà présentes sur vSphere 6.0.

Le principe est relativement simple sur le papier, par contre, on imagine les contraintes fortes en terme d’optimisation pour pouvoir déchiffrer/chiffre à la volée les I/O disques. Le nerf de la guerre ici est vraiment la performance attendue sur ce type de machine. Quel overhead le déchiffrement/chiffrement va-t-il générer sur la VM, difficile à dire pour le moment sans l’avoir vraiment testé. Cela n’a pas encore été évoqué, mais j’imagine qu’on devrait à terme pouvoir s’appuyer sur des ASIC spécialisés dans l’algorithme RSA pour décharger cette tâche du CPU. Bien sur le papier, donc, mais attention aux latences des I/Os …

Concernant l’intégration et la gestion de la sécurité autour de ce nouveau système de chiffrement, VMware à très bien fait les choses car il existe désormais un nouveau rôle spécifique dans les permissions vCenter permettant de limiter les opérations autorisées aux les administrateurs aux seules fonctions vraiment essentielles à la bonne MCO des VM chiffrées. Les principales interdictions, par rapport aux administrateurs classiques, sont : l’accès console, l’upload ou le download de VM chiffrées ainsi que toutes les opérations de chiffrement/déchiffrement. L’objectif est clair : un administreur “no cryptography” n’a aucun moyen d’accéder aux données de la VM, ni à sa console. Parfait pour de l’IAAS !

Je vous laisse consulter les planches ci-dessous pour vous faire une idée plus précise de la façon dont ça fonctionne techniquement.

Malgré tout cela, il y a intrinsèquement quelques limitations (dont certaines seront peut-être levées lors de releases ultérieures. Attention aussi à la gestion des backups, il faut gérer cela avec précautions évidemment (la partie gestion des clefs est particulièrement critique évidemment).

Enfin, du coté des gestionnaires de clefs supportés, VMware propose dors et déjà un certain nombre de KMS certifiés compatibles comme Vormetric de Thales ou les solutions de Gemalto. La liste devrait s’enrichir assez vite.

“Encrypted vMotion” : chiffrement des données réseau de bout en bout

Corolaire et complément indispensable, s’il en est, du chiffrement des machines virtuelles, les flux vMotion peuvent désormais êtres chiffrés, eux aussi. Là, on privilégie la performance : le chiffrement AES est employé après négociation entre les deux ESXi participant à la migration. A noter que seules les données des VM sont chiffrées, les entêtes de contrôle et de suivi ne le sont pas. En gros, on chiffre le payload, mais pas toute la trame. Ce chiffrement vMotion est par ailleurs totalement indépendant du type de VM transporté : qu’elle soit chiffrée ou non importe peu.

Enfin, il est possible de forcer le chiffrement vMotion ou ne le faire que de manière sélective, en fonction des capacités respectives des ESXi impliqués dans la phase de transfert.

Secure Boot ESXi

Pour terminer cet article sur les nombreuses améliorations de sécurité de vSphere 6.5, sachez que vous pouvez également activer un mode de boot dit “secure boot” sur vos ESXi. Ici, l’objectif est bien entendu de garantir la non compromission des hyperviseurs en vérifiant l’ensemble des “vib” à chaque boot de l’hyperviseur. De plus, dans ce mode, si vous tentez de pousser un package non signé ou dont la signature est invalide, ESXi refusera de l’installer, tout simplement (même avec une option –no-sig-check).

L’ensemble de ces trois grandes nouveauté porte clairement la sécurité globale de vSphere 6.5 à un niveau jamais atteint jusque là. Nul doute que cela va participer encore plus à la confiance générale des environnements VMware pour les problématiques d’hébergements pour professionnels où les confidentialité et la protection des données est un élément important (voire légalement obligatoire).

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *