Étude de cas : un portail sécurisé pour 120 sites industriels

À retenir

• Sept semaines, contrainte par une date d’audit et non par un budget.
• 120 sites connectés, chacun avec son périmètre de données et ses responsables locaux.
• Audit ISO 27001 passé sans remarque, trois mois après la mise en production.
• 99,99 % de disponibilité sur les douze mois suivants, soit moins d’une heure d’indisponibilité cumulée.
• Le journal d’audit a été écrit avant les écrans. Ajouté après, il aurait obligé à réécrire la couche de données.
• Le deuxième facteur par SMS a été refusé, au profit d’une application d’authentification. L’ANSSI le recommande, et c’est ce qui a convaincu.

Le point de départ : une date d’audit, pas un cahier des charges

Le client est un groupe industriel multi-sites. Un outil interne de suivi d’exploitation, utilisé jusque-là par le siège, devait être ouvert aux 120 sites du groupe. Le projet n’est pas arrivé avec une liste de fonctionnalités mais avec une date : l’audit de certification ISO 27001 était programmé, et le portail devait y passer.

Cette contrainte a façonné tout le reste. Quand la conformité est datée, l’ordre dans lequel on construit compte plus que ce qu’on construit. Les exigences d’authentification, de traçabilité et de cloisonnement des données ne peuvent pas être ajoutées à la fin : elles décident de la forme de la base.

L’existant était un accès par identifiant et mot de passe partagé par site. Un mot de passe pour un site entier, changé une fois par an, connu de tout le monde y compris d’anciens salariés. Le responsable sécurité le savait et ne pouvait rien en faire : il n’y avait pas de notion d’utilisateur, donc rien à révoquer.

Le piège que nous avons écarté en premier rendez-vous : ils envisageaient d’acheter une solution de gestion d’identités complète, à l’échelle du groupe, pour régler ce portail. C’est un projet de dix-huit mois qui n’aurait pas tenu la date de l’audit.

Le cadrage : ce qu’on a décidé de ne pas faire

Quatre jours de cadrage, dont une demi-journée avec le responsable sécurité seul, pour lire la grille d’audit avant tout le reste. C’est cette lecture qui a fixé le périmètre, pas les demandes des utilisateurs.

La grille demandait six choses précises. Nous avons construit celles-là, et refusé tout ce qui ne s’y rattachait pas directement, y compris des demandes légitimes.

• Pas de gestion d’identités à l’échelle du groupe. Le portail s’appuie sur l’annuaire existant, il ne le remplace pas.
• Pas de provisionnement automatique des comptes en première version. Les responsables locaux créent leurs utilisateurs, ce qui est plus lent et tenait la date.
• Pas de deuxième facteur par SMS. Refusé pour des raisons de sécurité, voir plus bas.
• Pas de tableau de bord consolidé pour le siège en première version. Demandé, utile, mais hors grille d’audit.
• Pas de connexion depuis l’extérieur du réseau au lancement. Ouverte trois mois plus tard, une fois l’audit passé.

L’architecture, brique par brique

L’authentification unique, branchée et non reconstruite

Le groupe disposait déjà d’un annuaire d’entreprise. Nous l’avons utilisé comme source unique d’identité, par un protocole d’authentification standard. L’utilisateur ne crée pas de mot de passe pour le portail : il n’y en a pas.

Ce choix a supprimé d’un coup la moitié de la grille d’audit. Pas de stockage de mots de passe, donc pas de politique de rotation à prouver, pas de question sur l’algorithme de hachage, pas de procédure de réinitialisation à auditer. La meilleure façon de sécuriser un secret est de ne pas l’avoir.

Le deuxième facteur, et pourquoi pas le SMS

Le client demandait un code par SMS, parce que tout le monde a un téléphone. Nous avons refusé et proposé une application d’authentification générant un code à durée limitée. L’argument n’était pas théorique : un code par SMS est interceptable par détournement de carte SIM, et les recommandations publiques de l’ANSSI écartent le SMS comme facteur fort.

La discussion a duré deux réunions. Ce qui a tranché n’est pas notre avis mais le fait que l’auditeur poserait la question. Nous avons gardé le SMS comme moyen de secours pour les sites sans téléphone compatible, avec une alerte au responsable sécurité à chaque usage, ce qui le rend visible plutôt qu’interdit.

Le journal d’audit, écrit avant les écrans

C’est la décision structurante du projet. Chaque opération sensible produit une ligne de journal : qui, quoi, quand, depuis quelle adresse, et l’état avant et après. Les lignes sont en ajout seulement, aucun chemin de l’application ne permet de les modifier ou de les supprimer.

