Utilisateur:RKCreeew/VeilleStrategique

Une page de Wikipédia, l'encyclopédie libre.
Article principal : cloud computing.

Les échanges de données Inter-Cloud se sont les échanges qui se font entre différents providers de Cloud, tels que AWS, AZUR, GCP et bien d'autres, les échanges doivent se faire sans problème de compatibilité et de sécurité.

Qu'est ce que l'Inter-cloud ?[modifier | modifier le code]

Définition[modifier | modifier le code]

Stratégie Inter-Cloud

Par définition, l'Inter-Cloud est une entreprise qui implique l'interconnexion des infrastructures de plusieurs fournisseurs de cloud [1]. c'est un terme qui fait référence à un modèle théorique pour les services de cloud computing basé sur l'idée de combiner de nombreux clouds individuels différents en une masse homogène en termes d'opérations à la demande. L'inter-cloud ferait simplement en sorte qu'un cloud puisse utiliser des ressources hors de sa portée, en profitant de contrats préexistants avec d'autres fournisseurs de cloud.[2],[3].

Explication[modifier | modifier le code]

L'Inter-cloud est un "Cloud de Cloud" mondial interconnecté et une extension du "réseau de réseaux" Internet sur lequel il repose [2],[4]. Le scénario Inter-cloud repose sur le concept clé selon lequel chaque cloud ne dispose pas de ressources physiques infinies ou d'une empreinte géographique omniprésente. Si un cloud sature les ressources de calcul et de stockage de son infrastructure ou si l'on demande à un cloud d'utiliser des ressources dans une région géographique où il n'a pas d'empreinte, il sera toujours en mesure de satisfaire les demandes d'allocation de services envoyées par ses clients [2],[5]. Au même titre qu'à la manière dont les opérateurs mobiles mettent en œuvre l'itinérance et l'interopérabilité inter-opérateurs [2].

Problèmes liés aux échanges de données[modifier | modifier le code]

Lors d'un échange de données entre différents fournisseur de cloud il se pose plusieurs problèmes, nous allons donc voir les principaux.

Au niveau de la législation[modifier | modifier le code]

La législation et les cadres de conformité soulèvent d'autres défis en matière d'externalisation des données, des applications et des processus, autrement dit la RGPD. Les normes élevées de confidentialité dans l'Union européenne, par exemple, et leurs variations juridiques entre les pays du continent donnent lieu à des défis techniques et organisationnels spécifiques[6]. Par exemple, la législation italienne exige que les données gouvernementales des citoyens italiens, si elles sont collectées par des agences officielles, doivent rester en Italie. Ainsi, l'utilisation d'un fournisseur de services en Cloud situé hors d'Italie pour la réalisation d'un service d'administration en ligne fourni aux citoyens italiens, violerait immédiatement cette obligation[7].

Au niveau de la sécurité[modifier | modifier le code]

Conséquences des failles de sécurité[modifier | modifier le code]

Le cloud computing crée un grand nombre de problèmes et de défis de sécurité [6]. Ces problèmes vont de la confiance requise du fournisseur de cloud et des attaques sur les interfaces de cloud, à l'utilisation abusive des services de cloud pour des attaques sur d'autres systèmes [7].

Un attaquant qui a accès au composant de stockage en cloud est en mesure de prendre des snapshot ou de modifier les données dans le stockage. Cette opération peut être effectuée une fois, plusieurs fois ou en continu. Un attaquant qui a également accès à la logique de traitement du Cloud peut également modifier les fonctions et leurs données d'entrée et de sortie[7].

Si un attaquant peut accéder à des jetons Kerberos, qui sont générer par Microsoft Passport, il peut accéder à tous les services de la victime[8], tout comme l'attaque contre MS Cardspace, qui peut également être appliquée aux profils de navigateur SAML (profils jeton et artefact). En résumés les protocoles d’authentification basés sur navigateur actuels pour le Cloud ne sont pas sécurisés, car le navigateur n’est pas en mesure d’émettre des jetons de sécurité basés sur XML par lui-même, et les systèmes fédérés de gestion de l’identité stockent des jetons de sécurité dans le navigateur, où ils ne sont protégés que par la PNE (non sécurisée) [9].

