Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
 Re: Запретительные гранты.  [new]
Jinn
Member

Откуда: С-Петербург
Сообщений: 204
С моей точки зрения, роли в Oracle реализованы чрезвычейно грамотно. Иерархическая наследственность. Грамотно распределив роли мы можем, назначив пользователю (всего лишь!) одну роль, предоставить ему доступ к нужным объектам базы данных. Включая новый объект базы в пользование для какой либо роли, мы предоставляем доступ к этому объекту и всем другим пользователям, которые обладают этой ролью (прямо или в порядке иерархии). Нет необходимости предоставлять гранты персональным пользователям. Вновь создаваемому пользователю присваивается (всего лишь!) роль и он может сразу приступать к работе. Используя такие возможности Oracle написать рабочее место по управлению доступом к базе - рутинная работа, даже думать не надо
11 ноя 04, 16:02    [1099073]     Ответить | Цитировать Сообщить модератору
 Re: Запретительные гранты.  [new]
Калина
Member

Откуда: Moskau
Сообщений: 2649
Ими заниматься удобно, а если делать делать через одно место, то даже в SQLServer не будет удобно.Нужно правильно представлять, что ты хочешь?
11 ноя 04, 16:03    [1099078]     Ответить | Цитировать Сообщить модератору
 Re: Запретительные гранты.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Зачем так кричать ? У всех такие проблемы и все как то справляются тем что есть. Грамотно проектируйте систему, и будет Вам щастье.
11 ноя 04, 16:04    [1099083]     Ответить | Цитировать Сообщить модератору
 Re: Запретительные гранты.  [new]
Геннадич
Member

Откуда: Алматы
Сообщений: 640
Ryaz
Oracle9i Label Security
Administrator’s Guide
Release 2 (9.2)
March 2002
Part No. A96578-01

Не обязательно запрещать доступ к данным, их можно ещё скрыть.
Почитай, подумай. Особенно про "инверсионные" группы. (В правильности перевода терминологии не ручаюсь)
- это за деньги,
а DBMS_RLS - это есть в базовой конфигурации
11 ноя 04, 16:05    [1099097]     Ответить | Цитировать Сообщить модератору
 Re: Запретительные гранты.  [new]
kto-to
Member

Откуда: Ukraine, Kyev
Сообщений: 835
Jinn
С моей точки зрения, роли в Oracle реализованы чрезвычейно грамотно. Иерархическая наследственность. Грамотно распределив роли мы можем, назначив пользователю (всего лишь!) одну роль, предоставить ему доступ к нужным объектам базы данных. Включая новый объект базы в пользование для какой либо роли, мы предоставляем доступ к этому объекту и всем другим пользователям, которые обладают этой ролью (прямо или в порядке иерархии). Нет необходимости предоставлять гранты персональным пользователям. Вновь создаваемому пользователю присваивается (всего лишь!) роль и он может сразу приступать к работе. Используя такие возможности Oracle написать рабочее место по управлению доступом к базе - рутинная работа, даже думать не надо


ты придумал хитруюсистему из 50 ролей.
Тут появляется чувак достаточно дать 12 твоих супер ролей
"и будет Вам счастье".
Потом оказывается, что все это правильно, но этот чувак
ни при каких обстоятельствах не должен получить
доступ к табличкам tbl1,tbl2?, к которым уже сейчас
имее доступ из-за 3-5 своих ролей.
И что ты будеш делать?
1)мудрить для чувака собственную роль и обновлять ее каждый раз,
когда будеш обновлять роли в которые он виртуально входит
И при этом ты еще должен зорко следить чтобы тому васе
из-за которого весь сыр-бор ты забыв не назначил случайно роль
с правами на этот грант.
2) убирать из этих 3-5 ролей этот грант в отдельную роль
и не забывать его выдавать всем чувакам, которым будеш
назначать одну из этих 3-5 ролей.
И при этом ты еще должен зорко следить чтобы тому васе
из-за которого весь сыр-бор ты забыв не назначил случайно роль
с правами на этот грант.

как видиш черезвычайно надежная система получается
и очень удобная.:-))))))))))))
а еще между прочим ты будеш постоянно ездить ко всем клиентам
и орбъяснять им как правильно нужно делать роли,
т.к. они не в состоянии будут сами все помнить и за всем уследить ...
11 ноя 04, 18:13    [1099694]     Ответить | Цитировать Сообщить модератору
 Re: Запретительные гранты.  [new]
