Élévation de privilèges

Élévation de privilèges : Situation où un compte obtient des droits supérieurs à ceux prévus, souvent par un contrôle manquant sur une action sensible.

Famille « Sécurité ». La définition ci-dessus suffit pour suivre une réunion. La suite sert à écrire une exigence que personne ne pourra interpréter à sa façon.

Où intervient Élévation de privilèges dans un projet

Sur un projet d’application, Élévation de privilèges se traite pendant la conception. Ajouter la sécurité à la fin revient à réécrire des parties déjà recettées, donc à les recetter de nouveau.

Sur un projet réel, la question ne se pose jamais en théorie : elle arrive dans un devis, dans une réunion de cadrage ou dans un rapport de recette.

De la définition à la ligne de cahier des charges

Dans un cahier des charges, Élévation de privilèges s’écrit en exigence vérifiable, avec le référentiel appliqué et le moment où le contrôle aura lieu.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Les modalités d’authentification, second facteur compris s’il est requis.
• Le stockage des secrets, côté application comme côté serveur.
• La gestion des accès de production, et leur revue périodique.
• Le test de restauration des sauvegardes, réellement exécuté au moins une fois.

Cette formulation se rédige avant la consultation, pas après réception des propositions : c’est elle qui rend deux devis comparables entre eux.

Le modèle de cahier des charges du guide reprend ces rubriques dans l’ordre attendu par une agence, et la grille de lecture des devis montre à quoi ressemble un chiffrage comparable.

Ce que ça change au moment de la recette

Élévation de privilèges se vérifie par un tiers, avec un rapport écrit et une liste de corrections datées.

• Vérifier que les correctifs annoncés ont été retestés, et par qui.
• Observer le comportement de l’application avec un jeton expiré.
• Vérifier que les contrôles d’accès sont bien refaits côté serveur.

Ces vérifications s’inscrivent au cahier de recette, avec un nom en face de chacune. Une case sans responsable reste vide.

Ce qui tourne mal le plus souvent

Les mêmes causes reviennent d’un projet à l’autre, quel que soit le prestataire et quelle que soit la taille du budget.

• Faire confiance aux contrôles réalisés dans l’application sans les refaire côté serveur.
• Journaliser des données sensibles pour faciliter le débogage, puis oublier de retirer les traces.
• Protéger l’application et négliger les interfaces qu’elle appelle.
• Considérer qu’une application sans données bancaires n’intéresse aucun attaquant.
• Employer le mot sans le définir, et laisser chaque partie prenante y mettre son propre sens.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• Réponse à incident
• Conformité continue
• EBIOS Risk Manager
• Gestionnaire de mots de passe
• Tableau de bord sécurité

Questions fréquentes

Qu’est-ce que « Élévation de privilèges » ?

Situation où un compte obtient des droits supérieurs à ceux prévus, souvent par un contrôle manquant sur une action sensible. Le mot est employé tel quel par les équipes francophones. C’est celui à utiliser dans les échanges avec une agence, y compris quand la traduction française existe.

Faut-il un audit de sécurité sur toutes les applications ?

Pas au même niveau. Une application sans compte ni donnée personnelle n’appelle pas l’effort d’un service bancaire. Le classement des données manipulées donne la mesure du travail à prévoir.

Comment savoir si le budget annoncé est cohérent ?

En comparant le périmètre écrit aux fourchettes constatées en France, détaillées poste par poste sur le guide des prix. Un chiffre isolé ne veut rien dire sans le périmètre qui va avec.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.