it-swarm.com.de

Datenbankmodell mit Benutzern, Rollen und Rechten

Ich habe ein Datenbankmodell mit einer Benutzertabelle und einer Rollentabelle. Ich möchte den Zugriff (Rechte) auf bis zu 10 verschiedene Elemente steuern. Der Zugriff kann entweder einer Rolle oder einem einzelnen Benutzer gewährt werden. Unten finden Sie die Tabellendefinition von Benutzern, Rollen und Elementen:

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,
  ...
);

...

Jetzt habe ich zwei verschiedene Möglichkeiten, die Rechte zu gestalten. Eine Tabelle mit einer Rechte-Typ-Spalte oder 10 Rechte-Tabellen - eine für jedes Element, auf das ich den Zugriff steuern möchte.

Was sind die Vor- und Nachteile einer Rechtstabelle gegenüber einer Rechtstabelle pro Element? - oder ist dies besser geeignet?

40
taudorf

Welche Art von Sicherheitsmodell planen Sie zunächst zu implementieren? Rollenbasierte Zugriffskontrolle (RBAC) oder diskretionäre Zugriffskontrolle (DAC)?

RBAC Im RBAC-Modell (Role-Based Access Control) basiert der Zugriff auf Ressourcen auf der einem Benutzer zugewiesenen Rolle. In diesem Modell weist ein Administrator einen Benutzer einer Rolle zu, die über bestimmte vorgegebene Rechte und Berechtigungen verfügt. Aufgrund der Zuordnung des Benutzers zur Rolle kann der Benutzer auf bestimmte Ressourcen zugreifen und bestimmte Aufgaben ausführen. RBAC wird auch als nichtdiskretionäre Zugangskontrolle bezeichnet. Die den Benutzern zugewiesenen Rollen werden zentral verwaltet.

DAC Im DAC-Modell (Discretionary Access Control) basiert der Zugriff auf Ressourcen auf der Identität des Benutzers. Einem Benutzer werden Berechtigungen für eine Ressource erteilt, indem er in eine Zugriffssteuerungsliste (ACL) aufgenommen wird, die der Ressource zugeordnet ist. Ein Eintrag in der ACL einer Ressource wird als Access Control Entry (ACE) bezeichnet. Wenn ein Benutzer (oder eine Gruppe) Eigentümer eines Objekts im DAC-Modell ist, kann der Benutzer anderen Benutzern und Gruppen Berechtigungen erteilen. Das DAC-Modell basiert auf dem Besitz von Ressourcen.

siehe Quelle

1) In RBAC: Sie benötigen die ElementType-Tabelle, um der Rolle Rechte zuzuweisen (Benutzer werden der Rolle (n) zugewiesen). RBAC definiert: "Was kann diese Rolle/dieser Benutzer tun". Der Administrator weist Rollen Rollen und Berechtigungen zu, weist Benutzern Rollen zu, um auf Ressourcen zuzugreifen. 2) In DAC: Benutzer und Rollen haben Rechte an Elementen über die Zugriffssteuerungsliste (Besitz). DAC definiert: "Wer hat Zugriff auf meine Daten". Benutzer (Eigentümer) erteilt Berechtigungen für die eigene Ressource.

Wie auch immer, ich schlage dieses Datenmodell vor:

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

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

(eins zu eins Beziehung)

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

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

1) RBAC (Viele-zu-Viele-Beziehung)

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

2) DAC (Viele-zu-Viele-Beziehung)

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

Mit einer Rechtstabelle für jedes Element müssen Sie eine Tabelle hinzufügen, sobald Sie ein Element hinzufügen. Dies würde zur Anwendungswartung beitragen.

Der Nachteil, alles in eine Tabelle zu packen, besteht darin, dass möglicherweise Skalierungsprobleme auftreten, die jedoch durch Partitionierung, materialisierte Ansichten und/oder virtuelle Spalten verringert werden können. Wahrscheinlich wären solche Maßnahmen nicht notwendig.

In Bezug auf das Tabellendesign könnte ich, wenn dies auf Oracle wäre, Folgendes vorschlagen:

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;

Der Paketcode kann die UserRoleID-Sequenz verwenden, um die ID in der Users-Tabelle und die ID in der Roles-Tabelle nach Bedarf zu füllen. In der Berechtigungstabelle können dann Elemente Rollen zugewiesen werden, die wiederum Benutzern zugewiesen sind, und/oder Elemente können Benutzern direkt zugewiesen werden.

5
Leigh Riffel