Sélection de la langue

Government of Canada / Gouvernement du Canada

Rapport du centre pour la cybersécurité sur la virtualisation des centres de données : pratiques exemplaires en matière de virtualisation des centres de données (ITSP.70.010)

De : Centre canadien pour la cybersécurité

Format de rechange : Rapport du centre pour la cybersécurité sur la virtualisation des centres de données : pratiques exemplaires en matière de virtualisation des centres de données (ITSP.70.010) (PDF, 1.1 Mo)

Avant-propos

L’ITSP.70.010 Pratiques exemplaires en matière de virtualisation des centres de données est un document NON CLASSIFIÉ publié avec l’autorisation du dirigeant principal du Centre Canadien pour la cybersécurité (Centre pour la cybersécurité). Ceux et celles qui souhaitent proposer des modifications au présent document doivent s’adresser à leur représentant des Services à la clientèle à :

Centre d’appel du Centre pour la cybersécurité
contact@cyber.gc.ca
613-949-7048 ou 1-833-CYBER-88

Date d’entrée en vigueur

Le présent document entre en vigueur le 27 mars 2020.

Table des matières

Liste des figures

Aperçu

Nombre d’organisations envisagent de virtualiser leurs centres de données dans le but d’optimiser le ratio de consolidation et de simplifier les opérations. Toutefois, il arrive que cette virtualisation soit mise en application en dépit d’une certaine méconnaissance des répercussions que cette approche peut avoir sur de multiples aspects de la posture de sécurité des centres de données visés. En tentant d’accroître ledit ratio de consolidation, les organisations risquent de compromettre, bien qu’involontairement, l’architecture de sécurité de leur réseau. De plus, le remplacement simultané de plusieurs mécanismes d’isolement physique par des équivalents virtuels peut engendrer des risques particulièrement importants pour l’architecture réseau.

Non seulement les centre de donnes virtualisés (CDV) présentent ils les vulnérabilités inhérentes aux centre de données traditionnels, mais il affichent, de surcroît, les nouvelles vulnérabilités qui caractérisent les environnement virtuels. Certes, les menaces qui pèsent sur la virtualisation complexe doivent être prises en compte (p. ex. les programmes malveillants furtifs [rootkit] introduits par le mode de gestion système [SMM pour System Management Mode], les attaques par canal auxiliaire [side channel], ou les détournements de l’hyperviseur [hyperjacking]), mais ce sont les menaces les plus pratiques qui constituent les risques les plus importants pour les CDV. Au nombre de ces menaces tangibles, il convient de signaler la configuration incorrecte, la compromission des interfaces de gestion ainsi que les attaques conventionnelles sur l’hyperviseur ou les machines virtuelles (VM pour Virtual Machines).

En définitive, il sera important de concevoir le CDV de façon à pallier les vulnérabilités que l’on retrouve couramment dans les centres de données tout autant que les vulnérabilités découlant des environnements virtualisés complexes. En l’occurrence, il est tout à fait possible de sécuriser adéquatement les CDV en ayant recours à diverses mesures de protection et en observant certaines pratiques exemplaires. Les mesures de protection et les pratiques exemplaires devront agir sur chacune des couches de l’environnement virtuel et tenir compte des interactions entre lesdites couches. Le présent rapport propose un aperçu de la notion de CDV, fait état des vulnérabilités propres aux CDV traditionnels et formule des recommandations pour la conception d’un CDV sécurisé.

1 Introduction

Bon nombre d’organisations envisagent de consolider leurs centres de données traditionnels dans des centres de données virtualisés (CDV) Footnote 1 dans le but de réduire les dépenses, et ce, grâce à l’optimisation des ratios de consolidation et aux économies d’échelle qui devraient en découler. Grâce à certaines avancées comme le processeur multicœur et la technologie Hyperthread, les ratios de consolidation sont désormais si élevés que la virtualisation est devenue incontournable sur le plan de l’exploitation.

Toutefois, nombre d’organisations optent pour la virtualisation sans avoir intégralement saisi les implications que la virtualisation peut avoir – en général et surtout dans le contexte des CDV – sur la sécurité. En effet, non seulement les CDV présentent ils les vulnérabilités inhérentes aux centre de données traditionnels, mais ils affichent, de surcroît, des vulnérabilités qui leur sont propres. Ainsi, en tentant d’accroître ledit ratio de consolidation, les organisations risquent de compromettre, bien qu’involontairement, l’architecture de sécurité de leur réseau.

Il conviendra donc que les organisations connaissent bien les répercussions que cette approche peut avoir sur de multiples aspects de la posture de sécurité des CDV. Qui plus est, ces organisations devront tenter de prévoir les répercussions de leurs décisions, et ce, à chacune des étapes de la conception et du déploiement de leur CDV. C’est seulement après avoir pris toutes ces précautions possibles que l’on pourra acquérir la certitude que les vulnérabilités de l’infrastructure auront été atténuées suffisamment pour résister aux menaces connues.

1.1 Politiques déterminante

Plusieurs lois et politiques du gouvernement du Canada (GC) énoncent des exigences en matière de sécurité des TI. Ainsi, les ministères du GC doivent veiller à ce que leurs politiques et leurs procédures qui encadrent la sécurité des TI respectent les politiques du Secrétariat du Conseil du Trésor (SCT) qui sont énumérées ci-dessous :

  • Politique sur la sécurité du gouvernement (PSG) [1]Footnote 2;
  • Norme opérationnelle de sécurité : Gestion de la sécurité des technologies de l’information (GSTI) [2]
  • Loi sur la protection des renseignements personnels [3];
  • Loi sur la gestion des finances publiques [4];
  • Ligne directrice sur l’utilisation acceptable des dispositifs et des réseaux [5]; and
  • Politique sur la gestion du matériel [6].

Les organisations non GC peuvent utiliser ces politiques comme documents de référence lors du développement de leurs propres cadres de politique de sécurité informatique.

1.2 Environnements visés

Le présent document énonce des conseils réservés aux systèmes de TI NON CLASSIFIÉ qui sont susceptibles de contenir des informations ou des biens sensibles dont la compromission pourrait causer un préjudice aux intérêts d’une entité, en l’occurrence une personne ou une organisation (c. à d. des renseignements personnelsFootnote 3 ou des informations d’entrepriseFootnote 4). Dans le contexte du GC, les conseils ici formulés peuvent être mis en œuvre dans les systèmes de TI qui contiennent de l’information PROTÉGÉ A ou PROTÉGÉ B.

Le présent document ne contient aucun conseil qui puisse s’appliquer aux systèmes de TI contenant des informations ou des biens hautement sensibles d’intérêt personnel (c. à d. de l’information PROTÉGÉ C dans le contexte du GC) ou des informations ou des biens sensibles d’intérêt national (c. à d. de l’information classifiéeFootnote 5). Les systèmes de TI qui protègent ce type d’information nécessitent des mesures particulières dont il ne sera pas question dans le présent document.Footnote 6

1.3 Relation avec le processus de gestion des risques liés aux TI

Le document du Centre pour la cybersécurité intitulé La gestion des risques liés à la sécurité des TI : une méthode axée sur le cycle de vie (ITSG 33) [9] présente deux niveaux d’activités de gestion des risques liés aux TI : les activités s’appliquant au niveau organisationnel et les activités s’appliquant au niveau des systèmes d’information. Ces deux niveaux d’activités sont schématiquement illustrés à la figure 1.

Figure 1 : Processus de gestion des risques liés à la sécurité des TI

Description détaillée suit immédiatement
Description détaillée

Processus de gestion des risques liés à la sécurité des TI

1.3.1 Activités au niveau organisationnel

Les activités au niveau organisationnel devraient être intégrées au programme de sécurité de l’organisation de façon à permettre la planification, l’administration, l’évaluation et l’amélioration de la gestion des risques liés à la sécurité des TI qui pourraient peser sur l’organisation. Les conseils du présent document devront être pris en compte au moment de la planification, du déploiement, de la surveillance et de l’évaluation. Ces activités sont décrites dans le détail à l’annexe 1 de l’ITSG 33 [10].

1.3.2 Activités au niveau des systèmes d’information

Les activités au niveau des systèmes d’information devraient être intégrées au cycle de vie d’un système d’information pour répondre aux besoins des activités opérationnelles sur le plan de la sécurité des TI, pour veiller à ce que les contrôles de sécurité appropriés soient appliqués et produisent l’effet escompté, et pour faire une évaluation continue desdits contrôles de sécurité dans le but de produire des rapports et de donner lieu, le cas échéant, à des mesures correctives. Au reste, le contenu du présent document devra être pris en compte lors des phases suivantes :

  • initiation;
  • développement et acquisition;
  • intégration et installation;
  • exploitation et maintenance.

Ces activités sont décrites dans le détail à l’annexe 2 de l’ITSG 33 [10].

1.4 Approche

Les pratiques exemplaires exposées dans le présent rapport ont été conçues à partir de nombreuses sources, notamment l’industrie (les fournisseurs et les analystes), le gouvernement des États Unis (p.ex. le National Institute of Standards and Technology [NIST]), et l’expertise interne.

