Assises de la sécurité : les RSSI face au défi de la sécurisation des environnements virtuels

La virtualisation doit-elle conduire à repenser les architectures de sécurité des SI ? Oui... et non. Pour Gérôme Billois, manager de la practice sécurité et gestion du risque du cabinet de conseil Solucom, « dans tous les cas, il faut faire de la sécurité comme on en faisait avant : un serveur, même virtuel, reste un serveur, visible sur le réseau. Même chose pour les postes clients : il ne faut pas oublier les bonnes pratiques. » Le ton est donné : la promesse d’isolation logique des systèmes virtualisés, par l’hyperviseur, ne suffit pas à produire une couche de sécurité suffisante pour renoncer aux méthodes classiques.

Une promesse d’isolation qui a de toute façon ses limites : le risque de « rebond entre machines virtuelles » pour un code malicieux. Reste que, pour Gérôme Billois, la probabilité associée à ce risque « est assez faible. » Même son de cloche chez l'éditeur Sourcefire, où Martin Roesch, directeur technique et créateur du célèbre système de détection d'intrusion Snort, assure : « le meilleur moyen de sécuriser l’hyperviseur, c’est déjà d’en réduire la taille. ESX, par exemple, ne pèse que 6 Mo. » Pour le reste, si l’hyperviseur concentre toutes les communications – et constitue de facto un nœud particulièrement intéressant pour un pirate –, « il s’agit de communications ; des échanges comme tous les autres. C’est un problème classique. » Bref, pour écouter du trafic de machines virtuelles, le faire au niveau de l’hyperviseur n’apporte pas grand chose par rapport à la prise de contrôle d’un commutateur.

Commencer par contrôler l’accès à la console d’administration

En fait, pour Gérôme Billois, le meilleur moyen aujourd’hui de protéger l’hyperviseur, c’est d’abord de contrôler finement et sévèrement les droits d’accès correspondant : « si quelqu’un vient à prendre le contrôle de l’hyperviseur, il peut lancer un déni de service massif. Le risque de pertes de données est également très élevé si quelqu’un venait à supprimer les images des machines virtuelles. » Bref, pour lui, la sécurisation d’un environnement virtualisé doit commencer par la protection de l’administration de cet environnement, en démarrant avec les postes permettant l’accès aux consoles d’administration. Vient ensuite la sécurisation du stockage.

Au-delà, pour se protéger des risques liés aux éventuels défaut d’imperméabilité de l’hyperviseur, « il ne faut pas virtualiser ensemble des systèmes aux besoins de sécurité très différents, » estime Gérôme Billois. Selon lui, mieux vaut créer des silos en fonction des contextes de sécurité : « chez nos clients, on considère même l’organisation des datacenters en fonction des besoins en niveaux de sécurité. »

La sécurité s’invite dans l’hyperviseur

Au-delà, et notamment pour associer étroitement fonctions de sécurité et hyperviseur, on flirte avec la découverte d’un nouveau monde. Pour Martin Roesch, « c’est une assez bonne idée que d'ajouter des outils de contrôle d’application des politiques de sécurité au-dessus de l’hyperviseur. » Une idée séduisante qui permet de gérer une partie des questions de sécurité non plus au niveau des machines virtuelles, mais directement au niveau de l’hyperviseur. Mais là, relève Gérôme Billois, « il n’y a que VMware qui permette ça, avec vSafe. C’est un sujet en pleine évolution. CheckPoint travaille dans ce sens, Cisco aussi. » Une perspective qui ne manque pas d’intérêt : « cela permet de couvrir des menaces de bas niveau comme les rootkits (programme pirate permettant de maintenir un accès frauduleux, ndlr), par exemple. Mais aussi, cela ouvre la voie à une simplification, à un assouplissement de l’infrastructure de sécurité. Par exemple, dans le cadre d’un PCA, on peut migrer une machine virtuelle d’un serveur à l’autre, tout en préservant son contexte de sécurité. »