Analyse approfondie de l'inventaire en temps réel

Très tôt chez FireMon (avant même que nous devenions FireMon), nous avons constaté que tenter d'évaluer en direct les comptes cloud des clients (y compris les abonnements/projets) était... problématique. Réaliser autant d'évaluations atteignait rapidement les limites de service et risquait de perturber les appels d'API internes d'un client. Rappelons que nous avons commencé il y a environ 7 ans, avant même l'existence du CSPM, et que tout le monde tirait les mêmes enseignements.

La première solution que nous avons imaginée consistait à collecter une fois les données de configuration, à les intégrer à notre propre inventaire, puis à y effectuer nos évaluations. Cela nous a permis de limiter nos appels d'API au strict nécessaire pour récupérer les métadonnées. Nous pouvions ensuite exécuter plusieurs évaluations à partir du même jeu de données. Pendant un temps, cette approche a bien fonctionné. Nous réalisions toujours des analyses de configuration planifiées, mais nous pouvions les répartir plus uniformément et les optimiser afin de réduire la surcharge d'appels d'API. Cette approche comportait toutefois ses propres difficultés. Que se passait-il si quelque chose changeait entre notre analyse et le moment où quelqu'un traitait enfin l'alerte ? De plus, balayer l'intégralité d'un service AWS pour en recenser toutes les ressources sollicitait encore fortement les limites d'API, lesquelles dépendent du service et de la région.

Nous nous sommes fixé deux défis pour mieux répondre à cette situation. Premièrement, mettre à jour l'inventaire en temps réel afin de réduire les pics d'appels d'API vers un service donné et de garantir que les clients ne travaillent jamais avec des données obsolètes. Deuxièmement, conserver un historique permettant aux clients et aux enquêteurs de revenir en arrière et de voir exactement ce qui a changé et comment. Nous reviendrons plus tard sur l'architecture technique, qui varie légèrement selon la plateforme cloud. En bref, en nous connectant directement au flux d'événements du fournisseur cloud, nous pouvions identifier les appels d'API de modification, extraire les ressources concernées, mettre à jour notre inventaire en temps réel et déclencher simultanément toutes nos évaluations pour un type d'inventaire donné.

Bien que nous continuions à assurer un balayage planifié une fois par jour, en dehors des heures de pointe, le passage au temps réel a résolu de nombreux problèmes et apporté des avantages intéressants, notamment :

• Les clients ne rencontrent jamais de données périmées ; tout ce qui figure dans la plateforme doit correspondre étroitement à la configuration et à l'état réellement en cours d'exécution.
• Comme nous surveillons les appels d'API, nous pouvons identifier qui les a effectués. D'un coup, nous disposons d'une attribution d'identité complète dans notre inventaire.
• Il devient facile de déterminer ce qui a changé au moment où les modifications sont apportées, ce qui assure un suivi complet des changements.
• Nous pouvons exécuter tous les contrôles et évaluations en temps réel, au fur et à mesure des modifications. Cela inclut la RÉSOLUTION des problèmes lorsque quelqu'un les corrige en externe, et pas seulement l'identification de nouveaux problèmes.

Et voilà. Un inventaire historique complet, en temps réel, avec suivi des changements et attribution d'identité ! Oui, un service comme AWS Config offre nativement cette fonctionnalité au sein du fournisseur cloud. Toutefois, outre son caractère économique, notre inventaire est étroitement intégré à nos évaluations, couvre plusieurs déploiements et fournisseurs cloud et propose des capacités assez impressionnantes, telles que des fonctions de recherche complètes.

La meilleure façon de le découvrir est notre visite vidéo de 90 secondes ! Et voici quelques captures d'écran clés :

Page principale, présentant une grande quantité de données importantes en une seule vue :

Voici la vue de l'historique des modifications, qui présente les changements avec tous les détails et leur attribution. Elle propose également des fonctions utiles telles que les événements liés, les ressources associées, les exemptions et un historique des résultats réussis/échoués pour la ressource :

Cette vue Historique suit les modifications de manière chronologique, avec un graphique illustrant les tendances d'activité. Un clic sur la chronologie permet d'accéder à la date correspondante :

Avez-vous déjà eu besoin de savoir quelle ressource cloud éphémère détenait l'adresse IP apparue dans les journaux à un instant précis ? Les intervenants en réponse aux incidents adorent cette fonction...

Voilà pour cet aperçu rapide. Dans de prochains articles, nous détaillerons davantage l'architecture et la manière dont nous gérons cela dans les environnements multicloud.