Le présent rapport fait état de pratiques exemplaires permettant de sécuriser les centres de données virtualisés. C’est à l’organisation qui opte pour la virtualisation de son centre de données qu’il revient de mettre en œuvre lesdites pratiques exemplaires, de les perfectionner en fonction des processus et de garantir un niveau d’assurance de la sécurité qui convienne à ses propres besoins de même qu’à ceux de ses clients. À la section 8 de l’annexe 2 de l’ITSG 33 [10], il est question dans le détail de la notion d’assurance de la sécurité. En outre, l’ITSG 33 stipule que le niveau d’assurance de la sécurité (SAL pour Security Assurance Level) consiste en un ensemble présélectionné d’exigences d’assurance qui garantissent la fiabilité de l’ingénierie de sécurité et des travaux de documentation effectués par l’équipe de projet. En définitive, les contrôles de sécurité mis en place sont censés donner les résultats escomptés et répondre aux besoins opérationnels en matière de sécurité. Il conviendra donc de considérer que les organisations qui suivent les pratiques exemplaires décrites dans le présent document, à un SAL de 3, pourraient raisonnablement conclure que leur CDV est adéquatement protégé contre les menaces conçues à l’intention des environnements virtualisés et exécutées par les auteurs disposant de moyens hautement sophistiqués (menace délibérée 5 [Td5]) ou inférieurs. C’est à cet état que le terme sécurisé renvoie tout au long du présent document. Il ne signifie donc pas que le niveau de sécurité soit absolu.

1.5 Portée

Le présent rapport aborde la question de la virtualisation des centres de données, une notion qui englobe bon nombre d’activités de virtualisation nécessaires à la création d’un CDV. L’une de ces activités de virtualisation consiste en la virtualisation des serveurs. En effet, la virtualisation des serveurs procède à la virtualisation intégraleFootnote 7 des ressources, le plus souvent à la virtualisation du matériel (bare-metal virtualization)Footnote 8. La virtualisation des postes de travail, laquelle a recours à la virtualisation hébergée (hosted virtualization)Footnote 9, est devenue désuète puisqu’elle donne lieu à certains problèmes de compatibilité sur le plan de l’architecture et de la sécurité. À proprement parler, il ne sera question ni de la virtualisation des applications ni de la virtualisation des systèmes d’exploitationFootnote 10 dans le présent rapport.

Les pratiques exemplaires énoncées dans le présent rapport visent tous les CDV. Au reste, les conseils ici formulés se veulent exempts de toute norme propriétaire. Ce qui signifie que les auteurs du présent rapport ont fait le nécessaire pour éliminer tout conseil de sécurisation pouvant relever d’un fournisseur particulier.

Le présent rapport se concentre surtout sur la conception des CDV et sur les aspects techniques qui en découlent. L’exploitation des CDV comporte nombre de questions de sécurité qui relèvent de la sphère opérationnelle, mais qui s’éloignent considérablement de la portée du présent rapport. Pour obtenir de plus amples détails concernant les contrôles de sécurité opérationnelle, prière de consulter l’ITSG 33 [10].

1.6 Hypothèses

Les conseils énoncés dans le présent document s’adressent un lectorat disposant d’une compréhension élémentaire des notions et des termes liés au domaine de la virtualisation.

2 Centres de données virtualisés : survol des notions

2.1 Aperçu

La virtualisation introduit une nouvelle couche d’abstraction entre les ressources physiques de soutien et les services qui reposent sur ces ressources. Dans le cas d’un CDV, la virtualisation sert à recréer abstraitement bon nombre des ressources physiques, notamment les serveurs, les réseaux et le stockage. En recréant ces ressources, le CDV est en mesure d’accroître considérablement son ratio de consolidationFootnote 11 et de développer sa polyvalence. Toutefois, la réalisation de ce type d’environnement peut comporter des risques sur le plan de la sécurité (lire l’encadré, ci-dessous). La présente section se penche sur les sept couches intégrales que l’on peut observer dans les CDV. Illustrées dans la figure 2, ces couches constituent la base des affirmations du présent document.

Figure 2 : Couches des centres de données virtualisés

Description détaillée suit immédiatement
Description détaillée

Couches des centres de données virtualisés

