Комментарии 6
В принципе старо как мир, доводилось иметь дело с таким подходом и как раз на уровне работы с БД через процедуры и представления.
Основная проблема: надо писать во всех функциях. Тут всё зависит от тех кто этим занят, если проект большой, то за всеми этими проверками просто не уследить. Люди могут быть ленивы, глупы или просто торопиться. Как следствие проверок не будет в коде.
Если код пилят со «стороны» к примеру подрядчики, становится ещё хуже.
В последнем примере есть поле u.branch_id. Я так понимаю это некий идентификатор доступа к ресурсу?.. Так вот, если вам нужно хранить несколько идентификаторов доступа к одному ресурсу, то вы либо увеличите количество записей в таблице, либо будете использовать массивы для их хранения. Если у Вас несколько ресурсов с разными идентификаторами, тогда вам нужно дополнительное поле или таблицы заточенные под эти ресурсы. Тогда не ясно, каким образом Ваше решение будет быстрее чем контроль строк от postgres из коробки?
Основная проблема: надо писать во всех функциях. Тут всё зависит от тех кто этим занят, если проект большой, то за всеми этими проверками просто не уследить. Люди могут быть ленивы, глупы или просто торопиться. Как следствие проверок не будет в коде.
Если код пилят со «стороны» к примеру подрядчики, становится ещё хуже.
В последнем примере есть поле u.branch_id. Я так понимаю это некий идентификатор доступа к ресурсу?.. Так вот, если вам нужно хранить несколько идентификаторов доступа к одному ресурсу, то вы либо увеличите количество записей в таблице, либо будете использовать массивы для их хранения. Если у Вас несколько ресурсов с разными идентификаторами, тогда вам нужно дополнительное поле или таблицы заточенные под эти ресурсы. Тогда не ясно, каким образом Ваше решение будет быстрее чем контроль строк от postgres из коробки?
Спасибо за отклик. Как я упоминал в статье, для меня оборачивание кода в хранимые процедуры это не минус, а плюс, но тут, как говорится «на вкус и цвет». Ошибиться и забыть что-то при написании клиента при таком подходе просто невозможно — предполагается, что у пользователя, под которым ходит приложение просто нет прав ни на что, кроме вызова процедур.
А branch_id это бизнес поле — филиал. Просто для примера. Ничего в структуру таблиу спуиально добавлять не нужно.
А branch_id это бизнес поле — филиал. Просто для примера. Ничего в структуру таблиу спуиально добавлять не нужно.
Простите, но мне лично контроль даже в хранимых процедурах кажется всё равно не эффективным, но дело не в производительности, а в том, что результат выполнения запросов известен только после их выполнения. Независимо от того, что выполнялось. В этом кроется дилемма безопасности. Если говорить прямо, то сегодня уровень безопасности обеспечивает не саму безопасность, а доступ на выполнение той или иной конструкции запроса. Например, если вы хотите удалить одну запись, а в результате удаляется 100, то вопрос к кому? К системе безопасности или к разработчику выполнимой процедуры? Понятно, что все запросы тестируются до попадания в продакшен, но по факту один разработчик должен доверяться другому и не может сам что-то настроить.
Я бы для себя поставил задачу безопасности по другому. Например:
1. Открыть транзакцию.
2. до выполнения запроса на удаления «выставил» в программе атрибут1=таблица1, процедура=удаление, количество записей=1.
3. Запуск запроса.
4. Проверка, что действительно из таблицы 1 было именно удалена запись в количестве именно 1шт. Если в результате выполнения процедуры произошло удаление больше одной записи или произошли изменения в других таблицах, то выполнить rollback, иначе — commit.
Вот теперь у программиста backend-а есть контроль над разработчиком БД. Класс! Вот такая система безопасности является именно безопасностью, а не системой распределения прав доступа. Вдруг разработчик БД «немного» накосячил и что-то упустил, ну так такая система безопасности не даст ему произвести действия, которые не планировал разработчик backend-а.
Но о такой системе я ещё не слышал )))
Я бы для себя поставил задачу безопасности по другому. Например:
1. Открыть транзакцию.
2. до выполнения запроса на удаления «выставил» в программе атрибут1=таблица1, процедура=удаление, количество записей=1.
3. Запуск запроса.
4. Проверка, что действительно из таблицы 1 было именно удалена запись в количестве именно 1шт. Если в результате выполнения процедуры произошло удаление больше одной записи или произошли изменения в других таблицах, то выполнить rollback, иначе — commit.
Вот теперь у программиста backend-а есть контроль над разработчиком БД. Класс! Вот такая система безопасности является именно безопасностью, а не системой распределения прав доступа. Вдруг разработчик БД «немного» накосячил и что-то упустил, ну так такая система безопасности не даст ему произвести действия, которые не планировал разработчик backend-а.
Но о такой системе я ещё не слышал )))
Статья про plpython-ориентированный механизм аутентификации, а не «разграничение доступа». Ваш GD.get('user_id') можно и RLS засунуть. Я не говорю о достоинствах и недостатках предложенного метода. Я лишь про название и содержание статьи.
Все эти надстройки разграничения доступа над штатной системой ни к чему хорошему не приведут. По сути придется обеспечивать единство правил в штатной системе и своей. Лучше использовать только штатную и научить приложение адекватно на это реагировать. В крайнем случае делать только ту часть, которой нет в штатной системе. И еще надо четко разделять понятия безопасности информации и разграничение доступа к данными, это не одно и тоже.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разграничение прав доступа в PostgreSQL