Comptes à privilèges, PAM et bastion d'administration

Un compte à privilèges est un compte qui peut modifier la configuration d'un système, gérer les droits des autres ou accéder à toutes les données : administrateur du domaine, root, compte de service, administrateur d'un pare-feu ou d'une console cloud. Ces comptes sont la cible prioritaire des attaquants, car ils ouvrent tout le système d'information. On les protège par des comptes d'administration dédiés, un poste d'administration réservé, une authentification multifacteur, un bastion d'administration par lequel passent et sont enregistrées toutes les connexions, et la gestion des accès à privilèges (PAM).

Pourquoi les comptes à privilèges sont la cible

Le scénario d'une attaque par rançongiciel suit presque toujours le même chemin :

1. un salarié ouvre une pièce jointe piégée : l'attaquant contrôle un poste ;
2. il récupère sur ce poste les traces d'authentification d'un administrateur qui s'y est connecté un jour pour dépanner ;
3. avec ce compte, il rebondit de machine en machine (mouvement latéral) jusqu'aux contrôleurs de domaine ;
4. administrateur du domaine, il désactive les sauvegardes et déploie le chiffrement sur toutes les machines en même temps.

L'étape 2 est celle qu'une bonne gestion des comptes à privilèges casse : si l'administrateur n'utilise jamais son compte d'administration sur un poste ordinaire, il n'y a rien à récupérer.

Les comptes à privilèges d'une organisation

Les mesures de base : séparer, réduire, protéger

L'ANSSI a publié des Recommandations relatives à l'administration sécurisée des systèmes d'information (version 3.0, 2021). Les mesures qui reviennent dans les sujets :

• un compte d'administration distinct du compte bureautique : Antoine Mercier lit ses courriels avec amercier et administre avec a.mercier.adm, qui n'a ni messagerie ni accès à Internet ;
• un poste d'administration dédié, sans navigation Internet ni messagerie, qui sert uniquement à administrer ; à défaut, une séparation forte (machine virtuelle d'administration sur un poste maîtrisé) ;
• des flux d'administration isolés : les interfaces d'administration (SSH, RDP, WinRM, consoles web) ne sont joignables que depuis le réseau d'administration ou le bastion ;
• l'authentification multifacteur sur tous les comptes à privilèges ;
• le moindre privilège : le nombre d'administrateurs du domaine se compte sur les doigts d'une main ; les autres tâches sont déléguées (réinitialiser un mot de passe dans une OU, gérer un serveur précis) ;
• la journalisation de toutes les actions d'administration, centralisée hors de portée des administrateurs eux-mêmes.

Le modèle en niveaux

Dans un domaine Active Directory, les ressources sont classées en niveaux selon leur criticité, et chaque compte d'administration n'administre qu'un niveau.

La règle : un compte d'un niveau ne se connecte jamais à une machine d'un niveau inférieur. Un administrateur du domaine qui ouvre une session sur un poste de travail pour dépanner y laisse des traces d'authentification ; si le poste est compromis, le domaine l'est aussi. L'ANSSI publie des recommandations dédiées à l'administration sécurisée des systèmes reposant sur Active Directory, construites sur ce cloisonnement.

Les mots de passe des administrateurs locaux : LAPS

Un parc installé à partir d'une même image a souvent le même mot de passe d'administrateur local sur tous les postes. Un attaquant qui récupère l'empreinte de ce mot de passe sur un poste l'utilise sur tous les autres (pass-the-hash, chapitre 7).

Windows LAPS (Local Administrator Password Solution), intégré à Windows depuis 2023, règle le problème : chaque poste génère un mot de passe d'administrateur local unique et aléatoire, le renouvelle régulièrement et le stocke dans l'annuaire (ou dans Entra ID), chiffré et lisible seulement par les comptes autorisés. Le technicien qui en a besoin le lit, l'accès est tracé, et le mot de passe peut être renouvelé après usage.

# Lire le mot de passe administrateur local du poste PC-0012 (droit délégué au support)
Get-LapsADPassword -Identity "PC-0012" -AsPlainText
# Forcer son renouvellement après l'intervention
Reset-LapsPassword    # à exécuter sur le poste lui-même

Pour les comptes de service, les comptes de service gérés de groupe (gMSA) d'Active Directory ont un mot de passe long, géré et renouvelé automatiquement par l'annuaire : aucun humain ne le connaît, il ne peut pas être deviné ni écrit sur un post-it.

Le bastion d'administration

Un bastion est un serveur placé en coupure entre les administrateurs et les systèmes à administrer : toutes les connexions d'administration passent par lui, et seulement par lui.

Ce que le bastion apporte :

Les solutions vont des passerelles libres comme Apache Guacamole (accès SSH et RDP par le navigateur) aux solutions complètes de gestion des accès à privilèges (PAM, Privileged Access Management) du marché, dont certaines sont certifiées par l'ANSSI. Une solution PAM ajoute l'accès juste-à-temps : un droit d'administration est accordé pour une intervention et une durée, après approbation, puis retiré automatiquement.

