Rétention des logs : conserver ce qui est nécessaire pour enquêter
Cybersécurité · 3 min
Articles de Fábio Ribeiro
Conserver les logs sans critère augmente les coûts et le bruit. Découvrez comment définir une rétention utile pour la sécurité, la continuité et l'audit.
TL;DR
- La rétention des logs doit partir des scénarios d'investigation, et non seulement de la capacité technique.
- Tous les événements n'exigent pas le même détail, la même protection ou la même période de rétention.
- La qualité des logs dépend de la couverture, de la normalisation, du contexte et du contrôle d'accès.
- Une rétention excessive peut augmenter les coûts, les risques et la complexité opérationnelle.
- La politique doit être révisée lorsque les systèmes, les risques, les contrats ou les exigences réglementaires changent.
La bonne question n'est pas combien conserver
De nombreuses organisations commencent leur politique de rétention des logs par la capacité de la plateforme : combien d'espace est disponible, combien coûte le stockage et pendant combien de temps est-il techniquement possible de conserver les événements. La question la plus utile est différente : quelles informations seront nécessaires pour reconstruire un incident, confirmer un changement, répondre à un audit ou démontrer l'exécution d'un contrôle ? Cette approche évite deux extrêmes fréquents : _tout conserver sans contexte_, créant ainsi des coûts et du bruit, ou __ne conserver que des événements agrégés__ qui ne permettent pas d'enquêter avec confiance.
Définir des scénarios avant de définir des délais
La rétention doit être conçue à partir de scénarios concrets : *accès administratif indu*, *changement de configuration critique*, *échec d'authentification*, *exfiltration suspecte*, *indisponibilité de service* ou *exécution d'une action privilégiée*. Pour chaque scénario, il est important d'identifier les sources, les champs nécessaires, les besoins de rétention, la période d'analyse nécessaire et les équipes impliquées. Les plateformes d'[observabilité et AIOps](/pt/solucoes/sistemas-monitorizacao) peuvent aider à centraliser les événements, mais ne remplacent pas la décision quant aux logs ayant une valeur opérationnelle, probatoire ou de conformité.
Tous les logs n'ont pas la même valeur
Les événements d'identité, d'administration, de réseau, de systèmes, d'applications critiques, de sauvegardes et de services cloud ne doivent pas être traités comme s'ils avaient le même poids. Certains exigent un plus grand détail et une protection contre les modifications ; d'autres peuvent être agrégés ou conservés moins longtemps. Il est également important de distinguer les logs techniques de la télémétrie volumineuse, des enregistrements contenant des données personnelles, des preuves de sécurité et des métriques de performance. Une politique mature définit les **classes de logs**, les **propriétaires**, la **finalité**, l'__emplacement__, la __période de rétention__ et les __critères de suppression__.
Le contexte est aussi important que le volume
Les logs sans contexte accélèrent rarement une investigation. Un événement d'accès est plus utile lorsqu'il peut être lié à l'identité, au dispositif, à l'application, à la localisation, au changement approuvé et au service affecté. La connexion aux inventaires, aux dépendances et aux procédures opérationnelles améliore l'interprétation des signaux. En cas d'incident, des [runbooks bien définis](/pt/blog/runbooks-automatizacao-resposta-incidentes) aident à transformer ces données en décisions répétables : _que valider en premier_, _qui impliquer_, _quelles preuves préserver_ et __quand escalader__.
Protéger les logs contre les abus et les pertes
Les logs eux-mêmes peuvent devenir sensibles. Ils peuvent révéler des modèles d'utilisation, des adresses, des noms d'utilisateurs, des clés mal exposées, des erreurs d'application ou des informations clients. C'est pourquoi la rétention doit inclure le **contrôle d'accès**, la **ségrégation des fonctions**, le **chiffrement** si approprié, les *pistes d'audit sur la consultation* et les __mécanismes d'immuabilité__ lorsque le risque le justifie. Dans un modèle avec [SOC/NOC as a Service](/pt/solucoes/soc-noc-as-a-service), il convient de clarifier contractuellement qui peut consulter, exporter, modifier et supprimer les enregistrements.
Revoir la politique en fonction du risque
Une politique de rétention des logs ne doit pas rester figée. De nouvelles applications, des services SaaS, des intégrations, des changements réglementaires, des audits et des incidents doivent conduire à des révisions périodiques. La décision n'est pas seulement technique : elle implique la **sécurité**, les **opérations**, le **juridique**, la **conformité** et les *responsables métier*. L'objectif est de maintenir des preuves suffisantes pour enquêter et démontrer le contrôle, sans accumuler de données sans finalité claire. Une bonne politique aide à réduire l'incertitude lorsqu'un incident se produit et rend plus prévisible l'équilibre entre __coût__, __risque__ et __utilité__.