|
|
su.dbms.sql- SU.DBMS.SQL ------------------------------------------------------------------ From : Vadim Rumyantsev 2:5030/301 06 Mar 2001 12:36:26 To : Ruslan Bikmetov Subject : безопасность превыше всего? -------------------------------------------------------------------------------- Во втоpник, 06 маpта 2001 09:03:05, Ruslan Bikmetov писал to All: >> Расшифруй, пожалуйста. Если ты о том, что облечённый соответствующими >> правами пользователь может всё испортить -- так это как бы >> подразумевается его уровнем ответственности, необходимым для получения >> этих прав. RB> Да, я именно об этом. Я хочу выяснить возможность создания механизма RB> (кстати под UDB 5.2) при котором пользователю будет затруднительно RB> либо невозможно деструктивно изменить большой объем данных, по RB> неосторожности либо злому умыслу, либо это изменение будет занимать RB> продолжительное время. Причем пользователь имеет привелегии на RB> изменение, в соответствии с логикой работы системы. Предположим RB> ситуацию, когда работник узнает о своем увольнении, либо о каких-то RB> иных неприятностях решает в отместку удалить данные из какой либо RB> таблицы. Это, мне кажется, внутренне противоречивая постановка вопроса. Если юзер имеет возможность много раз менять по одной записи, это в принципе то же самое, что изменение за один раз многих записей. Тут можно посоветовать разве что заранее перед известием об увольнении лишать прав :) и делать online backup, с тем чтобы в случае чего иметь возможность вернуться к любому моменту времени. Hу, или описанный тобой компромиссный вариант с триггерами, но я не думаю, что он что-то реально решает. Можно, кстати, просто замедлить триггером каждую операцию изменения строки. RB> Клиентская часть написана в основном на С++ билдере. Переписать ее на RB> static SQL и переучить программистов не представляется реальным. RB> Кроме того со старых времен осталась масса приложений на VA for ST RB> корые переписать тоже крайне затруднительно все они используют RB> dinamic SQL. Тяжело, конечно. Как раз тот вариант, когда простота разработки приходит в конфликт с функциональностью результирующего продукта. Sincerely, Vadim. --- GoldED/2 3.0.1-GP * Origin: Electronic Kludge (2:5030/301) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms.sql/22163aa4cd7e.html, оценка из 5, голосов 10
|