Réaliser un audit de sécurité informatique : la méthode

Un audit de la sécurité informatique peut porter sur deux plans.

L’audit organisationnel examine les règles : politique de mots de passe, gestion des arrivées et des départs, sauvegardes, sensibilisation des équipes.

L’audit technique examine la réalité du paramétrage : qui dispose réellement des droits d’administration, quels services sont exposés sur Internet, où sont stockés les secrets.

Les deux se complètent, mais l’audit technique apporte les constats les plus décisifs : une règle bien écrite ne protège rien si la configuration la contredit.
C’est lui que détaille cet article.

Pour un diagnostic plus large, qui couvre aussi l’architecture et les usages, la démarche d’un audit des systèmes d’information reste le bon point de départ.

Un audit qui veut tout couvrir finit par tout survoler.
Le périmètre se définit donc par ce qui concentre le risque : les applications exposées à vos clients, les outils d’administration, la chaîne de déploiement, les données sensibles.

Cette étape fixe aussi les règles du jeu :

• une lettre d’autorisation signée par la direction, et par l’hébergeur si l’infrastructure lui appartient,
• des fenêtres d’intervention convenues avec les équipes,
• l’engagement de tests non destructifs,
• un interlocuteur technique disponible, car chaque accès qui tarde décale tout le calendrier.

Avant d’examiner quoi que ce soit, il faut savoir ce qu’un attaquant verrait.
La cartographie répond à cinq questions :

1. Quels services sont accessibles depuis Internet ?
2. Qui dispose de droits d’administration, et depuis quels postes ?
3. Comment les utilisateurs s’authentifient-ils : annuaire, authentification unique, comptes locaux ?
4. Où se trouvent les secrets : mots de passe techniques, clés d’accès, certificats ?
5. Quels prestataires ont un accès, et lequel ?

Cette carte réserve souvent les premières surprises : un ancien serveur de test toujours en ligne, une interface d’administration ouverte à tous, un accès prestataire oublié.

C’est le cœur de l’audit technique.
Avec un accès en lecture aux outils, l’auditeur vérifie leur paramétrage réel.

Les points qui reviennent le plus souvent :

Comptes et accès

Double authentification absente sur les comptes d’administration, comptes partagés, comptes d’anciens salariés ou prestataires encore actifs.

Identités

Sessions trop longues, jetons d’accès sans expiration, droits accordés « temporairement » puis jamais retirés.

Code et déploiement

Mots de passe ou clés écrits en clair dans les dépôts de code, branches principales modifiables par tous, outils de déploiement aux droits trop larges.

Cloud et stockage

Espaces de stockage accessibles publiquement, liens de partage sans date d’expiration, environnements de test et de production mal cloisonnés.

API

Contrôle d’accès incomplet, qui permet par exemple à un utilisateur de consulter les données d’un autre en modifiant un simple identifiant dans l’adresse.

Composants

Bibliothèques et logiciels obsolètes, porteurs de vulnérabilités publiquement connues.

Pour les infrastructures plus avancées, conteneurs et clusters ajoutent leurs propres points de contrôle : droits, cloisonnement réseau, gestion des secrets.

Un audit livre souvent plusieurs dizaines de constats.
Sans cotation, ils se valent tous et rien n’avance.
Chaque constat reçoit donc une gravité, qui croise deux critères : l’impact s’il était exploité (fuite de données, arrêt de service, prise de contrôle) et la facilité d’exploitation (accessible depuis Internet ou non, compétences requises, accès préalable nécessaire).

Une échelle à quatre niveaux suffit : critique, élevé, moyen, faible.
Chaque constat est accompagné de sa preuve, d’une capture ou d’un extrait de configuration, pour que l’équipe technique puisse le vérifier elle-même.

L’audit produit deux documents, pour deux lecteurs.

Le rapport technique détaille chaque constat, sa preuve et la correction recommandée.
Le rapport de direction, en quelques pages, présente les risques majeurs et les décisions à prendre.

Le plan de corrections ordonne ensuite le travail :

