Déploiement de solutions cloud hautement disponibles …download.microsoft.com/download/9/D/3/9D33E54F-FB2F-4ACD-BD5… · Lors de la planification d'un ... La scrutation automatisée

microsoft.com/reliability

Déploiement de solutions cloud hautement disponibles et sécurisées

Décembre 2012

ii Déploiement de solutions cloud hautement disponibles et sécurisées

Déploiement de solutions cloud hautement disponibles et sécurisées

Ce document est fourni à titre purement informatif. MICROSOFT NE FORMULE AUCUNE GARANTIE, EXPLICITE, IMPLICITE OU LÉGALE CONCERNANT LES INFORMATIONS DE CE DOCUMENT.

Ce document est fourni « comme tel ». Les informations et les opinions exprimées dans ce document, y compris les URL et les autres références de site Web, peuvent être modifiées sans préavis. Vous l'utilisez en toute connaissance de cause.

Copyright © 2012 Microsoft Corporation. Tous droits réservés.

Les noms de produits et de sociétés réels mentionnés dans la présente documentation peuvent être des marques de leurs propriétaires respectifs.

Auteurs et contributeurs

DAVID BILLS – Microsoft Trustworthy Computing

CHRIS HALLUM – Microsoft Windows

YALE LI – Microsoft IT

MARC LAURICELLA – Microsoft Trustworthy Computing

ALAN MEEUS – Windows Phone

DARYL PECELJ – Microsoft IT

TIM RAINS – Microsoft Trustworthy Computing

FRANK SIMORJAY – Microsoft Trustworthy Computing

SIAN SUTHERS – Microsoft Trustworthy Computing

TONY URECHE – Microsoft Windows

Déploiement de solutions cloud hautement disponibles et sécurisées iii

Table des matières

Synthèse .................................................................................................................................. 1

Introduction ........................................................................................................................... 3

Estimation de la fiabilité et des attentes des utilisateurs ...................................... 4

Architecture orientée services .................................................................................... 5

Séparation de fonction ................................................................................................. 5

Basculement automatique ........................................................................................... 5

Tolérance aux pannes .................................................................................................... 6

Plan de reprise après sinistre ...................................................................................... 6

Tests et mesures .............................................................................................................. 6

Fournisseur de solutions cloud ....................................................................................... 8

Attentes et responsabilités des fournisseurs de solutions cloud ................... 8

Disponibilité du cloud ................................................................................................... 9

Conception prévue pour la disponibilité .............................................................. 10

Client professionnel du cloud ....................................................................................... 13

Responsabilité de l'entreprise ................................................................................... 13

Disponibilité d'informations sensibles stockées dans le cloud .................... 15

Utilisateurs et appareils utilisés pour accéder au cloud ...................................... 17

Attentes et retours des utilisateurs ......................................................................... 17

Conception pour les tests .......................................................................................... 18

Disponibilité de l'appareil utilisateur ..................................................................... 18

Lectures complémentaires ............................................................................................. 23


Synthèse De nos jours, de nombreuses organisations cherchent à améliorer la flexibilité et les performances des applications cloud. Ces deux points sont essentiels, mais les applications cloud doivent être également accessibles par les utilisateurs quel que soit l'endroit depuis lequel ils se connectent. Ce document décrit les principales méthodologies que les décideurs techniques pourront utiliser afin de s'assurer que les services cloud, qu'ils soient publics ou privés, restent disponibles en permanence pour les utilisateurs.

D'un point de vue général, chaque session cloud représente un client qui utilise un appareil informatique pour se connecter au service cloud d'une organisation, hébergé par une entité interne ou externe. Lors de la planification d'un service cloud hautement disponible, vous devez absolument prendre en compte les attentes et les responsabilités de chacune de ces parties. Votre plan doit tenir compte des limites réelles de la technologie et intégrer le fait que des défaillances peuvent survenir. Vous devrez prévoir une conception permettant d'isoler et de

2 Déploiement de solutions cloud hautement disponibles et sécurisées

réparer ces défaillances, tout en affectant le moins possible la disponibilité du service pour les utilisateurs.

Ce document fournit des exemples de déploiement de solutions de cloud assez robustes pour assurer des connexions clients hautement disponibles et sécurisées. Il présente également des exemples réels en matière d'extensibilité. L'objectif de ce document est de décrire les techniques qui permettent de réduire l'impact des défaillances et de fournir des services hautement disponibles tout en assurant une expérience utilisateur optimale.

Déploiement de solutions cloud hautement disponibles et sécurisées 3

Introduction

Les clients, très exigeants en matière de fiabilité de l'infrastructure informatique, le sont tout autant en ce qui concerne les services cloud. Le temps d'activité (ou « uptime »), par exemple, est un indicateur de fiabilité très répandu. À l'heure actuelle, les utilisateurs attendent des temps d'activité de service allant de 99,9 % (ou « trois neuf ») à 99,999 % (ou « cinq neuf »), c'est-à-dire de neuf heures maximum de temps d'indisponibilité par an (à 99,9 %) à cinq minutes maximum de temps d'indisponibilité par an (à 99,999 %). Les fournisseurs de services font souvent la distinction entre les coupures prévues et imprévues, mais, les responsables informatiques le savent bien, même un changement prévu peut engendrer des problèmes imprévus, et un seul problème imprévu peut remettre en question un engagement de service de 99,9 %.

