Depuis le début de l’année, au moins cinq cas majeurs de fuite de données dans le cloud ont été révélés. À chaque fois, il s’agissait d'une erreur de configuration du stockage Amazon S3 ou de bases de données hébergées dans un Cloud public.
Cela parait incroyable ? En fait, la réalité l’est plus encore. Car pour que de telles ressources Cloud soient accessibles à n’importe qui depuis l’extérieur, elles doivent être configurées expressément pour cela. Quelqu’un doit donc intentionnellement en réduire le niveau de sécurité par défaut.
C’est pourquoi il est difficile de parler « d’erreur de configuration », comme on l’entend souvent. Non, il ne s’agit pas d’erreurs, mais bel et bien d’une mauvaise configuration volontaire. Ces ressources ont été ouvertes intentionnellement pour en permettre l'accès à n'importe qui.
Cela n'est évidemment pas acceptable. Ces données sont souvent très personnelles, et permettent aux escrocs, lorsqu’ils mettent la main dessus, de mener de nombreuses arnaques contre les victimes dont les informations personnelles leur sont ainsi livrées en pâture. En voici quelques exemples :
- En 2017, un service qui aide les personnes ayant des difficultés à obtenir des crédits bancaires ou des cartes de paiement a exposé les données de ses clients. Les criminels s’en sont rapidement emparés pour escroquer en série ceux dont le seul crime était de faire confiance à une entreprise censée les aider
- En 2018, le fabricant d’un système de sécurité connecté a utilisé les mêmes clés de chiffrement, stockées en dur sur chaque appareil vendu et donc accessibles à quiconque, pour protéger l’accès à son serveur de stockage AWS. L’entreprise y stockait des enregistrements en provenance des appareils. Rapidement, les criminels ont pu trouver et exploiter des informations sensibles sur les habitudes des clients de ce système de sécurité
- Plus récemment, une société d'analyse de données financières a divulgué 24 millions d'enregistrements de prêts bancaires américains. La base de données était librement accessible sur Internet, sans mot de passe. On imagine facilement combien les escrocs sont prêts à payer pour obtenir ce genre de trésor de données personnelles !
La liste pourrait continuer à l’infini. Aucune industrie n'est exclue. Des gouvernements aux fournisseurs de services, de l'industrie manufacturière à la politique, de la finance au divertissement, chaque industrie a déjà été concernée par une telle fuite de donnée « volontaire ».
« Qui veut perdre des données » n’est pas un jeu télévisé auquel l’on a envie de participer !
Mais alors comment cela peut-il arriver ? Pourquoi quelqu'un de censé compromettrait-il intentionnellement la sécurité de ses propres ressources Amazon S3 ou de ses bases de données en ligne, en les rendant accessibles au public ?
Les coupables sont rarement à chercher du côté des exploitants (les « ops »). Il semble évident que les ingénieurs réseau, les administrateurs de bases de données, les ingénieurs système et les ingénieurs sécurité ne feraient pas de telles bêtises. Voyons pourquoi :
- Les ingénieurs réseau, historiquement responsables de l'accès aux systèmes sur le réseau et chargés de déterminer quels systèmes sont visibles au public, ne permettraient pas qu'une base de données soit ainsi directement exposée
- Les administrateurs de bases de données, historiquement responsables de la gestion des accès et des comptes utilisateurs de la base, ne permettraient pas non plus l'accès aux bases de données sans authentification. Ils suivraient des politiques de mots de passe standards, avec des exigences de complexité prédéfinies par la politique de sécurité de l’entreprise (PSSI), et n'autoriseraient même pas de mots de passe faibles
- Les ingénieurs système, historiquement responsables de la gestion des applications selon les normes de durcissement définies elles aussi par la PSSI de l’entreprise, placeraient un serveur Web devant la base de données et s'assureraient qu'il est correctement protégé, notamment par un pare-feu Web (WAF)
- Les ingénieurs sécurité, enfin, procèdent depuis toujours à des évaluations régulières de tous les systèmes et du réseau pour s'assurer du respect de la fameuse politique de sécurité. Ils ne laisseraient pas passer de tels systèmes exposés librement sur Internet.
Non, la responsabilité de ces mauvaises pratiques est généralement plutôt à rechercher du côté du développement. Par exemple, les responsables du développement peuvent parfois décider de ne pas intégrer les fonctions de sécurité standards à leur produit – souvent parce qu'ils ne veulent pas perturber le business en repoussant la date de livraison du code ou parce qu’ils craignent que cela introduise de nouveaux bogues potentiels, ce qui aurait au final la même conséquence.
Mais tant que les fonctions étaient bien comprises en interne, les développeurs ne pouvaient pas aisément court-circuiter les ingénieurs réseau, sécurité ou les experts des bases de données. Souvent, d’ailleurs, à leur grand dam, car ils estimaient que les processus formels venaient à l’encontre de leur agilité.
Mais le passage au cloud vient tout changer. Il permet notamment aux développeurs de contourner les rôles informatiques traditionnels dans l'entreprise. Cela crée les conditions idéales pour que les développeurs déploient des systèmes avec des dispositifs de sécurité mal configurés, non pas parce qu'ils le veulent, mais parce qu’ils ne peuvent pas en comprendre toutes les conséquences ou qu'ils estiment qu'une brèche a peu de chances de se produire (par manque d’expérience en matière de sécurité).
Comment éviter les brèches dans le Cloud ?
Comment résoudre ce problème ? Personne ne suggère évidemment de revenir aux délais habituels pour le déploiement des systèmes (une complainte courante chez les développeurs et qui les pousse, justement, à trouver des raccourcis).
Au risque d’avoir l’air de faire l’apologie d’un buzzword, il est peut-être temps de commencer à parler du DevSecOps comme d’une véritable discipline à part entière, afin d’insuffler de bonnes pratiques de sécurité au monde du développement.
Toutes les équipes traditionnelles doivent clairement être impliquées dans ce débat. Ce n’est qu’en mettant tout le monde autour de la table que l’on s’en sortira. Car le Cloud change tout : les rapports de sécurité sont limités par défaut. Il n'y a pas d'équipe réseau ou système pour demander une liste des sous-réseaux et des listes de contrôle d'accès (ACL), ni évidemment de groupes et permissions Active Directory à vérifier…
Pour aller au-delà de ces limitations, dans la plupart des clouds publics, les entreprises doivent acheter des outils d'audit de sécurité tiers juste pour produire les rapports que l'équipe de sécurité aurait normalement obtenus aisément en interne chez leurs collègues du réseau.
Alors certes, la sécurité est difficile. Oui, la sécurité ralentit parfois les choses. Et oui, la sécurité dans le Cloud change beaucoup d’habitudes. Mais ignorer ou dégrader intentionnellement la sécurité parce qu’on ne comprend pas toutes les implications de ce "nouveau monde du Cloud", parce que c'est plus commode ou que cela accélère la livraison du code est tout simplement inacceptable.
De vraies personnes peuvent être touchées à travers leurs données personnelles, et pas seulement financièrement. Ce sont de vraies personnes, et pas seulement de vagues incarnations numériques stockées dans une base de données. Les impacts sur leurs vies après qu’une base de données de préproduction se soit retrouvée accessible à des criminels sont malheureusement bien réels, et souvent durables.
Il est donc temps d'arrêter de parler de ces expositions comme étant le résultat d'une mauvaise configuration, et de commencer à les appeler pour ce qu'elles sont : une insécurité intentionnelle et délibérée.
Plus important encore, les professionnels de la sécurité numérique doivent mieux dénoncer ces mauvaises pratiques. C’est à eux de rappeler partout et dès que possible les impacts dévastateurs d’une brèche de données sur la vie des gens.