Организация доступа к программе

[Kotъ-Begemotъ]

Сразу извиняюсь. что сюда, но вопрос не с точки зрения безопасности как таковой. а больше с точки зрения правильности политики доступа, поэтому не в защиту или администрирование пишу, а сюда.

Вопрос собственно в политике доступа к программе. Ситуация такая - встроенных возможностей FireBird явно не хватает. Мне например нельзя допускать к работе пользователя, если пользователь с таким именем уже работает в системе, надо иметь возможность блокировать пользователя на уровне программы, учитывать "группу полномочий" юзера и так далее...

С другой стороны давать всем пользователям возможность логиниться под SYSDBA а затем подключать "свою" политику - тоже явно не выход... Напрашивается комбинация двух политик. Думается так:

1. Диалог ввода имени и пароля. Юзер вводит имя и пароль. Имена привыкли вводить по русски, думаю бороться с этим не следует, нужно просто транслитеровать имя. Далее идёт попытка коннекта к базе с этим именем, РОЛЬЮ RL_LOGIN (которая позволяет получить доступ на SELECT только к ОДНОЙ таблице - MY_USERS к примеру, или, что даже лучше, к одной SP которая будет возвращать необходимые данные.

2. Если попытка коннекта провалилась - всё понятно. Неверное имя и пароль, так как роль RL_LOGIN назначается ВСЕМ пользователям по-умолчанию.

3. Если попытка коннекта удачна - обращение к таблице MY_USERS (или запуск SP) и получение интересующих меня параметров - например в виде реальной роли этого пользователя, и скажем, кода возврата, который будет зависеть от того разрешён ли юзеру доступ, или он заблокирован администратором, работатет ли уже такой юзер в системе, или нет... Сохраняем полученное, если ситуация - отказ в доступе, выдаём соответствующее предупреждение.

4. Дисконнект от базы.

5. Если код возврата был позитивным то идёт повторный коннект к базе с этим же именем, паролем, но уже с ПРАВИЛЬНОЙ ролью, дающей необходимые права доступа к таблицам, SP, просмотрам и. т. п...

Таким образом в БД будет как минимум ДВЕ роли - одна только для первичного коннекта, вторая - для реальной работы (может будут и другие, в зависимости от полномочий юзера - конечно, я не дам доступа к SP, вносящей какие-нибудь каскадные изменения, скажем, обычному рядовому юзеру - ему это ни к чему).

Придётся, правда предусмотреть коннект SYSDBA чтобы коннект админа проходил "в одно касание" а не по такой двухзвенной системе...

Как думаете, нормально? Или есть какие-то наработки в этой области, про которые я не в курсе? Подскажите, плиз...

ЗЫ. И еще одно - если у кого есть на примете грамотный материал по просмотрам VIEW - киньте плиз, ссылочку, потому что никак я понять этого механизма не могу Нет, технически понимаю, а обоснования - то есть где это разумно применять, по сравнению с запросами как-то вот не вижу особо...

[kdv]

Придётся, правда предусмотреть коннект SYSDBA чтобы коннект админа проходил "в одно касание"

а админу зачем в программе ходить?

Как думаете, нормально?

нормально.

И еще одно - если у кого есть на примете грамотный материал по просмотрам VIEW - киньте плиз, ссылочку, потому что никак я понять этого механизма не могу

что значит "грамотный материал"??? view можно рассматривать как угодно. например, как "быстрый способ выполнить часто нужный и замудренный запрос".

то есть где это разумно применять

можно вообще нигде не применять. или хочется применять?

view это "сокращенный запрос". без параметров. Еще view можно использовать для "редактируемости "нередактируемых" запросов". Как "подставную таблицу". Собственно, это и есть "виртуальная таблица".

[Kotъ-Begemotъ]

а админу зачем в программе ходить?

Дык как же... А если надо юзера нового создать? Это кроме SYSDBA кто-то может сделать? Вроде заказчики привыкли, что есть в проге "менеджер пользователей" с возможностью создать нового (правда с минимильными правами, то есть в моём случае диспетчера). Или им каждый раз когда надо нового создать меня вызывать, чтобы я приехал, вошёл под SYSDBA и создал?!?
В принципе вроде больше не за чем вроде под SYSDBA заходить - бэкап делать и юзеры вроде как могут. Ну, рестор не могут в эту же базу, но насколько я понял это вообще не очень "правильный" путь - лучше рядом отресторить в другую базу, проверить работоспособность, и переключить юзеров на эту БД...

Хотя как не за чем, а метаданные изенить?!? Добавить индекс, или наоборот неэффективный индекс вместе с FK снести? Новую SP установить, или UDF?

[Kotъ-Begemotъ]

можно вообще нигде не применять. или хочется применять?
view это "сокращенный запрос". без параметров. Еще view можно использовать для "редактируемости "нередактируемых" запросов". Как "подставную таблицу". Собственно, это и есть "виртуальная таблица".

Не то чтобы прямо уж "хочется", просто ситуация мутная - никак не пойму каких-то больших плюсов применения просмотров... Или просто к своей задаче приложить не могу?!? Буду еще литературу читать... Вот с SP понятно, очень здорово! Избавит меня от многих траблов, с "промежуточными" таблицами, и "каскадами" запросов... А вот с VIEW - что-то в голове не складывается пока никак...

[kdv]

Дык как же...

ок, проехали.

наоборот неэффективный индекс вместе с FK снести?

гм. кто тебе такое посоветовал? или ты на отчеты IBAnalyst усердно молишься?

просто ситуация мутная - никак не пойму каких-то больших плюсов применения просмотров...

извини, ассоциация в голове возникла - мартышка и очки.
ну не надо оно тебе - так не юзай. Неужели стоит сверхзадача - всего попробовать понемножку, понапихать в модель БД?

А вот с VIEW - что-то в голове не складывается пока никак...

я тебе задачи view перечислил. если ты пытаешься придумать, на что эти view надеть - не надо. Обычно фичи БД используются по необходимости. Необходимости во view нет? ну и славно.

[Kotъ-Begemotъ]

ок, проехали.

Погоди, почему? Объяснить что ли жалко? ((

наоборот неэффективный индекс вместе с FK снести?

гм. кто тебе такое посоветовал? или ты на отчеты IBAnalyst усердно молишься?

А ты "на глазок" оцениваешь чтоль? Если у меня десяток "системных" таблиц с 5-10 значениями, и основная база, от 50 тыс, и до лимона записей, в которых эти 5-10 значений повторяются, ты считаешь, что надо FK строить?

я тебе задачи view перечислил. если ты пытаешься придумать, на что эти view надеть - не надо. Обычно фичи БД используются по необходимости. Необходимости во view нет? ну и славно.

Ну. надеюсь, что так... Не буду бежать впереди паровоза Пока вроде не надо, там посмотрим...

[Tonal]

2 Kotъ-Begemotъ
Может ты сформулируешь, что именно ты хочешь добиться от этих своих "политик доступов"?
Какие задачи решить?
Какие возможные атаки предполагаешь?

В простейшем случае подойдёт вообще общий конект под SYSDBA, или под общим пользователем со всеми правами + таблица пользователей.

[kdv]

Погоди, почему? Объяснить что ли жалко?

ты запарил своей мнительностью - меня вполне устроило объяснение, зачем нужен админ в программе.

А ты "на глазок" оцениваешь чтоль?

есть у меня некоторые телепатические наклонности. ошибся?

в которых эти 5-10 значений повторяются, ты считаешь, что надо FK строить?

я считаю что сначала делается модель, без оглядки на 1, 5 или 10 повторяющихся значений. А затем, когда модель наполнена тестовыми или реальными данными, можно начинать оптимизировать.
замечу - ОПТИМИЗИРОВАТЬ. потому что FK это средство контроля целостности. А оптимизация может ехать в ту или иную сторону, в зависимости от реальных данных. Сегодня 5 значений, а завтра 5 миллионов. Я утрирую, но изменение данных во времени тоже надо держать в голове.

[Slavik]

Далее идёт попытка коннекта к базе с этим именем, РОЛЬЮ RL_LOGIN (которая позволяет получить доступ на SELECT только к ОДНОЙ таблице - MY_USERS к примеру, или, что даже лучше, к одной SP которая будет возвращать необходимые данные.

Можно дать доступ к таблцице MY_USERS или SP служебному пользователю PUBLIC (т.е. "всем") и не париться с дополнительной ролью RL_LOGIN. Таким образом в БД достаточно ОДНОЙ роли для каждого типа рабочего места.

...просто ситуация мутная - никак не пойму каких-то больших плюсов применения просмотров...

Я вьюшки использую в том числе для разделения доступа. Например, пользователи смотрят не напрямую в таблицу документов, а через VIEW, который возвращает только нужные поля и только тех документов, доступ к которым пользователю разрешён. Это нужно для того, чтобы продвинутый пользователь, зная только свой логин, не смог посмотреть запрещённые ему документы левыми инструментами типа того же IBExpert'а.

[stix-s]

.....
зная только свой логин, не смог посмотреть запрещённые ему документы левыми инструментами типа того же IBExpert'а.

так ему помимо логина еще роль надо знать, а если реальных пользователей FB ему вообще не показывать,а только уже "русифицированных" из промежуточной таблицы, то копаться в базе сложнее будет, правда PUBLIC я бы не пользовал, а отдельного юзверя с зашитым паролем только для чтения таблицы пользователей

[Slavik]

так ему помимо логина еще роль надо знать

rdb$roles, rdb$user_privileges

а если реальных пользователей FB ему вообще не показывать,а только уже "русифицированных" из промежуточной таблицы, то копаться в базе сложнее будет, правда PUBLIC я бы не пользовал, а отдельного юзверя с зашитым паролем только для чтения таблицы пользователей

Что знает клиентская программа, то может узнать и юзер! Ведь разговор о "продвинутом" юзере

Напрасно боишься PUBLIC. Страх легко преодолевается хранимой процедурой или вьюхой, которые показывают не все данные по всем пользователям, а только те, которые относятся к текущему пользователю, и которые клиенсткой программе всё равно надо знать для корректной работы. Кстати, автор топика предложил интересный вариант с транслитерацией. С ней и не надо никаких "промежуточных" таблиц. Правда "ADMIN" и "АДМИН" будут одним и тем же юзером

Я сторонник ясных схем разграничения прав, в которых пользователь при правильной работе админов никакими средствами не может получить несанкционированный доступ к данным, а не мутняка с "зашитыми" логинами и паролями.

[stix-s]

rdb$roles, rdb$user_privileges

Пользователь показан как Иванова Мария Сергеевна - выполни свой запрос

Ведь разговор о "продвинутом" юзере

абсолютной защиты нет

Напрасно боишься PUBLIC. Страх легко преодолевается хранимой процедурой или вьюхой, которые показывают не все данные по всем пользователям, а только те, которые относятся к текущему пользователю, ........

И заодно показывает пользователю реальный логин с паролем к FB без всяких усилий с его стороны

Я сторонник ясных схем разграничения прав, в которых пользователь при правильной работе админов никакими средствами не может получить несанкционированный доступ к данным, а не мутняка с "зашитыми" логинами и паролями.

Зашивается один пользователь, только для доступа к первоначальной таблице

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

[Slavik]

Как я уже писал, речь идёт о продвинутом пользователе. Для него узнать "зашитый" в программу логин и пароль не проблема. Способов масса. Кроме того, беда "зашитых" паролей в том, что когда узнаёт его один "лишний" человек, то эта информация быстро становится общедоступной.

Дублировать систему доступа к серверу Interbase/Firebird, да ещё и так убого, считаю глупым занятием.

P.S. Вот что меня действительно удручает в системе прав Firebird, так это осутствие стандартных средств защиты метаданных. Т.е. нельзя запретить любому пользователю создавать свои объекты и самое главное изменять значения генераторов! Правда с фактами диверсий до сих пор не сталкивался...

[Kotъ-Begemotъ]

я считаю что сначала делается модель, без оглядки на 1, 5 или 10 повторяющихся значений. А затем, когда модель наполнена тестовыми или реальными данными, можно начинать оптимизировать.
замечу - ОПТИМИЗИРОВАТЬ. потому что FK это средство контроля целостности. А оптимизация может ехать в ту или иную сторону, в зависимости от реальных данных. Сегодня 5 значений, а завтра 5 миллионов. Я утрирую, но изменение данных во времени тоже надо держать в голове.

Так-то оно так, но в моём случае модель не с нуля делается, да и статистика уже существует. Мне не надо прикидывать каков будет прирост количества записей, я это просто знаю. Как и количество значений в справочниках. То есть цифры про которые я говорил - 5 записей и таблица растущая на ~50 тыс. записей в неделю это реальность... Поэтому в данном конкретном случае представляется ненужным построение ссылочной целостности с использованием FK, которое повлечёт за собой создание индекса, заведомо имеющего плохую селективность, да еще и ухудшающуюся со временем... Взято вроде не с потолка, а из соответствующей литературы...

ЗЫ. А IBAnalyst конечно использую, мои телепатические способности, к сожалению развиты не так как у тебя )) Смотрю как оптимальнее построить запрос, какие показатели индексов. Пока в первичном тесте, как запущу проект буду уже по реальным данным отслеживать...

[kdv]

IBAnalyst конечно использую

тогда читай хелп к нему, там есть Questions & Answers, пункт про "плохие" индексы по FK. Т.е. чего с ними делать.

[Kotъ-Begemotъ]

IBAnalyst конечно использую

тогда читай хелп к нему, там есть Questions & Answers, пункт про "плохие" индексы по FK. Т.е. чего с ними делать.

Опа! Спасибо, я хелп как раз и не догадался почитать, там вроде и так всё ясно Действительно полезная информация. Хотя про "относительный" контроль целостности на триггерах я уже у Борри вычитал Не панацея, конечно, но всё же...
Хотя тут и бизнес-логика помогает неплохо для предотвращения таких ситуаций.

[stix-s]

Как я уже писал, речь идёт о продвинутом пользователе. Для него узнать "зашитый" в программу логин и пароль не проблема. Способов масса. Кроме того, беда "зашитых" паролей...

Беда всех паролей в том, что пока они лежат в памяти клиента, их можно узнать и не важно "зашит" он или нет
Защита должна быть достаточной, а не пароноидальной
Подобные надстройки не для дублирования средств доступа FB, а для расширения возможностей

http://ibase.ru/devinfo/treedb2.htm
http://www.delphiplus.org/articles/ib/o ... index.html