La fiabilité est par-dessus tout une question de satisfaction client, ce qui en fait une affaire bien plus complexe qu'un simple relevé du temps d'activité. Imaginons par exemple un service sans aucune coupure, mais qui se révèle très lent ou difficile à utiliser. Bien que le maintien de la satisfaction client à un niveau élevé représente un défi à multiples facettes, la fiabilité est le fondement même de tous les autres aspects de la satisfaction client. Les services cloud doivent être conçus en gardant toujours la fiabilité à l'esprit. Ce document décrit les principes de fiabilité des services cloud suivants :

Utilisation d'une architecture orientée services

Mise en œuvre de la séparation de fonction

Conception prévue pour corriger les défaillances

Automatisation des tests et mesures

Compréhension des accords de niveau de service


Estimation de la fiabilité et des attentes des utilisateurs

Outre le temps d'activité (ou « uptime »), mentionné plus haut, d'autres indicateurs de fiabilité doivent être pris en compte. L'un des indicateurs de fiabilité du matériel informatique les plus courants est le temps moyen de fonctionnement avant défaillance (ou MTTF, « mean time to failure »). En cas de défaillance d'un composant, le service qu'il fournit devient indisponible jusqu'à ce que le composant soit réparé. Mais le MTTF n'est pas le seul indicateur pertinent. Pour déterminer le temps écoulé entre la défaillance et la réparation, l'on a créé le temps moyen de réparation (ou MTTR, « mean time to repair »). L'équation MTTF/MTTR permet de calculer un indicateur important de la fiabilité du service. Cette équation montre que la réduction de moitié du temps de réparation entraîne le doublement de la disponibilité mesurée. Considérons par exemple un service en ligne présentant un MTTF d'un an et un MTTR d'une heure. En termes de disponibilité mesurée, la réduction du MTTR à une demi-heure revient à doubler le MTTF, qui passe alors à deux ans.

En se concentrant sur le MTTR, l'on peut atténuer l'impact potentiel des défaillances et améliorer la fiabilité en créant un ensemble de serveurs de secours assez redondants pour accélérer la reprise après de tels incidents. Précisez toujours ces types d'atténuations dans un accord de niveau de service (SLA) conclu avec le fournisseur de solutions cloud. Vous reconnaissez ainsi implicitement qu'un certain nombre de défaillances peut survenir et que la meilleure façon de réduire au maximum l'impact des défaillances est d'augmenter le MTTF et de réduire le MTTR.

Les sections suivantes décrivent certaines des principales exigences d'architecture pour la conception de services cloud hautement disponibles.


Architecture orientée services L'adoption d'une technologie cloud efficace nécessite des modèles de conception appropriés. Dans une architecture orientée services, chaque composant doit disposer d'une interface conçue de sorte que sa mise en œuvre soit indépendante de tout autre composant et qu'elle puisse être utilisée par de nouveaux composants au fur et à mesure de leur déploiement. Une telle conception permet de réduire les temps d'arrêt système car les composants qui font appel à un composant défaillant sont capables de gérer un tel événement.

Séparation de fonction La séparation de fonction, également appelée séparation des problèmes, est un modèle de conception qui établit que chaque composant met en œuvre une seule ou un petit nombre de fonctions proches, sans chevauchement ni couplage faible à d'autres composants. L'architecture à trois niveaux présentée dans la Figure 1 de ce document est un exemple typique de séparation de fonction. Cette approche permet la propagation des fonctionnalités à différents endroits et sur différents réseaux, de sorte que chaque fonction a de bonnes chances de survivre à la défaillance de serveurs spécifiques. La figure illustre des serveurs Web frontaux redondants, des files d'attente de messages et des unités de stockage, chacun de ces éléments pouvant se trouver à des endroits différents.

Basculement automatique Si les interfaces de composants sont enregistrées par un URI (Uniform Resource Identifier), le basculement d'un fournisseur de services à un autre peut se révéler aussi simple qu'une recherche DNS. L'utilisation d'URI plutôt que l'indication de l'emplacement des services augmente les chances de localisation d'un service opérationnel.


Tolérance aux pannes Également appelée mode dégradé, la tolérance aux pannes dépend du rassemblement des blocs d'un service sans créer de dépendances inutiles. Si l'interface Web utilisateur est aussi simple que possible et découplée de la logique applicative ou d'arrière-plan, le canal de communication peut survivre aux défaillances d'autres composants et maintenir le lien entre l'organisation et l'utilisateur. En outre, l'interface Web peut être utilisée pour informer l'utilisateur de l'état actuel de chaque élément du service cloud de l'organisation. Cela permet non seulement à l'utilisateur de savoir quand les services seront entièrement rétablis, mais aussi d'augmenter la satisfaction des utilisateurs.