kto-to
Member

Откуда: Ukraine, Kyev
Сообщений: 835
Геннадич
а DBMS_RLS - это есть в базовой конфигурации

Можеш показать пример использования на одной табличке и одной процедуре
11 ноя 04, 18:19    [1099720]     Ответить | Цитировать Сообщить модератору
 Re: Запретительные гранты.  [new]
stdio
Member

Откуда:
Сообщений: 4524
kto-to
Jinn
С моей точки зрения, роли в Oracle реализованы чрезвычейно грамотно. Иерархическая наследственность. Грамотно распределив роли мы можем, назначив пользователю (всего лишь!) одну роль, предоставить ему доступ к нужным объектам базы данных. Включая новый объект базы в пользование для какой либо роли, мы предоставляем доступ к этому объекту и всем другим пользователям, которые обладают этой ролью (прямо или в порядке иерархии). Нет необходимости предоставлять гранты персональным пользователям. Вновь создаваемому пользователю присваивается (всего лишь!) роль и он может сразу приступать к работе. Используя такие возможности Oracle написать рабочее место по управлению доступом к базе - рутинная работа, даже думать не надо


ты придумал хитруюсистему из 50 ролей.
Тут появляется чувак достаточно дать 12 твоих супер ролей
"и будет Вам счастье".
Потом оказывается, что все это правильно, но этот чувак
ни при каких обстоятельствах не должен получить
доступ к табличкам tbl1,tbl2?, к которым уже сейчас
имее доступ из-за 3-5 своих ролей.
И что ты будеш делать?
1)мудрить для чувака собственную роль и обновлять ее каждый раз,
когда будеш обновлять роли в которые он виртуально входит
И при этом ты еще должен зорко следить чтобы тому васе
из-за которого весь сыр-бор ты забыв не назначил случайно роль
с правами на этот грант.
2) убирать из этих 3-5 ролей этот грант в отдельную роль
и не забывать его выдавать всем чувакам, которым будеш
назначать одну из этих 3-5 ролей.
И при этом ты еще должен зорко следить чтобы тому васе
из-за которого весь сыр-бор ты забыв не назначил случайно роль
с правами на этот грант.

как видиш черезвычайно надежная система получается
и очень удобная.:-))))))))))))
а еще между прочим ты будеш постоянно ездить ко всем клиентам
и орбъяснять им как правильно нужно делать роли,
т.к. они не в состоянии будут сами все помнить и за всем уследить ...
Тогда как ты будешь объяснять клиентам, что дали право на объект пользователю, а у пользователя-то тю-тю его и не появилось?
Тем что выдано "запрещение"? Ok. А давайте рассмотрим такой вариант:

1) Права на A,B,С ->(выдали) Роль ABC
2) Роль ABC + запрещение на A -> Роль BC
3) Роль BC + право на A -> Роль ABC1
4) Роль ABC1 + право на A -> Роль ABC2
5) Роль ABC2 -> пользователю Scott

Итак, как вы объясните то, что Scott не имеет права на A? Ведь я ВЫДАЛ право доступа к объекту позже чем запрещение! ИТОГО, получается, что в Вашей идее прав не соблюдается закон комутативности:
какое-то право 1 + какое-то право 2 <> какое-то право 2 + какое-то право 1

И это, Вы думаете, правильно?
11 ноя 04, 18:56    [1099823]     Ответить | Цитировать Сообщить модератору
 Re: Запретительные гранты.  [new]
kto-to
Member

Откуда: Ukraine, Kyev
Сообщений: 835
stdio
quot Jinn]

1) Права на A,B,С ->(выдали) Роль ABC
2) Роль ABC + запрещение на A -> Роль BC
3) Роль BC + право на A -> Роль ABC1
4) Роль ABC1 + право на A -> Роль ABC2
5) Роль ABC2 -> пользователю Scott

Итак, как вы объясните то, что Scott не имеет права на A? Ведь я ВЫДАЛ право доступа к объекту позже чем запрещение! ИТОГО, получается, что в Вашей идее прав не соблюдается закон комутативности:
какое-то право 1 + какое-то право 2 <> какое-то право 2 + какое-то право 1

И это, Вы думаете, правильно?


Уважаемый Scott вы не имеете доступа к объекту
A так входите в группу ABC2, которой запрещен этот доступ.
Попросите начальника перевести ВАС в другую группу.

