Autorisation et permissions : bonnes pratiques qui empêchent les accès non autorisés

La plupart des gens confondent authentification et autorisation, et cette confusion coûte cher. L'authentification consiste à prouver qui vous êtes, votre identifiant, votre mot de passe, votre jeton et vos données biométriques. Autoriser, c’est décider ce que vous, déjà identifié, avez le droit de faire. Ce sont des problèmes différents, et le deuxième est celui où résident la plupart des fuites et des fraudes internes.

Il est courant de voir des systèmes avec une connexion sans faille et une autorisation laxiste. La porte d'entrée est équipée d'une serrure biométrique, mais une fois à l'intérieur, n'importe qui peut ouvrir n'importe quel tiroir. L'attaquant n'a pas besoin de rompre votre authentification si, après s'être connecté avec un compte standard, il peut accéder à des données qu'il ne devrait pas.

Ce texte rassemble les étapes essentielles et les bonnes pratiques en matière d'autorisation. L’objectif est pratique : garantir que chaque utilisateur, système ou service accède exactement à ce dont il a besoin, ni plus, ni moins.

Le principe qui sous-tend tout : le moindre privilège

Si vous ne retenez qu'une idée de ce texte, prenez celle-ci : donner à chaque utilisateur l'accès minimum nécessaire pour faire son travail, et rien de plus. C'est le principe du moindre privilège et il résout, en pratique, la plupart des problèmes d'autorisation.

La tentation inverse est forte. Il est plus facile de donner un large accès « pour ne gêner personne » et d’en assumer les conséquences plus tard. Mais chaque autorisation supplémentaire est une porte de plus. Lorsqu’un compte est compromis, les dommages sont proportionnels à ce que ce compte pourrait faire. Les comptes dotés de trop de pouvoir transforment un petit incident en catastrophe.

Un moindre privilège n’est pas une méfiance envers les gens. Il s'agit de reconnaître que les comptes sont compromis, que des erreurs se produisent et que les dégâts doivent être contenus dès la conception.

Étape 1 : Modéliser les rôles avant de distribuer les autorisations

La distribution des autorisations utilisateur par utilisateur n'évolue pas et devient un gâchis en peu de temps. Une pratique mature consiste à organiser l’accès par rôles, le modèle connu sous le nom de RBAC (role-based access control).

Au lieu de dire « John peut consulter les rapports financiers », vous définissez le rôle « analyste financier » avec un ensemble d'autorisations et attribuez ce rôle à John. Lorsque John part et que Mary rejoint, vous échangez simplement qui occupe le rôle. Les autorisations sont décrites en un seul endroit, vérifiables et cohérentes.

Pour les scénarios plus complexes, il existe un contrôle basé sur les attributs (ABAC), où la décision prend en compte le contexte, l'heure, le lieu et la sensibilité des données. Mais commencez simplement. Un RBAC bien fait résout l’écrasante majorité des cas, et une complexité prématurée ne génère ici que des erreurs.

Étape 2 : Centraliser la décision d'autorisation

Une erreur architecturale courante consiste à disperser les règles d'autorisation dans le code, un « si » ici, une vérification là-bas. Au fil du temps, personne ne sait avec certitude qui peut faire quoi, et les règles diffèrent selon les parties du système.

La bonne pratique consiste à considérer l’autorisation comme une responsabilité centrale, avec un point clair où les décisions sont prises. Peu importe qu'il s'agisse d'une bibliothèque, d'un service ou d'un module, l'important est que la question « cet utilisateur peut-il faire ça ? recevoir une réponse cohérente, dans un endroit qui peut être audité et modifié.

Cela facilite également la vie lorsqu’il s’agit de prouver la conformité. Lorsqu'un auditeur, ou la LGPD elle-même, dans le cas de données personnelles, demande qui a accès à quoi, vous pouvez répondre en cherchant au même endroit, et non en cherchant dans l'intégralité du code.

Étape 3 : ne vous fiez jamais uniquement à ce que dit le client

Voici l'un des défauts les plus dangereux et les plus courants. Le frontend cache un bouton que l'utilisateur ne devrait pas voir et l'équipe considère le problème résolu. Ce n'est pas. Cacher le bouton est une expérience, pas une sécurité.

L'autorisation doit être vérifiée dans le backend, à chaque demande, à chaque fois. Un attaquant n'utilise pas votre interface, il appelle directement l'API. Si la seule barrière est visuelle, il n’y a pas de barrière. La règle est simple et non négociable : le client peut proposer, le serveur décide.

Il en va de même pour les identifiants. Si le système permet à l'utilisateur d'accéder à une ressource simplement en changeant le numéro dans l'URL, sans vérifier si cette ressource lui appartient, vous disposez d'une des vulnérabilités les plus exploitées qui existent, un accès inapproprié à un objet par référence directe, catalogué depuis des années par l'OWASP. Vérifiez la possession, pas seulement l'existence.

Étape 4 : Rendre l'accès révocable et vérifiable

L'accès accordé doit pouvoir être retiré, et rapidement. Lorsqu'une personne quitte l'organisation, change de rôle ou voit son compte compromis, vous devez couper l'accès immédiatement, et non lors du prochain sprint.

Cela suppose deux choses. Premièrement, savoir qui a accès à quoi, ce qui revient au point de centralisation et de modèle. Deuxièmement, enregistrez qui a accédé à quoi et quand. La journalisation des accès n'évite pas le problème, mais c'est ce qui vous permet d'enquêter, de répondre et d'apprendre après un incident. Un système sans piste d’audit est un système qui ne sait pas ce qui lui est arrivé.

Réflexion critique : l'accumulation silencieuse des privilèges

Il y a un problème qui s’aggrave sans que personne ne s’en aperçoive : l’accumulation des autorisations au fil du temps. La personne change de zone, obtient de nouveaux accès et conserve les anciens. Des années plus tard, elle accumule les autorisations de trois rôles qu'elle occupait autrefois. Personne ne l'a révisé, car réviser est un travail et ne vous donne pas de trophée.

Cette accumulation est une bombe à retardement. Lorsqu’un de ces comptes est compromis, l’accès est disproportionné. La défense est inconfortable mais nécessaire : révision périodique des accès. Regardez de temps en temps et demandez « est-ce que cette personne en a encore besoin ? Presque toujours, pour certaines autorisations, la réponse est non.

L’autre défi est culturel. L’autorisation restrictive génère des frictions, et les frictions génèrent des plaintes. L'utilisateur veut un accès large, le gestionnaire veut de l'agilité et la sécurité devient le méchant qui arrête tout le monde. Pour maintenir le moindre privilège, il faut la conviction des dirigeants et la certitude que les frictions d’aujourd’hui coûtent moins cher que les fuites de demain.

Ce qui reste

Une autorisation bien faite est invisible lorsqu’elle fonctionne et dévastatrice lorsqu’elle échoue. Cela n'apparaît pas dans une démonstration de produit, cela n'impressionne pas lors d'une réunion, et pourtant c'est l'une des décisions les plus importantes de tout système traitant de données sensibles.

Les étapes sont claires : le principe du moindre privilège, des rôles au lieu d'autorisations lâches, une prise de décision centralisée, une vérification côté serveur et un accès révocable et vérifiable. Aucun d’entre eux n’est sophistiqué. Tous sont souvent ignorés.

Si votre organisation gère des données sensibles et que vous ne savez pas qui peut accéder à quoi, c'est le bon moment pour les examiner. Sur le blog, vous trouverez d'autres textes sur la sécurité, le contrôle d'accès et la conformité qui approfondissent le sujet.