Les 5 grands axes de la sécurité multicloud

1 novembre 2020

Par Brandon Evans, formateur au SANS Institute

Résumé

La tendance à recourir à plusieurs fournisseurs Cloud confronte les professionnels de la sécurité et de la conformité à de nouveaux enjeux et perspectives. Dans un paysage d’offre de services en constante évolution, le risque est bien réel de prescrire des solutions de sécurité qui ne soient pas universelles.

Dans cet article, nous allons passer en revue cinq axes essentiels pour un usage sécurisé des trois principaux fournisseurs de Cloud public, à savoir Amazon Web Services, Microsoft Azure et Google Cloud Platform.

La tentation est grande d’ignorer le mouvement multicloud ou de le bloquer au sein de l’entreprise, mais une telle réponse risque surtout de rendre le problème ingérable. À l’inverse, s’ils en acceptent le caractère inévitable et s’attachent à le comprendre, les professionnels de la sécurité et de la conformité participent à accompagner l’évolution de l’entreprise en toute sécurité.

1. Introduction

En dépit des réticences de nombreux professionnels de la sécurité et de la conformité, les plateformes de Cloud public occupent une place de plus en plus appréciable dans la stratégie technique de toutes les entreprises ou presque. À cela, une raison principale : les intéressés côté technique ont estimé que les risques liés à l’infogérance de leurs données, même non négligeables, sont largement contrebalancés par ceux d’une gestion en interne des mêmes données ou pire d’un retard d’innovation qui les pénaliserait vis-à-vis de la concurrence.

Ces entreprises ont pris le temps d’étudier et de comparer les fournisseurs Cloud avant de sélectionner celui qui répondait le mieux à leurs besoins. Historiquement, elles ont choisi Amazon Web Services (AWS) à une large majorité. Si AWS reste encore certainement le premier fournisseur d’infrastructure Cloud IaaS, des concurrents sérieux se sont déclarés. Microsoft Azure a conclu de nombreux contrats avec son offre exhaustive axée sur la sécurité et l’intégration fluides des services, qui lui a valu de remporter en 2019 le marché JEDI du ministère de la Défense américain d’une valeur de 10 milliards de dollars. Bien que seulement 3e sur le podium, Google a emporté de nombreux suffrages avec Google Cloud Platform (GCP), d’une part grâce à ses efforts de développement et de soutien des technologies open source populaires, notamment Kubernetes, d’autre part grâce aux services singuliers que le rachat de Firebase lui a apportés.

Confrontées à un choix difficile entre plusieurs fournisseurs de qualité, beaucoup d’entreprises optent pour une approche « multicloud ». Plutôt que de tout parier sur un seul fournisseur, les entreprises multicloud évaluent des offres comparables et sélectionnent la meilleure, quel qu’en soit le fournisseur.

Le multicloud est devenu la norme. Les entreprises réalisent des économies, évitent la mono-dépendance et apportent à leurs développeurs les outils qu’ils veulent utiliser pour créer des applications Cloud.

Malgré l’engouement pour Azure, AWS reste largement utilisé par la même proportion d’entreprises et le recours à Google augmente. Ces chiffres seraient inexplicables sans la tendance du multicloud. https://www.zdnet.com/article/multicloud-everything-you-need-to-know-about-the-biggest-trend-in-cloud-computing

Malheureusement, le multicloud implique un surcroît de travail en sécurité. La transition sécurisée vers le Cloud et les « 175 services complets » d’AWS n’étaient déjà pas une mince affaire, mais, désormais, l’équipe Sécurité doit en plus analyser d’autres fournisseurs et en encadrer les usages. Pire encore ! d’un fournisseur Cloud à l’autre, les divergences ne manquent pas : on ne peut pas se contenter d’appréhender globalement les concepts Cloud ; l’équipe Sécurité d’une entreprise multicloud doit se plonger dans les détails. Si vous vous trouvez dans cette situation délicate, nous répertorions quelques-uns des aspects les plus importants à prendre en compte.

