|
pkarklinА м.б. стоит выснить свои точки зрения и на этот вопрос, не сваливаясь на флэйм?
Хм. В обсуждении вдвоем-втроем-вчетвером мы вполне возможно и смогли бы так пройти. Но по опыту предыдущих обсуждений, неизбежен сценарий типа следующего:
- приходит собеседник со стороны и выдвигает не очень взвешенное утверждение
- кто-нибудь из двоих-троих-четверых отвечает ему коротко и без реверансов
- кто-нибудь другой из двоих-троих-четверых забывает учесть контекст, в котором делалось каждое из утверждений, возмущается чем-нибудь типа "ну мы же это сейчас обсуждаем, а вы сказали, словно так и есть и другого не может быть", выдвигает встречное.. яркое утверждение итп.
- начинается флейм
- когда все устают, смотрим источники и выясняем, что флеймить-то было не о чем.
pkarklinНе спорю, что такой человек (группа) существует в любой организации, использующей то или иное решение. И этот человек (группа) наделен определенными полномочиями в бд, например, имеет право читать из всех таблиц (например, в MS SQL достаточно включить его в роль бд db_datareader ). Но это человек, умеющий это делать и понимающий свою ответственность. Но я не вижу из этого прямого следствия необходимости прямого доступа к таблицам остальных рядовых (читай неграмотных) пользователей.
То есть Вы предлагаете стрелять из пушки по воробьям. Здесь будет уместна аналогия с камерой хранения. Представьте себе самую обычную камеру хранения; каждый пользователь может подойти, открыть свою ячейку, положить-взять вещи. Это примерно та система, которую полагаю нормальной я. Вы же говорите: не надо давать пользователям прямой доступ к ячейкам. Давайте лучше заведем кладовщика, который будет осознавать свою ответственность и носить вещи в ячейки и обратно. Для этого мы дадим ему универсальную отмычку, подходящую к любой ячейке. Так вот, лично я вижу в этом следующие недостатки: во-первых, рядовым пользователям неудобно, во-вторых, кладовщик является слабым звеном, может и сам спереть вещи, и оказаться уязвимым для любого постороннего.
Давайте отойдем от аналогии и посмотрим, во что выливается этот принцип в случае ИС.
Во-первых, довольно часто тот, кто разрабатывает отчеты, не должен иметь доступ к "действительно секретной информации". Вы предлагаете наплевать на этот принцип; в результате, чтобы обеспечить это требование, придется извращаться (скажем, делать отдельную базу, выгружать туда часть данных, делать этот отчет там).
Во-вторых, после того, как ваш суперпользователь сделает отчет, снова вылезает вопрос безопасности, вылезает вот в каком аспекте. Если у пользователя есть доступ к таблицам, ограниченный RLS, выполнение отчета не требует никаких специфических прав. Я даю ему этот отчет в любом виде (скажем, как селект в экселе) и он получает эти данные, автоматически обрезанные согласно его правам. Если его права меняются - мне ничего не надо делать, отчет автоматом учтет эти изменения. Теперь, допустим, ваш суперпользователь сделал отчет в виде view или хранимки, грантовал этот объект нужным пользователям, точно так же положил на экселевский лист. Что происходит дальше? А происходит постоянный риск неправомерного доступа к данным. Почему: во-первых потому, что в каждом месте, где суперпользователь напрямую обращается к таблицам, он должен будет самостоятельно же резать их сообразно выданным правам. Во-вторых потому, что каждый раз приделывать полную проверку прав - очень большая работа; можно гарантировать, что она либо будет сделана с ошибками, либо, что на самом деле почти наверняка - будет выполнена в урезанном варианте, в духе "этот отчет нужен только для начальников отделов, поэтому права для секретарей начальников отделов проверять не будем". Ну а дальше при каждом изменении это предположение может стать неверным. К чему пришли? К тому, что суперпользователь не является адекватной заменой RLS.
pkarklin softwarerВообще меня удивляет Ваше представление об отчетах как "селекты писать". Скажем, к тому же OEBS есть EUL для Oracle Discoverer-а; у того заказчика, у которого я плотно общался с OEBS-ом, в штате был специальный сотрудник, главной и практически единственной задачей которого было писать дискаверные отчеты над OEBS-ом.
Под "аналитик SELECTы будет писать" понимался необходимый уровень квалификации того самого человека (группы), занимабщегося "добычей данных". А не то, что любой отчет м.б. составлен на основании одного селект. Мне казалось это очевидным.
Хм. Судя по последнему ответу, Вы совершенно не поняли сказанного и отвечаете невесть на что.
Oracle Discoverer - это инструмент, позиционирующийся как средство для аналитиков, позволяющее не писать селекты. Попросту говоря, визуальный конструктор отчетов. Какая "необходимая квалификация" для этого необходима?
pkarklinНаличие того или иного средства построения отчетности опять же для меня не предьявляет никаких требований к прямому доступу к таблицам .... Но это уход обсуждения от изначального русла
Хм. Если Вы посмотрите, на какой Ваш тезис отвечает упоминание дискаверера, обнаружите, что обоснованием "требований к прямому доступу" оно не позиционировалось, и не надо представлять его так. Уход в сторону сделали Вы, сказав про "аналитики будут писать селекты", я отвечаю именно на это, если теперь Вам этот уход не нравится - давайте закроем направление.
Далее, по поводу "обоснования требований прямого доступа". Простите, но я заранее уверен, что беседовать с Вами на эту тему бесполезно, просто потому, что Вы давным-давно заняли неконструктивную позицию и вряд ли с нее сдвинетесь. Аналогия здесь примерно следующая: Вы привыкли пользоваться амбарным замком, и будете вешать его даже на дверь с электронным, говоря при этом "обоснования требования открывания двери кнопкой с брелка мне так и не предоставили". Так вот, истина в том, что обоснования необходимости нет, действительно, можно продолжать пользоваться амбарным замком. Вопрос исключительно в удобстве и качестве результата, но это количественная категория, и на нее можно сколь угодно долго отвечать "а амбарный тоже запирает дверь, так что он ничем не хуже".
pkarklin softwarerview далеко не всегда позволяют получить информацию в удобоваримом для произвольного отчета виде.
М.б. это зависит от уменя строить эти самые вью?
Несколькими строками ниже Вы пообещали не рассказывать сказок.... нет, вру, сказали, что "не планировали рассказывать".
pkarklin softwarerВ случае, если нет других средств ограничения доступа, конечно, придется действовать именно так; при наличии нормальной RLS работать только через view - все равно что ремонтировать часы руками в перчатках.
Про "наличие нормальной RLS" никто и не спорит. Но я чуть Выше приводил пример другого использования вью. И Ваше высказывание "ремонтировать часы руками в перчатках" кажеться мне по крайней мере безапеляционным. Зачем мне каждый раз, имея прямой доступ к таблицам джоинить Объкт, Документ и Платежное поручение, если у меня есть готовое вью Платежное поручение?
Скажите пожалуйста, Павел, Вы по-русски читать умеете? Слово "только" в квоте видите? Как Вы думаете, оно там для красоты или все же с каким-то смыслом? Вы в очередной раз в наших спорах упираетесь в какой-то махровый максимализм, не видите разницы между "существуют случаи", "иногда", "часто" и "всегда". И при этом рассматриваете мое утверждение как "безапелляционное" :)
Объясняю еще раз, максимально доступно: я нигде не говорил, что следует отказаться от view там, где они удобны. Я утверждаю, что работа только через view не позволит оптимально решить все задачи. Приведенный Вами пример доказывает только то, что существуют некоторые задачи, для которых view удобны, чего я никогда не оспаривал. К тому, что обосновываю я - этот пример никакого отношения не имеет; он не способен ни подтвердить, ни опровергнуть мой тезис.
|
