Qui a les clés du coffre ? Le PAM expliqué sans jargon

La semaine dernière, des failles critiques ont rappelé une chose simple : quand une application web est compromise, l’attaquant hérite de tout ce qu’elle sait faire, y compris se connecter à la base de données. Et ces accès dorment trop souvent en clair dans des fichiers de configuration. Voici l’autre moitié de l’histoire : celle des clés.

Une histoire de trousseau

Imaginez un immeuble. Le gardien possède un passe-partout qui ouvre tout : les appartements, le local technique et le coffre de la copropriété. Jusque-là, rien d’anormal.

Maintenant, imaginez qu’on en ait fait des copies pour chaque prestataire. Que personne ne sache plus qui en possède une. Que la serrure n’ait jamais été changée, même après le départ de ceux qui l’avaient. Et qu’après un cambriolage, il soit impossible de savoir qui est entré, quand et pourquoi.

Dans nos systèmes d’information, ce passe-partout s’appelle un compte privilégié : l’administrateur du serveur (root), l’administrateur de la base de données (sa sous SQL Server, postgres sous PostgreSQL, root sous MySQL) ou les comptes que les applications utilisent pour se connecter. Il peut donner accès à des ressources sensibles, y compris aux données.

Le PAM, pour Privileged Access Management (Gestion des Accès Privilégiés), c’est la gouvernance de ces passe-partout : qui peut les utiliser, quand, pourquoi et avec quelle trace.

Le jour où j’ai compté les clés

Lors d’une mission d’audit, j’ai examiné un serveur SQL Server critique, utilisé par trois services de l’entreprise. Chaque service avait sa propre base de données. Normalement, on s’attend à trouver des droits d’administration adaptés à chaque base.

J’ai trouvé un seul compte. Il était membre du rôle db_owner dans les trois bases. Et pas seulement : il l’était aussi dans les bases système master, model, msdb et tempdb. Or master contient des informations sur l’instance et sa configuration, et msdb sert notamment à l’Agent SQL Server pour ses tâches planifiées. Ces droits étaient donc beaucoup plus étendus que nécessaire.

Ce n’était pas tout : le compte sa, l’administrateur intégré de SQL Server, était activé et utilisé pour se connecter avec SSMS, l’outil d’administration. Un identifiant tout-puissant, qui n’est le nom de personne.

Visiblement, le serveur avait été installé en suivant un tutoriel : ça marche, on avance, et personne n’est revenu régler correctement les droits d’accès. Rien de spectaculaire, et c’est justement le piège. La configuration d’un tutoriel est faite pour que ça fonctionne, pas pour que ça résiste.

Ce que cette mission m’a appris : le vrai risque n’est pas toujours une faille logicielle. C’est parfois un compte que personne n’a jamais remis en question.

Cinq problèmes qu’on rencontre souvent

1. Un compte administrateur partagé, dont le mot de passe est connu de plusieurs personnes.
2. Des mots de passe jamais renouvelés alors que leur sécurité ou leur attribution n’est plus maîtrisée.
3. Des droits permanents : un accès accordé « pour dépanner » qui reste ouvert pour toujours.
4. Des identifiants d’application en clair dans des fichiers de configuration (scripts, code source, dépôts).
5. Aucune trace fiable : en cas d’incident, impossible de dire qui a fait quoi.

Aucun de ces cinq points n’est une faille logicielle. Ce sont des habitudes. C’est d’ailleurs ce que rappelle le CERT-FR dans son retour d’expérience d’octobre 2026 : parmi les quelque 200 violations de données applicatives qu’il a suivies en 2025, beaucoup n’ont pas exigé d’exploiter une vulnérabilité technique.

Cinq gestes concrets : le PAM, version simple

