La sécurité dans les nuages : l’interview Cloud Sec de Teddy Ferdinand
Après la revue de presse sécurité Revolve Job Zero, nous vous proposons un nouveau format régulier sur la sécurité Cloud. Dans cette série d’interviews, nous allons à la rencontre de spécialistes sécurité qui travaillent sur le Cloud pour faire un état des lieux des tendances et des pratiques : boite à outils sécurité dans le Cloud, évolutions de fond, impacts de la crise sanitaire, transformation du métier de la sécurité… Notre invité aujourd’hui est Teddy Ferdinand, Architecte Cloud, geek assumé et autodidacte de l’informatique.
Teddy travaille chez WeScale depuis 2 ans en tant que Cloud Security Architect. Il accompagne ses clients pour la mise en place de sécurité dans le cloud, et notamment sur AWS. Teddy est présent sur Twitter, il anime un blog où il écrit sur les architectures Cloud et la sécurité, et il a récemment lancé une newsletter, Les nouvelles des nuages.
Boîte à outils sécurité dans le cloud
Quels services de sécurité utilises-tu sur AWS ? Est-ce que ça change ton métier ?
L’arrivée de nouveaux services a en partie simplifié les choses. Par exemple, Amazon GuardDuty est maintenant le premier service que je déploie sur un compte. Le service scanne tout, façon Big Brother, cela ne veut pas dire que c’est la meilleure solution, mais c’est efficace. Je suis plus mitigé sur AWS Security Hub, à cause de son adhérence forte avec AWS Config qui fait vite monter la note.
Amazon Macie, AWS Security Hub, Amazon GuardDuty, Amazon Detective… tous ces services managés existent parce qu’ils répondent à de nouveaux besoins clients, induits par la matrice de responsabilité partagée. Ils répondent aux besoins d’entreprises petites et moyennes, mais passé une certaine taille, les services managés ne suffisent plus. Dans ce cas, on a besoin de solutions fédérées, centralisées, standardisées, et les services managés des Cloud providers ne sont pas forcément compatibles avec des produits externes. Les entreprises sont plus nombreuses à passer au multi cloud, et pour scanner de la même manière leurs comptes AWS, GCP, et Azure, elles doivent utiliser des solutions tierces comme InsightVM, un outil pour scanner de façon agnostique.
Pour conclure, les services managés répondent à un besoin à un instant donné, mais ils ne sont plus forcément adaptés quand l’entreprise grandit.
Quels sont tes outils de prédilection ?
Globalement, j’aime beaucoup tous les outils d’infra as code et particulièrement les outils Hashicorp : Vagrant, Terraform, Vault, tous leurs outils sont utiles et j’apprécie leur posture. J’ai eu un coup de cœur pour Ansible : pour ceux qui comme moi ne sont pas développeurs, Ansible a beaucoup simplifié les choses.
Ensuite, les outils classiques comme GitLab CI ou Jenkins, qui permettent de simplifier, standardiser, et rendre les choses reproductibles.
En termes de sécurité, comme beaucoup j’apprécie Metasploit, c’est la toolbox de base. Enfin je suis content de voir qu’on a de plus en plus de distributions Linux orientées sécurité, comme Parrot OS, Kaisen Linux, Kali Linux, qui permettent de mettre en place la sécurité plus facilement, et de l’apporter au plus grand nombre.
Les évolutions de fond de la sécurité
Quels sont les défis de la sécurité sur le Cloud ?
Ils sont multiples, mais je commencerai par citer IAM, car on délègue une grosse partie des autorisations sur une plateforme externe où on ne maîtrise pas tout, avec des IAM parfois fluctuants. Ensuite, il s’agit de Cloud public, donc les ressources peuvent être accessibles, et ces expositions apportent de nouveaux risques. Avant, dans un datacenter où tout était verrouillé avec des firewall, on savait ce qui était exposé. Aujourd’hui ce n’est plus toujours le cas, on a un risque d’exposition indirecte via les API, et si l’IAM est mal sécurisé, on peut se trouver avec des ressources exposées. Il arrive malheureusement très souvent que des comptes soient ainsi utilisés pour faire du cryptomining.
Le Cloud permet aussi d’aller beaucoup plus vite, et c’est un plus pour le modèle agile, on peut répondre rapidement à des nouveaux besoins, à des montées en charge. En contrepartie, le risque est de prendre des raccourcis, et de livrer plus vite des choses non sécurisées. Aller vite c’est bien, mais il faut pouvoir mettre en place des garde-fous pour éviter d’avoir des machines exposées sur Internet. En moyenne, une machine ainsi exposée tombe en moins de 4 mn !
Enfin, le modèle partagé de sécurité avec les providers fait qu’on a pu se décharger de certaines tâches, comme l’accès au datacenter. Le cloud a déplacé la charge, on gère encore beaucoup de sujets, mais ce ne sont plus les mêmes.
Est-ce que le cloud est un accélérateur ou il apporte uniquement des risques ?
Je dirai qu’il y a un peu des deux, le Cloud apporte l’avantage de pouvoir disposer de ressources en quelques minutes, c’est un énorme progrès par rapport à l’époque où commander une machine prenait 6 mois. On peut tester plus vite de nouveaux projets, cloner des environnements, ou faire des PRA très facilement. Et grâce à l’infra as code, on peut reproduire, versionner, et vérifier. Mais cela crée aussi de nouveaux risques. Ce code doit être scanné, il faut vérifier qu’il est compliant, mettre en place des règles, et scanner les comptes Cloud avec des services comme Amazon GuardDuty pour détecter les comportements anormaux.
Est-ce que le passage sur le Cloud a changé la façon dont on considère la sécurité ?
Plus que le Cloud, c’est l’infra as code qui a fait bouger les choses. L’avantage de l’infra as code est de pouvoir exposer très facilement ce qu’on va faire, et cela a permis la mise en place d’outils comme open policy agent, TFLint, cfn nag, des outils qui scannent le code en amont pour prévenir les risques.
Le code produit est scannable, auditable, versionable et avec des process type GitOps, il peut être scanné à chaque étape, avant même d’être déployé. Le passage à l’infra as code a permis à la sécurité de s’implanter au cœur des projets. Avant, la sécurité était dans une tour d’ivoire, et le plus souvent arrivait en fin de projet pour tout bloquer. Maintenant, on devient des partenaires du projet, nous pouvons aider et accompagner dès son lancement, proposer des étapes pour faire les choses correctement tout au long du cycle de vie du projet. Cela ne veut pas dire que c’est parfait, mais c’est mieux ! L’infra as code permet aussi de s’assurer que les règles mises en place sont respectées.
Globalement, nous sommes maintenant plus proches du métier, et cela nous aide à mieux comprendre les enjeux business et les contraintes opérationnelles. Il est parfois nécessaire de faire des exceptions, et avoir conscience qu’on ne peut pas avoir 100% de couverture partout : pour livrer une fonctionnalité, on peut s’autoriser à ne pas être compliant pendant quelques jours. C’est devenu possible car la sécurité est plus proche des projets, et parce que la mentalité a changé, les équipes DevOps savent aussi faire de la sécurité.
Les changements récents
Comment s’est passée la mise en place du travail à distance lors de la crise sanitaire ?
Comme de nombreuses entreprises, mon client a subi le premier confinement. Les infrastructures n’étaient pas dimensionnées pour supporter 2000 personnes à distance du jour au lendemain, au mieux elles pouvaient tenir ponctuellement 10% de cette charge. Nous avons donc construit dans l’urgence de nouvelles infrastructures, nous avons aussi adapté les règles réseau, déployé des VPN et des proxy, etc. Nous avons utilisé un proxy dans le Cloud pour fédérer à distance les utilisateurs, comme s’ils étaient dans l’entreprise, de façon à garder le contrôle sur les flux réseaux et les accès, et éviter que le travail à distance ne se transforme en une énorme faille de sécurité.
Nous avons fait le choix de créer une nouvelle entrée sécurisée, avec VPN et proxy, et de sécuriser les postes avec des outils EDR pour attester que c’est bien le poste client qui est connecté. Nous avons aussi mis en place des licences supplémentaires sur Google Meet, et les utilisateurs ont appris à bien exploiter Slack. Aujourd’hui le travail à distance se fait de façon fluide, sans impact sur le quotidien.
Généraliser le travail à distance suppose aussi un accompagnement sur les bonnes pratiques : comment travailler de façon sécurisée à l’extérieur, comprendre que tous les réseaux ne sont pas sécurisés, savoir comment travailler dans un train avec un filtre écran et un MDP sécurisé, etc. Pour sécuriser le télétravail, il faut prendre de nouvelles habitudes et s’adapter à l’environnement, qu’il soit public ou privé. Tout cela s’est fait très rapidement mais les utilisateurs ont rapidement compris les problématiques de sécurité, ils ont maintenant le réflexe de comprendre pourquoi il y a des blocages, et ils viennent nous solliciter pour demander conseil. On s’est habitué à travailler comme on le souhaite, à distance, mais en suivant des règles pour ne pas mettre en péril l’entreprise.
La transformation du métier de la sécurité
Le manque de femmes dans la cybersécurité, qu’en penses-tu ?
C’est un vrai débat, et un problème dans l’IT en général. J’ai écrit un article sur mon blog à ce sujet, je pense que ce problème commence dès le collège/lycée, où on persuade les élèves que l’IT est un monde d’homme. Ce qui compte, c’est la qualité du travail fourni, pas le genre ou l’orientation sexuelle. J’ai travaillé avec des ingénieures auprès de qui j’ai beaucoup appris, et je déplore qu’il y ait si peu de femmes dans les métiers techniques. Elles sont plus nombreuses côté gestion de projet, mais nous devons faire comprendre aux plus jeunes que les métiers techniques ne sont pas réservés aux hommes. L’IT est ouvert à toutes et à tous, nous avons la chance d’avoir des métiers très riches, avec de nombreuses spécialisations. Avoir un pénis ne permet pas de mieux taper au clavier !
La souveraineté des données, c’est un vrai sujet ?
C’est une question qui suscite de l’inquiétude, chez les clients comme chez les utilisateurs. Tout le monde veut savoir où sont ses données, mais au-delà du fait de savoir où elles sont stockées, je pense que la question sous-jacente est de savoir s’il faut aider les entreprises à ne pas utiliser des solutions françaises. Le fait d’être soumis au Cloud Act inquiète beaucoup, mais je pense que dans 99% des cas, les providers n’ont pas d’intérêt à accéder à vos données. Les entreprises doivent cependant adopter de nouveaux réflexes comme le chiffrement. Tout stockage dans le cloud se fait avec une clé de chiffrement, un disque dur sur un VM doit être chiffré.
Dans ce contexte, que penses-tu des initiatives autour du Cloud de confiance et SecNumCloud ?
Les GAFAM seront de toute façon gagnants, car dans tous les cas le backend sera chez eux. Le cœur du problème, ce ne sont pas les données, mais le fait de contribuer à enrichir des entreprises extra territoriales qui font de l’optimisation fiscale. Une solution GCP fournie par Thalès ne donne pas de contrôle sur la solution logicielle qui reste américaine. Et ce ne sont pas les certifications complexes qui vont protéger les entreprises françaises. Par exemple, la certification PCI-DSS est très compliquée à obtenir pour une entreprise à taille humaine, mais les GAFAM ont la force de frappe nécessaire, ils ont des experts dédiés à ces sujets, ce qui leur permet de ne pas se soucier des normes complexes.
C’est ce qui m’inquiète avec la norme SecNumCloud, elle n’exclut que les petites sociétés comme Platform.sh. Il y a de nombreuses petites structures qui auraient leur place, mais qui n’ont pas la puissance nécessaire pour être certifiées Cloud de confiance. On essaie d’adresser par la question de la réglementation un terrain technologique qu’on a perdu. On devient des fournisseurs de services, là où la France pourrait être un véritable acteur de l’IT. C’est d’autant plus dommage que nous avons les compétences. Sur l’open source, par exemple, les français sont bons. Traefik affiche plusieurs millions de téléchargements. Avec l’open source, on aurait le moyen de se réapproprier indirectement toute la partie software sur laquelle on a perdu la main.