Sécurité de la virtualisation: Risques et recommandations

Conférence CNIS Mag du 28 septembre 2011

22

Sommaire de la présentation

• Introduction

• Concepts de la virtualisation

• Risques liés à la virtualisation

• Recommandations

• Conclusions

33

Introduction

• La virtualisation est basée sur le partage de ressources entre plusieurs objets

• Les entreprises voient (ou croient voir) très souvent les avantages (économiques / techniques) de la virtualisation

• Son déploiement est de fait en forte croissance

• Cependant, elle peut accroître les risques • fuite d’information

• atteinte à la disponibilité des services

• atteinte à l’intégrité des données

• Cette présentation expose • les risques associés aux architectures virtualisées

• et des recommandations de sécurité permettant de limiter ces risques

44

Concepts de virtualisation

• Différents niveaux de virtualisation – Virtualisation applicative

– Virtualisation système

Virtualisation complète sans modification du système virtualisé

matériel

Système d’exploitation

Couche d’abstraction

Système d’exploitation

Système d’exploitation

Cibles de la solution de virtualisation

Rendu virtuel

matériel

Couche d’abstraction

Application Application Applications Applications

Para-virtualisation gérée par la couche d’abstraction et par le système virtualisé modifié

Virtualisation assistée par le matériel

• Mais les risques en termes de sécurité sont similaires !

55

Principe primordial

• Faire s’exécuter deux environnements différents sur une même machine, c’est accepter qu’ils puissent interagir

• aucune solution de virtualisation ne peut procurer plus de cloisonnement que l’isolation physique

• la solution de virtualisation la plus robuste ne pourra donc que réduire le risque d’interaction entre environnements

• Utiliser un mécanisme de virtualisation pour isoler deux composants amenés naturellement à s’exécuter sur une même machine semble donc globalement sain

• Par contre, utiliser la virtualisation pour regrouper des objets qui devraient normalement être séparés est risqué !

66

• Déni de service– Sous-dimensionnement des ressources– Risque de famine

• Indisponibilité de l’hôte– Entraîne l’indisponibilité d’un grand

nombre de services à la fois

• Compromission des VM – D’un environnement depuis un autre

environnement– De l’hôte depuis un environnement

Risques associés à la virtualisation

Système d’exploitation

Système d’exploitation

Matériel

Système d’exploitation Hôte

Carte réseau

Carte réseau

Carte réseau

• Recommandations • Dimensionner correctement les ressources et imposer des quotas

• Prévoir des plans de sauvegarde et de reprise

• Maintenir la solution complète en conditions de sécurité (y compris lors de la modification du matériel)

• Durcir les systèmes invités (VM)

77

Compromission des machines virtuelles & Isolation des flux

Système d’exploitation

Matériel

Système d’exploitation Hôte

Système d’exploitation

Système d’exploitation

Matériel

Système d’exploitation

MatérielCarte réseauCarte réseau Carte réseau

• Les machines virtuelles peuvent être vulnérables • La virtualisation n’apporte rien à la sécurité des systèmes invités eux-mêmes

• Le partage de ressource peut être source de vulnérabilités • Les partages de mémoire, d’espace de stockage • Les flux réseau peuvent être mal cloisonnés

828/09/2011 Sécurité de la virtualisation

Compromission des machines virtuelles & Isolation des flux

Système d’exploitation

Matériel

Système d’exploitation Hôte

Système d’exploitation

Système d’exploitation

Matériel

Système d’exploitation

MatérielCarte réseauCarte réseau Carte réseau

Recommandations• Prévoir l’isolation des flux à tous les niveaux

• Chiffrer les flux réseau sensibles imposés par le composant en charge de l’application de la politique de sécurité

• Mettre en place des mécanismes de défense en profondeur

• durcir les OS

• Minimiser les interactions naturelles entre VM

99

Cloisonnement des flux (suite, la mémoire)

SE-Hôte

Système d’exploitation

Système d’exploitation

MatérielCarte réseau

Carte réseau

• Recommandations • S’assurer de l’isolation réelle des flux au niveau matériel

– Mise en œuvre de technologies matérielles à l’état de l’art (I/O MMU) ??

• Exclure les domaines critiques de la plateforme virtualisée

• Mettre en place des mécanismes complémentaires de confidentialité et de contrôle d’intégrité

Même lorsque les ressources matérielles sont distinctes, elles peuvent communiquer entre elles (exemple : communication entre cartes réseau)

1010

Administration des architectures virtualisées (système)

• Contraintes : complexification de l’administration• Niveau d’abstraction supplémentaire induit par la virtualisation

• Partage de l’administration entre le système hôte et les systèmes invités

• Recommandations : définition de zones de confiance • Authentification forte des administrateurs des systèmes

• Traçabilité des actions d’administration des machines virtuelles

• Equipes différentes » Distinction entre hôte et invité» Séparation de l’administration locale / distante

1111

Supervision des architectures virtualisées

• Contraintes – Complexification de la supervision

• incompatibilité entre cloisonnement des VM et vision d’ensemble • Pas de traçabilité de bout-en-bout des actions

– Prolifération et délocalisation non maîtrisées des données et des systèmes

– Appauvrissement de la gestion des erreurs– Complexité de gestion des logs (hôtes, invités) – Outils d’optimisation mémoire

• Audit plus difficile