Un utilisateur malveillant externe au Cloud effectue souvent des attaques DoS ou DDoS pour affecter la disponibilité des services et des ressources Cloud[10]. L'une des nombreuses raisons pour lesquelles l'attaque DDoS constitue une menace sérieuse est qu'il s'agit d'une attaque dévastatrice dans le cloud. L'attaquant déguise ou falsifie généralement la section "adresse IP" de l'en-tête d'un paquet afin de cacher son identité à sa victime. Cela rend extrêmement difficile de suivre la source de l'attaque [11].

Exemple d'attaques pendant les échanges de données[modifier | modifier le code]

Signature XML Un type bien connu d’attaques sur les protocoles utilisant la signature XML pour l’authentification ou la protection de l’intégrité est l’élément de signature XML. Ceci s’applique bien sûr aux Services Web et donc aussi au Cloud Computing.[12] Un message SOAP est envoyé par un client valide. Le corps de SOAP contient une demande pour le fichier « me.jpg » et a été signé par l’expéditeur.[13] La signature est incluse dans l’en-tête SOAP et fait référence au fragment de message signé utilisant un XPointer à 1. Si un attaquant écoute le message, il peut effectuer l’attaque suivante. [12]. En général, l'attaquant injecte des données non autorisées dans un document XML signé, ainsi qu'une construction possible de ce document, de sorte que l'intégrité et l'authenticité sont toujours vérifiées, mais de manière non véridique. un adversaire peut être capable de modifier des documents valides afin d'obtenir un accès non autorisé à des ressources protégées[14].

Machine Zombie : Par le biais d'Internet, un attaquant tente d'inonder la victime en envoyant des requêtes à partir d'hôtes innocents du réseau. Ces types d'hôtes sont appelés des machines zombies. Une telle attaque interrompt le comportement attendu du cloud et affecte la disponibilité des services du cloud. Le cloud peut être surchargé pour répondre à un certain nombre de demandes et donc épuisé, ce qui peut provoquer des attaques de type DoS (Denial of Service) ou DDoS (distributed denial of service) aux serveurs. Le cloud inondées par les demandes des attaquants ne peut pas répondre aux demandes valides des utilisateurs[15],[16].

Attaque par injection de service : L'injection de malware dans le cloud est l'attaque qui tente d'injecter un service, une application ou même une machine virtuelle malveillante dans le système cloud en fonction des modèles de service cloud (SaaS, [[Platform as a service|PaaS] et IssA)[17],[18]. Il peut fournir un service malveillant aux utilisateurs. Les logiciels malveillants du Cloud affectent les services Cloud en modifiant (ou en bloquant) les fonctionnalités de celui-ci. Prenons un cas dans lequel un adversaire crée ses services malveillants et les ajoute au système Cloud. Si un adversaire réussit à le faire, les requêtes valides des utilisateurs sont automatiquement redirigées vers les services malveillants de l'attaquant.[19],[18].

Le phishing : Les attaques de phishing sont bien connues pour manipuler un lien Web et rediriger un utilisateur vers un faux lien pour obtenir des données sensibles. Dans le Cloud, il est possible qu'un attaquant utilise le service Cloud pour héberger un site d'attaque de phishing afin de pirater les comptes et services d'autres utilisateurs dans le Cloud[20].

Attaques Diverses :

  • L'analyse des ports
  • l'usurpation d'adresse IP
  • l'empoisonnement DNS

sont également exécutés pour accéder aux ressources du Cloud. Un utilisateur malveillant peut capturer et analyser les données des paquets envoyés sur ce réseau en reniflant les paquets[10]

Interopérabilité[modifier | modifier le code]

La formulation de normes pour l'informatique en cloud est la solution la plus évidente pour parvenir à l'interopérabilité et à la portabilité dans les clouds[21]. Une tactique courante pour permettre l'interopérabilité est l'utilisation de normes ouvertes. Il existe de nombreux projets de standardisation du cloud[22]. Les projets de normalisation des clouds consacrent beaucoup d'efforts à l'élaboration de normes pour les clouds couvrant les aspects liés au développement, au déploiement, à la sécurité, à la gestion, au stockage, etc. La portée des avantages tirés de la normalisation dépend du type de modèle de service et du modèle de déploiement choisis. Le modèle de service qui bénéficie le plus de la normalisation est le IaaS (Infrastructure as a Service), suivi du PaaS (Platform as a Service) et enfin du SaaS (Software as a Service). Cela pourrait s'expliquer par le fait que IaaS est le modèle de service de base et que les autres modèles (PaaS et SaaS) en tirent essentiellement parti. [23]