Если владельцы роли АВС2 теоритически
могут иметь доступ к объекту А,
то им нельзя выдавать роль ABC1.
11 ноя 04, 19:38    [1099905]     Ответить | Цитировать Сообщить модератору
 Re: Запретительные гранты.  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 63933
Блог
Калина
А я настаиваю, что грамотно созданные роли решают вопрос.

Решают. Равно как и роли тоже излишни - грамотно розданные напрямую права решают вопрос. Вопрос - насколько удобно это решение в некотором экстремальном случае.
11 ноя 04, 19:46    [1099920]     Ответить | Цитировать Сообщить модератору
 Re: Запретительные гранты.  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 63933
Блог
Gluk (Kazan)
Зачем так кричать ? У всех такие проблемы и все как то справляются тем что есть. Грамотно проектируйте систему, и будет Вам щастье.

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

Надеюсь, Вы понимаете, что "глобальная перетряска" - операция довольно ненадежная. И когда в ее результате окажется, что теперь какой-то категории пользователей чего-то не хватает - Вы (как администратор production) почувствуете некоторый дискомфорт и некоторое раздражение.

Безусловно, это не означает, что надо потихоньку ломать систему. Но запретительные гранты позволяют заменить глобальную перетряску аккуратным и планомерным движением, в ходе которого система в каждый момент времени остается гарантированно работоспособной (а в итоге спокойно получается та же самая система прав, что и после разовой перетряски).
11 ноя 04, 19:53    [1099926]     Ответить | Цитировать Сообщить модератору
 Re: Запретительные гранты.  [new]
stdio
Member

Откуда:
Сообщений: 4524
kto-to
Если владельцы роли АВС2 теоритически
могут иметь доступ к объекту А,
то им нельзя выдавать роль ABC1.
Вот и получили. Если у нас была сбалансированная система (как-то розданы запретительные "гранты" и роли), то если кто-то выдаст запретительный "грант" роли ABC1, то что получится? Deadlock?
Ах, вы наверное скажете, что система не должна разрешать добавлять запретительный "грант" в таком случае. Возможно. Только куда девается декларируемая вами гибкость? А? Бардак какой-то вообще-то получается.

Вообще-то я ввязался в эту дискуссию с целью показать, что если в Oracle что-то присутствует, то это не просто так взялось или свалилось с потолка. Система, с которой Вы работаете была спроектирована, продумана и функциональность её подсистем взаимосвязана. Будете пытаться лезть с какими-то революционными идеями, то, поверьте, увидите, что не всё так тривиально.
11 ноя 04, 19:53    [1099927]     Ответить | Цитировать Сообщить модератору
 Re: Запретительные гранты.  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 63933
Блог
stdio
Вообще-то я ввязался в эту дискуссию с целью показать, что если в Oracle что-то присутствует, то это не просто так взялось или свалилось с потолка.

В то же время не все, что отсутствует в Оракле, отсутствует "не просто так"
11 ноя 04, 20:04    [1099940]     Ответить | Цитировать Сообщить модератору
 Re: Запретительные гранты.  [new]
mayton
Member

Откуда: loopback
Сообщений: 49731
В Oracle нет концепции запрещающих грантов. Пользователь в базу заводится полностью бесправным и постепенно повышается вплоть до ДБА. Если требуется изощренное управление правами то обычно создаются роли даже в том случае, если роль будет дана одному юзеру.
12 ноя 04, 01:20    [1100147]     Ответить | Цитировать Сообщить модератору
 Re: Запретительные гранты.  [new]
Ryaz
Member

Откуда:
Сообщений: 1306
kto-to
Ryaz
Oracle9i Label Security[quot]
кто может показать на пальцах как можно использоват эту штуку.

[quot задача]
* есть пользователь vasya
* есть таблица kolya.table1 и процедура kolya.procedure1
* у vasya есть роли которые дают ему Grant select on kolya.table1
1) как с помощью этой штуки не дать получить ему данные через адо по запросу
 select * from kolya.table1
???
1) как с помощью этой штуки не дать выполнить ему через адо
 begin  kolya.procedure1; end;
???


Документацию не читаем из принципа? Или ждём блюдечка с голубой каёмочкой?
Если кратко и грубо по 1-му: КАЖДЫЙ select пользователя дополняется автоматически определённым предикатом. Открой документацию, там всё написано вместе с примерами.
грант селект на данную табличку, в данном случае, пользователь может иметь, только вот информацию он не получит или получит исключительно ту которая ему определена для получения.

