|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
Хм. Боюсь, не понял, при чем тут загрузка данных. Возможно, из-за незнания особенностей того бизнес-процесса, который Вы имеете в виду. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.02.2007, 19:14 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
softwarerХм. Боюсь, не понял, при чем тут загрузка данных. Возможно, из-за незнания особенностей того бизнес-процесса, который Вы имеете в виду. Да простейший пример. Пользователь отрывает карточку конкретного клиента. В зависимости от его прав: - видны те или иные поля - доступно редактирование тех или иных полей - доступны те или иные действия (удаление, приостановка и пр.) Конечно возможен вариант, когда пользователь выбирает действие "Удалить", вызывается соответствующая процедура, которая возвращает ошибку. Однако гораздо более удобным кажется случай, если пользователь сразу не может нажать соответствующую кнопку или выбрать соответствующий пункт меню. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.02.2007, 19:35 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
MGRДа простейший пример. .... Хм. Насколько я понимаю, этот простейший пример уже никак не связан с загрузкой данных. MGRКонечно возможен вариант, когда пользователь выбирает действие "Удалить", вызывается соответствующая процедура, которая возвращает ошибку. ..... Не вижу смысла комментировать то, на что уже было отвечено: из ранее сказанного softwarerКак только "вся безопасность в СУБД", на клиенте она становится тривиальной "не показывать того, что все равно нет". Это уже не безопасность, а эстетика. pkarklinтолько как дополнение ("визуализация" на клиенте) к разграничению прав в самой бд. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.02.2007, 20:41 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
softwarer Безопасность должна быть в базе. Если поле невидимо - оно должно быть невидимо при коннекте этого пользователя к базе. И так далее. Точка. скажите, каким образом можно разделить в этмо случае права не на уровне полей, а на уровне записей. Ну если одному пользователю разрешено менять в таблице А записи , где поле DIV_ID =100, но никакие другие? мне приходит в голову, только триггеры с проверкой .. но кажется это не лучший вариант ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 04:37 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
Mainframeскажите, каким образом можно разделить в этмо случае права не на уровне полей, а на уровне записей. Ну если одному пользователю разрешено менять в таблице А записи , где поле DIV_ID =100, но никакие другие? мне приходит в голову, только триггеры с проверкой .. но кажется это не лучший вариант Некоторые СУБД (например, Oracle) имеют встроенную поддержку row-level security, в других (например, MS SQL) придеться самому строить ту или иную реализацию ACL (access control list). ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 08:17 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
Mainframe скажите, каким образом можно разделить в этмо случае права не на уровне полей, а на уровне записей. Ну если одному пользователю разрешено менять в таблице А записи , где поле DIV_ID =100, но никакие другие? мне приходит в голову, только триггеры с проверкой .. но кажется это не лучший вариант У ва же не возникает проблем с реализацией такой проверки на уровне приложения? А что мешает ровно тот же код написать и в хранимой процедуре, которая модификацию делает? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 09:25 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
Bogdanov Andrey У ва же не возникает проблем с реализацией такой проверки на уровне приложения? А что мешает ровно тот же код написать и в хранимой процедуре, которая модификацию делает? Да нет .. мы вообще-то пишем трехуровневые приложения .. у нас управления правами по другому принципу ..просто стало интересно. И потмо причем тут ХП ? если приложение 2-х уровневое, то пользователь имеет доступ напрямую к таблице. Он не будет обращаться к ХП (если он злостный товарищ). Его могут остановить триггеры к примеру, ну или что-то другое .. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 09:36 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
MainframeИ потмо причем тут ХП ? если приложение 2-х уровневое, то пользователь имеет доступ напрямую к таблице. Ошибаетесь. В тех БД, в которых нет адекватной поддержки row-level security, пользователь как правило не имеет доступа напрямую к таблице. Вместо этого ему дается доступ к view или ХП, реализующим проверку прав. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 09:43 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
MainframeИ потмо причем тут ХП ? если приложение 2-х уровневое, то пользователь имеет доступ напрямую к таблице. Он не будет обращаться к ХП (если он злостный товарищ). Его могут остановить триггеры к примеру, ну или что-то другое .. Гм... Не должен пользователь иметь никакого доступа к таблицам. Он вообще не должен знать как устроена модель данных. Все взаимодействие идет через хп, вью, функции. Даже если в системе и не требуется поддержка row-level security. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 10:10 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
pkarklinГм... Не должен пользователь иметь никакого доступа к таблицам. Это уже песня из серии "наши недостатки - самые идеологически правильные недостатки в мире". pkarklinОн вообще не должен знать как устроена модель данных. Все взаимодействие идет через хп, вью, функции. Даже если в системе и не требуется поддержка row-level security. Угу. После чего начинаются вопросы "а вот начальство просит меня состряпать пару отчетов над данными купленной системы...." ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 10:12 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
softwarerЭто уже песня из серии "наши недостатки - самые идеологически правильные недостатки в мире". Ну, если скрытие модели данных для Вас является недостатком - Ваше право так считать. Я противник предоставления доступа непосредственно к таблицам бд. Вне контекста "идеологически правильных недостатков" конкретной СУБД. softwarerУгу. После чего начинаются вопросы "а вот начальство просит меня состряпать пару отчетов над данными купленной системы...." Это как? Начальство, например, финансовый директор, "просит состряпать", например, финансового аналитика отчет "по данным системы"? Это значит финансовый аналитик SELECTы будет писать? Вы меня немного удивляете. Я не сталкивался, за редким исключением, на своем веку с такими пользователями. Готовую выборку в экселе "покрутить" еще куда не шло. Но чтоб стряпать самому отчеты "по данным" купленной (да хоть разработанной) системы... Ну, не знаю, что у Вас за пользователи. Да и потом, я лишь констатировал факт, что закрыт доступ к таблицам (что скрывает модель данных), но существующие view позволяют таким продвинутым пользователям получать информацию, представленную из модели в "удобоваримом виде" в соответствии с имеющимися полномочиями. Например, сущность "Платежное поручение" "состоит" из 3х таблиц (эдакий вариант наследования): Объект->Документ->Платежное поручение. Пользователю доступно представление "Платежное поручение", которое джоинит эти три таблицы и дает полный комплект аттрибутов сущности. Это то, что касается выборки. А есть набор хп для добавления, изменения, удаления. Мне не совсем понятны Ваши высказывани. Точнее вложенный в них смысл. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 10:28 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
softwarerНачальство, например, финансовый директор, "просит состряпать", например, финансового аналитика отчет "по данным системы"? Это значит финансовый аналитик SELECTы будет писать? Вы меня немного удивляете. Я не сталкивался, за редким исключением, на своем веку с такими пользователями. Готовую выборку в экселе "покрутить" еще куда не шло. Но чтоб стряпать самому отчеты "по данным" купленной (да хоть разработанной) системы... Ну, не знаю, что у Вас за пользователи.На сей раз Вы меня удивляете. :) Очень частая практика, что у клиента есть квалифицированный сотрудник, который осуществляет поддержку и ЗАПРОСТО может делать внешние отчеты над покупной системой. Чаще всего это обычный ИТ-шник эникейщик или аналитик. :) Более того ! Над покупной системой рано или поздно всегда нарастает ком из внешних отчетов, процедур, приблуд и т.д. Часто для этого используют ACCESS, т.к. в нем удобный и конструктор и репортер. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 10:44 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
....А вот это уже вызывает подозрение, что Вам хочется не столько истины, сколько победы в споре.Нет. Просто я утверждаю, что в данном вопросе не может быть одной абсолютной истины и этому есть множество доказательств, пусть даже порой спорных. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 10:54 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
а почему все говорят про вью, если вопрос идет о разделение прав на изменения по записям. как поняла, если способ в Оракле. Если пользователь имеет логин и пароль и ему разрешено писать в таблицу, то он ведь может записать в те записи этой таблицы, которые ему не разрешены, если не используется как вариант триггеры для записи, кодирование пароля пользователя системы (что бы он не знал анстоящего пароля) или какие-то дополлнительные средства . вот в MS мне неизвестный средства. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 10:55 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
Mainframeа почему все говорят про вью, если вопрос идет о разделение прав на изменения по записям. Потому что вью как раз можно использовать для реализации row-level security. Джоинясь во вью с таблицей (таблицами) ACL, где для пользователя (группы) пользователя прописаны горизонтальные фильтры. MainframeЕсли пользователь имеет логин и пароль и ему разрешено писать в таблицу, то он ведь может записать в те записи этой таблицы, которые ему не разрешены, Кто ж ему даст разрешение "писать в таблицу"?! Запись идет через хп, где опять же проверяются таблицы ACL. Да и без хп можно обойтись, используя опцию WITH CHECK OPTION при создании вью. Тогда модификацию через вью можно произвести только тех данных, которые подпадают под инструкцию SELECT вью. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 11:08 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
LSVОчень частая практика, что у клиента есть квалифицированный сотрудник, который осуществляет поддержку и ЗАПРОСТО может делать внешние отчеты над покупной системой. Чаще всего это обычный ИТ-шник эникейщик или аналитик. :) Все-таки не надо путать разработчика отчетов с пользователем программы. Этот квалифицированый сотрудник уже не является пользователем и было бы странно, если бы в своей работе он ограничивался интерфейсами, которые предназначены пользователям. У него наверняка будет возможность воспользоваться DBA-доступом или чем-то аналогичным и создать необходимые для его отчетов вью. И уж наличие у службы поддержки DBA-доступа никак не оправдывает наличие дыр в безопасности. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 11:23 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
pkarklinНу, если скрытие модели данных для Вас является недостатком - Ваше право так считать. Я противник предоставления доступа непосредственно к таблицам бд. Вне контекста "идеологически правильных недостатков" конкретной СУБД. Хм. К сожалению, попытка обсудить этот момент обречена вылиться во флейм, тупой и беспощадный. pkarklinЭто как? Начальство, например, финансовый директор, "просит состряпать", например, финансового аналитика отчет "по данным системы"? Это значит финансовый аналитик SELECTы будет писать? Вы меня немного удивляете. Я не сталкивался, за редким исключением, на своем веку с такими пользователями. Готовую выборку в экселе "покрутить" еще куда не шло. Но чтоб стряпать самому отчеты "по данным" купленной (да хоть разработанной) системы... Ну, не знаю, что у Вас за пользователи. Скажу так: за всю свою трудовую практику я не сталкивался с более-менее большой системой, к которой заказчик не приписывал бы дополнительных отчетов. При этом платить вендору за каждый новый отчет и пару месяцев ждать результата заказчика чаще всего не устраивает, поэтому в большинстве случаев отчеты приделываются собственными силами - либо штатными айтишниками, либо грамотными людьми из числа пользователей. Вообще меня удивляет Ваше представление об отчетах как "селекты писать". Скажем, к тому же OEBS есть EUL для Oracle Discoverer-а; у того заказчика, у которого я плотно общался с OEBS-ом, в штате был специальный сотрудник, главной и практически единственной задачей которого было писать дискаверные отчеты над OEBS-ом. pkarklinДа и потом, я лишь констатировал факт, что закрыт доступ к таблицам (что скрывает модель данных), но существующие view позволяют таким продвинутым пользователям получать информацию, представленную из модели в "удобоваримом виде" в соответствии с имеющимися полномочиями. view далеко не всегда позволяют получить информацию в удобоваримом для произвольного отчета виде. В случае, если нет других средств ограничения доступа, конечно, придется действовать именно так; при наличии нормальной RLS работать только через view - все равно что ремонтировать часы руками в перчатках. Сказку про то, что некий гуру способен написать такие view, что они сгодятся для абсолютно любых отчетов, да еще и не будут тормозить, я выслушивать не очень настроен. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 11:25 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
MainframeЕсли пользователь имеет логин и пароль и ему разрешено писать в таблицу, то он ведь может записать в те записи этой таблицы, которые ему не разрешены Как Вам сказать.... это высказывание по уровню продуманности и истинности аналогично примерно следующему: "ну раз пользователь имеет логин и пароль для подключения к базе, он может писать в любые таблицы в этой базе". Mainframeкодирование пароля пользователя системы (что бы он не знал анстоящего пароля) Да забудьте этот бред конца позапрошлого века. Технологии защиты, базирующиеся на "пользователь чего-то не знает" заведомо левы и дырявы, такие системы следует выбрасывать не глядя. Ну кто, черт возьми, помешает мне поставить снифер, или расковырять exe-шник, и поймать Ваш "супернадежноспрятанныйнастоящийпароль"? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 11:36 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
softwarerТехнологии защиты, базирующиеся на "пользователь чего-то не знает" заведомо левы и дырявы, такие системы следует выбрасывать не глядя. Ну все-таки все системы защиты базируются на том, что пользователь не знает паролей сисадмина, дба и иже с ними :) Но прятать от пользователя его собственный пароль, или "запретить" SQL*Plus - занятие бессмысленное. Вот только как бы это офицерам безопасности объяснить, так чтобы они поняли? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 11:45 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
softwarerХм. К сожалению, попытка обсудить этот момент обречена вылиться во флейм, тупой и беспощадный. А м.б. стоит выснить свои точки зрения и на этот вопрос, не сваливаясь на флэйм? softwarerСкажу так: за всю свою трудовую практику я не сталкивался с более-менее большой системой, к которой заказчик не приписывал бы дополнительных отчетов. При этом платить вендору за каждый новый отчет и пару месяцев ждать результата заказчика чаще всего не устраивает, поэтому в большинстве случаев отчеты приделываются собственными силами - либо штатными айтишниками, либо грамотными людьми из числа пользователей. Не спорю, что такой человек (группа) существует в любой организации, использующей то или иное решение. И этот человек (группа) наделен определенными полномочиями в бд, например, имеет право читать из всех таблиц (например, в MS SQL достаточно включить его в роль бд db_datareader ). Но это человек, умеющий это делать и понимающий свою ответственность. Но я не вижу из этого прямого следствия необходимости прямого доступа к таблицам остальных рядовых (читай неграмотных) пользователей. softwarerВообще меня удивляет Ваше представление об отчетах как "селекты писать". Скажем, к тому же OEBS есть EUL для Oracle Discoverer-а; у того заказчика, у которого я плотно общался с OEBS-ом, в штате был специальный сотрудник, главной и практически единственной задачей которого было писать дискаверные отчеты над OEBS-ом. Под "аналитик SELECTы будет писать" понимался необходимый уровень квалификации того самого человека (группы), занимабщегося "добычей данных". А не то, что любой отчет м.б. составлен на основании одного селект. Мне казалось это очевидным. Наличие того или иного средства построения отчетности опять же для меня не предьявляет никаких требований к прямому доступу к таблицам (если этого только (в силу ограничений) не требуют сами средства построения отчетности). Даже получив с сервера резалтсет от обычного SELECTа и использовав Excel можно получить очень "сложный" отчет. Но это уход обсуждения от изначального русла. Хотите обсудить возможности и требования средств порстроения отчетности - с удовольствием поучаствую. softwarerview далеко не всегда позволяют получить информацию в удобоваримом для произвольного отчета виде. М.б. это зависит от уменя строить эти самые вью? Помниться мне во времена работы с OEBS для построения оборотно-сальдовой ведомости мне хватило запроса, а программисты наворотили кучу кода на PL\SQL c курсорами и т.п. softwarerВ случае, если нет других средств ограничения доступа, конечно, придется действовать именно так; при наличии нормальной RLS работать только через view - все равно что ремонтировать часы руками в перчатках. Про "наличие нормальной RLS" никто и не спорит. Но я чуть Выше приводил пример другого использования вью. И Ваше высказывание "ремонтировать часы руками в перчатках" кажеться мне по крайней мере безапеляционным. Зачем мне каждый раз, имея прямой доступ к таблицам джоинить Объкт, Документ и Платежное поручение, если у меня есть готовое вью Платежное поручение? И, кроме получения самих "полных" сущностей вью могут использоваться для получения часто используемых объединений. Мне казалось это очевидным. softwarerСказку про то, что некий гуру способен написать такие view, что они сгодятся для абсолютно любых отчетов, да еще и не будут тормозить, я выслушивать не очень настроен. А я и не планировал Вам ее расказывать. Запрограммировать все сразу на все случаи жизни не получиться, но это опять не кажеться мне аргументом для предоставления прямого доступа пользователей к таблицам. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 11:52 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
Bogdanov AndreyНу все-таки все системы защиты базируются на том, что пользователь не знает паролей сисадмина, дба и иже с ними :) По-хорошему - не только на этом, а еще и на том, что пользователь не может проникнуть за консоль, с которой эти пароли будут действовать :) Да, я вполне осознанно сформулировал утверждение "коротко и не совсем точно", но думаю, при минимальном желании понятно, что к чему. Базовый принцип - злоумышленник, даже обладая полной информацией о структуре и реализации защиты, не должен иметь возможность ее легко пройти. В частности, если в exe-шнике зашит пароль к application role, или "шифровалка пароля пользователя", пройти такую защиту - вопрос сугубо технический. Конечно, его можно осложнить, выламывая из компьютера дисководы, usb-порты и так далее, но тем не менее, систему, полагающуюся только на это..... Я люблю вспоминать цитату из Хайнлайна: - Знаешь, как мы называем дамочек, полагающихся на календарный метод? Мы [медсестры] называем их "матерями" Bogdanov AndreyНо прятать от пользователя его собственный пароль, или "запретить" SQL*Plus - занятие бессмысленное. Вот только как бы это офицерам безопасности объяснить, так чтобы они поняли? C точки зрения максимальной безопасности оно не то чтобы полностью бессмысленно, свою лепту оно вносит, особенно в пункте "а что если в вашем хваленом оракле есть дыра в безопасности". ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 12:07 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
C точки зрения максимальной безопасности компьютеры вообще бессмысленны, т.к. почти везде есть критичные дыры, информацию о которых можно найти в инете за 5минут. ЭТО КАКОЙ-ТО ТУПИК ! ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 12:33 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
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 удобны, чего я никогда не оспаривал. К тому, что обосновываю я - этот пример никакого отношения не имеет; он не способен ни подтвердить, ни опровергнуть мой тезис. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 13:04 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
При обсуждении методов безопасности при работе с АИС оперируйте согласованными понятиями 1. От кого защищаетесь 1.1 Уровень знаний 1.2 Уровень полномочий внутри АИС 1.3 Уровень обеспечения и полномочий внутри организации 2. От чего защищаетесь 2.1 Уровень оснащенности 2.2 Уровень доступа по временни 2.3 Уровень доступа по территориальности ps: ответьте на вопросы возможность пожара относиться к безопасности? возможность маскишоу относиться к безопасности? возможность засланного-админа относиться к безопасности? LSVт.к. почти везде есть критичные дыры, информацию о которых можно найти в инете за 5минут. бред ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 13:22 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
softwarer Во-вторых, после того, как ваш суперпользователь сделает отчет, снова вылезает вопрос безопасности, вылезает вот в каком аспекте. Если у пользователя есть доступ к таблицам, ограниченный RLS, выполнение отчета не требует никаких специфических прав. Я даю ему этот отчет в любом виде (скажем, как селект в экселе) и он получает эти данные, автоматически обрезанные согласно его правам. Если его права меняются - мне ничего не надо делать, отчет автоматом учтет эти изменения. Теперь, допустим, ваш суперпользователь сделал отчет в виде view или хранимки, грантовал этот объект нужным пользователям, точно так же положил на экселевский лист. Что происходит дальше? А происходит постоянный риск неправомерного доступа к данным. Почему: во-первых потому, что в каждом месте, где суперпользователь напрямую обращается к таблицам, он должен будет самостоятельно же резать их сообразно выданным правам. Во-вторых потому, что каждый раз приделывать полную проверку прав - очень большая работа; можно гарантировать, что она либо будет сделана с ошибками, либо, что на самом деле почти наверняка - будет выполнена в урезанном варианте, в духе "этот отчет нужен только для начальников отделов, поэтому права для секретарей начальников отделов проверять не будем". Ну а дальше при каждом изменении это предположение может стать неверным. К чему пришли? К тому, что суперпользователь не является адекватной заменой RLS. Ну на эту же ситуацию можно взглянуть и по другому. Например, ни одному бухгалтеру в банке не нужно (и не можно) знать информацию об остатках по всем счетам. Отлично, мы настроим RLS требуемым образом. Потом, захочется получить баланс банка (который делается одним довольно простым select), и что каждый бухгалтер будет свой собственный баланс получать? По счетам, которые ему доступны. Должен отметить, что именно такие ситуации постоянно встречаются - для аналитической отчетности почти всегда требуется аггрегаты по более широкому спектру данных, чем доступные для непосредственной работы. А вот для оперативной отчетности (когда надо "напечатать" один живущий в СУБД "объект") почти всегда достаточно тех самых стандартных вью, о которых говорит pkarklin. В любом случае, человек, который разработывает отчеты (не знаю, почему его обозвали суперпользователем, если это обычный разработчик) должен задуматься о том, каким образом должна сказываться система безопасности на данных, которые его отчет представляет. И никакая RLS здесь не поможет. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 13:36 |
|
|
start [/forum/topic.php?fid=33&msg=34343617&tid=1549145]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
131ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
others: | 17ms |
total: | 249ms |
0 / 0 |