Przewodnik po projektowaniu bazy danych dla RBAC w MySQL

Ten samouczek zawiera kompletne kroki projektowania schematu bazy danych systemu kontroli dostępu opartej na rolach (RBAC) w celu zarządzania użytkownikami, rolami i uprawnieniami. Może być dalej używany do decydowania o dostępie do określonych zasobów na podstawie określonych uprawnień. Korzystanie z systemu RBAC należy traktować jako integralną część każdej aplikacji udostępniającej zasoby wielu użytkownikom. Np. pracownicy organizacji mogą uzyskiwać dostęp do produktów lub zarządzać nimi na podstawie przypisanych im uprawnień. Najlepiej byłoby, gdyby uprawnienia można było przypisać za pomocą ról.

Diagram relacji encji lub wizualny projekt bazy danych pokazano poniżej.

Rys. 1

Notatki :Tabele ról i uprawnień omówione w tym samouczku można dodać do baz danych aplikacji omówionych w samouczkach Blog oraz Ankieta i ankieta. Ten samouczek zakłada, że ​​uprawnienia są zakodowane na stałe na poziomie kodu, aby sprawdzić dostęp.

Możesz także odwiedzić popularne samouczki, w tym Jak zainstalować MySQL 8 w Ubuntu, Jak zainstalować MySQL 8 w Windows, Blog Database w MySql, Baza danych ankiet i ankiet w MySql oraz Nauka podstawowych zapytań SQL w MySQL.

Baza danych RBAC

Pierwszym krokiem jest utworzenie bazy danych RBAC. Można go utworzyć za pomocą zapytania, jak pokazano poniżej.

CREATE SCHEMA `rbac` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Użyłem zestawu znaków utf8mb4 do obsługi szerokiej gamy znaków.

Tabela użytkowników

W tej sekcji zaprojektujemy Tabelę użytkowników do przechowywania informacji o użytkowniku. Poniżej znajduje się opis wszystkich kolumn tabeli użytkowników.

Tabela użytkownika z odpowiednimi ograniczeniami jest pokazana poniżej.

CREATE TABLE `rbac`.`user` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `firstName` VARCHAR(50) NULL DEFAULT NULL,
  `middleName` VARCHAR(50) NULL DEFAULT NULL,
  `lastName` VARCHAR(50) NULL DEFAULT NULL,
  `mobile` VARCHAR(15) NULL,
  `email` VARCHAR(50) NULL,
  `passwordHash` VARCHAR(32) NOT NULL,
  `registeredAt` DATETIME NOT NULL,
  `lastLogin` DATETIME NULL DEFAULT NULL,
  `intro` TINYTEXT NULL DEFAULT NULL,
  `profile` TEXT NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE INDEX `uq_mobile` (`mobile` ASC),
  UNIQUE INDEX `uq_email` (`email` ASC) );

Tabela ról

W tej sekcji zaprojektujemy Tabelę ról do przechowywania ról systemowych. Poniżej znajduje się opis wszystkich kolumn tabeli ról.

Tabela ról z odpowiednimi ograniczeniami jest pokazana poniżej.

CREATE TABLE `rbac`.`role` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `title` VARCHAR(75) NOT NULL,
  `slug` VARCHAR(100) NOT NULL,
  `description` TINYTEXT NULL,
  `active` TINYINT(1) NOT NULL DEFAULT 0,
  `createdAt` DATETIME NOT NULL,
  `updatedAt` DATETIME NULL DEFAULT NULL,
  `content` TEXT NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE INDEX `uq_slug` (`slug` ASC) );

Tabela uprawnień

W tej sekcji zaprojektujemy Tabelę uprawnień do przechowywania uprawnień systemowych. Poniżej znajduje się opis wszystkich kolumn tabeli uprawnień.

Tabela uprawnień z odpowiednimi ograniczeniami jest pokazana poniżej.

CREATE TABLE `rbac`.`permission` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `title` VARCHAR(75) NOT NULL,
  `slug` VARCHAR(100) NOT NULL,
  `description` TINYTEXT NULL,
  `active` TINYINT(1) NOT NULL DEFAULT 0,
  `createdAt` DATETIME NOT NULL,
  `updatedAt` DATETIME NULL DEFAULT NULL,
  `content` TEXT NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE INDEX `uq_slug` (`slug` ASC) );

Tabela uprawnień do ról

Tabela uprawnień do ról może służyć do przechowywania mapowań uprawnień do ról. Poniżej znajduje się opis wszystkich kolumn tabeli uprawnień do ról.

Tabela uprawnień do ról z odpowiednimi ograniczeniami jest pokazana poniżej.

CREATE TABLE `rbac`.`role_permission` (
  `roleId` BIGINT NOT NULL,
  `permissionId` BIGINT NOT NULL,
  `createdAt` DATETIME NOT NULL,
  `updatedAt` DATETIME NULL,
  PRIMARY KEY (`roleId`, `permissionId`),
  INDEX `idx_rp_role` (`roleId` ASC),
  INDEX `idx_rp_permission` (`permissionId` ASC),
  CONSTRAINT `fk_rp_role`
    FOREIGN KEY (`roleId`)
    REFERENCES `rbac`.`role` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_rp_permission`
    FOREIGN KEY (`permissionId`)
    REFERENCES `rbac`.`permission` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION);

Rola użytkownika

Możemy zachować prostotę systemu, przypisując użytkownikowi pojedynczą rolę. Przypisana rola może służyć do ściągania uprawnień przypisanych do roli. Dostęp do określonego zasobu lub uprawnienia można sprawdzić, porównując uprawnienia zapisane na stałe z listą uprawnień przypisanych do roli przypisanej użytkownikowi.

Można to zrobić za pomocą zapytania, jak pokazano poniżej.

ALTER TABLE `rbac`.`user` 
ADD COLUMN `roleId` BIGINT NOT NULL AFTER `id`,
ADD INDEX `idx_user_role` (`roleId` ASC);

ALTER TABLE `rbac`.`user` 
ADD CONSTRAINT `fk_user_role`
  FOREIGN KEY (`roleId`)
  REFERENCES `rbac`.`role` (`id`)
  ON DELETE NO ACTION
  ON UPDATE NO ACTION;

Opcje zaawansowane

Można pomyśleć o przypisaniu wielu ról użytkownikowi za pomocą tabeli ról użytkowników. Bardziej zaawansowane opcje obejmują system hierarchii do grupowania uprawnień lub ról. Opcje te dodatkowo komplikują zapytanie w celu pobrania listy uprawnień, dlatego wymagają optymalizacji poprzez posiadanie odpowiedniego mechanizmu pamięci podręcznej.

Podsumowanie

W tym samouczku omówiliśmy projekt bazy danych systemu RBAC w celu zabezpieczenia określonych żądań i zasobów poprzez zezwolenie na dostęp tylko wtedy, gdy użytkownik ma odpowiednie uprawnienia.

Możesz przesłać swoje uwagi, aby dołączyć do dyskusji. Możesz być również zainteresowany zaprojektowaniem bazy danych aplikacji Blog oraz Ankieta i ankieta.

Pełny schemat bazy danych jest również dostępny na GitHub.