Par Nils Krumrey, Enterprise Presales Engineer, LogPoint

Lorsque nous échangeons avec nos clients, le besoin qui apparaît comme une priorité, tout en haut de leur liste, est souvent la « gestion de logs ». Cette tâche paraît plutôt simple. Cependant, si vous voulez faire plus que simplement cocher une case, il est nécessaire de vous plonger véritablement dans ce que signifie la gestion de logs.

Qu’est-ce que la journalisation ?

Tout type de données d’événement temporel est un log. Traditionnellement, nous considérons les logs comme des fichiers texte longs et compliqués, mais les logs actuels peuvent provenir de pratiquement n’importe où, sous n’importe quelle forme. Un scanner de virus qui garde une trace des événements de mise à jour des clients dans sa base de données ? C’est un log. Des données de flux réseau en provenance d’un Cloud Privé Virtuel dans AWS ? Il s’agit d’un log à nouveau. Et bien sûr, on retrouve aussi tous les incontournables tels que les logs d’événements Windows, les logs de serveur Web, les logs d’accès aux fichiers, etc.

Qu’est-ce que le log managemet ?

Si nous avons des logs, pourquoi ont-ils besoin d’être gérés ? Le terme « gestion de logs » est né à une époque où ces derniers étaient principalement des fichiers texte, les administrateurs se débattaient avec l’espace sur le disque, et log99 passait automatiquement à log00. C’est à ce moment-là que les logs devaient être « gérés » de telle sorte à pouvoir s’en débarrasser pour que le système source puisse respirer à nouveau.

Alors que les fichiers texte ont fait place au Syslog, aux API et aux bases de données, l’exemple simple de log00 est toujours le point de départ de la gestion de logs. La problématique d’espace disque n’est peut-être plus d’actualités de nos jours, il est clairement davantage question de s’assurer que nous capturons les logs avant qu’ils ne disparaissent. Il est surprenant de voir combien de systèmes écrasent encore leurs logs en réécrivant dessus et à quelle vitesse ils le font. Souvent, les logs n’existent que pendant 24 heures, ou moins, avant d’être écrasés et de disparaître. Si nous voulons donner un sens à ces données de log plus tard, nous devons nous assurer qu’elles soient correctement collectées et éviter toute perte.

Les différentes étapes de la gestion de logs

Nous avons déterminé ce qu’était un message de log et pourquoi ils devaient être capturés, mais comment pouvons-nous faire fonctionner ce processus en pratique ?

Collecte des logs

Tout d’abord, le message de log doit être collecté. Soit il faut aller le chercher (la solution va donc le récupérer), soit un processus doit nous le faire parvenir (la solution va donc le collecter). La collecte de logs peut être obtenue pour les fichiers log authentiques en se connectant à un système et en les récupérant à l’aide des protocoles SCP ou SFTP. Alternativement, le système source peut être configuré afin d’offrir une plus grande convivialité et déposer régulièrement des logs via le serveur FTP intégré à la solution en question. En plus de ces fichiers, nous pouvons avoir affaire à des données Syslog (assez répandues pour les périphériques réseau) ou à des traps SNMP. Dans l’univers Windows, il peut s’agir d’un agent, de Windows Event Forwarding Collector, de WMI. Nous pouvons également rencontrer ODBC pour les bases de données. Nous pouvons aussi avoir affaire à l’API Office 365 Management, l’API Defender Alert ou l’API EventHubs. Enfin, il peut s’agir d’un compartiment S3.

Les méthodes de collecte de logs sont en effet infinies. Mais il est essentiel que la solution de gestion de ces derniers prenne en charge les plateformes et les techniques que vous utilisez pour générer des données de log. Dans le cas contraire, vous allez générer des angles morts.

Collecte centralisée des logs

Une des raisons de collecter les logs est de s’assurer qu’ils se trouvent dans un endroit sûr, rapidement accessible. Il est inutile d’avoir des fichiers log dans de nombreux endroits différents. La collecte centralisée des logs est donc un moyen rapide de les valoriser. Vous devez savoir où ils se trouvent et comment y accéder à tout moment.

La solution choisie doit être déployée efficacement et sans frais supplémentaires dans des environnements distribués. Par exemple, un site distant peut produire un nombre surprenant de messages de log qui satureraient la liaison WAN. De même, pour certaines plateformes Cloud, les logs de sortie et d’entrée peuvent entraîner d’importants surcoûts. Dans de tels scénarios, conserver les logs stockés localement ou les garder dans le Cloud, tout en étant capable de les rechercher à distance à partir d’une ‘Tête Chercheuse’ (Search Head) centrale, pourrait être vital. Là encore, la solution doit être suffisamment flexible pour s’adapter à vos besoins et à votre environnement.

Stockage à long terme, conservation et rotation des logs