Pour que ce soit démontrable et pas seulement affirmé, chaque ligne porte une empreinte calculée sur son contenu et sur l’empreinte de la précédente. Modifier une ligne ancienne casse la chaîne, et un contrôle quotidien la vérifie de bout en bout. C’est cette chaîne que l’auditeur a demandé à voir, et c’est elle qui a clos le sujet en dix minutes.

Si ce journal avait été ajouté après coup, il aurait fallu réécrire chaque écriture de l’application pour y passer. C’est précisément pour ça qu’il a été écrit en premier.

Le cloisonnement des 120 sites

Chaque site ne voit que ses données. La règle est posée au niveau de la base et non dans le code de l’application : une politique de sécurité sur les lignes filtre selon l’identité de l’utilisateur connecté, quelle que soit la requête.

La différence est importante. Un filtre écrit dans le code se contourne par un oubli : un développeur ajoute une requête, oublie la condition, et un site voit les données d’un autre. Un filtre posé dans la base s’applique même à une requête mal écrite. Nous avons testé ce point en tentant volontairement d’écrire une requête sans filtre : elle renvoie zéro ligne.

La disponibilité, et ce qu’elle a coûté

L’engagement était de 99,9 %, soit huit heures d’indisponibilité par an. Le résultat mesuré a été de 99,99 %, soit moins d’une heure. Ce n’est pas de la chance, c’est le résultat de deux choix peu spectaculaires : une base répliquée avec basculement automatique, et des déploiements sans interruption de service.

Le coût de ces deux choix a été d’environ 180 € par mois d’hébergement supplémentaire. Rapporté à 120 sites dont l’exploitation s’arrête quand le portail s’arrête, la question ne se posait pas.

La révocation, qui était le vrai sujet

L’ancien système ne permettait pas de retirer un accès, puisqu’il n’y avait pas d’utilisateur. Désormais, la désactivation d’un compte dans l’annuaire du groupe coupe l’accès au portail à la session suivante, et les sessions actives expirent en huit heures au maximum.

Le responsable sécurité a demandé une coupure immédiate plutôt qu’à la session suivante. Nous avons ajouté une liste de révocation consultée à chaque requête sensible, ce qui coûte quelques millisecondes et répond au besoin réel : le départ d’un salarié qui a encore une session ouverte.

Le déroulé des sept semaines

Semaines	Ce qu’on a fait	Ce qu’on a appris
S1	Cadrage, dont une demi-journée sur la grille d’audit avec le responsable sécurité	Lire la grille avant les demandes utilisateurs a réduit le périmètre de moitié
S2	Journal d’audit, chaîne d’empreintes, politique de lignes dans la base	Écrire le journal en premier a été la décision la plus rentable du projet
S3	Branchement sur l’annuaire, authentification unique	Ne pas stocker de mot de passe a supprimé la moitié de la grille
S4	Deuxième facteur, application d’authentification, secours SMS tracé	Deux réunions pour écarter le SMS : c’est l’auditeur, pas nous, qui a tranché
S5 à S6	Écrans, rôles locaux, création d’utilisateurs par site	Les responsables locaux préfèrent créer eux-mêmes, contrairement à ce qu’on supposait
S7	Tests de pénétration externes, correction, mise en production	Deux corrections mineures, aucune sur l’authentification ni le journal

Les résultats

Indicateur	Avant	Après
Sites connectés	1, le siège	120
Mots de passe partagés	1 par site	0
Révocation d’un accès	impossible	immédiate
Journal des opérations sensibles	aucun	inaltérable, chaîné
Disponibilité mesurée	non mesurée	99,99 %
Remarques de l’auditeur ISO	sans objet	aucune

Le résultat qui compte n’est pas dans le tableau, c’est la durée de l’audit sur ce portail : dix minutes. L’auditeur a demandé la chaîne d’empreintes du journal, l’a vérifiée, et est passé au sujet suivant. Un journal construit après coup aurait produit une demi-journée de discussion et probablement une réserve.

Le résultat le plus facile à sous-estimer est la disparition des mots de passe partagés. Elle ne se mesure pas en incident évité, puisqu’un incident évité ne se compte pas. Elle se mesure en ceci : le départ d’un salarié ne nécessite plus de changer le mot de passe de tout un site.

Ce qu’on referait pareil, et ce qu’on regarderait autrement

• On referait l’ordre : grille d’audit, journal, puis écrans. C’est ce qui a tenu la date.
• On referait le refus du SMS comme facteur principal, et on garderait le secours tracé plutôt qu’interdit. Interdire sans alternative pousse les gens à contourner.
• On referait la politique de filtrage dans la base plutôt que dans le code, et on referait le test qui tente volontairement une requête sans filtre.
• On regarderait autrement le provisionnement des comptes. Nous avons supposé que les responsables locaux voudraient l’automatisme ; ils préféraient créer eux-mêmes. Une question en cadrage aurait suffi.
• On lancerait les tests de pénétration en semaine cinq et non en sept. Tout s’est bien passé, mais nous n’avions aucune marge si un défaut sérieux était sorti.