Équilibre entre sécurité et polyvalence : Les organisations qui mettent sur pied un centre de données s’intéressent à la virtualisation principalement pour accroître le ratio de consolidation et pour développer la polyvalence du système. L’accroissement du ratio de consolidation se traduit généralement par des économies budgétaires. En recréant abstraitement les ressources physiques, la virtualisation facilite la tâche des organisations qui souhaitent optimiser leurs ressources en fonction des besoins internes et des facteurs externes. De plus, la virtualisation simplifie grandement la gestion et la répartition des ressources. Cependant, cette souplesse n’est pas sans présenter certains risques sur le plan de la sécurité. La recherche d’un juste équilibre entre la sécurité et la polyvalence est un thème récurrent dans le présent document. (Voir les Pratiques exemplaires concernant les centres de données virtualisés (PE CDV no 1 [section 3]).

2.2 Réseautage

Le réseautage d’un centre de données traditionnel est relativement simple. Par contre, le réseautage d’un CDV et passablement plus complexe. Ainsi, la présente section analysera les types de réseaux qui conviennent aux CDV. Elle abordera également l’utilisation des zones de sécurité d’un réseau qui accueille un CDV.

2.2.1 Exigences concernant les réseaux

Quatre réseaux sont habituellement requis pour un CDV. Ces réseaux peuvent être séparés physiquement ou logiquement, ou encore peuvent avoir simultanément recours aux deux types de séparationFootnote 12. L’avantage des réseaux séparés physiquement est qu’ils garantissent une séparation complète, mais ils sont coûteux et posent certaines difficultés. En revanche, les réseaux séparés logiquement sont faciles à concevoir et peu coûteux, mais, on l’aura deviné, posent certaines difficultés sur le plan de la séparation. En l’occurrence, les quatre réseaux requis sont les suivants : le réseau de données, le réseau de gestion, le réseau de stockage et le réseau de migration à chaud. Voici une description de chacun des réseaux en question.

2.2.1.1 Réseau de données

Le réseau de données est utilisé pour toutes les communications en provenance et à destination des serveurs du CDV. En quelque sorte, il s’apparente au réseau central que l’on retrouve dans les environnements qui ont recours aux réseaux physiques. Le réseau de données devrait être séparé des autres réseaux pour des motifs de confidentialité, d’intégrité et de disponibilité.

2.2.1.2 Réseau de gestion

Dans un CDV, le réseau de gestion est utilisé pour l’acheminement de toutes les communications qui circulent entre l’interface de gestion de la virtualisation et l’hyperviseur. Le réseau de gestion sépare le trafic de gestion servant à l’administration ou à la maintenance (c. à d. surveillance, journalisation, mises à niveau logicielles, etc.) des données traitées et stockées dans le CDV. En l’occurrence, le réseau de gestion devrait être isolé et sécurisé de façon à empêcher les auteurs de menaces d’obtenir l’accès privilégié aux ressources ou de compromettre l’infrastructure virtuelle, et à garantir la disponibilité de ce réseau de gestion advenant un incident visant le réseau de données.

2.2.1.3 Réseau de stockage

Le réseau de stockage (SAN pour Storage Area Network) (SAN)Footnote 13 est utilisé pour l’acheminement de toutes les communications circulantes entre l’hyperviseur et la matrice de disques servant au stockage. Il sert principalement à transférer les MV depuis la matrice de stockage – où les MV sont conservées – vers le serveur où ces MV seront exploitées. Le SAN devrait être isolé de façon à empêcher un auteur de menace d’accéder aux MV qui seraient en cours de transfert. Certaines technologies de stockage (p. ex. la technologie d’interconnexion Fibre Channel) doivent tourner sur un réseau physique distinct pour des raisons techniques.

Il conviendra de noter que le réseau de stockage dont il est question dans la présente section est celui qui est requis pour la virtualisation. En l’occurrence, ce réseau de stockage sert principalement à transférer les MV depuis les matrices de stockage – où les MV sont conservées – vers le serveur physique où lesdites MV seront hébergées. En plus du stockage virtualisé, il faut absolument prévoir du stockage de données d’entreprise. Le stockage des données d’entreprise devrait employer une infrastructure de stockage distincte.

2.2.1.4 Réseau de migration à chaud

Le réseau de migration à chaud est utilisé pour transférer les MV entre les serveurs d’une même zone de sécurité réseau pour des raisons de rendement ou de maintenance. Le réseau de migration à chaud devrait être isolé pour des motifs de confidentialité et d’intégrité, dans le but d’empêcher un auteur de menace d’obtenir l’accès aux MV – et plus particulièrement à la mémoire des MV – pendant que ces MV sont en cours de transfert. L’isolement permet également de prévenir les problèmes de disponibilité pouvant résulter de conflits entre les diverses activités d’un réseau de données liées à la migration des MV.

2.2.2 Zones de sécurité réseau

Les zones de sécurité réseau permettent de procéder au partitionnement logique du réseau de données tout en appliquant à une politique de sécurité globale et des obligations communes en matière de sécurité. Les services qui ont des besoins semblables en matière de sécurité sont regroupés au sein d’une même zone de sécurité réseau et sont protégés conformément une même stratégie de sécurité conçue en fonction du degré de sensibilité des services fournis ou des données traitées. Du reste, les zones de sécurité réseau facilitent l’application d’une stratégie de défense approfondie. En l’occurrence, les ressources plus sensibles sont protégées par une succession de mesures de protection. Les publications Exigences de base en matière de sécurité pour les zones de sécurité de réseau au sein du gouvernement du Canada (ITSG 22)[11] et Établissement des zones de sécurité dans un réseau – Considérations de conception relatives au positionnement des services dans les zones (ITSG 38) [12] contiennent des conseils pour la mise en place de zones de sécurité réseau dans un environnement du GC.

Les zones de sécurité réseau sont mises en place dans un CDV de la même façon que dans les réseaux physiques semblables. Toutefois, dans le cas des CDV, il est essentiel de veiller à ce que la virtualisation n’entraîne aucun risque, même accidentel, de compromission de l’intégrité des zones de sécurité réseau ou des lignes de démarcation séparant les zones de sécurité réseau. (Voir PE CDV no 2 [section 3].)

Les zones de sécurité réseau requises pour tout CDV sont illustrées à la figure 2 :

  • zone public (ZP);
  • zone d’accès public (ZAP);
  • zone de travail (ZT);
  • zone d’accès restreint (ZAR);
  • zone de gestion (ZG).

Figure 3 : Zones de sécurité réseau d’un CDV

Description détaillée suit immédiatement
Description détaillée

Zones de sécurité réseau d’un CDV

Frontière/points d’interface entre les zones : Les frontières de sécurité – ou les points d’interface entre les zones (ZIP pour Zone Interface Points) – se situent entre les zones de sécurité réseau. Elles comportent généralement des coupe feux ou des routeurs de filtrage qui contrôlent les communications en provenance et à destination des zones. De plus, elles sont fréquemment dotées de systèmes de détection des intrusions (IDS pour Intrusion Detection Systems) qui surveillent le trafic dans l’intention de détecter les comportements inhabituels, et de systèmes de prévention des intrusions (IPS pour Intrusion Prevention Systems) qui réagissent à toute détection de comportement inhabituel. (À la section 2.8, il est question de la virtualisation des appliances de sécurité à l’intérieur des frontières.)
2.2.2.1 Zone public

Une zone publique (ZP) consiste en un réseau se trouvant à l’extérieur de l’espace contrôlé du CDV.

2.2.2.2 Zone accès public

La zone d’accès public (ZAP) agit comme intermédiaire d’accès entre la zone de travail (ZT) et la ZP. La ZAP sert à mettre un terme aux sessions de protocole entre la ZT et la ZP dans les deux directions et à lancer de nouvelles sessions de protocole vers une destination établie, ce qui s’exécute généralement au moyen de serveurs mandataires (proxy servers). Les hôtes qui hébergent des applications ou des données essentielles ne devraient pas se trouver dans la ZAP. Or, depuis le CDV, l’accès aux autres réseaux devrait passer uniquement par l’intermédiaire de la ZAP.

2.2.2.3 Zone de travail

La zone de travail (ZT) est l’environnement standard dans lequel sont exécutées les opérations courantes. Dans le cas des CDV, cette zone comprend la majorité des serveurs, auxquels les utilisateurs peuvent accéder depuis un point externe en passant par les services mandataires de la ZAP. Les CDV pourraient également comprendre des systèmes pour utilisateurs terminaux (c. à d. des postes de travail) que l’on installerait dans cette zone de travail. Cependant, il est recommandé de prévoir une séparation entre les systèmes pour utilisateurs terminaux de la ZT et les serveurs de la ZT.

2.2.2.4 Zone d’accès restreint

La zone d’accès restreint (ZAR) renferme des données et des services sensibles, voire des éléments critiques, notamment des services et des informations de nature sensible. Dans un CDV, le réseau de stockage (défini à la section 2.2.1.3) constitue une application particulière de la ZAR servant au stockage des images virtuelles.

2.2.2.5 Zone de gestion

C’est dans la zone de gestion (ZG) que sont situés les systèmes d’administration qui servent à la gestion des systèmes hébergés dans la ZAP, la ZT et la ZAR. Il importe de veiller à ce que la ZG ne soit pas soumise à la séparation découlant de l’utilisation des autres zones de sécurité réseau. (Voir PE CDV no 3 et no 4 [section 3].)

2.2.3 Virtualisation des fonctions réseau

Dans un CDV, les fonctions de consolidation et de virtualisation peuvent s’appliquer aux composantes réseau. Le recours au réseautage logiciel (SDN pour Software Defined Networking) et à la virtualisation des fonctions réseau (NFV pour Network Function Virtualization) contribue à transformer certaines composantes réseau, notamment les calculs et le stockage, en fonctionnalités conviviales. En revanche, même si ces technologies facilitent considérablement les fonctions d’optimisation et de consolidation des CDV, il conviendra de planifier et de configurer adéquatement les fonctions de sécurité relatives au SDN, puisque tout trafic virtualisé selon ces méthodes devient invisible pour les appliances de sécurité et les coupe feux standards qui se trouvent en marge de l’environnement virtualisé.

2.3 Matériel physique

Certes, la couche comprenant le matériel physique est le seul aspect qui soit demeuré semblable à ce que l’on trouve dans un environnement informatique traditionnel, mais il n’en reste pas moins qu’on relève également des différences significatives. La compatibilité matérielle, les processeurs, les adaptateurs de réseau et les commutateurs sont quatre facteurs importants des exigences visant le matériel physique servant de support pour les CDV.

2.3.1 Compatibilité matérielle

La majorité des CDV ont recours à des « hyperviseurs nus » dont l’une des caractéristiques est de tourner directement sur les composantes matérielles. Toutefois, certes, les hyperviseurs s’adaptent à de nombreuses composantes matérielles, mais il faut savoir que ce ne sont pas tous les serveurs qui sont pris en charge. Par conséquent, les fournisseurs d’hyperviseurs tiennent une liste des systèmes matériels qui sont pris en charge.

2.3.2 Processeurs

Les processeurs multicœurs, comme leur nom l’indique, comportent au moins deux cœurs d’unité centrale de traitement (UCT) (ci-après désignée par le terme « processeur »). En l’occurrence, la technologie du multifil simultané (HTT pour Hyperthreading Technology) reproduit un processeur additionnel pour chacun des cœurs de processeur. Par exemple, avec le multifil simultané, un processeur à deux cœurs sera perçu par un système d’exploitation traditionnel comme étant un processeur à quatre cœurs. Avec l’ajout de la mémoire vive (RAM pour Random Access Memory), ces deux technologies accroissent le nombre des MV qui peuvent être prises en charge par un seul et même système.

En outre, depuis 2005, la plupart des processeurs x86 employés dans les CDV sont dotés de l’assistance matérielle à la virtualisation. Même si certains détails peuvent différer sur le plan de la mise en place, l’assistance matérielle à la virtualisation représente, en quelque sorte, une extension de l’architecture x86 et permet d’optimiser la performance tout en renforçant la sécurité des environnements virtualisés. Au reste, de plus amples détails concernant l’assistance matérielle à la virtualisation sont présentés à la section 2.4.1.

2.3.3 Adaptateurs de réseau

Dans les centres de données traditionnels, la plupart des serveurs ont un nombre limité d’adaptateurs de réseau. Dans un CDV, les serveurs disposent d’un plus important nombre d’adaptateurs de réseau, ce qui permet de prendre en charge les divers réseaux nécessaires et de garantir une certaine redondance.

2.3.4 Dispositifs réseau

Grâce au SND, les fonctions réseau comme la commutation, le routage, et le filtrage par coupe-feu peuvent être intégrées au logiciel au moyen de la matrice sous-jacente formée par les commutateurs physiques. Ainsi, plusieurs réseaux peuvent être pris en charge par une même structure, laquelle est logiquement divisée au moyen de réseaux locaux virtuels (VLAN pour Virtual Local Area Networks). Les commutateurs ne sont pas forcément tous compatibles avec les divers types de SND. Par conséquent, il conviendra d’établir si le SDN est envisageable et, le cas échéant, de savoir dans quelle technologie il s’agira d’investir.

2.4 Hyperviseur

Également appelé « contrôleur de machine virtuelle » (VMM pour Virtual Machine Monitor), l’hyperviseur interagit directement avec le matériel physique du système. L’hyperviseur (voir illustration de la figure 2) exécute la répartition et la planification des accès aux ressources des serveurs physiques distribuées parmi les MV, tout en garantissant un degré d’isolement adéquat entre lesdites MV. Dans le cas des CDV, c’est l’hyperviseur nu qui est utilisé dans la très grande majorité des cas. (Voir PE CDV no 5 [section 3].) La présente section se penche sur les anneaux de protection, le partitionnement des ressources et sur le réseautage virtuel, trois éléments importants de l’hyperviseur.

2.4.1 Anneaux de protection

Les anneaux de protection représentent la hiérarchie des niveaux de privilège qui ont été appliqués aux processeurs x86 pour garantir une tolérance aux pannes et assurer une protection contre le code malveillant. Il conviendra de saisir l’importance des anneaux de protection pour bien comprendre les vulnérabilités dont il est question à la section 3.3. L’assistance matérielle à la virtualisation (voir la figure 4) est couramment mise en œuvre dans les CDV et comporte les anneaux de protection suivants :

Figure 4 : Anneaux de protection pour l’assistance matérielle à la virtualisation x86

Description détaillée suit immédiatement
Description détaillée

Anneaux de protection pour l’assistance matérielle à la virtualisation x86

  • Anneau 3 : Qu’elles fassent partie d’une architecture traditionnelle ou intégralement virtualisée ou encore qu’elles procèdent de l’assistance matérielle à la virtualisation, les applications tournent toujours au niveau de l’anneau 3.
  • Anneau 2 : L’anneau 2 est conçu pour prendre en charge les pilotes de périphériques dans les architectures traditionnelles x86. Il ne sert donc ni pour la virtualisation intégrale ni pour l’assistance matérielle à la virtualisation.
  • Anneau 1: Étant donné qu’ils tournent normalement dans l’anneau 0, les systèmes d’exploitation sont amenés à tenir pour acquis qu’ils tournent dans l’anneau 0. L’hyperviseur arrive à ce résultat en fournissant une traduction binaire d’une demande privilégiée d’un système d’exploitation. Dans l’assistance matérielle à la virtualisation, l’anneau 1 n’est pas utilisé.
  • Anneau 0 : L’anneau 0 est le niveau où le système d’exploitation interagit avec le matériel du système dans une architecture traditionnelle x86. Dans le cas de la virtualisation intégrale, l’hyperviseur tourne dans le même anneau de protection que celui où tournent le noyau et les pilotes de périphériques. Toutefois, dans le cas de l’assistance matérielle à la virtualisation, l’anneau 0 est réservé aux systèmes d’exploitation invités. Comme il est attendu que les systèmes d’exploitation invités tournent dans l’anneau 0, il n’est pas nécessaire de procéder à la traduction binaire.
  • Anneau -1 : L'anneau -1 est un anneau de protection superprivilégié (super privileged) qui est intégré à l'assistance matérielle à la virtualisation. Il est réservé à l’hyperviseur.
  • Anneau -2 : Le code du module de gestion système (SMM pour System Management Module) tourne dans une partie spécialement protégée de la mémoire système et est accessible seulement aux micrologiciels dudit système. Ce mode, qu’il nous arrive d’appeler anneau -2, est le plus privilégié des modes d’exploitation des processeurs x86.

2.4.2 Partitionnement des ressources

L’hyperviseur répartit les ressources matérielles parmi les MV qu’il héberge. Ce partitionnement est généralement exécuté logiquement plutôt que physiquement. Dans le cas du partitionnement logique, l’hyperviseur partage les ressources matérielles parmi les MV. L’hyperviseur peut attribuer ces ressources de telle façon que les MV n’utilisent que les ressources dont elles ont besoin, jamais davantage. Ce type de contrôle exercé sur les MV empêche toute utilisation excessive des ressources susceptible de priver les autres MV des ressources dont elles auraient besoin. Dans le cas du partitionnement physique, l’hyperviseur attribue diverses ressources physiques (p. ex. les partitions disque, les lecteurs de disque et les adaptateurs de réseau) à chacune des MV. Certes, cette approche limite les ressources qui peuvent être utilisées par chacune des MV, mais elle exige des ressources matérielles distinctes, ce qui va à l’encontre de l’objectif principal de la virtualisation. Dans le cas d’un CDV doté d’un hyperviseur nu, les MV ne peuvent communiquer entre elles que par l’intermédiaire des voies de communication réseau permises. Aucune autre voie de communication n’est censée être permise. En revanche, la virtualisation hébergée sur un poste de travail prend généralement en charge la fonction « copier-coller » de même que les transferts de fichiers entre les MV, ce qui élimine bon nombre des contrôles de séparation offerts par la virtualisation sur couche matérielle.

2.4.3 Réseautage virtuel

  • Adaptateurs de réseau virtuels – Des adaptateurs de réseau virtuels, que l’on appelle également « carte d’interface de réseau virtuel » (vNIC pour Virtual Network Interface Card) sont configurés pour chacune des MV et indiquent à celles-ci la façon dont elles doivent se connecter aux réseaux physique et virtuel.
  • Commutateurs virtuels – Les commutateurs virtuels sont les équivalents virtuels des commutateurs physiques. Ils sont employés dans les réseaux virtuels pour interrelier les MV au sein du réseau interne et pour relier les adaptateurs de réseau virtuels aux adaptateurs de réseau physiques.
  • Groupe de ports – Un groupe de ports est un élément qui permet le partitionnement d’un commutateur virtuel, sur le même principe que celui qui régit les ports d’un commutateur physique faisant partie d’un VLAN. Les vNIC sont associées aux groupes de ports d’un commutateur virtuel. Les vNIC peuvent communiquer avec les autres vNIC qui sont associées au même groupe de ports, mais ne peuvent pas communiquer avec les vNIC associées à d’autres groupes de ports, même si ces derniers relèvent du même commutateur virtuel.

2.5 Machine virtuelle (MV)

Une MV intègre tout un système d’information – comprenant des composantes matérielles, un système d’exploitation et des applications – dans un fichier. Le système d’exploitation et les applications n’interagissent pas directement avec les composantes matérielles du système. Ils passent plutôt par l’hyperviseur pour communiquer avec ces composantes matérielles. La présente section examine les trois composantes des MV : le matériel virtuel, le système d’exploitation et les applications.

2.5.1 Matériel virtuel

Le matériel virtuel est une représentation virtuelle des composantes physiques. L’hyperviseur virtualise les composantes matérielles de chacune des MV de façon à ce que le système d’exploitation hébergé se comporte comme s’il tournait vraiment sur un système physique. Plus spécifiquement, chaque élément hébergé agit comme s’il disposait de ses propres composantes matérielles, notamment le processeur, la mémoire, le stockage (disque dur, cédérom, disques vidéo), les contrôleurs de stockage, les cartes d’interface de réseau (généralement Ethernet), pilotes d’affichage et de son, clavier et souris. Pourtant, les MV n’ont aucun accès direct au matériel; elles ne voient que les dispositifs virtuels.

Dans le cas de la mémoire, chaque MV dispose de mémoire vive, qu’elle considère comme exclusivement la sienne, alors qu’en fait, la mémoire physique est partitionnée puis attribuée aux MV. La mémoire qui a été attribuée à une MV est dès lors mise à zéro. Le logiciel de virtualisation emploie un certain nombre de méthodes permettant d’attribuer plus de mémoire que ce que la mémoire physique contient véritablement, ce qui réduit le coût associé aux mémoires.

2.5.2 Système d’exploitation

Une MV est en mesure d’héberger la majeure partie des systèmes d’exploitation d’entreprise courants. Le système d’exploitation est quasi identique aux systèmes d’exploitation tournant sur des composantes matérielles. Souvent, le système d’exploitation ne voit pas qu’il tourne plutôt dans un environnement virtuel.

2.5.3 Applications

Une MV est en mesure d’héberger presque tous les types d’application. En outre, l’application est quasi identique aux applications qui tournent dans les environnements traditionnels. Du reste, les applications ne sont généralement pas en mesure de voir qu’elles tournent dans un environnement virtualisé.

2.6 Gestion

La séparation des tâches renvoie au fait de répartir les rôles et les responsabilités de façon telle qu’un individu ne serait pas en mesure de perturber, à lui seul, un processus essentiel. La séparation des tâches exigeFootnote 14, pour un ensemble de transactions donné, qu’aucun individu ne puisse à lui seul avoir les droits permettant d’exécuter toutes les transactions dudit ensemble. On cite souvent en exemple des transactions distinctes qui sont requises pour engager un paiement et pour autoriser un paiement. En l’occurrence, aucun individu ne devrait être autorisé à exécuter les deux transactions. Il conviendra donc de retenir que le principe de séparation des tâches est de la plus haute importance pour l’exploitation d’un CDV.

To comply with the principle of separation of duties, administrative roles in a VDC should be partitioned. There is a tendency in a VDC to want to combine administrative roles to streamline administration. However, this temptation should be resisted as it runs contrary to the principle of separation of duties. Privileged access should only be provided to a limited number of trusted individuals within the organization. Also, rather than provide an excessive amount of privilege, an organization might want to consider implementing a break-glass policyFootnote 15.

La gestion d’un CDV, comme l’illustre la figure 5, prévoir généralement les rôles suivants :

  • Gestion des applications : Les applications d’un CDV sont gérées depuis un environnement informatique traditionnel.
  • Gestion du système d’exploitation : La gestion du système d’exploitation est en plusieurs points semblable à la gestion des environnements informatiques traditionnels. La seule différence est que dans un CDV, plus d’un système d’exploitation peuvent être hébergés sur un même serveur physique.
  • Gestion de la virtualization : La gestion de la virtualisation correspond à une nouvelle couche de gestion qui est propre aux CDV. En s’en prenant à la gestion de la virtualisation, un auteur de menace peut tenter de commander les MV (démarrer ou arrêter une MV, transférer une MV vers un différent serveur physique, faire des copies instantanées de configuration dans le but de revenir éventuellement à d’anciennes configurations). Un auteur de menace peut également avoir recours à la virtualisation pour déployer des MV piratées, ou même apporter des modifications aux commutateurs virtuels. Pour atténuer ces risques, nous recommandons de séparer les rôles ayant trait à la gestion de la virtualisation. Nous recommandons également qu’un rôle de gestion de la virtualisation soit attribué à chacune des zones de sécurité réseau de façon à restreindre le champ de pouvoir de chacun des administrateurs. En l’occurrence, cette approche nécessite une collaboration entre les divers rôles de gestion de la virtualisation, ce qui fait en sorte que tout changement s’étend sur plus d’une zone de sécurité. (Voir PE CDV no 6 [section 3].)
  • Gestion de l’infrastructure : La gestion de l’infrastructure au sein d’un CDV comprend à la fois les systèmes physiques et l’infrastructure réseau (p.ex. les routeurs et les commutateurs).
  • Gestion de la sécurité : La gestion de la sécurité englobe la configuration et le maintien des contrôles de sécurité visant les frontières ainsi que des contrôles de sécurité visant les systèmes. Ce rôle est légèrement différent dans un CDV. En outre, les responsabilités liées à ce rôle sont les mêmes que celles s’appliquant aux centres de données traditionnels. Toutefois, ces responsabilités portent sur la couche de l’hyperviseur de même que sur les vulnérabilités particulières à la virtualisation.

Figure 5 : Gestion

Description détaillée suit immédiatement
Description détaillée

Gestion

2.7 Rangement

Dans les CDV, la plupart des SAN ont recours à la technologie Fibre Channel (FC) ou au protocole iSCSI (Internet Small Computer System Interface).

Fibre Channel, le nom que l’on donne communément à un ensemble de normes mises au point par l’American National Standards Institute (ANSI) est une liaison série qui prend en charge le protocole Fibre Channel (FCP pour Fibre Channel Protocol) ainsi que des protocoles de niveaux plus élevés comme SCSI. FC nécessite l’emploi d’un réseau Fibre Channel distinct. FC a l’avantage d’accroître la vitesse de transfert et tire avantage des technologies les plus évoluées du marché. Il existe une variante : Fibre Channel sur Ethernet (FCoE pour Fibre Channel over Ethernet), applique la technologie Fibre Channel sur Ethernet. Les SAN FC prennent en charge trois types de mécanismes d’authentification :

  • Diffie Hellman Challenge Handshake Authentication Protocol (DH CHAP)Footnote 16;
  • Fibre Channel Authentication Protocol (FCAP)Footnote 17; and
  • Fibre Channel Password Authentication Protocol (FCPAP)Footnote 18.

Norme établie par un groupe pour la participation à la standardisation d’Internet (IETF pour Internet Engineering Task Force) (documents RFC 3270, RFC 3783), la technologie iSCSI permet d’utiliser le protocole SCSI sur un réseau TCP/IP (Transmission Control Protocol/Internet Protocol). Ce procédé s’avère avantageux puisqu’il permet à un SAN iSCSI de recourir au standard Ethernet. Certains de ces avantages se manifestent sur le plan de la simplicité et du coût. Au reste, le SAN iSCSI prend en charge le protocole Challenge Handshake Authentication Protocol (CHAP) ainsi que le protocole de sécurité pour IP (IPSec pour IP Security).

2.8 Sécurité

Sur le plan de la sécurité, le processus de virtualisation doit miser sur une sécurisation adéquate du CDV, c’est d’ailleurs le propos de l’ensemble du présent rapport. Il n’est donc pas primordial d’en discuter dans la présente section. Toutefois, il conviendra d’indiquer que la virtualisation de la sécurité, là où les appliances de sécurité physique sont virtualisées, est de plus en plus employée dans les CDV. La section qui suit se penche sur les diverses approches que l’on peut appliquer à la virtualisation de la sécurité des CDV.

2.8.1 Virtualisation de la sécurité

Les appliances de sécurité – y compris les coupe feux, les systèmes de détection des intrusions (SDI), etc. – peuvent être virtualisées à l’instar des serveurs traditionnels. Les appliances de sécurité virtualisée sont souvent appelées « appliances de sécurité virtuelles » (ASV). Une ASV est une appliance virtuelle idéalement composée d’un système d’exploitation renforcé et d’une seule application de sécurité. Une ASV consiste généralement en une application de sécurité autonome qui répond au principe selon lequel les fonctions de sécurité sont isolées les unes des autres. (Voir PE CDV no 7 [section 3].) La virtualisation de la sécurité comporte nombre d’avantages, notamment les suivants : réduction des coûts, souplesse accrue et connectivité à l’infrastructure réseau virtualisée.

Figure 6 : Options en matière de virtualisation de la sécurité

Description détaillée suit immédiatement
Description détaillée

La figure 6 illustre les trois approches pouvant s’appliquer à la virtualisation de la sécurité

  1. Séparation des frontières avec des appliances de sécurité physiques (physique) – Cette approche physique est utilisée dans la plupart des centres de données traditionnels. Les espaces constituent des entités physiques distinctes (voir PE CDV no 8) [section 3]), mais chacun de ces espaces se compose d’appliances de sécurité physiques (ASP). Sur le plan de la sécurité, l’avantage de cette approche réside dans le fait que tout le trafic réseau qui circule entre les zones de sécurité réseau est forcé de passer par une imposition purement physique des frontières. Le désavantage réside dans le manque de souplesse observé dans les cas où l’on doit utiliser et gérer un nombre relativement élevé d’ASP.
  2. Séparation des frontières avec des appliances de sécurité virtuelles (hybride) – Cette approche hybride combine l’application physique distincte des espaces (correspond à PE CDV no 8) au moyen d’ASV. L’avantage de cette approche, sur le plan de la sécurité, réside dans le fait que tout le trafic réseau qui circule entre les zones de sécurité réseau est forcé de passer par l’imposition de séparations physiques entre les frontières. Un autre avantage, cette fois sur le plan de la souplesse, résulte de ce qu’un dispositif frontalier commun doté d’une ASV peut être exploité à chacune des frontières
  3. Frontières consolidées avec des appliances de sécurité virtuelles (logique) – Cette approche logique virtualise intégralement les frontières. Non seulement les frontières sont-elles hébergées sur un même dispositif physique, mais les ASV sont considérablement mises à contribution pour ainsi fournir les services de sécurité requis. Or, une source de préoccupation subsiste relativement au fait qu’en créant des zones de sécurité réseau de nature diverse sur un même serveur, on accroît fortement la probabilité que l’erreur humaine mène à des lacunes de configuration qui risquent de compromettre l’architecture de sécurité réseau du CDV. Au reste, l’avantage de cette approche s’observe particulièrement sur le plan de la souplesse en ce qu’elle permet à un seul dispositif physique disposant d’un ensemble d’ASV d’être mis en place pour toutes les frontières.

