Scurit de la virtualisation Risques et recommandations Confrence

  • Slides: 19
Download presentation
Sécurité de la virtualisation: Risques et recommandations Conférence CNIS Mag du 28 septembre 2011

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

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

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

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 3

Concepts de virtualisation • Différents niveaux de virtualisation – Virtualisation applicative – Virtualisation système

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

Principe primordial • Faire s’exécuter deux environnements différents sur une même machine, c’est accepter

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

Risques associés à la virtualisation • Déni de service Système d’exploitation Admin – Sous-dimensionnement

Risques associés à la virtualisation • Déni de service Système d’exploitation Admin – Sous-dimensionnement des ressources – Risque de famine Système d’exploitation Hôte Carte réseau Matériel Carte réseau • 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 • 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) 6

Système d’exploitation Applications Applications Système d’exploitation Admin Système d’exploitation Applications Compromission des machines virtuelles

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

Système d’exploitation Applications Applications Système d’exploitation Admin Système d’exploitation Applications Compromission des machines virtuelles

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

Applications Système d’exploitation SE-Hôte Admin Système d’exploitation Applications Cloisonnement des flux (suite, la mémoire)

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

Administration des architectures virtualisées (système) • Contraintes : complexification de l’administration • Niveau d’abstraction

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 10

Supervision des architectures virtualisées • Contraintes – Complexification de la supervision • incompatibilité entre

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

Synthèse des recommandations pour la conception d’architectures virtualisées • Recommandations techniques / architecture –

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 12

Synthèse des recommandations pour l’administration d’architectures virtualisées • Mettre en place des processus de

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 13

Recommandations transverses pour les architectures virtualisées (1) • Définir clairement les politiques et moyens

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 14

Recommandations transverses pour les architectures virtualisées (2) • Compléter la politique de sécurité existante

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 15

Conclusions • La virtualisation est un phénomène irréversible. • La sécurité doit être intégrée

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 16

Informations complémentaires • Parution prochaine du guide de l’ANSSI «Gérer les risques de la

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 17

Exemple d’architecture virtualisée (1) • Machines virtuelles avec stockage NAS 28/09/2011 Sécurité de la

Exemple d’architecture virtualisée (1) • Machines virtuelles avec stockage NAS 28/09/2011 Sécurité de la virtualisation 18

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

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