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 David Chapdelaine, Cloud Security Engineer pour une place de marché de C to C au Japon.

Professionnel de l’IT depuis plus de 20 ans, David Chapdelaine a quinze ans d’expérience dans la sécurité. Originaire du Québec, il est parti au Japon en 2009 pour y poursuivre son activité professionnelle. Il occupe depuis 3 ans le poste de Cloud Security Engineer chez Mercari, une place de marché C to C qui permet d’acheter et de vendre ses objets sur web ou mobile, avec en plus des fonctionnalités de paiement sans contact chez les commerçants.

Boîte à outils sécurité dans le Cloud

A quelles problématiques répondent vos choix d’outils ?

Nous sommes essentiellement sur Google Cloud Platform,  et nous avons environ 500 microservices dédiés au produit, tous hébergés sur un cluster Kubernetes. C’est une infrastructure très axée sur les conteneurs, donc nous avons beaucoup d’outils dédiés à la sécurité des conteneurs : sécurisation de l’environnement présent sur l’image, des librairies, des configurations par défaut ou du runtime. Nous nous assurons qu’il n’y ait pas de faille, pas de possibilité de sortir du conteneur pour aller sur les nodes du cluster.

L’entreprise a une forte culture d’ingénieurs, nous avons près de 300 ingénieurs qui travaillent sur le produit, donc nous devons trouver un équilibre, en leur donnant assez de latitude pour faire leur travail, tout en gardant la maîtrise de la sécurité du cluster. Au niveau des outils utilisés, les points les plus importants pour nous sont donc la sécurité du cluster et des conteneurs, et tout ce qui est en lien avec la livraison et les pipelines de CI/CD.

Utilisez-vous les outils de sécurité managés Google, des outils tiers ou open source ?

Nous utilisons beaucoup de services de Google comme Security Command Center, qui nous permet d’avoir une visibilité sur tout l’infrastructure gérée sur Google. Une partie de mon travail est aussi de créer des outils, notamment en utilisant des produits Open Source que nous améliorons en ajoutant des fonctionnalités. Nous avons environ 50% d’outils faits maison. D’une manière générale, tous les produits développés et livrés en interne par l’équipe sécurité sont faits en serverless (Cloud Run, Cloud Functions).

Comment cette boîte à outils répond à vos besoins ? Est-ce qu’il y a des outils qui manquent ?

L’outillage est toujours un amalgame de différents produits qu’on essaie de joindre ensemble pour avoir le résultat qui convient à l’entreprise. Actuellement il n’y a pas de solution out of the box qui puisse s’appliquer à notre façon de travailler. Nous utilisons GitHub pour héberger le code source, des applications GitHub apps pour auditer le code statique, vérifier les dépendances, les librairies, suivre les patchs à appliquer, s’assurer qu’aucun test n’est brisé par la mise à jour des librairies. Tout notre pipeline est un assemblage de différents produits commerciaux, open-source et aussi que nous créons, ou modifions.

C’est un avantage ou un inconvénient ? Est-ce que cela apporte plus de souplesse mais aussi plus de complexité de gestion ?

Notre cas est peut-être particulier, l’entreprise a une forte culture d’ingénieur, donc nous avons la capacité et la connaissance pour faire fonctionner le tout. On a par exemple beaucoup utilisé de solutions du marché, déployées sur notre cluster, mais quand nous sommes confrontés au besoin de faire des modifications, on revient sur la version open source pour ajouter les fonctionnalités dont nous avons besoin, créer notre propre agent, faire le wrapping, et le connecter à nos API.

Les évolutions de fond de la sécurité

La généralisation de l’infra as code a-t-elle amené plus de code dans les métiers de la sécurité ?

Nous avons une équipe SRE dont la mission est de créer la plateforme pour les ingénieurs. Pour cela, nous utilisons essentiellement Terraform (nous gérons environ 1000 Terraform states). Nous poussons pour le “zero touch production” : tout changement sur le Cloud doit se faire avec Terraform.

Donc oui, programmer fait partie du périmètre de la sécurité, ainsi que de proposer des solutions développées avec l’équipe SRE pour améliorer le pipeline CI/CD, ou la sécurité et l’observabilité de notre plateforme Cloud. Nous avons ainsi créé notre propre plateforme de surveillance qui est hébergée sur Google Cloud. Nous utilisons un système de  pub/sub pour recevoir le flot de logs, et avec des solutions open source tel que Open Policy Agent, nous avons écrit des sets de règles pour suivre les changements faits en production, détecter des anomalies, et enfin automatiser les réponses aux alertes par communication avec les APIs cloud. Sur GitHub, tout changement se fait par le code, ça passe par une peer review, un pipeline avec les plus bas niveaux de privilèges possibles et des clés temporaires. Tout cela est géré par un processus alimenté par Git. Par exemple, si quelqu’un avec des privilèges admin fait des changements qui vont à l’encontre de ce qui est défini sur Terraform, on est prévenu en temps réel via le stream.