3 Architecture de référence pour les CDV : pratiques exemplaires

La présente section présente une série de pratiques exemplaires visant l’architecture de référence pour les CDV. Ces pratiques exemplaires, lesquelles comprennent les neuf pratiques déjà exposées dans la présente, ont été réunies dans la liste ci-dessous pour en faciliter l’examen.

  1. Procéder à la consolidation/à la virtualisation seulement après mûre réflexion. Dès lors que la virtualisation est possible, on est souvent enclins à consolider et à virtualiser tout ce qui se trouve dans le centre de données. Sans un examen approfondi des enjeux de sécurité, la consolidation/la virtualisation risque fort d’affaiblir la posture de sécurité globale du CDV.
  2. Éviter d’étendre outre mesure les zones de sécurité réseau par la virtualisation. Nous recommandons fortement que les MV de diverses zones de sécurité réseau ne soient jamais colocalisées sur le même matériel physique d’un CDV donné. En autres mots, les serveurs devraient seulement être utilisés pour héberger les machines virtuelles appartenant à une même zone de sécurité réseau.
  3. Créer une ZG distincte pour chacune des zones de sécurité réseau. Nous recommandons fortement que des ZG physiquement séparées soient mises en place pour chacune des zones de sécurité réseau d’un CDV. Il ne devrait y avoir aucune connectivité directe entre les ZG.
  4. Créer une ZAR distincte pour le stockage virtuel de chacune des zones de sécurité réseau. Nous recommandons fortement que des ZAR physiquement séparées soient mises en place pour le réseau de stockage de chacune des zones de sécurité réseau d’un CDV. Il ne devrait y avoir aucune connectivité directe entre les ZAR.
  5. Employer un hyperviseur nu. Nous recommandons fortement qu’un hyperviseur nu soit employé dans un CDV. Un hyperviseur nu tourne directement sur le matériel physique. Par contre, un hyperviseur hébergé tourne en tant qu’application sur un système d’exploitation hôte. En définitive, les hyperviseurs ainsi hébergés posent certains problèmes de sécurité puisqu’ils assujettissent la couche de virtualisation (hyperviseur) ainsi que les systèmes virtualisés (MV) aux vulnérabilités inhérentes au système d’exploitation hôte. À contrario, un hyperviseur nu est conçu pour ce type d’environnement. En effet, il se fonde sur une base de code réduite et comporte moins de couches de composantes, ce qui le rend moins vulnérable aux éventuelles exploitations malveillantes.
  6. Séparer les fonctions de gestion. Dans un CDV, les fonctions de gestion devraient être séparées. Dans les centres de données traditionnels, on devrait prévoir un rôle lié à la gestion de la virtualisation. Ce rôle distinct de gestion de la virtualisation devrait être assigné à chacune des zones de sécurité réseau, dans le but d’empêcher que des modifications se répercutent dans une multiplicité de zones de sécurité réseau.
  7. Isoler les fonctions de sécurité. Non seulement les fonctions de sécurité doivent-elles être séparées des systèmes qu’ils sont censés protéger, mais elles doivent également être séparées les unes des autres. Dans le cas d’un CDV, les fonctions de sécurité aux frontières peuvent être hébergées sur des appliances de sécurité physiques ou virtuelles. De plus, les ASP et les ASV ne devraient assurer qu’une seule fonction de sécurité de façon à ce que celle-ci soit totalement isolée des fonctions remplies par les autres appliances de sécurité.
  8. Imposer des frontières distinctes. Dans le cas d’un CDV, nous recommandons fortement l’imposition de frontières distinctes. Cette approche empêche que des d’erreur de configuration ou des lacunes sur le plan de la sécurité en arrivent à compromettre l’architecture de sécurité d’un CDV donné. Lorsque cette approche est mise en œuvre, on peut recourir soit aux ASP soit aux ASV.
  9. Sécuriser chacune des couches du CDV. Comme les auteurs de menace attaqueront forcément les points les moins sécurisés d’un CDV, il sera important de tout mettre en œuvre pour sécuriser chacune des couches du CDV en question.
  10. Créer des séparations physiques entre les divers types de réseaux : données, gestion, stockage et migration à chaud. Pour les CDV, nous recommandons que des réseaux physiquement séparés soient mis en place pour accueillir les divers types de réseau (données, gestion, stockage et migration à chaud) plutôt que des VLAN ou des VSAN, et ce, pour des motifs de sécurité et de performance. Le recours à des réseaux physiques séparés permettra de veiller à ce que les réseaux privilégiés soient totalement isolés des autres types de trafic.
  11. Recourir à des contrôles logiques pour fournir une séparation granulaire, en complément de la séparation physique des zones de sécurité réseau. Bien que les zones de sécurité réseau servent à séparer sommairement les systèmes d’information, il est tout de même possible d’utiliser des méthodes de séparation plus fines à l’intérieur des parties de sécurité de réseau. La préoccupation est que les applications qui partagent une zone de sécurité réseau peuvent communiquer l’une avec l’autre sans que ces communications soient contraintes de passer par une frontière de sécurité. Ainsi, on peut exiger que le réseau de communication en question traverse une frontière de sécurité, ce qui le soumettrait à un degré de surveillance approprié. Cette exigence est possible grâce au recours à des contrôles logiques, notamment VLAN ou la microsegmentation, que le SDN est en mesure d’offrir.
  12. Utiliser les options de sécurité de la couche 2 pour atténuer les attaques contre la couche 2. Les attaques contre la couche 2 ont lieu depuis nombre d’années, mais elles sont tout de même efficaces contre les commutateurs dont la configuration est lacunaire. Il conviendra donc de réagir en planifiant des configurations de commutateurs qui soient sûres et adaptées, et en veillant à ce que ces configurations soient déployées dans l’ensemble du CDV.
  13. Recourir à l’authentification et au chiffrement pour protéger les communications réseau sensibles. En plus de l’isolement physique des réseaux sensibles, l’authentification et le chiffrement peuvent être mis à contribution pour renforcer la protection des communications réseau sensibles. Notons, toutefois, que le recours au chiffrement élimine la possibilité de recours à la surveillance réseau. Par conséquent, il pourrait s’avérer nécessaire de cesser le chiffrement aux points d’interface entre les zones (ZIP), ce qui permettrait d’analyser le trafic, qui serait ensuite chiffré de nouveau avant d’être remis en circulation.
  14. Recourir à la gestion des configurations et à la sécurité des systèmes pour sécuriser l’hyperviseur. L’hyperviseur devrait être sécurisé de la même façon que les noyaux traditionnels. Plus spécifiquement, cette sécurisation sera réalisée principalement par la réduction de la surface d’attaque (c. à d. par la désactivation ou le retrait de services inutiles), le renforcement des services en place (au moyen des conseils prodigués), et l’installation des plus récents correctifs. Il conviendra d’effectuer périodiquement un repérage des vulnérabilités ainsi qu’une vérification de conformité de façon à garantir l’efficacité des mesures appliquées.
  15. Utilisation des fonctions de gestion des ressources dans le but d’atténuer les vulnérabilités résultant de la répartition inadéquate desdites ressources (resource contention). Les contrôles de gestion des ressources, notamment l’allocation et la limitation desdites ressources, devraient être mis à contribution pour veiller à ce que les MV disposent de ressources suffisantes sans en monopoliser une quantité excessive, en cas de compromission.
  16. Faire appel à l’introspection et aux interfaces de programmation (API pour Application Programming Interfaces) connexes pour protéger les MV. L’introspection (et les API connexes) est une fonction de l’hyperviseur qui lui permet de surveiller les MV et leurs mémoires respectives, les processus et les fonctions réseau sans avoir à installer de fonctionnalités de sécurité additionnelles sur les MV. Bien que cette approche comporte certains désavantages, nous recommandons d’y avoir recours, dans le cas des CDV, pour atténuer les vulnérabilités que l’on observe couramment chez les MV et pour compenser le peu de visibilité des réseaux virtuels.
  17. Appliquer les options de sécurité visant les réseaux virtualisés, lesquelles sont fournies par les solutions SDN et permettent, notamment, de placer des stratégies de sécurité pour la microsegmentation ainsi que des coupe feux en chacun des points terminaux. Une configuration adéquate de ces options peut mener à un niveau de sécurisation accru, voire supérieur à que ce que l’on retrouve dans les systèmes traditionnels.
  18. Éviter d’amalgamer des systèmes d’information virtualisés dont les exigences de sécurité diffèrent les unes des autres. Le document La gestion des risques liés à la sécurité des TI – Une méthode axée sur le cycle de vie [10] décrit dans le détail une approche pour la définition des profils de contrôles de sécurité, et décrit chacun des contrôles de sécurité pouvant s’appliquer à un système d’information donné. Dans le cadre de ce processus, il est question d’évaluer les exigences s’appliquant au système sur le plan de la confidentialité, de l’intégrité et de la disponibilité. Nous recommandons fortement que les systèmes d’information intégrés à des MV soient hébergés sur des serveurs regroupant des MV dont les exigences de sécurité sont semblables.
  19. Procéder à une analyse approfondie de la situation avant de colocaliser sur un même serveur physique les systèmes d’information virtualisés appartenant à des organisations différentes. La colocalisation rend les MV plus vulnérables aux compromissions. Qui plus est, un auteur de menace peut expressément tenter de placer, parmi les MV d’un même serveur, une MV depuis laquelle il peut lancer des attaques. En conséquence, les MV appartenant à différentes organisations ne devraient être colocalisées sur un même serveur physique qu’après mûre réflexion.
  20. Isoler physiquement les services cryptographiques. Les services cryptographiques centralisés, y compris les autorités de certification (AC), ne devraient pas être hébergés dans des MV en raison de leur vulnérabilité aux attaques par canal auxiliaire. Idéalement, les services cryptographiques devraient être isolés de façon à prévenir ce type d’attaque.
  21. Sécuriser chacune des MV comme on le ferait avec les systèmes physiques. Les MV devraient être sécurisées à l’exemple des systèmes physiques, c’est à dire grâce à des éléments relevant de la gestion des configurations et de la sécurité des systèmes. Plus spécifiquement, les MV devraient être sécurisées par la réduction de leur surface d’attaque (c. à d. par la désactivation ou le retrait de services inutiles), le renforcement du système d’exploitation et des applications (suivant les conseils prodigués), et l’installation des plus récents correctifs. Il conviendra d’effectuer périodiquement un repérage des vulnérabilités ainsi qu’une vérification de conformité de façon à garantir l’efficacité des mesures appliquées. Il serait préférable d’utiliser des modèles, ce qui permettrait d’établir une base sécurisée. Les MV pourraient alors être créées à partir de ces modèles.
  22. Sécuriser l’accès aux interfaces de gestion. L’accès à l’interface de gestion devrait être sécurisé en suivant, dans la mesure du possible, les quatre étapes suivantes :
    • exiger une authentification à deux facteurs robuste et centralisée;
    • utiliser une console de gestion dédiée et sécurisée;
    • veiller à ce que les communications de gestion soient sécurisées;
    • désactiver les interfaces de gestion inutilisées tout en renforçant celles qui sont employées.
  23. Pratiquer une gestion efficace des images, en ayant recours, notamment, à des modèles. La gestion des images devrait être mise en place de façon à empêcher l’apparition d’une diversité excessive de MV, notamment de MV piratées ou de MV inactives. En l’occurrence, il s’agit de limiter la création des MV au profit de rôles administratifs particuliers, en utilisant des modèles et en ayant recours à des mesures de stockage et à des copies instantanées (snapshot).
  24. Recourir au contrôle des accès et au chiffrement pour atténuer le vol de MV. Les VM sont vulnérables au vol en plusieurs emplacements d’un CDV. L’application parallèle d’un contrôle des accès physique, d’un contrôle des accès logiques et de chiffrement peut être mise en œuvre pour atténuer ce type de vulnérabilité. Toutefois, ces contrôles doivent être appliqués à plusieurs couches pour être en mesure d’atténuer ladite vulnérabilité dans tout le CDV.

