Pourquoi protéger un mot de passe quand on peut s’en passer ?

Un problème que nous avons fini par considérer comme normal

Pratiquement toute application web dispose d’un panneau d’administration. Et ce panneau possède généralement une adresse de connexion, un formulaire d’authentification, un identifiant et un mot de passe.

Nous sommes tellement habitués à cette configuration que nous avons presque cessé de nous demander si tout devait nécessairement fonctionner ainsi.

Quand on n’a qu’un seul site, le problème ne semble pas très important. On crée un mot de passe complexe, on active l’authentification à deux facteurs, on limite le nombre de tentatives de connexion — et on passe à autre chose.

Mais que se passe-t-il quand les projets se multiplient et qu’on en a dix, vingt ou trente ?

Dans mon cas, il s’agit de l’écosystème DigiMeld, qui regroupe plus de trente projets logiciels indépendants. Chacun possède sa propre architecture, sa logique côté serveur et son interface d’administration.

Chacun a donc besoin d’un mécanisme d’accès administrateur.

Pendant longtemps, j’ai utilisé une approche tout à fait classique : des identifiants administrateur distincts, des mots de passe complexes et leur enregistrement dans le navigateur.

Ça fonctionnait.

Mais à un moment donné, je me suis demandé : pourquoi devrais-je conserver autant de mots de passe administrateur ? Pourquoi dois-je protéger non seulement les serveurs, mais aussi les moyens d’y accéder ?

Et ne serait-il pas possible de se passer de cette nécessité ?

J’en suis venu à une idée qui allait ensuite devenir le fondement de ma solution :

Il serait peut-être préférable de protéger non pas un point d’entrée permanent, mais le droit d’obtenir temporairement un accès.

Et s’il n’y avait tout simplement pas de page de connexion classique ?

J’ai décidé d’abandonner le modèle traditionnel d’authentification administrateur dans mes projets.

Pas simplement de masquer le formulaire de connexion.

Pas de changer l’adresse.

Pas de remplacer le mot de passe par un mot de passe encore plus complexe.

Mais de supprimer la nécessité même d’avoir en permanence une connexion par mot de passe.

Bien sûr, les interfaces d’administration n’ont pas disparu. Elles restent indispensables pour gérer les applications.

C’est la manière d’y accéder qui a changé.

Désormais, pour se connecter aux panneaux d’administration des projets intégrés, il n’est plus nécessaire de saisir un identifiant et un mot de passe enregistrés.

À la place, j’utilise mon propre système d’identification et de gestion des accès, MeldID.

Le principe est assez simple : l’accès administrateur n’est accordé que lorsqu’il est réellement nécessaire, à un utilisateur précis et pour un projet précis.

Et le simple fait de posséder un compte ne donne pas automatiquement le droit d’ouvrir un panneau d’administration.

Ce droit doit être accordé séparément.

Un accès qui n’existait pas une minute plus tôt

C’est sans doute la partie la plus intéressante de toute cette approche.

Dans le modèle traditionnel, l’administrateur dispose en permanence de moyens de connexion. Il peut les utiliser aujourd’hui, demain ou dans un mois, tant qu’ils restent valides.

J’ai décidé de changer ce principe.

Au lieu d’identifiants administrateur permanents, le système utilise une possibilité temporaire d’initier une connexion.

Elle est créée à la demande depuis un appareil mobile de confiance, comporte une composante aléatoire à résistance cryptographique et n’est valide que pendant une durée limitée.

Mais le simple fait de posséder ce lien temporaire ne donne pas accès au système.

C’est un point essentiel.

Imaginons que quelqu’un obtienne le lien d’une manière ou d’une autre. Dans un système classique reposant uniquement sur le secret de l’adresse, une telle fuite pourrait poser un grave problème.

Dans mon modèle, le lien permet seulement de lancer la procédure de confirmation.

Pour la poursuivre, une autorisation distincte doit être donnée depuis un appareil mobile de confiance équipé de MeldID.

Sans cette confirmation, aucune session administrateur n’est créée.

C’est pourquoi je considère le lien temporaire non pas comme un remplacement du mot de passe, mais comme l’un des éléments de la procédure d’octroi des accès.

Savoir où se présenter et avoir le droit d’entrer sont deux choses tout à fait différentes.

Le téléphone devient un outil de gestion des accès

Dans ce modèle, l’appareil mobile joue un rôle bien plus important que celui d’un simple générateur de codes à usage unique.

Il sert à confirmer les actions liées à l’accès administrateur.

Lorsque je veux ouvrir un panneau d’administration, le système demande une confirmation via MeldID.

Je vois la demande correspondante sur mon appareil de confiance et je confirme l’action.

Ce n’est qu’après vérification que le système autorise la poursuite de la procédure de connexion.

La confirmation est liée à une action précise, et non au simple fait que le téléphone a été déverrouillé.