Un choix que chaque client doit faire concerne la durée de stockage des messages de log. Il existe de nombreux critères, listés ci-dessous :

Conformité : existe-t-il des raisons réglementaires pour lesquelles les messages de log doivent être conservés ou même supprimés ? Les politiques PCI, GDPR et celles de l’entreprise entrent en jeu à ce niveau. Tant pour les données qui doivent être conservées que pour celles qui doivent être supprimées. La définition de politiques de conservation granulaires sera bénéfique. Il se peut, par contre, que des messages de log spécifiques contenant certaines Informations Personnellement Identifiables (IPI) doivent être conservés pendant une durée plus courte, ou que certains de leurs champs doivent être chiffrés.

Besoins opérationnels : existe-t-il certains cas d’usage dans lesquels avoir un message de log serait bénéfique après coup ? Par exemple, combien de temps après que l’activité ait eu lieu pourrait-il, de manière réaliste (ou légale), y avoir une réclamation concernant des droits d’auteur d’un tiers et visant un étudiant ayant téléchargé illégalement des films sur le réseau universitaire ?

Volumes et coûts des logs : les messages de log occupent de l’espace disque et ce dernier représente un coût. Certains fournisseurs facturent même la quantité de données stockées à l’aide de leurs propres outils. Une telle approche entraîne un coût spécifique pour chaque jour pendant lequel les messages de log sont stockés et conservés. Ainsi, il arrive un moment où le coût de conservation des logs stockés sur une longue durée est plus important que l’avantage qu’ils pourraient offrir. Dans de tels cas de figure ils devraient probablement être supprimés.

Choisir la bonne solution de stockage

Concernant le stockage des logs, il existe différentes façons de l’aborder. Certains services Cloud et gérés incluent tous les coûts de stockage dans un prix d’abonnement. Néanmoins, une conservation supplémentaire a tendance à être coûteuse. De plus, il existe peu de contrôle sur ce qui est stocké, le lieu et la durée de stockage, avec les données du client qui ne sont plus réellement en sa possession.

Avec d’autres solutions, les données appartiennent aux clients qui déploient ses propres niveaux de stockage. En fonction de l’architecture, la réponse peut déplacer automatiquement des données plus anciennes vers un niveau de stockage plus lent (tel qu’un NAS à disque plus lent plutôt qu’un DAS/SAN et des SSD). Certains fournisseurs envoient les données de log vers un niveau de type « hors ligne » ou « archive ». Cette démarche nécessite un processus de restauration lent si les données de log sont réellement nécessaires.

Comme d’habitude, une solution flexible offre le meilleur contrôle sur la conservation des logs et les coûts associés. Le maintien de la propriété des données, le stockage de différents messages de log concernant différentes périodes de temps, la protection des données sensibles tout en étant capable d’effectuer des recherches sur ces dernières, et la gestion automatique des niveaux de stockage par la solution devraient éliminer la plupart des problèmes posés par une solution de gestion de logs rigide.

Analyse et recherche de logs/rapports : Pourquoi utiliser la gestion de logs ?

Donc, où en sommes-nous à présent ? Nous avons collecté les logs et nous nous sommes assurés qu’ils étaient stockés de manière centralisée et pour une durée appropriée. Mais, après tout ce travail mis en œuvre, il est raisonnable de penser que ces logs vont avoir une quelconque utilité !

C’est là que la simple gestion de logs devient un SIEM (Security Information and Event Management/Gestion des informations et des événements de sécurité). Alors que la sécurité est devenue une préoccupation majeure, avec un SIEM, tout événement d’un fichier log peut être trouvé, faire l’objet d’une alerte et être observé via des tableaux de bord et des rapports.

Ainsi, la collecte et le stockage des logs est une première étape importante. Parfois, la collecte et le stockage de ces derniers représentent tout ce qui est nécessaire pour répondre à certaines exigences en matière de conformité. Cependant, la valeur réelle commence à émerger en utilisant à proprement parler ces logs. Par exemple, en effectuant une analyse de logs.

Avec un SIEM, vous avez accès à toute la puissance des logs. Tous les messages de log sont disponibles de manière centralisée presque immédiatement. Une telle possibilité signifie que vous saurez toujours à quel niveau résoudre les problèmes. Qu’il s’agisse de problèmes de connectivité réseau, d’alertes émises par un scanner de virus, d’utilisateurs bloqués avec l’impossibilité de se connecter et de toutes sortes d’autres incidents qui auraient autrement nécessité une recherche manuelle via des fichiers log difficiles à consulter au sein d’une multitude de systèmes, en partant du principe que ces derniers soient encore disponibles.

Pour des fonctionnalités encore plus avancées, qui vont au-delà des outils de gestion de logs, n’hésitez pas à consulter nos autres articles de blog sur le site LogPoint !