Plan de reprise après sinistre Vous devez vous préparer à une défaillance occasionnelle des services. Une défaillance matérielle, des défauts logiciels et des catastrophes naturelles ou provoquées par l'homme peuvent entraîner une défaillance de service. Prévoyez, avant le déploiement, un programme destiné aux problèmes quotidiens afin d'aider les dépanneurs à déterminer les éléments à vérifier et les réponses à apporter aux différents problèmes. Cependant, des interruptions environnementales très importantes, parfois appelées cygnes noirs, se produiront aussi de temps en temps. Vous devez tenir compte de tels événements dans le processus de planification. Selon la théorie du cygne noir, la somme de ces événements peu probables joue un rôle bien plus important que les coupures régulières.

Tests et mesures Il existe deux types appropriés de test et de mesure d'un service en fonctionnement. La scrutation automatisée du service par un serveur de test peut conduire à la détection et au signalement précoces d'une défaillance, et ainsi à la réduction du MTTR.

Une enquête devrait être effectuée auprès des utilisateurs juste avant ou juste après un déploiement afin de comprendre comment les utilisateurs réagissent et


d'identifier les attentes non satisfaites. La façon la plus simple d'obtenir des commentaires des utilisateurs est de leur en demander, non pas à chacun de leurs passages, mais de manière occasionnelle. Cela vous fournira des données utiles, même avec un très faible pourcentage de réponses, et vous obtiendrez des indicateurs de performance clés (KPI) des utilisateurs qui vous permettront de générer des rapports mensuels.


Fournisseur de solutions cloud

Les nouvelles technologies de solutions cloud ont permis de réaliser deux concepts datant des années 1970.

La virtualisation du matériel informatique est désormais une réalité, avec des images et des disques durs virtuels pouvant être gérés à distance.

La mise à l'échelle rapide et l'agilité sont également devenues réalité, avec des outils de gestion permettant de commander la puissance du matériel physique et virtuel.

Il est essentiel que les professionnels de l'informatique comprennent ces concepts, ainsi que leur potentiel. Comme indiqué dans la section « Synthèse », les concepts mentionnés dans ce document s'appliquent aux clouds publics et privés, chacun ayant sa place dans la boîte à outils des services informatiques tournés vers l'avenir. L'objectif premier au début d'un projet devrait être la conception relative au cloud et aux services de gestion qui assureront le minimum d'interruptions de service aux utilisateurs.

Attentes et responsabilités des fournisseurs de solutions cloud Il existe une responsabilité partagée entre toute organisation et son fournisseur de solutions cloud. Pour les applications personnalisées, le fournisseur de service cloud conçoit un service fiable, basé sur l'utilisation de certaines fonctions, telles que le basculement et la surveillance, par le développeur. Le développeur doit comprendre et utiliser ces fonctions pour que la fiabilité représente un objectif réalisable.

Une organisation qui met en œuvre une solution associée à une infrastructure cloud doit garantir une disponibilité maximale du service. Les utilisateurs s'attendent à ce que ces types de services soient aussi fiables qu'un téléphone. Et bien que des coupures puissent survenir, il s'agit d'événements localisés et rares. La capacité de l'organisation à fournir une telle garantie requiert une


communication transparente avec le fournisseur concernant le fonctionnement du service et ce que le consommateur du service doit fournir. Sans une telle transparence, les différentes parties risquent de se renvoyer la balle à propos de la responsabilité de chacun au lieu d'assurer une reprise automatisée en cas de défaillance du service entraînant des indisponibilités pour les utilisateurs.

La situation est identique pour les clouds privés. Une organisation informatique peut répartir la responsabilité de l'infrastructure vers des experts en interne, qui créent ensuite un cloud privé. Le service cloud doit fournir une plate-forme fiable sur laquelle le reste de l'équipe informatique peut créer des solutions innovantes répondant aux besoins métier de l'organisation. Mais tout comme pour un service cloud externalisé, une complète transparence et une documentation précise des attentes permettront d'éviter les défaillances résultant de domaines de responsabilité flous ou mal définis.

Disponibilité du cloud En général, les services cloud publics sont hautement disponibles grâce à l'utilisation d'un ensemble de batteries de serveurs et de périphériques réseau répartis sur plusieurs secteurs géographiques et gérés de façon professionnelle. Même les plus grandes entreprises disposant de clouds privés destinés à du contenu sensible peuvent tirer profit de services cloud publics pour l'hébergement de leurs solutions d'applications. Les clouds publics de taille importante ont une capacité (quasi) infinie car ils ont plus de serveurs à disposition pour répondre à la demande, même lorsque celle-ci est plus importante que prévu. Le déchargement du surplus de capacité des serveurs présente plusieurs avantages, le plus important étant que, dans la plupart des modèles de cloud public, le surplus de capacité n'est pas facturé tant qu'il n'est pas utilisé.

