Je gardais sous le coude depuis quelques temps un potentiel article à propos du site cloudfail.net, remarquable référentiel de rapports d’incidents concernant les principales plateformes de Cloud computing. Ce site consolide en effet les rapports d’incidents déclarés sur ces plateformes, les taggue, et les classe par catégorie.
Je devrais peut-être parler de ce site au passé, puisqu’il est inaccessible depuis le 4 juillet, et aucun signe ne permet de dire s’il reviendra en ligne. Quoi qu’il en soit, à la lecture de cette base de données, il en ressort qu’une majorité écrasante d’incidents (en nombre) affectant les offres de Cloud computing impactent la disponibilité du service. Et en conséquence, l’indisponibilité est perçue par utilisateurs et grand public comme le principal risque lié aux offres de Cloud, au détriment des atteintes à la confidentialité et à l’intégrité – les deux autres mamelles de la sécurité.
Le problème, c’est que les rapports d’incident publiés par ces plateformes n’offrent qu’une analyse partielle, voire pas d’analyse du tout, des causes du dysfonctionnement : tout au mieux sait-on si l’incident résulte d’une opération de maintenance planifiée ou s’il s’agit d’un événement inattendu. L’atteinte à la disponibilité du service est donc un impact par défaut, celui perçu en bout de chaîne, à défaut d’en savoir plus sur les causes réelles du problème : en toute logique, c’est donc aussi le seul impact mesuré et cadré par les contrats d’externalisation. Or en soi, une atteinte à la disponibilité, ça ne veut pas dire grand-chose, car cette atteinte est en général provoquée par d’autres causes. Par exemple, la corruption d’une base de données provoquera son indisponibilité, le temps de retrouver les backups et de restaurer l’intégrité de la base. Ou encore, une intrusion résultera en général par un arrêt temporaire du service, pour réaliser des analyses forensics et pour nettoyer les systèmes affectés. Or, si l’on tait ces causes, le client du service de Cloud ne percevra en bout de chaîne qu’un problème de disponibilité du service.
Alors quoi, il n’y aurait donc chez nos fournisseurs de Cloud que des incidents provoqués par des routeurs qui crashent, des switchs qui plantent, et des défauts d’alimentation électrique ? L’actualité nous rappelle le contraire, avec quelques méga-incidents (Microsoft Azure, Amazon, LinkedIn, etc.) dont l’impact énorme a mis en lumière des incidents de nature bien différente. Mais en dehors de ces trop rares éclairages, nous ne percevons la sécurité du Cloud que par la lorgnette de sa disponibilité.
C’est d’autant plus fâcheux que le domaine de la disponibilité est parfois perçu, à tort, comme étranger à la sécurité informatique ; celui que l’on peut sous-traiter le plus facilement à grands coups de SLA (ah, si l’on pouvait aussi sous-traiter les dommages à son image de marque…), en redondant les serveurs, ou encore en déléguant le problème aux équipes opérationnelles. Sauf que comme on l’a vu, bien souvent l’indisponibilité est le symptôme d’un défaut de sécurité plus grave ; et d’ailleurs, changeons de vocabulaire : personne ne contesterait que les dénis de service sont bien un problème de sécurité, quoique représentant une pure atteinte à la disponibilité. Ce désintérêt est aussi alimenté par le fait que la malfaisance informatique occupe le devant de la scène, reléguant les phénomènes accidentels à la périphérie des préoccupations des RSSI.
Nous avons donc d’un côté, les fournisseurs de Cloud computing qui semblent tentés de faire passer sous le tapis de l’indisponibilité la majeure partie de leurs incidents ; et de l’autre côté, un certain désintérêt de la sécurité pour les problématiques de disponibilité. Dans ces cas là, on dit « Vous pouvez embrasser la mariée ».
Comparez la performance des offres cloud via notre service Cloud Monitor