4 Sommaire

Un nombre grandissant d’organisations projettent de virtualiser leurs centres de données virtuels (CDV) dans le but d’optimiser le ratio de consolidation et de simplifier leurs opérations. Toutefois, pour entreprendre un tel virage, il est essentiel d’appréhender les implications que la virtualisation peut avoir en matière de sécurité et sur la posture de sécurité du centre de données en général.

Heureusement, il est tout à fait possible de sécuriser adéquatement les CDV en ayant recours à diverses mesures de protection et en observant les pratiques exemplaires en matière de sécurité de l’information. Les mesures de protection et les pratiques exemplaires présentées dans ce rapport permettent d’agir sur chacune des couches de l’environnement virtuel tout en tenant compte des interactions qui s’exercent entre celles-ci. Le présent rapport propose un aperçu des notions entourant les CDV, fait état des vulnérabilités propres aux CDV traditionnels et formule des recommandations pour la conception d’un CDV sécurisé.

4.1 Contacts et assistance

Si votre organisation souhaite obtenir plus d’informations sur les meilleures pratiques en matière de virtualisation des centres de données, veuillez contacter :

 

Centre d’appel du Centre pour la cybersécurité
contact@cyber.gc.ca
613-949-7048 ou 1-833-CYBER-88

5 Contenu complémentaire

