Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: < 1 2 3 4 5 >
ANB © (2005-05-25 16:05:00)
Знаю несколько способов :
- Через гранты раздаем права. Тонкая настройка (выборка только части записей или сложные условия) - на клиенте. Хуже еще не видел, легко ломается, хотя можно усложнить взлом, например, шифруя пароль.
- Доступ только на вьюхи, изменения через хранимки - жутко неудобно каждый раз переправлять эти хранимки. И блокирутся возможность выполнять обычные DML.
- Доступ только на вьюхи, изменения через instead of триггера + хранимки для удобства - так еще не видел, соответственно прокомментировать не могу.
Все комментарии, ессно, имхо.
Кто еще с какими схемами защиты сталкивался и какую может посоветовать ?

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

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

evvcom (2005-05-26 11:02:00) [63]

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

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

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

evvcom (2005-05-26 10:50:00) [65]

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

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

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

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

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

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

evvcom (2005-05-26 10:32:00) [67]

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

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

Danilka (2005-05-26 10:29:00) [68]
[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)
> Это уже немного не по теме, согласись.

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

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

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

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

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

evvcom (2005-05-26 10:22:00) [71]

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

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

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

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

Sergey13 (2005-05-26 10:19:00) [72]
Я не говорю, что это бесполезная весчь. Но целесообразность ее применения - это вопрос для каждого случая индивидуальный.

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

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

ANB (2005-05-26 10:08:00) [74]
4. Тоже склоняюсь к 3-му варианту, тем более что в этом случае мутатинги не лезут (не уверен, вопрос к Danilka - лезут или нет ?).
Мутатинги штука вообще хитрая и могут вылезти не только в триггерах. В триггерах не очень сложный, но все равно гемморный способ обхода.

ANB (2005-05-26 10:05:00) [75]

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

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

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

Sergey13 (2005-05-26 09:41:00) [77]
Мне все таки непонятно, что обсуждаем? Безопасность или контроль доступа? Эти темы, хоть и перекликаются, но не совпадают. ИМХО.

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

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

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

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

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

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

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

evvcom (2005-05-25 17:18:00) [79]

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

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

evvcom (2005-05-25 17:14:00) [80]

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

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

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

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

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

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

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

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

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

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

Страницы: < 1 2 3 4 5 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »