powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Организация модели безопасности на уровне БД
25 сообщений из 26, страница 1 из 2
Организация модели безопасности на уровне БД
    #39176427
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Добрый день Уважаемые!

Подскажите мне пожалуйста есть ли очевидные плюсы и минусы в моей схеме.

Когда проектирую приложение, то сразу же закладываю какую-то модель безопасности для приложения. Сейчас она у меня такого вида:
В БД имеются сущности: Компания , Отдел , Проект , Сотрудник
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
Table Users (
    id     BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    info   CHAR(255) NOT NULL
)

Table Organization (
    id     BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    info   CHAR(255) NOT NULL
)

Table Otdel (
    id     BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    info   CHAR(255) NOT NULL
)

Table Project (
    id     BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    info   CHAR(255) NOT NULL
)


И у пользователя (Сотрудника) при его авторизации из БД получаются данные по его доступам:
"системного уровня" - типа можно в системе создавать объекты, заправвлять ими. Пользователей и т.п.
"уровня компании" - типа в компании можно рулить в которой пользователь имеет права.
"уровня отдела" ....
"уровня проекта" ....

И в БД этьо соответственно реализовано таким образом:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
//"системные права" 
Table sysRights (
    id        BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    rightName CHAR(32)
)

Table userSysRights (
    id      BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    userID  SERIAL,
    sysRightID SERIAL,
    UNIQUE KEY userRight(userID, sysRightID),
    FK(userID)  -> Users(id),
    FK(sysRightID) -> sysRights(id)
)
//"права на уровне компании"
Table orgRights (
    id        BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    rightName CHAR(32)
)
TABLE userOrgRights (
    id         BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    userID     SERIAL,
    orgID      SERIAL,
    orgRightID SERIAL,
    UNIQUE KEY userOrgRight (userID, orgID, orgRightID),
    FK(userID) -> Users(id),
    FK(orgID)  -> Organizations(id),
    FK(orgRightID) -> orgRights(id)
)
.... И т.д. для Otdel, Project 



При авторизации пользователя, соответственно загружаются все связанные с ним доступы всех уровней и помещаются соответственно в многомерный массив типа
Код: php
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Array(
  //Системные доступы
  [0] => Array(1, 3, ...),
  //Доступы уровня компании
  [1] => Array (
            //В компании 1
               [1] => Array(2,6....),
            //В компании 5   
               [5] => Array(4),
              ....
            ),
........ аналогично в [2] для Отделов, в [3] для Проектов
)


И в дальнейшем при работе приложения, при выполнении действий, при которых соответственно надо иметь то или иное право, делается проверка из этого массива прав.

Вопрос у меня соответственно, нет ли очевидных косяков в таком способе разграничении доступа в большом приложении?
Как вы в своих проектах это реализуете?
...
Рейтинг: 0 / 0
Организация модели безопасности на уровне БД
    #39176428
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Прочитал заголовок и понял, что он некорректный. Не организация безопасности на уровне БД, а организация системы доступа в БД.
...
Рейтинг: 0 / 0
Организация модели безопасности на уровне БД
    #39176433
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kormotКак вы в своих проектах это реализуете?
SQL access rights + RLS по необходимости.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Организация модели безопасности на уровне БД
    #39176436
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovkormotКак вы в своих проектах это реализуете?
SQL access rights + RLS по необходимости.

А можно попросить в двух словах что такое SQL Access rights? Из гугла понял что это специфично для MS SQL Server, это в смысле доступ к отдельным таблицам, строкам и колонкам на уровне БД? Или нет?
RLS совсем не нашёл.
...
Рейтинг: 0 / 0
Организация модели безопасности на уровне БД
    #39176439
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kormotА можно попросить в двух словах что такое SQL Access rights?
RTFM GRANT/REVOKE, Row-Level Security.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Организация модели безопасности на уровне БД
    #39176441
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Это получается что при организации доступа на уровне БД, все пользователи у которых есть разграничение к отдельным объектам в БД, должны быть заведены как пользователи БД?

Дмитрий, а при использовании БД MySQL какие способы организации доступа обычно используются?
...
Рейтинг: 0 / 0
Организация модели безопасности на уровне БД
    #39176443
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kormotЭто получается что при организации доступа на уровне БД, все пользователи у
которых есть разграничение к отдельным объектам в БД, должны быть заведены как
пользователи БД?
Вы не поверите, но таки да, пользователи должны быть заведены как пользователи БД для того
чтобы они могли использовать БД.

Поделки на MySQL обычно не заботятся о безопасности вообще.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Организация модели безопасности на уровне БД
    #39176457
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovПоделки на MySQL обычно не заботятся о безопасности вообще.