2. L’ardue et omniprésente gestion des identités et des accès (IAM)

L’IAM, de l’anglais Identity and Access Management, est un des grands concepts fondamentaux du Cloud. Un bon IAM laisse les personnes ou l’infrastructure Cloud accéder aux ressources Cloud dont elles ont besoin et barre l’entrée à toute autre.

Mode d’accès d’une infrastructure Cloud à d’autres services via IAM : exemple de workflow

Cet idéal est rarement atteint en pratique. En 2017, l’analyse d’un échantillon de plus de 31 000 charges de travail et instances de machines virtuelles EC2 par Alert Logic a détecté 30 000 erreurs de configuration d’IAM. Les attaquants prennent progressivement conscience de ces faiblesses qu’ils exploitent avec créativité.

Dans le monde du développement, peu saisissent les risques que posent les mauvaises politiques d’IAM. Le point de vue général est qu’on a le contrôle sur tout le code susceptible d’accéder aux ressources Cloud. Mais, avec cet état d’esprit, on se contente d’éviter de déployer du code malicieux. On passe à côté du risque très réel d’attaques par falsification de requêtes côté serveur (SSRF), par injection de commandes, ou ciblant des prestataires dans des supply-chain attacks où l’attaquant va voler les informations d’identification IAM sous-jacentes et écrire son propre code malicieux pour compromettre ou corrompre vos ressources. Vous pouvez regarder une démonstration en conditions réelles des ravages que peut subir une organisation aux politiques insuffisantes dans un contexte sans serveur dans mon webcast SANS@Mic « Attacking Serverless Servers: Reverse Engineering the AWS, Azure, and GCP Function Runtimes » (je vous préviens, c’est effrayant !).

Laisser un Cloud accéder à un autre ajoute encore à la complexité. Avec un seul fournisseur, l’entreprise a le luxe de le laisser s’occuper de la génération, de l’expiration et du renouvellement automatique des données d’authentification. À l’inverse, si elle veut relier deux services Cloud dans deux Clouds différents, elle doit exporter les informations d’identification longue durée d’un fournisseur à l’autre et assurer la prise en charge des procédures de renouvellement des informations d’accès de chaque Cloud. Par exemple, dans le schéma ci-dessus, pour autoriser l’accès à DynamoDB à une instance AWS EC2, celle-ci doit être affectée d’un « profil d’instance » pour lui permettre d’endosser un rôle IAM et d’obtenir des informations d’accès temporaire à la base de données. Pour donner accès à Azure à la même base DynamoDB, il va falloir créer un utilisateur IAM avec des informations d’accès permanent qui seront stockées dans Azure. Les bonnes pratiques d’AWS incitent à utiliser les rôles IAM dès que possible plutôt que les utilisateurs, mais ce type d’architecture multicloud vient contrarier cet idéal.

Que chaque fournisseur Cloud gère l’IAM à sa manière ne facilite pas les choses. Chacun a son vocabulaire propre, sa logique d’évaluation et ses défauts. Notons en particulier que GCP enfreint les conventions IAM. Par défaut, lorsqu’on lance une machine virtuelle (VM) sur AWS ou Azure, elle n’a accès à aucune autre ressource Cloud. GCP suit pour ainsi dire l’approche inverse : la plateforme accorde à la VM un compte de service par défaut doté du rôle « Éditeur ». Les éditeurs ont accès en lecture et écriture à toutes les ressources du projet. Ils peuvent aussi créer et supprimer de nombreuses ressources. Il s’agit du deuxième rôle primitif le plus puissant, juste après « Propriétaire » qui peut en outre gérer les rôles et la facturation. Les mêmes notions applicables aux VM Cloud le sont aux fonctions sans serveur de ces fournisseurs. Finalement, il est fondamental d’appréhender les différentes approches afin de n’exposer que l’infrastructure et les données strictement nécessaires aux tiers.

3. La sécurité réseau reste primordiale

