Comment se préparer à un audit de sécurité quand on édite un SaaS

La qualité d’un audit dépend autant de la préparation du client que du savoir-faire de l’auditeur. Une mission d’une semaine dont deux jours sont consacrés à obtenir des accès fonctionnels produit mécaniquement moins de résultats. Voici ce qui se prépare en amont, dans l’ordre.

1. Définir le périmètre, et surtout ce qui en est exclu

Un périmètre s’écrit noir sur blanc, avec les domaines et sous-domaines concernés, les adresses IP le cas échéant, les API publiques et internes couvertes, les applications mobiles, et les intégrations tierces.

Le plus important est la liste des exclusions explicites. Les cas fréquents : services hébergés chez un tiers dont vous n’êtes pas propriétaire, environnement de production quand seul le staging est testé, systèmes de paiement opérés par un prestataire, ou plateformes d’un partenaire.

Deux erreurs symétriques sont courantes. Un périmètre trop large dilue l’effort : six jours sur quinze applications donnent une couverture superficielle partout. Un périmètre trop étroit crée un faux sentiment de sécurité : auditer l’application web sans son API mobile, alors que les deux partagent le même back-end, laisse un pan entier hors du champ.

2. Préparer un environnement de test représentatif

L’idéal est un environnement de recette identique à la production en configuration, mais peuplé de données fictives. « Identique en configuration » est la partie qui pose problème : quand le staging désactive le WAF, tolère des mots de passe faibles ou emploie des clés de test, les résultats se transposent mal.

Points à vérifier avant le démarrage :

• La version déployée correspond à celle de production, à quelques jours près.
• Les mêmes protections périmétriques sont actives, ou leur absence est documentée.
• Les données sont fictives mais réalistes en volume et en structure. Une organisation vide ne permet pas de tester les fuites entre clients.
• Les intégrations externes sont branchées sur des bacs à sable, pas sur des comptes réels.
• L’environnement est stable pendant toute la mission : un déploiement en cours de test invalide les constats.

Si l’audit doit se dérouler en production, cas parfois inévitable, il faut le décider consciemment, prévoir une fenêtre horaire, désactiver les alertes non pertinentes et convenir d’un canal de contact immédiat.

3. Fournir les bons comptes

Pour une application SaaS multi-tenant, la configuration minimale utile est la suivante :

• Deux organisations distinctes, chacune avec ses propres données. C’est la seule façon de tester sérieusement la séparation entre clients.
• Un jeu de comptes par rôle dans chaque organisation : administrateur, utilisateur standard, lecteur seul, invité externe si le produit en propose.
• Des identifiants qui fonctionnent réellement, testés la veille du démarrage. Un compte expiré ou bloqué après trois tentatives fait perdre une demi-journée.
• Un moyen de recevoir les e-mails de ces comptes (boîte de test accessible), indispensable pour les parcours d’inscription, d’invitation et de réinitialisation.

Prévoyez aussi une procédure de déblocage rapide : les tests déclenchent régulièrement des verrouillages de compte ou des limitations de débit.

4. Rassembler la documentation utile

Trois documents économisent plusieurs jours d’auditeur :

Un schéma d’architecture, même sommaire : composants, flux entre eux, emplacement des données, points d’entrée exposés. Un schéma fait à la main vaut mieux qu’un document officiel obsolète.

La description du modèle de permissions : rôles existants, actions autorisées pour chacun, notion d’appartenance à une organisation, cas particuliers (super-administrateur interne, comptes de service, accès support).

La documentation d’API, sous forme de spécification OpenAPI, de collection Postman ou de schéma GraphQL. Sans elle, l’auditeur reconstitue la surface d’attaque par observation, ce qui consomme du temps et laisse forcément des zones non explorées.

Y ajouter, si disponibles : les rapports d’audits précédents et leur suivi de correction, la liste des incidents passés, et les points sur lesquels l’équipe a elle-même des doutes. Cette dernière information est précieuse et trop rarement transmise.

5. Prévenir les bonnes personnes

Un audit non annoncé mobilise l’équipe d’astreinte pour rien. À prévenir avant le démarrage : l’équipe technique, le support client (des données de test étranges vont apparaître), le prestataire d’hébergement si ses conditions l’exigent, et l’éditeur du WAF ou du service anti-DDoS.

Certains hébergeurs et fournisseurs cloud imposent une déclaration préalable pour les tests d’intrusion. Ce point se vérifie plusieurs semaines à l’avance.

6. Réserver du temps d’équipe pendant la mission

Un audit n’est pas une prestation passive. Il faut prévoir :

• Une réunion de lancement d’une heure, avec un développeur qui connaît le produit en profondeur.
• Un canal de discussion direct pour les questions ponctuelles pendant toute la durée.
• Un point intermédiaire, particulièrement utile sur les missions longues, pour remonter immédiatement un constat critique plutôt que d’attendre le rapport.
• Un rapport rédigé pour deux lectorats : une synthèse pour la direction et un corps technique directement exploitable par les développeurs.

Comptez l’équivalent d’un à deux jours-homme côté client sur une mission d’une semaine.

7. Anticiper l’après

La remise du rapport n’est pas la fin. Avant même le démarrage, il est utile de savoir qui arbitrera les corrections, dans quel sprint elles seront intégrées, et si une contre-vérification est prévue au contrat. Beaucoup de prestataires incluent une revalidation des correctifs dans un délai de un à trois mois : c’est le moment de le préciser, pas six mois plus tard.

Une préparation qui sert aussi en interne

Un effet secondaire souvent constaté : la préparation elle-même fait apparaître des problèmes. Formaliser le modèle de permissions révèle des incohérences. Lister les intégrations tierces met au jour des connexions oubliées. Dresser l’inventaire des sous-domaines exposés fait ressortir des environnements de démonstration laissés en ligne depuis deux ans.

Ces découvertes n’ont rien coûté en jours d’audit, et elles figurent parmi les plus rentables de l’exercice.