Ещё можно реализовать обыкновенным синонимом КАЖДОМУ юзеру. Не должен запускать процедуру - дропнули синоним.
Аналогично можешь поступить для таблиц и пр.

ЗЫ. Чем меньше рычагов управления даёшь юзеру - тем крепче спишь.
Юзер с возможностью управления безопасностью - как обезъяна с гранатой. В итоге получишь, скорей свего, конструкцию типа grant all on all to all ;-)
Предопредели перечень стандартных ролей и не загоняйся.



По поводу запретительных прав. Свои 5 коп.
Лучше уж запрещено всё что не разрешено (Oracle и это, имхо, логичней) нежели разрешено то что не запрещено (M$). Роли придуманы для создания ГРУПП пользователей с одинаковыми правами. Если это условие не выполняется - то не надо заморачиваться с группами.
12 ноя 04, 08:23    [1100291]     Ответить | Цитировать Сообщить модератору
 Re: Запретительные гранты.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
softwarer
Gluk (Kazan)
Зачем так кричать ? У всех такие проблемы и все как то справляются тем что есть. Грамотно проектируйте систему, и будет Вам щастье.

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

Надеюсь, Вы понимаете, что "глобальная перетряска" - операция довольно ненадежная. И когда в ее результате окажется, что теперь какой-то категории пользователей чего-то не хватает - Вы (как администратор production) почувствуете некоторый дискомфорт и некоторое раздражение.

Безусловно, это не означает, что надо потихоньку ломать систему. Но запретительные гранты позволяют заменить глобальную перетряску аккуратным и планомерным движением, в ходе которого система в каждый момент времени остается гарантированно работоспособной (а в итоге спокойно получается та же самая система прав, что и после разовой перетряски).


Я в курсе, но как то привык обходиться тем, что есть и не кричу об этом на форуме.
12 ноя 04, 09:17    [1100373]     Ответить | Цитировать Сообщить модератору
 Re: Запретительные гранты.  [new]
LeSS
Member

Откуда:
Сообщений: 113
Тебе нужно вот это
http://www.interface.ru/oracle/ks.htm
перейди на вторую часть (в конце страницы ссылка)
12 ноя 04, 10:24    [1100607]     Ответить | Цитировать Сообщить модератору
 Re: Запретительные гранты.  [new]
kto-to
Member

Откуда: Ukraine, Kyev
Сообщений: 835
stdio
Вообще-то я ввязался в эту дискуссию с целью показать, что если в Oracle что-то присутствует, то это не просто так взялось или свалилось с потолка. Система, с которой Вы работаете была спроектирована, продумана и функциональность её подсистем взаимосвязана. Будете пытаться лезть с какими-то революционными идеями, то, поверьте, увидите, что не всё так тривиально.


" Система, с которой Вы работаете была спроектирована, продумана и функциональность её подсистем взаимосвязана."
Согласен. Но я работаю с 2-мя системами.
И я не думаю, что MSSQL писалася по принципу " абы что-то написать".
Да в нем есть вещи которые реализованы хуже чем у оракла,
но есть и многие явные удобства.
А запретительных грантов в оракле нет не потому, что это глупость/тупость,
а потому, что для реализации этого дела в оракле на уровне сситемы
потребуется куча усилий и получившееся что-то будет тормознутое...
Подумайте хотябы какие проблемы возникнут в связи с тем,
что некоторые вещи выполняются чисто с правами пользователя
(т.е. игнорируются роли в которые он входит,
а значит и запреты будут отдыхать)
12 ноя 04, 11:08    [1100839]     Ответить | Цитировать Сообщить модератору
 Re: Запретительные гранты.  [new]
kto-to
Member

Откуда: Ukraine, Kyev
Сообщений: 835
mayton
В Oracle нет концепции запрещающих грантов. Пользователь в базу заводится полностью бесправным и постепенно повышается вплоть до ДБА. Если требуется изощренное управление правами то обычно создаются роли даже в том случае, если роль будет дана одному юзеру.


В MSSQL трехфазная логика:
1) явно разрешение отсутсвует и явное запрещение отсутствует
2) явно разрешение присутствует и явное запрещение отсутствует
3) явное запрещение присутствует