Le NIST, l'OMG, la DMTF(qui à produit la liste des 14 cas d'utilisation à la gestion du cloud) et d'autres organismes, dans le cadre de leurs efforts liés aux normes de portabilité des données, d'interopérabilité, de sécurité et de gestion de l'informatique dématérialisée, ont développé des cas d'utilisation pour l'informatique en cloud. Dans ce contexte, les cas d'utilisation font référence aux modes d'interaction typiques entre les consommateurs et les fournisseurs de services en cloud [22]. Par exemple Le NIST définit 21 cas d'utilisation classés en trois groupes : gestion du cloud, l'interopérabilité du cloud et la sécurité du cloud. En particulier, les cas d'utilisation de l'interopérabilité du cloud incluent la copie de données objets entre les fournisseurs de cloud, la charges de travail, l'éclatement du cloud, et la migration des applications et des machines virtuelles (VMs).

Si nous examinons l'ensemble des cas d'utilisation proposés par le NIST, l'OMG et la DMTF, les cas d'utilisation liés à l'interopérabilité (ou qui bénéficieraient de l'existence de normes) peuvent être mis en correspondance avec les quatre cas d'utilisation de base de l'interopérabilité du cloud suivants :

  • Authentification de l'utilisateur : Un utilisateur qui a établi une identité auprès d'un fournisseur de services en cloud peut utiliser la même identité auprès d'un autre fournisseur de services en cloud.
  • Migration de la charge de travail : Une charge de travail qui s'exécute dans un fournisseur de services en cloud peut être téléchargée vers un autre fournisseur de services en cloud.
  • Migration de données : Les données qui résident dans un fournisseur de cloud computing peuvent être déplacées vers un autre fournisseur de cloud computing.
  • Gestion de la charge de travail : Des outils personnalisés développés pour la gestion des charges de travail en cloud peuvent être utilisés gérer plusieurs ressources en cloud provenant de différents fournisseurs. [22].

Sécurité des échanges[modifier | modifier le code]

Avec l'inclusion de langages de script (généralement JavaScript) dans les pages Web, il est devenu important de définir des droits d'accès pour ces scripts. Un choix naturel est d'autoriser les opérations de lecture/écriture sur le contenu de la même origine, et d'interdire tout accès au contenu d'une origine différente.[8].

Diverses technologies distinctes sont utilisées et combinées pour construire des systèmes de Cloud Computing. En fonction du type de cloud (IaaS, PaaS ou SaaS), les technologies d'accès peuvent varier des clients lourds compatibles avec les services aux clients légers basés sur un navigateur Web. [24].

Protection Contre les attaques citées précédemment[modifier | modifier le code]

Machine Zombie : Une meilleure authentification et autorisation et IDS/IPS peuvent fournir une protection contre une telle attaque.

Attaque par injection de service : Pour se défendre contre ce type d'attaque, un module de vérification de l'intégrité du service doit être mis en œuvre. Une forte isolation entre les VMs peut empêcher l'attaquant d'injecter du code malveillant dans la VM du voisin [17],[19]. Une valeur de hachage peut être utilisée pour stocker sur le fichier image de l'instance de service d'origine et comparer cette valeur avec les valeurs de hachage de toutes les nouvelles images d'instance de service [17].

Pishing Une meilleure authentification et une meilleure isolation entre les machines virtuelles peuvent fournir une protection contre de telles attaques[25].

Détection des intrusions dans le Cloud :

déploiement d'IDS sur chaque couche du cloud

