Stanislas Quastana's blog on TechNet

Windows Server, Windows Client, Cloud Computing, DirectAccess, sécurité des Systèmes d Information

Cloud et Sécurité - Mythes et réalités - partie 3 - quid de la disponibilité ?

Cloud et Sécurité - Mythes et réalités - partie 3 - quid de la disponibilité ?

  • Comments 1
  • Likes

[Note préalable : ceci est la troisième partie d’une série d’articles traitant du Cloud Computing et de la Sécurité. Les deux premiers articles sont ici et ici]

Tout client d'une solution de Cloud (privé ou public) se doit d'être concerné par la disponibilité des données stockées et des services proposés (peut être encore plus quand le Cloud est public).

3 éléments majeurs sont à considérer :

- L’indisponibilité de la connectivité réseau suite à la défaillance (ou à l'attaque) d'un des éléments (routeur, pare-feu, DNS...) de l'infrastructure réseau du fournisseur de Cloud.  L'indisponibilité peut être liée à une coupure dans la chaine de communication ou à une saturation d'un des points de cette chaine.

On peut résumer le problème à la phrase suivante : "pas de Cloud sans réseau" ou “Pas de réseau, pas de Cloud”

Au delà de l'infrastructure réseau du fournisseur de Cloud, il faut également que le client apporte une attention particulière à son réseau et à la disponibilité de sa connectivité vers Internet (avoir à minima plusieurs liaisons vers des Fournisseurs d'Accès Internet différents n'est pas un luxe mais une nécessité). Pour les petites structures (exemple : les sucursales d’un réseau d’agences), la connexion vers Internet peut être “backupée” par l’usage d’une clé 3G par exemple.

- Le niveau de disponibilité proposé (contractuellement) par le fournisseur de Cloud. Aujourd'hui, aucun fournisseur de services Cloud ne propose de disponibilité à cinq 9 (cf. tableau ci-dessous) sur la totalité de ses services, la moyenne étant plutôt du trois 9.

A titre d'exemples : Microsoft garanti contractuellement un niveau de service (SLA) de 99.9% pour ces services SaaS suivants : Exchange Online, SharePoint Online, Office Live Meeting and Office Communications Online. Microsoft Forefront Online Protection for Exchange (SaaS d’hygiène pour la messagerie électronique) garanti un niveau de service de 99.999% pour l’infrastructure réseau.

Note : la mesure de la disponibilité est généralement à l’échelle du mois (voire du mois glissant) dans les contrats (cf. exemple plus bas dans cet article)

Informations complémentaires sur les niveaux de services dans les offres Cloud Microsoft :

Dans la réalité, la plupart des fournisseurs de Cloud Public ont connus ces dernières années (et pour certains ces derniers mois) des pannes ou indisponibilités non planifiées (quand c’est planifié, l’indisponibilité n’est pas comptabilisée)

Quelques exemples issus du site datacenterknowledge.com (vous pouvez y faire une recherche sur le mot clé Outage, il y a pas mal d’articles) :

 

- Le niveau de disponibilité des données stockées dans un Cloud peut varier en fonction des fournisseurs et des services qu'ils proposent et des options retenues (et payées) par le client. Le stockage de données n'implique pas forcément la présence de mécanismes de sauvegarde / restauration. Donc vigilance lors de la lecture des clauses contractuelles.

———

Il est fondamental lors du choix d'un fournisseur de Cloud de comparer les SLA et les clauses contractuelles concernant la disponibilité des services Cloud Publics proposés par les fournisseurs.

En effet, ces clauses et données peuvent varier fortement entre fournisseurs et il n'est pas toujours possible de comparer des éléments comparables. Au final, c’est au client de trouver le fournisseur avec les clauses contractuelles les plus adaptées à son besoin.

De même, il faut absolument que le client connaisse les compensations financières (généralement sous la forme d’avoirs) qu’il va obtenir en cas du non respect du SLA par le fournisseur de Cloud

Prenons le cas du SLA de SharePoint Online Services (cf. ici) pour illustrer un exemple de SLA :

2-Niveau de Service Temps d'Activité Mensuel 

A– Définitions

« Temps d'Indisponibilité » désigne toute période au cours de laquelle les utilisateurs sont dans l'impossibilité de lire ou d'écrire toute ou partie d'une collection de sites SharePoint pour laquelle ils disposent des autorisations appropriées. Le Temps d'Indisponibilité n'inclut pas les périodes au cours desquelles le Service n'est pas disponible en raison : (i) d'un Temps d'Indisponibilité planifié ou d’une opération de maintenance ou de mise à niveau planifiée du réseau, du matériel ou du service ; ou (ii) des agissements ou des omissions du Client ou de ses employés, agents, prestataires ou fournisseurs, ou de toute personne ayant accès au réseau Microsoft au moyen des mots de passe ou de l’équipement du Client.

« Temps d’Indisponibilité Planifié » désigne les périodes de Temps d’Indisponibilité notifiées par Microsoft aux Clients au moins cinq (5) jours avant le début dudit Temps d’Indisponibilité. Le Temps d’Indisponibilité Planifié inférieur à dix (10) heures par année calendaire n’est pas considéré comme un Temps d’Indisponibilité pour les besoins du présent SLA.

Le « Pourcentage de Temps de Disponibilité Mensuel » d’un Client spécifique est calculé en totalisant le nombre de minutes d’un mois calendaire et en multipliant ce chiffre par le nombre total d’utilisateurs titulaires d’une licence moins le nombre total de minutes de Temps d’Indisponibilité subies par tous les utilisateurs au cours du mois calendaire ; le chiffre obtenu est ensuite divisé par le nombre total de minutes dans ce mois calendaire multiplié par le nombre total d’utilisateurs. La formule suivante illustre ce calcul :

B– Niveaux de Service de Temps de Disponibilité

Autre exemple de SLA : celui d’Amazon S3 (http://aws.amazon.com/fr/s3-sla/)

Typiquement ici, la compensation financière est moins intéressante que dans le SLA de SharePoint Online (Note : je ne devrais pas comparer des contrats d’offres non comparables mais c’est juste pour illustrer le fait que les compensations en cas de non respect des SLA diffèrent d’une offre à l’autre et d’un fournisseur à un autre)

——-

Responsabilité du client d'une Offre Cloud

Le client doit connaitre et comprendre les niveaux de service attendus (SLA) ainsi que les méthodes de communications utilisées (courrier électronique, SMS, tableau de bord en ligne, flux RSS) pour être informé d'un arrêt temporaire des services.

Exemples de tableaux de bords :

Service Windows InTune (SaaS) : accessible via le menu Administration d’un compte Windows Intune

Services Microsoft Online (SaaS) : https://health.emea.microsoftonline.com/ 

Plus d’informations sur le Dashboard de Microsoft Online Services : http://blogs.technet.com/b/msonline/archive/2010/09/27/introducing-the-microsoft-online-service-health-dashboard.aspx

Services Windows Azure (PaaS) : http://www.microsoft.com/windowsazure/support/status/servicedashboard.aspx

Services Amazon AWS (IaaS) : http://status.aws.amazon.com/

Le client d’un fournisseur de Cloud peut également compléter ces moyens d'informations fournis par le fournisseur par ses propres outils de surveillance (on-premise ou en ligne)

Exemples de services de surveillance :


Bien entendu en fonction du modèle de Cloud utilisé (IaaS, PaaS ou SaaS), la responsabilité en terme de disponibilité va être plus ou moins partagée entre le client et le fournisseur de Cloud.

Dans une offre SaaS, le fournisseur de Cloud est responsable de quasiment la totalité de la chaine applicative (à l'exception potentielles des composants externalisés tels que la gestion d'identité chez un fournisseur d'identité tiers).

Dans une offre PaaS, le fournisseur de Cloud est responsable de la disponibilité de la plateforme applicative mais pas de la disponibilité de l'application elle-même ou des composants tiers utilisés par le client. La qualité et la robustesse et la capacité à monter en charge de l'application va également avoir un impact sur sa disponibilité.

Dans une offre IaaS, le fournisseur de Cloud est responsable de la disponibilité de la plateforme de virtualisation (réseau + matériel + socle de virtualisation) mais pas de la disponibilité du système installé dans les machines virtuelles, des applications exécutées dans ces machines ou des composants tiers utilisés par le client. La bonne gestion par le client des machines virtuelles et des composants et applications installées va fortement influencer la disponibilité.

– Stanislas Quastana -

Comments
  • Superbe article, merci

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment