Résumé

Cette série d’articles illustre la mise en place de politiques de contrôle d’accès basées sur des rôles au sein d’une application web. Nous prendrons en exemple un service numérique composé un frontend en Angular et d’un backend en Spring Boot. La gestion des utilisateurs se ferra grâce à Keycloak.

Dans ce premier article, nous allons présenter les enjeux de sécurité relatifs du contrôle d’accès. Par la suite, nous mettrons en places les différentes briques du système décrit en exemple.

Qu’est ce que le contrôle d’accès ?

Dans le cadre du développement de services numériques, les applications produites doivent quasiment toujours être utilisées avec des d’utilisateurs aux besoins variées et qui ne nécessitent pas tous l’accès aux même ressources. Certaines ressources doivent aussi être protégées ou accessibles uniquement par certains utilisateurs.

Prenons en exemple une application web permettant d’effectuer des démarches administratives en ligne. Tout utilisateur authentifié doit être en mesure de créer des demandes via des formulaires, et de consulter les demandes qu’il a effectué pour en connaître le status de traitement. Les agents de l’administration doivent quand à eux valider ou refuser des demandes. Ce mécanisme de validation doit être uniquement accessible aux agents et non simplement aux utilisateurs authentifiés. On a ici deux types d’utilisateurs avec deux modes d’accès différents aux ressources que composent les opérations sur les demandes.

Le contrôle d’accès désigne ainsi les mécanismes permettant de réguler l’accès à des ressources. Celles-ci peuvent être de nature diverses comme par exemple des bases de données, des espaces de stockages de fichiers ou encore des routes dans une API. Le rôle du contrôle d’accès est de s’assurer que seule une entité (en général un utilisateur) autorisée peut interagir avec les ressources dont elle fait la demande.

On distingue usuellement deux parties dans le contrôle d’accès : l’authentification et l’autorisation.
Dans la première, l’objectif est de vérifier l’identité d’un utilisateur. Il existe de nombreuses méthodes d’authentification comme l’utilisation d’un mot de passe, de jetons, de certificats ou même de clé physique.
Dans la deuxième, on souhaite déterminer les permissions relatives à l’usage notre système dont l’utilisateur dispose. Les permissions sont en général associées à des opérations à réaliser sur des ressources (création, lecture, modification, suppression).

Pourquoi est-ce important ?

En permettant la restriction de l’usage de ressources, le contrôle d’accès se trouve donc en première ligne de la stratégie de sécurité d’un service numérique. Ainsi, une mauvaise configuration de cette brique est souvent à l’origine de failles de sécurité qui peuvent donner lieu par la suite à des incidents en production et des attaques.

Le rapport OWASP Top 10 est un document de référence produit par la fondation OWASP en agrégeant des rapports de tests de pénétrations et d’audits de cybersécurité. Il présente les 10 vulnérabilités les plus représentées. Dans sa version la plus récente datant de 2021, on retrouve à la première place du classement les politiques de contrôles d’accès non fonctionnelles avec une présence (plus ou moins sévère) dans 94% du jeux de données. Cette vulnérabilité conduit même à des incidents dans environ 4% de cas.

• A01:2021-Broken Access Control moves up from the fifth position; 94% of applications were tested for some form of broken access control. The 34 Common Weakness Enumerations (CWEs) mapped to Broken Access Control had more occurrences in applications than any other category.

Ue manière simple et efficace d’éviter ce type de vulnérabilité est de systématiquement refuser l’accès à n’importe quelle ressource non publique tant qu’aucune autre politique de permission n’a été mise en place : c’est le refus par défaut. OWASP préconise aussi d’appliquer le principe de moindre privilège qui consiste à donner à un utilisateur uniquement les permissions dont il a besoin pour effectuer les actions liées à son utilisation du service, plutôt que de lui attribuer un rôle avec des permissions très étendues au delà de ses besoins.

Pour les applications backend, on retrouve dans la plupart des frameworks la possibilité de créer des middlewares ou des configurations de sécurité permettant la gestion globale de l’accès à toutes les routes exposées. La SecurityFilterChain de Spring Security en est un exemple avec la possibilité de faire appel à la méthode denyAll() qui rejète toutes les requêtes effectuées par défaut.

Application pratique et fil rouge

Au cours de cette série d’articles, nous utiliserons en fil rouge l’exemple de l’application web permettant d’effectuer des démarches administratives. On définit les types d’utilisateurs :

• les citoyens : il s’agit d’utilisateurs authentifiés ayant la possibilité de créer une demande et de lister seulement les demandes qu’ils ont créées.
• les agents : des utilisateurs authentifiés qui peuvent lister toutes les demandes et les valider.

Pour rester efficace mais représentatif d’un cas d’usage réel plus complexe, on mettra en place l’architecture suivante :

• un application frontend, réalisée avec le framework Angular, servira d’interface utilisateur
• un backend réalisé en Java avec le framework Spring Boot, exposera une API REST permettant des opérations sur les demandes
• une brique de gestion des utilisateurs via Keycloak
• une base de données PostgreSQL pour la persistence

L’interface utilisateur disposera pour tout utilisateur authentifié d’un formulaire pour effectuer une demande et d’une page recensant les demandes effectuées. Les agents auront eux accès à la liste des demandes avec un bouton permettant de les valider.

L’API REST exposée par le backend disposera des routes suivantes :

Accès à tous les utilisateurs authentifiés :

• POST /demandes
• GET /demandes/me

Accès restreint aux agents :

• GET /demandes
• PUT /demandes/:id

Conclusion

Le contrôle d’accès est à la base de la stratégie de sécurité d’un service numérique et constitue la première barrière sur laquelle un attaquant potentiel pourra se retrouver bloquer.

Nous avons défini un exemple d’application web avec des contraintes métier nécessitant la séparation d’utilisateurs en groupes aux permissions distinctes, et l’architecture technique qui nous permettra de développer une telle application. Cette application poursuivra son développement dans les futures articles de cette série.