De nombreux fournisseurs de solutions cloud offrent des capacités intégrées pour une disponibilité et une réactivité améliorées, telles que :

Le tourniquet DNS (round-robin)

Des réseaux de distribution de contenu

Le basculement automatisé

Des zones de disponibilité géographiques


Conception prévue pour la disponibilité Comme indiqué précédemment, la façon la plus efficace d'améliorer la disponibilité est de réduire le MTTR. Si le cloud s'appuie sur la diversité géographique et réseau, veillez à ce que la répartition de charge détourne automatiquement les utilisateurs des composants défaillants et les achemine vers des composants opérationnels. Même une fonctionnalité assez simple telle que la répartition de charge réseau peut être affectée par une interaction imprévue entre l'organisation et le fournisseur de service cloud ou le DNS. Ce type d'interaction peut introduire dans l'offre de service des instabilités qui n'ont pas été anticipées.

Par exemple, des solutions d'atténuation des attaques par DDoS (Distributed Denial of Service, déni de service distribué) s'en prenant à la disponibilité doivent être mises en place par tout service cloud. Toutefois, à moins que des mesures d'atténuation ne soient déjà implémentées de manière rigoureuse, les entreprises avec peu d'expérience en matière de sécurité peuvent, sans le vouloir, provoquer l'indisponibilité d'une application, pouvant s'avérer tout aussi dommageable qu'une attaque DDoS. L'atténuation DDoS est un exemple de fonction dont la mise à disposition est largement plus efficace à l'échelle du fournisseur de service cloud ou du FAI.

La plupart des principaux fournisseurs de service cloud sont certifiés en matière de fiabilité et de sécurité. Ils en font état dans des documents tels que ceux du registre STAR (Security, Trust, and Assurance Registry) de la Cloud Security Alliance (CSA).1 Bien que le registre STAR soit relativement récent, il est important que les responsables informatiques tiennent compte du fait que la plupart de leurs systèmes internes n'ont pas bénéficié de ce type de certification établie par des organismes tiers. Obtenir ce type d'accréditation à coûts partagés est un autre avantage potentiel des services cloud publics.

Lors de l'évaluation des atouts et contraintes liés à la création d'une solution cloud à haut niveau de disponibilité, il est important de vérifier que la conception de l'architecture inclut un processus d'analyse des menaces, portant sur les problèmes connus tels que ceux définis précédemment, ainsi que les cas d'interruption de l'activité propres à la solution que vous souhaitez déployer. Généralement, une 1 Registre STAR (Security, Trust and Assurance Registry) : https://cloudsecurityalliance.org/star/


analyse des menaces ne tient compte que des attaques de sécurité. Mais toute solution cloud bien conçue tiendra également compte des autres types de perte de disponibilité, ainsi que des procédures d'atténuation.

