Améliorer la théorie unifiée de la gouvernance du cloud

Il y a un peu plus d'un an, j'ai écrit la théorie unifiée de la gouvernance du cloud. C'est un concept que j'explore depuis environ 5 ou 6 ans pour tenter de cerner la cause profonde des difficultés qu'ont les entreprises à s'adapter au cloud. Certes, le titre est un peu prétentieux, mais j'ai été analyste chez Gartner, alors bon ?

Comme toute (je l'espère) bonne théorie, je la fais évoluer au fil du temps, à mesure que je travaille avec davantage d'entreprises et que je parle à davantage de personnes. Je m'en suis énormément servi ces deux dernières années dans mes conférences et mes formations, d'autant que j'ai été sollicité sur de plus en plus de scénarios de gouvernance. Encore et encore, les problèmes majeurs que je rencontre ne sont pas tant techniques qu'organisationnels. Oui, la sécurité du cloud comporte de TRÈS nombreuses complexités techniques, qui peuvent conduire et conduisent effectivement à des compromissions, mais d'après mon expérience, les enjeux de gouvernance pèsent bien plus lourd que les enjeux techniques.

Une bonne gouvernance ne corrigera pas une faille zero day, mais une mauvaise gouvernance fait que l'attaquant n'en a jamais besoin.

Le cœur de la théorie n'a pas vraiment changé, je cherche simplement de meilleures façons de l'expliquer. J'ai aussi décidé de l'alléger un peu. Voici la forme sous laquelle je la présente actuellement sur mes diapositives :

• Le cloud décentralise les opérations et l'infrastructure
• Mais le cloud unifie toutes les interfaces d'administration
• Et place tous les portails d'administration et toutes les ressources sur Internet, protégés par un nom d'utilisateur et un mot de passe

Par rapport à la version précédente, les changements sont minimes mais aussi considérables :

• Toutes les fonctions d'administration et de gestion sont unifiées au sein d'une interface utilisateur unique, présente sur Internet.
• Protégée par un nom d'utilisateur, un mot de passe et, peut-être, une authentification multifacteur.
• La technologie évolue plus vite que la gouvernance.

J'emploie toujours la formule « ni points de passage obligés ni gardiens » dans mes interventions, mais je me suis aperçu que c'était une façon plus longue de dire « décentralisé ». Le problème fondamental, c'est le contrôle indépendant de l'ensemble de la pile en dehors de l'infrastructure centralisée. Le fait qu'une équipe de développement ou d'application puisse construire et gérer toute sa propre infrastructure dans son propre environnement avec une simple carte de crédit. Il existe encore certaines dépendances et certains contrôles, en particulier dans le plan de données ou lorsqu'il faut se raccorder aux réseaux, mais cela ne change rien au point principal.

Vouloir tout recentraliser ne fonctionnera que rarement.

Ensuite, je n'ai pas vraiment modifié l'unification des interfaces d'administration. Pour développer : nous avons décentralisé toute l'infrastructure et tout le contrôle au niveau du déploiement, mais tout le monde, dans le monde entier, utilise la même console web et les mêmes points de terminaison d'API.

Les attaquants disposent d'une seule porte d'entrée vers une infinité de cibles.

J'ai ensuite repris le sous-point de la première version pour en faire le point 3. Ces portails d'administration sont tous sur Internet et, par défaut, ne reposent guère que sur un nom d'utilisateur et un mot de passe. Toutes les ressources sont elles aussi à un paramètre près d'être exposées sur Internet : demandez donc à tous ces buckets S3 et à ces clusters ElasticSearch.

C'est vraiment aussi simple que cela. Les équipes gèrent leurs propres ressources de façon indépendante. Partout dans le monde, elles utilisent toutes les mêmes portails web et les mêmes points de terminaison d'API. Et n'importe quel imbécile disposant des bons identifiants peut fouiller l'arrière-boutique de votre « centre de données ».

Voilà le plus fou : tout cela était déjà exposé en 2011 dans la norme NIST 800-145, les 2 pages de la définition du cloud computing par le NIST. Ce document définissait les cinq caractéristiques essentielles du cloud computing :

• Libre-service à la demande
• Accès réseau étendu
• Mutualisation des ressources
• Élasticité rapide
• Service mesuré

Si l'on reprend les trois premiers points, nous avons :

• Les équipes gèrent leurs propres ressources
• Tout est sur Internet
• Et tout repose sur des pools de ressources collectifs

Bien, alors qu'est-ce que tout cela signifie et que devons-nous faire ?

L'accepter.

C'est la première étape. Comprendre le problème et s'en servir comme grille de lecture pour concevoir nos solutions. Comme je l'écrivais récemment dans mon article sur l'autorisation forte :

Parce qu'ils n'ont pas l'habitude que tout soit (potentiellement) sur Internet. L'ensemble du plan de gestion est sur Internet : si un attaquant obtient des identifiants, vous ne pouvez pas l'arrêter avec un pare-feu ni en coupant l'accès à un serveur.

Partez de là. Acceptez cette réalité de base. Que pouvons-nous faire pour réduire ce risque ? Pour réduire ces attaques ? À mon sens, le choix le plus déterminant consiste à se concentrer sur l'IAM, et sur l'intersection entre la gouvernance et l'IAM. Qui gère les autorisations ? Les accès ? Quels contrôles de sécurité permettent de prévenir, de détecter et de corriger les attaques liées à l'IAM ? Quels sont vos processus autour de l'IAM ? Vos équipes de réponse aux incidents connaissent-elles en profondeur les rouages de l'IAM de votre ou vos fournisseurs cloud ? Utilisez-vous le JIT ou l'autorisation forte ? Comment gérez-vous l'IAM pour les prestataires et les services externes ?

Commencez par votre gouvernance et vos processus IAM. Choisissez et utilisez ensuite les technologies qui les soutiennent. C'est le moyen le plus déterminant d'améliorer la sécurité de votre cloud. J'espère vraiment ne pas être le premier à vous le dire.