AWS re:Inforce, la sécurité au coeur du Cloud

Temps de lecture : 5 minutes

Si la sécurité du Cloud a toujours fait partie de l’agenda d’AWS, le sujet bénéficie maintenant d’un événement dédié. AWS re:Inforce est un nouveau rendez-vous proposé par AWS pour réunir les professionnels de la sécurité et du Cloud, et faire progresser les bonnes pratiques associées. Que retenir de cet événement ? Plutôt que d’énumérer une longue liste services sécurité, toujours croissante, nous avons préféré nous concentrer sur l’analyse des messages clés délivrés lors de la keynote par Steve Schmidt, VP & CISO AWS, et les représentants des 2 clients AWS, Liberty Mutual et Capital One.

En synthèse : comme souvent, l’enjeu n’est pas tant technologique que culturel.

Learning, behavior, features” : le point de départ de la sécurité dans le Cloud, c’est l’apprentissage. Seule la formation permet de faire évoluer les comportements, et les fonctionnalités viennent en complément de ce changement d’état d’esprit. Ce message était vrai il y a quelques années, il le sera encore dans cinq ans, car si les fonctionnalités changent, l’état d’esprit doit rester le même.

Apprentissage

“Expliquez à vos développeurs où ils ont fait des erreurs, aidez-les à se prémunir de ces erreurs à l’avenir, car aucun outil n’est parfait” 

La sécurité ne concerne pas que les acteurs de la sécurité, et le premier enjeu est de former les développeurs aux concepts de sécurité. Les outils ne sont pas parfaits, et ne le seront jamais, et c’est pour cela que l’apprentissage est nécessaire. On ne peut pas compter que sur l’outil, c’est l’humain qui le rend efficace en le complétant. Ce message est aussi appuyé par Liberty Mutual, pour qui la sécurité doit également se former aux métiers des développeurs.

Comportement

“Le plus important pour l’industrie de la sécurité est de créer un comportement sécurité chez chaque collaborateur”

La sécurité est l’affaire de tous et chaque acteur de l’IT doit intégrer les enjeux de sécurité à son niveau. Il y a donc un travail d’évangélisation à mener pour changer l’état d’esprit et faire en sorte que chacun adopte des réflexes sécurité et applique les bonnes pratiques. Concrètement, comment faire? Là aussi, nous rejoignons complètement Steve Schmidt quand il affirme que l’automatisation des contrôles et de l’alerting est critique. Mais il faut aussi savoir faire preuve de flexibilité, et proposer des mesures de sécurité qui répondent aux besoins de projets et cas concrets ; plutôt que de définir des modèles de sécurité “hors sol”, qui cherchent à répondre à des enjeux trop génériques ou auxquels l’organisation n’est pas encore confrontée.

Pour terminer sur ce point, Steve Schmidt a mentionné ne pas aimer le terme DevSecOps, qu’il juge trop marketing voire contre-productif. De son point de vue, que nous partageons, tout comme le DevOps, le DevSecOps est un état d’esprit qui décrit la façon dont fonctionnent les opérations et non un poste. Si, dans un premier temps, les organisations peuvent éprouver le besoin de positionner un référent sécurité au sein des équipes IT pour porter ce changement et aider à diffuser la culture sécurité au sein du devops, ce n’est pas une fin en soi. Sous peine de reproduire l’approche sécurité “en silo” au coeur même de la production.

Les fonctionnalités

10% des offres sur le marketplace concernent la sécurité, et AWS propose plus de 210 services et fonctionnalités autour de la sécurité. Au delà des chiffres, il faut surtout retenir que la sécurité sur le Cloud peut et doit s’opérer avec les outils du Cloud. Les fournisseurs cloud, comme AWS, ont bien compris l’intérêt de proposer des services sécurité managés, qui bénéficient donc du double avantage d’être facilement automatisables et intégrables avec toutes les autres fonctionnalités du cloud.

A ce titre, on retiendra d’ailleurs en complément les annonces faites autour de nouveaux services managés de sécurité :

  • AWS Security Hub en General availability : le service permet de consolider les remontées des différents services de sécurité et outils, pour créer une base de “security findings” et ainsi améliorer la visibilité, le reporting et le process de remédiation des non-conformités, vulnérabilités et incidents de sécurité.
  • AWS Control Tower en General availability : dans un environnement multi-comptes, ce service permet de créer des baselines intégrant par défaut les bonnes pratiques de sécurité configurables à travers les services AWS Organizations, AWS IAM, AWS Config, AWS CloudTrail, AWS Service Catalog…
  • VPC Traffic Mirroring : ce service permet de capturer et rediriger trafic réseau vers des outils d’analyse à des fins de troubleshooting et d’analyses opérationnelles
  • Le marketplace est maintenant intégré à des systèmes d’achat Coupa (et à terme tous les systèmes utilisant le protocole cXML), ce qui facilitera le contrôle de coûts et la centralisation des services tiers, dont ceux de sécurité
  • Chiffrement : les nouveaux espaces de stockage EBS sont maintenant chiffrés par défaut. Au delà de cette annonce, AWS a mis en avant sa capacité à assurer un système de chiffrement à tous les niveaux, aussi bien entre les backbones internationaux, les centres de données que les machines virtuelles
  • AWS Certificate manager : ce service permet de disposer d’une autorité racine de gestion des certificats intégrée au Cloud et ainsi de s’exonérer du recours à une autorités de certification racines externe

Pour aller plus loin : la sécurité à l’échelle

Pour terminer, Steve Schmidt a soulevé la question de la sécurité à l’échelle. Comment sécuriser un environnement AWS qui grandit chaque jour ? Réponse, en appliquant à la sécurité les principes propres au développement cloud, donc en se reposant sur le code et le serverless. Le machine learning est également un sujet à suivre pour améliorer la détection. Idem pour les concepts de raisonnements automatisés et de preuve formelle de sécurité : quand on a plusieurs patterns de sécurité, il faut pouvoir juger l’ensemble, voir comment les patterns se situent les uns par rapport aux autres, si l’un est plus faible que l’autre, et si globalement on n’a pas créé de faille. Sur ce point, on s’appuiera sur Zelkova et Tiros, deux outils encore en preview.

Ceci conclut notre retour sur cette première édition de re:Inforce. Il s’agit d’un avis personnel et totalement subjectif, et je serais très curieuse de connaître votre avis sur ces sujets. D’accord, pas d’accord ? Commentez et partagez avec nous les sujets qui vous ont le plus intéressé !

Commentaires :

A lire également sur le sujet :