Cloud computing : risques et périls!

Cet article a été publié initialement sur mon ancien blog, qui était hébergé par blogspot.com.

Mardi 12 avril 2011, j'ai fait une présentation intitulée "Cloud computing : risques et périls"  à la conférence sur la Protection des données et Cloud computing du Clusis.

J'ai commencé ma présentation par donner ma définition du Cloud computing et présenter la pyramide du Cloud. Durant cette introduction, j'ai présenté un nouveau concept qui commence à se répandre dans monde du Cloud. Il s'agit de la notion de "community Cloud". Ce dernier est une forme de coopérative appliquée aux systèmes d'information. Cela permet de partager les coûts liés à un projet de type Cloud "privé" entre plusieurs entreprises désirant partager des ressources dans le cadre d'un projet, ayant une entreprise commune (par exemple : une entreprise franchisée) ou des entreprises qui ont un métier similaire et qui n'ont pas les ressources nécessaires pour déployer un Cloud "privé" (par exemple : des hôpitaux).

Durant cette première phase de ma présentation, j'ai également parlé de la jeune startup DotCloud qui a développé une solution de type PaaS (Platform as a Service) qui permet aux développeurs de développer dans de nombreux langages sans se soucier des problèmes de scalabilité et d'élasticité. Cette plate-forme est hébergée sur la solution de IaaS (Infrastructure as a Service) d'Amazon. Cette solution a pour avantage de bénéficier d'une plate-forme robuste et éprouvée avec Amazon, mais elle montre aussi de nouveaux risques et périls comme le SLA.

La deuxième partie de ma conférence a principalement consisté à lever des interrogations sur les risques et périls du Cloud et à donner des pistes de réflexions. Personnellement, j'ai regroupé ces risques et périls en quatre catégories.

La première catégorie concerne la sécurité physique des données. Quelle est la nature des données publiques - confidentielles ou secrètes? Est-ce que mes données sont encryptées sur le Cloud? Est-ce que je peux les crypter? Est-ce que le prestataire est certifié ISO 27000? Est-ce qu'il a été audité SAS 70 par exemple? Existe-t-il des normes et standards nationaux pour la certification et l'auditatbilité?

Ma deuxième catégorie porte sur les problèmes légaux. Durant cette conférence nous venions d'avoir deux présentations, une sur la loi fédérale du 19 juin 1992 sur la protection des données (LPD) en Suisse et l'autre sur l'agrément un nouvel outil pour accompagner les institutions en matière de protection des données dans leurs projets informatiques et technologiques. Je n'ai donc pas réellement évoqué les problèmes légaux nationaux, par compte j'ai insisté sur les problèmes légaux internationaux comme l'USA PATRIOT Act. Cette loi donne au FBI le pouvoir de demander à n'importe quelle organisation de fournir toutes les pièces tangibles pour une enquête de lutte contre le terrorisme international ou les activités d'intelligence clandestines. Des lois semblables peuvent entrer en vigueur  dans tous pays. Elles ne permettent pas de garantir la sécurité et la confidentialité des données traitées sur des plateformes de "Cloud Computing" domiciliées en dehors du territoire ou exploitées par des sociétés basées à l'étranger.

La troisième catégorie de risques et périls porte sur la dépendance. Le débat existe depuis de nombreuses années en matière d'open source. Il est encore plus fort avec le Cloud, car il n'existe pas encore de standards. L'IEEE (Institute of Electrical and Electronics Engineers) a annoncé le 4 avril 2011 [1], qu'il allait créer un groupe de travail pour définir les standards en matière de Cloud computing. En matière de dépendance il faut aussi réfléchir à la dépendance réseau. Que faire en cas de panne ou coupure réseau? Par exemple, que faire si les liens vers d'autres pays sont coupés? Le dernier point à vérifier en matière de dépendance est la viabilité de l'entreprise. Ce point est d'autant plus important, car il n'existe que peu de standard en matière de Cloud.

La quatrième catégorie que j'ai présentée lors de cette conférence est le SLA (Service Level Agrement). Avant de signer un SLA il faut vérifier le niveau de service 99.95% (~4 heures d'arrêt par an) ou 99.999% (~5 minutes d'arrêt par an). Que couvre ce SLA? Panne machine? Panne réseau? Panne électrique? Quels sont les conditions pour que cela soit applicable? Quelles sont les pénalités. Plus les pénalités sont élevées plus le prestataire de service à intérêt à faire fonctionner sa solution. Dans le cas contraire il risque la faillite.

J'ai conclu ma présentation en présentant mon modèle ci-dessous.

En fonction du besoin métier, de la criticité de l'information et du degré de confiance dans le Cloud, le chef de projet devra choisir la case de la matrice qui lui convient. Plus le bleu de la cellule est foncé, plus je peux garder le contrôle et la maîtrise de mon système d'information. Inversement plus la couleur est claire et plus mon système d'information sera vaporeux. Je risque donc de violer les lois sur la protection des données, de perdre une partie de mes données ou ne pas pouvoir récupérer et supprimer mes données du Cloud, mais je me serai familiarisé avec le Cloud!

[1] IEEE LAUNCHES PIONEERING CLOUD COMPUTING INITIATIVE, IEEE, http://standards.ieee.org/news/2011/cloud.html, publié le 04/04/2011, consulté le 04/04/2011