sécurité de la virtualisation: risques et recommandations
DESCRIPTION
Sécurité de la virtualisation: Risques et recommandations. Conférence CNIS Mag du 28 septembre 2011. Sommaire de la présentation. Introduction Concepts de la virtualisation Risques liés à la virtualisation Recommandations Conclusions. Introduction. - PowerPoint PPT PresentationTRANSCRIPT
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 – [email protected]
– 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