Sécurité de la virtualisation: Risques et recommandations

1. Sécurité de la virtualisation: Risques et recommandations Conférence CNIS Mag du 28 septembre 2011

2. Sommaire de la présentation • Introduction • Concepts de la virtualisation • Risques liés à la virtualisation • Recommandations • Conclusions

3. 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

4. Concepts de virtualisation • Différents niveaux de virtualisation • Virtualisation applicative • Virtualisation système Application Application Applications Applications Cibles de la solution de virtualisation Para-virtualisation gérée par la couche d’abstraction et par le système virtualisémodifié Système d’exploitation Système d’exploitation Couche d’abstraction Rendu virtuel Virtualisation complète sans modification du système virtualisé Système d’exploitation Couche d’abstraction matériel matériel • Virtualisation assistée par le matériel • Mais les risques en termes de sécurité sont similaires !

5. 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é !

6. Risques associés à la virtualisation • 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 Admin Système d’exploitation Système d’exploitation Système d’exploitation Hôte Matériel 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)

7. Compromission des machines virtuelles & Isolation des flux Applications Applications Applications Applications Applications Applications Applications Applications Applications Applications Applications Applications Admin Système d’exploitation Système d’exploitation Système d’exploitation Système d’exploitation Système d’exploitation Hôte Matériel Matériel Matériel Carte réseau Carte 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

8. Compromission des machines virtuelles & Isolation des flux Applications Applications Applications Applications Applications Applications Applications Applications Applications Applications Applications Applications Admin Système d’exploitation Système d’exploitation Système d’exploitation Système d’exploitation Système d’exploitation Hôte Matériel Matériel Matériel Carte réseau Carte 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 Sécurité de la virtualisation 28/09/2011

9. Cloisonnement des flux (suite, la mémoire) Applications Applications Applications Applications Applications Applications Même lorsque les ressources matérielles sont distinctes, elles peuvent communiquer entre elles (exemple : communication entre cartes réseau) Admin Système d’exploitation Système d’exploitation SE-Hôte Matériel Carte 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é

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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) Sécurité de la virtualisation 28/09/2011 Machines virtuelles avec stockage NAS

19. Exemple d’architecture virtualisée (2) Sécurité de la virtualisation 28/09/2011