Как лучше построить безопасность БД ? (Oracle)

← →
ANB © (2005-05-25 16:05) [0]

Знаю несколько способов :
- Через гранты раздаем права. Тонкая настройка (выборка только части записей или сложные условия) - на клиенте. Хуже еще не видел, легко ломается, хотя можно усложнить взлом, например, шифруя пароль.
- Доступ только на вьюхи, изменения через хранимки - жутко неудобно каждый раз переправлять эти хранимки. И блокирутся возможность выполнять обычные DML.
- Доступ только на вьюхи, изменения через instead of триггера + хранимки для удобства - так еще не видел, соответственно прокомментировать не могу.
Все комментарии, ессно, имхо.
Кто еще с какими схемами защиты сталкивался и какую может посоветовать ?

← →
Sergey13 © (2005-05-25 16:10) [1]

>Как лучше построить безопасность БД ?
Безопасность от чего?

← →
evvcom © (2005-05-25 16:21) [2]

> - Доступ только на вьюхи, изменения через хранимки - жутко
> неудобно каждый раз переправлять эти хранимки. И блокирутся
> возможность выполнять обычные DML.

Я делаю и чтение, и запись через хранимки. Неудобства не испытывал пока. Блокируется DML? Или все же DDL? А зачем DDL юзеру?

← →
ANB © (2005-05-25 16:39) [3]

> Блокируется DML?
- есно. Если стоит защита с изменениями через хранимки, а нужно будет выполнить изменение в базе не из клиента, а ручками, то нужно и юзать тогда эти процедуры. А прямые апдейты будут доступны, во первых - только программисту, во вторых - ими можно поломать базу.

← →
evvcom © (2005-05-25 16:57) [4]

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

Ах вот, что ты имел в виду! А зачем тогда давать юзеру выполнять прямые апдейты? Не надо! Пусть это и будет доступно только программисту и админу. А чтобы не поломать базу, используй констрэйнты и тригера.

← →
ANB © (2005-05-25 17:06) [5]

> evvcom © (25.05.05 16:57) [4]
- работал я с системой, которая была построена по такому принципу. Только автор очень не любил триггера (mutating-ов боялся), принципиально не делал каскадное удаление и вырубил все внешние ключи, так как решил сделать возможность ссылаться на несколько таблиц, а ссылочную целостность проверял в хранимках.
За несколько лет эксплуатации сопровождающие ПРОГРАММИСТЫ, не всегда знающие, а иногда и не имеющие возможность вызвать соответствующие ХП, такого наворотили прямыми DML в базе . . . Мусора было, хоть отбавляй.

← →
Danilka © (2005-05-25 17:09) [6]

Наша контора работает по третьему варианту. Довольно удобно.

← →
Danilka © (2005-05-25 17:10) [7]

[1] Sergey13 © (25.05.05 16:10)
Ну, например, какой-то юзер должен видеть только определенную группу клиентов в базе.

← →
evvcom © (2005-05-25 17:14) [8]

> Только автор очень не любил триггера (mutating-ов боялся),

mutating не так уж и часто встречается. Есть способы их обойти, сам еще не пробовал, но принципы нашел уже.

> принципиально не делал каскадное удаление

я тоже не делаю

> и вырубил все внешние ключи

а вот это зря, не побоюсь сказать это без имхо

> так как решил сделать возможность ссылаться на несколько
> таблиц

у тебя Oracle какой? Если 9 и выше, то можешь для этого использовать объектные решения.

> такого наворотили прямыми DML в базе

вот для этого и придумали ссылочную целостность и тригера. Не советую повторять эти ошибки.

← →
evvcom © (2005-05-25 17:18) [9]

> Наша контора работает по третьему варианту. Довольно удобно.

Не пробовал, но думаю, это ничем не отличается от 2 варианта.

← →
Danilka © (2005-05-25 18:42) [10]

[9] evvcom © (25.05.05 17:18)
Ну, самое весомое отличие это то, что можно делать апдейт вьюхи по каким-то условиям, когда сразу апдейтятся несколько записей. С ХП это повторить уже сложнее. И вообще, получается для клиента такая вьюха неотличима от таблицы, и всю работу с ней можно строить как с таблицей.

Привык к такому варианту работы, а как столкнулся с проблемами в использовании instead of триггеров в МС-Скуле, так сидел здесь на форуме и горько плакал, пока уважаемый Fay не подсказал один из вариантов решения проблемы. :)