5.1 Liste des abbréviations

Terme Définition
ANSI American National Standards Institute
API Interface de programmation d’applications (Application Programming Interface)
ASP Appliance de sécurité physique
ASV Appliance de sécurité virtuel
CDV Centre de données virtualisé
CCC Centre Canadien pour la cybersécurité (Centre pour la cybersécurité)
CHAP Protocole d’authentification par défi réponse (Challenge-Handshake Authentication Protocol)
CST Centre de la sécurité des communications
DH-CHAP Protocole d’authentification par défi réponse Diffie Hellman (Diffie-Hellman - Challenge Handshake Authentication Protocol)
DHCP Protocole DHCP (Dynamic Host Configuration Protocol)
FC Fibre Channel
FCAP Fibre Channel Authentication Protocol
FCPAP Fibre Channel Password Authentication Protocol
FCoE Fibre Channel sur Ethernet (Fibre Channel over Ethernet)
GC Gouverement du Canada
HTT Technologie du multifil simultané (Hyper-Threading Technology)
IDS Système de détection d’intrusion (Intrusion Detection System)
IETF Groupe pour la participation à la standardisation d’Internet (Internet Engineering Task Force)
IPS Systèmes de prévention des intrusions (Intrusion Prevention Systems)
IPsec Sécurité du protocole Internet (Internet Protocol Security)
iSCSI Interface pour petits systèmes informatiques sur Internet (Internet Small Computer System Interface)
ITSG Conseils en matière de sécurité des technologies de l’information (Information Technology Security Guidance)
NAS Stockage en réseau NAS (Network Attached Storage)
NFV Virtualisation des fonctions réseau (Network Function Virtualization)
NIST National Institute of Standards Technology
PE Pratiques exemplaires
RAM Mémoire vive (Random Access Memory)
RFC Demande de commentaires (Request for Comments)
RPV Réseau privé virtuel
SAL Niveau d’assurance de la sécurité (Security Assurance Level)
SAN Réseau de stockage (Storage Area Network)
SCT Secrétariat du Conseil du Trésor
SDN Réseautage logiciel (Software Defined Networking)
SMM Module de gestion système (System Management Module)
SSH Protocole SSH (Secure Shell)
TCP/IP Protocole TCP/IP (Transmission Control Protocol/Internet Protocol)
Td5 Menace délibérée 5 (Threat Deliberate 5)
TI Technologie de l’information
TPM Module de plateforme fiable (Trusted Platform Module)
UCT Unité centrale de traitement
VLAN Réseau local virtuel (Virtual Local Area Network)
VMM Contrôleur de machine virtuelle (Virtual Machine Monitor)
vNIC Carte d’interface de réseau virtuel (Virtual Network Interface Card)
VSAN Réseau de stockage virtuel (Virtual Storage Area Network)
ZAP Zone d’accès public
ZAR Zone d’accès restreint
ZG Zone de gestion
ZIP Points d’interface entre les zones (Zone Interface Points)
ZP Zone publique
ZT Zone de travail