La biométrie mobile vérifie l’utilisateur localement, tandis que le serveur vérifie la confirmation cryptographique provenant de l’appareil enregistré.

Cette approche évite de se fier uniquement à un mot de passe ou à un message indiquant que l’utilisateur aurait confirmé sa connexion.

Elle offre également un autre avantage : les appareils de confiance peuvent être gérés.

Si un appareil ne doit plus servir à confirmer les accès, son statut de confiance peut être révoqué.

Il cesse alors d’être un moyen d’autorisation valide pour les opérations concernées.

Un seul système pour de nombreux projets indépendants

Lorsque j’ai commencé à développer ce mécanisme, l’un de mes principaux objectifs était de préserver l’autonomie de chaque projet.

Je ne voulais pas réunir tous les panneaux d’administration dans une seule immense application.

Chaque service DigiMeld devait continuer à gérer sa propre logique, ses paramètres, ses utilisateurs et ses données.

J’ai donc séparé les deux fonctions.

MeldID s’occupe de l’identification et de l’octroi de l’autorisation d’accès administrateur.

Chaque projet, lui, gère ses propres fonctionnalités d’administration et vérifie les autorisations en vigueur.

On obtient ainsi une gestion centralisée des accès sans avoir à centraliser les applications elles-mêmes.

De plus, les droits sont accordés séparément.

L’administrateur d’un projet n’accède pas automatiquement aux autres simplement parce qu’il possède un compte MeldID.

On peut définir une liste distincte d’utilisateurs autorisés pour chaque périmètre d’administration.

Par ailleurs, les droits des utilisateurs ordinaires et les privilèges d’administration restent séparés.

Cette approche s’est révélée particulièrement pratique pour un écosystème composé de dizaines de services.

Pourquoi je préfère l’accès temporaire à l’accès permanent

J’ai volontairement intégré un autre principe au système.

L’accès administrateur ne doit pas être permanent.

L’autorisation est valable pendant une durée limitée et prend fin, que l’utilisateur continue ou non à travailler dans son navigateur.

Pour poursuivre le travail après son expiration, il faut suivre une nouvelle procédure de confirmation.

Cela évite qu’une autorisation accordée une fois ne se transforme en droit permanent.

Mais limiter la durée ne suffit pas.

Il est important de pouvoir mettre fin prématurément à un accès déjà accordé.

C’est pourquoi MeldID prévoit la révocation centralisée des autorisations administrateur.

Lorsqu’une autorisation est révoquée, les projets intégrés reçoivent l’événement correspondant et invalident les sessions administrateur associées.

La gestion des accès ne s’arrête donc pas au moment où l’utilisateur s’est connecté avec succès.

La possibilité de révoquer les privilèges est, à mes yeux, aussi importante que celle de les accorder.

Un système distribué doit toutefois tenir compte des délais de transmission des événements, de l’indisponibilité temporaire de certains composants et d’autres contraintes opérationnelles. La durée limitée des sessions constitue une protection supplémentaire.

Qu’est-ce qui a changé dans mon travail au quotidien ?

Tout d’abord, je n’ai plus besoin de recourir constamment aux mots de passe administrateur enregistrés.

Je n’ai plus à conserver dans mon navigateur une série d’identifiants pour me connecter à chacun des panneaux d’administration intégrés.

À la place, je gère les autorisations par l’intermédiaire d’un mécanisme unique.

Je sélectionne le projet nécessaire, je confirme l’accès et je me mets au travail.

Quand l’accès administrateur n’est plus nécessaire, je peux le révoquer.

Il est particulièrement pratique de ne pas avoir à repenser tout le système d’authentification administrateur à chaque nouveau projet.

Il suffit de l’intégrer au modèle existant et de définir les autorisations nécessaires.

Bien sûr, cela ne signifie pas que tous les risques de sécurité ont disparu.

Les autorisations temporaires, les appareils de confiance, les sessions côté serveur et l’infrastructure centrale doivent eux aussi être protégés.

Mais je n’ai plus à résoudre séparément le même problème de gestion des mots de passe administrateur pour chaque application.

Et c’était précisément l’un de mes objectifs initiaux.

Ces technologies n’existent-elles pas déjà ?

Bien sûr que si.

L’authentification sans mot de passe, la gestion des accès privilégiés, les autorisations temporaires et la confirmation via des appareils de confiance sont des pratiques bien connues dans le secteur de la sécurité de l’information.

On retrouve ces approches dans les systèmes de gestion des identités et des accès (Identity and Access Management), de gestion des accès privilégiés (Privileged Access Management) et dans les modèles Zero Trust.

Je ne prétends pas avoir inventé ces principes.

Mon objectif était différent.

Je devais créer un système intégré qui réponde aux besoins spécifiques de l’infrastructure DigiMeld et permette de gérer l’accès administrateur à de nombreux projets indépendants.

J’ai finalement réuni plusieurs approches éprouvées au sein d’une architecture adaptée à mes exigences.