Le schéma suivant illustre une architecture générique à trois niveaux, avec capacité de redondance. Chaque requête dispose de plusieurs voies pour atteindre un composant pouvant y répondre. À gauche, un appareil utilisateur (par exemple un ordinateur portable), à partir duquel est acheminée la requête (avec tourniquet DNS et fonctionnalités d'équilibrage de la charge réseau, si disponibles). En tandem, un service de test de disponibilité automatique contrôle toute l'activité du système pour informer au plus vite en cas de défaillance et activer aussi rapidement que possible les procédures de réparation requises.

Le service cloud du schéma présente une séparation des fonctions. Ainsi, le chemin réseau jusqu'à l'utilisateur ne comporte aucun composant commun susceptible d'être à l'origine d'une défaillance des deux chemins. Chaque site de service cloud peut intégrer d'autres redondances de composants. Dans ce cas, la file d'attente peut être fournie par le fournisseur de service cloud. S'il est nécessaire de partager entre les deux sites une base de données commune, c'est l'architecture d'application de l'entreprise qui doit router le trafic jusqu'aux données en assurant un basculement vers un autre site exécutant une copie en miroir de la base de données. Toutefois, de nombreuses offres de cloud public incorporent des fonctionnalités de redondance de données qui doivent être étudiées.

Dans cet exemple de solution, l'équilibrage des charges est réparti entre Internet au niveau frontal, le service cloud au niveau intermédiaire et l'application de l'entreprise au niveau arrière-plan. Des tests de désactivation de chacun de ces composants doivent être effectués avec des charges réelles pour vérifier que les options de basculement répondent comme prévu.


Figure 1. Conception permettant d'assurer la disponibilité

Si le composant frontal du site Web est suffisamment simple et direct, les utilisateurs doivent toujours être en mesure de voir le logo et les informations d'état de l'entreprise, preuves de la fiabilité de celle-ci. La simplicité, à la fois au niveau des composants et des connexions, est l'élément clé de la fiabilité et de la disponibilité du système dans sa globalité. Les systèmes complexes et étroitement interconnectés sont difficiles à gérer et à dépanner en cas de défaillance.


Client professionnel du cloud

Toute entreprise faisant l'acquisition de services cloud auprès de fournisseurs de cloud publics ou privés doit parfaitement comprendre la responsabilité du fournisseur de cloud, ainsi que les limites de cette responsabilité. De la même manière, tout fournisseur de cloud doit comprendre les exigences en matière de sécurité et de disponibilité de la solution qu'il offre à ses usagers. Une solution cloud requiert une implémentation extrêmement fiable et doit offrir au fournisseur de service cloud la possibilité de créer un service intégrant ses propres fonctionnalités en cohérence avec les exigences de l'entreprise. Il est intéressant de préciser que cette partie intégration est celle qui crée le plus d'innovation et de valeur ajoutée dans l'entreprise.

Responsabilité de l'entreprise À partir du moment où les responsabilités du fournisseur de service cloud sont clairement définies, documentées et acceptées par le biais d'un contrat de niveau de service, la responsabilité de toute menace non atténuée incombe alors au client/à l'entreprise. Pour identifier les potentielles menaces non atténuées, il est recommandé d'organiser des sessions de réflexion de groupe pour définir l'ensemble des menaces possibles et classer celles connues comme incombant au fournisseur de service cloud. Il est alors de la responsabilité de l'entreprise d'atténuer les menaces restantes. La liste de risques et responsabilités suivante peut servir de guide concernant les types de menaces à prendre en compte.

Appliquer le contrôle d'accès au niveau local et au niveau du cloud. Si des incidents de perte de données peuvent survenir pour diverses raisons, ils se produisent bien souvent lorsqu'un attaquant usurpe l'identité d'un utilisateur valide ou élève ses propres privilèges pour acquérir des droits d'accès qui n'ont pas été autorisés. La plupart des entreprises tiennent à jour un répertoire des employés et partenaires pouvant être fédérés ou disposent de comptes


miroir dans l'environnement cloud ; toutefois, il est possible que d'autres utilisateurs doivent être authentifiés selon des méthodes différentes. Pour s'assurer de disposer d'une flexibilité suffisante ultérieurement, il est recommandé de souscrire à des services cloud implémentant la fédération et prenant en charge les identités d'annuaires de l'entreprise situés en interne ainsi que celles de fournisseurs d'identité externes. La tendance pour les fournisseurs est d'intégrer des services de contrôle d'accès dans leurs offres de services. Il est recommandé d'éviter de dupliquer votre base de données de comptes pour ne pas accroître la surface d'attaque des informations contenues, par exemple les données de mots de passe.

Protection des données en transit. Il peut y avoir perte de données si les données stockées ou en transit ne sont pas protégées. Les données en transit peuvent être protégées par l'utilisation du chiffrement TLS (Transport Layer Security) entre points de terminaison. La protection des données stockées est un défi complexe. Le chiffrement peut être assuré dans le cloud, mais si les données doivent être déchiffrées par des applications s'exécutant également dans le cloud, la clé de chiffrement doit disposer de protections spéciales. Il est important de noter qu'attribuer au cloud l'accès aux clés de chiffrement et aux données chiffrées revient à stocker des données non chiffrées.

Protection des rôles approuvés. Généralement, les autorisations permettant d'effectuer des fonctions administratives ou d'accéder à des données sensibles dépendent du rôle des utilisateurs au sein de leur entreprise. Du fait que les rôles varient alors que les identités persistent, il est nécessaire de maintenir à jour une correspondance entre l'identifiant de chaque utilisateur et les rôles qui lui sont attribués. Si le fournisseur de service cloud se charge du contrôle d'accès, cette liste doit être à la disposition du cloud et doit être gérée en conséquence. Une bonne pratique consiste à utiliser des technologies d'autorisation par revendications telles que SAML (Security Assertion Markup Language).

Protection des données sur des appareils mobiles. La protection des informations d'identification utilisateur et autres données sensibles sur des appareils mobiles n'est possible qu'à la condition de pouvoir y appliquer une politique de sécurité. Il est recommandé de configurer les politiques des boîtes aux lettres Microsoft Exchange ActiveSync. Bien que tous les appareils


n'implémentent pas l'ensemble des politiques ActiveSync, le marché répond à ce besoin et les entreprises doivent chercher à déployer et appliquer des solutions de sécurité au niveau des points de terminaison pour tous les appareils mobiles.

Développement du code conformément au processus SDL. Le code d'application peut provenir de la combinaison entre du code en provenance du fournisseur de service cloud (par exemple sous forme d'échantillon de code), de l'entreprise cliente du cloud et de tiers. Un processus de modélisation des menaces, tel que celui utilisé dans le cadre de SDL (Security Development Lifecycle), le processus de développement logiciel avec assurance de sécurité créé par Microsoft, doit tenir compte de ce facteur. S'il est une zone en particulier qui doit être analysée, c'est le potentiel de conflit si plusieurs composants contrôlent une fonctionnalité associée, telle que le processus d'autorisation.