А те которые необычные поделки и заботятся о безопасности, то как это делают?
...
Рейтинг: 0 / 0
Организация модели безопасности на уровне БД
    #39176461
Злой Бобр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kormot... при использовании БД MySQL какие способы организации доступа обычно используются?
Аналогичные. Только в мускуле это все ужато. Т.е. только с доступами на уровне таблицы.
...
Рейтинг: 0 / 0
Организация модели безопасности на уровне БД
    #39176462
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kormotА те которые необычные поделки и заботятся о безопасности, то как это делают?

Используя Oracle.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Организация модели безопасности на уровне БД
    #39176465
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Злой БобрАналогичные. Только в мускуле это все ужато. Т.е. только с доступами на уровне таблицы.
Но ведь доступов уровня таблицы не хватит чтобы сделать разграничение прав разным объектам описанным в таблице.
В итоге всё равно приходится контроль прав организовывать на уровне приложения, а хранение этих прав организовывать в БД. Я и спрашиваю в основном про реализацию хранения прав доступа в таблице, когда эти права реализуются на уровне приложения а в БД лишь хранятся.
...
Рейтинг: 0 / 0
Организация модели безопасности на уровне БД
    #39176467
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kormotНо ведь доступов уровня таблицы не хватит чтобы сделать разграничение прав
разным объектам описанным в таблице.
Те, у кого СУБД не поддерживает RLS из коробки, решают эту проблему используя view,
triggers и stored procedures.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Организация модели безопасности на уровне БД
    #39176496
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovkormotНо ведь доступов уровня таблицы не хватит чтобы сделать разграничение прав
разным объектам описанным в таблице.
Те, у кого СУБД не поддерживает RLS из коробки, решают эту проблему используя view,
triggers и stored procedures.

О, вот это я возьму на вооружение, спасибо!

Это уже вопрос наверное отдельно топика, но раз уж тут view (они же курсоры вроде?) предложили, то я про них сразу и спрошу.
Я к своему стыду эту конструкцию никогда не использовал, хотя понимаю всю его пользу. Видимо сейчас их и использую в деле.

Скажите пожалуйста, а если у этих представлений плюсы в плане производительности. Т.е. если я создам представление, в котором данные к которым у меня часто идут обращения например в качестве вложенных SELECT'ов в запросах, то если я вместо этих вложеных SELECT'ов буду использовать представление, то будет ли какой-то выигрыш в производительности, или это конструкция для того чтобы удобней и проще было строить запросы?

Также есть ли негативные эффекты для производительности БД если создано много представлений? Допустим для каждого пользователя если активного делать представление с данными к которым он часто обращается, то при наличии например 1000 представлений, не ухудшить ли это работу БД?
...
Рейтинг: 0 / 0
Организация модели безопасности на уровне БД
    #39176500
Злой Бобр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kormotВ итоге всё равно приходится контроль прав организовывать на уровне приложения, а хранение этих прав организовывать в БД. Я и спрашиваю в основном про реализацию хранения прав доступа в таблице, когда эти права реализуются на уровне приложения а в БД лишь хранятся.
В большинстве коммерческого софта именно так и делается - правами рулит приложение. Т.е. в БД создается 2 служебных пользователя. Под первым смотрим таблицу с правами, под вторым приложение работает с БД. Может конечно немного сумбурно высказал, но если непонятно то догадывайтесь.
kormotСкажите пожалуйста, а если у этих представлений плюсы в плане производительности ...

Также есть ли негативные эффекты для производительности БД если создано много представлений? Допустим для каждого пользователя если активного делать представление с данными к которым он часто обращается, то при наличии например 1000 представлений, не ухудшить ли это работу БД?
Нету, это лишь визуальное отображение. Хотя для кого-то может показаться плюсом хренение селектов. Лично я не считаю это плюсом. Более того нет необходимости для каждого пользователя создавать свои вьюхи. Это путь в никуда.
Насчет проихводительности - вроде объективных причин нет. Но я с таким бардаком не работал, так что - ХЗ как оно себя поведет. Но думаю что для небольшой БД это вообще не критично при любом раскладе. В любом случае - откажитесь от этого пути, а то засунут (клиенты) ваши руки в двери и правильно сделают.
...
Рейтинг: 0 / 0
Организация модели безопасности на уровне БД
    #39176503
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Злой Бобр спасибо! Поэтично и понятно :)
...
Рейтинг: 0 / 0
Организация модели безопасности на уровне БД
    #39176506
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kormotСкажите пожалуйста, а если у этих представлений плюсы в плане производительности. Т.е. если я создам представление, в котором данные к которым у меня часто идут обращения например в качестве вложенных SELECT'ов в запросах, то если я вместо этих вложеных SELECT'ов буду использовать представление, то будет ли какой-то выигрыш в производительности, или это конструкция для того чтобы удобней и проще было строить запросы?

