Sécurité du cloud

La non-interopérabilité des fournisseurs

Un client peut éprouver le besoin de changer de fournisseur de cloud. Celui-ci ne peut aujourd'hui pas effectuer un transfert de stockage directement de son fournisseur vers un autre. Néanmoins, la norme CDMI (Cloud Data Management Interface) décrit un format d'échange qui permet de déplacer les données d'un environnement cloud vers un autre[4].

Le chiffrement dans le cloud

Le client peut utiliser le chiffrement des données pour le stockage dans le cloud, mais il reste à définir qui doit contrôler les clés de chiffrement et de déchiffrement. En toute logique, ceci doit être géré par le client[5].

L'intégrité des données

Dans le cloud, il est nécessaire d'assurer l'intégrité des données pendant un transfert ou un stockage. Il faut donc que les opérations sur les données soient contrôlées afin de n'effectuer que les opérations qui sont autorisées. Il n'existe actuellement pas de standard commun entre les fournisseurs de cloud[5].

La gestion des logs

Dans le respect du Payment Card Industry Data Security Standard (PCI DSS), les logs doivent être fournis au gestionnaire de sécurité[5].

Le stockage

Les données peuvent être transférées entre plusieurs datacenter géographiquement éloignés. Le particulier ou l'entreprise ne connait pas la position des données entre chaque datacenter[6].

La confidentialité

Le propriétaire des données doit savoir quelles informations sont gardées et dans certains cas être capable de demander leur suppression. Pour ce qui est du paiement sécurisé ou Payment Card Industry Data Security Standard (PCI DSS), les données bancaires et la trace des transactions doivent pouvoir être transférées aux autorités et personnes chargées des régulations[7].

La sécurité physique

La sécurité physique est rompue avec le modèle du cloud, à cause de la notion de partage de ressources et de virtualisation. Une machine physique partage ses ressources avec les différentes machines virtuelles qu'elle héberge et ceci indépendamment du client de la machine[5]. Il revient logiquement au fournisseur de choisir ou mettre en place son architecture et quelle sécurité physique est déployée, mais aussi protéger et documenter l’accès au données utilisateur.

L'audit

Le fournisseur de cloud doit être audité sur la sécurité de ses infrastructures et de ses solutions par une société externe ou passer acquérir une certification[8].

Les mises à jour

Afin de bénéficier des mises à jour de sécurité sur les produits qui sont installés ou utilisés sur l'infrastructure cloud, le client doit s'assurer d'effectuer régulièrement les mises à jour[5].

Test de sécurité de l'image de base

Le cloud est basé sur la virtualisation, ceci permet au fournisseur de créer une image de base sécurisée et à jour afin de déployer à la demande d'un client une machine ou un service[9]. Elle permet au fournisseur de mettre en place des patchs de sécurité mais également de tester les impacts de l'installation de celui ci[9].

La sécurité de la localisation des données

Dans le cloud, les données d'un particulier ou d'une entreprise sont hébergées chez le fournisseur. Les lois concernant le transfert de données personnelles ainsi que la conservation des données peuvent différer d'un pays à l'autre[10]. Dans le cas où des données violent la loi de l’État où elles résident il y a un risque de saisie par le gouvernement[4]

La confidentialité des données

Le client doit connaître l'utilisation de ses données et pouvoir faire valoir ce droit de confidentialité devant la justice afin que le fournisseur justifie de l'utilisation de ses données[5].

Les données confidentielles

• Toute information permettant d'identifier un individu[5].
• Toute information récoltée par le biais d'un ordinateur personnel[5].
• Toute information permettant la localisation d'un périphérique personnel[5].
• Toute information personnelle d'un individu[5].

Le cloud computing introduit le partage de ressources, ce qui peut potentiellement mener à des attaques de type attaque par canal auxiliaire (écoute passive d'informations) ou canal caché (envoi d'informations) entre différentes machines virtuelles évoluant dans le même environnement[11].

Le problème d'isolation réside dans le fait que l’environnement (machine virtuelle) d'un attaquant peut potentiellement se retrouver sur la même machine physique d'un utilisateur cause que cette dernière héberge de multiples machines virtuelles. Cela lui permet de mettre en place différentes attaques matérielles ou logicielles pour écouter ou perturber les autres machines virtuelles[11].