Optimisation du système pour limiter le MTTR. Le processus de modélisation des menaces doit également tenir compte des différents types de défaillances possibles et les identifier, afin de garantir un MTTR aussi réduit que possible. Pour chaque défaillance potentielle, il est nécessaire de préciser les outils et technologies disponibles pour une récupération rapide de la fonctionnalité.

Disponibilité d'informations sensibles stockées dans le cloud Le cloud propose plusieurs options intéressantes de protection des données au sein d'une architecture à haut niveau de disponibilité. Considérons l'exemple de solution cloud suivant, dans lequel la fonctionnalité de sécurité et de disponibilité est répartie entre l'entreprise et le cloud. Les informations sensibles de l'entreprise sont stockées dans le cloud mais les clés de déchiffrement sont conservées par l'entreprise, de sorte qu'aucune attaque lancée sur le cloud ne peut mettre en danger les informations sensibles. Une solution consiste à chiffrer toutes les données stockées dans le cloud pour éviter toute fuite de données. Toutefois, il est également possible de faire la disctinction entre les types de données de manière à protéger les données les plus sensibles par chiffrement et les données moins sensibles uniquement par le contrôle d'accès. Les principes de l'architecture de


séparation des fonctions et de répartition géographique cités précédemment sont utilisés ici pour accroître la tolérance.

La figure suivante illustre le mode de fonctionnement du scénario de protection des données. Les données sont saisies et récupérées au niveau d'une station de travail sur le réseau d'une entreprise. Le réseau utilise un pare-feu pour la protection contre les intrusions. La station de travail se connecte à un service sur le réseau qui utilise une clé pour chiffrer et déchiffrer les données. La clé est obtenue à partir de l'annuaire central de l'entreprise, de sorte que tous les réseaux locaux distincts protégés peuvent accéder aux données stockées dans le cloud.

L'utilisateur est authentifié par l'annuaire de l'entreprise. La fédération et la technologie SAML permettent un contrôle centralisé de l'authentification et de l'autorisation, en s'appuyant sur l'annuaire de comptes existants (de type Active Directory) dans un environnement distribué.

Figure 2. Chiffrement des données dans le cloud

Cet exemple de données chiffrées dans le cloud peut être utilisé comme modèle pour divers types de mises en œuvre. La protection de la clé de chiffrement des données supprime toute menace de fuite de données dans le cloud et laisse à l'entreprise le contrôle complet des données sous forme non chiffrée. L'architecture distribuée garantit la disponibilité du service.


Utilisateurs et appareils utilisés pour accéder au cloud

Les utilisateurs évaluent le degré de disponibilité d'un service cloud uniquement en termes de possibilité ou non d'effectuer une tâche précise. Cela signifie que le service cloud, mais aussi l'appareil utilisé pour y accéder, doivent être fonctionnels.

Attentes et retours des utilisateurs Les utilisateurs jugent de la disponibilité d'un service selon qu'ils remplissent leurs objectifs ou non. Le schéma suivant présente les étapes typiques du processus par lequel l'utilisateur obtient l'accès à une ressource dans le cloud. D'abord, l'appareil de l'utilisateur doit se connecter au réseau local et être authentifié. Ensuite, le niveau de sécurité de l'appareil, ou état général, est vérifié et un processus d'autorisation basé sur les rôles permet d'établir l'accès approprié pour l'utilisateur. Enfin, la ressource dans le cloud doit être disponible. Toute défaillance de l'un de ces éléments empêche l'utilisateur d'accomplir la tâche voulue. Parfois, le blocage est lié à des raisons de sécurité, mais pour l'utilisateur, il s'agit toujours d'une entrave.

Figure 3. Éléments de blocage de la disponibilité

En cas d'échec de l'un des éléments du schéma, il est important d'indiquer à l'utilisateur la nature du problème ainsi que les méthodes de restauration de la disponibilité de la solution. Lorsque l'intervention de l'utilisateur est requise, les instructions doivent être claires et concises.


Conception pour les tests Un programme de test automatique permet de détecter les défaillances de la solution. Il est recommandé de concevoir la solution pour qu'elle puisse être testée en ligne. Tous les services destinés aux utilisateurs et les pages Web doivent activer des programmes de requêtes automatiques, avec signalement en temps quasi réel et transmission automatique en cas de défaillance. Les tests en ligne peuvent proposer des indicateurs de performance précieux concernant la disponibilité des services d'une solution.

Une méthode permettant de communiquer la perception de disponibilité des utilisateurs doit également être mise en œuvre. Exemple :

Si une application fournit aux utilisateurs un accès au cloud, utilisez-la pour générer des statistiques, comme le temps entre l'ouverture de session et l'acquisition des données stockées dans le cloud.

À la fin de leur session, demandez régulièrement aux utilisateurs s'ils acceptent de répondre à un court questionnaire.

Envoyez sur le terrain des chercheurs en expérience utilisateur pour obtenir des commentaires des utilisateurs.

