Article initialement publié dans Cyberun #30 de Juillet 2023

Toute migration dans le Cloud public apporte son lot de nouvelles problématiques pour les métiers de l’IT.

Une migration dans AWS ne fait pas exception, avec souvent un certain manque de visibilité sur l’infrastructure que l’on déploie. La diversité des services proposés fait qu’il n’est pas simple de suivre la totalité des ressources déployées (les instances, les équilibreurs de charge, les bases de données, les espaces de stockage , les lambda, …).

Afin de surveiller le bon usage de ces ressources, il est donc essentiel de mettre en place une solution de supervision de la conformité des instances tant en termes de configuration que de tagging.

Les points les plus critiques en termes de sécurité sont souvent les mêmes, que ce soit on-premises ou dans AWS :

• la difficulté à encadrer les accès aux ressources AWS, qui nécessite la mise en place d’un bastion pour sécuriser ces accès  ;
• la difficulté à centraliser les sorties sur Internet, qui nécessite la mise en place d’un proxy dédié ;
• le besoin de centraliser les logs générés par les composants du parc ;
• la capacité à gérer le patching des serveurs / instances et, au-delà, de sécuriser la configuration des OS de façon globale ;
• la définition et la mise en œuvre d’une politique de tagging des ressources. Cette politique permet de s’assurer de la cohérence et de l’uniformité des tags. Les services techniques ou FinOps s’appuient sur ces tags pour travailler de façon efficiente.

Dans la suite de cet article, je vais vous présenter le système de tableau de bord que nous avons mis en place dans le cadre d’un projet client pour assurer ce suivi au quotidien. L’objectif de ces tableaux de bord est de mettre en évidence visuellement les conformités mais surtout les non conformités. Nous avons deux tableaux de bord, l’un plus axé “Sécurité” (dashboard “panoptique”), assurant le suivi des conformités (tags, proxy, bastion, log, antivirus, EDR, etc.), l’autre permettant le suivi des mises à jour système des serveurs (dashboard “patching”).

En fin d’article, nous présenterons aussi la mesure de taxe sécurité mise en place par le client en cas de non-conformité remontée par les deux dashboards.

Le dashboard “Panoptique”

Ce tableau de bord permet de donner une vision globale de l’état de sécurisation et du tagging des ressources. Pour le moment, seulement deux types de ressources sont analysés en détail : les serveurs (instance EC2) et les équilibreurs de charge (ALB/ELB). 

Différents onglets permettent de rentrer dans le détail de chaque type de conformité

Les différentes pages permettent de trouver des indicateurs détaillés et/ou agrégés par entités (services). Chacun peut donc voir rapidement et simplement l’état de son infrastructure.

Lorsque cela est pertinent on peut afficher les listes des ressources identifiées ainsi que son état de conformité. Un système de filtrage dynamique permet de cibler les différentes ressources en fonction de critères (conforme / non conforme, nature du service, type de ressources…)

Le dashboard “Patching”

Un inventaire détaillé et dynamique des niveaux de patching

Ce tableau de bord permet de présenter les instances qui sont enrôlées dans le système de mise à jour automatique de leur OS. Quotidiennement nous affichons un état de la campagne mensuelle de mise à jour.

Ainsi il est possible d’avoir un état des lieux clair de la conformité des instances à travers un inventaire détaillé de ces instances et de la qualité de fonctionnement de la solution de mise à jour.

Un onglet donne une visibilité claire sur les instances et leurs dates mensuelles de mise à jour ( définies en fonction d’un système de tag attachés aux instances)