La virtualisation est liée au cloud computing. En effet, le fournisseur de cloud propose à ses clients d'acquérir son propre serveur autrement dit sa propre machine virtuelle. Le fournisseur de cloud, propose ce service sans prendre connaissance du système d'exploitation installé sur cette machine virtuelle, ni de la configuration de celui-ci. Néanmoins, ce dernier propose un système de sécurité comme service (Security as a service) basé sur l'introspection des machines virtuelle[12].

L'introspection des machines virtuelles pour la sécurité

Pour assurer la sécurité des ressources des machines virtuelles, il existe un composant permettant de contrôler la mémoire, le disque virtuel et le système d'exploitation installé sur celle-ci. Ce composant est basé sur l'introspection de la machine virtuelle (VMI). Un exemple d'un tel composant est Xen Access. Il permet de contrôler que les ressources soient sécurisées et qu'il n'y a à pas eu d'intrusion avant le démarrage de la machine virtuelle[13].

La protection de la mémoire

Une machine virtuelle peut subir une attaque basée sur la modification de la mémoire. L'attaquant peut soit y introduire un Rootkit ou des données dans les zones protégées de celle-ci[13]. Quelques implémentations de protection pour la mémoire :

• CoPilot, un noyau de système d'exploitation basé sur le contrôle d'intégrité et la détection des modifications illégales d'un noyau Linux[13].
• Paladin, un composant qui utilise la virtualisation pour la détection et le contrôle d'une attaque par Rootkit[13].
• Xenkimono, un composant qui détecte les violations des règles de sécurité en utilisant l'introspection de la machine virtuelle (VMI). Il implémente un contrôle d'intégrité, pour détecter la modification du code du noyau système[13].
• SecVisor, un petit hyperviseur qui assure que le code exécuté par le noyau système est approuvé par l'utilisateur. Il utilise pour cela la virtualisation de la mémoire physique[13].

La sécurisation de l'exécution de code

La sécurisation de l'exécution de code dans le noyau permet de prévoir les exécutions malveillantes. Un exemple de système permettant de contourner ce problème et d'assurer la protection de l'exécution de code est Manitou. Ce système utilise le moniteur de mémoire virtuelle (VMM) afin de calculer un hash sur chaque page mémoire et de vérifier avant l'exécution du code si le hash est dans la liste des hash autorisés[13].

La sécurité des flux de données

Une attaque sur les machines virtuelles peut agir sur des flux de données par exemple. C'est pour cela que la mise en place de système de contrôle et d'intégrité doit permettre d'éviter la modification des flux de données. Lares est un exemple de composant permettant via l'introduction d'un outil sur le système d'exploitation cible, de vérifier si la machine virtuelle est sécurisée. Il utilise pour cela la vérification des règles de sécurité et l'introspection de la machine virtuelle (VMI)[13].

Il n'y a pour le moment pas de norme ISO standardisant explicitement le cloud[14]. Cette prochaine norme est en cours de création et permettra de standardiser le cloud de manière à rendre disponible une API unique pour l'utilisation de plusieurs fournisseurs de cloud mais également définir la sécurité requise pour le cloud. Néanmoins, les fournisseurs de cloud concrétisent leur niveau de sécurité en obtenant des normes sur la sécurité de l'information applicables en partie sur le cloud[15]. Ces normes sont exposées ci-dessous.

• ISO 7498-2 : la norme ISO 7498-2 est un volet sécurité relativement ancien[16] de la norme ISO 7498 plus connue sous le nom de Modèle OSI. Elle définit l'exigence en matière de sécurité sur des thèmes comme : l'identification, les autorisations, la confidentialité, la disponibilité, l'intégrité et la non-repudiation[14]. La sécurité du cloud peut être guidée par cette norme afin d'être efficace et sécurisée[14].
• ISO/CEI 27001 : la norme ISO 27001 est une norme reconnue à l'échelle internationale pour l'évaluation de la sécurité des environnements informatiques[15]. Cette norme concernant la sécurité de l'information est basée sur les méthodes de gestion de la sécurisation de l'information, la confidentialité, l'intégrité et la disponibilité[15].
• ISO/CEI 27017 : la norme ISO/CEI 27017 est une déclinaison du guide de bonnes pratiques ISO/CEI 27002 traitant spécifiquement de l'informatique en nuages.
• ISO/CEI 27018 : la norme ISO/CEI 27018 est une norme récente (août 2014) corollaire à ISO 27001 et elle concerne les prestataires des services Cloud public. Elle propose un ensemble de bonnes pratiques pour la protection des informations personnelles identifiables.

