Ce principe, n’est pas toujours bien appliqué dans les applications complexes, dont l’architecture est multicouche, c’est à dire des applications qui ne s’exécutent pas uniquement dans la session de l’utilisateur. Un exemple typique est une application web accédant à une base de données. Souvent, l’application web s’authentifie auprès de la base de données avec un compte applicatif dédié unique, dont le niveau de privilège sur la base de données correspond aux privilèges nécessaires pour l’utilisateur le plus privilégié de l’application.
Du point de vue de la sécurité cette situation n’est pas optimale car, en cas d’exploitation d’une vulnérabilité dans l’application web, l’attaquant dispose alors des privilèges les plus élevés sur les données de la base et ce, quels que soient les privilèges dont il dispose dans l’application web. Dans le jargon de la cybersécurité, la vulnérabilité sera alors classée de type “élévation de privilèges”.
Pour éviter cela, il est possible de déployer une infrastructure d’authentification qui permette de propager l’identité et les privilèges de l’utilisateur depuis l’application cliente (typiquement le navigateur) jusqu’à la base de données. Dans cette configuration, les données de la base sont accédées sous l’identité de l’utilisateur et avec ses propres privilèges. Dit autrement, l’application web ne dispose plus d’un compte dédié, mais ne fait que relayer les droits de l’utilisateur auprès de la base de données. En cas d’exploitation d’une vulnérabilité dans l’application web à partir d’un compte utilisateur non privilégié, l’attaquant ne peut alors plus accéder aux données privilégiées de la base de données, puisque l’application web ne dispose pas de ces privilèges.
La sécurité globale de l’application est alors substantiellement améliorée et, s’il reste nécessaire de corriger rapidement toute vulnérabilité découverte dans l’application web, leur criticité s’en trouve réduite.
Stéphane ADENOT
