Comment concevoir un contrôle d'accès basé sur les rôles?
J'essaie de suivre le modèle de contrôle d'accès des bases de rôles pour restreindre ce que les utilisateurs peuvent ou ne peuvent pas faire dans mon système.
Jusqu'à présent, j'ai les entités suivantes:
tilisateurs - Les personnes qui utiliseront le système. Ici, j'ai des noms d'utilisateur et des mots de passe. rôles - Collection de rôles que les utilisateurs peuvent avoir. Des trucs comme manager, admin, etc. ressources - Les choses que les utilisateurs peuvent manipuler. Comme les contrats, les utilisateurs, les ébauches de contrats, etc. opérations - Les choses que les utilisateurs peuvent faire avec les ressources. Comme créer, lire, mettre à jour ou supprimer.
Maintenant, mon doute monte ici dans le diagramme où j'ai une relation comme celle-ci:
opérations (0 .. *) sont exécutées sur ressources (0 .. *) qui génère une table que j'ai appelée permissions et qui stockera opération et ressource.
Le tableau des autorisations ressemblera à ceci (une ligne): ID: 1, opération: créer, ressource: contrat.
Ce qui signifie un permission à créer a contrat.
Je l'ai fait de cette façon parce que je pense que certaines ressources peuvent ne pas avoir toutes sortes d'opérations. Par exemple, pour l'enregistrement contrats, les utilisateurs peuvent télécharger des fichiers, mais cela opération n'est pas disponible pour enregistrer un fournisseur .
Alors maintenant, quand le administrateur donnera autorisations à un rôle, il n'aura pas de liste de ressources avec chaque opération enregistrée dans le système.
Je pense que chaque ressource a sa propre collection de opérations qui peut être exécutée sur lui.
Je peux préciser si quelque chose n'est pas compréhensible.
Est-ce la bonne façon d'implémenter le rbac?
MODIFIER
Ce que je veux dire, c'est qu'en ayant une table permissions qui a opération et ressource, j'ai DEUX tables supplémentaires parce que je veux associer ressources avec opérations. J'aurais pu aussi juste faire ressources avoir autorisations où la table des autorisations stockerait les autorisations.
Mais ce qui se serait passé, c'est que certaines autorisations qui n'existent même pas pour certaines ressources seraient apparues lorsque l'administrateur les aurait attribuées.
Donc, je veux savoir du point de vue de la conception de la base de données si cette autorisation de table qui a une opération de colonne et une autre ressource est correcte? Vais-je rencontrer des problèmes s'il reste comme ça?
Votre design me semble assez proche. Juste quelques suggestions.
utilisateurs - Personnes qui utiliseront le système. Ici, j'ai des noms d'utilisateur et des mots de passe.
Bien
rôles - Collection de rôles que les utilisateurs peuvent avoir. Des trucs comme manager, admin, etc.
Très bien aussi. Mais vous aurez également besoin d'une entité/table "UserRoles" qui vous indiquera quels utilisateurs ont quels rôles. Il est probable qu'un utilisateur donné puisse avoir deux rôles ou plus.
ressources - Choses que les utilisateurs peuvent manipuler. Comme les contrats, les utilisateurs, les ébauches de contrats, etc.
Ce pourrait être juste une question de sémantique. Je ne pense pas que les utilisateurs manipulent directement les ressources; les rôles le font. Ainsi, il va utilisateur -> rôle utilisateur -> rôle -> opération -> ressource
opérations - Choses que les utilisateurs peuvent faire avec les ressources. Comme créer, lire, mettre à jour ou supprimer.
oui, sauf "rôles" au lieu de "utilisateurs"
Le tableau des autorisations ressemblera à ceci (une ligne): ID: 1, opération: créer, ressource: contrat. Ce qui signifie une autorisation de créer un contrat.
Hmmm. Il y a deux façons de procéder. Vous pourriez avoir la table d'autorisations que vous décrivez, mais vous auriez également besoin d'une table/entité RolePermissions supplémentaire qui vous indique quel rôle a quelle autorisation. Mais je ne suis pas sûr que ce soit nécessaire.
Une manière plus simple de le faire est une table/entité d'autorisations avec ces colonnes/attributs: ID de rôle, ID d'opération, ResourceID. De cette façon, les opérations x combinaisons de ressources sont affectées directement à un rôle, plutôt que chargées dans une autorisation affectée à un rôle. Il élimine une entité. Il n'y a vraiment pas besoin d'une table d'autorisations indépendante des rôles, sauf si vous souhaitez prédéfinir les combinaisons d'autorisations autorisées et celles qui ne le sont pas.
Je n'utiliserais ni n'implémenterais RBAC. Au lieu de cela, j'utiliserais ABAC. Laisse-moi expliquer...
- RBAC ou contrôle d'accès basé sur les rôles concerne la gestion des utilisateurs et l'attribution des rôles. Dans RBAC, vous pouvez dire qu'Alice est gestionnaire. Vous pouvez définir des autorisations statiques avec cela. Par exemple, un gestionnaire peut approuver des prêts. Il existe donc un lien entre Alice et le gestionnaire pour approuver Loan en tant que permission. Il existe de nombreux systèmes qui vous permettront de le faire, vous n'avez donc pas besoin d'implémenter vos propres tables. Même LDAP prend en charge des ensembles limités de RBAC. C'est OK tant que vous disposez d'un ensemble relativement restreint de rôles et d'autorisations. Mais que faire si vous souhaitez prendre en compte des autorisations spécifiques comme c'est votre cas? Afficher, supprimer, insérer? Et si vous voulez prendre en compte les relations?
- L'ABAC ou le contrôle d'accès basé sur des attributs concerne une autorisation à granularité fine, basée sur des règles. Avec ABAC, vous pouvez utiliser des rôles tels que définis dans RBAC et écrire des politiques, par exemple
- Les gestionnaires peuvent consulter les documents de leur service
- Les employés peuvent modifier les documents dont ils sont propriétaires
Dans votre question, vous avez essentiellement défini le modèle d'information. Vos objets et leurs attributs par exemple un utilisateur (nom, mot de passe, service ...); un objet (par exemple un contrat) et ainsi de suite.
Dans ABAC, vous découpleriez donc entièrement votre code/logique d'application de la logique d'autorisation qui est ensuite stockée en tant que stratégies à l'aide d'attributs. Les autorisations elles-mêmes sont stockées directement dans la stratégie (voir l'exemple ci-dessus). L'architecture de déploiement ABAC ressemble à ce qui suit
Le fait est que si vous adoptez une approche ABAC, vous écrivez des politiques pour ABAC (soit en XACML ou ALFA - il y a beaucoup d'outils pour cela) et vous n'avez plus jamais à coder ou implémenter RBAC ou à contrôler l'accès.