La sécurité dans le cloud peut être définie dans le Service Level Agreement (SLA), afin de prévenir et garantir les niveaux de sécurité pour chaque service[17].

Le prestataire ou le fournisseur de cloud

la société proposant une offre cloud.

Le client

le particulier ou la société qui investit dans une offre cloud afin d'y héberger des données potentiellement confidentielles ou personnelles.

Le Service Level Agreement (ou SLA) permet de définir la sécurité mise en place contre les attaques malveillantes et les pannes éventuelles, entre le prestataire et le client[17].

Ce document est important pour les deux parties, s'il est utilisé correctement il permet de[17] :

• identifier et définir les besoins du client
• fournir un cadre pour la compréhension
• simplifier les questions complexes
• réduire les zones de conflit
• encourager le dialogue en cas de conflit
• éliminer les espérances peu réalistes

Le SLA n'est pas adapté pour le cloud computing à cause de son architecture bien différente des systèmes informatiques précédents[18]. En effet, le cloud est basé sur une architecture centralisée dans des centres de traitements de données qui sont exposés sur internet[17]. Le SLA garantit aujourd'hui, sauf dans des cas bien particuliers, les termes suivants :

Réclamation au fournisseur à la suite d'une panne

Le client doit ouvrir un ticket au support en saisissant les informations nécessaires spécifiées dans le SLA[18].

Réclamation au fournisseur à la suite d'une faute du client

Le client peut être pénalisé financièrement ou son compte peut être bloqué si un problème survient et le met en cause. Ceci est une cause de violation du contrat et permet de prévoir des attaques ou autres actions provenant de l'infrastructure du client[18].

Réseau Privé

Le fournisseur garantit 99,9 % de disponibilité du réseau privé entre le datacenter et le client. Ceci inclut la mise en place et sécurisation d'un VPN, la bande passante maximale possible et les outils d'analyses du trafic sur le réseau[17].

Réseau Public

Le fournisseur garantit 99,9 % de disponibilité du réseau public (internet), avec des redondances sur les connexions[18].

La redondance des infrastructures

Le fournisseur garantit 99,9 % de disponibilité des infrastructures et des services[19].

Le changement de matériel

Pour répondre à la demande du client ou un besoin de maintenance de l'infrastructure, des changements de matériels peuvent être nécessaires. Ces changements doivent être planifiés et si ce changement n'est pas possible, une pénalité sera appliquée au fournisseur[19].

Pour garantir un niveau de sécurité, le SLA doit définir les méthodes utilisées pour maintenir et garantir la sécurité de l'infrastructure cloud qui sera utilisée par le client. Les termes en discussions pour la standardisation du SLA sont listés ci-dessous[19] - [8] :

Accès d'utilisateur privilégié

Les administrateurs ont un accès global aux informations, il est nécessaire de définir les administrateurs habilités à intervenir sur les infrastructures du client dans le cadre de la confidentialité des données d'une entreprise[19] - [8].

Conformité règlementaire

Le client est responsable de la sécurité et l'intégrité de ces données. Pour cela, le fournisseur de cloud fournit les services et outils nécessaires au bon déroulement de ces tâches. Le prestataire traditionnel est soumis à des audits et des certifications. Les fournisseurs de cloud qui refusent ces audits doivent le signaler aux clients et spécifier que le client ne peut utiliser que les fonctions les plus insignifiantes[19] - [8].

L'emplacement des données

Dans le cloud, une notion de localisation des données est difficile à acquérir. En effet, un fournisseur de cloud dispose de plusieurs datacenter à travers le monde et dans des pays différents. C'est pour cela qu'il est nécessaire que le client prenne connaissance de la localisation de ces données, car celles-ci peuvent être stockées dans des pays ou les lois de confidentialité des données sont différentes[19] - [8].

Ségrégation de données

Les données dans le cloud sont présentes sur plusieurs centres de données afin que le fournisseur de cloud puisse garantir un service de haute disponibilité à son client. La sécurisation des données grâce au chiffrement est nécessaire pour la transmission de celle-ci vers les différents centres de données. Le client doit prendre connaissance de la méthode de chiffrement ainsi que la méthode utilisée pour le transfert approuvée par un spécialiste[19] - [8].

La restauration

Le client doit connaitre le niveau de service en matière de restauration des données. Les fournisseurs ne sont pas dans l'obligation de répliquer les données du client. Dans le cas où l'infrastructure utilisée par le client subirait une défaillance, celui-ci pourrait perdre une partie ou la totalité de ces données si toutefois le fournisseur n'inclut pas dans son offre la réplication ou la sauvegarde des données[19] - [8].