← →
Sergey13 © (2005-05-26 09:41) [11]

Мне все таки непонятно, что обсуждаем? Безопасность или контроль доступа? Эти темы, хоть и перекликаются, но не совпадают. ИМХО.

2[7] Danilka © (25.05.05 17:10)
>Ну, например, какой-то юзер должен видеть только определенную группу клиентов в базе.
Это несложно решается и без вьюшно/процедурных наворотов.

Я тоже был одно время озабочен подобными вопросами. Потом подумав (я не работал со сведениями, составляющими какую либо тайну 8-), проанализировав реалии (ни один юзер на моей памяти не проникал в БД через Плюс или нечто подобное - 99.9% на это физически не способны 8-) я на это плюнул. 8-)

Что плохого, что юзер увидит "не своих" клиентов например? Если не увидит, то попытается его ввести - геморой. Что значит "своих"? А если юзер Иванов перешел работать в другое подразделение или ушел совсем? Передавать их всех Петрову? Удалять?

Читая про детальный контроль доступа и политики безопасности (когда к запросам автоматически дописываются условия) я обратил внимание, что примеры, там рассмотреные, обычно не сложнее select * from Table. У меня таких запросов практически нет. 8-) А если в действительно сложный запрос что то автоматически (во время выполнения) добавится, кто поручится, что производительность этого запроса не полетит вверх тормашками?

В общем, мне кажется, что прежде чем заниматься "безопасностью", надо шибко подумать - а оно надо?

← →
Danilka © (2005-05-26 10:00) [12]

[11] Sergey13 © (26.05.05 09:41)
Да не такие уж это и навороты. Просто, как ты сам сказал, простейших запросов select * from Table практически не бывает. В основном - сложные выборки из нескольких таблиц, а то и вьюх. Зачем все это писать на клиента, когда можно оформить вьюхой? А клиентов я привел просто как пример, хотя и такое тоже есть - есть задача, где у каждого менеджера есть четко закрепленные свои клиенты, их может быть штук десять - рыться в сотнях или тысячах контрагентах, где есть и поставщики и т.д., зачем? добавил группу: "клиенты такие-то", а у этого пользователя при подключении прописана эта группа как основная и вьюха клиентов, скоторой он работает чаще всего, фильтрует их по этой группы. У каждого менеджера - совя группа. Так им намного легче. :))

← →
ANB © (2005-05-26 10:05) [13]

> Sergey13 © (26.05.05 09:41) [11]

1. Обсуждаем контроль доступа. И безопасность тоже.
2. Я тоже не во все проекты ее вставляю
3. Но для коммерческих проектов класса ERP ее делать надо. Первый вариант уже видел. Начали подпрыгивать, когда продавцы залезли в базу девелопером и давай развлекаться. Ушло около миллиона баксов, а концов нашли далеко не на всю сумму. В результате юзеры сидели на компах с закрытым профилем, то есть могли запустить только ERP, не имели доступа к локальным дискам. Это и неудобно и все равно, при желании ломается. Доступ был заложен на грантах, то есть под этим же паролем юзер мог подключится к оракле напрямую. Я предложил идею с шифрованием пароля, но внедрить не успели - разогнали департамент.

← →
ANB © (2005-05-26 10:08) [14]

4. Тоже склоняюсь к 3-му варианту, тем более что в этом случае мутатинги не лезут (не уверен, вопрос к Danilka - лезут или нет ?).
Мутатинги штука вообще хитрая и могут вылезти не только в триггерах. В триггерах не очень сложный, но все равно гемморный способ обхода.

← →
Danilka © (2005-05-26 10:16) [15]

[14] ANB © (26.05.05 10:08)
А что такое "мутатинги"? :)
Да и нет никакого гемороя - зачастую триггер запускает процедуру из пакета, т.к. вьюх одного и того-же, например, документа может быть много, а процедура добавления/изменения одинаковая.
Кроме того, триггер выполняет какие-то необходимые действия, которые так или иначе все равно надо выполнить, так что геморой в любом случае одинаковый. :)

← →
Sergey13 © (2005-05-26 10:19) [16]

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

2[13] ANB © (26.05.05 10:05)
>Начали подпрыгивать, когда продавцы залезли в базу девелопером и давай развлекаться
Можно например повесить тригер на LogOn и анализировать имя проги.

