Sécurité sans rôle?

Question

Ceci est une question discutable car je ne suis plus sur ce projet, mais il continue à me déranger. Je me demande si quelqu'un a une meilleure idée de référence future et de bonnes pratiques générales de programmation.

L'approche de la sécurité des manuels est la «sécurité basée sur les rôles». Chaque écran, rapport ou autre tâche est associé à un ou plusieurs rôles; chaque utilisateur est assigné à un ou plusieurs rôles; et alors chaque utilisateur peut exercer les écrans, etc. qui correspondent à ses rôles et rien d'autre. Droite?

Il y a quelques années, j'ai dirigé une équipe de développement d'un système de gestion de manuels techniques militaires. Chaque manuel avait un «gestionnaire de contenu technique», la personne responsable de la rédaction ou de l'édition; un «gestionnaire de stock», chargé de garder la trace des copies et de les faire expédier; et un «gestionnaire administratif», responsable du budget et qui a donc décidé à quelle fréquence le livre serait révisé, combien de copies seraient imprimées, et ainsi de suite. Bien sûr, chaque livre avait un groupe de personnes qui commanderaient des copies et le liraient. (Comme c'était l'armée, vous deviez être autorisé à mettre la main sur un livre, les autorisations de sécurité et tout le reste.) Nous ne nous préoccupions pas des lecteurs, mais plutôt des gens de chaque base qui géraient les bibliothèques. , mais ce n'est pas vraiment pertinent ici. Alors ... ce sont des "rôles" évidents, mais un rôle était lié à un livre en particulier. Une personne pourrait être le gestionnaire de contenu technique du livre A, le gestionnaire administratif du livre B et un lecteur de 50 autres livres. Nous ne pouvions donc pas vraiment dire qu'un utilisateur avait "un rôle". Chaque utilisateur avait des rôles différents pour chaque livre.

En plus de cela, il privilèges au niveau du système de routine étaient plus: Nous avons eu quelques administrateurs système autorisé à mettre à jour quoi que ce soit dans le systeem, les gens du centre d'assistance qui pourrait voir presque toutes les données, mais pas mise à jour, etc.

J'ai fini par créer une base de données comme celle-ci. (Pour éviter d'entrer dans une partie de notre terminologie étrange que je vais changer quelques noms de champs et de tables ici, l'idée est la même.)

Personne (person_id, nom, etc.)

Technical_Manual (manual_id, titre, admin_manager_person_id, stock_manager_person_id, content_manager_person_id, etc.)

Authorized_Reader (manual_id, person_id, etc.)

utilisateur (user_id, admin_role, etc.)

je n'étais pas vraiment satisfait de ce régime, car cela signifiait que la sécurité était répartie sur trois tables: la table technical_manual, la table authorized_reader et la table user. Mais ... y avait-il une façon plus propre de le faire? De meilleures idées?

Answer 1

La façon dont je l'ai récemment fait quelque chose de vaguement semblable à celui des vents allant jusqu'à ressembler à:

Person (person_id, name, etc) 

Role (role_id, name [admin manager, stock manager, content manager, authorized reader, etc]) 

Technical_Manual (manual_id, title, etc) 

Technical_Manual_Role (manual_id, person_id, role_id) 

De plus, dans mon système, les rôles sont pour la plupart juste des paquets d'autorisation par défaut, et les autorisations utilisateur pour des actions spécifiques (Lire , Modifier, Déplacer, Supprimer, etc.) peuvent être faites pour varier vers le haut ou vers le bas de la ligne de base pour leur rôle.

Answer 2

Je sais que cela peut sembler un peu kludgy, mais vous pouvez faire quelque chose comme ceci:

Roles(role_id, etc)

Technical_Manual(manual_id, acceptable_roles, etc) où acceptable_roles est une liste

délimité ensuite dans votre programme, diviser la liste délimitée . Je ne dis pas que c'est la meilleure façon, mais ça marcherait. Bien que, je ne sais pas si ce serait le meilleur pour une application militaire :)

Answer 3

