En lisant sur ACL et RBAC, il me semble que je le comprends facilement - il y a des noms d'utilisateur ou des rôles qui ont accès à un actif. Je peux également voir comment je pourrais les mettre en œuvre.

c'est-à-dire que cette image donne une vue claire d'ACL et RBAC pour moi (comme dans je peux continuer et concevoir des tables de base de données basées sur ci-dessus): (Image courtoisie de pressbooks )

Ce avec quoi je me bats, c'est ABAC. Diverses images que j'ai trouvées jusqu'à présent sont ondulées à la main ou trop compliquées, ou suggèrent d'utiliser une entité externe tierce pour l'autorisation. Ou donnez des exemples d'attributs étranges que je ne suis pas tout à fait certain de savoir comment utiliser.

Exemple de départ

Alors permettez-moi de commencer par quelque chose dans la vraie vie. Disons que j'ai une entreprise de 70 à 200 personnes. Et mon atout à protéger est un site Web avec de nombreuses pages différentes. Je souhaite permettre à certaines personnes d'accéder à certains actifs.

Par exemple, je veux qu'une personne Leslieait accès à une page Web appelée Price Manageret lui permette de gérer uniquement les Travelprix du groupe de prix sur cette page, mais ne puisse pas gérer les prix du Productgroupe sur la même page. Comment pourrais-je implémenter cela en utilisant ABAC?

En fouillant jusqu'à présent, je suppose que je pourrais attribuer Lesliecertains attributs (mais lesquels et quels sont ces attributs?), Puis avoir une table de base de données les stockant. Je peux ensuite concevoir un moteur qui examine ces attributs (mais ne considère pas Lesliecomme un "rôle" comme cela se fait dans RBAC), et décide à partir de là s'il faut accorder ou non l'accès à la page. À quoi ressemblerait ce moteur? Est-ce un simple bloc if / else? Autre chose?

Que se passe-t-il si Leslie change plus tard de poste et que quelqu'un doit changer son accès? À quoi cela ressemblera-t-il si elle a besoin que son accès soit Productretiré et révoqué Travel? Comment sera -t- elle être codé si besoin d'avoir accès à la révocation la Price Managerpage tout à fait et , par conséquent pas avoir accès à ni plus Travel, ou Product?

L'atout dans mon cas, juste pour le reformuler, est Price Manager, et un utilisateur peut accéder à différents groupes de prix sur cette page, tels que la Traveltarification, la Producttarification, etc.

Ce que je recherche, c'est une feuille de route raisonnablement complète vers la clarification des détails et vers la mise en œuvre où je pourrais aller et la mettre en œuvre sans deviner. c'est-à-dire qu'il pourrait être complété conceptuellement et / ou avoir un exemple spécifique où je peux visualiser une structure de base de données, etc.

Bonus: ABAC est-il un moyen approprié pour un besoin d'autorisation relativement petit, c'est-à-dire gérer 70 à 200 personnes et accéder à quelque 150 à 450 actifs? Serait-il préférable de s'en tenir à ACL / RBAC à la place?

Une implémentation ABAC est plus complexe que ACL / RBAC. Certains frameworks vous offrent même des éléments d'infrastructure pour gérer ces derniers. Si les personnes et les actifs peuvent être regroupés sous un nombre relativement petit et fixe de rôles / catégories, il est probablement préférable de s'en tenir à ACL / RBAC. Si les autorisations diffèrent considérablement d'une personne à l'autre, alors ABAC pourrait fournir une solution meilleure et plus flexible.

Si vous choisissez de suivre le chemin ABAC, la première chose que vous devez faire est de passer du temps à lire et à comprendre la norme XACML . Les exemples fournis dans le document utilisent une syntaxe compatible XACML et sont un peu difficiles à mâcher au début. Je suppose que vous ne voulez pas implémenter une solution compatible standard, vous n'avez donc besoin que des idées générales.

Concepts

XACML s'articule autour de 4 concepts et de leurs attributs: sujets , actions , ressources et environnement . Il y en a quelques autres, mais ce sont les plus importants. Tout le reste est construit au-dessus d'eux. Si je devais faire une phrase avec ces concepts, cela pourrait être quelque chose comme: les sujets effectuent des actions sur les ressources dans un certain environnement . Appliquer cela à votre scénario se traduirait par quelque chose comme:

• Leslie ouvre la page Web du gestionnaire de prix.
• Leslie crée un prix de voyage en utilisant la page Web du gestionnaire de prix.

Collection d'attributs

La première chose que nous devons faire est de rassembler les attributs pertinents des concepts énoncés ci-dessus. Idéalement, vous ne devriez pas attribuer d'attributs spécifiques car XACML essaie d'être discret et de se fier uniquement à ce que le système fournit naturellement. Et nous avons donc:

Matière

Tout acteur, que ce soit une personne ou un service, dans votre système. Notre sujet est Leslie. Quels attributs sont requis pour identifier Leslie de manière unique? Probablement certains des éléments suivants: first name, last name, e-mail, ssn, company id, position(s).

action

