web-dev-qa-db-fra.com

Modèle de base de données avec utilisateurs, rôles et droits

J'ai un modèle de base de données avec une table utilisateur et une table de rôle. Je souhaite contrôler l'accès (droits) jusqu'à 10 éléments différents. L'accès peut être accordé à un rôle ou à un seul utilisateur. Voici la définition du tableau des utilisateurs, des rôles et des éléments:

CREATE TABLE users
(
  id serial NOT NULL PRIMARY KEY,
  username character varying UNIQUE,
  password character varying,
  first_name character varying,
  last_name character varying,
  ...
);

CREATE TABLE roles
(
  id serial NOT NULL PRIMARY KEY,
  name character varying NOT NULL,
  description character varying,
  ...
);

CREATE TABLE element_1
(
  id serial NOT NULL PRIMARY KEY,
  name character varying NOT NULL,
  description character varying,
  ...
);

...

Maintenant, j'ai deux façons différentes de concevoir les droits. Une table avec une colonne de type de droits ou 10 tables de droits - une pour chaque élément auquel je veux contrôler l'accès.

Quels sont les avantages et les inconvénients d'une table de droits par rapport à une table de droits par élément? - ou est-ce une façon plus appropriée de le faire?

database-designbest-practices
40
taudorf

Tout d'abord, quel type de modèle de sécurité prévoyez-vous de mettre en œuvre? Contrôle d'accès basé sur les rôles (RBAC) ou contrôle d'accès discrétionnaire (DAC)?

RBAC dans le modèle RBAC (Role-Based Access Control), l'accès aux ressources est basé sur le rôle attribué à un utilisateur. Dans ce modèle, un administrateur attribue un utilisateur à un rôle doté de certains droits et privilèges prédéterminés. En raison de l'association de l'utilisateur avec le rôle, l'utilisateur peut accéder à certaines ressources et effectuer des tâches spécifiques. RBAC est également connu sous le nom de contrôle d'accès non discrétionnaire. Les rôles attribués aux utilisateurs sont administrés de manière centralisée.

DAC Dans le modèle DAC (Discretionary Access Control), l'accès aux ressources est basé sur l'identité de l'utilisateur. Un utilisateur se voit accorder des autorisations sur une ressource en étant placé sur une liste de contrôle d'accès (ACL) associée à la ressource. Une entrée sur l'ACL d'une ressource est connue comme une entrée de contrôle d'accès (ACE). Lorsqu'un utilisateur (ou groupe) est propriétaire d'un objet dans le modèle DAC, l'utilisateur peut accorder une autorisation à d'autres utilisateurs et groupes. Le modèle DAC est basé sur la propriété des ressources.

voir source

1) Dans RBAC: vous avez besoin d'une table ElementType pour attribuer des droits au rôle (les utilisateurs sont affectés aux rôles). RBAC définit: "Que peut faire ce rôle/cet utilisateur". L'administrateur attribue des droits pour les rôles et des autorisations aux rôles, attribue des utilisateurs aux rôles pour accéder aux ressources. 2) Dans DAC: les utilisateurs et les rôles ont des droits sur les éléments via la liste de contrôle d'accès (propriété). Le CAD définit: "qui a accès à mes données". L'utilisateur (propriétaire) accorde des autorisations à la ressource possédée.

Quoi qu'il en soit, je suggère ce modèle de données:

CREATE TABLE ElementType
(
    Id (PK)
    Name
    ...
)

CREATE TABLE ElementBase
(
    Id (PK)
    Type (FK to ElementType)
    ...
)

(relation individuelle)

CREATE TABLE Element_A
(
    Id (PK, FK to ElementBase)
    ...
)

CREATE TABLE Element_B
(
    Id (PK, FK to ElementBase)
    ...
)

1) RBAC (relation plusieurs à plusieurs)

CREATE TABLE ElementType_To_Role_Rights
(
    RightId (PK)
    RoleId  (FK to Role)
    ElementTypeId (FK to ElementType)
    ...
)

2) CAD (relation plusieurs à plusieurs)

CREATE TABLE ElementBase_To_Actor_Rights
(
    RightId (PK)
    ElementBaseId (FK to ElementBase)
    ActorId (FK to Actor)
    ...
)

CREATE TABLE Actor
(
    Id (PK)
    Name
)

CREATE TABLE User
(
    Id (PK, FK to Actor)
    Password
    ...
)

CREATE TABLE Role
(
    Id (PK, FK to Actor)
    ...
)
35
garik

Avec une table de droits pour chaque élément, dès que vous ajoutez un élément, vous devrez ajouter une table. Cela ajouterait à la maintenance de l'application.

L'inconvénient de tout mettre dans une table est que vous pouvez rencontrer des problèmes de mise à l'échelle, mais ceux-ci peuvent être atténués à l'aide du partitionnement, des vues matérialisées et/ou des colonnes virtuelles. De telles mesures ne seraient probablement pas nécessaires.

En ce qui concerne la conception de la table, si c'était sur Oracle, je pourrais suggérer quelque chose comme ceci:

CREATE SEQUENCE UserRoleID;

CREATE TABLE USERROLE 
(
  USERID NUMBER(7) NOT NULL 
, ROLEID NUMBER(7) NOT NULL 
, CONSTRAINT USERROLE_PK PRIMARY KEY 
  (
    USERID 
  , ROLEID 
  )
  ENABLE 
) 
ORGANIZATION INDEX;

CREATE TABLE PERMISSIONS 
(
  ID NUMBER(7) NOT NULL 
, ELEMENTID NUMBER(7) NOT NULL 
, CONSTRAINT USERROLE_PK PRIMARY KEY 
  (
    ID 
  , ELEMENTID 
  )
  ENABLE 
) 
ORGANIZATION INDEX;

Le code de package peut utiliser la séquence UserRoleID pour remplir l'ID dans la table Users et l'ID dans la table Roles si nécessaire. La table des autorisations pourrait alors avoir des éléments affectés à des rôles qui sont à leur tour attribués aux utilisateurs et/ou des éléments attribués directement aux utilisateurs.

5
Leigh Riffel