Roschke et.al a proposé en 2009 une architecture de déploiement de Systèmes de Détection d'Intrusion(IDS) dans le Cloud. Il a proposé le déploiement d'IDS sur chaque couche du cloud pour recueillir les alertes des capteurs déployés dans le cloud. Pour chaque couche, il devrait y avoir des capteurs basés sur le réseau et des capteurs basés sur l'hôte.[26],[27] En outre, le capteur IDS doit signaler les alertes à un système central de gestion IDS, qui est responsable de la collecte et du prétraitement des alertes de tous les capteurs.[27] Ces alertes sont stockées dans le stockage de la base de données d'événements. Il peut être configuré et contrôlé par l'utilisateur. Des informations telles que l'état de la VM (machine virtuelle), la charge de travail de la VM et les affectations IDS-VM peuvent être surveillées. Les machines virtuelles IDS impliquées peuvent être arrêtées, démarrées et récupérées par le système de gestion. Les défis rencontrés lors de la mise en œuvre de cet IDS sont : la sortie des différents capteurs n'est pas standardisée, la communication entre les capteurs et le composant de gestion est peu flexible, les architectures complexes avec plusieurs capteurs [26]. En outre, les fournisseurs de services en cloud devraient utiliser des capteurs IDS pour surveiller leur infrastructure cloud, c'est-à-dire le niveau matériel de l'infrastructure, afin de détecter les attaques sur le réseau.[27]

La gestion des identités et des accès[modifier | modifier le code]

Echange de token pour gérer efficacement les identités dans l'environnement Inter-cloud

L'une des conditions essentielles pour réussir à gérer efficacement les identités dans l'environnement Inter-cloud est la présence et la prise en charge d'une solide capacité de gestion d'identité fédérée basée sur des normes [28],[29], à l'aide des normes de fédération en vigueur telles que SAML, WS-Federation et Liberty ID-FF. Les systèmes complets de gestion d'identité fournissent généralement des services tels que : Le provisionnement et la gestion des utilisateurs, l'authentification et l'autorisation, l'ingénierie des rôles et l'intégration/la virtualisation des données d'identité. [28].Dans un modèle d'identité fédérée typique, pour qu'un fournisseur de cloud puisse établir une communication sécurisée avec un autre fournisseur de cloud, il demande un jeton de confiance au service du fournisseur de confiance. Le service du fournisseur de confiance envoie deux copies des clés secrètes, le jeton de preuve crypté du service de confiance ainsi que le jeton crypté demandé. [28],[30].

Le chiffrement et la gestion des clés[modifier | modifier le code]

La technologie de chiffrement est un élément essentiel du cadre de sécurité global d'Inter-cloud. La sécurité est conçue de manière à ce que les données soient cryptées « au repos » et « en transit ». Dans le monde de l'inter-cloud et du cloud computing en général, il y a un changement radical de point de vue,[31] en particulier la façon dont nous pensons à l'informatique en supprimant les spécificités de l'emplacement de ses ressources ; Le cloud computing peut être considéré comme une « dépérimétrisation » radicale. Cependant, séparer les ressources de l'emplacement crée des problèmes de sécurité qui résultent de cette absence de périmètre. Dans un tel monde, il est absolument nécessaire de sécuriser les ressources informatiques à l'aide d'un cryptage fort en tirant parti d'un mécanisme de gestion de clés évolutif et robuste sous-jacent. Cependant, les algorithmes de chiffrement sont aussi bons que le processus de gestion des clés sous-jacent La gestion des clés ne concerne pas seulement la technologie, elle inclut également des éléments de personnes et de processus. La défaillance ou la compromission de l'un de ces composants entraîne la défaillance ou la compromission de l'ensemble du système. Contrairement à l'environnement Internet statique traditionnel, dans un environnement Inter-cloud, il existe un grand besoin de séparer les ressources informatiques et les clés de chiffrement, une chaîne de séparation ainsi qu'une chaîne de contrôle avec plusieurs parties impliquées à chaque étape. [31],[32].

Comme les ressources informatiques dans un environnement Inter-cloud peuvent potentiellement se trouver n'importe où. Afin de pouvoir chiffrer/déchiffrer ces ressources, les clés correspondantes doivent être récupérées. Pour aider à rationaliser le processus de communication global entre l'environnement de gestion de clés et les clients cryptographiques, nous évaluons des normes d'interopérabilité telles que le protocole d'interopérabilité de gestion de clés OASIS ( KMIP ) récemment annoncé. [31],[32].