Si une organisation savait sortir un logiciel sans jamais un seul bogue de sécurité, assurer la maintenance de son infrastructure sans aucune erreur de configuration et valider sans aucun doute possible ses fournisseurs, alors exposer tous ses actifs sur l’internet public ne la mettrait pas en trop grand danger. Mais dans la vraie vie, sécuriser le périmètre de notre réseau constitue notre première ligne de défense contre une myriade de menaces.

Le principe reste le même dans le Cloud. Quand nous confions nos actifs privés à notre fournisseur, nous ne voulons certainement pas les exposer aux internautes anonymes qui compulsent Shodan. Chaque fournisseur offre des moyens d’isoler logiquement vos ressources du monde extérieur sans grande difficulté. Mais faire interagir entre elles des ressources de différents Clouds implique de fragiliser ces configurations. Le sujet est si pointu que GCP a publié une série de trois articles « Cloud hybride et multicloud ». La complexité est de mise dans un environnement à plusieurs Clouds, même si elle ne dure que le temps de la transition d’un système sur site vers le Cloud ou d’un changement de fournisseur. Pour citer un triste constat dans cette série d’articles, « une configuration hybride ou multicloud est rarement un objectif en soi, mais plutôt un moyen de répondre aux besoins de l’entreprise ».

Tout comme l’IAM, la gestion de la sécurité du réseau est radicalement différente d’un fournisseur Cloud à l’autre et, là encore, GCP se démarque. Par exemple, pour toute nouvelle machine virtuelle dans AWS et Azure, il vous est explicitement demandé de configurer les ports qui acceptent le trafic entrant et les sources autorisées. Même si la configuration recommandée par défaut autorise le trafic SSH entrant de partout dans le monde, le modèle de responsabilité partagée renvoie le client à sa propre responsabilité dans le choix judicieux ou non de ce paramètre. Par comparaison, le Google Compute Engine présente seulement les options suivantes :

Ensemble trompeur de règles de pare-feu paramétrables dans Google Compute Engine.

Mais une fois la VM lancée, vous remarquerez qu’elle autorise l’accès SSH. Et la raison en est que, par commodité, GCP préremplit les valeurs réseau par défaut avec des règles pour le moins surprenantes qui acceptent le trafic SSH et RDP de toute provenance. Même le trafic ICMP entrant est autorisé : je sais bien qu’il est courant de faire un test ping vers Google lors de l’analyse d’un problème réseau, mais on va bien au-delà ici.

Les très permissives règles dans le réseau par défaut sur Google Cloud Platform. https://cloud.google.com/vpc/docs/firewalls#more_rules_default_vpc

Est-il utile de rappeler qu’il est important de connaître ces pièges pour tout nouveau fournisseur Cloud, pour éviter de figurer dans Shodan, le moteur de recherche de la honte ?

4. Chiffrement incohérent : casse-tête de la conformité

Les fournisseurs Cloud et les équipes Sécurité s’entendent tous sur l’importance du chiffrement. Le seul problème est que les avis divergent sur les détails. Il y aurait beaucoup à dire, mais nous allons nous intéresser à deux grandes catégories de chiffrement : au repos et en transit.

Le premier fait référence au chiffrement des données là où elles sont stockées. Par exemple, dans la configuration des bases de données Cloud gérées, on peut paramétrer le chiffrement du disque sous-jacent. Ainsi, en cas de vol de la machine hôte, les données resteraient inaccessibles au voleur. Azure et GCP ont l’avantage de toujours chiffrer les volumes des bases de données, mais au détriment de la personnalisation. S’il est impossible aux clients de désactiver le chiffrement, ils n’ont pas non plus la main sur la méthode ni sur les clés de chiffrement. De quoi poser un grave problème de conformité à l’entreprise qui serait empêchée par contrat de recourir à tout élément de clé généré dans le Cloud. À l’inverse, AWS vous laisse chiffrer votre base de données au repos avec n’importe quelle clé principale client (CMK) d’un service de gestion de clés (KMS), qu’elle soit gérée par AWS ou par vous, le client. Les deux approches se valent. L’important est de savoir laquelle est compatible avec votre organisation.