Quels sont les principaux challenges de sécurité sur le Cloud ?

C’est vraiment la partie livraison et la supply chain (CI/CD). Tout changement, toute modification arrive par la pipeline CI/CD, et notre expérience des incidents montre que les attaquants se déplacent sur cette partie. C’est un vrai challenge, et nous avons eu l’an passé un gros incident de sécurité qui nous a poussé à aller plus loin dans notre couverture de cette partie. L’observabilité est un challenge aussi : il y a tellement de ressources, donner à l’équipe sécurité une vision d’ensemble devient un vrai enjeu. Nous devons pouvoir suivre tous les changements en production, avoir la bonne visibilité, et la définir pour qu’elle soit automatisée.

Est-ce que la montée en puissance des services managés soulage d’une part du travail ?

Pas tellement, on utilise des services comme GuardDuty, mais il reste toujours à gérer la remédiation automatique, c’est une partie important du travail. On pourrait parler de “security automation”. Notre système se connecte aux services de sécurité des cloud providers, comme GuardDuty ou Security Command Center, avec un système de pub/sub, et nous avons développé des fonctions qui font de l’auto remédiation. C’est quelque chose qui n’est pas encore disponible chez les Cloud providers.

Les changements récents

Quel a été l’impact de la crise sanitaire sur ton métier ?

Toute l’entreprise est passée au télétravail en mars 2020, et c’est toujours le cas actuellement. Deux années de télétravail ont amené de nombreux changements dans les méthodes de travail, et nous évoluons vers le VDI. Nous testons actuellement Amazon Appstream pour fournir à nos utilisateurs des environnements desktop et permettre d’accéder aux données confidentielles de façon sécurisée. Dans un premier temps, nous avons mis en place un VPN, mais l’idée c’est d’aller vers un environnement déporté “beyond corp”.

L’entreprise était déjà axée sur les services SaaS avant la crise : solutions d’authentification, boites mail, partage de fichiers, tout cela était déjà sur le cloud, donc faire la transition vers le travail à distance n’a pas généré beaucoup de problèmes. Cela nous a quand même demandé de revoir la façon de penser la sécurité. Quand les gens étaient au bureau, nous avions des règles basées sur les adresses IP et les firewalls, ce qui n’était plus possible en travail à distance. Nous étudions actuellement Tailscale, un système de type Wireguard, qui déploie un réseau VPN mesh sans avoir besoin de endpoints VPN. Les agents Tailscale sont hébergés soit sur le cluster, soit sur l’infrastructure cloud, pour ensuite se connecter directement sur chaque service.

La souveraineté des données, c’est un sujet ?

A l’échelle de notre entreprise, il n’y pas vraiment d’impact de ce sujet. Nous avons juste eu à gérer le cas de collaborateurs qui, durant la crise Covid,  étaient bloqués dans des pays définis comme moins amicaux et dont l’accès à certaines données devait être restreint pour cette raison. Nous travaillons toujours sur ce sujet, à savoir comment devenir une entreprise globale tout en gérant ce type d’enjeux grâce aux solutions VDI. Cependant il n’y a pas d’enjeu de souveraineté des données vis-à-vis des providers américains, c’est plutôt avec la Chine que le sujet est sensible. Il y a eu récemment au Japon le cas d’une entreprise dont les données clients étaient envoyées en Chine, et ça a fait pas mal de bruit.

La transformation du métier de la sécurité

Quelle est la place des femmes dans l’IT et la cybersecurité au Japon ?

Dans l’équipe security engineering, il y a actuellement une seule femme. Côté securité management et risques, on est plus proche des 50%. Plus globalement au Japon, nous avons beaucoup de retard sur l’Europe et les Etats-Unis.  Au sein de l’équipe technique, sur 25 personnes, il y a seulement 3 japonais. Il est déjà très difficile de trouver des candidats côté cloud /sécurité au Japon, on est obligés de recruter à l’extérieur, donc à plus forte raison, des femmes. 

Le cloud est-il un accélérateur de sécurité, ou un vecteur de nouveaux problèmes ?

Je dirai un peu les deux. Définitivement le cloud a compliqué l’enjeu, il a élargi la surface d’attaque. On premise, on était sur une sécurité très physique, avec des mécaniques bien connues, maintenant tout est axé sur les API, nous avons besoin de maintenir une communication entre différents systèmes qui sont complètement externes : Github qui doit avoir accès à la CI/CD via Circle CI, puis au Cloud… Les services se multiplient, et tous doivent interagir ensemble. Authentifier, fédérer, échanger les clés et les secrets tout en gardant une vision globale sur l’ensemble, ça complique la mise.

D’un autre côté, le Cloud a amené beaucoup plus d’échanges avec l’équipe DevOps. Sécurité et DevOps, l’un ne va pas sans l’autre, cette complexité fait que tout doit être automatisé, et pour cela il faut collaborer complètement avec l’équipe DevOps et les services qu’ils fournissent.