Также есть ли негативные эффекты для производительности БД если создано много представлений? Допустим для каждого пользователя если активного делать представление с данными к которым он часто обращается, то при наличии например 1000 представлений, не ухудшить ли это работу БД?

Обычные view не улучшают производительности - да, они для более компактного и понятного кода. Бывают индексированные/материализованные view - вот они улучшают производительность операций чтения, но ухудшают производительность модификации данных.
в принципе еще бывает что view (обычные) плохо обрабатываются оптимизатором, план запроса получается неоптимальным.
Негативные эффекты от множества обычных view - смотря какая погрешность их измерения :) разумеется, какие-то ресурсы на это тратятся. Чтобы оные негативные эффекты от 1000 view ухудшили бы общую производительность системы хотя бы на 1% (если не считать упомянутые выше возможные проблемы с оптимизацией, которые не зависят от количества view) - я сомневаюсь.

И да, view и курсоры - это совсем разные вещи.
...
Рейтинг: 0 / 0
Организация модели безопасности на уровне БД
    #39176566
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторразным объектам описанным в таблицеЧто-то я объектов и не вижу. Пользователей вижу, права вижу (похоже только ваше приложение умеет их использовать), а объектов не вижу. Или объекты это элементы интерфейса и приложение само решает как показывать пользователю. Тогда для другого приложения (например генератора отчетов) придется повторять эту логику.
Про RLS
https://rsdn.ru/article/db/RowLevelSecurity.xml
...
Рейтинг: 0 / 0
Организация модели безопасности на уровне БД
    #39177176
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Уважаемые подскажите ещё пожалуйста такой момент:
До этого всегда делал по схеме, что неавторизованный пользователь - значит с ним не связано никакой учётной записи в БД, и его userID=0
А тут подумал, что ведь для неавторизованных пользователей тоже может быть свой набор прав. Стоит ли заморачиваться с созданием анонимного пользователя в БД, с которым будет ассоциирован неавторизованный посетитель. И у этого анонимного пользователя допустим userID=1 т.е. при создании и первоначальном наполнении БД, там бы и прописывался пользователь и ему бы сразу давался набор прав.

А то получается в ситуации когда анонимного пользователя нет, то получается что у него просто нет никаких прав доступа. И их невозможно никак реализовать.

Опять же спрашиваю, как обычно в системах где нет возможности полноценно реализовать RLS на уровне БД (типа MySQL) это обычно делают?
...
Рейтинг: 0 / 0
Организация модели безопасности на уровне БД
    #39177197
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если доступом управляет приложение, тогда в БД вообще один служебный пользователь (пусть Злой Бобр пояснит зачем нужен второй) и базе вообще по барабану чему равен userID. Недостатки такого подхода проявятся, когда к базе будет подключатся другое приложение.
Теоретически СУБД может поддерживать неавторизированного пользователя guest
...
Рейтинг: 0 / 0
Организация модели безопасности на уровне БД
    #39177201
Злой Бобр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kormot... как обычно в системах где нет возможности полноценно реализовать RLS на уровне БД (типа MySQL) это обычно делают?
Ну так возьми любую cms типа джумлы и посмотри как там реализовано. Лучше один раз увидеть ...
...
Рейтинг: 0 / 0
Организация модели безопасности на уровне БД
    #39177212
kormot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SERG1257Если доступом управляет приложение, тогда в БД вообще один служебный пользователь (пусть Злой Бобр пояснит зачем нужен второй) и базе вообще по барабану чему равен userID. Недостатки такого подхода проявятся, когда к базе будет подключатся другое приложение.
Теоретически СУБД может поддерживать неавторизированного пользователя guest
Блин, вроде же из первых постов топика понятно, что речь идёт не о пользователях БД, а о пользователях приложения, которые хранятся просто как строки в одной из таблиц БД. Речь не о системных пользователях БД, а о пользователях приложения. Не знаю как ещё это описать. Короче опишу это так, что в это не те пользователи которыми подключаются к БД:
Код: php
1.
$conn = mysqli_connect($dbHost, $dbUser, $dbPass, $dbName);


а те которые авторизуются через веб форму и проверяется их авторизация так допустим:
Код: php
1.
2.
3.
4.
5.
6.
7.
8.
$loginHash = mysqli_real_escape_string($conn, $_GET['userLogin']);
$passHash = mysqli_real_escape_string($conn, $_GET['userPass']);
$salt = mysqli_real_escape_string($conn, $_SESSION['salt']);