Le support

La surveillance des activités illégales sur les interfaces du cloud est très difficile. La raison de cette difficulté est la centralisation des infrastructures qui engendre la présence de plusieurs clients sur un même serveur, la localisation des datacenters. Il est donc très difficile pour le fournisseur de détecter et bloquer les utilisations malveillantes des infrastructures. Cette information doit être spécifiée au client afin que celui-ci soit vigilant[19] - [8].

L'efficacité

Il est nécessaire pour le client d'avoir des informations sur l'infrastructure du fournisseur et des garanties quant à la fiabilité de ces solutions. Le client externalisant ces infrastructures chez un fournisseur de cloud a besoin de garanties sur ces applications et ces données afin d'être sûr que celui-ci ne subit pas des pertes à la suite d'une panne[19] - [8].

L'attaque par balayage de port permet à celui-ci de découvrir des ports de communication exploitables. Cette attaque peut être évitée grâce à des systèmes de sécurité comme un pare-feu ou encore un système de détection d'intrusion ((en) IDS : Intrusion System Detection)[21]. Les infrastructures du cloud sont sensibles à ce type d'attaque si celle-ci est effectuée en parallèle[22]. Un système tel que l'IDS analyse une partie du trafic et ne détecte donc pas une attaque par scan de port si celle-ci est effectuée avec différents scanner[23]. Les solutions de sécurité actuelle ne sont pas adaptées pour ce type d'attaque sur une telle infrastructure[22].

L'attaque par déni de service a pour but de rendre un service indisponible par une surcharge réseau par exemple. Le fournisseur doit mettre en œuvre les solutions contre ces attaques[24]. Cette attaque peut être évitée grâce à la scalabilité du cloud. Des services comme Amazon permettent dynamiquement de mettre davantage de ressources ou d'instances suivant le besoin[24]. Néanmoins, les clients n'utilisant pas les services de scalabilité sont soumis aux risques de ces attaques, il est dans ce cas difficile de détecter ces attaques pour les bloquer cause du potentiel nombre d'attaques simultanées[23].

Le client et le fournisseur doivent s'assurer que les logiciels qu'ils utilisent sont à jour afin d'éviter l'exploitation des bogues logiciels. Cette action ne permet pas de les éviter mais de limiter les risques[24].

L'attaque de l'homme du milieu a pour but d'intercepter les communications entre un client et un serveur afin de consulter, capturer et contrôler la communication en toute transparence[25].

L'analyseur de paquets est une application ou un périphérique qui permet de lire, capturer les données qui transitent sur un réseau. Cette attaque permet à l'attaquant de récupérer les données puis les lire[25].

Le principe de cette attaque est d'injecter sur une des plateformes du cloud (Saas, Iaas, Paas) du code malicieux afin de compromettre l'infrastructure victime[25].

Les attaques distribuées telles qu'un déni de service ont un impact économique pour le client[26]. Ces attaques peuvent être contrées grâce à la scalabilité du cloud et donc engendrer des coûts supplémentaire pour le client[26]. Dans le cas où le client n'a pas mis ce type de solution en place, il risque que son infrastructure soit hors service et donc des pertes de bénéfices pour celui-ci[26].

La mutualisation du matériel permet d'optimiser les coûts par rapport aux systèmes conventionnels (afin de réaliser des économies) et de développer des applications partagées sans avoir besoin de posséder ou de louer chez un hébergeur ses propres serveurs. Cela évite aussi toute maintenance des machines. Ces avantages peuvent pousser a l'utilisation du cloud computing et rendre acceptable une prise de risque plus forte.

Si un fournisseur tombe en faillite, le client perd l'accès à ses applications et ses données car l'infrastructure du fournisseur passe hors ligne. Les données du fournisseur ne sont donc pas récupérables et deviennent la propriété du créancier du fournisseur de cloud[26]. Cette situation peut entraîner la faillite du client si toutefois celui-ci est une entreprise et que les données qui étaient hébergées chez le fournisseur soient sensibles et indispensables pour l'entreprise.

Le système de paiement aux ressources consommées peut engendrer une surfacturation de la part du fournisseur pour des ressources allouées mais non consommées[26]. Cette surfacturation est une perte pour le client.

