Início / dba / Perguntas / 1732
Accepted
taudorf
Asked: 2011-03-15 03:48:56 +0800 CST

Modelo de banco de dados com usuários, funções e direitos

  • 772

Eu tenho um modelo de banco de dados com uma tabela de usuários e uma tabela de funções. Quero controlar o acesso (direitos) a até 10 elementos diferentes. O acesso pode ser concedido a uma função ou a um único usuário. Abaixo está a definição da tabela de usuários, funções e itens:

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

...

Agora eu tenho duas maneiras diferentes de projetar os direitos. Uma tabela com uma coluna de tipo de direitos ou 10 tabelas de direitos - uma para cada elemento ao qual desejo controlar o acesso.

Quais são os prós e contras de uma tabela de direitos versus uma tabela de direitos por elemento? - ou é a maneira mais adequada de fazer isso?

database-design best-practices

2 respostas

  1. Best Answer

    Em primeiro lugar, que tipo de modelo de segurança você planeja implementar? Controle de acesso baseado em função (RBAC) ou controle de acesso discricionário (DAC)?

    RBAC no modelo de controle de acesso baseado em função (RBAC), o acesso aos recursos é baseado na função atribuída a um usuário. Nesse modelo, um administrador atribui a um usuário uma função que possui certos direitos e privilégios predeterminados. Devido à associação do usuário com a função, o usuário pode acessar determinados recursos e executar tarefas específicas. O RBAC também é conhecido como Controle de Acesso Não Discricionário. As funções atribuídas aos usuários são administradas centralmente.

    DAC No modelo de controle de acesso discricionário (DAC), o acesso aos recursos é baseado na identidade do usuário. Um usuário recebe permissões para um recurso ao ser colocado em uma lista de controle de acesso (ACL) associada ao recurso. Uma entrada na ACL de um recurso é conhecida como uma entrada de controle de acesso (ACE). Quando um usuário (ou grupo) é o proprietário de um objeto no modelo DAC, o usuário pode conceder permissão a outros usuários e grupos. O modelo DAC é baseado na propriedade do recurso.

    ver fonte

    1) No RBAC: você precisa da tabela ElementType para atribuir direitos à função (os usuários são atribuídos à(s) função(ões)). O RBAC define: "O que essa função/usuário pode fazer". O administrador atribui direitos a funções e permissões a funções, atribui usuários a funções para acessar recursos. 2) No DAC: usuários e funções têm direitos aos elementos via lista de controle de acesso (propriedade). DAC define: "quem tem acesso aos meus dados". O usuário (proprietário) concede permissões ao recurso de propriedade.

    De qualquer forma, sugiro este modelo de dados:

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

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

    (relação de um para um)

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

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

    1) RBAC (relação muitos para muitos)

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

    2) DAC (relação muitos para muitos)

    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)
    ...
)
    • 36

  2. Com uma tabela de direitos para cada elemento, assim que você adicionar um elemento, precisará adicionar uma tabela. Isso aumentaria a manutenção do aplicativo.

    A desvantagem de colocar tudo em uma tabela é que você pode ter problemas de dimensionamento, mas eles podem ser mitigados usando particionamento, visualizações materializadas e/ou colunas virtuais. Provavelmente tais medidas não seriam necessárias.

    Quanto ao design da tabela, se isso estivesse no Oracle, eu poderia sugerir algo assim:

    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;

    O código do pacote pode usar a sequência UserRoleID para preencher o Id na tabela Users e o Id na tabela Roles conforme necessário. A tabela Permissões poderia então ter elementos atribuídos a funções que, por sua vez, são atribuídas a usuários e/ou ter elementos atribuídos diretamente a usuários.

    • 5

relate perguntas