$result= $conn->sql('SELECT aa.id 
                     FROM   Users AS aa 
                     WHERE  MD5(aa.userLogin)="'.$loginHash.'" 
                        AND MD5(CONCAT("'.$salt.'", aa.passHash))="'.$passHash.'"');



А по поводу отдельного пользователя для чтения таблицы с доступами, так это очень даже дельное замечание от Злого Бобра . Если все запросы работают от пользователя БД которому ни читать ни писать в таблицы с доступами, то при возникновении SQL-инъекций, злоумышленник себе не сможет допустим прописать права в приложении, также как прочитать таблицу с логинами/хэшами. Так что тут мне по крайней мере дополнительных объяснений от Злого Бобра не требуется.
Злой БобрНу так возьми любую cms типа джумлы и посмотри как там реализовано. Лучше один раз увидеть ...
лезть туда.... Я вот что-то никогда cms-ками не пользовался, хотя дебажить сторонние проги, дебажил и понемногу вникал в суть написаного, но ради этого вопроса погружаться в джумлу...
Может так у кого есть свои мысли на этот счёт со своими за и против?
...
Рейтинг: 0 / 0
Организация модели безопасности на уровне БД
    #39177218
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SERG1257Если доступом управляет приложение, тогда в БД вообще один служебный пользователь (пусть Злой Бобр пояснит зачем нужен второй) и базе вообще по барабану чему равен userID. Недостатки такого подхода проявятся, когда к базе будет подключатся другое приложение.
Теоретически СУБД может поддерживать неавторизированного пользователя guest
никаких недостатков нет - какие права админ даст другим пользователям, такие права у них и будут
userId для БД существенен, все ж лучше пусть юзер сам достучится до БД с минимальными правами, а потом уж получит делегированные права
...
Рейтинг: 0 / 0
Организация модели безопасности на уровне БД
    #39177255
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ViPRosSERG1257Если доступом управляет приложение, тогда в БД вообще один служебный пользователь (пусть Злой Бобр пояснит зачем нужен второй) и базе вообще по барабану чему равен userID. Недостатки такого подхода проявятся, когда к базе будет подключатся другое приложение.
Теоретически СУБД может поддерживать неавторизированного пользователя guest
никаких недостатков нет - какие права админ даст другим пользователям, такие права у них и будут

Ну то есть "админу" придется дублировать всю систему безопасности приложения еще и в БД.
...
Рейтинг: 0 / 0
Организация модели безопасности на уровне БД
    #39177279
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот Матроскин,

частично, хотя бы
...
Рейтинг: 0 / 0
Организация модели безопасности на уровне БД
    #39177291
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kormot а о пользователях приложения, которые хранятся просто как строки в одной из таблиц БД.То бишь у тебя должны быть таблицы
пользователи
Код: sql
1.
create table my_users (usr_id int primary key....)


объекты
Код: sql
1.
create table my_objects (obj_id int primary key....)


действия
Код: sql
1.
create table my_actions (act_id int primary key...)



и одна большая связывающая их
Код: sql
1.
2.
3.
4.
5.
create table my_permissions (perm_id int primary key,
usr_id int references my_users,
obj_id int references my_objects,
act_id int references my_actions
)



Для удобства управления пользователи и объекты (особые извращенцы могут сгруппировать и действия) могут объединятся в группы
Код: sql
1.
create table u_groups (u_group_id int primary key ...)


Код: sql
1.
2.
3.
create table users_u_groups_xref (users_u_groups_xref_id int primary key,
u_group_id int references u_groups,
usr_id int references my_users)


Код: sql
1.
create table o_groups (o_group_id int primary key ...)


Код: sql
1.
2.
3.
create table objects_o_groups_xref (objects_o_groups_xref_id int primary key,
o_group_id int references o_groups int,
obj_id int references my_objects )


права на уровне групп
Код: sql
1.
2.
3.
4.
5.
create table o_u_groups_permissions (o_u_groups_permissions_id int primary key
o_group_id int references o_group,
u_group_id int references u_group,
act_id int references my_actions
)



и таблица my_permissions превращается во вьюху объединяющая права юзеров на объекты плюс группы юзеров на группы объектов а также (в худшем случае) юзеров на группы объектов и групп юзеров на объекты.
Для достижения максимальной скорости рекомендую эту вьюху материализовать, ибо модификация прав происходит гораздо реже чем проверка прав.

Для тех кому и этого мало, можно сделать группы иерархичными (реализуя хранения иерархии различными способами)

Типа такого ответа ожидалось?

kormot WHERE MD5(aa.userLogin)="'.$loginHash.'"СУБД не любит сравнений с фунциями над колонками. Это затрудняет индексирование сводя план к тупому скану. Решение либо вводить зависимое поле и поддерживать его целостность триггером и/или ограничением либо смотреть как поддерживает ваш mysql индекс по функции
...
Рейтинг: 0 / 0
25 сообщений из 26, страница 1 из 2
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Организация модели безопасности на уровне БД
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]