• 1. Un compte par personne : Chaque administrateur se connecte avec sa propre identité, jamais avec un compte humain partagé. Les comptes intégrés comme postgres ou root sont réservés aux situations où ils sont réellement indispensables et doivent être strictement protégés.
• 2. Des droits temporaires (Just-In-Time) : En l’absence d’un outil PAM dédié, mettre en place un processus d’accès temporaire : demande tracée, rôle accordé par un administrateur, échéance définie et retrait vérifié. Effectuer les tâches courantes et les essais dans un environnement de test avec des données protégées. Pour les interventions indispensables en production, accorder un accès nominatif, justifié, limité dans le temps et tracé.
• 3. Un coffre-fort pour les secrets : Sortir les identifiants d’application des fichiers de configuration et mettre en place une rotation maîtrisée, sans interrompre le service. Cette rotation doit respecter les règles prévues par la PSSI et les documents associés ; si ces règles sont absentes ou obsolètes, demander leur mise à jour aux responsables concernés.
• 4. Des journaux protégés et externalisés : Les connexions et les requêtes sensibles sont enregistrées — par exemple avec l’extension pgAudit pour PostgreSQL ou une solution d’audit adaptée à MySQL — puis envoyées vers un système séparé, dont les accès sont distincts de ceux des administrateurs de la base.
• 5. Un compte de secours scellé (« break-glass ») : Il existe pour les urgences ultimes, son utilisation déclenche immédiatement une alerte de sécurité, et son mot de passe est renouvelé après chaque usage.

Le rôle du DBA : un risque important et une défense essentielle

Un DBA détient par nature des privilèges étendus sur une ressource précieuse de l’entreprise : les données. Cela fait de lui à la fois :

• Une cible de choix : voler ses identifiants peut ouvrir l’accès direct à toutes les données sensibles de l’organisation.
• La personne la mieux placée pour réduire le risque : c’est lui qui conçoit les rôles et détermine qui peut lire, modifier ou administrer.

Un DBA qui prend le PAM au sérieux :

• Crée un compte par application, strictement limité aux données et aux opérations nécessaires.
• Sépare les rôles d’administration, d’audit et de sauvegarde.
• Révise régulièrement les accès : qui a encore quels droits, et pourquoi ?
• Conserve les preuves : journaux, demandes d’accès et approbations.
• Applique les exigences de la PSSI et des documents associés, ou demande leur mise à jour lorsque nécessaire.

C’est aussi l’esprit des référentiels internationaux comme ISO/IEC 27001 : contrôler les accès, gérer les droits privilégiés et protéger la journalisation.

Ce que je dirais aux décideurs (DG, DSI)

1. Demandez la liste des comptes privilégiés — systèmes, bases et applications : qui en est responsable, depuis quand sont-ils utilisés, et comment leur sécurité est-elle assurée ?
2. Interdisez formellement les comptes humains partagés. C’est une décision de gouvernance, pas seulement un projet technique.
3. Financez en priorité un coffre à secrets et une journalisation centralisée et protégée, avant tout produit sophistiqué.

Ce que je fais concrètement en tant que DBA

• Dresser l’inventaire exhaustif des comptes de base de données — humains, applications et services — avec un responsable désigné pour chacun.
• Passer systématiquement aux comptes nominatifs et réserver les comptes intégrés aux interventions qui le nécessitent.
• En l’absence d’un outil PAM, mettre en place un processus d’accès temporaire : demande tracée, rôle accordé par un administrateur, échéance définie et retrait vérifié.
• Effectuer les tâches courantes et les essais dans un environnement de test avec des données protégées. Pour les interventions indispensables en production, accorder un accès nominatif, justifié, limité dans le temps et tracé.
• Sortir les identifiants d’application des fichiers de configuration et mettre en place une rotation maîtrisée, sans interrompre le service, conformément à la PSSI.
• Envoyer les journaux hors des serveurs de base et réviser les accès chaque trimestre.

Par où commencer sans gros budget ?

1. Faire l’inventaire : un simple tableur partagé et sécurisé suffit pour démarrer.
2. Supprimer les comptes humains partagés inutiles et purger les comptes orphelins (anciens prestataires, collaborateurs ayant changé de poste).
3. Envoyer les journaux hors des serveurs de base.
4. Mettre en place un processus tracé pour les accès temporaires.
5. Choisir un outil PAM seulement après avoir clarifié et formalisé les besoins réels.

Une question pour finir

Combien de personnes connaissent aujourd’hui le mot de passe administrateur de vos bases de données, et comment cet accès est-il contrôlé ?

La réponse à cette question vous dira exactement où en est la sécurité de votre coffre-fort numérique.