Le problème avec l'ajustement de force tout dans le modèle de «rôles» sont la logistique/volumes/charge de travail pour maintenir l'ensemble complet des règles de sécurité dans le cas où ces règles sont très "fines". Par grain fin, je veux dire le cas où il y a beaucoup de facteurs de discrimination potentiels dans toute décision d'autorisation, et pour chaque facteur discriminant (disons, «montant du crédit demandé par le client»), il y a un une gamme potentiellement importante de «valeurs» (disons, il y a 25 plages distinctes de crédit-montant-appliqué-pour). Supposons qu'il existe trois facteurs de discrimination de ce type, chacun avec une plage de sept valeurs possibles (7 plages de crédit distinctes). Ensuite, vous devrez définir 7 * 7 * 7 = 343 rôles. Ensuite, pour chaque utilisateur de votre système, vous devez affecter le sous-ensemble complet de tous les rôles que cet utilisateur peut effectuer. Si un utilisateur est autorisé à se prononcer sur une demande de crédit de 50.000.000, alors il est tout à fait probable (mais encore une fois, pas absolument certain!) Qu'il est également autorisé à se prononcer sur une demande de crédit de 5.000.000. C'est pourquoi dans mon projet, les facilités liées à la sécurité se limitent à l'identification (userid) et à l'authentification (usercertificate). Il n'y a aucune disposition d'autorisation. Ceux-ci doivent être traités par des contraintes définies par l'utilisateur.

Answer 4

Vous pouvez adopter une approche plus basée sur les revendications pour l'autorisation.

Il peut exister des autorisations générales que chaque utilisateur peut avoir ou non (c'est-à-dire admin) qui pourraient être directement attachées à un rôle. et nous utiliserions votre table pour faire correspondre à un utilisateur particulier les publications pour lesquelles ils ont avancé des droits, et créer des revendications pour ces entrées.

Ainsi, lorsque l'autorisation d'un utilisateur est demandée, vous obtenez une collection de revendications, certaines de haut niveau dérivées de rôles, et d'autres spécifiques à la publication, dérivées de vos tables.

Answer 5

Commentaire sur la réponse du Chaos:

Il me semble que les rôles « au niveau du système » pourrait adapter le même schéma si manual_id pour de telles choses pourraient être réglées à null ou une valeur magique. Oui, je sais, certaines personnes ont une forte aversion pour les nulls, mais ça marche ici. Ensuite, il y aurait une seule table de sécurité, et tout est propre.

J'ai rencontré beaucoup de problèmes avec les trois domaines de gestion. Nous avons eu un certain nombre de questions comme «De quels livres Bob est-il responsable?», Ce qui nécessitait une requête avec un grand OR pour aller contre les trois champs. Ce qui signifiait que nous avions besoin de trois index. Je me suis rendu compte plus tard que nous aurions mieux fait de séparer cela en une table distincte. Mais jeter les lecteurs autorisés dans la même table ... beaucoup de choses à nettoyer. Jetez des trucs au niveau du système aussi et ... J'aime ça. Il devient facile de demander "Quels sont les droits de Mary Jones?" ainsi que «Qui a droit au manuel de l'avionique F-15?», «Qui sont tous nos gestionnaires de contenu techniques? etc.

Answer 6

Je voulais juste ajouter plus de concept. Même si le RBAC (contrôle d'accès basé sur les rôles) semble être en vogue, il existe de nombreux modèles comme DAC et MAC qui permettent de résoudre le problème de contrôle d'accès plus longtemps (le RBAC a été formalisé vers 1995 alors que d'autres le modèle existe depuis plus longtemps et est utilisé par les militaires). La façon dont vous avez expliqué les exigences que je vois utiliser plusieurs modèles

1. RBAC - utilisé dans le cas de «rôles système» dont vous avez parlé.
2. Contrôle d'accès basé sur l'attribut/politique - utilisé pour toutes les pièces liées manuellement. MAC - utilisé pour contrôler l'accès aux manuels à la base, c'est-à-dire que chaque manuel et utilisateur a un niveau de sensibilité associé et qu'ils doivent correspondre en fonction de critères spécifiques pour pouvoir y accéder.

Ces modèles peuvent être exprimés à l'aide de normes telles que XACML (et évaluées lors de l'exécution à l'aide d'implémentations de moteur de règles) qui peuvent décrire une stratégie. Par exemple, dans votre cas, la politique ressemblerait à quelque chose le long de la ligne de

(attribut basé)

Autoriser « tout le monde » à « modifier » « manuel » si userId = manual.technical_content_manager

Autoriser " tout le monde » à "si le navire" "manuel" userId = manual.stock_manager

(RBAC)

Autoriser "HelpDesk" à "vue" "info manuel", "manuel"

Allow "Administrateur" à "vue", "modifier", "bateau" "manuel"

(MAC)

Autoriser « tout le monde » à « vue » « manuel » si userId.level> = manual.level

Basé sur le modèle de politique ci-dessus, il est clair que vous devez suivre-rôle utilisateur la cartographie qui peut être fait en utilisant la table et récupéré au moment de l'exécution pour alimenter le moteur de règles au moment de l'exécution.