Sur la quantité d’applications et systèmes d’information que j’ai pu développer, analyser et auditer, une grande majorité présentaient des défauts de sécurité majeurs. C’est un constat assez effarant. Le plus inquiétant est que la gestion des droits d’accès est un sujet de second ordre dans les systèmes sus-mentionnés. La course à l’échéance et au tout à pas cher contraint les architectes et développeurs à prendre des raccourcis et décisions aberrantes. Ce constat est encore plus évident dans l’univers du « web » où les dates de livraison pour être « time to market » et la rentabilité à court terme sont des objectifs qui prévalent souvent sur la sécurité des utilisateurs et des données du client.
Mais avec un peu de culture sur la sécurité des systèmes et quelques ressources bien placées, développeurs et architectes peuvent limiter la casse et satisfaire les exigences des décideurs pressés peu scrupuleux …
Attention ! Cet article n’est pas un article sur le cyclimse. Merci de votre compréhension.
L’autorisation (en anglais authorization) est le processus qui permet de définir si un sujet a accès à un objet (ressource, fonctionnalité, information). Elle est à distinguer de l’authentification qui permet d’identifier si le sujet est bien celui qu’il prétend être.
Au passage, avec espièglerie je me permet de glisser une remarque sur la spécification HTTP que nous utilisons depuis des années que ce soit l’obsolète rfc 2616 section 14.8 ou la récente révision 7235 section 4.2. L’entête HTTP utilisée pour l’authentification s’appele Authorization, de qui se moque-t-on ? :)
(Pour ceux qui suivent on reprend les mêmes pour HTTP2 puisqu’il est compatible HTTP …)
Fin de la récréation.
L’autorisation est délivrée suivant la politique de contrôle d’accès. Il existe différentes politiques de contrôle d’accès, chacune étant adaptée à des besoins différents. Voyons les plus répandues.
Ici l’accès aux ressources est conditionné par l’identité de l’utilisateur ou par les groupes auxquels il est associé. C’est un modèle que vous connaissez sûrement, car c’est celui de base de beaucoup de systèmes de fichiers sur Unices.
Dans ce système, le propriétaire d’une ressource peut en changer les droits d’accès à discrétion …
Par exemple, en tant qu’utilisateur vous pouvez modifier les droits d’accès de vos fichiers (chmod) et même en transférer la propriété (chown)
Les caractéristiques les plus courantes de ces systèmes sont :
Ce type de contrôle d’accès s’avère peu pratique dans le cas où l’on souhaite contrôler ce que l’utilisateur fait de ses ressources. Par exemple je ne souhaite pas que mon gestionnaire de compte transfère ma liste de clients à un fournisseur qui utilise mon système.
Ce type de contrôle d’accès est géré par l’organisation ou l’entité qui la met en œuvre. Il attribue à l’information un niveau de secret et aux utilisateurs une accréditation (majoritairement temporaire). Un sujet peut accéder à un objet si son niveau d’accréditation est supérieur ou égal au niveau de secret de cet objet. Cependant un sujet peut créer un objet à un niveau de secret supérieur à son niveau d’accréditation.
Par exemple en tant que consultant en sécurité ou sous-officier, je peux accéder (temporairement) aux informations du niveau « diffusion restreinte », « confidentiel défense », « secret défense », mais pas au niveau « très secret défense » en lecture / écriture. En revanche je devrais pouvoir emettre un document « très secret défense »
On retrouve souvent dans ces systèmes des contraintes supplémentaires appliquées par les politiques de sécurité comme l’aspect temporel de l’accès aux données ou les canaux d’accès.
Par exemple : Les informations de niveau 3 ne sont accessibles que depuis le réseau interne uniquement pendant les heures de bureau.
Ce type de contrôle d’accès permet de limiter la diffusion de l’information, ce qui n’existe pas dans le DAC. Il est très approprié pour des systèmes de haute sécurité. Cependant il n’est pas très flexible et s’intègre mal à la notion de perimètre d’activité. Sa grande qualité est sa lisibilité ce qui est un avantage lorsqu’on audite la sécurité d’un système.
Dans cette politique les usagers du système se voient attribuer un rôle qui est souvent rattaché à une fonction dans un organisme. Prenons l’exemple d’un système d’information d’une chaîne de distribution, les rôles sont étroitement liés au fonctionnel de l’organisme, ainsi on pourrait retrouver les rôles caissier, chef de rayon, directeur de magasin, comptable …
La politique de sécurité définira que les rôles caissier et directeur de magasin ont accès à l’ouverture du tiroir caisse, Le rôle chef de rayon a accès aux marges et résultats de son propre rayon. Et ainsi de suite.
+————————————————————+
| |
| Permission |
+—————————————+ +————————+ | +——————————————+ |
| | | | | | | |
| Utilisateur +——————+ Rôle +—————+ | Action | |
| | | | | | | |
+—————————————+ +————————+ | | Objet | |
| | | |
| | Contexte | |
| +——————————————+ |
+————————————————————+
Les systèmes RBAC sont caractérisés par différents points :
Les rôles sont découpés et assignés en fonction du ou des rôles opérationnels d’une structure. Ce qui a pour avantage de simplifier l’élaboration de la politique de sécurité, ce qui évitera des erreurs et donc des failles potentielles.
L’attribution de rôles est faite de manière centralisée par un administrateur du système ou des responsables. Il y a donc un contrôle de la diffusion de l’information.
Ils peuvent introduire une dimension relationnelle entre le sujet et l’objet. Par exemple le chef de rayon ne peut modifier que les prix de son propre rayon.
Les rôles sont associés à des profils d’autorisations qui conditionnent l’accès aux transitions, actions, et informations.
Le contrôle d’accès peut être dépendant de l’état du système. Par exemple le directeur de magasin peut actionner la commande de tiroir caisse à n’importe quel moment alors que le caissier ne peut le faire que pendant la phase d’encaissement.
Ce système est adapté pour la sécurisation de système d’information d’entreprises et organisations, les applications web …
Il présente l’avantage de se mouler dans le domaine d’application dans lequel il est intégré. Son inconvénient est qu’il demande beaucoup de rigueur pour être mis en œuvre et maintenir son niveau de lisibilité.
Pour définir quels types de contrôle d’accès seront implémentés il faut réaliser un travail fastidieux mais nécessaire d’évaluation des risques.
Dans un premier temps il faut identifier quels éléments du système seront des objets et donc devront faire l’objet d’un contrôle d’accès.
Digression métaphysique
Inutile de répondre « tout », car tout est rien, et donc la réponse sera rien. Si tout est objet alors le notion d’objet n’a pas lieu d’être puisque rien n’est le contraire de ce tout. C’est le vide qui donne existence au plein.
Fin de la digression
Les objets pour rappel peuvent être de la donnée comme une fonction ( souvenez-vous du tiroir caisse … )
Puis il faut définir le degré de confidentialité, les critères de disponibilité et l’importance attachée à leur intégrité.
Le degré de confidentialité peut être défini suivant une échelle. Il détermine la portée ou le niveau de diffusion. La disponibilité permet d’exprimer des contraintes basées sur un état du système par exemple. ( encaissement terminé, entre 12h et 13h … ). L’importance de l’intégrité peut varier d’une donnée à une autre, avoir une adresse client modifiée peut être moins dommageable que la modification de destination de votre virement automatique vers les Îles Caïmans )
Et maintenant qualifier et quantifier l’impact d’une faille dans chacun de ces 3 critères pour chaque objet.
Avec ceci vous aurez déjà une bonne vision de ce qui est critique dans le système.
Au regard de ces indices vous allez pouvoir sélectionner une ou plusieurs méthodes de contrôle d’accès pour les objets de votre système. En se basant sur l’audience de ce blog ce sera RBAC dans 80 % des cas, cependant si vous construisez un système d’archivage de fichiers par exemple, il vous faudra surement coupler DAC avec RBAC.
Vous pouvez faire votre propre expérience vous-même ; mais je vais vous faire gagner du temps, de l’argent pour votre employeur, et de la sérénité pour vos clients et utilisateurs, en commençant par énumérer les erreurs à éviter.
Les cas énumérés ci-dessous sont tirés de faits réels, nul doute que vous saurez en trouver davantage voire d’ajouter les vôtres à cette liste.
Partir du principe que le système est sécurisé par obfuscation. Que l’URL n’est pas référencée, ou en cachant des données dans des _hidden fields_. Ne sous-estimez pas les utilisateurs. La gestion des autorisations ne doit jamais s’appuyer sur des données qui passent par le client.
Multiplier les rôles et niveaux de droits, au point de créer des conflits dans les niveaux de permission. Ce qui tôt ou tard donnera lieu à une faille due à une erreur de configuration.
Protégér l’interface de gestion des droits par un simple mot de passe. Si l’interface d’administration est le maillon le plus faible de la chaîne de sécurité, alors tous les efforts menés seront vains.
Mutualiser le compte administrateur entre plusieurs intervenants. Chacun son compte, un point c’est tout. Dans le cas contraire vous rencontrerez des soucis lorsqu’il faudra identifier les actions d’un utilisateur malicieux.
Baser le contrôle d’accès sur des informations fournies par le client (par opposition au serveur). Il suffira alors de modifier les données envoyées par le client pour gagner en privilèges …
Faire tourner votre application avec un compte système privilégié ou utiliser le compte super-adiministrateur du SGBD. La moindre vulnérabilité pourrait avoir des conséquences catastrophiques.
Coder les contrôles de rôle en dur dans l’application. La moindre modification de la politique de sécurité vous obligera à faire un cycle complet de développement.
Eparpiller la logique de contrôle d’accès dans l’application ou définir les droits d’accès manuellement à chaque point d’entrée de l’application. Un jour vous oublierez d’implémenter un contrôle d’accès. Vous augmentez le risque d’erreur en réduisant la lisibilité.
Avoir une politique de sécurité qui donne accès par défaut et donc n’interdit que pour certains rôles. Encore une fois vous serez vulnérable aux oublis et erreurs humaines.
Attribuer des permissions individuelles par utilisateur. Cela rendra l’administration tellement fastidieuse qu’il en résultera des erreurs de configuration.
Implémenter un système RBAC qui permet d’assigner des permissions à des rôles et des rôles à des utilisateurs. Ainsi vous pourrez facilement modifier les permissions attribuées à un rôle et donc de tous les utilisateurs qui sont attachés à ce rôle.
Rendre la délivrance d’autorisation contextuelle à la donnée. Par exemple un manager ne peut accéder qu’aux données de son équipe
Implémenter le contrôle d’autorisation systématique pour toutes les ressources/pages/endpoint de l’application. Au travers de filtres sur les actions/activités exposées aux utilisateurs par exemple. Cela vous évitera d’oublier de protéger une action.
Prévoir le cas de l’utilisateur anonyme. Il serait dommage qu’un utilisateur anonyme ou non authentifié ait plus de privilèges qu’un autre.
Restreindre l’accès à l’administration sur des plages réseau spécifiques. Cela réduit le champs des attaques sur l’interface d’administration.
Journaliser les refus d’autorisation et contrôler ce journal à interval défini. Cela peut mettre la puce à l’oreille sur une attaque qui se prépare.
Utiliser une authentification centralisée multi-facteur. Cela concerne l’authentification mais l’usurpation d’identité est un très bon moyen d’augmenter son niveau de privilège dans un système.
Une interface claire et lisible pour auditer l’état actuel des permissions. Ce qui mettra en évidence les incohérences de la politique de sécurité.
Consacrer davantage de temps à sécuriser l’interface d’administration.
Il est important que le rôle en lui même ne soit pas le critère d’autorisation, mais les permissions qui lui sont associées. Pour des raisons de facilité d’administration et de flexibilité. Un rôle n’est pas un droit, un rôle donne accès à des droits qui eux même donnent accès à des activités ou actions.
Finalement, la granularité des rôles doit être fine et les rôles d’un utilisateur souvent multiples. Prenons l’exemple de monsieur J qui au sein de son entité est à la fois chef de service et chef de projet, car ce monsieur a plusieurs casquettes, dans la réalité ça arrive presque constament. Il faut bien au moins 2 rôles associés à son utilisateur, auxquels sont associés les permissions qui permettent d’accomplir les tâches correspondantes à ces 2 rôles. Dans le cas contraire vous risquez de tomber dans des travers tels que :
Surtout ne partez pas bille-en-tête au moment de concevoir la gestion des droits d’accès dans un système. Il est tellement facile de se tromper et plus le système sera complexe plus l’erreur sera difficile à repérer. Nous avons tous plusieurs fois vérifié le fait que prendre des raccourcis dans le développement d’une application se paie très cher quelques mois plus tard. Et personnellement je n’ai jamais constaté l’inverse.
Alors puisqu’on le sait, pourquoi arrive-t-il encore de s’y laisser prendre ?
Pour le lecteur courageux qui souhaite approfondir la question RBAC, je propose cette lecture comme base de départ.
L’équipe Synbioz.
Libres d’être ensemble.