← →
evvcom © (2005-05-26 10:22) [17]

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

Пример можно?

> И вообще, получается для клиента такая вьюха неотличима
> от таблицы

Точнее, наверное, не для клиента, а для разработчика. Хотя в данном случае это можно приравнять. Не буду спорить, есть кое-какие преимущества, но и есть недостатки. Ну куда же без них :). Во вьюху кроме единственного селекта больше ничего не запихаешь, а это тоже далеко не всегда удобно.

← →
Danilka © (2005-05-26 10:23) [18]

[16] Sergey13 © (26.05.05 10:19)
> Но целесообразность ее применения - это вопрос для каждого
> случая индивидуальный.

Для меня - практически решен. :)
И в тех местах, где халтуркой занимаюсь. Стараюсь во вьюхи все заворачивать, т.к. зачастую, когда у клиента какая-то проблема, ее можно решить сразу на месте не имея дельфей и без перекомпиливания исходников, внося изменения только на сервере. Да даже и не на месте - куда проще дома подготовить скрипт, который прокатал у клиента, чем нести новый экзешник и ставить на все рабочие места.

← →
Sergey13 © (2005-05-26 10:27) [19]

2[18] Danilka © (26.05.05 10:23)
> Для меня - практически решен. :)
Я не против. Решил и хорошо. 8-)

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

← →
Danilka © (2005-05-26 10:29) [20]

[17] evvcom © (26.05.05 10:22)
> Пример можно?

UPDATE v_my_data SET xxx = 1 WHERE yyy = 2
?
При этом, записей во вьюхе с yyy = 2 несколько десятков, например. А в случае, когда апдейт возможен только через ХП придется для каждой записи выполнять ХП.

> Во вьюху кроме единственного селекта больше ничего не запихаешь,
> а это тоже далеко не всегда удобно.

не понял, что значит единственный селект? :) есть вьюхи с селектами из десятка таблиц, и тело вьюхе весом с десяток килобайт. :)

[19] Sergey13 © (26.05.05 10:27)
> Это уже немного не по теме, согласись.

Не по теме безопастности, но к теме вьюх - вполне подходит. :)

← →
evvcom © (2005-05-26 10:32) [21]

> Можно например повесить тригер на LogOn и анализировать
> имя проги.

А что, экзешник переименовать стало большой проблемой?

← →
Sergey13 © (2005-05-26 10:45) [22]

2 [21] evvcom © (26.05.05 10:32)
> А что, экзешник переименовать стало большой проблемой?
Нет. Это не проблема. Но до этого надо еще додуматься. Это раз. В тригере можно уведомить администратора. Это два. У тебя юзеры умеют дивелопером пользоваться (он у них вообще есть?!!!)? Умеют тригеры отключать? В БД нельзя вести логирование важной инфы в недоступных для прочих таблицах. Может к твоей базе проявляют интерес разведки врагов? Или наши компетентные органы? Это три, четыре и т.д.

Еще раз говорю. Я не против безопасности. Я за двумя руками!!! Но у нее много аспектов и методов повышения. Все три перечисленных в топике метода равноправны (ИМХО) и сильно зависят от качества реализации (что показано в [5]). Если такая проблема стоИт, то надо ей заниматься. Тратить на это время и деньги. Просто часто я вижу примеры легких параной с манией преследования, когда чуть ли не школьное расписание пытаются шифровать.

← →
evvcom © (2005-05-26 10:50) [23]

> А в случае, когда апдейт возможен только через ХП придется
> для каждой записи выполнять ХП.

Это почему? Что мешает в ХП такой же апдейт написать?

> есть вьюхи с селектами из десятка таблиц

Это понятно, что селекты во вьюхах тоже могут join-ы содержать. Только вот если тебе перед селектом надо бы десяток процедур выполнить, да хотя бы одну, то с вьюхой это уже не прокатит. И параметры. Вьюхой выдаешь жесткий набор строк или изгаляться через передачу параметров через запись в настроечные таблицы. А с ХП этих проблем нет.

← →
Val © (2005-05-26 10:51) [24]

>[15] Danilka © (26.05.05 10:16)
А что такое "мутатинги"? :)
мутатинги, насколько я помню из анекдота, возникают из-за немытого мутатора. :)

← →
evvcom © (2005-05-26 11:02) [25]

> Val © (26.05.05 10:51) [24]

Тебе надо в "потрепаться", т.к. "мутатинги" действительно в оракле существуют независимо от вымытости твоего мутатора.

