Pour un éditeur de logiciel en mode service, ISO/IEC 27001 a cessé d'être un projet de sécurité pour devenir une condition d'entrée commerciale. Aucun texte ne l'impose ; les acheteurs, eux, l'imposent. Le risque principal n'est donc pas d'échouer à l'audit, il est de décrocher un certificat dont le périmètre ne recouvre pas ce que les clients croient acheter — et de le découvrir lors d'un questionnaire de sécurité, ou pire, après un incident.
Cet article propose une lecture opérationnelle et ne constitue pas un avis juridique. Un éditeur étant souvent lui-même sous-traitant d'entités régulées, ses engagements contractuels peuvent aller au-delà de ce que la norme prévoit.
Le périmètre, ou la tentation de rétrécir
Les mécanismes de la norme — approche par les risques, déclaration d'applicabilité, amélioration continue, audit par un organisme tiers — sont détaillés dans la page consacrée aux obligations ISO 27001 en matière d'authentification. Un seul mécanisme mérite d'être repris ici, parce qu'il est propre aux éditeurs : le certificat porte sur le périmètre que vous avez vous-même défini.
Réduire ce périmètre est légal, courant, et parfois raisonnable. Cela devient un problème quand le périmètre exclut ce qui porte le risque réel : la chaîne de production logicielle, les postes des développeurs, l'outil de support. Un certificat qui couvre la plateforme mais pas le pipeline qui la déploie répond à la lettre de la question posée par le client, jamais à son intention. Les acheteurs matures lisent désormais l'annexe du certificat avant le certificat lui-même.
Les accès qui décident du résultat de l'audit
Un éditeur SaaS possède une poignée de chemins d'accès qui, s'ils tombent, emportent tout le reste. Ce sont eux que l'auditeur échantillonne.
La console d'administration multi-tenant
C'est l'actif le plus asymétrique de l'entreprise : un compte, tous les clients. Le contrôle d'accès et les droits d'accès privilégiés y sont testés en priorité. La question posée n'est pas « est-ce protégé ? » mais « combien de personnes peuvent atteindre ce niveau, et par combien de chemins différents ? ».
Les clés d'API et les comptes de service
Elles échappent aux politiques d'authentification conçues pour des humains. L'auditeur cherche un propriétaire nommé, une durée de vie, une procédure de rotation, et une trace d'usage. Une clé de longue durée stockée dans un dépôt de code ou dans une variable d'environnement oubliée constitue un écart difficile à minimiser.
Les pipelines de déploiement continu
Le pipeline détient, par construction, des droits supérieurs à ceux de la plupart des salariés. Il signe, déploie, migre des schémas. Un jeton de robot compromis vaut un accès administrateur — sans aucune des alertes qui accompagneraient une connexion humaine anormale.
L'accès des développeurs à la production
Rarement supprimé, souvent justifié par l'astreinte. La difficulté n'est pas d'interdire cet accès, c'est de le rendre exceptionnel, motivé, limité dans le temps et journalisé de façon exploitable.
La fonction de support avec usurpation d'identité client
L'« impersonation » permet à un technicien de voir l'application comme le client la voit. C'est un excellent outil de support et un point de rupture majeur : un compte de support compromis donne accès à des données clients sans jamais toucher aux comptes clients. Toute session ouverte de cette manière doit être consentie, bornée et visible côté client.
Les environnements de préproduction
Ils contiennent des données réelles bien plus souvent que ne le dit la documentation, tout en étant protégés comme des bacs à sable. C'est l'écart le plus embarrassant à expliquer en réunion de clôture.
Preuves attendues, chemin par chemin
| Chemin d'accès | Mesure d'annexe A principalement mobilisée | Preuve à produire | Écart typique |
|---|---|---|---|
| Console multi-tenant | Droits d'accès privilégiés | Liste nominative des porteurs, revue datée, journal des actions | Rôle d'administration attribué « temporairement » il y a un an |
| Clés d'API | Informations d'authentification | Inventaire avec propriétaire et date de rotation | Clé partagée entre deux services, sans date d'expiration |
| Pipeline CI/CD | Contrôle d'accès | Traçabilité des déploiements et des secrets utilisés | Secret de longue durée dans la configuration du pipeline |
| Accès développeur en production | Gestion des identités | Demande motivée, durée, révocation automatique | Accès permanent justifié par l'astreinte |
| Support avec usurpation | Journalisation | Enregistrement horodaté de chaque session, motif associé | Fonction activable sans traçabilité côté client |
| Préproduction | Sécurité des relations avec les fournisseurs et contrôle d'accès | Preuve d'anonymisation ou classification équivalente à la production | Extraction de production copiée pour reproduire un bogue |
Le questionnaire de sécurité client : un audit permanent
Entre deux audits de certification, ce sont les questionnaires clients qui contrôlent l'éditeur. Ils ne posent pas les mêmes questions et sont souvent plus précis sur l'authentification : méthodes proposées aux utilisateurs finaux, fédération avec l'annuaire du client, protection de la console d'administration, gestion des comptes de service, délai de révocation. Répondre vite et de façon cohérente suppose que ces réponses existent déjà dans le système de management, pas qu'on les reconstruise à chaque appel d'offres.
C'est aussi là que la question de la résistance réelle apparaît. Un client régulé demandera si vos accès d'administration résistent au relais de session ; une méthode contournable par un intermédiaire actif sera relevée. Certains éditeurs choisissent d'ajouter, sur les actions les plus lourdes de conséquences, une preuve d'intention distincte de la session, comme le facteur cognitif, plutôt que d'empiler des facteurs de même nature.
Plan de travail
- Écrire le périmètre en pensant à l'acheteur : plateforme, pipeline, support, postes de développement.
- Inventorier les identités non humaines avant les identités humaines, avec un propriétaire pour chacune.
- Rendre l'accès développeur à la production exceptionnel et daté, avec révocation automatique.
- Journaliser l'usurpation de support de bout en bout, et rendre la trace consultable par le client.
- Traiter la préproduction comme la production ou prouver que les données y sont réellement transformées.
- Préconstituer les réponses aux questionnaires dans les documents du système de management.
FAQ
Notre certification suffit-elle à répondre à un client régulé ?
Rarement à elle seule. Un client soumis à ses propres obligations vous transmettra un questionnaire et des clauses contractuelles qui vont au-delà du certificat. La certification crédibilise la démarche ; elle ne remplace pas les preuves demandées sur des points précis.
Faut-il inclure les postes des développeurs dans le périmètre ?
C'est vivement conseillé chez un éditeur. Le poste de développement accède au code, aux secrets et souvent aux environnements. L'exclure produit un certificat que les acheteurs techniques savent lire comme une réserve.
Comment traiter les comptes de service qui ne peuvent pas porter de second facteur ?
En les traitant comme une catégorie à part : identifiants à durée de vie courte, restriction par origine réseau, cloisonnement des droits, rotation automatisée et journalisation. L'analyse de risque doit expliquer pourquoi la compensation est proportionnée.
Le SSO fédéré avec l'annuaire du client déplace-t-il notre responsabilité ?
Partiellement seulement. L'authentification est déléguée, mais la gestion des sessions, la révocation, les comptes locaux de secours et l'accès administrateur restent chez vous — et ce sont précisément ces points que l'audit examine.
Aller plus loin : pilier : authentification cognitive · lecture générale d'ISO 27001 · NIS2 pour les éditeurs SaaS · accès à privilèges et PAM