Toute action effectuée par les sujets. Peut être les opérations CRUD standard ou quelque chose de plus complexe. Nos actions sont open/viewet create. Les attributs de ces actions peuvent être différents en fonction du cadre d'application Web que vous utilisez. Nous en parlerons davantage lorsque nous arriverons à la ressource.

Ressource

Assez explicite. Nos ressources sont les price manager page, travel priceset the newly created price. Il pourrait y en avoir plus, si vous le voulez vraiment. Vous souhaiterez peut-être masquer les actions que les utilisateurs ne peuvent pas effectuer. Par exemple. le create price buttonpeut être une ressource qui peut être affichée / masquée selon que l'utilisateur a des autorisations pour créer des prix. Étant donné que la seule façon pour un utilisateur de voir une liste de prix pourrait être par le biais de cette page, ce serait probablement une bonne idée d'appliquer une autorisation à ce niveau plutôt que de descendre dans la pile.

L'accès aux ressources est le plus compliqué à mettre en œuvre, notamment sur celles qui proviennent d'une base de données. L'option plus fine est la sécurité au niveau des lignes. Certaines bases de données ont un certain degré de prise en charge. Certains implémenteurs XACML sont allés jusqu'à créer un sur-ensemble SQL. Cela dépend vraiment de vos besoins d'autorisation, mais la seule chose que vous ne voulez pas faire est de tout extraire d'une table, puis de décider quoi afficher. Vous pouvez regrouper des ressources par ensembles d'autorisations, les résumer derrière une API et appliquer une autorisation aux points de terminaison de l'API.

Environnement

Je ne peux pas le définir correctement (XACML n'a pas non plus de définition appropriée) mais disons que c'est la "bulle" dans laquelle tout cela se produit. Cela comprend: web application, web server, operating system, browser, office. Vous pouvez extraire des attributs tels que : ip address, time of day, user locale, user agent, operating system version. Vous pouvez les utiliser pour bloquer l'accès des utilisateurs à des environnements qui ne sont pas pris en charge par votre application (par exemple, anciens navigateurs, anciens systèmes d'exploitation, ordinateurs en dehors de votre réseau, accès en dehors des heures d'ouverture).

Demande d'autorisation

Une fois que nous avons rassemblé tous les attributs nécessaires, nous les regroupons dans une demande d'autorisation et les transmettons à une entité qui peut prendre des décisions d'autorisation en fonction des valeurs de ces attributs. Dans XACML lingua, l'endroit où vous collectez ces attributs et appliquez les décisions prises est alors appelé un point d'application de la politique (PEP) et le point qui prend des décisions est appelé un point de décision de la politique (PDP). Les emplacements à partir desquels les valeurs d'attribut sont obtenues sont appelés points d'information de politique s (PIP). Les PEP, PDP et PIP peuvent faire partie de votre application car ils peuvent être des systèmes externes. Vous pouvez trouver un diagramme de la façon dont ils communiquent entre eux dans la norme XACML.

Processus décisionnel

Le processus décisionnel est basé sur des règles . Les règles peuvent être regroupées en stratégies qui peuvent être regroupées en ensembles de stratégies . Chacun d'eux a un objectif . La cible est utilisée pour décider si l'une des règles s'applique à la demande d'autorisation. Considérez-le comme un filtre. La cible contient des conditions créées à l'aide de noms et de valeurs d'attribut. Par exemple, les règles de votre application peuvent être regroupées en quelque chose comme:

Application Web (ensemble de règles)
| - cible: nom-application == "Application Web"
`- Version 1.0 (ensemble de règles)
    | - cible: application-version == "1.0"
    `- Voir le gestionnaire de prix (politique)
        | - target: web-page-name == "price manager" && action-name == "view"
        `- Leslie peut voir le gestionnaire de prix (règle)
            | - cible: nom-sujet == "Leslie"
            `- permission: autoriser

Le PDP fera correspondre tout ce qui se trouve dans l'ensemble ci-dessus avec les valeurs d'attribut dans la demande d'autorisation. Ce qui se passe s'il n'y a pas de règles qui correspondent, cela dépend de la mise en œuvre de votre PDP. Une fois que le PDP a pris une décision ( allow, denyou not-applicable), il le renvoie au PEP qui agit sur lui en accordant ou en refusant l'accès à la ressource. Avec la réponse du PDP peut envoyer une liste obligationset advicesque le moût PEP ou doit remplir dans le processus d'application. Selon la façon dont les règles sont stockées (fichiers texte ou base de données), un administrateur peut utiliser un éditeur de texte standard ou une application d'édition personnalisée pour les modifier à sa guise. La révocation de l'accès de Leslie au gestionnaire de prix revient à changer simplement l'autorisation de allowàdeny, le PEP fait son travail.

Mise en vigueur

Cela dépend fortement de votre pile technologique. Certains frameworks Web ont des points d'application naturels (par exemple, ASP.NET MVC a des filtres d'attribut). Vos couches métier peuvent avoir à définir de tels points d'application. J'ai trouvé plus facile d'appliquer l'application aux points de terminaison de service (pensez aux microservices) ou au niveau de l'interface utilisateur.

Autres bénéfices

Un bon effet secondaire de l'implémentation est que vous vous retrouvez avec une piste d'audit assez riche qui peut être utilisée à d'autres fins.