• immédiatement : les constats critiques, souvent corrigés en quelques heures (désactiver un compte, retirer une clé exposée),
• sous 30 jours : les constats élevés,
• à 60 et 90 jours : les chantiers plus structurants, comme la refonte des droits ou le cloisonnement des environnements.

Une correction appliquée dans l’urgence peut être incomplète, et une nouvelle configuration peut réintroduire un défaut corrigé.
Des contrôles à trois, six et douze mois vérifient que les constats critiques sont levés, mesurent l’avancement du plan et repèrent les nouvelles expositions.
C’est cette boucle qui transforme un rapport en progrès réel.

Un cabinet de courtage de 80 salariés propose à ses clients un extranet pour consulter leurs contrats, développé par un prestataire et hébergé dans le cloud.
Un grand compte lui adresse un questionnaire de sécurité avant de renouveler son contrat : le cabinet décide de faire auditer son extranet et ses outils d’administration.

Le déroulé

• Deux semaines de cadrage et d’obtention des accès.
• Douze jours d’audit : cartographie, examen de la configuration, cotation.
• Une restitution réunissant la direction et le prestataire, six semaines après la signature.

Les constats

23 constats, dont 3 critiques :

• le compte d’administration d’un ancien prestataire, toujours actif et sans double authentification,
• des clés d’accès au stockage des documents, écrites en clair dans le dépôt de code,
• une faille de l’extranet : en modifiant le numéro de contrat dans l’adresse, un client connecté pouvait afficher les documents d’un autre client.

Les corrections

• Les 3 constats critiques sont corrigés dans la semaine qui suit la restitution.
• Les 7 constats élevés sont levés sous 60 jours.
• Au contrôle des six mois, 21 constats sur 23 sont corrigés ; les 2 restants, de gravité faible, sont acceptés et documentés.

Le bilan

Le cabinet répond au questionnaire de son client avec des preuves à l’appui : rapport de direction, plan de corrections, résultats du contrôle.
Le contrat est renouvelé.
Surtout, la faille de l’extranet, qui aurait exposé les documents de l’ensemble de ses clients, est fermée avant toute exploitation.

Un premier niveau d’audit peut être mené en interne.
Le guide d’hygiène informatique de l’ANSSI, avec ses 42 mesures, offre une grille de lecture solide pour vérifier les fondamentaux : comptes, mises à jour, sauvegardes, cloisonnement.

Un auditeur externe apporte trois choses qu’une équipe interne obtient difficilement : un regard neuf sur des configurations qu’elle a elle-même mises en place, une méthode éprouvée sur d’autres systèmes, et des constats prouvés que vos clients ou votre assureur reconnaissent.
C’est la démarche de notre audit cybersécurité pour PME, qui suit précisément ces six étapes.

Peut-on réaliser un audit de sécurité informatique en interne ?

Oui, pour un premier niveau. Le guide d’hygiène informatique de l’ANSSI permet de vérifier les fondamentaux. Un auditeur externe reste préférable pour l’audit technique des configurations et pour produire des constats reconnus par vos clients ou votre assureur.

À quelle fréquence auditer la sécurité de son SI ?

Un audit complet tous les deux ou trois ans, complété par des contrôles ciblés dans l’année qui suit, constitue un bon rythme pour une PME. Tout changement majeur justifie un audit sans attendre : migration vers le cloud, nouvelle application exposée, changement de prestataire.

Quelle différence entre audit de sécurité et audit des systèmes d’information ?

L’audit des systèmes d’information examine l’ensemble du SI : architecture, flux, usages, dépendances. L’audit de sécurité se concentre sur les risques d’intrusion et de fuite de données. Le premier aide à décider des évolutions, le second à réduire l’exposition.

Que faire si l’audit révèle une faille critique ?

La corriger sans attendre le rapport final : un auditeur sérieux signale immédiatement tout constat critique. Il faut ensuite vérifier si la faille a pu être exploitée auparavant, en examinant les journaux d’accès.