Le patching automatique est une solution mise en place qui s’appuie sur les fonctionnalités du service “Système Manager” AWS (SSM). (https://aws.amazon.com/fr/systems-manager/)

En utilisant les documents de mise à jour OS présents dans SSM, nous avons pu mettre en place une solution agnostique assurant de façon simple, pour les utilisateurs, un suivi de patching des instances enrôlées dans le service.

Le service permet le maintien en conditions opérationnelles, ainsi que la sécurisation des OS. Nous assurons aussi la communication auprès des utilisateurs pour le suivi des instances bénéficiaires du service.

Une solution basée sur un moteur à base de Lambda et de DynamoDB

Un ensemble de Lambda mère/filles permet l’analyse de l’infrastructure (Multi-Comptes et Multi-Régions).

Un système de “fenêtres de maintenance” permet de définir les plages horaires de patching (il existe actuellement quatre fenêtres définies : 5 heures, 12 heures, 21 heures et 23 heures). Ces fenêtres de maintenance exécutent des lambda chargées de traiter chaque instance à patcher au travers d’une Step Function. En fin de patching nous adressons un message à un salon Hangout pour informer les utilisateurs concernés de la réussite ou non de l’action de patching.

Merci à Jérémie Rodon pour son aide dans la mise en place de la solution par StepFunction !

A lire ici, son article sur les wait (https://rebirth.devoteam.com/2021/11/09/astuce-aws-step-functions-wait/)

“Rien n’est certain, que la mort et les impôts !”

Tout ce dashboarding, et les non conformités mises en évidence, nous ont permis de mettre en place une solution innovante de taxe, afin d’inciter à la mise en conformité.

L’assurance cybersécurité a été instaurée en 2021. Elle a pour but d’encourager les utilisateurs à mettre en place les mesures de sécurité de base. Elle est calculée en fin de mois à partir d’extractions des dashboards : une somme de taxe globale est divisée par le nombre de non conformités Proxy, Bastion, Journalisation des serveurs sensibles et des équilibreurs de charge exposés, EDR et Agent Qualys. 

Ce calcul donne le coût de la non conformité du mois. Ce prix est ensuite multiplié par le nombre de non conformités totales de chaque client.

Une logique d’amélioration continue

Nous avons essayé de mettre en place une solution simple et facilement lisible par tous, autour d’un sujet pas si simple que cela… la sécurisation et la mise en conformité d’un SI dans le Cloud AWS.

Les enjeux sont identiques à ceux d’un SI on-premises, mais l’outillage est plus automatisable. Etant donné que toute l’infrastructure est interrogeable par des appels API, nous avons pu mettre en place une solution d’inventaire au travers de lambdas et également des inventaires SSM.

Ces données croisées, et mises en base de données sous BigQuery (GCP), nous ont permis le déploiement de ces tableaux de bord. Après plusieurs essais et quelques loupés (une première version de la gestion du patching entièrement basée sur System Manager (Automation), des Automations manquant de souplesse et trop complexes à maintenir), nous avons trouvé une réponse satisfaisante. 

Nous continuons à l’améliorer, avec la mise en place d’un traitement au travers des Step Functions. Nous lui ajoutons aussi régulièrement de nouvelles fonctionnalités, avec notamment l’implémentation d’un outil de gestion et d’orchestration des tables et des vues dans BigQuery, pour gérer requêtes en cascade. Nous avons également revu les modèles de données pour une meilleure exploitation de ces dernières, ce qui nous a permis de mettre en place un tableau de bord “Sécurité” très complet avec un niveau de détail à la journée.

Ce qu’en pensent les utilisateurs

Dans un premier temps, la taxe n’a pas forcément été “facilement” accueillie, ce n’est pas en soit son coût, il est mineur, mais plutôt le fait que ce soit exposé de façon publique en interne. Mais avec le temps, et avec un travail important de sensibilisation et de support aux utilisateurs, nous avons pu faire valoir sa pertinence ; et notamment démontrer l’évolution plus que positive du niveau de conformité des SI. Nous continuons le travail d’évangélisation quotidiennement, et nous pouvons clairement affirmer que ça paye.

Les utilisateurs nous remontent maintenant régulièrement leur intérêt pour ces tableaux de bord qui sont devenus des outils incontournables de leur activité.

En conclusion, il existe désormais au sein des équipes une appétence certaine, et un outillage optimisé, pour la mise en conformité des ressources présentes dans les comptes AWS.