Le chiffrement en transit consiste à sécuriser un canal de communication de façon qu’aucun tiers ne puisse observer ni modifier le trafic entre l’émetteur et le destinataire. Toujours dans notre exemple de la base de données gérée, chaque fournisseur vous permet de rendre obligatoire le chiffrement en transit. Certains en facilitent la mise en œuvre. C’est le cas d’Azure et de GCP, chez qui il suffit d’activer un seul paramètre, clairement visible dans la console Web. Pour arriver au même résultat dans AWS, il faut créer un jeu de configuration dit « Groupe de paramètres », activer un obscur paramètre « rds.force_ssl » à la treizième page, puis associer le groupe de paramètres à l’instance de base de données. En cas d’irrégularité dans la transmission de données chiffrées, votre responsabilité juridique pourrait être engagée. Pour assurer vos arrières, vous êtes donc tenu de multiplier les vérifications pour chaque fournisseur.

Dans le Cloud, il s’avère parfois extrêmement difficile de déterminer les paramètres importants.

5. Le multicloud améliore, un peu, la disponibilité

À l’ère d’un Cloud balbutiant et peu étendu, il n’était pas rare de multiplier les Clouds pour élargir sa disponibilité partout dans le monde. Aujourd’hui, l’argument ne tient plus. Preuve en est la carte que j’ai dressée des emplacements approximatifs de l’infrastructure Cloud d’AWS, d’Azure et Google Cloud:

L’infrastructure Cloud d’AWS apparaît en orange, Azure en bleu, et GCP en vert. https://www.google.com/maps/d/viewer?mid=1WKYlcUMJKnOnlvmGkn82Ek0TZAgKmFj3

AWS et Azure affichent une couverture relativement comparable et bien établie : vous pouvez héberger vos ressources chez eux dans la plupart des régions du monde, sauf en Russie. Il n’en va pas de même pour GCP, sans présence aucune en Afrique ou en Chine. Même si Google annonçait en 2018 une prochaine « offre de services en Chine continentale », l’engagement n’a pas encore été tenu.

L’équivalence territoriale entre AWS et Azure peut laisser perplexe puisque Azure déclare « être présent dans plus de régions du monde que tout autre fournisseur Cloud ». Certes, ce décompte est correct avec 58 régions pour Azure, 23 pour AWS et 22 pour GCP. Toutefois, la région telle que définie par Azure est radicalement différente de celle d’AWS. Chez AWS, ce sont des « zones de disponibilité » ou AZ (Availability Zone), à savoir une grappe de datacenters dans une même région. Ainsi, dans le cas d’une infrastructure déployée sur plusieurs AZ, quand une zone subit une panne, l’infrastructure reste disponible dans la région. Jusqu’en 2018, Azure n’offrait pas de zones de disponibilité : un service de haute disponibilité passait par la réplication de l’infrastructure vers une région ou un fournisseur Cloud différents. Si Azure déploie actuellement ses zones de disponibilité aux autres régions et services, il n’en reste pas moins que seules 10 de leurs régions sont concernées. Par contraste, AWS propose plusieurs AZ dans chacune de ses régions (sauf Osaka) et intègre leur prise en charge dans tous ses services : sa présence mondiale est bien la plus importante, ce que reflète l’omniprésence de la couleur orange dans la carte ci-dessus. Ceci étant, si l’un de vos critères impose d’héberger votre infrastructure au Mexique ou au Qatar, Azure est votre seule option.

6. Le multicloud va tôt ou tard arriver dans votre organisation