• Recommandations – Différents environnements de supervision / niveau ou groupe de

niveaux – Disposer d’une gestion des erreurs au niveau global

• Centralisation des logs et contrôle d’intégrité des logs • Outils de corrélation

1212

Synthèse des recommandations pour la conception d’architectures virtualisées

• Recommandations techniques / architecture – Regrouper sur une même machine physique les systèmes invités

relevant de la même zone de confiance (logique, process, physique, géographique)

– Regrouper sur une même machine physique les systèmes invités manipulant des données de même niveau de sensibilité

– Utiliser au minimum une carte réseau physique par groupe de systèmes invités qui manipulent des données de même sensibilité

– Dédier un réseau à l’administration des systèmes hôtes et un réseau à la supervision

• S’assurer que la solution de virtualisation gère le cloisonnement des données au niveau matériel – Utilisation d’I/O MMU

• Durcir les systèmes invités– Configuration de sécurité des systèmes hôte et invités

1313

Synthèse des recommandations pour l’administration d’architectures virtualisées

• Mettre en place des processus de création et de suivi des machines virtuelles– Etablir des règles strictes et précises concernant la migration

manuelle ou automatique des VM

• Fixer des quotas de ressources à chaque machine virtuelle (processeur, mémoire, espace disque)

• Gérer la mise à jour de sécurité de l’ensemble des composants (machines virtuelles invitées, système hôte)

• Superviser les matériels, les systèmes et les couches de virtualisation (traces, …)– Mettre en œuvre des moyens de contrôle des flux échangés entre

les machines virtuelles

1414

Recommandations transverses pour les architectures virtualisées (1)

• Définir clairement les politiques et moyens techniques de mise à jour des systèmes invités, du système hôte et de la solution de virtualisation

• S’assurer que la solution de virtualisation ne diminue pas le niveau de sécurité intrinsèque des systèmes invités

• Il est très fortement recommandé de choisir des solutions de virtualisation dont la sécurité a été évaluée (par exemple labellisée par l’ANSSI)

• Porter une attention particulière à la sécurité des postes dédiés à l’administration et à la gestion des machines virtuelles

1515

Recommandations transverses pour les architectures virtualisées (2)

• Compléter la politique de sécurité existante de l’organisme en prenant en compte les particularités de la virtualisation

• Avant de virtualiser une architecture, il faut préalablement assurer indépendamment la sécurité des systèmes virtualisés

• Ressources humaines – Former les administrateurs au domaine de la virtualisation

– Séparer les administrateurs des machines hôtes des administrateurs des systèmes invités

– Si possible et en fonction de la sensibilité des données, habiliter le personnel assurant l’administration et la supervision

– Organiser les astreintes

1616

Conclusions

• La virtualisation est un phénomène irréversible.

• La sécurité doit être intégrée dans les démarches de virtualisation – pour analyser les risques associés

– et mettre en œuvre les mesures de réduction de risque nécessaires

• Pour les systèmes sensibles, toujours poser la question– Puis-je virtualiser ce système

ou dois-je le laisser dans un environnement physique isolé?

• L’ANSSI prépare un guide regroupant entre autres les recommandations présentées ici

1717

Informations complémentaires

• Parution prochaine du guide de l’ANSSI «Gérer les risques de la virtualisation»

• Pour en savoir plus – conseil@ssi.gouv.fr

– Site institutionnel: http://www.ssi.gouv.fr

– Publications de l’ANSSI: http://www.ssi.gouv.fr/publications

18

Exemple d’architecture virtualisée (1)

• Machines virtuelles avec stockage NAS

28/09/2011 Sécurité de la virtualisation

Matériel

SE Hôte

SE

Invi

té 1

SE

Invi

té 2

SE

Invi

té 3

Adm

in

Carte réseauCarte réseau

Carte réseau Carte réseauPériphérique de stockage

NAS

Périphériques de stockage virtuels dédiés

Périphérique de stockage virtuel partagé

1928/09/2011 Sécurité de la virtualisation

Exemple d’architecture virtualisée (2)

Super-vision

Adm

hôtes

Adm

invités

Stockage

Réseau d’administration invités

Réseau d’administration et de supervision hôtes

Réseau de stockage

Réseau de données

Commutateur Routeur

Matériel

SE Hôte

SE

Invi

té 1

SE

Invi

té 2

SE

Invi

té 3

Ad

min

Car

te ré

seau

Car

te ré

seau

Car

te ré

seau

App

licat

ion

11

App

licat

ion

12

App

licat

ion

21

App

licat

ion

22

App

licat

ion

31

App

licat

ion

32

Matériel

SE Hôte

SE

Invi

té 1

SE

Invi

té 2

SE

Invi

té 3

Ad

min

Car

te ré

seau

Car

te ré

seau

Car

te ré

seau

App

licat

ion

11

App

licat

ion

12

App

licat

ion

21

App

licat

ion

22

App

licat

ion

31

App

licat

ion

32

Matériel

SE Hôte

SE

Invi

té 1

SE

Invi

té 2

SE

Invi

té 3

Ad

min

Car

te ré

seau

Car

te ré

seau

Car

te ré

seau

App

licat

ion

11

App

licat

ion

12

App

licat

ion

21

App

licat

ion

22

App

licat

ion

31

App

licat

ion

32

Espace de supervision

Car

te ré

seau

Car

te ré

seau

Car

te ré

seau