Les 4 phases de l'automatisation de la gestion du cloud

Le parcours d'automatisation du cloud d'un professionnel de la sécurité

Si vous me croisez lors d'une conférence, vous m'entendrez probablement dire que « la sécurité du cloud commence par l'architecture et se termine par l'automatisation ». J'enchaîne aussitôt sur l'importance d'adopter un état d'esprit cloud native, même lorsque l'on est enlisé dans la réalité d'un pénible lift and shift avant l'échéance du contrat de centre de données et l'extinction des lumières. La formule est plaisante, mais elle ne dit rien de la manière dont je suis passé du statut de professionnel de la sécurité classique (pare-feux et gestion des correctifs) à celui d'adepte de l'architecture et de l'automatisation cloud native. Plutôt que de prêcher du haut de ma chaire, il me semble plus utile de décrire mon parcours personnel et les prises de conscience techniques qui l'ont jalonné. Si vous êtes un professionnel de la sécurité, ou si vous cherchez à faire monter en compétences un professionnel de la sécurité sur le cloud, vous emprunterez très probablement un chemin très similaire.

Phase 1 : automatiser les configurations

Pour ma part, tout a commencé il y a environ neuf ans, lorsqu'on m'a demandé de concevoir le premier programme de formation de la Cloud Security Alliance. J'ai rapidement compris qu'il nous fallait des laboratoires reproductibles, exécutables partout dans le monde, avec des étudiants et des formateurs dont les compétences allaient du « développeur » à l'« auditeur gratte-papier ». À cette époque, Amazon Web Services n'avait pas encore véritablement déployé IAM et les VPC étaient uniquement des réseaux privés. Et des concepts comme l'Infrastructure as Code commençaient tout juste à devenir réalisables.

Je me retrouvais donc à chercher comment construire dans le cloud un laboratoire pratique de pile applicative pour des milliers d'étudiants. De façon cohérente, *et* avec la possibilité de le mettre à jour au fur et à mesure des avancées technologiques d'AWS. À l'époque, créer ses propres AMI restait une corvée, mais j'ai alors découvert les merveilles de `cloud-init`. Un simple script que je pouvais héberger dans un bucket S3, avec deux courtes lignes que les étudiants collaient dans le champ User Data de leurs instances, ce qui configurait celles-ci exactement comme il le fallait au démarrage. Et quand les mises à jour logicielles cassaient quelque chose, il me suffisait de modifier ce script à l'URL publiée pour que chaque nouvelle instance utilise la nouvelle configuration — magique ! Si cela n'aidait en rien pour appliquer des correctifs à ce qui tournait déjà, cela me permettait de garantir une bonne expérience au premier lancement, bien plus facilement qu'en mettant à jour et en publiant de nouvelles AMI. Et, par pure imprudence pour ma réputation, vous pouvez toujours en consulter une version ultérieure ici sur S3.

Ma première étape a été `cloud-init`. Ce n'est plus un outil que j'utilise, mais ce fut une révélation de pouvoir scripter un serveur entier et de le voir s'exécuter intégralement, à partir d'un copier-coller et d'un unique fichier hébergé.

Phase 2 : automatiser les flux de travail

Mais l'étape suivante a eu bien plus d'impact. Après quelques années de formations pratiques et de développement de mes propres charges de travail, j'ai commencé à explorer l'idée de la Software Defined Security. J'avais devant moi une corne d'abondance d'API cloud qui me murmuraient toutes « appelle-moi » à l'oreille. J'ai cherché des exemples et je n'ai trouvé… rien. Même Security Monkey n'avait pas encore été publié.

Un cours pour la conférence de sécurité Black Hat approchait, et j'ai décidé de m'en servir comme prétexte pour apprendre Ruby et les API AWS (via le SDK Ruby). J'ai fini par écrire trois démonstrations :

• Une application de réponse aux incidents capable de mettre une instance en quarantaine, d'analyser l'ensemble de ses métadonnées, de la verrouiller à l'aide d'AWS IAM, de créer une image de tout le stockage et de lancer un serveur d'analyse forensique prêt à examiner les snapshots attachés. Cela accomplissait en 3 secondes ce qui me prenait auparavant 30 minutes.
• Une petite application qui se connectait à AWS et à Chef et identifiait toutes les instances n'exécutant pas Chef (serveurs « non gérés »). Un processus qui pouvait prendre des semaines dans un centre de données traditionnel.
• Une autre application qui ouvrait les security groups à un scanner Qualys, déclenchait une analyse, puis refermait le security group une fois celle-ci terminée.

Je n'avais jamais codé en Ruby auparavant : les trois ont donc demandé environ deux mois de travail à temps partiel avant d'être opérationnels. Elles étaient assez simples, mais j'en ai tiré de précieux enseignements.