5.2 Glossaire

Terme Définition
Amalgame Dans le contexte de la virtualisation, l’amalgame consiste à disposer sur un même hyperviseur des MV assujetties à des exigences de sécurité différentes ou des MV appartenant à divers clients, dans le seul but d’optimiser le rendement et le ratio de consolidation.
Centre de données virtualisé (CDV) Centre de données qui a recours à la virtualisation dans une large mesure pour abstraire les ressources de traitement, de réseautique, de stockage, de sécurité et de gestion des ressources de la structure matérielle sous-jacente.
Diffie Hellman Challenge-Handshake Authentication Protocol (DH-CHAP) Norme Internet pour l’authentification des dispositifs se connectant à un commutateur Fibre Chanel, qui utilise un protocole d’authentification à échange sécurisé de clés, lequel prend en charge à la fois l’authentification « commutateur à commutateur » et l’authentification à connexion télématique (host to switch).
Fibre Channel Authentication Protocol (FCAP) Mécanisme facultatif d’authentification employé entre deux dispositifs ou entités dans un réseau Fibre Chanel (FC) qui utilise des certificats ou des clés facultatives.
Fibre Channel Password Authentication Protocol (FCPAP) Mode facultatif d’authentification fondée sur un mot de passe et doté d’un protocole d’échange de clé. Ce mode est employé dans les réseaux Fibre Chanel. Il permet l’authentification réciproque entre les ports Fibre Chanel.
Mode de gestion système (SMM pour System Management Mode) Mode d’exploitation des unités centrales de traitement (UCT) x86 dans lequel toutes les exécutions normales sont suspendues, y compris celles du système d’exploitation. Un système logiciel distinct (lequel se trouve habituellement avec les micrologiciels d’un ordinateur) ou un débogueur matériellement assisté est exécuté grâce à des privilèges accrus.
Norme pour signature numérique (DSS) Algorithme de signature numérique (DSA pour Digital Signature Algorithm) développé par la National Security Agency (NSA) des États Unis, pour la génération de signatures numériques servant à l’authentification des documents électroniques. La norme DSS a été créée par la National Institute of Standards Technology (NIST) en 1994 et est devenue la norme du gouvernement des États Unis pour l’authentification des documents électroniques. Des précisions sur la norme DSS se trouvent dans le document faisant état de la Federal Information Processing Standard (FIPS) 186.
Politique du bris de glace Politique visant le contrôle des accès qui permet exceptionnellement (p. ex. en cas d’urgence) d’aller à l’encontre d’une pratique standard. Par exemple, dans le cas d’un centre de données, la politique qui encadre les pouvoirs restreints peut être mise entre parenthèses suivant l’application d’une politique du bris de glace pour répondre à une situation exceptionnelle où, par exemple, plusieurs administrateurs souffriraient d’une grippe carabinée et ne seraient plus en mesure d’effectuer leurs tâches. Une politique du bris de glace est invariablement mise en place parallèlement à des mécanismes compensatoires de vérification. De cette façon, toute mesure prise conformément à cette politique serait l’objet de vérifications permettant de veiller à ce qu’aucune intervention non autorisée ne soit réalisée.
Protocole iSCSI (Internet Small Computer System Interface) Protocole de la couche de transport établissant la façon dont les paquets Small Computer System Interface (SCSI) doivent être portés dans un réseau TCP/IP. Le protocole iSCSI se superpose au protocole TCP (Transport Control Protocol) et permet aux commandes SCSI d’être acheminées de bout en bout dans un réseau local (LAN pour Local Area Network), un réseau étendu (WAN pour Wide Area Networks) ou dans l’Internet.
Virtualisation du système d’exploitation Type de virtualisation, que l’on nomme aussi virtualisation du noyau partagé (shared kernel virtualization), qui diffère de la virtualisation intégrale dans la mesure où ses applications sont hébergées dans des environnements virtuels qui tournent sur un même système d’exploitation plutôt que sur des systèmes d’exploitation distincts.
Virtualisation hébergée Type de virtualisation où l’hyperviseur tourne sur un système d’exploitation standard, lequel agit comme intermédiaire dans les transactions avec le matériel sous-jacent.
Virtualisation intégrale Tout premier type de virtualisation x86 jamais développé, qui demeure le plus utilisé à ce jour. Il s’agit là de virtualisation intégrale dans la mesure où le système d’exploitation hébergé et les applications connexes tournent sur des MV qui fonctionnent indistinctement du matériel sous-jacent, puisqu’ils en sont séparés par une couche de virtualisation.

