Quelle est la meilleure façon de protéger les serveurs dans le Cloud ? Comment gérer leur nature éphémère et fournir la même protection dans le cloud que sur site ? Pour le savoir, InfoQ s'est entretenu avec Mark Nunnikhoven, ingénieur principal dans la division Cloud & Technologies Émergentes de Trend Micro. Vous pouvez trouver Mark sur Twitter : @marknca.
InfoQ : Sur quels points la "sécurité dans le cloud" est plus mature ou moins mature que ce que nous faisons dans les data centers locaux ?
L'approche de la sécurité en data center est assez mature. Il y a quelques éléments de conception basiques qui peuvent être manipulés pour remplir les besoins spécifiques. La plupart des data centers ont un périmètre défini, un inventaire qui grossit peu et des processus clairement définis mis en place pour faciliter les changements. Le point clé dans cet espace est le contrôle de l'environnement dans son entier.
Dans un modèle "Cloud", et encore plus dans les clouds publics, il y a beaucoup plus de flexibilité. Une approche de la sécurité différente est essentielle parce que les utilisateurs et les fournisseurs de cloud partagent la responsabilité de la sécurité. Il est essentiel de prendre du recul et de regarder en quels aspects du déploiement vous avez confiance, et à quel point. Il y a une absence décidée de mise en vigueur centralisée des contrôles de sécurité. La sécurité peut quand-même être gérée de manière centralisée en utilisant un produit comme Deep Security, mais sa mise en vigueur est éparpillée entre vos ressources informatiques.
Nous explorons toujours quelles approches fonctionnent pour quels scénarios dans le cloud, et c'est le changement majeur. Dans le data center, votre application est cantonnée dans un paradigme de protection spécifique. Dans le cloud, c'est l'inverse. Votre paradigme de sécurité s'adapte aux spécificités de votre application.
InfoQ : Comment l'idée du cryptage distribué dans le cloud change-t-elle au regard des problématiques d'espionnage ? Est-ce que les clients ont besoin d'un contrôle total sur les clés?
Les révélations récentes au public concernant le degré d'espionnage auquel il est soumis ont assurément augmenté la prise de conscience sur les sujets relatifs à la gestion des clés de cryptage. Cette question est posée de plus en plus souvent, mais malheureusement la réponse est unique pour chaque situation, parce qu'il y a énormément de facteurs en jeu.
D'une perspective haut-niveau, les entreprises suivent les lois du (ou des) pays dans le(s)quel(s) elles opèrent, et si vos clés et données sont sous la même juridiction, il n'est pas difficile pour un tiers ayant des ressources suffisantes d'obtenir les deux. D'après moi, il est préférable d'avoir ses données et clés sous des juridictions différentes. C'est à la fois un challenge technique et légal de maintenir le contrôle de vos informations.
InfoQ : Qu'est-ce que Trend Micro - et d'autres dans ce domaine - ajoutent aux capacités de sécurisation du cloud basiques ? Qui pourrait se contenter de l'offre "clé en main" d'AWS ?
Selon moi, on ne peux pas se contenter de l'expérience "clé en main" d'AWS. AWS eux-même opèrent selon un modèle de responsabilité partagée. Ils fournissent une sécurisation de première classe jusqu'au niveau du système d'exploitation. Après ça, c'est la responsabilité du client de fournir la sécurité.
AWS fournit des outils comme IAM, les groupes de sécurité et les ACLs de réseau pour aider, mais vous avez quand-même besoin de comprendre comment ils fonctionnent. Une application qui accepte des envois de fichiers est un exemple simple. Vous pouvez configurer tous les outils qu'AWS fournit et votre application va quand-même courir un risque dans le sens où des utilisateurs peuvent potentiellement envoyer un fichier malicieux ou accidentellement dangereux.
InfoQ : Comment des produits comme l'offre Deep Security de Trend Micro aident dans des scénarios de cloud hybride ?
Un scénario de cloud hybride est une division de vos ressources informatiques ; que ce soit une instance AWS, une machine virtuelle ou votre ordinateur physique. Le défi est que chaque fournisseur et chaque environnement a un profil de sécurité différent.
Est-ce que le firewall de votre data center de secours est configuré de la même manière que celui de votre data center primaire ? Et vos groupes de sécurité AWS ? Azure ? Rackspace ? Il y a une quantité significative d'efforts à fournir pour s'assurer que vous appliquez vos politiques de sécurité de manière uniforme.
Deep Security résoud ce défi en centralisant la gestion et la mise en application de vos politiques de sécurité. Définissez-les une seule fois, quelle que soit la localisation de l'agent, et le même niveau de sécurité est appliqué partout.
InfoQ : Comment gérez-vous la nature éphémère des serveurs dans le cloud, qui peuvent être en ligne à une heure donnée et hors-ligne la suivante ? Est-ce que ça rend la sécurisation et le traçage plus difficiles ?
La nature éphémère d'un serveur dans le cloud rend les choses plus difficiles à tracer. La plupart des outils de sécurité n'ont pas été développés dans la perspective d'un serveur n'existant que pendant 15 minutes. Ce défi cependant n'est pas difficile à surmonter. En tant qu'industrie, nous devons approcher le problème selon un angle différent de celui auquel nous sommes habitués.
Une bonne approche du problème est celle que nous avons adoptée avec Deep Security. Nos technologies de connecteurs cloud traquent automatiquement vos instances AWS comme elles viennent, sans intervention requise. Une fois qu'une instance est détruite, elle est retirée de votre inventaire actif dans Deep Security. Vous maintenez toujours une piste d'audit complète, mais l'instance n'apparaîtra pas comme "manquante" comme elle le ferait dans des outils plus traditionnels.
InfoQ : Est-ce que les agents de serveurs dans le cloud se comportent différemment de ceux des serveurs sur site ? Ou bien s'attend-on à ce qu'ils s'exécutent quel que soit l'environnement ?
Nous ne voyons pas une grosse différence dans le comportement des agents de serveur dans le cloud comparé aux agents sur site. DeepSecurity et SecureCloud (notre produit de cryptage) ont été construits pour fonctionner dans des environnements massivement virtualisés qui démontrent beaucoup de comportements similaires aux clouds publics.
Avec une conception solide de la communication agent-manager, vous ne devriez pas voir beaucoup de différence.
InfoQ : Comment les agents travaillent-ils avec la nouvelle classe de frameworks basés sur les conteneurs (LXC, Docker, Warden) qui tournent sous Linux ? Il y a un focus plus fort sur la virtualisation des applications plutôt que les serveurs entiers. Comment la sécurité du cloud change-t-elle pour accommoder cela ?
C'est une excellente question. Il y a beaucoup d'excitation autour de la "conteneurisation" en ce moment, et à raison. Les agents continuent de jouer un rôle ici et sont la meilleure solution aujourd'hui. Ces conteneurs s'exécutent tout de même sur un système d'exploitation, ils cachent juste ce niveau à l'application.
Je pense que c'est juste un autre exemple qui pousse la sécurité plus bas dans la pile. Avec les déploiements dans le cloud public, nous savons que beaucoup de clients ne sont pas très engagés dans la sécurité. Ils veulent un fort niveau de protection derrière leurs déploiements, mais juste interagir avec quand il y a un problème qui ne peut être résolu automatiquement.
En ce qui concerne les conteneurs, je pense que nous verrons une tendance à introduire la sécurité dans les primitives du conteneur. Le conteneur sera capable de dire "j'ai besoin des types de protection suivants" et la plate-forme exécutant l'agent s'adaptera pour les fournir.
InfoQ : Est-ce qu'on a besoin d'une reconnaissance des applications de telle manière à ce qu'un port de firewall soit ouvert à une app mais pas à une autre ?
Si vous m'aviez posé cette question il y a deux ans, j'aurais répondu "oui" sans équivoque, mais aujourd'hui je n'en suis plus si sûr. C'est une excellente capacité à avoir, et elle peut assurément trouver un usage, mais nous voyons de plus en plus de systèmes mono-application et ce n'est donc plus un pré-requis aussi urgent.
Dans un scénario de conteneur comme celui dont nous avons précédemment discuté, le contexte "par conteneur" sera clé, mais dans les environnements de cloud public d'aujourd'hui il est plus probable que nous voyions des instances séparées pour chaque application.
InfoQ : Est-ce qu'une capacité de "mise à jour automatique" est cruciale pour les produits qui vont sur des serveurs dans le cloud ?
Absolument. La plus grosse pression que nous ayons vue dans le cloud concerne la sécurité complètement automatisée. Avec des applications à la scalabilité élastique, à la demande, les utilisateurs ne peuvent pas se permettre de mettre à jour les logiciels manuellement. Les utilisateurs ont besoin de pouvoir simplement définir le besoin pour un produit particulier et l'avoir toujours à jour.
Un bon exemple concret est l'approche que nous avons prise avec l'Agent Deep Security. Bien sûr vous pouvez pré-installer celui-ci dans votre image et l'activer chaque fois que vous lancez une nouvelle instance. Vous pouvez même le mettre à jour depuis le gestionnaire. Mais c'est beaucoup plus efficace de l'installer et l'activer à la volée quand une nouvelle instance se lance.
A propos de l'interviewé
Mark Nunnikhoven est ingénieur principal du département Cloud & Technologies Emergentes de Trend Micro. Il travaille avec le groupe R&D pour tout ce qui concerne la recherche et l'innovation de la sécurité du cloud et les systèmes de sécurité utilisables. Il apporte plus de 15 ans d'expérience forgée dans un large éventail de postes IT, de la fourniture de service au développement d'applications en passant par l'ingénierie de la sécurité, jusqu'à à son activité chez Trend Micro. Mark est un membre actif de l'IEEE et du Consortium of Digital Forensics Specialists (CDFS), et possède un certain nombre de certifications en sécurité ainsi qu'un master (MSc) en sécurité de l'information, avec une spécialisation dans l'expertise judiciaire informatique (digital forensics). Vous pouvez suivre Mark sur Twitter @marknca.