Disponibilité de l'appareil utilisateur Les appareils utilisés pour accéder à des solutions cloud doivent être de confiance, afin d'éviter toute fuite d'informations sensibles. Les appareils mobiles étant de plus en plus utilisés pour accéder à ce type d'informations, il est nécessaire de trouver un moyen d'en évaluer la sécurité ou l'intégrité. Une bonne conception cloud est capable d'évaluer l'intégrité de l'appareil et de vérifier l'identité de l'utilisateur. Cette section décrit comment configurer l'évaluation de l'intégrité de l'appareil de manière à rendre la solution cloud disponible aux utilisateurs où qu'ils se trouvent.

Cet exemple de solution répond au besoin d'établir un accès sécurisé au réseau d'une entreprise depuis un appareil appartenant à l'utilisateur. Ce type de scénario est souvent appelé « Bring your own device to work » (« Fournissez votre propre


appareil »), ou BYOD. Pendant des années, les services informatiques ont pu protéger les actifs des entreprises en isolant toutes les ressources, y compris les ordinateurs clients qui accédaient à ces ressources, à l'intérieur d'un périmètre protégé. Dans les scénarios BYOD, les utilisateurs disposent d'appareils grand public qui peuvent accéder à toutes leurs données personnelles où qu'ils se trouvent, et ils souhaitent utiliser les mêmes appareils pour accéder aux ressources de l'entreprise. Ce phénomène est appelé la consumérisation de l'informatique.

