samedi 3 août 2013
mercredi 2 décembre 2009
Sécurité de la virtualisation et du "Cloud Computing"
Publié le 10 novembre 2009 - Jean-François Audenard
Les techniques de virtualisation des environnements informatiques ne datent pas d'hier : elles sont utilisées depuis fort longtemps dans des environnements de type "mainframes".
Depuis quelques bonnes années, les solutions de virtualisation se sont démocratisées et font partie de la trousse à outils de tout bon informaticien qui se respecte : Les VmWare, Hyper-V, Linux KVM et autres Xen sont des technologies très souvent utilisées en entreprise.
Comme toute technologie, ce n'est qu'une fois que celle-ci commence à fonctionner correctement que se pose la problématique de la sécurité (cf ce que nous pouvons voir dans le domaine de la VoIP). Cette "maturation lente et naturelle" de la sécurité des environnements virtualisés a été accélérée par un catalyseur appelé "Cloud Computing" : Les environnements sont transférés depuis les réseaux internes des entreprises sur Internet.
De quelle manière un responsable sécurité doit-il aborder ce changement ? Ayant été récemment interpelé sur ce sujet, il m'a semblé intéressant de partager avec vous quelques réflexions autour de ce thème.
Concernant la virtualisation
Quelques axes de réflexions sur les changements et risques induits par la virtualisation. J'ai volontairement mis de coté les sujets très techniques de compromission de la technologie elle-même... (Pour une prochaine fois peut-être ?)
La prolifération des Machines Virtuelles (VM)
Activer une nouvelle instance d'un système est très facile : La tentation est donc naturellement grande d'instancier plusieurs instances d'un environnement pour des tests, une démonstration, etc... Si les administrateurs en charge de l'infrastructure virtualisée ne possèdent pas les outils leur permettant d'automatiser leurs actions sur un parc virtuellement très important, on va rapidement se retrouver dans une situation ou les serveurs/services ne seront pas tous à jour des correctifs ou supervisés comme il se doit. Une outil de gestion de parc est essentiel : En effet, on perd le coté "1 système d'exploitation <=> 1 serveur physique" : On peut donc plus facilement "égarer" une machine virtuelle...
L'explosion du nombre de VM va aussi rapidement réactiver l'un des vieux démons : la gestion des identités et des accès (le fameux IAM : Identity & Access Management) qui va être encore plus important dans une infrastructure virtualisée.
Le risque de comportements soudains
Dans un environnement virtualisé, une VM peut être très facilement arrêtée, suspendue ou encore dupliquée. Une VM présentant des vulnérabilités sur l'un de ses services réseaux peut donc ne pas être identifiée lors d'un scan de détection de vulnérabilité (car arrêtée ou suspendue durant les tests) ; lorsque celle-ci sera réactivée elle affaiblira automatiquement le niveau de sécurité de l'ensemble.
Le même scénario est aussi vraisemblable dans le cas ou une VM aurait été infectée par un vers informatique : Cette VM peut ne pas être comptabilisée/identifiée comme infectée lors d'une campagne de nettoyage et pourra ressurgir de façon sporadique au sein de l'infrastructure virtualisée et (re)-propager l'infection.
Mécanismes de retour-arrière (ou rollback)
Les mécanismes de retour-arrière sont particulièrement utiles : Il est possible de "revenir dans le temps" et ainsi de remettre une VM dans un état antérieur. Très pratique pour "effaçer" les effets néfastes d'une mise à jour de mauvaise qualité. De même, cela peut réactiver d'anciennes failles de sécurité ou faire revivre des comptes d'accès désactivés ou encore de vieux mots de passe... Très nouveaux comme comme problèmes non ?
Toujours autour du rollback : Dans le cas d'une intrusion sur une VN, un administrateur démotivé aura tendance à restaurer l'état du système avant l'intrusion : Cela aura un effet curatif mais les "symptômes" seront toujours bien présents, sauf si l'administrateur aura pris la peine de combler les failles utilisées initialement.
Et le "Cloud Computing" dans tout ça ?
Dans le cadre des offres de Cloud Computing, les techniques de virtualisation de systèmes sont effectivement très présentes : On va donc y retrouver, de façon plus ou moins visible, toutes les problématiques liées à ce type de technologies : Ma recommandation serait de poser toutes les questions utiles aux fournisseurs de services "cloud" afin d'évaluer le niveau de sécurité de leurs services.
Prenons-nous au jeu des questions :
Ségrégation des systèmes
- Comment sont séparés mes applications/systèmes vis-à-vis de ceux d'autres clients ?
- Est-il possible de demander à ce que mes systèmes soient sur des systèmes distincts de ceux d'autres clients ?.
Sécurité des données
- Comment sont séparées mes données vis-à-vis de celles d'autres clients ?
- Ou sont stockées mes données ?
- Comment assurez-vous l'intégrité de mes données ?
- Mes données stockées sont-elles cryptées ?
- Quels sont les contrôles d'accès à mes données ?
Transfert des données
- Par quels moyens est-ce que j'envoie mes données sur vos plateformes ? Quelles sont les mesures de sécurité disponibles ?
- Quelles sont les procédures et systèmes pour m'assurer que je puisse disposer à tout moment de mes données ?
Interconnexion
- Par quels moyens mon réseau interne est-il interconnecté à vos plateformes ?
- Comment assurez-vous que vos plateformes/systèmes ne peuvent pas être un point de rebond entre différents clients ?
Gestion des vulnérabilités
- Quel niveau de visibilité puis-je avoir sur votre programme de suivi des vulnérabilités ?
- Comment organisez-vous le suivi des annonces de nouvelles vulnérabilités ?
- A quelle fréquence effectuez-vous des tests de détection de vulnérabilités ?
Gestion des identités
- Est-il possible d'interfacer vos systèmes avec mon infrastructure IAM (Identity & Access Management) ?
- Si les comptes d'accès de mes utilisateurs sont gérés sur vos systèmes, comment en assurez-vous la sécurité ? Comment sont gérés les mouvements de personnel ?
Disponibilité
- Quel est le niveau de SLA que vous proposez ?
- Quelles mesures mettez-vous en œuvre afin de protéger votre service contre les menaces ou erreurs ?
- Est-ce que vos plateformes sont raccordées via de multiples liens réseaux redondants d'ISP différents (Multi-homing) ?
- Avez-vous des systèmes de protection contre les attaques en DDoS ? Comment fonctionnent-ils ?
Sécurité des applicatifs
Pour les applicatifs que vous mettez à disposition pour la gestion du service (web interfaces appelées "Espace Client") :
- Suivez-vous des principes de développement sécurisés comme ceux de l'OWASP ?
- Quel est votre processus de vérification du niveau de sécurité tout au long du cycle de vie du développement de vos applicatifs développés en interne ?
- Pour les composants packagés livrés ou développés par des tiers, quel sont vos demandes sécurité d'un point de vue contractuel et en terme de test de qualité sécurité ?
Supervision sécurité et réponse sur incidents
- Comment supervisez-vous la sécurité de votre service ?
- Quels sont les types d'équipements/systèmes utilisés pour la détection d'anomalies/intrusions/tentatives (IDS, Honeypots, ...) ?
- Quel est le niveau de compétence/expertise des personnes de votre SOC ?
- Êtes-vous en mesure d'assurer la supervision sécurité de mes systèmes et applications ?
BCP/DRP
- Quels sont vos plans de continuité d'activité et de reprise sur désastre ?
- Leurs objectifs et leur niveau sont-ils effectivement compatibles/homogènes avec nos attentes ?
- Est-il possible d'auditer votre BCP ? Votre DRP ? Ont-ils été audités par un tiers de confiance ?
Traçabilité
- Est-il possible d'avoir accès à tous les enregistrements et traces d'accès à nos systèmes, applications et données ?
- Combien de temps conservez-vous ces informations ? Comment en assurez-vous l'intégrité ?
- Est-il possible de les stocker sur des systèmes dédiés et/ou pour une durée précise ?.
Juridique/réglementation
- Quelle est la législation/réglementation (LSI, LCEN, CNIL, ...) applicable à nos plateformes ?
- Êtes-vous concerné par la réglementation (ARCEP) pour les opérateurs de services de télécommunications ?
- Quels sont les recours possibles (Compensation financières, rupture du contrat avant terme, ...) en cas d'incidents de sécurité ou d'incapacité à répondre aux SLA ?
Pour conclure
La sécurité des environnements virtualisés ou des services de type "Cloud Computing" va au delà des aspects purement techniques : Que ce soit sur un cloud interne ou dans le cadre d'un service souscrit auprès d'un tiers, une entreprise doit en intégrer les implications et poursuivre sa gestion du risque.
Après, ayant une expérience passée dans le monde des plateformes d'hébergement mutualisées, je trouve que cela reste assez homogène coté sécurité... C'est le coté "'fuzz" du Cloud Computing : Du neuf basé sur du vieux, trop classique. :-)
Ce qui a radicalement changé c'est surtout le niveau de criticité des applications ou systèmes confiés à un tiers : Nous sommes passés de l'hébergement de sites web Internet à des systèmes critiques. La sécurité des environnements de type "cloud" va donc être d'une importance stratégique dans les années à venir.
Les techniques de virtualisation des environnements informatiques ne datent pas d'hier : elles sont utilisées depuis fort longtemps dans des environnements de type "mainframes".
Depuis quelques bonnes années, les solutions de virtualisation se sont démocratisées et font partie de la trousse à outils de tout bon informaticien qui se respecte : Les VmWare, Hyper-V, Linux KVM et autres Xen sont des technologies très souvent utilisées en entreprise.
Comme toute technologie, ce n'est qu'une fois que celle-ci commence à fonctionner correctement que se pose la problématique de la sécurité (cf ce que nous pouvons voir dans le domaine de la VoIP). Cette "maturation lente et naturelle" de la sécurité des environnements virtualisés a été accélérée par un catalyseur appelé "Cloud Computing" : Les environnements sont transférés depuis les réseaux internes des entreprises sur Internet.
De quelle manière un responsable sécurité doit-il aborder ce changement ? Ayant été récemment interpelé sur ce sujet, il m'a semblé intéressant de partager avec vous quelques réflexions autour de ce thème.
Concernant la virtualisation
Quelques axes de réflexions sur les changements et risques induits par la virtualisation. J'ai volontairement mis de coté les sujets très techniques de compromission de la technologie elle-même... (Pour une prochaine fois peut-être ?)
La prolifération des Machines Virtuelles (VM)
Activer une nouvelle instance d'un système est très facile : La tentation est donc naturellement grande d'instancier plusieurs instances d'un environnement pour des tests, une démonstration, etc... Si les administrateurs en charge de l'infrastructure virtualisée ne possèdent pas les outils leur permettant d'automatiser leurs actions sur un parc virtuellement très important, on va rapidement se retrouver dans une situation ou les serveurs/services ne seront pas tous à jour des correctifs ou supervisés comme il se doit. Une outil de gestion de parc est essentiel : En effet, on perd le coté "1 système d'exploitation <=> 1 serveur physique" : On peut donc plus facilement "égarer" une machine virtuelle...
L'explosion du nombre de VM va aussi rapidement réactiver l'un des vieux démons : la gestion des identités et des accès (le fameux IAM : Identity & Access Management) qui va être encore plus important dans une infrastructure virtualisée.
Le risque de comportements soudains
Dans un environnement virtualisé, une VM peut être très facilement arrêtée, suspendue ou encore dupliquée. Une VM présentant des vulnérabilités sur l'un de ses services réseaux peut donc ne pas être identifiée lors d'un scan de détection de vulnérabilité (car arrêtée ou suspendue durant les tests) ; lorsque celle-ci sera réactivée elle affaiblira automatiquement le niveau de sécurité de l'ensemble.
Le même scénario est aussi vraisemblable dans le cas ou une VM aurait été infectée par un vers informatique : Cette VM peut ne pas être comptabilisée/identifiée comme infectée lors d'une campagne de nettoyage et pourra ressurgir de façon sporadique au sein de l'infrastructure virtualisée et (re)-propager l'infection.
Mécanismes de retour-arrière (ou rollback)
Les mécanismes de retour-arrière sont particulièrement utiles : Il est possible de "revenir dans le temps" et ainsi de remettre une VM dans un état antérieur. Très pratique pour "effaçer" les effets néfastes d'une mise à jour de mauvaise qualité. De même, cela peut réactiver d'anciennes failles de sécurité ou faire revivre des comptes d'accès désactivés ou encore de vieux mots de passe... Très nouveaux comme comme problèmes non ?
Toujours autour du rollback : Dans le cas d'une intrusion sur une VN, un administrateur démotivé aura tendance à restaurer l'état du système avant l'intrusion : Cela aura un effet curatif mais les "symptômes" seront toujours bien présents, sauf si l'administrateur aura pris la peine de combler les failles utilisées initialement.
Et le "Cloud Computing" dans tout ça ?
Dans le cadre des offres de Cloud Computing, les techniques de virtualisation de systèmes sont effectivement très présentes : On va donc y retrouver, de façon plus ou moins visible, toutes les problématiques liées à ce type de technologies : Ma recommandation serait de poser toutes les questions utiles aux fournisseurs de services "cloud" afin d'évaluer le niveau de sécurité de leurs services.
Prenons-nous au jeu des questions :
Ségrégation des systèmes
- Comment sont séparés mes applications/systèmes vis-à-vis de ceux d'autres clients ?
- Est-il possible de demander à ce que mes systèmes soient sur des systèmes distincts de ceux d'autres clients ?.
Sécurité des données
- Comment sont séparées mes données vis-à-vis de celles d'autres clients ?
- Ou sont stockées mes données ?
- Comment assurez-vous l'intégrité de mes données ?
- Mes données stockées sont-elles cryptées ?
- Quels sont les contrôles d'accès à mes données ?
Transfert des données
- Par quels moyens est-ce que j'envoie mes données sur vos plateformes ? Quelles sont les mesures de sécurité disponibles ?
- Quelles sont les procédures et systèmes pour m'assurer que je puisse disposer à tout moment de mes données ?
Interconnexion
- Par quels moyens mon réseau interne est-il interconnecté à vos plateformes ?
- Comment assurez-vous que vos plateformes/systèmes ne peuvent pas être un point de rebond entre différents clients ?
Gestion des vulnérabilités
- Quel niveau de visibilité puis-je avoir sur votre programme de suivi des vulnérabilités ?
- Comment organisez-vous le suivi des annonces de nouvelles vulnérabilités ?
- A quelle fréquence effectuez-vous des tests de détection de vulnérabilités ?
Gestion des identités
- Est-il possible d'interfacer vos systèmes avec mon infrastructure IAM (Identity & Access Management) ?
- Si les comptes d'accès de mes utilisateurs sont gérés sur vos systèmes, comment en assurez-vous la sécurité ? Comment sont gérés les mouvements de personnel ?
Disponibilité
- Quel est le niveau de SLA que vous proposez ?
- Quelles mesures mettez-vous en œuvre afin de protéger votre service contre les menaces ou erreurs ?
- Est-ce que vos plateformes sont raccordées via de multiples liens réseaux redondants d'ISP différents (Multi-homing) ?
- Avez-vous des systèmes de protection contre les attaques en DDoS ? Comment fonctionnent-ils ?
Sécurité des applicatifs
Pour les applicatifs que vous mettez à disposition pour la gestion du service (web interfaces appelées "Espace Client") :
- Suivez-vous des principes de développement sécurisés comme ceux de l'OWASP ?
- Quel est votre processus de vérification du niveau de sécurité tout au long du cycle de vie du développement de vos applicatifs développés en interne ?
- Pour les composants packagés livrés ou développés par des tiers, quel sont vos demandes sécurité d'un point de vue contractuel et en terme de test de qualité sécurité ?
Supervision sécurité et réponse sur incidents
- Comment supervisez-vous la sécurité de votre service ?
- Quels sont les types d'équipements/systèmes utilisés pour la détection d'anomalies/intrusions/tentatives (IDS, Honeypots, ...) ?
- Quel est le niveau de compétence/expertise des personnes de votre SOC ?
- Êtes-vous en mesure d'assurer la supervision sécurité de mes systèmes et applications ?
BCP/DRP
- Quels sont vos plans de continuité d'activité et de reprise sur désastre ?
- Leurs objectifs et leur niveau sont-ils effectivement compatibles/homogènes avec nos attentes ?
- Est-il possible d'auditer votre BCP ? Votre DRP ? Ont-ils été audités par un tiers de confiance ?
Traçabilité
- Est-il possible d'avoir accès à tous les enregistrements et traces d'accès à nos systèmes, applications et données ?
- Combien de temps conservez-vous ces informations ? Comment en assurez-vous l'intégrité ?
- Est-il possible de les stocker sur des systèmes dédiés et/ou pour une durée précise ?.
Juridique/réglementation
- Quelle est la législation/réglementation (LSI, LCEN, CNIL, ...) applicable à nos plateformes ?
- Êtes-vous concerné par la réglementation (ARCEP) pour les opérateurs de services de télécommunications ?
- Quels sont les recours possibles (Compensation financières, rupture du contrat avant terme, ...) en cas d'incidents de sécurité ou d'incapacité à répondre aux SLA ?
Pour conclure
La sécurité des environnements virtualisés ou des services de type "Cloud Computing" va au delà des aspects purement techniques : Que ce soit sur un cloud interne ou dans le cadre d'un service souscrit auprès d'un tiers, une entreprise doit en intégrer les implications et poursuivre sa gestion du risque.
Après, ayant une expérience passée dans le monde des plateformes d'hébergement mutualisées, je trouve que cela reste assez homogène coté sécurité... C'est le coté "'fuzz" du Cloud Computing : Du neuf basé sur du vieux, trop classique. :-)
Ce qui a radicalement changé c'est surtout le niveau de criticité des applications ou systèmes confiés à un tiers : Nous sommes passés de l'hébergement de sites web Internet à des systèmes critiques. La sécurité des environnements de type "cloud" va donc être d'une importance stratégique dans les années à venir.
Cloud computing : la virtualisation à l'échelle planétaire
La virtualisation n'est pas nouvelle dans le monde informatique. Machines, processeurs, stockage, applications... Autant de domaines d'applications variés où ces techniques ont été mises en œuvre dès le début de l'histoire de l'informatique, à une époque où les ressources étaient rares et leur allocation dispensée avec parcimonie. Mais si, aujourd'hui pour des raisons différentes, on virtualise encore et que les techniques ont évolué, le principe reste identique : on introduit une couche logicielle dans le système, qui « voit de plus haut » les ressources de façon à les utiliser avec plus d'efficience. En ce qui concerne la virtualisation des systèmes d'exploitation, un nouveau concept émerge : celui d'hyperviseur. Ce dernier pourrait se substituer aux systèmes d'exploitation « classiques », en interfaçant le hardware (processeur, CPU) et les systèmes d'exploitation, voire directement des applicatifs. Dans la première catégorie, on trouve les offres VMWare ou Xen ; dans la seconde, LiquidVM (BEA).
Plus généralement, si l'essor de la virtualisation semble s'accélérer dans les entreprises, c'est parce que jusqu'à présent, le concept était surtout appliqué sur les machines de développement et de test, plus rarement sur les serveurs de production. Si le marché a gagné en maturité, la pression reste cependant forte sur les besoins de consolidation et de rentabilisation, et se posent de plus en plus crûment des questions liées à la facture énergétique ou à des préoccupations d'ordre écologique. Profitant de ce contexte, le marché envoie un signal puissant aux clients, avec des mots-clés qui marquent : simplicité, fiabilité, économie...
Bien entendu, la complexité accrue des systèmes accélère le besoin de virtualisation. Elle augmente également le poids des conséquences d'une panne qu'on ne peut jamais écarter. Autre point rarement évoqué : le surcoût « machine » nécessaire au bon fonctionnement de la virtualisation (overhead) un surcoût non négligeable.
C'est dans ce contexte qu'on évoque aujourd'hui une virtualisation à l'échelle de la planète : le « cloud computing ». Ce dernier (qu'on assimile parfois abusivement à l'utility computing) reprend l'image habituellement utilisée du nuage (cloud) pour représenter l'Internet. Ensemble indéterminé de machines reliées entre elles et accessibles par l'Internet, le cloud computing s'appuie techniquement sur le Grid computing. Celui-ci permet d'automatiser nombre de tâches de gestion de clustering, de faire exécuter une application sur des machines différentes (type d'architectures CPU, cycles etc.), ou de « découper » une application en plusieurs sous-ensembles traités par le « nuage ». Google, l'un des promoteurs importants de ce concept, est suivi par d'autres acteurs majeurs des TIC, IBM, Microsoft ou Amazon... Tous pratiquent déjà le cloud computing pour leur propre compte.
Plus généralement, si l'essor de la virtualisation semble s'accélérer dans les entreprises, c'est parce que jusqu'à présent, le concept était surtout appliqué sur les machines de développement et de test, plus rarement sur les serveurs de production. Si le marché a gagné en maturité, la pression reste cependant forte sur les besoins de consolidation et de rentabilisation, et se posent de plus en plus crûment des questions liées à la facture énergétique ou à des préoccupations d'ordre écologique. Profitant de ce contexte, le marché envoie un signal puissant aux clients, avec des mots-clés qui marquent : simplicité, fiabilité, économie...
Bien entendu, la complexité accrue des systèmes accélère le besoin de virtualisation. Elle augmente également le poids des conséquences d'une panne qu'on ne peut jamais écarter. Autre point rarement évoqué : le surcoût « machine » nécessaire au bon fonctionnement de la virtualisation (overhead) un surcoût non négligeable.
C'est dans ce contexte qu'on évoque aujourd'hui une virtualisation à l'échelle de la planète : le « cloud computing ». Ce dernier (qu'on assimile parfois abusivement à l'utility computing) reprend l'image habituellement utilisée du nuage (cloud) pour représenter l'Internet. Ensemble indéterminé de machines reliées entre elles et accessibles par l'Internet, le cloud computing s'appuie techniquement sur le Grid computing. Celui-ci permet d'automatiser nombre de tâches de gestion de clustering, de faire exécuter une application sur des machines différentes (type d'architectures CPU, cycles etc.), ou de « découper » une application en plusieurs sous-ensembles traités par le « nuage ». Google, l'un des promoteurs importants de ce concept, est suivi par d'autres acteurs majeurs des TIC, IBM, Microsoft ou Amazon... Tous pratiquent déjà le cloud computing pour leur propre compte.
Inscription à :
Articles (Atom)