5.3 Références

Numéro Référence
1 Secrétariat du Conseil du Trésor du Canada – Politique sur la sécurité du gouvernement (PSG) , 1er juillet 2009.
2 Secrétariat du Conseil du Trésor du Canada – Norme opérationnelle de sécurité : Gestion de la sécurité des technologies de l’information (GSTI) , non daté.
3 Secrétariat du Conseil du Trésor du Canada – Directive sur les pratiques relatives à la protection de la vie privée, 6 mai 2014
4 Ministère de la Justice – Loi sur la gestion des finances publiques, 12 mars 2018.
5 Secrétariat du Conseil du Trésor du Canada – Ligne directrice sur l’utilisation acceptable des dispositifs et des réseaux, 30 mai 2016.
6 Secrétariat du Conseil du Trésor du Canada – Politique sur la gestion du matériel, 26 juin 2006.
7 Ministère de la Justice du Canada – Loi sur la protection des renseignements personnels, (R.S.C., 1985, c. P-21).
8 Ministère de la Justice du Canada – Loi sur la protection des renseignements personnels et les documents électroniques, (S.C. 2000, c.5).
9 Ministère de la Justice du Canada – Loi sur la l’accès à l’information, (R.S.C., 1985, c. A-1).
10 Centre de la sécurité des communications – ITSG 33 – La gestion des risques liés à la sécurité des TI : Une méthode axée sur le cycle de vie, décembre 2014.
11 Centre de la sécurité des communications – ITSG 22 – Exigences de base en matière de sécurité pour les zones de sécurité de réseau au sein du gouvernement du Canada, 1er juin 2007.
12 Centre de la sécurité des communications – ITSG 38 – Zones de sécurité des réseaux – Considérations en matière de conception liées au placement de services dans des zones, 1er mai 2009.

5.4 Bibliographie

5.4.1 Publications du Centre pour la cybersécurité

ITSG 22 – Exigences de base en matière de sécurité pour les zones de sécurité de réseau au sein du gouvernement du Canada, Centre Canadien pour la cybersécurité, juin 2007.
ITSG 33 – La gestion des risques liés à la sécurité des TI : Une méthode axée sur le cycle de vie, Centre Canadien pour la cybersécurité, décembre 2014..
ITSP.30.031 V3 – Guide sur l’authentification des utilisateurs dans les systèmes de technologie de l’information, Centre Canadien pour la cybersécurité, avril 2018.
ITSP.40.062 – Conseils sur la configuration sécurisée des protocoles réseau, Centre Canadien pour la cybersécurité, août 2007.
ITSP.40.111 – Algorithmes cryptographiques pour l’information NON CLASSIFIÉ, PROTÉGÉ A et PROTÉGÉ B, Centre Canadien pour la cybersécurité, août 2016.
TRA 1 Méthodologie harmonisée d’évaluation des menaces et des risques (EMR) , Centre Canadien pour la cybersécurité, octobre 2007.
TSCG 01\E: – Lignes directrices sur la chaîne d’approvisionnement des technologies – Clauses contractuelles liées à l’équipement et aux services de télécommunication, Centre Canadien pour la cybersécurité, octobre 2010.

5.4.2 Publications de services partagés canada (SPC)

Isolement dans les centres de données définis par des logiciels, Services partagés Canada, janvier 2015.

5.4.2 Autres publications

A. Desnos, E. Filiol and I. Lefou. Detecting (and creating!) a HVM rootkit (aka BluePill-like) , septembre 2009.
Sawani, SubVirt: Implementing Malware with Virtual Machines, 2006.
Tereshkin & R. Wojtczuk, Introducing Ring -3 Rootkits, Invisible Things Lab, juillet 2009.
Danev, et al. Enabling Secure VM-vTPM Migration in Private Clouds, Department of Computer Science, ETH Zurich, Suisse, 2011.
Dolan-Gavitt., et al. Virtuoso: Narrowing the Semantic Gap in Virtual Machine Introspection, School of Computer Science, Georgia Institute of Technology, 2011.
Dai Zovi, Hardware Virtualization Rootkits, Matasano, 2006.
Kyte, P. Zavarsky, D. Lindskog & R. Ruhl. Detection of Hardware Virtualization Based Rootkits by Performance Benchmarking, Concordia University College of Alberta, 2012.
J. Rutkowska & A. Tereshkin, IsGameOver() Anyone?, Version 1.01, Invisible Things Lab, août 2007.
J. Rutkowska, Introducing Blue Pill, Invisible Things Lab, 22 juin 2006.
J. Stewart, Practical Considerations in Virtual Machine Covert Channels, Thesis, East Stroudsburg University of Pennsylvania, 6 mai 2011.
J. Xiao, Z. Xu, H. Huang & H. Wang, POSTER: A Covert Channel Construction in a Virtualized Environment, 2012.
K. Figueroa, M. Figueroa and A. Williams, VLAN Layer 2 Attacks: Their Relevance and Their Kryptonite, Defcon 16, 2008.
K. Kortchinsky, CLOUDBURST, A VMware Guest to Host Escape Story, Immunity Inc., 2009.
K. Nance, B. Hay & M. Bishop, Virtual Machine Introspection – Observation or Interference? IEEE Security & Privacy, 2008.
K. Suzaki, K. Iijima, T. Yagi and C. Artho, Memory Deduplication as a Threat to the Guest OS, National Institute of Advanced Industrial Science and Technology, 2011.
M. Green, Attack of the week: Cross-VM side-channel attacks, 26 octobre 2012.
M. Myers & S. Youndt, An Introduction to Hardware-assisted Virtual Machine Rootkits, Crucial Security, 7 août 2007.
Ptacek, Goldsmith & Lawson. Don’t Tell Joanna, the Virtualized Rootkit is Dead, Matasano Security, 2007.
R. Wojtczuk and J. Rutkowska, Attacking Intel Trusted Execution Technology, Invisible Things Lab, février 2009.
R. Wojtczuk and J. Rutkowska, Attacking Intel TXT via SINIT Code Execution Hijacking, Invisible Things Lab, novembre 2011.
R. Wojtczuk, Subverting the Xen Hypervisor, Invisible Things Lab, 2008.
S. Bahram, et al., DKSM: Subverting Virtual Machine Introspection for Fun and Profit, 2010.
S. Convery, Hacking Layer 2: Fun with Ethernet Switches, Cisco Systems, 2002.
S. Embleton, S. Sparks and C. Zou, SMM Rootkits: A New Breed of OS Independent Malware, University of Central Florida, 22 septembre 2008.
Separation of Duties, NIST, 1995
Special Publication 800-125 - Guide to Security for Full Virtualization Technologies, NIST, janvier 2010.
SYSRET 64-bit Operating System Privilege Escalation Vulnerability on Intel CPU Hardware, CERT, 12 juin 2012.
T. Garfinkel & M. Rosenblum, A Virtual Machine Introspection Based Architecture for Intrusion Detection, Computer Science Department, Stanford University, 2003.
T. Garfinkel & M. Rosenblum. When Virtual is Harder than Real: Security Challenges in Virtual Machine Based Computing Environments, Stanford University Department of Computer Science, 2005.
T. Ristenpart, et al. Hey, You, Get Off of My Cloud: Exploring Information Leakage in Third-Party Compute Clouds, 2011.
Trusted Platform Module Summary, Trusted Computing Group.
V. Scarlata, et al., TPM Virtualization: Building a General Framework, Intel Corporation, 2008.
VMware vSphere 6.5: Install, Configure, Manage, VMware Education Services, 2017.
vTPM: Virtualizing the Trusted Platform Module, IBM Research Report, IBM, 14 février 2006.
Y. Bulygin & D. Samyde, Chipset Based Detection and Removal of Virtualization Malware a.k.a. DeepWatch, Intel Corporation, 2008.
Y. Xu, et al., An Exploration of L2 Cache Covert Channels in Virtualized Environments, 2011.
Y. Zhang, et al., Cross-VM Side Channels and Their Use to Extract Private Keys, 2012.
Z. Wu, Z. Xu & H. Wang, Whispers in the Hyper-space: High-speed Covert Channel Attacks in the Cloud, The College of William and Mary, 2012.
Date de modification :