|
|
|
Организация модели безопасности на уровне БД
|
|||
|---|---|---|---|
|
#18+
Добрый день Уважаемые! Подскажите мне пожалуйста есть ли очевидные плюсы и минусы в моей схеме. Когда проектирую приложение, то сразу же закладываю какую-то модель безопасности для приложения. Сейчас она у меня такого вида: В БД имеются сущности: Компания , Отдел , Проект , Сотрудник Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. И у пользователя (Сотрудника) при его авторизации из БД получаются данные по его доступам: "системного уровня" - типа можно в системе создавать объекты, заправвлять ими. Пользователей и т.п. "уровня компании" - типа в компании можно рулить в которой пользователь имеет права. "уровня отдела" .... "уровня проекта" .... И в БД этьо соответственно реализовано таким образом: Код: 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. При авторизации пользователя, соответственно загружаются все связанные с ним доступы всех уровней и помещаются соответственно в многомерный массив типа Код: php 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. И в дальнейшем при работе приложения, при выполнении действий, при которых соответственно надо иметь то или иное право, делается проверка из этого массива прав. Вопрос у меня соответственно, нет ли очевидных косяков в таком способе разграничении доступа в большом приложении? Как вы в своих проектах это реализуете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2016, 16:05 |
|
||
|
Организация модели безопасности на уровне БД
|
|||
|---|---|---|---|
|
#18+
Прочитал заголовок и понял, что он некорректный. Не организация безопасности на уровне БД, а организация системы доступа в БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2016, 16:07 |
|
||
|
Организация модели безопасности на уровне БД
|
|||
|---|---|---|---|
|
#18+
kormotКак вы в своих проектах это реализуете? SQL access rights + RLS по необходимости. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2016, 16:19 |
|
||
|
Организация модели безопасности на уровне БД
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovkormotКак вы в своих проектах это реализуете? SQL access rights + RLS по необходимости. А можно попросить в двух словах что такое SQL Access rights? Из гугла понял что это специфично для MS SQL Server, это в смысле доступ к отдельным таблицам, строкам и колонкам на уровне БД? Или нет? RLS совсем не нашёл. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2016, 16:29 |
|
||
|
Организация модели безопасности на уровне БД
|
|||
|---|---|---|---|
|
#18+
kormotА можно попросить в двух словах что такое SQL Access rights? RTFM GRANT/REVOKE, Row-Level Security. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2016, 16:33 |
|
||
|
Организация модели безопасности на уровне БД
|
|||
|---|---|---|---|
|
#18+
Это получается что при организации доступа на уровне БД, все пользователи у которых есть разграничение к отдельным объектам в БД, должны быть заведены как пользователи БД? Дмитрий, а при использовании БД MySQL какие способы организации доступа обычно используются? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2016, 16:40 |
|
||
|
Организация модели безопасности на уровне БД
|
|||
|---|---|---|---|
|
#18+
kormotЭто получается что при организации доступа на уровне БД, все пользователи у которых есть разграничение к отдельным объектам в БД, должны быть заведены как пользователи БД? Вы не поверите, но таки да, пользователи должны быть заведены как пользователи БД для того чтобы они могли использовать БД. Поделки на MySQL обычно не заботятся о безопасности вообще. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2016, 16:44 |
|
||
|
Организация модели безопасности на уровне БД
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovПоделки на MySQL обычно не заботятся о безопасности вообще. А те которые необычные поделки и заботятся о безопасности, то как это делают? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2016, 17:07 |
|
||
|
Организация модели безопасности на уровне БД
|
|||
|---|---|---|---|
|
#18+
kormot... при использовании БД MySQL какие способы организации доступа обычно используются? Аналогичные. Только в мускуле это все ужато. Т.е. только с доступами на уровне таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2016, 17:12 |
|
||
|
Организация модели безопасности на уровне БД
|
|||
|---|---|---|---|
|
#18+
kormotА те которые необычные поделки и заботятся о безопасности, то как это делают? Используя Oracle. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2016, 17:13 |
|
||
|
Организация модели безопасности на уровне БД
|
|||
|---|---|---|---|
|
#18+
Злой БобрАналогичные. Только в мускуле это все ужато. Т.е. только с доступами на уровне таблицы. Но ведь доступов уровня таблицы не хватит чтобы сделать разграничение прав разным объектам описанным в таблице. В итоге всё равно приходится контроль прав организовывать на уровне приложения, а хранение этих прав организовывать в БД. Я и спрашиваю в основном про реализацию хранения прав доступа в таблице, когда эти права реализуются на уровне приложения а в БД лишь хранятся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2016, 17:18 |
|
||
|
Организация модели безопасности на уровне БД
|
|||
|---|---|---|---|
|
#18+
kormotНо ведь доступов уровня таблицы не хватит чтобы сделать разграничение прав разным объектам описанным в таблице. Те, у кого СУБД не поддерживает RLS из коробки, решают эту проблему используя view, triggers и stored procedures. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2016, 17:23 |
|
||
|
Организация модели безопасности на уровне БД
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovkormotНо ведь доступов уровня таблицы не хватит чтобы сделать разграничение прав разным объектам описанным в таблице. Те, у кого СУБД не поддерживает RLS из коробки, решают эту проблему используя view, triggers и stored procedures. О, вот это я возьму на вооружение, спасибо! Это уже вопрос наверное отдельно топика, но раз уж тут view (они же курсоры вроде?) предложили, то я про них сразу и спрошу. Я к своему стыду эту конструкцию никогда не использовал, хотя понимаю всю его пользу. Видимо сейчас их и использую в деле. Скажите пожалуйста, а если у этих представлений плюсы в плане производительности. Т.е. если я создам представление, в котором данные к которым у меня часто идут обращения например в качестве вложенных SELECT'ов в запросах, то если я вместо этих вложеных SELECT'ов буду использовать представление, то будет ли какой-то выигрыш в производительности, или это конструкция для того чтобы удобней и проще было строить запросы? Также есть ли негативные эффекты для производительности БД если создано много представлений? Допустим для каждого пользователя если активного делать представление с данными к которым он часто обращается, то при наличии например 1000 представлений, не ухудшить ли это работу БД? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2016, 19:03 |
|
||
|
Организация модели безопасности на уровне БД
|
|||
|---|---|---|---|
|
#18+
kormotВ итоге всё равно приходится контроль прав организовывать на уровне приложения, а хранение этих прав организовывать в БД. Я и спрашиваю в основном про реализацию хранения прав доступа в таблице, когда эти права реализуются на уровне приложения а в БД лишь хранятся. В большинстве коммерческого софта именно так и делается - правами рулит приложение. Т.е. в БД создается 2 служебных пользователя. Под первым смотрим таблицу с правами, под вторым приложение работает с БД. Может конечно немного сумбурно высказал, но если непонятно то догадывайтесь. kormotСкажите пожалуйста, а если у этих представлений плюсы в плане производительности ... Также есть ли негативные эффекты для производительности БД если создано много представлений? Допустим для каждого пользователя если активного делать представление с данными к которым он часто обращается, то при наличии например 1000 представлений, не ухудшить ли это работу БД? Нету, это лишь визуальное отображение. Хотя для кого-то может показаться плюсом хренение селектов. Лично я не считаю это плюсом. Более того нет необходимости для каждого пользователя создавать свои вьюхи. Это путь в никуда. Насчет проихводительности - вроде объективных причин нет. Но я с таким бардаком не работал, так что - ХЗ как оно себя поведет. Но думаю что для небольшой БД это вообще не критично при любом раскладе. В любом случае - откажитесь от этого пути, а то засунут (клиенты) ваши руки в двери и правильно сделают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2016, 19:16 |
|
||
|
Организация модели безопасности на уровне БД
|
|||
|---|---|---|---|
|
#18+
Злой Бобр спасибо! Поэтично и понятно :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2016, 19:26 |
|
||
|
Организация модели безопасности на уровне БД
|
|||
|---|---|---|---|
|
#18+
kormotСкажите пожалуйста, а если у этих представлений плюсы в плане производительности. Т.е. если я создам представление, в котором данные к которым у меня часто идут обращения например в качестве вложенных SELECT'ов в запросах, то если я вместо этих вложеных SELECT'ов буду использовать представление, то будет ли какой-то выигрыш в производительности, или это конструкция для того чтобы удобней и проще было строить запросы? Также есть ли негативные эффекты для производительности БД если создано много представлений? Допустим для каждого пользователя если активного делать представление с данными к которым он часто обращается, то при наличии например 1000 представлений, не ухудшить ли это работу БД? Обычные view не улучшают производительности - да, они для более компактного и понятного кода. Бывают индексированные/материализованные view - вот они улучшают производительность операций чтения, но ухудшают производительность модификации данных. в принципе еще бывает что view (обычные) плохо обрабатываются оптимизатором, план запроса получается неоптимальным. Негативные эффекты от множества обычных view - смотря какая погрешность их измерения :) разумеется, какие-то ресурсы на это тратятся. Чтобы оные негативные эффекты от 1000 view ухудшили бы общую производительность системы хотя бы на 1% (если не считать упомянутые выше возможные проблемы с оптимизацией, которые не зависят от количества view) - я сомневаюсь. И да, view и курсоры - это совсем разные вещи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2016, 20:20 |
|
||
|
Организация модели безопасности на уровне БД
|
|||
|---|---|---|---|
|
#18+
авторразным объектам описанным в таблицеЧто-то я объектов и не вижу. Пользователей вижу, права вижу (похоже только ваше приложение умеет их использовать), а объектов не вижу. Или объекты это элементы интерфейса и приложение само решает как показывать пользователю. Тогда для другого приложения (например генератора отчетов) придется повторять эту логику. Про RLS https://rsdn.ru/article/db/RowLevelSecurity.xml ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2016, 03:07 |
|
||
|
Организация модели безопасности на уровне БД
|
|||
|---|---|---|---|
|
#18+
Уважаемые подскажите ещё пожалуйста такой момент: До этого всегда делал по схеме, что неавторизованный пользователь - значит с ним не связано никакой учётной записи в БД, и его userID=0 А тут подумал, что ведь для неавторизованных пользователей тоже может быть свой набор прав. Стоит ли заморачиваться с созданием анонимного пользователя в БД, с которым будет ассоциирован неавторизованный посетитель. И у этого анонимного пользователя допустим userID=1 т.е. при создании и первоначальном наполнении БД, там бы и прописывался пользователь и ему бы сразу давался набор прав. А то получается в ситуации когда анонимного пользователя нет, то получается что у него просто нет никаких прав доступа. И их невозможно никак реализовать. Опять же спрашиваю, как обычно в системах где нет возможности полноценно реализовать RLS на уровне БД (типа MySQL) это обычно делают? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.02.2016, 18:03 |
|
||
|
Организация модели безопасности на уровне БД
|
|||
|---|---|---|---|
|
#18+
Если доступом управляет приложение, тогда в БД вообще один служебный пользователь (пусть Злой Бобр пояснит зачем нужен второй) и базе вообще по барабану чему равен userID. Недостатки такого подхода проявятся, когда к базе будет подключатся другое приложение. Теоретически СУБД может поддерживать неавторизированного пользователя guest ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.02.2016, 18:53 |
|
||
|
Организация модели безопасности на уровне БД
|
|||
|---|---|---|---|
|
#18+
kormot... как обычно в системах где нет возможности полноценно реализовать RLS на уровне БД (типа MySQL) это обычно делают? Ну так возьми любую cms типа джумлы и посмотри как там реализовано. Лучше один раз увидеть ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.02.2016, 19:02 |
|
||
|
Организация модели безопасности на уровне БД
|
|||
|---|---|---|---|
|
#18+
SERG1257Если доступом управляет приложение, тогда в БД вообще один служебный пользователь (пусть Злой Бобр пояснит зачем нужен второй) и базе вообще по барабану чему равен userID. Недостатки такого подхода проявятся, когда к базе будет подключатся другое приложение. Теоретически СУБД может поддерживать неавторизированного пользователя guest Блин, вроде же из первых постов топика понятно, что речь идёт не о пользователях БД, а о пользователях приложения, которые хранятся просто как строки в одной из таблиц БД. Речь не о системных пользователях БД, а о пользователях приложения. Не знаю как ещё это описать. Короче опишу это так, что в это не те пользователи которыми подключаются к БД: Код: php 1. а те которые авторизуются через веб форму и проверяется их авторизация так допустим: Код: php 1. 2. 3. 4. 5. 6. 7. 8. А по поводу отдельного пользователя для чтения таблицы с доступами, так это очень даже дельное замечание от Злого Бобра . Если все запросы работают от пользователя БД которому ни читать ни писать в таблицы с доступами, то при возникновении SQL-инъекций, злоумышленник себе не сможет допустим прописать права в приложении, также как прочитать таблицу с логинами/хэшами. Так что тут мне по крайней мере дополнительных объяснений от Злого Бобра не требуется. Злой БобрНу так возьми любую cms типа джумлы и посмотри как там реализовано. Лучше один раз увидеть ... лезть туда.... Я вот что-то никогда cms-ками не пользовался, хотя дебажить сторонние проги, дебажил и понемногу вникал в суть написаного, но ради этого вопроса погружаться в джумлу... Может так у кого есть свои мысли на этот счёт со своими за и против? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.02.2016, 19:37 |
|
||
|
Организация модели безопасности на уровне БД
|
|||
|---|---|---|---|
|
#18+
SERG1257Если доступом управляет приложение, тогда в БД вообще один служебный пользователь (пусть Злой Бобр пояснит зачем нужен второй) и базе вообще по барабану чему равен userID. Недостатки такого подхода проявятся, когда к базе будет подключатся другое приложение. Теоретически СУБД может поддерживать неавторизированного пользователя guest никаких недостатков нет - какие права админ даст другим пользователям, такие права у них и будут userId для БД существенен, все ж лучше пусть юзер сам достучится до БД с минимальными правами, а потом уж получит делегированные права ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.02.2016, 20:00 |
|
||
|
Организация модели безопасности на уровне БД
|
|||
|---|---|---|---|
|
#18+
ViPRosSERG1257Если доступом управляет приложение, тогда в БД вообще один служебный пользователь (пусть Злой Бобр пояснит зачем нужен второй) и базе вообще по барабану чему равен userID. Недостатки такого подхода проявятся, когда к базе будет подключатся другое приложение. Теоретически СУБД может поддерживать неавторизированного пользователя guest никаких недостатков нет - какие права админ даст другим пользователям, такие права у них и будут Ну то есть "админу" придется дублировать всю систему безопасности приложения еще и в БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.02.2016, 21:58 |
|
||
|
Организация модели безопасности на уровне БД
|
|||
|---|---|---|---|
|
#18+
Кот Матроскин, частично, хотя бы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.02.2016, 22:50 |
|
||
|
Организация модели безопасности на уровне БД
|
|||
|---|---|---|---|
|
#18+
kormot а о пользователях приложения, которые хранятся просто как строки в одной из таблиц БД.То бишь у тебя должны быть таблицы пользователи Код: sql 1. объекты Код: sql 1. действия Код: sql 1. и одна большая связывающая их Код: sql 1. 2. 3. 4. 5. Для удобства управления пользователи и объекты (особые извращенцы могут сгруппировать и действия) могут объединятся в группы Код: sql 1. Код: sql 1. 2. 3. Код: sql 1. Код: sql 1. 2. 3. права на уровне групп Код: sql 1. 2. 3. 4. 5. и таблица my_permissions превращается во вьюху объединяющая права юзеров на объекты плюс группы юзеров на группы объектов а также (в худшем случае) юзеров на группы объектов и групп юзеров на объекты. Для достижения максимальной скорости рекомендую эту вьюху материализовать, ибо модификация прав происходит гораздо реже чем проверка прав. Для тех кому и этого мало, можно сделать группы иерархичными (реализуя хранения иерархии различными способами) Типа такого ответа ожидалось? kormot WHERE MD5(aa.userLogin)="'.$loginHash.'"СУБД не любит сравнений с фунциями над колонками. Это затрудняет индексирование сводя план к тупому скану. Решение либо вводить зависимое поле и поддерживать его целостность триггером и/или ограничением либо смотреть как поддерживает ваш mysql индекс по функции ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.02.2016, 23:22 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=39177291&tid=1540388]: |
0ms |
get settings: |
7ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
50ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
56ms |
get tp. blocked users: |
2ms |
| others: | 14ms |
| total: | 163ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...