L'audit ISO demande la matrice des accès. On découvre douze comptes admin, trois clés SSH sans propriétaire, un accès support hébergeur « permanent pour faciliter les tickets », et un développeur avec droits production « le temps du debug » — depuis huit mois.
Le principe du moindre privilège est une évidence sur le papier : chaque identité ne reçoit que les droits nécessaires à sa tâche, le temps nécessaire. En hébergement, la difficulté n'est pas le principe — c'est ne pas sacrifier la capacité d'intervention quand le site tombe à 3 h du matin.
Cartographier avant de couper
Avant de révoquer quoi que ce soit, produisez une cartographie en trois couches.
Couche hébergeur : qui chez le prestataire peut toucher votre VPS, bucket ou panel ? Accès rescue, console, API support.
Couche infrastructure client : comptes cloud IAM, groupes, policies, clés API, accès base read/write.
Couche applicative : admin CMS, back-office métier, CI/CD avec deploy en production.
| Rôle | Droits typiques | Durée | Revue |
|---|---|---|---|
| Dev quotidien | Staging, read-only prod logs | Permanent | Trimestrielle |
| Exploitation / SRE | Deploy prod, restart, backup trigger | Permanent | Mensuelle |
| Support hébergeur | Ticket-scoped, pas de clé SSH client | Par incident | Chaque ticket |
| Break-glass | Full admin | Minutes | Post-incident |
Réduire les privilèges sans cartographie, c'est couper le câble qui tenait encore debout la prod.
Patterns qui tiennent en production
RBAC par environnement. Prod, staging et dev avec comptes séparés. Aucun token CI ne pointe vers prod sans pipeline validé.
Élévation just-in-time. L'astreinte demande un rôle élevé pour deux heures ; approbation manager ; révocation automatique.
Comptes de service limités. Chaque microservice ou cron reçoit uniquement la ressource qu'il consomme — pas s3:* sur tout le compte.
Support hébergeur encadré. Clause contractuelle : accès uniquement sur invitation, durée max, notification client, journaux transmis sur demande.
Testez un scénario d'incident simulé : l'astreinte doit pouvoir redémarrer un service en moins de quinze minutes sans root permanent.
Erreurs fréquentes
Tout bloquer d'un coup. Le support interne contourne avec des comptes personnels non gouvernés.
Oublier les clés API oubliées. Un ancien plugin SaaS conserve un accès write S3.
Confondre moindre privilège et obscurité. Cacher le panel admin sans MFA ni journaux ne réduit pas le risque.
Ignorer les droits hébergeur. Vous durcissez IAM côté client pendant que le prestataire garde un accès rescue illimité.
Programmez une revue trimestrielle : dernières connexions, comptes inactifs 90 jours, alignement avec l'organigramme.
Le sommet : le privilège permanent est une dette
Le sommet : la conformité n'attend pas l'absence d'admin, mais une gouvernance visible des élévations.
Décider et avancer sans angle mort
Exportez la liste IAM, panel et SSH cette semaine. Supprimez les comptes orphelins, activez MFA partout, définissez une procédure break-glass d'une page testée en simulation.
Confrontez votre hébergeur sur l'accès support : durée, notification, journaux. Utilisez l'annuaire et le comparateur. Complétez avec Accès administrateur : piste d'audit. Planifiez une revue dans 90 jours avec métrique : nombre de comptes full admin, durée moyenne des élévations just-in-time.
Questions fréquentes
Le moindre privilège s'applique-t-il à l'hébergeur aussi ?
Oui. Le support ne devrait accéder à votre environnement qu'avec ticket, durée limitée et périmètre restreint — pas un accès permanent root.
Comment démarrer sur un VPS ou un cloud ?
Inventaire des comptes, suppression des orphelins, séparation prod/staging, MFA, puis réduction progressive des droits IAM en observant les refus légitimes.
Comment gérer l'astreinte sans compte partagé ?
Comptes nominatifs avec élévation temporaire, break-glass documenté et journalisé — pas de mot de passe root commun.
Le moindre privilège suffit-il pour la conformité ?
Non. Accompagnez-le de journaux admin, revues périodiques et tests de restauration.
Le moindre privilège mature ne se mesure pas aux comptes supprimés — mais aux interventions d'urgence qui restent possibles sans root éternel.