PREUVE / Feuillet de consultation
Pentest en boîte grise pour SaaS : quels accès préparer ?
Mis à jour le
Définir la connaissance donnée au cabinet
Un pentest en boîte grise fournit des informations et des accès déterminés à l’avance. Pour un SaaS, il peut s’agir de comptes utilisateurs, d’une description d’architecture et d’une documentation API. Le terme ne désigne pas un forfait universel. Décrivez précisément ce que le cabinet reçoit, ce qu’il doit découvrir et les hypothèses de menace retenues. Une boîte grise avec un seul compte ne couvre pas automatiquement les écarts entre tous les rôles.
Ce mode peut aider à examiner les parcours authentifiés demandés par le client. Il ne supprime pas les limites de temps, de méthode ou d’environnement. Faites confirmer si des tests sans authentification sont aussi inclus. Le CTO et le cabinet doivent distinguer les informations utilisées pour orienter l’audit des informations qui modifient les scénarios. Le rapport permettra ainsi à l’acheteur de comprendre la nature des accès disponibles pendant l’évaluation.
Préparer les comptes par rôle
Créez des identités dédiées à l’audit, avec des droits représentatifs et des données fictives. Utilisez des noms permettant à l’exploitation de reconnaître les comptes de test. Les rôles doivent correspondre à une matrice validée : lecture, modification, administration d’organisation ou support selon le produit. Ne fournissez pas directement un compte personnel d’administrateur pour gagner du temps. La traçabilité serait moins claire et la révocation plus difficile.
Si l’application est multi-tenant, préparez plusieurs organisations de test et les rattachements nécessaires. Un utilisateur appartenant à plusieurs organisations permet d’examiner certains changements de contexte. Les accès doivent être opérationnels avant la fenêtre d’audit. Réservez un créneau de vérification avec le cabinet : connexion, MFA, accès aux données et disponibilité des fonctions. Cette préparation limite les interruptions sans faire supposer une durée de prestation fixe.
Conserver la protection des accès
La MFA ne doit pas être contournée silencieusement pour faciliter les tests. Convenez de comptes et de facteurs dédiés selon le fonctionnement réel de l’application. La CNIL a publié une recommandation sur l’authentification multifacteur ; elle porte sur ce mécanisme et sa conformité, pas sur tous les processus de gestion des identités. Pour l’audit, décrivez séparément l’enrôlement, les droits, la récupération et la révocation que vous souhaitez examiner.
Transmettez les secrets par un canal convenu après contrat. Aucun mot de passe ou jeton ne doit être ajouté au formulaire public de demande de devis. Fixez une durée de validité et une procédure de rotation si un accès est exposé. Les journaux doivent permettre de reconnaître les opérations du cabinet. Définissez les modalités d’accès au réseau si une liste d’adresses autorisées ou une passerelle spécifique est nécessaire.
Fournir une documentation utile
Une description des fonctions et des frontières de confiance aide à organiser les scénarios. La documentation doit indiquer les versions actives et les exclusions. Si elle est incomplète, signalez-le ; le cabinet peut ajuster ses hypothèses. Une liste d’endpoints ne remplace pas la description du métier. Les règles d’approbation, d’invitation, de partage et d’export expliquent les actions qui devraient être possibles ou refusées selon le rôle.
Préparez des contacts capables de répondre aux questions pendant la mission. Le cabinet ne doit pas inventer le comportement attendu lorsqu’un parcours est ambigu. Une clarification peut changer la qualification d’un constat ou révéler un risque métier. Conservez ces échanges dans le dossier de mission afin que la restitution distingue les hypothèses initiales des règles effectivement validées avec vos équipes.
Révoquer et restituer
À la fin de la mission, fermez les comptes et révoquez les jetons selon la procédure définie. Vérifiez les sessions persistantes et les accès techniques complémentaires. Convenez de la conservation des données de test et des preuves par le cabinet. Si un retest est prévu, choisissez entre prolongation bornée et recréation des accès. Le calendrier de révocation doit rester explicite plutôt qu’être oublié au moment de transmettre le rapport au client.
La synthèse doit préciser les rôles et les informations fournies sans inclure leurs secrets. Une conclusion sur un parcours authentifié ne démontre pas l’absence de défaut sur tous les autres parcours. Faites inscrire les fonctions non examinées et les difficultés d’accès. Le commercial utilise ces limites pour présenter la preuve avec exactitude ; le CTO prépare les corrections et la revérification des scénarios qui restent pertinents pour la vente.
Grille de vérification avant commande
Pour « Pentest en boîte grise pour SaaS : quels accès préparer ? », conservez les réponses suivantes dans votre dossier achat. Une case vide devient une demande de clarification. Elle ne doit pas être interprétée comme un engagement inclus dans le prix ou comme une preuve déjà disponible.
- Collecter rôles, comptes dédiés et documentation utile. Demandez au candidat de préciser sa proposition, les éléments nécessaires et les limites. Conservez sa réponse avec la version de la consultation pour que le CTO et la direction commerciale puissent vérifier l’offre retenue.
- Différencier accès donnés et hypothèses de menace. Demandez au candidat de préciser sa proposition, les éléments nécessaires et les limites. Conservez sa réponse avec la version de la consultation pour que le CTO et la direction commerciale puissent vérifier l’offre retenue.
- Préparer MFA, traçabilité, révocation et fenêtre d’audit au contrat. Demandez au candidat de préciser sa proposition, les éléments nécessaires et les limites. Conservez sa réponse avec la version de la consultation pour que le CTO et la direction commerciale puissent vérifier l’offre retenue.
| Décision | Pièce à conserver | Responsable à désigner |
|---|---|---|
| Périmètre et exclusions acceptés | Version de la consultation et réponse détaillée du candidat, avec les interfaces et rôles concernés | Responsable technique de l’application |
| Format de preuve attendu | Confirmation du grand compte sur les documents, la langue et les conditions de revue | Interlocuteur commercial avec l’équipe sécurité client |
| Traitement des résultats | Plan de correction, critères de recette et conditions de retest proposées au devis | Équipe de développement et décideur de risque |
| Autorisation et diffusion | Mandat validé et droits de partage du rapport ou de la synthèse expurgée | Personne habilitée à engager la mission |
La consultation doit conserver les hypothèses qui peuvent changer le prix ou la date : accès non prêts, fonction indisponible, nouvelle version ou extension du périmètre. Demandez au cabinet comment une modification sera approuvée. Le rapport doit refléter la prestation effectivement réalisée. Une correction future, une disponibilité souhaitée et l’accord du grand compte restent des éléments à confirmer, chacun par son responsable.
Sources primaires consultées
Vérification éditoriale : 1er octobre 2026. Les conseils de consultation de ce feuillet sont une application pratique à discuter avec vos responsables et le cabinet.