Et je pense que la valeur du travail d’ingénierie ne réside pas nécessairement dans l’invention d’une technologie entièrement nouvelle.

Elle consiste parfois à bien définir le problème et à trouver la solution qui lui convient.

MeldID ne sert pas uniquement aux panneaux d’administration

Il convient ici d’apporter une précision.

MeldID n’a pas été conçu uniquement comme un outil pour gérer mes propres accès administrateur.

Il propose également aux développeurs un SDK permettant d’intégrer des mécanismes d’identification et de confirmation de connexion à leurs propres applications.

De plus, ce SDK est gratuit.

Par exemple, un développeur tiers peut utiliser MeldID comme niveau supplémentaire de confirmation de l’authentification des utilisateurs.

Même si l’application conserve la connexion traditionnelle par identifiant et mot de passe, leur saisie correcte peut ne pas suffire à finaliser l’authentification.

L’utilisateur reçoit une demande sur son appareil mobile de confiance, où il peut confirmer ou refuser la tentative de connexion.

Cela permet de réduire le risque d’accès non autorisé en cas de compromission des identifiants.

Il est important de distinguer cette fonctionnalité publique de MeldID du modèle d’accès administrateur que j’ai conçu pour les projets DigiMeld.

Les deux reposent sur des principes communs de confiance et de confirmation des actions, mais répondent à des besoins différents.

La sécurité ne consiste pas seulement à protéger ce qui existe déjà

Le travail sur ce système m’a amené à reconsidérer les mécanismes d’authentification auxquels nous sommes habitués.

Nous essayons souvent de protéger des choses qui existent pour des raisons historiques.

Nous ajoutons de nouvelles vérifications, des restrictions, des mots de passe supplémentaires et des couches de protection.

C’est parfois vraiment nécessaire.

Mais il est parfois plus utile de poser une autre question :

Le mécanisme que nous cherchons à protéger doit-il nécessairement continuer d’exister sous sa forme actuelle ?

Dans mon cas, la réponse était non.

Je n’avais pas besoin d’un formulaire de connexion administrateur accessible en permanence.

J’avais besoin de pouvoir obtenir des privilèges administrateur en toute sécurité, précisément au moment où ils étaient nécessaires.

Ce sont deux problèmes différents.

Passer du premier au second a changé non seulement l’architecture technique, mais aussi mon travail quotidien sur les projets.

Non pas un aboutissement, mais une direction choisie

Aujourd’hui, cette architecture est déjà utilisée dans une grande partie de l’écosystème DigiMeld.

Les projets restants passent progressivement au nouveau modèle d’accès administrateur.

J’effectue la migration étape par étape, en vérifiant le fonctionnement de chaque application. Une fois la transition terminée, je prévois un audit supplémentaire de l’ensemble du système.

Certains éléments de l’interface et certaines règles de gestion des sessions peuvent encore évoluer.

Mais le principe général est déjà établi.

Je ne veux pas revenir à un modèle où, pour gérer des dizaines de mes propres projets, je dois conserver et utiliser en permanence des dizaines de mots de passe administrateur.

Je ne considère toutefois pas ma solution comme universelle.

Les organisations ont des exigences, des infrastructures, des modèles de menace et des pratiques d’administration différents.

Ce qui est pratique et pertinent pour l’écosystème DigiMeld ne sera pas nécessairement optimal pour un autre développeur.

Le principe de l’octroi temporaire de privilèges mérite néanmoins qu’on s’y intéresse.

Pour conclure

J’ai décidé de partager cette expérience non pas parce que je me considère comme l’inventeur d’une nouvelle méthode d’authentification.

Ni parce que je veux présenter un système de plus comme absolument sécurisé.

La sécurité absolue n’existe pas.

La manière de poser la question me semble simplement intéressante.

Au lieu de protéger sans fin un accès administrateur permanent, on peut remettre en question la nécessité même de son existence.

Au lieu de conserver une multitude de mots de passe, on peut utiliser des autorisations temporaires.

Au lieu d’accorder automatiquement sa confiance après une première authentification, on peut confirmer l’octroi de privilèges précis.

Au lieu d’attendre qu’une session expire, on peut prévoir la possibilité de révoquer les accès de manière centralisée.

Enfin, au lieu d’avoir un mécanisme de connexion distinct pour chaque projet, on peut créer un système unifié de gestion des autorisations administrateur tout en préservant l’autonomie des applications.

Je ne prétends pas que cette approche exclut toute possibilité de compromission.

Elle déplace simplement l’accent : au lieu de protéger des identifiants permanents, elle privilégie l’octroi et la révocation contrôlés des privilèges.

Parfois, le moyen le plus efficace de réduire la surface d’attaque n’est peut-être pas d’ajouter une couche de protection supplémentaire, mais de renoncer à ce dont le système peut parfaitement se passer.

C’est cette idée qui a marqué le début de l’histoire de MeldID Admin Gateway pour moi.