Références[modifier | modifier le code]

  1. ↑ Grozev 2014, p. 372
  2. ↑ a b c et d Ashok 2015, p. 30
  3. ↑ Grozev 2014, p. 371
  4. ↑ kumar 2016, p. 114
  5. ↑ Toosi 2014, p. 30
  6. ↑ a et b Bohli 2013, p. 212
  7. ↑ a b et c Bohli 2013, p. 213
  8. ↑ a et b Meiko 2009, p. 112
  9. ↑ Meiko 2009, p. 113
  10. ↑ a et b Adeel 2013, p. 4
  11. ↑ Yang 2012, p. 626
  12. ↑ a et b Asma 2016, p. 749
  13. ↑ Meiko 2009, p. 111
  14. ↑ Jensen 2013, p. 153
  15. ↑ Adeel 2013, p. 5
  16. ↑ Modi 2013, p. 569
  17. ↑ a b et c Zaki 2011, p. 2675
  18. ↑ a et b Modi 2013, p. 570
  19. ↑ a et b Adeel 2013, p. 6
  20. ↑ Modi 2013, p. 571
  21. ↑ kaur 2017, p. 4
  22. ↑ a b et c grace 2013, p. 1653
  23. ↑ kaur 2017, p. 5
  24. ↑ Meiko 2009, p. 110
  25. ↑ Adeel 2013, p. 7
  26. ↑ a et b Kumar 2013, p. 4
  27. ↑ a b et c Roschke 2009, p. 732
  28. ↑ a b et c Deepak 2010, p. 541
  29. ↑ Guenana 2015, p. 2
  30. ↑ Bernstein 2011, p. 4
  31. ↑ a b et c Deepak 2010, p. 542
  32. ↑ a et b Diamond 2011, p. 296

