Comprendre le contrôle d'accès : authentification, autorisation et gestion des ressources

Le contrôle d’accès est l’un de ces sujets qui semblent évidents jusqu’à ce qu’on l’examine de près. C’est aussi, année après année, la première catégorie du Top 10 de l’OWASP (Broken Access Control), et de loin la faiblesse la plus fréquente qu’on observe, tant dans l’industrie que dans nos propres analyses. La bonne nouvelle, c’est qu’une fois qu’on a les bonnes questions en tête, le sujet devient beaucoup plus simple.

Alors, c’est quoi exactement le contrôle d’accès ?

Le contrôle d’accès détermine qui peut faire quoi, sur quelle ressource. Quand une application reçoit une requête, elle doit répondre à trois questions — et les trois comptent.

1. Est-ce que je sais qui est l’utilisateur ? (authentification)

C’est l’étape de l’identité : l’utilisateur est-il vraiment qui il prétend être ? Les mots de passe, l’AMF, l’authentification unique (SSO) — tout ça répond à cette première question.

2. Est-ce que cet utilisateur est autorisé à effectuer cette action ? (autorisation)

Savoir qui est l’utilisateur ne dit rien sur ce qu’il a le droit de faire. Un utilisateur authentifié n’est pas nécessairement un utilisateur autorisé à supprimer, modifier ou administrer.

3. A-t-il le droit d’accéder à cette ressource précise ? (autorisation au niveau de l’objet)

C’est la question la plus souvent oubliée. Avoir le droit de voir « une » entrée ne signifie pas avoir le droit de voir « toutes » les entrées. Quand cette vérification est absente, on appelle ça de l’IDOR (Insecure Direct Object Reference) : il suffit de modifier un identifiant dans la requête pour accéder aux données de quelqu’un d’autre.

À retenir : oublier une seule de ces trois questions suffit à créer une vulnérabilité. Les trois forment un tout.

La question qu’on oublie : où la vérification se fait-elle ?

Répondre correctement aux trois questions ne suffit pas. Il faut aussi se demander où ces vérifications sont appliquées. Et c’est précisément là que se joue la différence entre une vraie mesure de sécurité et une simple convention d’interface.

Côté client

Les contrôles côté client sont appliqués par l’interface : un bouton « Supprimer » masqué, une option grisée, un menu qui n’apparaît pas. C’est utile et tout à fait normal. C’est ce qui rend une application agréable à utiliser et oriente les utilisateurs à l’écart des options qui seraient de toute façon refusées. Ce n’est pas ce qui empêche l’action : quand le contrôle d’accès est fait correctement, le serveur refuse l’opération peu importe ce que l’interface affiche.

Ces contrôles vivent du côté de l’utilisateur, et quiconque manipule directement les requêtes peut les contourner, car l’interface n’est qu’une porte parmi d’autres pour atteindre les données.

Côté serveur

Les contrôles côté serveur sont appliqués par l’application elle-même, là où les données résident. Ils ne dépendent pas de l’interface utilisée et ne peuvent pas être contournés en modifiant une requête.

C’est cette couche, et seulement cette couche, qui protège véritablement les données sensibles : consultation, modification, suppression, révélation d’un mot de passe, accès aux pièces jointes, etc.

Un contrôle côté client est une convention d’expérience utilisateur, pas une mesure de sécurité. La règle est simple : toute permission qui protège des données sensibles ou un flux critique doit être appliquée côté serveur. Un contrôle côté client peut l’accompagner, mais ne peut jamais le remplacer.

Ce que ça veut dire concrètement pour vos données

Prenons l’exemple de Remote Desktop Manager (RDM), notre application de bureau pour la gestion des connexions à distance et des identifiants. RDM offre une expérience riche : permissions, rôles, options affichées ou masquées selon l’utilisateur. Mais où ces permissions sont-elles réellement appliquées ? La réponse dépend entièrement de l’architecture du workspace auquel il se connecte.

• Un workspace SQL Server (connexion directe à la base de données). Dans ce cas, il n’y a pas de serveur d’application entre RDM et la base de données. RDM communique directement avec SQL Server. Les permissions existent, mais elles sont appliquées par le client. Autrement dit, elles vivent toutes côté client. La couche côté serveur — celle qui résiste à la manipulation directe — n’est tout simplement pas présente.
• Un workspace recommandé, adossé à un serveur d’application. Il en existe deux déclinaisons : Devolutions Server (DVLS), le workspace autohébergé que vous déployez sur votre propre infrastructure, et Devolutions Cloud, le workspace entièrement géré, hébergé dans l’infonuagique. Dans les deux cas, RDM reste le client, mais c’est le serveur qui valide chaque accès : qui vous êtes, ce que vous avez le droit de faire, et sur quelle ressource précise. Les trois questions trouvent leur réponse là où ça compte vraiment — côté serveur.

Ce n’est pas une question de bonnes intentions ou de configuration soignée. C’est une question d’architecture. Sans serveur d’application, il n’y a pas d’endroit physique où appliquer les contrôles côté serveur. C’est la raison fondamentale pour laquelle on recommande d’associer RDM à un workspace Devolutions — pas par préférence de produit, mais parce que l’architecture l’exige.

En résumé

• Un bon contrôle d’accès répond à trois questions : qui (authentification), quoi (autorisation) et sur quelle ressource (autorisation au niveau de l’objet).
• Un contrôle côté client améliore l’expérience, mais ne protège rien en lui-même, puisqu’il peut être contourné.
• Seul un contrôle côté serveur protège véritablement les données sensibles.
• Pour que cette couche côté serveur existe, il faut un workspace Devolutions derrière RDM : Devolutions Server (DVLS) si vous voulez autohéberger, ou Devolutions Cloud si vous préférez un service entièrement géré.

Si RDM se connecte actuellement directement à une base de données SQL Server, ça vaut la peine de vous demander : où mes contrôles d’accès sont-ils réellement appliqués ? L’architecture, et non la configuration, vous donnera la réponse honnête. Vous pouvez explorer les workspaces disponibles pour voir lequel convient à votre environnement.

Et le coût est rarement l’obstacle qu’on imagine : Devolutions Server et Devolutions Cloud offrent tous les deux une option gratuite pour démarrer. Utiliser Devolutions Server comme serveur central requiert simplement une licence Remote Desktop Manager Enterprise active — et comme connecter RDM à une base de données SQL Server nécessite déjà cette même licence Enterprise, vous détenez très probablement déjà tout ce qu’il vous faut pour faire la transition. (Accéder au workspace depuis un navigateur Web, sans RDM, utilise une licence d’accès client distincte.)