Audit infrastructure : les 7 points qu'on regarde en premier

Un audit d’infrastructure complet prend deux à trois semaines, livrables inclus. Mais dans les premières heures sur le terrain, sept points donnent déjà 80% du diagnostic. Sept signaux qui disent “tout est sous contrôle” ou “il faut courir”. Voici notre check-list initiale, dans l’ordre où on la déroule chez un nouveau client.

1. La cartographie réseau existe-t-elle ?

C’est la question qui fait grincer des dents. Demandez le schéma réseau du site, et observez la réaction.

Trois cas de figure :

• Schéma propre, à jour, daté : très bon signe. Cela révèle une équipe qui documente, qui réfléchit avant d’agir, et qui sait expliquer son infra. Le reste de l’audit sera probablement fluide.
• Schéma vieux de trois ans, partiellement obsolète : situation normale. La plupart des PMEs sont là. Il faut prévoir une journée de re-cartographie active (Nmap, capture mDNS, ARP scan via routeur).
• Pas de schéma du tout : signal d’alarme. Si personne ne sait ce qu’il y a sur le réseau, personne ne peut le sécuriser. C’est le premier livrable à produire avant tout le reste.

L’outil qu’on utilise pour reconstituer rapidement : Nmap en mode -sn sur la plage du LAN, croisé avec la table ARP du routeur principal et les baux DHCP. En une heure on a 95% des hôtes actifs.

2. Combien de services exposent un port en clair ?

Un scan externe rapide depuis l’extérieur. Pas une attaque, juste une photo. On regarde :

• Les ports ouverts sur l’IP publique principale
• Les certificats TLS (validité, version, suite cryptographique)
• Les bannières de service (versions exposées)

Les drapeaux rouges typiques : un port 23 (telnet) qui répond, un MySQL sur 3306 public, une interface d’admin web sans HTTPS, ou pire, un phpMyAdmin accessible depuis Internet. On a vu des DMZ qui exposaient un ESXi en 5480 avec mot de passe par défaut. C’est arrivé en 2024 chez un prospect qui pensait être “petit donc pas ciblé”.

3. Les sauvegardes sont-elles testées ?

La question piège : “Quand avez-vous restauré un backup pour de vrai la dernière fois ?”. Si la réponse est “jamais” ou “je sais plus”, on a un problème.

Les checks rapides :

• Existe-t-il une politique de rétention écrite ?
• Les backups sont-ils chiffrés au repos ?
• Sont-ils stockés hors site ?
• Y a-t-il un journal des restaurations test (au moins trimestriel) ?
• Les BDD sont-elles snapshotées avec un dump SQL cohérent (pas un cp à chaud du datadir) ?

Sur les missions où la réponse à toutes les questions est “non”, la priorité numéro 1 du livrable est la mise en place d’une stratégie de sauvegarde, parce que tout le reste devient inutile au premier ransomware.

4. La gestion des comptes admin

Combien de comptes administrateurs ? Combien sont actifs ? Combien correspondent à des personnes encore présentes dans l’entreprise ?

Sur Active Directory, on lance un audit Bloodhound léger pour cartographier les chemins de privilege escalation. Sur Linux, on regarde /etc/sudoers et /etc/sudoers.d/, on liste les users avec getent passwd | awk -F: '$3 >= 1000 && $3 < 65000', et on croise avec les sessions actives via last.

Le drapeau rouge : un compte admin nommé prestataire2019, dernière connexion il y a deux ans, jamais désactivé. Vu en 2025 chez un client. C’est le premier qu’on désactive, avec sa clé SSH révoquée et ses sessions fermées.

5. L’état des mises à jour

Un coup d’oeil sur le parc :

• Combien de serveurs sont en LTS active ?
• Combien sont en distribution end-of-life (Debian 10, Ubuntu 18, CentOS 7…) ?
• Quelle est la dernière date d’application des patchs de sécurité ?

Sur les systèmes obsolètes, on note l’urgence. Une CentOS 7 en 2026, c’est un ticking bomb : plus de patchs, plus de support officiel, et les CVE s’accumulent. La migration peut prendre trois à six mois selon la complexité du stack applicatif, donc il faut commencer hier.

L’outil qu’on utilise : un inventaire Ansible en mode gather_facts, qui remonte distribution, version, kernel, et état des paquets. En une heure on a la photo du parc.

6. Le monitoring est-il déclencheur ou décoratif ?

On distingue deux types de monitoring :

• Décoratif : Grafana branché sur Prometheus, beau dashboard, mais personne ne reçoit d’alerte. C’est de la décoration murale.
• Déclencheur : Alertmanager configuré, alertes routées vers Slack, SMS pour les criticals, et un on-call qui les traite réellement.

La question qui tranche : “Quel a été le dernier incident détecté en premier par votre monitoring, plutôt que par un utilisateur qui appelle ?” Si la réponse est “jamais”, le monitoring n’a aucune valeur.

On audite aussi ce qui n’est PAS surveillé : les certificats TLS (combien expirent dans 30 jours sans alerte ?), l’espace disque sur les filesystems de logs, l’état des sauvegardes, la latence des requêtes critiques. C’est souvent là que ça pèche.

7. La documentation existe-t-elle vraiment ?

Pas le wiki de 2018 qu’on vous montre fièrement. La doc opérationnelle, celle qui permet à un nouvel admin de débugger un incident à 3h du matin sans réveiller le CTO. Les questions :

• Y a-t-il un runbook pour redémarrer chaque service critique ?
• Les credentials sont-ils dans un coffre-fort partagé (Bitwarden, Vault, Passbolt) avec rotation documentée ?
• Existe-t-il une procédure de PRA testée ?
• Les contrats fournisseurs (cloud, ISP, support) sont-ils référencés avec numéros d’urgence ?

L’absence de documentation opérationnelle est le facteur de risque numéro un sur le long terme. Une infra parfaitement architecturée mais non documentée meurt au premier départ d’admin senior.

Le livrable

Après ces sept points, on a un état des lieux honnête en 24-48h. Pas un audit complet — celui-là prend trois semaines avec scan de vulnérabilités, review GPO, tests d’intrusion légers et review des configs détaillées. Mais on a le triage : ce qui peut attendre, ce qu’il faut corriger ce mois-ci, et ce qui doit être traité avant la fin de la semaine.

C’est cette priorisation qui fait la différence entre un audit utile et un PDF de 80 pages qui finit dans un tiroir. Un client doit pouvoir agir dès le premier jour, pas attendre la version finale du rapport pour qu’un attaquant entre en attendant.

En conclusion

Si vous reprenez une infra, regardez ces sept points en priorité. Si vous opérez votre propre infra, posez-vous ces questions une fois par trimestre, et notez les réponses. Le score qui monte, c’est de la sécurité. Le score qui stagne ou baisse, c’est de la dette technique qui se transforme en risque opérationnel.

Et si certaines réponses vous mettent mal à l’aise — c’est exactement à ce moment-là qu’il faut nous appeler.