Est-ce une bonne stratégie pour implémenter le contrôle d'accès?

Question

J'aimerais mettre en place un système de contrôle d'accès piloté par base de données. J'ai lu sur ACL, les rôles, RBAC, etc., mais il semble que les régimes les plus courants ont des inconvénients majeurs. RBAC, par exemple, semble être maladroit lorsqu'il s'agit de mettre en œuvre un contrôle d'accès précis (par exemple, permettre à un certain rôle de mettre à jour uniquement des colonnes particulières d'un enregistrement particulier).

si je structuré ma liste de contrôle d'accès comme celui-ci:

| role | table | action | columns | conditions  | 
| ----- | ----- | ------ | -------- | ----------------- | 
| user | user | view | name, id | self.id = user.id | 
| user | user | update | password | self.id = user.id | 
| admin | user | update | *  |     | 
| admin | user | create | *  |     | 
| admin | user | delete | *  |     | 

L'idée est que le rôle (s) d'un utilisateur sera vérifié par rapport à cette table lorsqu'ils tentent d'accéder à la base de données (donc, mis en œuvre à le niveau du modèle). action peut être l'un des {create, view, update, delete, list}. L'étendue self serait un mot clé réservé faisant référence aux propriétés de l'utilisateur actuel. Cela nous permettrait par exemple de permettre uniquement aux utilisateurs de mettre à jour leurs propres mots de passe (et pas ceux de quelqu'un d'autre).

Est-ce robuste? Évidemment, j'aurais toujours besoin d'une liste séparée pour contrôler l'accès à d'autres types de ressources comme les URI, etc.

Answer 1

Bonne question. Vous rencontrez les limites des ACL et RBAC. Il existe une autre méthode plus flexible appelée contrôle d'accès basé sur des attributs (ABAC). Le diagramme suivant montre comment le contrôle d'accès a évolué au fil du temps pour répondre à des scénarios plus complexes (plus d'utilisateurs, plus de données, plus de périphériques, plus de contexte).

Plus spécifiquement, vous éprouvez des difficultés avec le fait que RBAC ne prend pas en charge les relations. ABAC fait cependant. ABAC est basé sur des attributs. Un attribut est juste une paire clé-valeur, par ex. rôle == gestionnaire ou emplacement == Arizona.

ABAC utilise des stratégies avec des attributs pour exprimer des scénarios d'autorisation. Par exemple, dans ABAC vous pouvez exprimer des scénarios tels que:

• Un utilisateur avec le rôle == médecin peut faire l'action == vue sur une ressource de type == dossier médical si le médecin emplacement == l'emplacement du patient.

Il existe une norme appelée XACML (eXtensible Access Control Markup Language) que vous pouvez utiliser pour implémenter ABAC. Il existe même des produits qui offrent XACML spécifiquement pour les bases de données et le contrôle d'accès aux données tels que le Axiomatics Data Access Filter.

Si vous voulez en savoir plus sur ABAC je vous recommande tourner à 2 grandes ressources:

1. NIST: Guide d'attributs en fonction de contrôle d'accès (ABAC) Définition et considérations (pdf)
2. Webinar sur la Document NIST.