Certains des points soulevés plus haut, qu’ils concernent la sécurité ou l’opérationnel, vous inciteront peut-être à empêcher l’adoption du multicloud dans votre organisation, s’il n’est pas déjà trop tard. Bien ou mal, la bataille est quasiment perdue d’avance. Même si votre organisation a un fournisseur exclusif, vous seriez bien en peine de prévoir les piles techniques dont vous hériterez à l’occasion d’une fusion ou d’une acquisition. Si vous récupérez une infrastructure chez un fournisseur Cloud que vous ne connaissez pas, votre organisation a une alternative : apprendre à prendre en charge la nouvelle technologie ou migrer les actifs hérités vers votre fournisseur en place. Idéale, la seconde solution pourrait aussi se révéler exorbitante. Si ce coût ne se justifie pas commercialement, l’organisation n’aura d’autre choix que de prendre en charge le nouveau fournisseur Cloud.

Même dans le cadre d’une entreprise plus petite, peu concernée par les fusions et acquisitions, on se souviendra avec grand intérêt de ce qui pousse en premier lieu les équipes à adopter d’autres solutions Cloud : faciliter le travail ou le rendre plus agréable. Au bout du compte, ce sont les développeurs qui créent les produits qui rapportent de l’argent, pas l’équipe Sécurité. Si l’équipe de développement découvre une offre de service susceptible de l’aider à mettre son produit sur le marché avant la concurrence, elle peut et doit l’utiliser, hors problème de sécurité catastrophique ou dette technique intenable.

Quand on l’en empêche, il arrive très souvent qu’elle crée des comptes Cloud « fantômes » qui échappent à la gestion et au contrôle de l’entreprise. C’est le pire scénario possible pour une organisation qui cherche à standardiser tant soit peu ses comptes Cloud. Un compte Cloud fantôme peut mener à un développement sauvage, hors de toute règle, mais il signifie aussi la disparition de toute forme de contrôle, d’analyse et d’appréciation de la situation dudit compte par le service central. Au-delà, l’existence de tels comptes soulève des inquiétudes juridiques et politiques puisque leur fourniture a souvent lieu hors des procédures officielles. La situation n’est pas tenable. Au final, il faudra consolider les actifs du compte Cloud fantôme dans un compte d’entreprise : l’aventure aura été plus coûteuse et chronophage que si l’organisation avait empêché la divergence au départ.

Au lieu de tenter en vain d’arrêter le mouvement multicloud, l’équipe Sécurité doit accepter son inéluctabilité et l’accompagner de garde-fous pour chacun des fournisseurs Cloud. Si vous souhaitez approfondir le sujet, vous êtes invité à découvrir ma formation SANS, SEC510: Multicloud Security Assessment and Defense. Dans ce cours, les stagiaires apprennent à mener des évaluations de sécurité multicloud transversales (AWS, Azure et GCP), à identifier les principales faiblesses des services Cloud essentiels, et à appliquer des configurations durcies. De vastes pans du Cloud restent trop peu, pas, voire mal, documentés. Pour évaluer le risque dans le Cloud, il faut s’intéresser aux rouages internes. Dans le cours SEC510, nous ne nous contentons pas de citer les bonnes pratiques extraites de la documentation de chaque fournisseur : nous mettons nous-mêmes à l’épreuve ces recommandations dans un environnement multicloud réaliste de test. La formation couvre en détail les thèmes abordés dans cet article, et bien plus encore.

Pour en savoir plus sur le programme de formation et les cours de SANS, reportez-vous au site SANS.

Auteur: Brandon Evans

À propos de l’auteur :

Brandon Evans est formateur au SANS Institute. Il assure le cours SEC540: Cloud Security and DevOps Automation et est le principal concepteur du prochain SEC510: Multicloud Security Assessment and Defense. Dans son rôle de Senior Application Security Engineer chez Asurion, il fournit des services de sécurité à des milliers de ses collègues développeurs répartis sur différents sites dans le monde qui programment des centaines d’applications Web. Ces services comprennent notamment des revues de code axées sur la sécurité, des tests d’intrusion, le développement de gabarits de code sécurisé, et la promotion de l’importance de créer des produits sécurisés.