Côté SISR : le plan d'action chez Sorbier Logistique

Antoine Mercier constate que les trois membres du service informatique sont tous administrateurs du domaine, qu'ils administrent depuis leur poste habituel, que le mot de passe d'administrateur local est le même sur les 30 postes, et que le prestataire du logiciel de paie se connecte en RDP directement depuis Internet. Son plan :

1. créer pour chacun un compte d'administration nominatif, distinct de son compte de tous les jours, et ne laisser que lui-même dans les administrateurs du domaine ; déléguer le reste (réinitialisation des mots de passe, gestion des postes) ;
2. activer la MFA sur tous ces comptes ;
3. déployer Windows LAPS sur les postes et les serveurs ;
4. remplacer les comptes de service à mot de passe fixe par des gMSA quand l'application le permet ;
5. installer un bastion : le prestataire s'y connecte avec un compte nominatif et la MFA, n'accède qu'au serveur de paie, et ses sessions sont enregistrées ; fermer le RDP exposé sur Internet ;
6. sous Linux, interdire la connexion SSH directe de root (PermitRootLogin no dans /etc/ssh/sshd_config), imposer les clés SSH (PasswordAuthentication no) et passer par sudo, qui journalise chaque commande. L'authentification par clé SSH repose sur une paire de clés, comme une passkey : la clé publique est copiée dans ~/.ssh/authorized_keys sur le serveur, la clé privée reste sur le poste d'administration, protégée par une phrase de passe. Génération : ssh-keygen -t ed25519. Le détail est dans le cours Administration Linux ;
7. centraliser les journaux d'administration sur un serveur que les administrateurs ne peuvent pas modifier, et alerter sur les ajouts au groupe des administrateurs du domaine.

Côté SLAM : les secrets et les fonctions d'administration

Pour un développeur, les privilèges prennent d'autres formes :

• les secrets dans le code : un mot de passe de base de données ou une clé d'API écrits dans le code source finissent dans le dépôt Git, et y restent dans l'historique même après suppression. Les secrets vont dans des variables d'environnement ou un coffre-fort de secrets, le fichier .env est dans .gitignore, et un outil de détection de secrets analyse les commits. Un secret publié par erreur se renouvelle immédiatement : le supprimer du dépôt ne suffit pas ;
• le compte de base de données de l'application n'a que les droits nécessaires, jamais root (chapitre 9) ; les évolutions de structure passent par un autre compte, utilisé seulement lors des déploiements ;
• les fonctions d'administration de l'application (gestion des comptes, des rôles, export de données) demandent une réauthentification récente, sont journalisées et, si possible, accessibles seulement depuis le réseau interne ;
• les jetons de l'intégration continue ont des droits limités au dépôt et à la tâche, et une date d'expiration.

Tracer les actions d'administration

La journalisation des accès est une exigence de sécurité, mais aussi une obligation : le RGPD (article 32) impose des mesures de sécurité adaptées, et la CNIL a précisé dans sa recommandation sur la journalisation (délibération n° 2021-122 du 14 octobre 2021) qu'une durée de conservation de six mois à un an est en général adaptée pour les journaux d'accès, sauf obligation ou risque particulier justifiant une autre durée. Les journaux eux-mêmes contiennent des données personnelles (identifiants, adresses IP) et doivent être protégés.

Le sujet SLAM de 2024 (U6) faisait travailler ces notions sur les journaux d'authentification d'applications : rappeler l'objectif réglementaire de la traçabilité des accès, distinguer archivage (conserver des données qui ne servent plus au quotidien, pour une durée imposée, à des fins de preuve) et sauvegarde (pouvoir restaurer après une perte), puis dire si la confidentialité et l'intégrité des journaux archivés étaient garanties par une procédure qui les compressait et les chiffrait, sans vérifier de somme de contrôle.

Comment l'E7 l'interroge

• SISR : relever les erreurs d'une organisation de l'administration (compte partagé, administration depuis le poste bureautique, mot de passe local identique) ; proposer une architecture avec bastion et règles de pare-feu ; justifier LAPS ou les gMSA ; sécuriser l'accès d'un prestataire.
• SLAM : repérer un secret dans un extrait de code ou de configuration ; proposer des droits minimaux pour le compte applicatif ; compléter une méthode de journalisation (le sujet de 2025 demandait d'ajouter l'adresse IP aux traces).
• Tronc commun : expliquer l'intérêt de la traçabilité, distinguer archivage et sauvegarde, justifier la protection des journaux.

Pour aller plus loin. Le chapitre Administration sécurisée du cours Cybersécurité des infrastructures place le bastion dans l'architecture réseau, avec les flux d'administration à filtrer.

Exercices