- Gestion des logs
- Journalisation
- DNSSI
- Cybersécurité
- Loi 05-20
- SIEM
- Conservation des données
- Services managés
Gestion des logs : ce que la DNSSI impose, quoi journaliser, et comment dimensionner
Sans journaux complets, horodatés et conservés, impossible de reconstituer un incident. Au Maroc, la DNSSI fixe des règles précises : centralisation, synchronisation des horloges, conservation d'au moins six mois. Ce qu'elle impose, ce qu'il faut journaliser ou non, l'architecture type et une méthode pour estimer le volume et le coût.
Novagios11 min de lecture

En bref
- La DNSSI impose de collecter les journaux des serveurs, équipements de sécurité, équipements réseau, applications et postes de travail, de les centraliser, de les protéger contre la falsification, de les analyser périodiquement et de les conserver au moins six mois. Les horloges doivent être synchronisées sur un service NTP de confiance.
- Les actions des administrateurs et les interventions de maintenance doivent être tracées ; ces dernières sont conservées au moins trois mois.
- Tout ne doit pas être journalisé : mots de passe, jetons de session, clés, données de carte bancaire et données personnelles sensibles n'ont rien à faire dans un log.
- Un log est une donnée personnelle dès qu'il contient un identifiant ou une adresse IP : la loi 09-08 s'applique, avec minimisation et accès restreint.
- Le coût dépend du volume : il se calcule à partir du nombre d'événements par seconde, de leur taille et de la durée de conservation. Un stockage en paliers (récent, intermédiaire, archive) le maîtrise.
Ce que dit la DNSSI
La DNSSI, dans sa version mise à jour adossée à la loi 05-20 relative à la cybersécurité et à son décret d'application n° 2-21-406, s'applique aux systèmes d'information des administrations de l'État, des collectivités territoriales, des établissements et entreprises publics, et aux infrastructures d'importance vitale publiques et privées. Ses mesures sur la journalisation :
| Mesure | Ce qu'elle exige |
|---|---|
| EXP-JOURN/SURV-JOURNAL | collecter les journaux des différentes sources (serveurs, équipements de sécurité, équipements réseau, applications, postes de travail) en fonction des risques ; les centraliser ; les protéger contre la falsification et les accès non autorisés ; les analyser périodiquement avec des actions définies ; les conserver au moins six mois |
| EXP-JOURN/SURV-PRIVIL | tracer les actions des administrateurs et des opérateurs système |
| EXP-JOURN/SURV-MAINT | tracer les interventions de maintenance et conserver ces traces au moins trois mois |
| EXP-JOURN/SURV-SYNCHRON | synchroniser tous les actifs sur la même base de temps, un service NTP de confiance |
Une entreprise privée qui n'est pas une infrastructure vitale n'est pas soumise à la DNSSI, mais celle-ci reste la meilleure référence nationale, et ses clients publics peuvent l'exiger. Pour situer votre organisation, voir notre grille de maturité cybersécurité.
Quoi journaliser, source par source
| Source | Événements prioritaires |
|---|---|
| Annuaire et authentification (Active Directory, SSO) | connexions réussies et échouées, verrouillages de comptes, création, modification et suppression de comptes, changements de groupes à privilèges |
| Serveurs | ouvertures de session, élévations de privilèges, arrêts et redémarrages de services, modifications de configuration |
| Équipements de sécurité (pare-feu, proxy, VPN, antivirus, EDR) | flux refusés, connexions VPN, détections, mises à jour de signatures en échec |
| Équipements réseau | changements de configuration, accès d'administration, changements d'état des interfaces |
| Applications métier | connexions, accès aux données sensibles, exports massifs, modifications de droits, erreurs applicatives |
| Bases de données | connexions des comptes à privilèges, modifications de schéma, accès aux tables sensibles |
| Cloud et SaaS | journaux d'administration, de connexion et d'accès aux données fournis par chaque service |
| Postes de travail | ouvertures de session, exécution de logiciels non autorisés, branchement de supports amovibles |
Chaque événement doit permettre de répondre à quatre questions : quand (date et heure synchronisées), où (équipement, application, adresse), qui (utilisateur ou compte de service, adresse source) et quoi (type d'événement, gravité, résultat).
Ce qu'il ne faut pas écrire dans un log
Un log est souvent plus largement accessible que la donnée qu'il décrit. Y écrire des secrets revient à les diffuser. Le guide de journalisation de l'OWASP recommande d'exclure, ou de masquer, chiffrer ou hacher :
- les mots de passe et les codes d'authentification ;
- les identifiants de session et les jetons d'accès ;
- les chaînes de connexion aux bases de données, les clés de chiffrement et autres secrets ;
- les données de carte bancaire et de compte bancaire ;
- les données personnelles sensibles ;
- les informations commercialement sensibles et le code source.
Le piège le plus courant est le mode « débogage » laissé actif en production, qui écrit le contenu complet des requêtes, mots de passe compris.
Un log est aussi une donnée personnelle
Un journal qui contient un identifiant d'utilisateur, une adresse IP ou une action sur un dossier relève de la loi 09-08 sur la protection des données personnelles. Trois règles en découlent :
- Finalité définie : sécurité, traçabilité, diagnostic. Les journaux ne doivent pas servir à autre chose, par exemple à surveiller la productivité des salariés.
- Minimisation : ne collecter que ce qui sert la finalité, et pseudonymiser quand c'est possible.
- Accès restreint : seules les personnes dont la fonction le justifie lisent les journaux, et ces accès sont eux-mêmes tracés.
À titre de repère, la CNIL française recommande une conservation de six mois à un an pour la journalisation des accès, et jusqu'à trois ans dans certains cas de contrôle interne. Le minimum de six mois de la DNSSI s'inscrit dans cette fourchette.
L'architecture type
| Étape | Rôle | Bonnes pratiques |
|---|---|---|
| 1. Sources | produire les événements | journalisation activée dès l'installation, horloges synchronisées, format structuré (JSON) |
| 2. Collecte | récupérer les événements sur chaque site | agents ou collecteurs intermédiaires, mise en mémoire tampon en cas de coupure |
| 3. Transport | acheminer vers le stockage central | protocole fondé sur TCP, chiffré (TLS), en temps réel si la bande passante le permet |
| 4. Stockage central | conserver et indexer | serveurs dédiés, partition réservée aux journaux, supervision de l'espace disque, droits d'écriture et de suppression très restreints |
| 5. Analyse | détecter et enquêter | règles de corrélation, tableaux de bord, alertes reliées au centre de services |
| 6. Archivage | conserver à moindre coût | stockage peu coûteux, éventuellement en écriture unique, avec suppression automatique à échéance |

L'agence française de cybersécurité (ANSSI) recommande, dans son guide sur l'architecture des systèmes de journalisation, des serveurs centraux dédiés, une architecture hiérarchique pour les organisations multisites, des protocoles fondés sur TCP et chiffrés, et un accès en lecture réservé aux seuls comptes dont la fonction le justifie.
Pour l'hébergement, les journaux suivent les données qu'ils décrivent : pour une entité vitale, le référentiel de qualification des prestataires cloud exige au niveau 2 que les données techniques, journaux compris, restent sur le territoire national. Voir notre article sur le cloud souverain.
Un format structuré plutôt que du texte libre
Un log en texte libre se lit à l'œil, mais s'analyse mal. Un log structuré se filtre, se corrèle et s'agrège :
{"time":"2026-10-02T09:14:07.312Z","level":"WARN","service":"portail-usagers",
"event":"auth.failure","user":"u-48213","src_ip":"10.20.4.17","reason":"bad_password","attempt":3}
Trois conventions suffisent pour commencer : un horodatage au format ISO 8601 en temps universel, un niveau de gravité commun (par exemple ceux de syslog, de « debug » à « emergency »), et des noms de champs identiques d'une application à l'autre. Le standard ouvert OpenTelemetry fournit un modèle de données commun pour les journaux, les métriques et les traces.
Estimer le volume et le coût : une méthode simple
Le volume stocké se calcule ainsi :
volume = événements par seconde × taille moyenne d'un événement × 86 400 secondes × jours de conservation ÷ taux de compression
Exemple fictif, à visée illustrative. Une organisation produit en moyenne 2 000 événements par seconde, d'une taille moyenne de 500 octets.
| Étape du calcul | Résultat |
|---|---|
| Volume brut par seconde | 2 000 × 500 octets = 1 Mo/s |
| Volume brut par jour | 1 Mo × 86 400 ≈ 86 Go |
| Volume brut sur 183 jours (six mois) | ≈ 15,8 To |
| Volume stocké avec une compression de 8 pour 1 (hypothèse, variable selon l'outil) | ≈ 2 To |

Trois leviers réduisent la facture sans perdre la conformité :
- filtrer à la source les événements sans valeur (messages de débogage, vérifications de santé répétitives) ;
- stocker en paliers : quelques semaines en stockage rapide et indexé pour l'enquête, le reste en stockage intermédiaire puis en archive peu coûteuse jusqu'à la fin de la durée de conservation ;
- différencier les durées par catégorie : six mois minimum pour la sécurité, moins pour le diagnostic applicatif, davantage si un texte sectoriel l'exige.
Les outils
| Famille | Exemples | Point d'attention |
|---|---|---|
| Collecte et transport | rsyslog, syslog-ng, Fluent Bit, OpenTelemetry Collector | homogénéiser la configuration sur tous les sites |
| Stockage et recherche libres | OpenSearch, Elasticsearch, Grafana Loki, Graylog | dimensionnement et exploitation à assurer |
| Détection de sécurité libre | Wazuh | règles à adapter au contexte |
| Plateformes commerciales | Splunk, Microsoft Sentinel, Datadog, Elastic Security | coût souvent indexé sur le volume ingéré, localisation des données à vérifier |
Le choix dépend moins de l'outil que de trois questions : où les journaux doivent-ils être hébergés, qui les exploitera au quotidien, et quel volume faut-il absorber.
La méthode en six étapes
- Inventorier les sources et les classer par criticité, en commençant par l'annuaire, les accès à privilèges, les équipements de sécurité et les applications sensibles.
- Synchroniser les horloges de tout le parc sur un service NTP de confiance.
- Définir la politique de journalisation : événements à collecter par source, données à exclure, durées de conservation par catégorie, personnes autorisées à lire.
- Centraliser avec un transport chiffré et un stockage dédié, protégé en écriture et en suppression.
- Analyser : une dizaine de règles prioritaires (échecs de connexion répétés, création de compte à privilèges, connexion hors horaires, effacement de journaux, exports massifs), reliées à un ticket dans l'outil de gestion des services.
- Contrôler chaque trimestre : chaque source remonte-t-elle bien ? La durée de conservation est-elle respectée ? Les alertes ont-elles été traitées ?
Les erreurs les plus fréquentes
- Des horloges désynchronisées : impossible de reconstituer une chronologie entre deux équipements.
- Des journaux stockés sur la machine attaquée : un attaquant qui obtient les droits d'administration efface ses traces.
- Tout collecter sans rien analyser : la DNSSI demande une analyse périodique, pas seulement un archivage.
- Des secrets dans les journaux : mots de passe ou jetons écrits par un mode débogage oublié.
- Une source qui se tait sans que personne ne le remarque : un équipement qui n'envoie plus rien doit déclencher une alerte.
- Aucune durée de suppression : conserver indéfiniment augmente le coût et le risque, et contredit la loi 09-08.
Questions fréquentes
Combien de temps faut-il conserver les logs au Maroc ?
Pour les organisations soumises à la DNSSI, au moins six mois pour les journaux de sécurité, et au moins trois mois pour les traces des interventions de maintenance. Des textes sectoriels peuvent imposer davantage.
Faut-il un SIEM ?
Pas pour commencer. Une centralisation bien faite, avec une dizaine de règles d'alerte, couvre l'essentiel. Un SIEM devient utile quand le volume, le nombre de sources ou les exigences de détection augmentent.
Peut-on stocker les logs dans le cloud ?
Oui, sous réserve de la sensibilité des données qu'ils décrivent. Pour une entité vitale traitant des données sensibles, les journaux doivent rester sur le territoire national, chez un prestataire qualifié de niveau 2 ou sur site.
Les logs sont-ils des données personnelles ?
Dès qu'ils contiennent un identifiant, une adresse IP ou une action rattachable à une personne, oui. La loi 09-08 s'applique : finalité définie, minimisation, accès restreint, durée limitée.
Qui doit lire les journaux ?
L'équipe d'exploitation ou de sécurité, selon une procédure définie. Les accès aux journaux sont eux-mêmes tracés, et les administrateurs des systèmes surveillés ne doivent pas pouvoir supprimer les traces de leurs propres actions.
Par où commencer
Synchronisez les horloges, centralisez les journaux de l'annuaire, des accès à privilèges et des équipements de sécurité, et écrivez votre politique de conservation : ces trois actions couvrent l'essentiel des exigences de la DNSSI. Les équipes Novagios accompagnent ces projets : cybersécurité pour la politique et la détection, services managés pour l'exploitation au quotidien, cloud et infrastructures pour l'architecture et l'hébergement, et IT Service Management pour relier les alertes au centre de services. Pour un premier diagnostic, contactez nos experts.
Sources
- DGSSI, Directive nationale de la sécurité des systèmes d'information (version mise à jour), mesures EXP-JOURN/SURV-JOURNAL, SURV-PRIVIL, SURV-MAINT et SURV-SYNCHRON.
- Loi n° 05-20 relative à la cybersécurité et décret n° 2-21-406 pris pour son application.
- Loi n° 09-08 relative à la protection des personnes physiques à l'égard du traitement des données à caractère personnel.
- ANSSI, « Recommandations de sécurité pour l'architecture d'un système de journalisation » (ANSSI-PA-012, janvier 2022).
- CNIL, recommandation relative aux mesures de journalisation (novembre 2021).
- OWASP, « Logging Cheat Sheet ».