Dans un tel scénario, le service cloud doit établir l'identité de l'utilisateur, apprendre ses préférences sur la manière dont ses informations personnelles peuvent être utilisées et obtenir l'autorisation de l'utilisateur si le service (ou l'entreprise) souhaite stocker ses informations personnelles pour une utilisation ultérieure ou les partager avec autrui. En outre, le service cloud pourrait renfermer du contenu pouvant uniquement être transmis aux appareils utilisateur qui sont déterminés comme étant sécurisés. Bon nombre d'utilisateurs souhaitent savoir que leur vie privée, leur identité et leurs actifs sont protégés contre les logiciels malveillants, bien que la plupart d'entre eux ne veuillent pas être incommodés par des mécanismes de sécurité.

La figure suivante montre une solution construite pour évaluer le niveau de sécurité de l'appareil mobile depuis le cloud. L'appareil mobile authentifie l'utilisateur via une connexion à un fournisseur d'identité situé dans le cloud. Si le service Web renferme des informations hautement confidentielles, ou qu'il essaie d'obtenir une indication tangible des intentions de l'utilisateur, il peut choisir de vérifier la sécurité de l'appareil mobile avant de poursuivre. L'appareil de l'utilisateur reçoit ensuite une attestation d'intégrité qui peut être envoyée en même temps que l'ID de l'utilisateur.


Figure 4. Clients mobiles sécurisés

Les appareils Windows 8 peuvent être protégés contre les rootkits et les bootkits de bas niveau à l'aide de technologies matérielles telles que le démarrage sécurisé (Secure Boot et Trusted Boot).

Le démarrage sécurisé Secure Boot est un processus de validation par micrologiciel qui aide à prévenir les attaques de type rootkit ; il fait partie de la spécification UEFI (Unified Extensible Firmware Interface). L'objectif d'UEFI est de définir une méthode standard de communication entre le système d'exploitation et le matériel moderne, qui peut exécuter des fonctions d'entrée/sortie (I/O) plus efficaces et plus rapides que les précédents systèmes BIOS basés sur des interruptions logicielles.

Le démarrage sécurisé Trusted Boot crée une condition dans laquelle le logiciel malveillant peut être détecté (même s'il peut altérer le processus de démarrage, ce qui est peu probable), empêchant l'attribution d'une attestation d'intégrité. Secure Boot protège également le logiciel de protection contre les logiciels malveillants.


Un agent RAS (Remote Attestation Service) peut communiquer des données de démarrage mesurées qui sont protégées par un module de plate-forme sécurisée (TPM). Une fois que l'appareil a démarré correctement, les données de mesure du processus de démarrage (par exemple, le démarrage mesuré sous Windows 8) sont envoyées à un agent RAS qui les compare et transmet l'état d'intégrité de l'appareil (positif, négatif ou inconnu) en lui renvoyant une revendication d'intégrité.

Si l'intégrité de l'appareil est confirmée, il envoie cette information au service Web afin que la stratégie de contrôle d'accès de l'entreprise puisse être invoquée pour autoriser l'accès.

En fonction des exigences du fournisseur de contenu, les données d'intégrité de l'appareil peuvent être combinées aux informations d'identité de l'utilisateur sous la forme de revendications SAML (Security Assertion Markup Language) ou OAuth (norme libre d'autorisation). Le fournisseur d'identité, par exemple Active Directory, peut appartenir à l'employeur de l'utilisateur, au fournisseur de contenu ou à un réseau social tel que Facebook. Les données sont évaluées par des services de détection des fraudes qui sont déjà utilisés sur la plupart des sites Web commerciaux. L'accès au contenu est ensuite autorisé au niveau de confiance considéré comme approprié pour les assertions, ou revendications, d'intégrité. Ces protocoles basés sur des revendications sont structurés pour autoriser des demandes supplémentaires du fournisseur de contenu à l'appareil de l'utilisateur en fonction des demandes de transaction de l'utilisateur auprès du fournisseur. Par exemple, si des transferts de fonds ou de données sensibles sont demandés, il peut être nécessaire qu'un état de sécurité supplémentaire soit établi en interrogeant l'appareil de l'utilisateur avant de pouvoir procéder à la transaction.


Conclusions Les exemples précédents illustrent des solutions qui mettent en avant une architecture de service sécurisée avec séparation des fonctions. Les modèles architecturaux démontrés divisent la solution en composants faiblement couplés. Cette approche permet à chaque composant de basculer sans difficulté, même si d'autres composants subissent une défaillance catastrophique. Le service dans son ensemble peut continuer avec une partie ou la totalité de ses fonctionnalités, quel que soit le composant individuel qui arrête de fonctionner. Cette conception peut utiliser des solutions hybrides qui incluent certaines fonctionnalités hébergées en interne tout en proposant d'autres fonctionnalités, comme le passage à l'échelle de solution, via un cloud public.

Il est recommandé de s'assurer que la disponibilité soit surveillée par un service qui opère dans le même domaine que l'utilisateur. En outre, les services doivent être conçus et localisés de manière à les rendre accessibles et gérables depuis des lieux géographiques variés pour assurer leur disponibilité lors de sinistres et de catastrophes naturelles.

Les développeurs et les clients de services cloud doivent communiquer et coopérer afin d'anticiper, de prévoir dans la conception et de tester les défaillances à chaque point. Cette communication et cette coopération auront un impact direct sur le succès de la solution et la satisfaction de ses utilisateurs.


Lectures complémentaires

Pour plus d'informations sur les scénarios et solutions détaillés dans cet article, consultez les ressources suivantes. Ces documents fournissent des informations supplémentaires qui vous aideront à prendre les bonnes décisions de conception pour la disponibilité de vos solutions cloud.

The Windows Azure Application Model (Le modèle d'application Windows Azure), article en anglais https://www.windowsazure.com/en-us/develop/nodejs/fundamentals/application-model/

Microsoft System Center http://microsoft.com/systemcenter (ce site Web est désormais consacré à la version Release Candidate 2012)

Cloud Computing: Achieving Control in the Hybrid Cloud (Cloud Computing : garder le contrôle dans le cloud hybride), article en anglais http://technet.microsoft.com/en-us/magazine/hh389788.aspx

Cloud Security Alliance - Security, Trust & Assurance Registry (STAR) https://cloudsecurityalliance.org/star/

Security Guidelines for SQL Azure (Consignes de sécurité pour SQL Azure), article en anglais http://social.technet.microsoft.com/wiki/contents/articles/1069.security-guidelines-for-sql-azure.aspx

Service-Oriented Architecture – Design Patterns (article en anglais) www.soapatterns.org/masterlist_c.php

Cloud Insecurity: Not Enough Tools, Experience or Transparency (Insécurité du cloud : insuffisance d'outils, d'expérience ou de transparence), article en anglais www.technewsworld.com/story/74890.html

How the Cloud Looks from the Top: Achieving Competitive Advantage In the Age of Cloud Computing (Vue d'ensemble du cloud : obtenir l'avantage concurrentiel à l'époque du cloud computing), fichier PDF en anglais http://download.microsoft.com/download/1/4/4/1442E796-00D2-4740-AC2D-782D47EA3808/16700%20HBR%20Microsoft%20Report%20LONG%20webview.pdf

https://www.windowsazure.com/en-us/develop/nodejs/fundamentals/application-model/

https://www.windowsazure.com/en-us/develop/nodejs/fundamentals/application-model/

http://microsoft.com/systemcenter

http://technet.microsoft.com/en-us/magazine/hh389788.aspx

https://cloudsecurityalliance.org/star/

http://social.technet.microsoft.com/wiki/contents/articles/1069.security-guidelines-for-sql-azure.aspx

http://social.technet.microsoft.com/wiki/contents/articles/1069.security-guidelines-for-sql-azure.aspx

http://www.soapatterns.org/masterlist_c.php

http://www.technewsworld.com/story/74890.html

http://download.microsoft.com/download/1/4/4/1442E796-00D2-4740-AC2D-782D47EA3808/16700%20HBR%20Microsoft%20Report%20LONG%20webview.pdf





One Microsoft Way Redmond, WA 98052-6399 microsoft.com/reliability

Documents

Déploiement de solutions cloud hautement disponibles …download.microsoft.com/download/9/D/3/9D33E54F-FB2F-4ACD-BD5… · Lors de la planification d'un ... La scrutation automatisée