• (en) M. Balachandra Reddy Kandukuri, Ramakrishna Paturi V et D^r Atanu Rakshit, « Cloud Security Issues », Services Computing, 2009. SCC '09. IEEE International Conference on, IEEE,‎ 21 septembre 2009, p. 517-520 (ISBN 978-0-7695-3811-2, DOI 10.1109/SCC.2009.84)
• (en) S. Ramgovind, MM. Eloff et E. Smith, « The Management of Security in Cloud Computing », Information Security for South Africa (ISSA), 2010, IEEE,‎ 30 septembre 2010, p. 1-7 (ISBN 978-1-4244-5493-8, DOI 10.1109/ISSA.2010.5588290)
• (en) Sato Hiroyuki, Kanai Atsushi et Tanimoto Shigeaki, « A Cloud Trust Model in a Security Aware Cloud », Applications and the Internet (SAINT), 2010 10th IEEE/IPSJ International Symposium on, IEEE,‎ 7 octobre 2010, p. 121-124 (ISBN 978-1-4244-7526-1, DOI 10.1109/SAINT.2010.13)
• (en) Mihai Christodorescu, Reiner Sailer, Douglas Lee Schales, Daniele Sgandurra et Diego Zamboni, « Cloud Security Is Not (Just) Virtualization Security », CCSW '09 Proceedings of the 2009 ACM workshop on Cloud computing security, ACM,‎ 2009, p. 97-102 (ISBN 978-1-60558-784-4, DOI 10.1145/1655008.1655022)
• (en) Yanpei Chen, Vern Paxson et Randy H. Katz, « What’s Ncew About Cloud Computing Security? », EECS Department, University of California, Berkeley,‎ 20 janvier 2010, p. 1-8, article n^o UCB/EECS-2010-5
• (en) Michael Armbrust, Armando Fox, Rean Griffith, Anthony D. Joseph, Randy Katz, Andy Konwinski, Gunho Lee, David Patterson, Ariel Rabkin, Ion Stoica et Matei Zaharia, « A view of cloud computing », Magazine Communications of the ACM - Volume 53 Issue 4, ACM,‎ avril 2010, p. 50-58 (DOI 10.1145/1721654.1721672)
• (en) Krešimir Popović et Željko Hocenski, « Cloud computing security issues and challenges », Conference Publications,‎ 29 juillet 2010, p. 344-349 (ISBN 978-1-4244-7763-0)
• (en) Vic Winkler, « Securing the Cloud Cloud Computer Security Techniques and Tactics », Book,‎ avril 2011, p. 65, 68, 72, 81, 218–219, 231, 240 (ISBN 978-1-59749-592-9)
• (en) Damien Riquet, Gilles Grimaud et Michaël Hauspie, « Large-scale coordinated attacks: Impact on the cloud security », The Second International Workshop on Mobile Commerce, Cloud Computing, Network and Communication Security 2012,‎ 6 juillet 2012, p. 558-563
• Damien Riquet, Gilles Grimaud et Michaël Hauspie, « Étude de l’impact des attaques distribuées et multi-chemins sur les solutions de sécurité réseaux », 9^e Conférence Internationale Jeunes Chercheurs, Lille, France, Octobre 2012,‎ octobre 2012, p. 1-8
• (en) David Molnar et Stuart Schechter, « Self Hosting vs. Cloud Hosting:Accounting for the security impact of hosting in the cloud », Microsoft Research,‎ 2010, p. 1-18
• (en) Farhan Bashir Shaikh et Sajjad Haider, « Security threats in cloud computing », Internet Technology and Secured Transactions (ICITST), 2011 International Conference for,‎ 2012, p. 214-219 (ISBN 978-1-4577-0884-8)
• (en) Neetika Karwasra1 et Mukesh Sharma2, « cloud computing : security risks and its future », Computer Engineering Department, The Technology Institute of Textile and Sciences 1, 2 Bhiwani (Haryana),‎ 2012, p. 214-219
• (en) Arora Priyanka, Singh Arun et Tyagi Himanshu, « Evaluation and Comparison of Security Issues on Cloud Computing Environment », World of Computer Science and Information Technology Journal (WCSIT),‎ 2012, p. 179-183 (ISSN 2221-0741)

• Cybersécurité
• Sécurité des infrastructures du cloud
• RGPD
• CLOUD Act
• Cloud européen
• Bouclier de protection des données UE-États-Unis

• (fr) La première norme ISO sur l'informatique dans "les nuages", le Cloud Computing, en préparation
• (en) CSA Guide
• (en) 5 famous cloud security blunders
• (fr) https://www.isdecisions.fr/probleme-securite-stockage-cloud/