Bibliographie[modifier | modifier le code]

  • Document utilisé pour la rédaction de l’article (en) David Bernstein et Vij Deepak, « Intercloud Security Considerations », 2010 IEEE Second International Conference on Cloud Computing Technology and Science,‎ , p. 537-544 (DOI 10.1109/CloudCom.2010.82)
  • Document utilisé pour la rédaction de l’article (en) Jens-Matthias Bohli, Nils Gruschka, Jensen Meiko, Luigi Lo lacono et Ninja Marnau, « Security and Privacy-Enhancing Multicloud Architectures », IEEE Transactions on Dependable and Secure Computing, vol. 10,‎ , p. 212-224 (DOI 10.1109/TDSC.2013.6)
  • Document utilisé pour la rédaction de l’article (en) « On Technical Security Issues in Cloud Computing », 2009 IEEE International Conference on Cloud Computing,‎ , p. 109-116 (DOI 10.1109/CLOUD.2009.60)
  • Document utilisé pour la rédaction de l’article (en) Muttukrishnan Rajarajan, Chirag Modi, Dhiren Patel, Bhavesh Borisaniya et Avi Patel, « A survey on security issues and solutions at different layers of Cloud computing », The Journal of Supercomputing, vol. 63,‎ , p. 561-592 (DOI 10.1007/s11227-012-0831-5)
  • Document utilisé pour la rédaction de l’article (en) Asma A. Shaikh, « Attacks on cloud computing and its countermeasures », 2016 International Conference on Signal Processing, Communication, Power and Embedded System,‎ , p. 748-752 (DOI 10.1109/SCOPES.2016.7955539)
  • Document utilisé pour la rédaction de l’article (en) Christian Mainka, « Making XML Signatures Immune to XML Signature Wrapping Attacks », Cloud Computing and Service Science,‎ , p. 151-167 (DOI 10.1007/978-3-319-04519-1_)
  • Document utilisé pour la rédaction de l’article (en) Yang Lanjuan, Tao Zang, Jinyu Song, Jin Shuang Wang et Ping Chen, « Defense of DDoS attack for cloud computing », 2012 IEEE International Conference on Computer Science and Automation Engineering (CSAE), vol. 2,‎ , p. 626-629 (DOI 10.1109/CSAE.2012.6272848)
  • Document utilisé pour la rédaction de l’article (en) Muhammad Adeel Javaid, « Top Threats to Cloud Computing Security », SSRN Electronic Journal,‎ , p. 10 (DOI 10.2139/ssrn.2325234)
  • Document utilisé pour la rédaction de l’article (en) Jamil Danish et Zaki Hassan, « Security issues in cloud computing and countermeasures », International Journal of Engineering Science and Technology (IJEST), vol. 3,‎ , p. 2672-2676 (DOI doi.org/10.21817/ijest)
  • Document utilisé pour la rédaction de l’article (en) Naresh Kumar et Shalini Sharma, « Study of intrusion detection system for DDoS attacks in cloud computing », 2013 Tenth International Conference on Wireless and Optical Communications Networks (WOCN),‎ , p. 1-5 (DOI 10.1109/WOCN.2013.6616255)
  • Document utilisé pour la rédaction de l’article (en) Kumar V Ashok, « A Survey on Intercloud and its Security », International Journal of Research Studies in Computer Science and Engineering (IJRSCSE), vol. 2,‎ , p. 27-40 (ISSN 2349-4859)
  • Document utilisé pour la rédaction de l’article (en) Nikolay Grozev et Rajkumar Buyya, « Inter-Cloud architectures and application brokering: taxonomy and survey », Software: Practice and Experience, vol. 44,‎ , p. 369-390 (DOI https://doi.org/10.1002/spe.2168)
  • Document utilisé pour la rédaction de l’article (en) Dinkar Sitaram, Sudheendra Harwalkar et K.V. Suchith Kumar, « Standards Based Integration of Intercloud for Federation with OpenStack », 2016 IEEE International Conference on Cloud Computing in Emerging Markets (CCEM),‎ , p. 113-118 (DOI 10.1109/CCEM.2016.028)
  • Document utilisé pour la rédaction de l’article (en) Adel Nadjaran Toosi, Rodrigo N. Calheiros et Rajkumar Buyya, « Interconnected Cloud Computing Environments: Challenges, Taxonomy, and Survey », Association for Computing Machinery, vol. 47,‎ , p. 47 (DOI 10.1145/2593512)
  • Document utilisé pour la rédaction de l’article (en) Kiranbir Kaur, DR. Sandeep Sharma et DR. Karanjeet Singh Kahlon, « Interoperability and Portability Approaches in Inter-Connected Clouds: A Review », Association for Computing Machinery, vol. 50,‎ , p. 1-40 (ISSN 0360-0300, DOI 10.1145/3092698)
  • Document utilisé pour la rédaction de l’article (en) Lewis Grace A., « Role of Standards in Cloud-Computing Interoperability », 2013 46th Hawaii International Conference on System Sciences,‎ , p. 1652-1661 (DOI 10.1109/HICSS.2013.470)
  • Document utilisé pour la rédaction de l’article (en) Sebastian Roschke, Feng Cheng et Christoph Meinel, « Intrusion Detection in the Cloud », 2009 Eighth IEEE International Conference on Dependable, Autonomic and Secure Computing,‎ , p. 729-734 (DOI 10.1109/DASC.2009.94)
  • Document utilisé pour la rédaction de l’article (en) Fouad Amine Guenana et Ahmed Serhrouchni, « Secure access amp; authentication for collaborative intercloud exchange service », 2015 International Conference on Cyber Security of Smart Cities, Industrial Control System and Communications (SSIC),‎ , p. 1-5 (DOI 10.1109/SSIC.2015.7245331)
  • Document utilisé pour la rédaction de l’article (en) David Bernstein et Vij Deepak, « Intercloud exchanges and roots topology and trust blueprint », Proceedings on the International Conference on Internet Computing (ICOMP),‎ , p. 1-7 (lire en ligne)
  • Document utilisé pour la rédaction de l’article (en) David Bernstein, Vij Deepak et Stephen Diamond, « An Intercloud Cloud Computing Economy - Technology, Governance, and Market Blueprints », 2011 Annual SRII Global Conference,‎ , p. 293-299 (DOI 10.1109/SRII.2011.40)

Catégorie:Service de cloud computing‎ Catégorie:Sécurité informatique

Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Utilisateur:RKCreeew/VeilleStrategique&oldid=197283723 ».