Combien coûterait un projet équivalent aujourd’hui ?

Un portail équivalent se chiffrerait aujourd’hui entre 28 000 et 45 000 € HT sur sept à dix semaines. Le facteur qui fait bouger la fourchette n’est pas le nombre de sites, c’est l’état de l’annuaire d’entreprise : un annuaire propre et déjà centralisé fait gagner deux semaines, un parc de comptes dispersés en coûte trois.

Comptez en plus l’hébergement en haute disponibilité, de l’ordre de 150 à 300 € par mois, et un test de pénétration externe entre 4 000 et 9 000 € selon le périmètre. Les deux sont des lignes à part, et un devis qui les inclut sans les nommer les a probablement sous-estimées. Voir aussi sécurité et RGPD d’une application métier.

Questions fréquentes

Faut-il écrire le journal d’audit avant ou après les fonctionnalités ?

Avant, sans hésitation. Un journal ajouté après coup oblige à reprendre chaque écriture de l’application pour y passer, ce qui coûte plus cher que de l’avoir posé au départ et laisse des trous. Dans ce projet, il a été écrit en semaine deux, avant le premier écran.

Pourquoi refuser le code par SMS comme deuxième facteur ?

Parce qu’il est interceptable par détournement de carte SIM, et que les recommandations publiques de l’ANSSI l’écartent comme facteur fort. Nous l’avons conservé en moyen de secours pour les sites sans téléphone compatible, avec une alerte au responsable sécurité à chaque usage.

Comment garantir qu’un site ne voit pas les données d’un autre ?

En posant le filtre dans la base et non dans le code. Une politique de sécurité sur les lignes s’applique à toutes les requêtes, y compris celles qu’un développeur écrirait en oubliant la condition. Testez-le en écrivant volontairement une requête sans filtre : elle doit renvoyer zéro ligne.

Une authentification unique est-elle plus sûre que des mots de passe ?

Oui, parce qu’elle supprime le secret au lieu de le protéger. Sans stockage de mot de passe, il n’y a ni politique de rotation à prouver, ni algorithme de hachage à défendre, ni procédure de réinitialisation à auditer. Et la révocation devient immédiate et centralisée.

Combien de temps avant qu’un accès révoqué soit réellement coupé ?

À la session suivante par défaut, soit huit heures au maximum ici. Si ce délai est inacceptable, une liste de révocation consultée à chaque requête sensible rend la coupure immédiate pour quelques millisecondes de coût. C’est ce que nous avons ajouté à la demande du responsable sécurité.

Quand lancer un test de pénétration externe ?

Au moins deux semaines avant la mise en production, pas la semaine d’avant. Nous l’avons fait en semaine sept sur sept et tout s’est bien passé, mais nous n’avions aucune marge si un défaut sérieux était ressorti. Nous le programmerions en semaine cinq aujourd’hui.

Glossaire

• Authentification unique : mécanisme par lequel un utilisateur s’identifie une fois auprès d’un annuaire central et accède ensuite à plusieurs applications sans nouveau mot de passe.
• Deuxième facteur : élément de preuve supplémentaire au mot de passe, par exemple un code à durée limitée généré par une application.
• Politique de sécurité sur les lignes : règle posée dans la base de données qui filtre les lignes visibles selon l’identité de l’utilisateur, indépendamment du code applicatif.
• Chaîne d’empreintes : suite d’empreintes où chacune est calculée à partir du contenu et de l’empreinte précédente, de sorte qu’une modification ancienne casse la suite.

Sources

• ANSSI, recommandations sur l’authentification multifacteur et les mots de passe
• CNIL, les durées de conservation des données
• Service public, obligations documentaires des entreprises
• Mesures de disponibilité relevées sur les douze mois suivant la mise en production.

À lire aussi sur le blog

• Sécurité et RGPD d’une application métier
• Architecture multi-tenant d’un SaaS
• Prix d’un logiciel métier sur mesure
• Coût d’hébergement d’une application
• Étude de cas : 12 000 bons de livraison par mois

Aller plus loin avec nous

Si vous avez une date de conformité et un outil à ouvrir, commencez par lire la grille d’audit avec nous, avant d’écrire la moindre fonctionnalité. C’est une demi-journée, et c’est elle qui décide si vous tiendrez la date. Voir comment nous travaillons sur les outils internes.