← →
Sergey13 © (2005-05-26 11:06) [26]

2[25] evvcom © (26.05.05 11:02)
Нет. Когда не выполняют условия и ограничения (т.е. лезут с немытым мутатором 8-) и появляются мутатинги.

← →
Val © (2005-05-26 11:17) [27]

>[25] evvcom © (26.05.05 11:02)
да вы что? в оракле существуют мутатинги? а мне в потрепаться?
:) не смешите меня, уважаемый. _Мутации_ могут быть в любой серверной субд, при определенных действиях (например выборка в триггере из этой же изменяемой таблицы).
А мутатинги существуют в воображении вашем и не более. Или приведете литературный пример?

← →
ANB © (2005-05-26 11:33) [28]

> Val © (26.05.05 11:17) [27]
- Оракл есть ? Напиши триггер before rows for update, поселекай в нем свою табличку, а потом попробуй проапдейтить ее. Вылезет длинная ошибка. Ессно, это ошибка состоит не в мутации таблицы, а в кривых ручках прога и политике Оракл (т.к. в мсскуле такой ошибки не бывает), но ораклисты понимают проблему с полуслова и назыают ее "мутатинги". Исторически сложилось. Все имхо.

> Но до этого надо еще додуматься.
- бывают очень прошаренные юзеры. Плюс, они и с прогами погут поделится. Безопасность же на админе висит. Ну поставили триггер на кассу. Так еще нашли кучу способов денежку уводить.

2[28] ANB © (26.05.05 11:33)
> Напиши триггер before rows for update, поселекай в нем свою табличку
Т.е. сделать как нельзя? И удивляться результату? 8-)

Есть у меня еще мысля, по поводу трехслойки. Тогда юзер коннектится только к серверу приложения, а к оракле никакого доступа не имеет. Но ни разу не писал.

>[28] ANB © (26.05.05 11:33)
елки-палки..нет слов. вы, простите, сами понимаете, что пишите? или просто "мутатингов" боитесь?

2[29] ANB © (26.05.05 11:35)
>- бывают очень прошаренные юзеры. Плюс, они и с прогами погут поделится. Безопасность же на админе висит. Ну поставили триггер на кассу. Так еще нашли кучу способов денежку уводить.

Тогда вам надо в милицию обращаться. А если они (внутренние враги) еще и админа подкупят? А если и глава конторы в доле? Какую программу ты напишешь? Тут вызод один - топорм по серверу (или по сетевому кабелю как минимум) пока все не разворовали. 8-)

Есть же триггеры уровня схемы, запрещай юзверям применять DDL. Снять такие триггера сможет только собственник схемы.

> Есть же триггеры уровня схемы, запрещай юзверям применять DDL

Зачем триггеры? Есть GRANT/REVOKE

> Val ©

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

> Т.е. сделать как нельзя? И удивляться результату? 8-)
- не, человек просил объяснить, что такое мутатинги. Я написал, как это посмотреть, вдруг не знает ?

>[36] evvcom © (26.05.05 11:57)
заметьте, смайл означает то что он означает. "прицепился" же я к вашей попытке послать меня в "потрепаться" после абсолютно безобидной шутки.

Кстати, термин "мутации", как и "мутатинги" весьма условный. Просто на это слово начинается мессага об ошибке. Ну, думаю, ораклистам причину объяснять не надо.

> Тогда вам надо в милицию обращаться
- в милицию можно обращаться, если прихватили на месте. Думаю, более приличным вариантом будет не допускать подобных вещей. Схемы увода денежки бывают довольно заковыристые. Одну мы откопали (это уже была штатная дырка в программе) только через год, когда половина участников уже уволилась. Да и что ты ментам предьявишь - записи в логе ? Денежка вполне законно ушла, сам факт обнаружить довольно трудно. Особенно если у тебя больше 2000 пользователей.

> Val © (26.05.05 12:02) [38]
- ну все остынь. Давай я перед тобой извинюсь. Ты по сабжу что нибудь имеешь ? А то уже Жук пришел, ща мы опять в холиварчик плавно переползем.

to Danilka - ты так и не ответил на вопрос - если я нагло буду нарушать правила (селекать из изменяемых таблиц например) в триггере instead of, мутатинг вылезет или нет ?

Как лучше построить безопасность БД ? (Oracle) Найти похожие ветки