В Оракле двухфазная логика:
1) явно разрешение отсутсвует
2) явно разрешение присутствует

1 - доступ запрещен
2- доступ разрешен
3 - доступ запрещен
12 ноя 04, 11:16    [1100881]     Ответить | Цитировать Сообщить модератору
 Re: Запретительные гранты.  [new]
kto-to
Member

Откуда: Ukraine, Kyev
Сообщений: 835
LeSS
Тебе нужно вот это
http://www.interface.ru/oracle/ks.htm
перейди на вторую часть (в конце страницы ссылка)


спасибо. Стало понятнее как этот пакет можно использовать.
Правда у меня сложилось впечатление что он применим
только для таблиц и вьювов.
Хотя этот механизм мне может понадобится
при реализации другой задачи.
12 ноя 04, 11:28    [1100952]     Ответить | Цитировать Сообщить модератору
 Re: Запретительные гранты.  [new]
Ales Protiv
Member

Откуда: Прага
Сообщений: 1872
Не проще ли исходить из того, что есть, и крутиться исходя из этого.
Вообще, на мой взгляд, довольно странная система получается, когда у пользователя по 30 ролей и причем права в половине из них пересекаются.

В такой системе один запретительный грант, имхо, не спасет. Поскольку ролей, извиняюсь, до одного места, с привилегиями бардак, а вас послушать, так и управлять ими будут остолопы. И по вашему, если человек не может грамотно распределять роли, то он будет втыкать в запретительные гранты?

Есть еще вариант рассматривать роли в качестве групповых операций с привилегиями. И при гранте роли выдавать привилегии напрямую пользователям. Тогда каждого пользователя можно всегда подредактироать вне зависимости от его роли. Правда тогда возникают другие вопросы... но где их не возникат?...
12 ноя 04, 11:37    [1101005]     Ответить | Цитировать Сообщить модератору
 Re: Запретительные гранты.  [new]
Ryaz
Member

Откуда:
Сообщений: 1306
У m$ 4-х фазная логика. это когда начинает путаться кому что можно, а кому нельзя то вводится 4-е измерение под кодовым названием "недопустимая операция" т.о. m$ решает абсолютно любую спорную ситуацию.
12 ноя 04, 11:44    [1101048]     Ответить | Цитировать Сообщить модератору
 Re: Запретительные гранты.  [new]
kto-to
Member

Откуда: Ukraine, Kyev
Сообщений: 835
kto-to
LeSS
Тебе нужно вот это
http://www.interface.ru/oracle/ks.htm
перейди на вторую часть (в конце страницы ссылка)


спасибо. Стало понятнее как этот пакет можно использовать.
Правда у меня сложилось впечатление что он применим
только для таблиц и вьювов.
Хотя этот механизм мне может понадобится
при реализации другой задачи.


еще раз спасибо.
Похоже оччень полезная штука.
24 ноя 04, 13:31    [1132105]     Ответить | Цитировать Сообщить модератору
 Re: Запретительные гранты.  [new]
Калина
Member

Откуда: Moskau
Сообщений: 2649
автор
В такой системе один запретительный грант, имхо, не спасет. Поскольку ролей, извиняюсь, до одного места, с привилегиями бардак, а вас послушать, так и управлять ими будут остолопы. И по вашему, если человек не может грамотно распределять роли, то он будет втыкать в запретительные гранты?

Ключевое слово - остолопы.
Чем неудобна раздача прав пользователю напрямую , на каждый объект, дал-забрал - какие проблемы?
Доступ он либо есть либо нет , зачем вариант №3
24 ноя 04, 13:51    [1132208]     Ответить | Цитировать Сообщить модератору
 Re: Запретительные гранты.  [new]
Ales Protiv
Member

Откуда: Прага
Сообщений: 1872
доступ вроде есть или его как бы нету :)
24 ноя 04, 14:46    [1132468]     Ответить | Цитировать Сообщить модератору
 Re: Запретительные гранты.  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 63933
Блог
Калина
Чем неудобна раздача прав пользователю напрямую , на каждый объект, дал-забрал - какие проблемы?

Доступ на уровне дал-забрал гарантирует необходимость время от времени выполнять массовые операции, то есть "давать" тысячу..две..десять тысяч..

Именно этим - и последствиями этого - он и неудобен.
24 ноя 04, 16:48    [1133091]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4   вперед  Ctrl      все
Все форумы / Oracle Ответить