Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 

De la Théorie à la pratique





















Abonnez-vous gratuitement à notre NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Se désabonner

Cyrille Barthélémy, Intrinsec : Audit de sécurité dans le cloud computing, de nouvelles pratiques en émergence

avril 2010 par Cyrille Barthélémy, directeur des activités sécurité d’Intrinsec

Considérons les modèles de services SaaS, Paas et IaaS posés depuis 2009 par le NIST[1]. Prenons les quatre modèles de déploiement privé, public, communautaire ou hybride. Chaque couple modèle de service/modèle de déploiement a des spécificités qu’il faut prendre en compte dans le plan d’audit général ou les expressions de besoins ponctuelles afin d’évaluer ou de contrôler la sécurité.

Les cercles de réflexion déjà sensibilisés au sujet du Cloud s’accordent à dire qu’il s’agit d’une agrégation de technologies disposant de bonnes pratiques, pour autant la sécurité de l’ensemble (et la façon de l’évaluer) n’est pas perçue de manière aussi transparente ("le tout est plus grand que la somme des parties").

Quant aux analystes, ils observent que la réticence à mettre en œuvre une solution de Cloud computing vient du manque de visibilité sur la sécurité des clouds : cette observation est renforcée par la multiplication des audits, tests d’intrusion et contrôles de conformité sur ces environnements mutualisés.

Enfin le retour d’expérience des prestataires de services de sécurité en termes d’audits ou de tests d’intrusion sur « les nouveaux clouds » montrent que l’infrastructure sous-jacente, les couches de virtualisation du réseau, du stockage et des systèmes sont le plus souvent laissés de côté ; tant au niveau technique qu’organisationnel.

Considérons votre solution SaaS hébergée sur un cloud :

La forte mutualisation et la grande proximité de données tierces limitent fortement les degrés de liberté des campagnes de tests et ne permettent pas de faire une évaluation réaliste de la sécurité de votre système. Par ailleurs vous n’aviez pas besoin des accès au web service, à l’API, ... Vous n’avez donc pas souscrit à l’option et ne vous souciez pas de sécuriser les accès… Pourtant ils présentent un risque et devraient faire partie de l’évaluation !

Prenons maintenant votre solution IaaS hébergée sur un cloud privé externe :

Vos systèmes s’exécutent à l’extérieur de votre entreprise, confinés dans le cloud privé de votre prestataire, sur des infrastructures mutualisées avec d’autres clients. L’évaluation classique se concentrera sur l’infrastructure que l’on vous fournit. Cependant le contrôle des systèmes mutualisés est majeur et doit être décrit dans les scénarios de test :

. les attaques latérales (lancés depuis l’infrastructure d’un autre client),

. les capacités de malveillances internes sur les données,

. les capacités d’attaques de backoffice de gestion du cloud (ingénierie sociale sur le système de gestion du changement, attaques des zones d’administration privilégiés).

L’audit effectif des systèmes mutualisés sera sans aucun doute un point de friction à venir avec votre hébergeur : Il est déjà compliqué d’effectuer totalement et sans retenue l’audit d’un système mutualisé simple (un DNS ou un relai de messagerie) ; L’audit (ou pire, le test d’intrusion) sur un hyperviseur ou un SAN mutualisé sera encore plus complexe à réaliser.

Votre hébergeur solutionnera le problème par des revues théoriques ou des extractions de configuration qui sont moins probantes sur ces points stratégiques. Assurez vous donc lors de la revue de votre contrat avec votre hébergeur d’avoir pris en compte toute les considérations de sécurité, pour faire autoriser ce type de contrôle par la suite ou obtenir une transparence sur les mesures de sécurité déployées.

Heureusement certains organismes travaillent sur un début de solution à toutes ces problématique de sécurité sur le Cloud :

L’analyse de risque publiée par l’ENISA [2] et le guide de bonnes pratiques préparé par la Cloud Security Alliance [3] mettent en avant un certain nombre de risques spécifiques ou génériques, des listes de contrôles ainsi qu’un ensemble de bonnes pratiques qui peut être dérivé en liste de contrôle vis à vis de l’état de l’art du moment. Outil prometteur, la matrice de contrôle en cours de construction par la CSA [4] viendra d’ici quelques mois compléter ce premier arsenal.

Considérant les technologies en place, de nombreuses bonnes pratiques et outils de contrôle sont déjà disponibles. Les référentiels et les compétences adaptés aux exigences de sécurité et aux modèles de déploiement restent à développer, pour fournir un cadre minimal pour évaluer la sécurité de ces infrastructures.


[1] http://csrc.nist.gov/groups/SNS/clo...
[2] http://www.enisa.europa.eu/act/rm/f...
[3] http://www.cloudsecurityalliance.org/
[4] http://www.cloudsecurityalliance.or...




Voir les articles précédents

    

Voir les articles suivants