• La gestion des identifiants était essentielle, et compliquait aussi le partage du code et la configuration correcte des environnements par les autres. Puiser dans des fichiers de configuration était… pénible. En particulier pour des éléments comme le choix du security group à utiliser comme groupe de quarantaine, et dans quelle région.
• Ruby fonctionnait très bien sur mon système local, mais je dépassais ensuite les limites de service et je devais insérer des temporisations lorsque j'exécutais le code dans une instance AWS. Les limites de service des API ne sont pas vos amies.
• Tout cela était en réalité très statique. Aussi élégantes fussent-elles pour des démonstrations, ces applications se résumaient à exécuter manuellement du code depuis un poste de travail ou une instance. Cela a mal vieilli.

J'ai regroupé le tout sous le nom de « SecuritySquirrel », et vous pouvez trouver les versions de 2014 sur GitHub. Croyez-le ou non, ce ne sont même pas les originaux que j'ai utilisés pendant quelques années avant de les publier.

Phase 3 : automatiser le cloud lui-même

Lorsque AWS a publié les Rules pour CloudWatch, j'ai assemblé en environ 2 heures, le samedi matin suivant, assez de code Python pour annuler toute modification d'un security group en 10 à 15 secondes — y compris des filtres permettant de cibler la défense selon les tags, le VPC ou l'auteur de la demande de modification. Vous pouvez télécharger le code et les instructions, et contrairement à mon code Ruby, celui-ci fonctionne encore plutôt bien pour du code cloud vieux de 3 ans.

Depuis cette première démonstration, j'ai constitué une bibliothèque d'automatisations événementielles exécutées dans Lambda, dont certaines sont disponibles en téléchargement. Dans ce paquet, ma préférée est `identify_internet_facing_servers.py` que, pour les besoins de la démonstration, j'ai reliée à un bouton Amazon Dash en version IoT. En effet, je transporte dans ma poche un véritable bouton Easy physique. Le script repère toutes les instances dont le port 22 est ouvert sur Internet et, d'un double-clic sur le bouton, je peux révoquer les règles, puis recevoir un SMS sur mon téléphone une fois que tout est rentré dans l'ordre.

L'enseignement principal a été inattendu. Ces automatisations événementielles ne remplaçaient pas mes flux de travail exécutés sur des hôtes : elles répondaient à un autre objectif. J'ai compris que j'étais passé de la création de flux de travail destinés à accélérer mes tâches à la mise en place de garde-fous destinés à préserver la sécurité en arrière-plan. Les deux ont une valeur considérable.

Phase 4 : tout automatiser

Mes travaux les plus récents portent sur l'utilisation de Jenkins et de l'Infrastructure as Code (principalement CloudFormation) pour renforcer la sécurité. Cette combinaison me permet d'automatiser la sécurité au sein même de l'infrastructure et des applications, et de moins dépendre d'outils externes.

Par exemple, j'ai publié un scanner d'identifiants simple à exécuter dans Jenkins pour détecter toutes les clés d'accès stockées avant même le démarrage du build. Pourquoi attendre et tenter de les débusquer plus tard ? J'ai ensuite écrit d'autres harnais de test me permettant d'exécuter dans Jenkins pratiquement n'importe quel outil d'évaluation, et de faire échouer les builds dès qu'ils ne passent pas un test de sécurité, comme une analyse réseau (astuce de pro : Jenkins fait échouer un build si un script lui renvoie un code de sortie autre que 0).

Pour boucler la boucle, nous animons désormais le cours de formation à l'aide de modèles CloudFormation qui construisent tous les éléments de la pile applicative, afin que les étudiants puissent se concentrer sur l'ajout de la sécurité. Nous sommes passés de la création de serveurs de formation cohérents à celle d'environnements de formation cohérents, avec des AMI personnalisées que nous pouvons mettre à jour en quelques minutes… à l'échelle mondiale… avec très peu d'efforts, tous les logiciels étant préinstallés et prêts pour la configuration finale.

Mon parcours dans le cloud a commencé il y a environ neuf ans, et mon parcours dans l'automatisation presque au même moment. J'ai commencé par construire des choses puis par tenter d'en automatiser des parties ; aujourd'hui, je pars du principe que tout sera automatisé. Mes premiers travaux concernaient l'exploitation, alors qu'ils sont désormais presque entièrement consacrés à la sécurité. À faire disparaître la charge opérationnelle et à permettre aux parties de mon esprit dédiées à la sécurité de se concentrer sur ce qu'elles font le mieux. En chemin, j'ai aussi appris que toutes les automatisations ne se valent pas : il y a une place pour les garde-fous, les flux de travail, l'orchestration multiplateforme, l'infrastructure as code et l'automatisation des pipelines. Tout cela apporte aujourd'hui des bénéfices de sécurité presque inimaginables, mais nous en sommes encore aux tout premiers temps, à une époque où l'on peut perdre une semaine rien qu'à rétro-analyser une API mal documentée.

Si vous travaillez dans la sécurité, il est temps de vous mettre au code. Si vous êtes développeur ou dans l'exploitation, il est temps de vous mettre à la sécurité. Car la plus grande leçon de toutes, c'est que l'époque de la sécurité comme parapluie est révolue et que celle de la sécurité intégrée à la trame est arrivée.