|
Название: Разграничение прав доступа в SQL сервере Отправлено: -QT- от Август 28, 2007, 14:38 Прошу прощения за вопрос не по теме НО запостил я этот же вопрос в нужном форуме, а туда видимо
никто не заходит. Благодарю за понимание. :D Доброго времени суток. Объясните, кто использовал схемы в PostgreSQL, как это можно практически использовать для разделения доступа в приложении и необходимо ли это делать. Погуглив проблемму наткнулся на Veil for PostgreSQL. Скачал - собрал - поставил - исследую. Кто использовал данную приблуду отзовитесь - поделитесь мнениями. Заранее спасибо. Название: Re: Разграничение прав доступа в SQL сервере Отправлено: alexis от Август 28, 2007, 20:10 Именно данную "приблуду" не использовал, но...
Для разраграничения прав у нас используется самописный тип: row_acl. Вот так выглядит из psql консоли. Код: cms1=> select name, usr, grp, acl from element limit 5; То есть: каждая строка таблицы имеет колонку типа row_acl В этом типе в 15 битах описываются права для владельца, группы и остальных. В общем - unix-way. В добавок ко всему, реальные таблицы закрыты вьюхами на DML. На вьюхах описаны правила, что делать при вставке, апдейте, делите. Вьюхи построены на основе права "чтения" на объект. Название: Re: Разграничение прав доступа в SQL сервере Отправлено: Вудруф от Август 29, 2007, 07:04 Как вариант - отдельные таблицы для различных прав доступа.
Далее, создаётся две схемы. В первой - все таблицы+процедуры для работы. Вторая схема имеет доступ к процедурам первой, причём все процедуры работают только если первоначально была вызвана процедура login (пользователь вошёл в систему) и при этом проверяют права доступа для любого совершаемого действия. Возможно, мы несколько перестраховались, но всё работает. Цель - повышение безопасности, чтобы даже при взломе нашего web-сервера злоумышленник не мог напрямую работать с базой данных... Название: Re: Разграничение прав доступа в SQL сервере Отправлено: Вячеслав от Август 29, 2007, 07:26 Вот сюда посмотри - не слоник но рядом ;)
http://www.ibase.ru/devinfo/treedb2.htm (http://www.ibase.ru/devinfo/treedb2.htm) Название: Re: Разграничение прав доступа в SQL сервере Отправлено: Вячеслав от Август 29, 2007, 07:28 Именно данную "приблуду" не использовал, но... Гы таки у вас acl или rwd ? ЕСли первое - скоростью работы и размером баз не поделитесь - а то я как-раз голову ломаю как ускорить процесс .......Для разраграничения прав у нас используется самописный тип: row_acl. Вот так выглядит из psql консоли. То есть: каждая строка таблицы имеет колонку типа row_acl В этом типе в 15 битах описываются права для владельца, группы и остальных. В общем - unix-way. Название: Re: Разграничение прав доступа в SQL сервере Отправлено: alexis от Август 29, 2007, 08:28 Назвали мы его так - row_acl
Аксес лист для строки. r - read ( как select ) w - write( как update/delete ) d - delete ( как уадение подчиненного объекта: связи, подстатьи, блоба) i - insert ( как вставка подчиненного объекта ) x - право на просмотр объектов сущности - контейнер: раздел, страница ) Тип внутренне представлен int'ом. При выводе text row_acl_out() преобразует интовую маску в текстовое представление Есть гистовый индекс для этого типа. Скорости на больших объемах не замеряли. Могу сказать, что сейчас на >5 гектарной базе запросы умещаются в сотые доли секунды. Название: Re: Разграничение прав доступа в SQL сервере Отправлено: Вячеслав от Август 29, 2007, 09:19 Ясненько - то-есть все-таки rwd ;) Ну что-ж пошел дальше рыть ???
Название: Re: Разграничение прав доступа в SQL сервере Отправлено: -QT- от Август 29, 2007, 15:18 Не думал, что будет такой активный отклик на мой вопрос.
Спасибо что откликнулись. Прочитал http://www.ibase.ru/devinfo/treedb2.htm (http://www.ibase.ru/devinfo/treedb2.htm) и пришел к выводу что система RWD для моего случая подходит более чем ACL. Теперь нужно правильно реализовать эту схему для моего случая. По поводу "схем" в постгресе - тоже понял, хочу только уточнить. Вудруф, у Вас "схема" применялась по принципу - одна схема - один АРМ или более глобально ? По вопросу Veil - скажу так (если не ошибаюсь) Это то что нужно даже с интегрированием в сам сервер. ;D Тут еще нужно покопаться ... ::) ??? Название: Re: Разграничение прав доступа в SQL сервере Отправлено: alexis от Август 29, 2007, 17:01 Если есть желание, могу сделать архив с реализацией нашей структуры базы.
Архив init скриптов. Название: Re: Разграничение прав доступа в SQL сервере Отправлено: -QT- от Август 30, 2007, 08:05 Если есть желание, могу сделать архив с реализацией нашей структуры базы. С удовольствием посмотрю. Большое спасибо.Архив init скриптов. Название: Re: Разграничение прав доступа в SQL сервере Отправлено: -QT- от Август 30, 2007, 09:05 Вчера обдумывал варианты решения. ???
Остановившись на схеме RWD подумалось, ведь в самой СУБД есть и пользователи и группы так кто-же нам мешает их использовать в решении проблемы разграничения прав - !!!! Оказывается - незнание ! ;D или нехватка знаний. Подскажите КАК залезть в нутро сервера чтобы по умолчанию в таблицу добавить несколько полей и триггеров. Название: Re: Разграничение прав доступа в SQL сервере Отправлено: Вячеслав от Август 30, 2007, 15:54 НЕ НАДО трогать системные таблицы - гимору не оберешься :(
Вообще-то логичнее делать разграничение прав доступа для каждой бд... А если хош нормальную защиту даннных - смотри в сторону мандатов -> Oracle Linter.... etc Название: Re: Разграничение прав доступа в SQL сервере Отправлено: alexis от Август 30, 2007, 16:08 Мы используем внутренние роли постгреса.
+ посгрес позволяет создавать пользователей per-database Название: Re: Разграничение прав доступа в SQL сервере Отправлено: -QT- от Август 31, 2007, 10:28 НЕ НАДО трогать системные таблицы - гимору не оберешься :( Для каждой базы данных права будут создаваться. Необходимо разграничение по доступу для записи.Вообще-то логичнее делать разграничение прав доступа для каждой бд... А если хош нормальную защиту даннных - смотри в сторону мандатов -> Oracle Linter.... etc Иметь владельца записи и права для ( владельца-группы-прочие ). По вопросу СУБД - никаких шатаний не подразумевается - выбран Постгрес. Возможно использовать данную схему без изменения системных таблиц но тогда я думаю вся система доступа будет делаться не опираясь на возможности СУБД - а самостоятельно и сущесствовать обособленно от какого либо сервера баз данных. Название: Re: Разграничение прав доступа в SQL сервере Отправлено: -QT- от Август 31, 2007, 10:32 Мы используем внутренние роли постгреса. Если можно подробнее раскажите где копать, читать, смотреть.+ посгрес позволяет создавать пользователей per-database Название: Re: Разграничение прав доступа в SQL сервере Отправлено: Вудруф от Сентябрь 03, 2007, 11:57 Цитировать У Вас "схема" применялась по принципу - одна схема - один АРМ или более глобально? Открытый пользователь - один, закрытых схем - несколько. Но сделано так, скорее, из исторических соображений. Ну и независимые схемы удобнее обслуживать.Реально достаточно одного открытого пользователя (с известным паролем) для подключения к БД web-сервера и одну схему другого пользователя, содержащую функциональную часть всех приложений. Название: Re: Разграничение прав доступа в SQL сервере Отправлено: -QT- от Сентябрь 03, 2007, 15:11 Цитировать У Вас "схема" применялась по принципу - одна схема - один АРМ или более глобально? Открытый пользователь - один, закрытых схем - несколько. Но сделано так, скорее, из исторических соображений. Ну и независимые схемы удобнее обслуживать.Реально достаточно одного открытого пользователя (с известным паролем) для подключения к БД web-сервера и одну схему другого пользователя, содержащую функциональную часть всех приложений. Для более полного прояснения ситуации расписываю требования к системе. Существуют АРМы - и в пределах каждого АРМа необходимо динамически изменять (то-есть раз в день, неделю, месяц) права доступа групп пользователей (или одного пользователя) внутри этого АРМа к части информации -> то-есть сам пользователь может назначать кому (какой группе пользователей) какая информация доступна для просмотра-изменения-удаления или это делается автоматически в шаблонах для этого пользователя. Банальный пример: Планировщик задач. Руководитель предприятия ставит задачу начальнику отдела. Видеть задачу может только те лица, которые выбранны для исполнения задачи тоесть начальник отдела и возможно заместитель, но они имеют право редактировать только ту информацию, которая относится к отчету о выполнении работы. В свою очередь начальник отдела разбивает установленную задачу на подзадачи для сотрудников с аналогичным алгоритмом обработки, только поля для изменения у сотрудников могут отличаться от предидущего алгоритма. Это один из возможных вариантов использования. Другие относятся к хранению и использованию документооборота предприятия (кому читать, кому писать, кому еще чего много можно ;D ну типа удалять). Для этого пытаюсь найти основу решения, которое можно использовать в разграничении информации. ПС. Да забыл сказать, что пользователей может быть много 200-500 отэтого и вся возня много разных профилей требуется. Название: Re: Разграничение прав доступа в SQL сервере Отправлено: -QT- от Сентябрь 04, 2007, 19:37 Сегодня на работе поставил таки Veil для постреса залил демобазы и потестил как они
описывают в документации. Пока получил только удовлетворение от увиденного. Раздача прав владельцем записи для других на чтение изменение и удаление информации. Похоже что можно раздавать права и для групп тоже - но это еще нужно проверить, а также отштудировать админ-возможности и API но это уже проза жизни.... едем дальше. Название: Re: Разграничение прав доступа в SQL сервере Отправлено: Вудруф от Сентябрь 05, 2007, 10:21 Попробую пояснить, почему мы не пользовались схемой, обеспечивающей "control access to data at the row, or even column, level".
У нас - несколько тысяч сотрудников. Большинству из них приходится работать с нашей системой. Именно поэтому проще делать web-ориентированные АРМы. Далее, если мы будем использовать встроенные в базу данных ограничения по принципу unix-way (rwx), то нам придётся создавать столько пользователей БД, сколько у нас сотрудников. Таким количеством пользователей базы данных очень сложно управлять. Выход - создание отдельных таблиц для работы с пользователями и их правами доступа. При этом все проверки основываются на "разрешениях". Есть таблица "тип разрешения", есть таблица "разрешение", пользователю или группе. Для специфических типов разрешений в таблице групп хранится название процедуры, проверяющей соответствие текущего пользователя (не базы данных, а зарегистрированного при помощи вызова login) группе. Так сделано для доступа к разделам, доступным пользователям только на момент их нахождения в той или иной должности. Иначе же мы должны были бы давать такие права людям отдельно, при их увольнении или смены должности - их забирать обратно. Повторяю, пользователей - тысячи. Кстати, проверка доступа на уровне строк может строиться и на основе предикатов. Если предикат истинен - строка в выборку попадает. Это так, к сведению. Однако, нами для доступа к информации применяются функции, возвращающие курсор (ещё один вариант - представления). В обоих случаях пользователю попадают только строки на основе его разрешений (проверяемые нами, а не БД). Вот так вот, несколько сумбурно... Будут вопросы - welcome :) Название: Re: Разграничение прав доступа в SQL сервере Отправлено: -QT- от Сентябрь 05, 2007, 11:01 Попробую пояснить, почему мы не пользовались схемой, обеспечивающей "control access to data at the row, or even column, level". У нас - несколько тысяч сотрудников. Большинству из них приходится работать с нашей системой. Именно поэтому проще делать web-ориентированные АРМы. === Да с таким кол-вом пользователей Ваш подход вполне оправдан Далее, если мы будем использовать встроенные в базу данных ограничения по принципу unix-way (rwx), то нам придётся создавать столько пользователей БД, сколько у нас сотрудников. Таким количеством пользователей базы данных очень сложно управлять. === Позвольте не согласиться с этим, Чем больше людей занимается производством продукции - тем больше менеджеров занимается их управлением, это же справедливо и для нашей ситуации: 30-пользователей --> 1 сервер + 1 админ ; 100-пользователей --> 2 сервера + 2 админа; 1000- пользователей --> 5 серверов + 4 адимна + 2 аникейщика поддержки (это просто для примера, но на практике приблизительно так-же) :) Выход - создание отдельных таблиц для работы с пользователями и их правами доступа. При этом все проверки основываются на "разрешениях". Есть таблица "тип разрешения", есть таблица "разрешение", пользователю или группе. Для специфических типов разрешений в таблице групп хранится название процедуры, проверяющей соответствие текущего пользователя (не базы данных, а зарегистрированного при помощи вызова login) группе. Так сделано для доступа к разделам, доступным пользователям только на момент их нахождения в той или иной должности. Иначе же мы должны были бы давать такие права людям отдельно, при их увольнении или смены должности - их забирать обратно. Повторяю, пользователей - тысячи. === Вот это и реализует Veil. Кстати, проверка доступа на уровне строк может строиться и на основе предикатов. Если предикат истинен - строка в выборку попадает. Это так, к сведению. === Об этом поподробнее пожалуста. ??? Однако, нами для доступа к информации применяются функции, возвращающие курсор (ещё один вариант - представления). В обоих случаях пользователю попадают только строки на основе его разрешений (проверяемые нами, а не БД). === Да, да это тоже вариант решения но ним можно управлять не для всех групп пользователей. Вот так вот, несколько сумбурно... Будут вопросы - welcome :) У меня из всего изученного и услышанного сложилось мнение: 1. Пользователь должен аутентифицироваться в начале по принципу Директор, Бухгалтер, Товаровед, Менеджер по продажам, и другие группы имеющие собственный АРМ (это относится к группе пользователей) тоесть АРМ АРМ и еще раз АРМ. (На уровне АРМ свои схемы - касательно Постгреса, тоесть набор таблиц, колонок в них, хранимок и др. и права на них читать-изменять-удалять) 2. После выбора АРМ идентифицировать себя как лицо тобиш ФИО Иванов Иван Иванович таб. № 548714258 ;D (На уровне пользователя набор кортежей ему доступный с указанными правами для него или его группы) 3. Доступ к данным пофамильно для ведения логов и разрешения конфликтных ситуаций типа (А Я Ваши документы в ГЛАЗА не видел, и не удалал я ничего - отстаньте от меня!!!!) :D ;D Если Вы считаете что я не прав - готов к конструктивным гонениям. :) Название: Re: Разграничение прав доступа в SQL сервере Отправлено: Вудруф от Сентябрь 17, 2007, 13:10 Извините, что с такой задержкой отвечаю :)
Не совсем понял про количество серверов и прочее. Я говорил про то, что пользователями базы данных (на уровне СУБД) сложно управлять. Про Veil почитаю, может, мы придумывали колесо :) Цитировать Об этом поподробнее пожалуста. Ну, я не знаю, есть ли такое в PostgreSQL. В Oracle можно накладывать ограничения на выборку из таблицы на основе предиката. Мы задаём некоторую функцию-предикат, если строка ей удовлетворяет - она попадает в выборку, иначе - нет. То же самое можно реализовать и в представлениях/встроенных функциях, возвращающих курсор, но писать надо меньше :) Работает именно для пользователей БД.Может, я что-то не то говорю, я с этим средством подробно не разбирался. Цитировать но ним можно управлять не для всех групп пользователей почему? по-моему, для каждого АРМ мы можем прописать свои специфические проверки3 - да, именно так 1, 2 - не совсем. У каждого пользователя есть своя учётная запись (одна). Он может находиться в нескольких группах пользователей (в некоторые он попадает автоматически, по какому-то критерию, в некоторые - заносится вручную). Права на работу с тем или иным приложением выдаются либо непосредственно пользователям, либо группе вручную. Далее, все АРМы находятся в одной системе. Т.е. пользователь входит в систему и может работать со всеми теми приложениями, с которыми ему разрешено работать, с тем уровнем привелегий, которые ему были даны. Название: Re: Разграничение прав доступа в SQL сервере Отправлено: andrew.k от Ноябрь 17, 2010, 18:25 Тип внутренне представлен int'ом. Расскажите, как это реализовано. Как поле int преобразовать к набору битов и как их значения использовать в запросах?При выводе text row_acl_out() преобразует интовую маску в текстовое представление Есть гистовый индекс для этого типа. |